From j.schoenwaelder@jacobs-university.de Tue Dec 3 04:34:09 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA931AE133 for ; Tue, 3 Dec 2013 04:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-UQAkKesZlu for ; Tue, 3 Dec 2013 04:34:07 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 41A701AE139 for ; Tue, 3 Dec 2013 04:34:07 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C70A2004D; Tue, 3 Dec 2013 13:34:04 +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 DYoqy1PAptSy; Tue, 3 Dec 2013 13:34:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F419D20046; Tue, 3 Dec 2013 13:34:03 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C0BF429CC953; Tue, 3 Dec 2013 13:33:58 +0100 (CET) Date: Tue, 3 Dec 2013 13:33:58 +0100 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy Management)" Message-ID: <20131203123358.GA70916@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy Management)" , 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) Cc: netmod@ietf.org Subject: [netmod] another iana timezone document update needed X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2013 12:34:10 -0000 Jeffrey, while producing the document writeup, I found some minor issues we should resolve before we ship this document to the IESG: a) You need to add a normative reference to RFC 6020. b) You need to add the following boilerplate text to the Introduction The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. and you need to add a normative reference to RFC 2119. c) You should reference RFC 6557 (I think both in the Introduction and the IANA Considerations section) since this document defines the general rules for the maintenance of the timezone database. And you need to add RFC 6557 to the normative references section. d) I suggest you revise the abstract to better reflect the purpose of the document. OLD This document defines the iana-timezones YANG module for timezone configuration. NEW This document defines the initial version of the iana-timezones YANG module. The iana-timezones YANG module defines the iana-timezone type, which is a serialization of the existing IANA Time Zone registry into YANG format. The document provides instructions to IANA how to maintain the iana-timezones YANG module when the underlying Time Zone registry is updated. e) Similarly, I suggest to revise the Introduction (this also takes account of item b) mentioned above): OLD This document defines the iana-timezones YANG module for timezone configuration. The iana-timezones module reflects IANA's existing "timezone database". The latest revision of the module can be obtained from the IANA web site (http://www.iana.org/time-zones). Whenever a new timezone name is added to the IANA "timezone database", the iana-timezones module is updated by IANA. NEW This document defines the initial version of the iana-timezones YANG module [RFC6020]. The iana-timezones YANG module defines the iana-timezone type, which is a serialization of the existing IANA Time Zone registry [RFC6557] into YANG format. Section 3 of this document provides instructions to IANA how to maintain the iana-timezones YANG module when the underlying Time Zone registry is updated. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. Can you produce a new revision of this 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 Dec 3 07:16:22 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B1A1ADBC7 for ; Tue, 3 Dec 2013 07:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N75yvc6crmQr for ; Tue, 3 Dec 2013 07:16:20 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 89FDB1AD9AB for ; Tue, 3 Dec 2013 07:16:20 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62E3F2006F; Tue, 3 Dec 2013 16:16:17 +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 boyCHNnvjyt1; Tue, 3 Dec 2013 16:16: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 E6AB920082; Tue, 3 Dec 2013 16:16:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4674229CD513; Tue, 3 Dec 2013 16:16:11 +0100 (CET) Date: Tue, 3 Dec 2013 16:16:10 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20131203151610.GB71692@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] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2013 15:16:22 -0000 Hi, I hereby like to start a WG last call for the document "A YANG Data Model for Routing Management": http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-12 Please indicate your support by Friday December 20th. We are not only interested in receiving defect reports, we are equally interested in statements of the form: "I have reviewed I-D XYZ and I found no issues" "I have implemented the data model in I-D XYZ" "I am implementing the data model in I-D XYZ" "I am considering to implement the data model in I-D XYZ" This is the 1st WG last call on this document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Dec 3 08:31:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED99B1A1F6F for ; Tue, 3 Dec 2013 08:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjh-9SuNUuP0 for ; Tue, 3 Dec 2013 08:31:30 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B1AAF1A1F65 for ; Tue, 3 Dec 2013 08:31:29 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D126720090; Tue, 3 Dec 2013 17:31:26 +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 FGaYP519pqwU; Tue, 3 Dec 2013 17:31:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 604BE2006D; Tue, 3 Dec 2013 17:31:26 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 082EC29CDADD; Tue, 3 Dec 2013 17:31:22 +0100 (CET) Date: Tue, 3 Dec 2013 17:31:21 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20131203163121.GA72067@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20131120070012.GA44513@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131120070012.GA44513@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 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, 03 Dec 2013 16:31:32 -0000 Hi, here is my quick summary of the result of the poll. In total, I saw input from six people and here is a dense summary of what I think they said. Let me know if something is missing or widely incorrect. * Proposed NETMOD work items [1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt [2] http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt * Martin Bjorklund [1] real problem, not sure the I-D has the proper solution [2] support (obviously) and implementation of this [3] support and willing to review [4] support of the work but not sure NETMOD is the right home [5] support of the work but not sure NETMOD is the right home [6] interesting issue but the solution may be too simplistic/specific * Andy Biermann [1] support (obviously) [2] support as a YANG extension but not as a new YANG version [3] support and required if RESTCONF gets chartered in NETCONF [4] support of the work but not sure NETMOD is the right home [5] support of the work but not sure NETMOD is the right home [6] network-wide data models is different than the NFS mount type solution Andy likes to avoid another version of the YANG language at this point in time. * Ladislav Lhotka [1] support but should be part of YANG 1.1 [2] support but should be part of YANG 1.1 [3] support but should be part of YANG 1.1 [4] support of the work but not sure NETMOD is the right home [5] support of the work but not sure NETMOD is the right home [6] support of the work but not sure NETMOD is the right home * Reinaldo Penno [1] [2] support but with lower priority [3] support adoption and willing to review [4] support adoption and willing to review [5] asking for a device model to complement this... [6] support adoption * Xufeng Liu [1] support but should be part of YANG 1.1 [2] support but should be part of YANG 1.1 [3] support and implementing this already [4] support of the work [5] support of the work and started to implement this [6] * Alexander Clemm [1] support but the solution may need further work [2] support [3] support [4] support (obviously) [5] support (obviously) [6] support (obviously) Alex believes YANG is not mainstream enough to have data models been done by other working groups. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Tue Dec 3 09:24:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E541AD942; Tue, 3 Dec 2013 09:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1zMjg9U6Kud; Tue, 3 Dec 2013 09:23:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 216061A1F08; Tue, 3 Dec 2013 09:23:59 -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: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131203172358.28840.31117.idtracker@ietfa.amsl.com> Date: Tue, 03 Dec 2013 09:23:58 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-iana-timezones-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:24:01 -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 Working Gr= oup of the IETF. Title : IANA Timezone Database YANG Module Author(s) : Jeffrey Lange Filename : draft-ietf-netmod-iana-timezones-03.txt Pages : 40 Date : 2013-12-03 Abstract: This document defines the initial version of the iana-timezones YANG module. The iana-timezones YANG module defines the iana-timezone type, which is a serialization of the existing IANA Time Zone registry into YANG format. The document provides instructions to IANA how to maintain the iana-timezones YANG module when the underlying Time Zone registry is updated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-timezones There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-iana-timezones-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-timezones-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Tue Dec 3 12:46:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA8E1ADF81; Tue, 3 Dec 2013 12:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSbPPlguakxn; Tue, 3 Dec 2013 12:46:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F7A1ADED6; Tue, 3 Dec 2013 12:46:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131203204604.3216.6394.idtracker@ietfa.amsl.com> Date: Tue, 03 Dec 2013 12:46:04 -0800 Cc: netmod@ietf.org Subject: [netmod] Last Call: (IANA Timezone Database YANG Module) to Proposed Standard X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 20:46:06 -0000 The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'IANA Timezone Database YANG Module' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-12-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the initial version of the iana-timezones YANG module. The iana-timezones YANG module defines the iana-timezone type, which is a serialization of the existing IANA Time Zone registry into YANG format. The document provides instructions to IANA how to maintain the iana-timezones YANG module when the underlying Time Zone registry is updated. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netmod-iana-timezones/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netmod-iana-timezones/ballot/ No IPR declarations have been submitted directly on this I-D. From yihuan@cisco.com Tue Dec 3 15:05:22 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8DC1AE1E1 for ; Tue, 3 Dec 2013 15:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jahdJ4M40K7y for ; Tue, 3 Dec 2013 15:05:20 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 3C60C1AE1D3 for ; Tue, 3 Dec 2013 15:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1166; q=dns/txt; s=iport; t=1386111914; x=1387321514; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=4BsxBq7j5RZPefz9g9FlhKuBsbtTi4msd2XAsL/gLVg=; b=X0HZndWzCv1USm3kewn4DYAFv7v8A+N1G0R5mRutjbon5JDetdIX0Fen XPHbbsl4QwVd3int3rC6WfBFQVVDUtHxskRzeZlR2So2g1rEKxtGL7FEz hc3pw92NdL62iFGZDODYQHiLYJYUGf31XH+Pde1exaF0e+/cAvKOVa7BD o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAOBinlKtJXG8/2dsb2JhbABXA4MHOFO4Gk6BGxZ0gicBBAEBARodNBkEAQgOAiYrDAslAgQBEogBDcFJFwSOahcRhCIDmBSBMJBjgymBaAY8 X-IronPort-AV: E=Sophos;i="4.93,820,1378857600"; d="scan'208";a="4107458" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-2.cisco.com with ESMTP; 03 Dec 2013 23:05:14 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB3N5ET3015485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 23:05:14 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.155]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 17:05:14 -0600 From: "Lisa Huang (yihuan)" To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20) Thread-Index: AQHO8Hwfr4EdK3Cwd0+oSTzn0uy2Pw== Date: Tue, 3 Dec 2013 23:05:13 +0000 Message-ID: In-Reply-To: <20131203151610.GB71692@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [128.107.158.60] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:05:22 -0000 I have reviewed I-D draft-ietf-netmod-routing-cfg-12 and I found no issues. Lisa On 12/3/13 7:16 AM, "Juergen Schoenwaelder" wrote: >Hi, > >I hereby like to start a WG last call for the document "A YANG Data >Model for Routing Management": > > http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-12 > >Please indicate your support by Friday December 20th. We are not only >interested in receiving defect reports, we are equally interested in >statements of the form: > > "I have reviewed I-D XYZ and I found no issues" > "I have implemented the data model in I-D XYZ" > "I am implementing the data model in I-D XYZ" > "I am considering to implement the data model in I-D XYZ" > >This is the 1st WG last call on this document. > >/js > >--=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 jmedved@cisco.com Tue Dec 3 20:53:35 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA071ADF8A for ; Tue, 3 Dec 2013 20:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1GdA0qlC4pj for ; Tue, 3 Dec 2013 20:53:30 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 73A321ADF23 for ; Tue, 3 Dec 2013 20:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3722; q=dns/txt; s=iport; t=1386132808; x=1387342408; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=4EvWBBylXIcHhQFZBMfEokenWgj+LTZySRvfE4sTaBw=; b=fXVON7GghRgRz1upeZNijsY7u5W0MfWJbkvx//aESw3Vumk426djmE9i W4KmbplXWTZIMeFtS74JUUI4+VRxpgVQWtnMOpiggfELVvGFmqMaDh26y lqaLZVTRHphDOeGlXwNIX3FKiyIPrsg4JEi3DRUJlgQjQKTV4RyqbKT2T o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAMG0nlKtJXHA/2dsb2JhbABXA4MHOFO4JU6BHhZ0gicBBAEBAWsZBAEIDgJRDAslAgQBEhuHZg3BNBcEjkcjFxGEIgOYFIEwkGODKYIq X-IronPort-AV: E=Sophos;i="4.93,822,1378857600"; d="scan'208";a="286227085" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 04 Dec 2013 04:53:27 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB44rRdE002276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 04:53:27 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.125]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 22:53:26 -0600 From: "Jan Medved (jmedved)" To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] poll of interest on I-Ds submitted to the NETMOD WG Thread-Index: AQHO5b4yaS9e5WVfTkma7gRhfcYT+ZpDI0uAgABJOgA= Date: Wed, 4 Dec 2013 04:53:26 +0000 Message-ID: In-Reply-To: <20131203163121.GA72067@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.27.7.165] Content-Type: text/plain; charset="Windows-1252" Content-ID: <835D5C943A93FC48A021AD332AA04469@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 04:53:35 -0000 Sorry for the late response, Ive been really underwater=8A FWIW, please fin= d below my input:=20 1. Support 2. Support 3. Support, being implemented in OpenDaylight 4. Support 5. Support, being implemented in OpenDaylight, 6. Support, being implemented in OpenDaylight - Martin: agreed, the draft needs more work, but it's an implementable starting point - Andy: agreed, but we need access to device models through the controller too Thanks, Jan On 12/3/13 8:31 AM, "Juergen Schoenwaelder" wrote: >Hi, > >here is my quick summary of the result of the poll. In total, I saw >input from six people and here is a dense summary of what I think they >said. Let me know if something is missing or widely incorrect. > >* Proposed NETMOD work items > > [1]=20 >http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt > [2]=20 >http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.t >xt > [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt > [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt > [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt > >* Martin Bjorklund > > [1] real problem, not sure the I-D has the proper solution > [2] support (obviously) and implementation of this > [3] support and willing to review > [4] support of the work but not sure NETMOD is the right home > [5] support of the work but not sure NETMOD is the right home > [6] interesting issue but the solution may be too simplistic/specific > >* Andy Biermann > > [1] support (obviously) > [2] support as a YANG extension but not as a new YANG version > [3] support and required if RESTCONF gets chartered in NETCONF > [4] support of the work but not sure NETMOD is the right home > [5] support of the work but not sure NETMOD is the right home > [6] network-wide data models is different than the NFS mount type >solution > > Andy likes to avoid another version of the YANG language at this > point in time. > >* Ladislav Lhotka > > [1] support but should be part of YANG 1.1 > [2] support but should be part of YANG 1.1 > [3] support but should be part of YANG 1.1 > [4] support of the work but not sure NETMOD is the right home > [5] support of the work but not sure NETMOD is the right home > [6] support of the work but not sure NETMOD is the right home > >* Reinaldo Penno > > [1]=20 > [2] support but with lower priority > [3] support adoption and willing to review > [4] support adoption and willing to review > [5] asking for a device model to complement this... > [6] support adoption > >* Xufeng Liu > > [1] support but should be part of YANG 1.1 > [2] support but should be part of YANG 1.1 > [3] support and implementing this already > [4] support of the work > [5] support of the work and started to implement this > [6]=20 > >* Alexander Clemm > > [1] support but the solution may need further work > [2] support > [3] support > [4] support (obviously) > [5] support (obviously) > [6] support (obviously) > > Alex believes YANG is not mainstream enough to have data models been > done by other working groups. > >/js > >--=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 bclaise@cisco.com Wed Dec 4 08:42:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF7D1AE2CC for ; Wed, 4 Dec 2013 08:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.501 X-Spam-Level: X-Spam-Status: No, score=-8.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znP_frFIdR4I for ; Wed, 4 Dec 2013 08:42:03 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4562B1AE2D9 for ; Wed, 4 Dec 2013 08:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25834; q=dns/txt; s=iport; t=1386175318; x=1387384918; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ZMcZ2sJBwk7eeKHinidkT6t2Qq2PIHLapkX7aJSNZUQ=; b=kKM/pU08gqtc12ouzyXQMdwqbStrEkXW3DZ75GqCJL4ujA4VOVrlgKit PYLjXOqzANlKVNsZW0tcBA6qCs0LpwWAXuVY4M0DEORPVzO+ZFoLyvGBA b6NIWhx7hCMid7WQzZBmJDznet/c+UsRUKWQjw92g2y2pq0q89UG8EbUI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtQGANdan1KQ/khN/2dsb2JhbABagwc4iSmnPIhRgSMWdIImAQEEeRAZEyUPAkYGDQEHAQEXh2cNwWYXjn4HhDMDmBSBMIUVi06DKjs X-IronPort-AV: E=Sophos;i="4.93,825,1378857600"; d="scan'208,217";a="1070782" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 04 Dec 2013 16:41:57 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB4GfoEC012543; Wed, 4 Dec 2013 16:41:52 GMT Message-ID: <529F5B4E.70406@cisco.com> Date: Wed, 04 Dec 2013 17:41:50 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Martin Bjorklund References: <529E61CC.1070202@cisco.com> In-Reply-To: <529E61CC.1070202@cisco.com> X-Forwarded-Message-Id: <529E61CC.1070202@cisco.com> Content-Type: multipart/alternative; boundary="------------030601030108050500040607" Cc: NETMOD Working Group Subject: [netmod] AD review draft-ietf-netmod-interfaces-cfg-13 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 16:42:06 -0000 This is a multi-part message in MIME format. --------------030601030108050500040607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, This draft came a long way since my previous AD review some months ago. Thanks. - From http://tools.ietf.org/html/rfc6241 o state data: The additional data on a system that is not configuration data such as read-only status information and collected statistics. However, the document makes a difference between the state data and counters Abstract This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data, state data and counters for the collection of statistics. Introduction The data model includes configuration data, state data and counters for the collection of statistics. Maybe the solution is to change "state data" in the above two sections to "state information", and to use "state data" when you mean both state data and counters. Note that all "state data" instance must be checked. - If the device supports arbitrarily named user-controlled interfaces, the NETCONF server advertises the feature "arbitrary-names". If the device does not advertise this feature, the names of user-controlled interfaces MUST match the device's naming scheme. How a client can learn the naming scheme of such devices is outside the scope of this document. I had to look in the appendix to understand this concept: E.1 . Router with Restricted Interface Names . . . . . . . . . .38 E.2 . Router with Arbitrary Interface Names . . . . . . . . . .39 (and it does make sense after reading the appendices) You should explain with an example: E1: The name of a vlan interface is restricted to the form ".". versus E2: The implementation does not restrict the user-controlled interface names. And refer the appendices for the examples. For a more complete example, seeAppendix E.2 . - OLD: In most cases, the "name" of an "interface" entry is mapped to ifName. ifName is defined as an DisplayString [RFC2579 ] which uses a 7-bit ASCII character set. An implementation MUST restrict the allowed values for "name" to match the restrictions of ifName. NEW: In most cases, the "name" of an "interface" entry is mapped to ifName. ifName is defined as an DisplayString [RFC2579 ] which uses a 7-bit ASCII character set. If the device implements IF-MIB [RFC2863 ], and the mapping is supported, an implementation MUST restrict the allowed values for "name" to match the restrictions of ifName. However, I see later on: When a configured user-controlled interface is created by the system, it is instantiated with the same name in the /interface-state/interface list. Since the name in that list MAY be mapped to ifName by an implementation, such an implementation MUST restrict the allowed values for this leaf so that it matches the restrictions of ifName. So it seems that my "NEW" is wrong. NEW NEW: In most cases, the "name" of an "interface" entry is mapped to ifName. ifName is defined as an DisplayString [RFC2579 ] which uses a 7-bit ASCII character set. Since the "name" MAY be mapped to ifName [RFC2863 ], an implementation MUST restrict the allowed values for "name" to match the restrictions of ifName. - There are a number of counters in the IF-MIB that exist in two versions; one with 32 bits and one with 64 bits. The YANG module contains the 64 bits counters only. NEW: There are a number of counters in the IF-MIB that exist in two versions; one with 32 bits and one with 64 bits. Amongst those, the YANG module contains the 64 bits counters only. - +----------------------------------+------------------------+ | YANG data node | IF-MIB object | +----------------------------------+------------------------+ | /interfaces-state/interface | ifEntry | | /interfaces-state/name | ifName | | description | ifAlias | | type | ifType | | enabled / admin-status | ifAdminStatus | | oper-status | ifOperStatus | | last-change | ifLastChange | | if-index | ifIndex | | link-up-down-trap-enable | ifLinkUpDownTrapEnable | | phys-address | ifPhysAddress | | higher-layer-if / lower-layer-if | ifStackTable | | speed | ifSpeed | | in-octets | ifHCInOctets | | in-unicast-pkts | ifHCInUcastPkts | | in-broadcast-pkts | ifHCInBroadcastPkts | | in-multicast-pkts | ifHCInMulticastPkts | | in-discards | ifInDiscards | | in-errors | ifInErrors | | in-unknown-protos | ifInUnknownProtos | | out-octets | ifHCOutOctets | | out-unicast-pkts | ifHCOutUcastPkts | | out-broadcast-pkts | ifHCOutBroadcastPkts | | out-multicast-pkts | ifHCOutMulticastPkts | | out-discards | ifOutDiscards | | out-errors | ifOutErrors | +----------------------------------+------------------------+ You should say a few words: - why /interfaces-state/interface and /interfaces-state/name only? - why type is both of them? (Btw, that's my guess that it applies to both them) One easy fix is to always prepend /interfaces/ and /interfaces-state/ +----------------------------------+------------------------+ | YANG data node | IF-MIB object | +----------------------------------+------------------------+ | /interfaces-state/interface | ifEntry | | /interfaces-state/name | ifName | | /interfaces/description | ifAlias | | /interfaces/type | ifType | | /interfaces-state/type | ifType | ... - I wondered about the correlation between the entries in /interface/ and /interfaces-state/ ? In the section 3.1, an extra paragraph would help, explaining the correlation of entries in/interfaces/ and/interfaces-state/ * In the normal case, ie, if all interfaces are configured, entries in/ //interface/ = entries in/interfaces-state/ * On top of that, if some interfaces are pre-provisioned, extra entries will appear in the/interfaces/ * However, it could also happen that not all interfaces are configured: in this case, all existing interfaces would appear in/ //interfaces-state/ while only the configured ones appear in/interface/ - Looking (only) at the figure at the beginning of section 3: +--ro interfaces-state +--ro interface* [name] +--ro higher-layer-if* interface-state-ref +--ro lower-layer-if* interface-state-ref I wondered if I could have interface layering for pre-provisioned interfaces (like a VLAN on soon-to-inserted line card). My first reaction was no, because I could not see under /interfaces/ : +--ro higher-layer-if* interface-ref +--ro lower-layer-if* interface-ref However, it's possible. While all the text is there in section 3.3, it might be stressed that two different mechanisms are used. OLD: Two state data leaf-lists, "higher-layer-if" and "lower-layer-if", represent a read-only view of the interface layering hierarchy. NEW: While the layering mechanism is configured with a new type (identityref), two state data leaf-lists, "higher-layer-if" and "lower-layer-if", represent a read-only view of the interface layering hierarchy (interface-state-ref). Note: I trust you on the English and correctness. - feature pre-provisioning { description "This feature indicates that the device supports pre-provisioning of interface configuration, i.e., it is possible to configure an interface whose physical interface hardware is not present on the device."; I wondered whether an OIR (Online Insertion and Removal) feature should advertise this pre-provisioning feature? I guess it depends whether the configuration is kept and visible or not. Anyway, I don't want to delay this document any further. So maybe something to consider in the future, potentially with a new OIR feature. - o Symbols after data node names: "?" means an optional node, "!" means a presence container, and "*" denotes a list and leaf-list. At first glance, I thought you missed 3 !, after each container. Until I realize that you speak about "presence container". Please make clear: for example, add the term to the terminology. - description "The list of configured interfaces on the device. The operational state of an interface is available in the /interfaces-state/interface list. If the configuration of a system-controlled interface cannot be used by the system (e.g., the interface hardware present does not match the interface type), then the configuration is not applied to the system-controlled interface shown in the /interfaces-state/interface list. If the the configuration of a user-controlled interface cannot be used by the system, the configured interface is not instantiated in the /interfaces-state/interface list."; s/the the/the - If the device supports pre-provisioning of interface configuration, the feature 'pre-provisioning' is advertised. If the device allows arbitrarily named user-controlled interfaces, the feature 'arbitrary-names' is advertised. Is this common practice to repeat this within a leaf, while the features are specified at the beginning of the YANG document. I could understand for the first entry because it makes the link with the previous paragraph, but the second comes out of the blue. I'm simply trying to understand what the conventions are. Once we agree on the changes, post a new version, and I'll progress the draft to IETF LC. Regards, Benoit --------------030601030108050500040607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

This draft came a long way since my previous AD review some months ago. Thanks.

-
From http://tools.ietf.org/html/rfc6241
   o  state data: The additional data on a system that is not
      configuration data such as read-only status information and
      collected statistics.
However, the document makes a difference between the state data and counters
Abstract

   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface type specific data models
   augment the generic interfaces data model defined in this document.
   The data model includes configuration data, state data and counters
   for the collection of statistics.
Introduction
   The data model includes configuration data, state data and counters
   for the collection of statistics.
Maybe the solution is to change "state data" in the above two sections to "state information", and to use "state data" when you mean both state data and counters. Note that all "state data" instance must be checked.

- 
   If the device supports arbitrarily named user-controlled interfaces,
   the NETCONF server advertises the feature "arbitrary-names".  If the
   device does not advertise this feature, the names of user-controlled
   interfaces MUST match the device's naming scheme.  How a client can
   learn the naming scheme of such devices is outside the scope of this
   document.

I had to look in the appendix to understand this concept:
     E.1.  Router with Restricted Interface Names . . . . . . . . . . 38
     E.2.  Router with Arbitrary Interface Names  . . . . . . . . . . 39
(and it does make sense after reading the appendices)

You should explain with an example:
   E1: The name of a vlan interface is restricted to the form
   "<physical-interface-name>.<subinterface-number>".

	versus

   E2: The implementation does not restrict the user-controlled interface
   names.

And refer the appendices for the examples.	
   For a more complete example, see Appendix E.2.


-
OLD:
   In most cases, the "name" of an "interface" entry is mapped to
   ifName. ifName is defined as an DisplayString [RFC2579] which uses a
   7-bit ASCII character set.  An implementation MUST restrict the
   allowed values for "name" to match the restrictions of ifName.
NEW:
   In most cases, the "name" of an "interface" entry is mapped to
   ifName. ifName is defined as an DisplayString [RFC2579] which uses a
   7-bit ASCII character set.  If the device implements IF-MIB [RFC2863], 
   and the mapping is supported, an implementation MUST restrict the allowed 
   values for "name" to match the restrictions of ifName.

However, I see later on:
              When a configured user-controlled interface is created by
              the system, it is instantiated with the same name in the
              /interface-state/interface list.  Since the name in that
              list MAY be mapped to ifName by an implementation, such an
              implementation MUST restrict the allowed values for this
              leaf so that it matches the restrictions of ifName.
So it seems that my "NEW" is wrong.
NEW NEW: 
   In most cases, the "name" of an "interface" entry is mapped to
   ifName. ifName is defined as an DisplayString [RFC2579] which uses a
   7-bit ASCII character set.  Since the "name" MAY be mapped to ifName [RFC2863], 
   an implementation MUST restrict the allowed values for "name" to match
   the restrictions of ifName.


- 
  There are a number of counters in the IF-MIB that exist in two
   versions; one with 32 bits and one with 64 bits.  The YANG module
   contains the 64 bits counters only. 

NEW:  
   There are a number of counters in the IF-MIB that exist in two
   versions; one with 32 bits and one with 64 bits.  Amongst those, the YANG module
   contains the 64 bits counters only. 



- 

       +----------------------------------+------------------------+
       | YANG data node                   | IF-MIB object          |
       +----------------------------------+------------------------+
       | /interfaces-state/interface      | ifEntry                |
       | /interfaces-state/name           | ifName                 |
       | description                      | ifAlias                |
       | type                             | ifType                 |
       | enabled / admin-status           | ifAdminStatus          |
       | oper-status                      | ifOperStatus           |
       | last-change                      | ifLastChange           |
       | if-index                         | ifIndex                |
       | link-up-down-trap-enable         | ifLinkUpDownTrapEnable |
       | phys-address                     | ifPhysAddress          |
       | higher-layer-if / lower-layer-if | ifStackTable           |
       | speed                            | ifSpeed                |
       | in-octets                        | ifHCInOctets           |
       | in-unicast-pkts                  | ifHCInUcastPkts        |
       | in-broadcast-pkts                | ifHCInBroadcastPkts    |
       | in-multicast-pkts                | ifHCInMulticastPkts    |
       | in-discards                      | ifInDiscards           |
       | in-errors                        | ifInErrors             |
       | in-unknown-protos                | ifInUnknownProtos      |
       | out-octets                       | ifHCOutOctets          |
       | out-unicast-pkts                 | ifHCOutUcastPkts       |
       | out-broadcast-pkts               | ifHCOutBroadcastPkts   |
       | out-multicast-pkts               | ifHCOutMulticastPkts   |
       | out-discards                     | ifOutDiscards          |
       | out-errors                       | ifOutErrors            |
       +----------------------------------+------------------------+

You should say a few words:
- why /interfaces-state/interface and /interfaces-state/name only?
- why type is both of them? (Btw, that's my guess that it applies to both them)

One easy fix is to always prepend /interfaces/ and /interfaces-state/

       +----------------------------------+------------------------+
       | YANG data node                   | IF-MIB object          |
       +----------------------------------+------------------------+
       | /interfaces-state/interface      | ifEntry                |
       | /interfaces-state/name           | ifName                 |
       | /interfaces/description          | ifAlias                |
       | /interfaces/type                 | ifType                 |
       | /interfaces-state/type           | ifType                 |
       ...   

- 
I wondered about the correlation between the entries in /interface/ and /interfaces-state/ ?
In the section 3.1, an extra paragraph would help, explaining the correlation of entries in /interfaces/ and /interfaces-state/
* In the normal case, ie, if all interfaces are configured, entries in /interface/ = entries in /interfaces-state/
* On top of that, if some interfaces are pre-provisioned, extra entries will appear in the /interfaces/
* However, it could also happen that not all interfaces are configured: 
  in this case, all existing interfaces would appear in /interfaces-state/ while only the configured ones appear in/interface/


-
Looking (only) at the figure at the beginning of section 3: 
  +--ro interfaces-state
         +--ro interface* [name]
            +--ro higher-layer-if*   interface-state-ref
            +--ro lower-layer-if*    interface-state-ref

I wondered if I could have interface layering for pre-provisioned interfaces (like a VLAN on soon-to-inserted line card).
My first reaction was no, because I could not see under /interfaces/ :
            +--ro higher-layer-if*   interface-ref
            +--ro lower-layer-if*    interface-ref

However, it's possible. While all the text is there in section 3.3, it might be stressed that two different mechanisms are used.
OLD:

   Two state data leaf-lists, "higher-layer-if" and "lower-layer-if",
   represent a read-only view of the interface layering hierarchy.

NEW:

   While the layering mechanism is configured with a new type
   (identityref), two state data leaf-lists, "higher-layer-if" 
   and "lower-layer-if", represent a read-only view of the interface 
   layering hierarchy (interface-state-ref).

Note: I trust you on the English and correctness.

   
-      feature pre-provisioning {
       description
         "This feature indicates that the device supports
          pre-provisioning of interface configuration, i.e., it is
          possible to configure an interface whose physical interface
          hardware is not present on the device.";

I wondered whether an OIR (Online Insertion and Removal) feature should advertise this pre-provisioning feature?
I guess it depends whether the configuration is kept and visible or not.
Anyway, I don't want to delay this document any further. 
So maybe something to consider in the future, potentially with a new OIR feature. 


- 
  o  Symbols after data node names: "?" means an optional node, "!"
      means a presence container, and "*" denotes a list and leaf-list.

At first glance, I thought you missed 3 !, after each container.
Until I realize that you speak about "presence container".
Please make clear: for example, add the term to the terminology.

- 
  description
           "The list of configured interfaces on the device.

            The operational state of an interface is available in the
            /interfaces-state/interface list.  If the configuration of a
            system-controlled interface cannot be used by the system
            (e.g., the interface hardware present does not match the
            interface type), then the configuration is not applied to
            the system-controlled interface shown in the
            /interfaces-state/interface list.  If the the configuration
            of a user-controlled interface cannot be used by the system,
            the configured interface is not instantiated in the
            /interfaces-state/interface list.";


s/the the/the


-
              If the device supports pre-provisioning of interface
              configuration, the feature 'pre-provisioning' is
              advertised.

              If the device allows arbitrarily named user-controlled
              interfaces, the feature 'arbitrary-names' is advertised.

Is this common practice to repeat this within a leaf, while the features are specified at the beginning of the YANG document.
I could understand for the first entry because it makes the link with the previous paragraph, but the second comes out of the blue.
I'm simply trying to understand what the conventions are.

Once we agree on the changes, post a new version, and I'll progress the draft to IETF LC.

Regards, Benoit

      

    

    

  


--------------030601030108050500040607--

From yihuan@cisco.com  Wed Dec  4 11:31:43 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843B51ADBD1 for ; Wed,  4 Dec 2013 11:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIPDieSyPkFf for ; Wed,  4 Dec 2013 11:31:41 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 91F9B1AD6A4 for ; Wed,  4 Dec 2013 11:31:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3738; q=dns/txt; s=iport; t=1386185498; x=1387395098; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=JRZ8O2yR0D5YzsKPRDArIF0NKrvaexF2OaGk1lsxfqI=; b=dqbYAV8u9O/Mi5C/olu2xKvZTBihP4Ytk/buAGypYnx8noTMSTowSDuB U8fwoL3mFM3NMRJqOB2444z6HwWKuHgw/nuamQk37JwGN5/gcuyHQRXHD Ap1+9nGXT0fZC2UvZ2CSqWUMve8i/f4arZztW9EX0qAXx4Sey4FYGgLZ/ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAHGCn1KtJXG+/2dsb2JhbABXA4MHOFO4Fk6BJBZ0gicBBAEBATc0GQQBCA4CJisMCyUCBAESG4dnDcFzFwSOahcRhCIDmBSBMJBjgymCKg
X-IronPort-AV: E=Sophos;i="4.93,827,1378857600";  d="scan'208";a="4347915"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-4.cisco.com with ESMTP; 04 Dec 2013 19:31:38 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB4JVc7D019616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 19:31:38 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.155]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 13:31:37 -0600
From: "Lisa Huang (yihuan)" 
To: Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] poll of interest on I-Ds submitted to the NETMOD WG
Thread-Index: AQHO5b4yzSJN0sRpG0KOgaODpvXY35pDI0uAgAE+mAA=
Date: Wed, 4 Dec 2013 19:31:37 +0000
Message-ID: 
In-Reply-To: <20131203163121.GA72067@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.85.135]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 04 Dec 2013 19:31:43 -0000

Sorry for my delayed reply.

1. Support. Have not completed read the draft yet.
2. I support this. I do have questions that what are the cases that a yang
model should use xpath functions if a better design of model is not
available. Use cases in the draft would be helpful.
3. Support. However, most data model used xpath to-some-extend.
Suggestions about how to deal with xpath in the draft would be helpful.
4. Support=20
5. Support. Could help to review it.
6. Support. Could help to review it.




On 12/3/13 8:31 AM, "Juergen Schoenwaelder"
 wrote:

>Hi,
>
>here is my quick summary of the result of the poll. In total, I saw
>input from six people and here is a dense summary of what I think they
>said. Let me know if something is missing or widely incorrect.
>
>* Proposed NETMOD work items
>
>  [1]=20
>http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt
>  [2]=20
>http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.t
>xt
>  [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt
>  [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt
>  [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt
>  [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt
>
>* Martin Bjorklund
>
>  [1] real problem, not sure the I-D has the proper solution
>  [2] support (obviously) and implementation of this
>  [3] support and willing to review
>  [4] support of the work but not sure NETMOD is the right home
>  [5] support of the work but not sure NETMOD is the right home
>  [6] interesting issue but the solution may be too simplistic/specific
>
>* Andy Biermann
>
>  [1] support (obviously)
>  [2] support as a YANG extension but not as a new YANG version
>  [3] support and required if RESTCONF gets chartered in NETCONF
>  [4] support of the work but not sure NETMOD is the right home
>  [5] support of the work but not sure NETMOD is the right home
>  [6] network-wide data models is different than the NFS mount type
>solution
>
>  Andy likes to avoid another version of the YANG language at this
>  point in time.
>
>* Ladislav Lhotka
>
>  [1] support but should be part of YANG 1.1
>  [2] support but should be part of YANG 1.1
>  [3] support but should be part of YANG 1.1
>  [4] support of the work but not sure NETMOD is the right home
>  [5] support of the work but not sure NETMOD is the right home
>  [6] support of the work but not sure NETMOD is the right home
>
>* Reinaldo Penno
>
>  [1]=20
>  [2] support but with lower priority
>  [3] support adoption and willing to review
>  [4] support adoption and willing to review
>  [5] asking for a device model to complement this...
>  [6] support adoption
>
>* Xufeng Liu
>
>  [1] support but should be part of YANG 1.1
>  [2] support but should be part of YANG 1.1
>  [3] support and implementing this already
>  [4] support of the work
>  [5] support of the work and started to implement this
>  [6]=20
>
>* Alexander Clemm
>
>  [1] support but the solution may need further work
>  [2] support
>  [3] support
>  [4] support (obviously)
>  [5] support (obviously)
>  [6] support (obviously)
>
>  Alex believes YANG is not mainstream enough to have data models been
>  done by other working groups.
>
>/js
>
>--=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 lhotka@nic.cz  Thu Dec  5 02:24:57 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C011ADDD1 for ; Thu,  5 Dec 2013 02:24:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level: 
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzv0ZqfVE3_H for ; Thu,  5 Dec 2013 02:24:55 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id B5F221ADBD0 for ; Thu,  5 Dec 2013 02:24:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id CEA0D540623 for ; Thu,  5 Dec 2013 11:24:49 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtRESOqoiPmh for ; Thu,  5 Dec 2013 11:24:42 +0100 (CET)
Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id D636A540251 for ; Thu,  5 Dec 2013 11:24:37 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: 
References: 
User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0)
Mail-Followup-To: netmod@ietf.org
Date: Thu, 05 Dec 2013 11:24:37 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Dec 2013 10:24:58 -0000

"Lisa Huang (yihuan)"  writes:

> Sorry for my delayed reply.
>
> 1. Support. Have not completed read the draft yet.
> 2. I support this. I do have questions that what are the cases that a yang
> model should use xpath functions if a better design of model is not
> available. Use cases in the draft would be helpful.
> 3. Support. However, most data model used xpath to-some-extend.
> Suggestions about how to deal with xpath in the draft would be helpful.

The draft is designed to handle XPath expressions appearing in the data model, the idea is to (conceptually) map JSON text to XML and an XPath expression is then evaluated with the latter.

It seems though an example would be helpul, I am appending it to the todo list.

Thanks, Lada

> 4. Support 
> 5. Support. Could help to review it.
> 6. Support. Could help to review it.
>
>
>
>
> On 12/3/13 8:31 AM, "Juergen Schoenwaelder"
>  wrote:
>
>>Hi,
>>
>>here is my quick summary of the result of the poll. In total, I saw
>>input from six people and here is a dense summary of what I think they
>>said. Let me know if something is missing or widely incorrect.
>>
>>* Proposed NETMOD work items
>>
>>  [1] 
>>http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt
>>  [2] 
>>http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.t
>>xt
>>  [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt
>>  [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt
>>  [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt
>>  [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt
>>
>>* Martin Bjorklund
>>
>>  [1] real problem, not sure the I-D has the proper solution
>>  [2] support (obviously) and implementation of this
>>  [3] support and willing to review
>>  [4] support of the work but not sure NETMOD is the right home
>>  [5] support of the work but not sure NETMOD is the right home
>>  [6] interesting issue but the solution may be too simplistic/specific
>>
>>* Andy Biermann
>>
>>  [1] support (obviously)
>>  [2] support as a YANG extension but not as a new YANG version
>>  [3] support and required if RESTCONF gets chartered in NETCONF
>>  [4] support of the work but not sure NETMOD is the right home
>>  [5] support of the work but not sure NETMOD is the right home
>>  [6] network-wide data models is different than the NFS mount type
>>solution
>>
>>  Andy likes to avoid another version of the YANG language at this
>>  point in time.
>>
>>* Ladislav Lhotka
>>
>>  [1] support but should be part of YANG 1.1
>>  [2] support but should be part of YANG 1.1
>>  [3] support but should be part of YANG 1.1
>>  [4] support of the work but not sure NETMOD is the right home
>>  [5] support of the work but not sure NETMOD is the right home
>>  [6] support of the work but not sure NETMOD is the right home
>>
>>* Reinaldo Penno
>>
>>  [1] 
>>  [2] support but with lower priority
>>  [3] support adoption and willing to review
>>  [4] support adoption and willing to review
>>  [5] asking for a device model to complement this...
>>  [6] support adoption
>>
>>* Xufeng Liu
>>
>>  [1] support but should be part of YANG 1.1
>>  [2] support but should be part of YANG 1.1
>>  [3] support and implementing this already
>>  [4] support of the work
>>  [5] support of the work and started to implement this
>>  [6] 
>>
>>* Alexander Clemm
>>
>>  [1] support but the solution may need further work
>>  [2] support
>>  [3] support
>>  [4] support (obviously)
>>  [5] support (obviously)
>>  [6] support (obviously)
>>
>>  Alex believes YANG is not mainstream enough to have data models been
>>  done by other working groups.
>>
>>/js
>>
>>-- 
>>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
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

From mbj@tail-f.com  Thu Dec  5 03:32:18 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D841ADF5C for ; Thu,  5 Dec 2013 03:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxuZWBonJezY for ; Thu,  5 Dec 2013 03:32:16 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id D4BC31ADF58 for ; Thu,  5 Dec 2013 03:32:15 -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 C071037C004; Thu,  5 Dec 2013 12:32:10 +0100 (CET)
Date: Thu, 05 Dec 2013 12:32:10 +0100 (CET)
Message-Id: <20131205.123210.2269861100175493083.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <529F5B4E.70406@cisco.com>
References: <529E61CC.1070202@cisco.com> <529F5B4E.70406@cisco.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Dec 2013 11:32:19 -0000

Hi Benoit,

Benoit Claise  wrote:
> Dear all,
> 
> This draft came a long way since my previous AD review some months
> ago. Thanks.
> 
> -
> From http://tools.ietf.org/html/rfc6241
> 
>    o  state data: The additional data on a system that is not
>       configuration data such as read-only status information and
>       collected statistics.
> 
> However, the document makes a difference between the state data and
> counters
> 
> Abstract
> 
>    This document defines a YANG data model for the management of network
>    interfaces.  It is expected that interface type specific data models
>    augment the generic interfaces data model defined in this document.
>    The data model includes configuration data, state data and counters
>    for the collection of statistics.
> 
> Introduction
> 
>    The data model includes configuration data, state data and counters
>    for the collection of statistics.
> 
> Maybe the solution is to change "state data" in the above two sections
> to "state information", and to use "state data" when you mean both
> state data and counters. Note that all "state data" instance must be
> checked.

So the issue is that in 6241 state data is defined as:

   state data = status information + statistics

And here we say:

   state data + statistics

which doesn't make sense if "state data" already includes statistics.

Proposal:

OLD:

    The data model includes configuration data, state data and counters
    for the collection of statistics.

NEW:

    The data model includes configuration data, status information and
    counters for the collection of statistics.

(in the Abstract and Introduction).

> -
> 
>    If the device supports arbitrarily named user-controlled interfaces,
>    the NETCONF server advertises the feature "arbitrary-names".  If the
>    device does not advertise this feature, the names of user-controlled
>    interfaces MUST match the device's naming scheme.  How a client can
>    learn the naming scheme of such devices is outside the scope of this
>    document.
> 
> I had to look in the appendix to understand this concept:
>      E.1
>      .
>      Router with Restricted Interface Names . . . . . . . . . .38
>      
>      E.2
>      .
>      Router with Arbitrary Interface Names . . . . . . . . . .39
>      
> (and it does make sense after reading the appendices)
> 
> You should explain with an example:
>    E1: The name of a vlan interface is restricted to the form
>    ".".
> 
> 	versus
> 
>    E2: The implementation does not restrict the user-controlled interface
>    names.
> 
> And refer the appendices for the examples.	
>    For a more complete example, seeAppendix E.2
>    .
> 
> 

Proposal:

OLD:

   interfaces MUST match the device's naming scheme.  How a client can
   learn the naming scheme of such devices is outside the scope of this
   document.

NEW:

   interfaces MUST match the device's naming scheme.  How a client can
   learn the naming scheme of such devices is outside the scope of this
   document.  See Appendix E.1 and Appendix E.2 for examples.


> -
> OLD:
>    In most cases, the "name" of an "interface" entry is mapped to
>    ifName. ifName is defined as an DisplayString [RFC2579
>    ] which uses a
>    7-bit ASCII character set.  An implementation MUST restrict the
>    allowed values for "name" to match the restrictions of ifName.
> NEW:
>    In most cases, the "name" of an "interface" entry is mapped to
>    ifName. ifName is defined as an DisplayString [RFC2579
>    ] which uses a
>    7-bit ASCII character set.  If the device implements IF-MIB [RFC2863
>    ],
>    and the mapping is supported, an implementation MUST restrict the
>    allowed
>    values for "name" to match the restrictions of ifName.
> 
> However, I see later on:
>               When a configured user-controlled interface is created by
>               the system, it is instantiated with the same name in the
>               /interface-state/interface list.  Since the name in that
>               list MAY be mapped to ifName by an implementation, such an
>               implementation MUST restrict the allowed values for this
>               leaf so that it matches the restrictions of ifName.
> So it seems that my "NEW" is wrong.
> NEW NEW:
>    In most cases, the "name" of an "interface" entry is mapped to
>    ifName. ifName is defined as an DisplayString [RFC2579
>    ] which uses a
>    7-bit ASCII character set.  Since the "name" MAY be mapped to ifName
>    [RFC2863 ],
>    an implementation MUST restrict the allowed values for "name" to match
>    the restrictions of ifName.
> 
> 


Proposal:

OLD:

   In most cases, the "name" of an "interface" entry is mapped to
   ifName. ifName is defined as an DisplayString [RFC2579] which uses
   a 7-bit ASCII character set.  An implementation MUST restrict the
   allowed values for "name" to match the restrictions of ifName.

NEW:

   In most cases, the "name" of an "interface" entry is mapped to
   ifName. ifName is defined as an DisplayString [RFC2579] which uses a
   7-bit ASCII character set.  An implementation that performs this
   mapping MUST restrict the allowed values for "name" to match the
   restrictions of ifName.


> -
>   There are a number of counters in the IF-MIB that exist in two
>    versions; one with 32 bits and one with 64 bits.  The YANG module
>    contains the 64 bits counters only.
> 
> NEW:
>    There are a number of counters in the IF-MIB that exist in two
>    versions; one with 32 bits and one with 64 bits.  Amongst those, the
>    YANG module
>    contains the 64 bits counters only.

Ok.

> -
> 
>        +----------------------------------+------------------------+
>        | YANG data node                   | IF-MIB object          |
>        +----------------------------------+------------------------+
>        | /interfaces-state/interface      | ifEntry                |
>        | /interfaces-state/name           | ifName                 |
>        | description                      | ifAlias                |
>        | type                             | ifType                 |
>        | enabled / admin-status           | ifAdminStatus          |
>        | oper-status                      | ifOperStatus           |
>        | last-change                      | ifLastChange           |
>        | if-index                         | ifIndex                |
>        | link-up-down-trap-enable         | ifLinkUpDownTrapEnable |
>        | phys-address                     | ifPhysAddress          |
>        | higher-layer-if / lower-layer-if | ifStackTable           |
>        | speed                            | ifSpeed                |
>        | in-octets                        | ifHCInOctets           |
>        | in-unicast-pkts                  | ifHCInUcastPkts        |
>        | in-broadcast-pkts                | ifHCInBroadcastPkts    |
>        | in-multicast-pkts                | ifHCInMulticastPkts    |
>        | in-discards                      | ifInDiscards           |
>        | in-errors                        | ifInErrors             |
>        | in-unknown-protos                | ifInUnknownProtos      |
>        | out-octets                       | ifHCOutOctets          |
>        | out-unicast-pkts                 | ifHCOutUcastPkts       |
>        | out-broadcast-pkts               | ifHCOutBroadcastPkts   |
>        | out-multicast-pkts               | ifHCOutMulticastPkts   |
>        | out-discards                     | ifOutDiscards          |
>        | out-errors                       | ifOutErrors            |
>        +----------------------------------+------------------------+
> 
> You should say a few words:
> - why /interfaces-state/interface and /interfaces-state/name only?

Note that the first sentence in section 4 is:

   If the device implements IF-MIB [RFC2863], each entry in the
   "/interfaces-state/interface" list is typically mapped to one
   ifEntry.

So the mapping is from /interfaces-state/interface to ifEntry.

> - why type is both of them? (Btw, that's my guess that it applies to
> - both them)

See below.

> One easy fix is to always prepend /interfaces/ and /interfaces-state/
> 
>        +----------------------------------+------------------------+
>        | YANG data node                   | IF-MIB object          |
>        +----------------------------------+------------------------+
>        | /interfaces-state/interface      | ifEntry                |
>        | /interfaces-state/name           | ifName                 |
>        | /interfaces/description          | ifAlias                |
>        | /interfaces/type                 | ifType                 |
>        | /interfaces-state/type           | ifType                 |
>        ...
> 
> -
> I wondered about the correlation between the entries in /interface/
> and /interfaces-state/ ?
> In the section 3.1, an extra paragraph would help, explaining the
> correlation of entries in/interfaces/ and/interfaces-state/
> * In the normal case, ie, if all interfaces are configured, entries in/
> * //interface/ = entries in/interfaces-state/
> * On top of that, if some interfaces are pre-provisioned, extra entries
> * will appear in the/interfaces/
> * However, it could also happen that not all interfaces are configured:
>   in this case, all existing interfaces would appear in/
>   //interfaces-state/ while only the configured ones appear
>   in/interface/


Adding the prefix to all of them makes the table look bad (too long
rows...)  I propose that we add the prefix in all cases where there's
a conflict, but do not use the prefix where there is no conflict.
Specifically, this means that the "type" node gets a prefix:

Proposal:

OLD:

       | /interfaces-state/interface      | ifEntry                |
       | /interfaces-state/name           | ifName                 |
       | description                      | ifAlias                |
       | type                             | ifType                 |

NEW:

       | /interfaces-state/interface      | ifEntry                |
       | /interfaces-state/name           | ifName                 |
       | description                      | ifAlias                |
       | /interfaces-state/type           | ifType                 |


> -
> Looking (only) at the figure at the beginning of section 3:
>   +--ro interfaces-state
>          +--ro interface* [name]
>             +--ro higher-layer-if*   interface-state-ref
>             +--ro lower-layer-if*    interface-state-ref
> 
> I wondered if I could have interface layering for pre-provisioned
> interfaces (like a VLAN on soon-to-inserted line card).
> My first reaction was no, because I could not see under /interfaces/ :
>             +--ro higher-layer-if*   interface-ref
>             +--ro lower-layer-if*    interface-ref
> 
> However, it's possible. While all the text is there in section 3.3, it
> might be stressed that two different mechanisms are used.
> OLD:
> 
>    Two state data leaf-lists, "higher-layer-if" and "lower-layer-if",
>    represent a read-only view of the interface layering hierarchy.
> 
> NEW:
> 
>    While the layering mechanism is configured with a new type
>    (identityref), two state data leaf-lists, "higher-layer-if"
>    and "lower-layer-if", represent a read-only view of the interface
>    layering hierarchy (interface-state-ref).
> 
> Note: I trust you on the English and correctness.
> 

Proposal:

NEW:

  While the interface layering is configured in type specific models,
  two generic state data leaf-lists, "higher-layer-if" and
  "lower-layer-if", represent a read-only view of the interface
  layering hierarchy.


>    -      feature pre-provisioning {
>        description
>          "This feature indicates that the device supports
>           pre-provisioning of interface configuration, i.e., it is
>           possible to configure an interface whose physical interface
>           hardware is not present on the device.";
> 
> I wondered whether an OIR (Online Insertion and Removal) feature
> should advertise this pre-provisioning feature?
> I guess it depends whether the configuration is kept and visible or
> not.
> Anyway, I don't want to delay this document any further.
> So maybe something to consider in the future, potentially with a new
> OIR feature.

Ok.

> -
>   o  Symbols after data node names: "?" means an optional node, "!"
>       means a presence container, and "*" denotes a list and leaf-list.
> 
> At first glance, I thought you missed 3 !, after each container.
> Until I realize that you speak about "presence container".
> Please make clear: for example, add the term to the terminology.
> 

Ok; specifically I suggest we add the term "presence container" to
the list in section 1.1, under:

   The following terms are defined in [RFC6020] and are not redefined
   here:



> -
>   description
>            "The list of configured interfaces on the device.
> 
>             The operational state of an interface is available in the
>             /interfaces-state/interface list.  If the configuration of a
>             system-controlled interface cannot be used by the system
>             (e.g., the interface hardware present does not match the
>             interface type), then the configuration is not applied to
>             the system-controlled interface shown in the
>             /interfaces-state/interface list.  If the the configuration
>             of a user-controlled interface cannot be used by the system,
>             the configured interface is not instantiated in the
>             /interfaces-state/interface list.";
> 
> 
> s/the the/the


Ok.

> -
>               If the device supports pre-provisioning of interface
>               configuration, the feature 'pre-provisioning' is
>               advertised.
> 
>               If the device allows arbitrarily named user-controlled
>               interfaces, the feature 'arbitrary-names' is advertised.
> 
> Is this common practice to repeat this within a leaf, while the
> features are specified at the beginning of the YANG document.
> I could understand for the first entry because it makes the link with
> the previous paragraph, but the second comes out of the blue.
> I'm simply trying to understand what the conventions are.

There are no such conventions; we're just trying to make the
description text as clear as possible.  I think this helps in this
case, but if people think it makes the text confusing we can remove
it.


/martin

From mbj@tail-f.com  Thu Dec  5 03:42:10 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512A11ADF62; Thu,  5 Dec 2013 03:42:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t6yT8WQqx-y; Thu,  5 Dec 2013 03:42:07 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 15E3B1ADE8B; Thu,  5 Dec 2013 03:42:07 -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 5967937C003; Thu,  5 Dec 2013 12:42:03 +0100 (CET)
Date: Thu, 05 Dec 2013 12:42:03 +0100 (CET)
Message-Id: <20131205.124203.1262736930138942377.mbj@tail-f.com>
To: jonathan@hansfords.net
From: Martin Bjorklund 
In-Reply-To: <805097241-1386243620-cardhu_decombobulator_blackberry.rim.net-562429940-@b12.c4.bise7.blackberry>
References: <529F5B4E.70406@cisco.com> <20131205.123210.2269861100175493083.mbj@tail-f.com> <805097241-1386243620-cardhu_decombobulator_blackberry.rim.net-562429940-@b12.c4.bise7.blackberry>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod-bounces@ietf.org, netmod@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Dec 2013 11:42:10 -0000

"Jonathan Hansford"  wrote:
> A VERY small point, but it frustrates me each time I read it:
> 
> s/an DisplayString/a DisplayString

Fixed!


/martin

From ietfdbh@comcast.net  Thu Dec  5 08:57:42 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688661AE0C8 for ; Thu,  5 Dec 2013 08:57:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6xr_V50_fUG for ; Thu,  5 Dec 2013 08:57:40 -0800 (PST)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id E0EF31AE0A9 for ; Thu,  5 Dec 2013 08:57:39 -0800 (PST)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta15.westchester.pa.mail.comcast.net with comcast id xqU21m0020Fqzac5Fsxccf; Thu, 05 Dec 2013 16:57:36 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta08.westchester.pa.mail.comcast.net with comcast id xsxb1m00b2yZEBF3Usxcy1; Thu, 05 Dec 2013 16:57:36 +0000
From: "ietfdbh" 
To: "'Martin Bjorklund'" , 
References: <529E61CC.1070202@cisco.com>	<529F5B4E.70406@cisco.com> <20131205.123210.2269861100175493083.mbj@tail-f.com>
In-Reply-To: <20131205.123210.2269861100175493083.mbj@tail-f.com>
Date: Thu, 5 Dec 2013 11:57:38 -0500
Message-ID: <029401cef1db$1ab5ffb0$5021ff10$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMAvbxV5QzuoJGt2JlaezLLrsDkdwHAgkoBAt5j7SCXvRCigA==
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386262656; bh=03pv8b3V8lAPMHtsG64XXOX1w23mKZKGNWLen7l7gFs=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=ADx161PRhbRx2pMyKOZdC/2W4H9dgkDOxlwQ0x/YZ0EKl/wv30rdLPMfM8rFCCLgg xIFm+Wt/J8rVBd/TuiQkcxhDxgtzgNW9Wn3Q7Ad88JpzBTWh2jflM+Zv66G+iCwclG kPzm6ebtkX9/xbEAp7Hb7DUoc7CetWXBI5as9+InI82bWmLILah788J3WM0KINl0YQ MdOpgmCCwv/tYzKXa1HAbNUrZJGGqF1m4JtVWb0Nm2kmH3JuEZ6/FjjO50nY+/zWzK n9u4g9kkxJ/1y9PtuguC3rO9wTkR2PwvVNyLDvSsqnvbaAoSFw/U7wcxpt5RnKNs4X 4w2tR02xQmTQA==
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Dec 2013 16:57:42 -0000

Comments inline

David Harrington
ietfdbh@comcast.net
+1-603-828-1401

> Proposal:
> 
> OLD:
> 
>     The data model includes configuration data, state data and counters
>     for the collection of statistics.
> 
> NEW:
> 
>     The data model includes configuration data, status information and
>     counters for the collection of statistics.
> 
> (in the Abstract and Introduction).

Why not simply:
     The data model includes configuration data and state data.

Let me ask a question. The WG has decided that config data and state data
should be in separate trees.
If there is config data + status information + counters, does that imply a
separate tree for the counters? If so, why?

There has been some discussion that, if state data was mixed with config
data in the same tree, that the volatility of counters would make it harder
to query for changes to config data. Would this also be true of status
information? If so, then maybe a separate tree for counters would make
sense. When I worked on NMS code, we frequently queried the counters, but
less frequently needed to check for changes to config or status information,
and while LastChanged objects were helpful to drive when config/status
information needed to be updated on the NMS-side, LastChanged objects simply
wouldn't work for most counters.

> 
[...]
> Proposal:
> 
> OLD:
> 
>    In most cases, the "name" of an "interface" entry is mapped to
>    ifName. ifName is defined as an DisplayString [RFC2579] which uses
>    a 7-bit ASCII character set.  An implementation MUST restrict the
>    allowed values for "name" to match the restrictions of ifName.
> 
> NEW:
> 
>    In most cases, the "name" of an "interface" entry is mapped to
>    ifName. ifName is defined as an DisplayString [RFC2579] which uses a
>    7-bit ASCII character set.  An implementation that performs this
>    mapping MUST restrict the allowed values for "name" to match the
>    restrictions of ifName.
> 

How about:
> NEW NEW NEW ;-):
> 
    In most cases, the "name" of an "interface" entry is mapped to
    ifName. ifName is defined as a DisplayString [RFC2579] which uses
    a 7-bit ASCII character set.  For interoperability reasons, an
implementation MUST restrict the
    allowed values for "name" to match the restrictions of ifName.

I recommend you REQUIRE DisplayString syntax, to ensure interoperability
between clients and servers.
If this is left as an implementation choice, then you probably should
identify the different requirements for servers and clients.
If servers are allowed to implement using non-DisplayString semantics, the
standard should place some restrictions on what is allowed, so client
implementers know what they need to accommodate. 

Can a server choose to implement using an 8-bit or 16-bit character set? How
should a client determine that this is the case?
Can a server choose to ignore the special meanings of NUL, LF, CR, BEL, BS,
HT, VT and FF? If an NMS expects servers to abide by those special meanings,
it could misinterpret data, and mislead operators.
Can a server choose to implement names that exceed 255 characters? If so,
what is an NMS that allocates a 255-character buffer REQUIRED to do with the
excess? Throw it away and ignore it? How should subsequent matching
algorithms deal with that truncation?
If a server implements names > 255, MUST/SHOULD/MAY a client dynamically
allocate larger buffers to accommodate whatever size a server chooses to
send? How should the NMS know how big a buffer is needed, if the delimiters
of the name are implementation-specific?

These questions of interoperability are important whether the server
implements IF-MIB or not.
The processing would be much less complex, and more interoperable, if
implementations were **standardized** to use consistent size and character
set constraints, regardless of the presence of IF-MIB.

> 
> > -
> >   There are a number of counters in the IF-MIB that exist in two
> >    versions; one with 32 bits and one with 64 bits.  The YANG module
> >    contains the 64 bits counters only.
> >
> > NEW:
> >    There are a number of counters in the IF-MIB that exist in two
> >    versions; one with 32 bits and one with 64 bits.  Amongst those, the
> >    YANG module
> >    contains the 64 bits counters only.
> 

It might be helpful to explain why:
NEW:
There are a number of counters in the IF-MIB that are duplicated in two
versions; Counter32s, for backwards compatibility with SNMPv1, and
Counter64s, to support high capacity devices.  
Since SNMPv1 has been declared Historic, the YANG module
contains only the 64 bit counters.

> Adding the prefix to all of them makes the table look bad (too long
> rows...)  I propose that we add the prefix in all cases where there's
> a conflict, but do not use the prefix where there is no conflict.
> Specifically, this means that the "type" node gets a prefix:
> 
> Proposal:
> 
> OLD:
> 
>        | /interfaces-state/interface      | ifEntry                |
>        | /interfaces-state/name           | ifName                 |
>        | description                      | ifAlias                |
>        | type                             | ifType                 |
> 
> NEW:
> 
>        | /interfaces-state/interface      | ifEntry                |
>        | /interfaces-state/name           | ifName                 |
>        | description                      | ifAlias                |
>        | /interfaces-state/type           | ifType                 |
> 

I think it is less ambiguous to include the prefix consistently.
In a standard, avoiding ambiguity is more important than avoiding looking
bad (long rows).

> 
> > -
> >               If the device supports pre-provisioning of interface
> >               configuration, the feature 'pre-provisioning' is
> >               advertised.
> >
> >               If the device allows arbitrarily named user-controlled
> >               interfaces, the feature 'arbitrary-names' is advertised.
> >
> > Is this common practice to repeat this within a leaf, while the
> > features are specified at the beginning of the YANG document.
> > I could understand for the first entry because it makes the link with
> > the previous paragraph, but the second comes out of the blue.
> > I'm simply trying to understand what the conventions are.
> 
> There are no such conventions; we're just trying to make the
> description text as clear as possible.  I think this helps in this
> case, but if people think it makes the text confusing we can remove
> it.
> 

I'm a little concerned about the use of "arbitrary-names".
You don't have any **useful** definition of what arbitrary means.
The definition of arbitrary names uses arbitrary in the definition (usually
considered a bad thing).
I think, but am not sure, that what you mean is that the "arbitrary"
constraints on naming are implementation-specific.

For reasons I mentioned above, I think "arbitrary constraints" are a bad
thing.
At a minimum, I think the document should standardize some constraints on
the naming, even if those constraints are not DisplayString, otherwise it
can be difficult for implementations to interoperate.


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


From mbj@tail-f.com  Thu Dec  5 13:06:03 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896E31AE116 for ; Thu,  5 Dec 2013 13:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xafI06gRlKr for ; Thu,  5 Dec 2013 13:06:00 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFA71AE110 for ; Thu,  5 Dec 2013 13:05:57 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 69D0E37C007; Thu,  5 Dec 2013 22:05:52 +0100 (CET)
Date: Thu, 05 Dec 2013 22:05:52 +0100 (CET)
Message-Id: <20131205.220552.467577048.mbj@tail-f.com>
To: ietfdbh@comcast.net
From: Martin Bjorklund 
In-Reply-To: <029401cef1db$1ab5ffb0$5021ff10$@comcast.net>
References: <529F5B4E.70406@cisco.com> <20131205.123210.2269861100175493083.mbj@tail-f.com> <029401cef1db$1ab5ffb0$5021ff10$@comcast.net>
X-Mailer: Mew version 6.5 on Emacs 23.4 / 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] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Dec 2013 21:06:03 -0000

Hi David,

"ietfdbh"  wrote:
> Comments inline
> 
> David Harrington
> ietfdbh@comcast.net
> +1-603-828-1401
> 
> > Proposal:
> > 
> > OLD:
> > 
> >     The data model includes configuration data, state data and counters
> >     for the collection of statistics.
> > 
> > NEW:
> > 
> >     The data model includes configuration data, status information and
> >     counters for the collection of statistics.
> > 
> > (in the Abstract and Introduction).
> 
> Why not simply:
>      The data model includes configuration data and state data.

Ok, that's better.

> Let me ask a question. The WG has decided that config data and state
> data
> should be in separate trees.
> If there is config data + status information + counters, does that
> imply a
> separate tree for the counters? If so, why?
> 
> There has been some discussion that, if state data was mixed with
> config
> data in the same tree, that the volatility of counters would make it
> harder
> to query for changes to config data.

In this particular case this was not the reason for the separation.
(the reason for separation was that the configured interfaces and the
interfaces actually in use on the device are really separate entities).

> Would this also be true of status
> information? If so, then maybe a separate tree for counters would make
> sense. When I worked on NMS code, we frequently queried the counters,
> but
> less frequently needed to check for changes to config or status
> information,
> and while LastChanged objects were helpful to drive when config/status
> information needed to be updated on the NMS-side, LastChanged objects
> simply
> wouldn't work for most counters.

Agreed.

> > Proposal:
> > 
> > OLD:
> > 
> >    In most cases, the "name" of an "interface" entry is mapped to
> >    ifName. ifName is defined as an DisplayString [RFC2579] which uses
> >    a 7-bit ASCII character set.  An implementation MUST restrict the
> >    allowed values for "name" to match the restrictions of ifName.
> > 
> > NEW:
> > 
> >    In most cases, the "name" of an "interface" entry is mapped to
> >    ifName. ifName is defined as an DisplayString [RFC2579] which uses a
> >    7-bit ASCII character set.  An implementation that performs this
> >    mapping MUST restrict the allowed values for "name" to match the
> >    restrictions of ifName.
> > 
> 
> How about:
> > NEW NEW NEW ;-):
> > 
>     In most cases, the "name" of an "interface" entry is mapped to
>     ifName. ifName is defined as a DisplayString [RFC2579] which uses
>     a 7-bit ASCII character set.  For interoperability reasons, an
> implementation MUST restrict the
>     allowed values for "name" to match the restrictions of ifName.
> 
> I recommend you REQUIRE DisplayString syntax, to ensure
> interoperability
> between clients and servers.

Agreed.  That's what we have both in the current text, and in the
proposed clarified text.  I.e., if you map to ifName, then you MUST
match its restrictions.

> If this is left as an implementation choice, then you probably should
> identify the different requirements for servers and clients.
> If servers are allowed to implement using non-DisplayString semantics,
> the
> standard should place some restrictions on what is allowed, so client
> implementers know what they need to accommodate. 
> 
> Can a server choose to implement using an 8-bit or 16-bit character
> set? How
> should a client determine that this is the case?
> Can a server choose to ignore the special meanings of NUL, LF, CR,
> BEL, BS,
> HT, VT and FF? If an NMS expects servers to abide by those special
> meanings,
> it could misinterpret data, and mislead operators.
> Can a server choose to implement names that exceed 255 characters? If
> so,
> what is an NMS that allocates a 255-character buffer REQUIRED to do
> with the
> excess? Throw it away and ignore it? How should subsequent matching
> algorithms deal with that truncation?
> If a server implements names > 255, MUST/SHOULD/MAY a client
> dynamically
> allocate larger buffers to accommodate whatever size a server chooses
> to
> send? How should the NMS know how big a buffer is needed, if the
> delimiters
> of the name are implementation-specific?
> 
> These questions of interoperability are important whether the server
> implements IF-MIB or not.
> The processing would be much less complex, and more interoperable, if
> implementations were **standardized** to use consistent size and
> character
> set constraints, regardless of the presence of IF-MIB.

The leaf "name" is of type string.  So whatever is a valid string is
acceptable.  See RFC 6020 for a definition of valid strings.

> > > -
> > >   There are a number of counters in the IF-MIB that exist in two
> > >    versions; one with 32 bits and one with 64 bits.  The YANG module
> > >    contains the 64 bits counters only.
> > >
> > > NEW:
> > >    There are a number of counters in the IF-MIB that exist in two
> > >    versions; one with 32 bits and one with 64 bits.  Amongst those, the
> > >    YANG module
> > >    contains the 64 bits counters only.
> > 
> 
> It might be helpful to explain why:
> NEW:
> There are a number of counters in the IF-MIB that are duplicated in
> two
> versions; Counter32s, for backwards compatibility with SNMPv1, and
> Counter64s, to support high capacity devices.  
> Since SNMPv1 has been declared Historic, the YANG module
> contains only the 64 bit counters.

Ok, make sense.

> > Adding the prefix to all of them makes the table look bad (too long
> > rows...)  I propose that we add the prefix in all cases where there's
> > a conflict, but do not use the prefix where there is no conflict.
> > Specifically, this means that the "type" node gets a prefix:
> > 
> > Proposal:
> > 
> > OLD:
> > 
> >        | /interfaces-state/interface      | ifEntry                |
> >        | /interfaces-state/name           | ifName                 |
> >        | description                      | ifAlias                |
> >        | type                             | ifType                 |
> > 
> > NEW:
> > 
> >        | /interfaces-state/interface      | ifEntry                |
> >        | /interfaces-state/name           | ifName                 |
> >        | description                      | ifAlias                |
> >        | /interfaces-state/type           | ifType                 |
> > 
> 
> I think it is less ambiguous to include the prefix consistently.

What is the ambiguity?

> In a standard, avoiding ambiguity is more important than avoiding
> looking
> bad (long rows).

I certainly agree.

> > > -
> > >               If the device supports pre-provisioning of interface
> > >               configuration, the feature 'pre-provisioning' is
> > >               advertised.
> > >
> > >               If the device allows arbitrarily named user-controlled
> > >               interfaces, the feature 'arbitrary-names' is advertised.
> > >
> > > Is this common practice to repeat this within a leaf, while the
> > > features are specified at the beginning of the YANG document.
> > > I could understand for the first entry because it makes the link with
> > > the previous paragraph, but the second comes out of the blue.
> > > I'm simply trying to understand what the conventions are.
> > 
> > There are no such conventions; we're just trying to make the
> > description text as clear as possible.  I think this helps in this
> > case, but if people think it makes the text confusing we can remove
> > it.
> > 
> 
> I'm a little concerned about the use of "arbitrary-names".
> You don't have any **useful** definition of what arbitrary means.

The feature is currently described like this:

      "This feature indicates that the device allows user-controlled            
       interfaces to be named arbitrarily.";

How about NEW:

      "This feature indicates that the device allows user-controlled            
       interfaces to be named arbitrarily by the client.";

(since it is 'user-controller', adding "by the client" is kind of
redundant, but might help to make it more clear).

> The definition of arbitrary names uses arbitrary in the definition
> (usually
> considered a bad thing).
> I think, but am not sure, that what you mean is that the "arbitrary"
> constraints on naming are implementation-specific.

No, it means that there are no constraints.  The client can put an
arbitrary name there.

> For reasons I mentioned above, I think "arbitrary constraints" are a
> bad
> thing.
> At a minimum, I think the document should standardize some constraints
> on
> the naming, even if those constraints are not DisplayString, otherwise
> it
> can be difficult for implementations to interoperate.



/martin

From evoit@cisco.com  Thu Dec  5 22:07:33 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017831AE2D5 for ; Thu,  5 Dec 2013 22:07:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0blEjfawown for ; Thu,  5 Dec 2013 22:07:29 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 62DCE1AE2C8 for ; Thu,  5 Dec 2013 22:07:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12159; q=dns/txt; s=iport; t=1386310046; x=1387519646; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1iK9BxdE+8Jim5t1gB4Ipc9xdUEZ057UnHqJ3KzOG5Y=; b=D4CBogdd9q1BWLP3mR7gsoagZ2AcXw6URnu0dMTkZR8d/3RW47ItqDRg NF1EGk7+TdGt4OYf2rPGzRWL3sNMDtSHxtnvsmo3lfgWYkDVZ3fop+IjA HCpgGl77lEAYb9lpPa6Z5g+jzeZur35agnMStOpgWtiHNHWE6/At0hdRX A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMHANZooVKtJXHB/2dsb2JhbABWA4JDRDhTsCKIA06BJBZ0gh4HAQEBBAEBASpBFwICAgEIDgIBAwECCx0HGwwLFAcBAQUDAgQBEgiFQQeCMg3BDRcEjksgAQwKAQYLgw+BEwOUMYUTkGODKYIq
X-IronPort-AV: E=Sophos;i="4.93,839,1378857600";  d="scan'208,217";a="289756507"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 06 Dec 2013 06:07:24 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rB667NpQ003384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Dec 2013 06:07:23 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.57]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 00:07:23 -0600
From: "Eric Voit (evoit)" 
To: Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] poll of interest on I-Ds submitted to the NETMOD WG
Thread-Index: AQHO8GpRG8ivdgBcrUeu+83UjMrorZpGrscA
Date: Fri, 6 Dec 2013 06:07:22 +0000
Message-ID: 
References: <20131120070012.GA44513@elstar.local> <529E45CA.1070503@cisco.com>
In-Reply-To: <529E45CA.1070503@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.142.105.132]
Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120110638xmbalnx11ciscoc_"
MIME-Version: 1.0
Subject: [netmod] FW:  poll of interest on I-Ds submitted to the NETMOD WG
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 06:07:33 -0000

--_000_EF64FF31F4C4384DBCE5D513A791C2B120110638xmbalnx11ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Here is my late input...    I support the work on


[4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt

[5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt

[6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt

Due to relevance to OpenDaylight and SDN.  I believe it useful to have a co=
nsistent namespace administrable across multiple network elements for certa=
in classes of use cases.

Efforts on [1], [2], and [3] appear interesting to me, but I haven't examin=
ed them enough  to have strong opinions.

Eric


-------- Original Message --------
Subject:

[netmod] poll of interest on I-Ds submitted to the NETMOD WG

Date:

Wed, 20 Nov 2013 08:00:12 +0100

From:

Juergen Schoenwaelder 

Reply-To:

Juergen Schoenwaelder 

To:





Hi,



at the last WG meeting in Vancouver, we did run out of time to discuss

what to do with the various individual I-Ds that have been submitted

to the NETMOD WG. So I like to poll for opinions on the list in order

to get a feeling where we are. In particular, I like to poll for

opinions on whether the following I-Ds should be worked on in an IETF

working group and how you see the priorities. In particular, it would

be nice to know who is willing to actively review documents and also

who is planning to implement the technology proposed in the various

I-Ds.



YANG Infrastructure:



[1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt

[2] http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-0=
0.txt

[3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt



Data Models:



[4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt

[5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt



Other Stuff:



[6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt



If I am missing an I-D that is mature enough to be included in this

list, please let me know.



/js



--

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





--_000_EF64FF31F4C4384DBCE5D513A791C2B120110638xmbalnx11ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Here is my late input&=
#8230;    I support the work on


 


[4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt

[5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-top=
o-01.txt


[6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt<=
/pre>

 


Due to relevance to Op=
enDaylight and SDN.  I believe it useful to have a consistent namespac=
e administrable across multiple network elements for certain classes of use=
 cases.


 


Efforts on [1], [2], a=
nd [3] appear interesting to me, but I haven’t examined them enough &=
nbsp;to have strong opinions.


 


Eric=







-------- Original Message -------- 








Subjec=
t: 




[netmod] poll of interest on I-Ds submitted to the N=
ETMOD WG








Date: =





Wed, 20 Nov 2013 08:00:12 +0100








From: =





Juergen Schoenwaelder 
<j.schoenwaelder@jacobs-university.de>








Reply-=
To: 




Juergen Schoenwaelder 
<j.schoenwaelder@jacobs-university.de>








To: 




<netmod@ietf.o=
rg>








 


Hi,


 


at the last WG meeting in Vancouver, we did run out of time to discuss=



what to do with the various individual I-Ds that have been submitted


to the NETMOD WG. So I like to poll for opinions on the list in order<=
o:p>


to get a feeling where we are. In particular, I like to poll for<=
/o:p>


opinions on whether the following I-Ds should be worked on in an IETF<=
o:p>


working group and how you see the priorities. In particular, it would<=
o:p>


be nice to know who is willing to actively review documents and also


who is planning to implement the technology proposed in the various


I-Ds.


 


YANG Infrastructure:


 


[1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conforma=
nce-01.txt


[2] http://tools.ietf.org/id/draft-bjorklund-netmod-yang=
-xpath-extensions-00.txt


[3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt


 


Data Models:


 


[4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt

[5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-top=
o-01.txt


 


Other Stuff:


 


[6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt<=
/pre>

 


If I am missing an I-D that is mature enough to be included in this


list, please let me know.


 


/js


 


-- 


Juergen Schoenwaelder        &=
nbsp;  Jacobs University Bremen gGmbH


Phone: +49 421 200 3587       &=
nbsp; Campus Ring 1, 28759 Bremen, Germany


Fax:   +49 421 200 3103     &nb=
sp;   <http://www=
.jacobs-university.de/>


_______________________________________________


netmod mailing list


netmod@ietf.org

https://www.i=
etf.org/mailman/listinfo/netmod


 


 


 






--_000_EF64FF31F4C4384DBCE5D513A791C2B120110638xmbalnx11ciscoc_--

From bclaise@cisco.com  Fri Dec  6 01:31:32 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110F01AE2D0 for ; Fri,  6 Dec 2013 01:31:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUVYGQGscnBR for ; Fri,  6 Dec 2013 01:31:29 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 026F31AD9AC for ; Fri,  6 Dec 2013 01:31:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8180; q=dns/txt; s=iport; t=1386322285; x=1387531885; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IogvdB+sqGTzbTe5zxWp7aYs1D7J3ZCLEqWn+nv5mo0=; b=aX828BL/WSPEsIiRydektsOR2ZT5fc7sW1J+eaFgVu9p92xMso1gJ1NL iJSLZ+GbsBrKcx5eLJx1KxY12xoCpvunVQjg0+vxD1ky7FKfMV1guwaKa zWnaj5PI+lX4o/yltZpsAki2tG0w8UB1xzd04B7pMYNBju650Wvk8BQHO M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai0FACaZoVKQ/khM/2dsb2JhbABZgwc4uUyBJBZ0giUBAQEEOEABEAsOCgkWDwkDAgECAUUGDQEFAgEBh34NwHYXjh4RAVAHhDMDmBSBMIUVi06DKjuBNQ
X-IronPort-AV: E=Sophos;i="4.93,839,1378857600";  d="scan'208";a="1165193"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 06 Dec 2013 09:31:22 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB69VIHn025246; Fri, 6 Dec 2013 09:31:18 GMT
Message-ID: <52A19966.3020903@cisco.com>
Date: Fri, 06 Dec 2013 10:31:18 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Martin Bjorklund 
References: <529E61CC.1070202@cisco.com>	<529F5B4E.70406@cisco.com> <20131205.123210.2269861100175493083.mbj@tail-f.com>
In-Reply-To: <20131205.123210.2269861100175493083.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] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 09:31:32 -0000

Hi Martin,

Here are some answers.
I removed some points on which we agree. And I left some others, to be 
answered with the latest email.
> Hi Benoit,
>
> Benoit Claise  wrote:
>> Dear all,
>>
>> This draft came a long way since my previous AD review some months
>> ago. Thanks.
>>
>> -
>>
>>     If the device supports arbitrarily named user-controlled interfaces,
>>     the NETCONF server advertises the feature "arbitrary-names".  If the
>>     device does not advertise this feature, the names of user-controlled
>>     interfaces MUST match the device's naming scheme.  How a client can
>>     learn the naming scheme of such devices is outside the scope of this
>>     document.
>>
>> I had to look in the appendix to understand this concept:
>>       E.1
>>       .
>>       Router with Restricted Interface Names . . . . . . . . . .38
>>       
>>       E.2
>>       .
>>       Router with Arbitrary Interface Names . . . . . . . . . .39
>>       
>> (and it does make sense after reading the appendices)
>>
>> You should explain with an example:
>>     E1: The name of a vlan interface is restricted to the form
>>     ".".
>>
>> 	versus
>>
>>     E2: The implementation does not restrict the user-controlled interface
>>     names.
>>
>> And refer the appendices for the examples.	
>>     For a more complete example, seeAppendix E.2
>>     .
>>
>>
> Proposal:
>
> OLD:
>
>     interfaces MUST match the device's naming scheme.  How a client can
>     learn the naming scheme of such devices is outside the scope of this
>     document.
>
> NEW:
>
>     interfaces MUST match the device's naming scheme.  How a client can
>     learn the naming scheme of such devices is outside the scope of this
>     document.  See Appendix E.1 and Appendix E.2 for examples.
ok
>
>
>> -
>> OLD:
>>     In most cases, the "name" of an "interface" entry is mapped to
>>     ifName. ifName is defined as an DisplayString [RFC2579
>>     ] which uses a
>>     7-bit ASCII character set.  An implementation MUST restrict the
>>     allowed values for "name" to match the restrictions of ifName.
>> NEW:
>>     In most cases, the "name" of an "interface" entry is mapped to
>>     ifName. ifName is defined as an DisplayString [RFC2579
>>     ] which uses a
>>     7-bit ASCII character set.  If the device implements IF-MIB [RFC2863
>>     ],
>>     and the mapping is supported, an implementation MUST restrict the
>>     allowed
>>     values for "name" to match the restrictions of ifName.
>>
>> However, I see later on:
>>                When a configured user-controlled interface is created by
>>                the system, it is instantiated with the same name in the
>>                /interface-state/interface list.  Since the name in that
>>                list MAY be mapped to ifName by an implementation, such an
>>                implementation MUST restrict the allowed values for this
>>                leaf so that it matches the restrictions of ifName.
>> So it seems that my "NEW" is wrong.
>> NEW NEW:
>>     In most cases, the "name" of an "interface" entry is mapped to
>>     ifName. ifName is defined as an DisplayString [RFC2579
>>     ] which uses a
>>     7-bit ASCII character set.  Since the "name" MAY be mapped to ifName
>>     [RFC2863 ],
>>     an implementation MUST restrict the allowed values for "name" to match
>>     the restrictions of ifName.
>>
>>
>
> Proposal:
>
> OLD:
>
>     In most cases, the "name" of an "interface" entry is mapped to
>     ifName. ifName is defined as an DisplayString [RFC2579] which uses
>     a 7-bit ASCII character set.  An implementation MUST restrict the
>     allowed values for "name" to match the restrictions of ifName.
>
> NEW:
>
>     In most cases, the "name" of an "interface" entry is mapped to
>     ifName. ifName is defined as an DisplayString [RFC2579] which uses a
>     7-bit ASCII character set.  An implementation that performs this
>     mapping MUST restrict the allowed values for "name" to match the
>     restrictions of ifName.
ok
>
>
>> -
>>    There are a number of counters in the IF-MIB that exist in two
>>     versions; one with 32 bits and one with 64 bits.  The YANG module
>>     contains the 64 bits counters only.
>>
>> NEW:
>>     There are a number of counters in the IF-MIB that exist in two
>>     versions; one with 32 bits and one with 64 bits.  Amongst those, the
>>     YANG module
>>     contains the 64 bits counters only.
> Ok.
>
>
> -
> I wondered about the correlation between the entries in /interface/
> and /interfaces-state/ ?
> In the section 3.1, an extra paragraph would help, explaining the
> correlation of entries in/interfaces/ and/interfaces-state/
> * In the normal case, ie, if all interfaces are configured, entries in/
> * //interface/ = entries in/interfaces-state/
> * On top of that, if some interfaces are pre-provisioned, extra entries
> * will appear in the/interfaces/
> * However, it could also happen that not all interfaces are configured:
>    in this case, all existing interfaces would appear in/
>    //interfaces-state/ while only the configured ones appear
>    in/interface/
>
You don't consider this one above as a useful piece of information for 
the draft?
>
>> -
>> Looking (only) at the figure at the beginning of section 3:
>>    +--ro interfaces-state
>>           +--ro interface* [name]
>>              +--ro higher-layer-if*   interface-state-ref
>>              +--ro lower-layer-if*    interface-state-ref
>>
>> I wondered if I could have interface layering for pre-provisioned
>> interfaces (like a VLAN on soon-to-inserted line card).
>> My first reaction was no, because I could not see under /interfaces/ :
>>              +--ro higher-layer-if*   interface-ref
>>              +--ro lower-layer-if*    interface-ref
>>
>> However, it's possible. While all the text is there in section 3.3, it
>> might be stressed that two different mechanisms are used.
>> OLD:
>>
>>     Two state data leaf-lists, "higher-layer-if" and "lower-layer-if",
>>     represent a read-only view of the interface layering hierarchy.
>>
>> NEW:
>>
>>     While the layering mechanism is configured with a new type
>>     (identityref), two state data leaf-lists, "higher-layer-if"
>>     and "lower-layer-if", represent a read-only view of the interface
>>     layering hierarchy (interface-state-ref).
>>
>> Note: I trust you on the English and correctness.
>>
> Proposal:
>
> NEW:
>
>    While the interface layering is configured in type specific models,
>    two generic state data leaf-lists, "higher-layer-if" and
>    "lower-layer-if", represent a read-only view of the interface
>    layering hierarchy.
ok
>
>
>>     -      feature pre-provisioning {
>>         description
>>           "This feature indicates that the device supports
>>            pre-provisioning of interface configuration, i.e., it is
>>            possible to configure an interface whose physical interface
>>            hardware is not present on the device.";
>>
>> I wondered whether an OIR (Online Insertion and Removal) feature
>> should advertise this pre-provisioning feature?
>> I guess it depends whether the configuration is kept and visible or
>> not.
>> Anyway, I don't want to delay this document any further.
>> So maybe something to consider in the future, potentially with a new
>> OIR feature.
> Ok.
Regards, Benoit

From bclaise@cisco.com  Fri Dec  6 01:32:41 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301181AD9AC for ; Fri,  6 Dec 2013 01:32:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLuYOsvRWYAC for ; Fri,  6 Dec 2013 01:32:38 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id DD5DB1AD7C2 for ; Fri,  6 Dec 2013 01:32:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9478; q=dns/txt; s=iport; t=1386322354; x=1387531954; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=aQVuRzrS8RZfJi33gPJcCTO6IS0vbpSLl950yWuOVxY=; b=WYK963H96Jkaa30qf2fC9HaLTQ8oTAPqn1/PgMinM0I/kvatNvLl5Rp9 yPY+BLjjyZoIARte9msFROfqJBdAz1YYbXvl9t9Xi+b1fch6cSQj5j5lb P3DMYa0XCS8nkNEobSW8CJ4NxMCiDfdNtoLxvMdjuWBKp6i3sUFimugrt s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiwFACaZoVKQ/khM/2dsb2JhbABPBwODB7oEgSQWdIIlAQEBAwE4QAEQCw4KCRYPCQMCAQIBRQYBDAEFAgEBh2wDCQa5XAiHHxeOJEwQBxGEIgOYFIZFi06DKjs
X-IronPort-AV: E=Sophos;i="4.93,839,1378857600";  d="scan'208";a="1165240"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 06 Dec 2013 09:32:33 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB69WTMH025538; Fri, 6 Dec 2013 09:32:29 GMT
Message-ID: <52A199AD.3060409@cisco.com>
Date: Fri, 06 Dec 2013 10:32:29 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Martin Bjorklund , ietfdbh@comcast.net
References: <529F5B4E.70406@cisco.com>	<20131205.123210.2269861100175493083.mbj@tail-f.com>	<029401cef1db$1ab5ffb0$5021ff10$@comcast.net> <20131205.220552.467577048.mbj@tail-f.com>
In-Reply-To: <20131205.220552.467577048.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] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 09:32:41 -0000

On 5/12/2013 22:05, Martin Bjorklund wrote:
> Hi David,
>
> "ietfdbh"  wrote:
>> Comments inline
>>
>> David Harrington
>> ietfdbh@comcast.net
>> +1-603-828-1401
>>
>>> Proposal:
>>>
>>> OLD:
>>>
>>>      The data model includes configuration data, state data and counters
>>>      for the collection of statistics.
>>>
>>> NEW:
>>>
>>>      The data model includes configuration data, status information and
>>>      counters for the collection of statistics.
>>>
>>> (in the Abstract and Introduction).
>> Why not simply:
>>       The data model includes configuration data and state data.
> Ok, that's better.
I would go for
     The data model includes configuration data and state data (status 
information and counters)

People will get this key message without the need to look up the "state 
data" definition in the other RFC.

>
>> Let me ask a question. The WG has decided that config data and state
>> data
>> should be in separate trees.
>> If there is config data + status information + counters, does that
>> imply a
>> separate tree for the counters? If so, why?
>>
>> There has been some discussion that, if state data was mixed with
>> config
>> data in the same tree, that the volatility of counters would make it
>> harder
>> to query for changes to config data.
> In this particular case this was not the reason for the separation.
> (the reason for separation was that the configured interfaces and the
> interfaces actually in use on the device are really separate entities).
>
>> Would this also be true of status
>> information? If so, then maybe a separate tree for counters would make
>> sense. When I worked on NMS code, we frequently queried the counters,
>> but
>> less frequently needed to check for changes to config or status
>> information,
>> and while LastChanged objects were helpful to drive when config/status
>> information needed to be updated on the NMS-side, LastChanged objects
>> simply
>> wouldn't work for most counters.
> Agreed.
>
>>> Proposal:
>>>
>>> OLD:
>>>
>>>     In most cases, the "name" of an "interface" entry is mapped to
>>>     ifName. ifName is defined as an DisplayString [RFC2579] which uses
>>>     a 7-bit ASCII character set.  An implementation MUST restrict the
>>>     allowed values for "name" to match the restrictions of ifName.
>>>
>>> NEW:
>>>
>>>     In most cases, the "name" of an "interface" entry is mapped to
>>>     ifName. ifName is defined as an DisplayString [RFC2579] which uses a
>>>     7-bit ASCII character set.  An implementation that performs this
>>>     mapping MUST restrict the allowed values for "name" to match the
>>>     restrictions of ifName.
>>>
>> How about:
>>> NEW NEW NEW ;-):
>>>
>>      In most cases, the "name" of an "interface" entry is mapped to
>>      ifName. ifName is defined as a DisplayString [RFC2579] which uses
>>      a 7-bit ASCII character set.  For interoperability reasons, an
>> implementation MUST restrict the
>>      allowed values for "name" to match the restrictions of ifName.
>>
>> I recommend you REQUIRE DisplayString syntax, to ensure
>> interoperability
>> between clients and servers.
> Agreed.  That's what we have both in the current text, and in the
> proposed clarified text.  I.e., if you map to ifName, then you MUST
> match its restrictions.
>
>> If this is left as an implementation choice, then you probably should
>> identify the different requirements for servers and clients.
>> If servers are allowed to implement using non-DisplayString semantics,
>> the
>> standard should place some restrictions on what is allowed, so client
>> implementers know what they need to accommodate.
>>
>> Can a server choose to implement using an 8-bit or 16-bit character
>> set? How
>> should a client determine that this is the case?
>> Can a server choose to ignore the special meanings of NUL, LF, CR,
>> BEL, BS,
>> HT, VT and FF? If an NMS expects servers to abide by those special
>> meanings,
>> it could misinterpret data, and mislead operators.
>> Can a server choose to implement names that exceed 255 characters? If
>> so,
>> what is an NMS that allocates a 255-character buffer REQUIRED to do
>> with the
>> excess? Throw it away and ignore it? How should subsequent matching
>> algorithms deal with that truncation?
>> If a server implements names > 255, MUST/SHOULD/MAY a client
>> dynamically
>> allocate larger buffers to accommodate whatever size a server chooses
>> to
>> send? How should the NMS know how big a buffer is needed, if the
>> delimiters
>> of the name are implementation-specific?
>>
>> These questions of interoperability are important whether the server
>> implements IF-MIB or not.
>> The processing would be much less complex, and more interoperable, if
>> implementations were **standardized** to use consistent size and
>> character
>> set constraints, regardless of the presence of IF-MIB.
> The leaf "name" is of type string.  So whatever is a valid string is
> acceptable.  See RFC 6020 for a definition of valid strings.
>
>>>> -
>>>>    There are a number of counters in the IF-MIB that exist in two
>>>>     versions; one with 32 bits and one with 64 bits.  The YANG module
>>>>     contains the 64 bits counters only.
>>>>
>>>> NEW:
>>>>     There are a number of counters in the IF-MIB that exist in two
>>>>     versions; one with 32 bits and one with 64 bits.  Amongst those, the
>>>>     YANG module
>>>>     contains the 64 bits counters only.
>> It might be helpful to explain why:
>> NEW:
>> There are a number of counters in the IF-MIB that are duplicated in
>> two
>> versions; Counter32s, for backwards compatibility with SNMPv1, and
>> Counter64s, to support high capacity devices.
>> Since SNMPv1 has been declared Historic, the YANG module
>> contains only the 64 bit counters.
> Ok, make sense.
yes, even better
>
>>> Adding the prefix to all of them makes the table look bad (too long
>>> rows...)  I propose that we add the prefix in all cases where there's
>>> a conflict, but do not use the prefix where there is no conflict.
>>> Specifically, this means that the "type" node gets a prefix:
>>>
>>> Proposal:
>>>
>>> OLD:
>>>
>>>         | /interfaces-state/interface      | ifEntry                |
>>>         | /interfaces-state/name           | ifName                 |
>>>         | description                      | ifAlias                |
>>>         | type                             | ifType                 |
>>>
>>> NEW:
>>>
>>>         | /interfaces-state/interface      | ifEntry                |
>>>         | /interfaces-state/name           | ifName                 |
>>>         | description                      | ifAlias                |
>>>         | /interfaces-state/type           | ifType                 |
>>>
>> I think it is less ambiguous to include the prefix consistently.
> What is the ambiguity?
As Dave, I have a small preference for the consistent addition of prefix.
>
>> In a standard, avoiding ambiguity is more important than avoiding
>> looking
>> bad (long rows).
> I certainly agree.
>
>>>> -
>>>>                If the device supports pre-provisioning of interface
>>>>                configuration, the feature 'pre-provisioning' is
>>>>                advertised.
>>>>
>>>>                If the device allows arbitrarily named user-controlled
>>>>                interfaces, the feature 'arbitrary-names' is advertised.
>>>>
>>>> Is this common practice to repeat this within a leaf, while the
>>>> features are specified at the beginning of the YANG document.
>>>> I could understand for the first entry because it makes the link with
>>>> the previous paragraph, but the second comes out of the blue.
>>>> I'm simply trying to understand what the conventions are.
>>> There are no such conventions; we're just trying to make the
>>> description text as clear as possible.  I think this helps in this
>>> case, but if people think it makes the text confusing we can remove
>>> it.
>>>
>> I'm a little concerned about the use of "arbitrary-names".
>> You don't have any **useful** definition of what arbitrary means.
> The feature is currently described like this:
>
>        "This feature indicates that the device allows user-controlled
>         interfaces to be named arbitrarily.";
>
> How about NEW:
>
>        "This feature indicates that the device allows user-controlled
>         interfaces to be named arbitrarily by the client.";
>
> (since it is 'user-controller', adding "by the client" is kind of
> redundant, but might help to make it more clear).
If it helps, fine.
>
>> The definition of arbitrary names uses arbitrary in the definition
>> (usually
>> considered a bad thing).
>> I think, but am not sure, that what you mean is that the "arbitrary"
>> constraints on naming are implementation-specific.
> No, it means that there are no constraints.  The client can put an
> arbitrary name there.
>
>> For reasons I mentioned above, I think "arbitrary constraints" are a
>> bad
>> thing.
>> At a minimum, I think the document should standardize some constraints
>> on
>> the naming, even if those constraints are not DisplayString, otherwise
>> it
>> can be difficult for implementations to interoperate.
>
>
> /martin
> .
>
Thanks and regards, Benoit

From jonathan@hansfords.net  Fri Dec  6 02:26:05 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774AF1AE307 for ; Fri,  6 Dec 2013 02:26:05 -0800 (PST)
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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyTbHZARCZPv for ; Fri,  6 Dec 2013 02:26:01 -0800 (PST)
Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) by ietfa.amsl.com (Postfix) with ESMTP id 84EEE1AE323 for ; Fri,  6 Dec 2013 02:26:00 -0800 (PST)
Received: from [192.168.1.100] ([84.92.149.4]) by avasout01 with smtp id yARt1m00305w0Nk01ARus5; Fri, 06 Dec 2013 10:25:56 +0000
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=IvYnLtPg c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=crK2bTrhSLoA:10 a=m-qb6kl8J2YA:10 a=0B8HqoTn75oA:10 a=8nJEP1OIZ-IA:10 a=6bkCdLdQAAAA:8 a=GWxWy9ZvW1UA:10 a=C_IRinGWAAAA:8 a=48vgC7mUAAAA:8 a=qliFNMQ4UyEo5dRIMOoA:9 a=7lzrWKJBflLqdrCY:21 a=pfOOCXsIdDc73VQI:21 a=wPNLvfGTeEIA:10 a=oSt6Lz0FISYA:10 a=si9q_4b84H0A:10 a=lZB815dzVvQA:10
Message-ID: <52A1A632.5020102@hansfords.net>
Date: Fri, 06 Dec 2013 10:25:54 +0000
From: Jonathan Hansford 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Benoit Claise , Martin Bjorklund ,  ietfdbh@comcast.net
References: <529F5B4E.70406@cisco.com>	<20131205.123210.2269861100175493083.mbj@tail-f.com>	<029401cef1db$1ab5ffb0$5021ff10$@comcast.net> <20131205.220552.467577048.mbj@tail-f.com> <52A199AD.3060409@cisco.com>
In-Reply-To: <52A199AD.3060409@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 10:26:05 -0000

On 06/12/2013 09:32, Benoit Claise wrote:
> On 5/12/2013 22:05, Martin Bjorklund wrote:
>> Hi David,
>>
>> "ietfdbh"  wrote:
>>> Comments inline
>>>
>>> David Harrington
>>> ietfdbh@comcast.net
>>> +1-603-828-1401
>>>
>>>> Proposal:
>>>>
>>>> OLD:
>>>>
>>>>      The data model includes configuration data, state data and 
>>>> counters
>>>>      for the collection of statistics.
>>>>
>>>> NEW:
>>>>
>>>>      The data model includes configuration data, status information 
>>>> and
>>>>      counters for the collection of statistics.
>>>>
>>>> (in the Abstract and Introduction).
>>> Why not simply:
>>>       The data model includes configuration data and state data.
>> Ok, that's better.
> I would go for
>     The data model includes configuration data and state data (status 
> information and counters)
>
> People will get this key message without the need to look up the 
> "state data" definition in the other RFC.

+1

>
>>
>>> Let me ask a question. The WG has decided that config data and state
>>> data
>>> should be in separate trees.
>>> If there is config data + status information + counters, does that
>>> imply a
>>> separate tree for the counters? If so, why?
>>>
>>> There has been some discussion that, if state data was mixed with
>>> config
>>> data in the same tree, that the volatility of counters would make it
>>> harder
>>> to query for changes to config data.
>> In this particular case this was not the reason for the separation.
>> (the reason for separation was that the configured interfaces and the
>> interfaces actually in use on the device are really separate entities).
>>
>>> Would this also be true of status
>>> information? If so, then maybe a separate tree for counters would make
>>> sense. When I worked on NMS code, we frequently queried the counters,
>>> but
>>> less frequently needed to check for changes to config or status
>>> information,
>>> and while LastChanged objects were helpful to drive when config/status
>>> information needed to be updated on the NMS-side, LastChanged objects
>>> simply
>>> wouldn't work for most counters.
>> Agreed.
>>
>>>> Proposal:
>>>>
>>>> OLD:
>>>>
>>>>     In most cases, the "name" of an "interface" entry is mapped to
>>>>     ifName. ifName is defined as an DisplayString [RFC2579] which uses
>>>>     a 7-bit ASCII character set.  An implementation MUST restrict the
>>>>     allowed values for "name" to match the restrictions of ifName.
>>>>
>>>> NEW:
>>>>
>>>>     In most cases, the "name" of an "interface" entry is mapped to
>>>>     ifName. ifName is defined as an DisplayString [RFC2579] which 
>>>> uses a
>>>>     7-bit ASCII character set.  An implementation that performs this
>>>>     mapping MUST restrict the allowed values for "name" to match the
>>>>     restrictions of ifName.
>>>>
>>> How about:
>>>> NEW NEW NEW ;-):
>>>>
>>>      In most cases, the "name" of an "interface" entry is mapped to
>>>      ifName. ifName is defined as a DisplayString [RFC2579] which uses
>>>      a 7-bit ASCII character set.  For interoperability reasons, an
>>> implementation MUST restrict the
>>>      allowed values for "name" to match the restrictions of ifName.
>>>
>>> I recommend you REQUIRE DisplayString syntax, to ensure
>>> interoperability
>>> between clients and servers.
>> Agreed.  That's what we have both in the current text, and in the
>> proposed clarified text.  I.e., if you map to ifName, then you MUST
>> match its restrictions.
>>
>>> If this is left as an implementation choice, then you probably should
>>> identify the different requirements for servers and clients.
>>> If servers are allowed to implement using non-DisplayString semantics,
>>> the
>>> standard should place some restrictions on what is allowed, so client
>>> implementers know what they need to accommodate.
>>>
>>> Can a server choose to implement using an 8-bit or 16-bit character
>>> set? How
>>> should a client determine that this is the case?
>>> Can a server choose to ignore the special meanings of NUL, LF, CR,
>>> BEL, BS,
>>> HT, VT and FF? If an NMS expects servers to abide by those special
>>> meanings,
>>> it could misinterpret data, and mislead operators.
>>> Can a server choose to implement names that exceed 255 characters? If
>>> so,
>>> what is an NMS that allocates a 255-character buffer REQUIRED to do
>>> with the
>>> excess? Throw it away and ignore it? How should subsequent matching
>>> algorithms deal with that truncation?
>>> If a server implements names > 255, MUST/SHOULD/MAY a client
>>> dynamically
>>> allocate larger buffers to accommodate whatever size a server chooses
>>> to
>>> send? How should the NMS know how big a buffer is needed, if the
>>> delimiters
>>> of the name are implementation-specific?
>>>
>>> These questions of interoperability are important whether the server
>>> implements IF-MIB or not.
>>> The processing would be much less complex, and more interoperable, if
>>> implementations were **standardized** to use consistent size and
>>> character
>>> set constraints, regardless of the presence of IF-MIB.
>> The leaf "name" is of type string.  So whatever is a valid string is
>> acceptable.  See RFC 6020 for a definition of valid strings.
>>
>>>>> -
>>>>>    There are a number of counters in the IF-MIB that exist in two
>>>>>     versions; one with 32 bits and one with 64 bits.  The YANG module
>>>>>     contains the 64 bits counters only.
>>>>>
>>>>> NEW:
>>>>>     There are a number of counters in the IF-MIB that exist in two
>>>>>     versions; one with 32 bits and one with 64 bits. Amongst 
>>>>> those, the
>>>>>     YANG module
>>>>>     contains the 64 bits counters only.
>>> It might be helpful to explain why:
>>> NEW:
>>> There are a number of counters in the IF-MIB that are duplicated in
>>> two
>>> versions; Counter32s, for backwards compatibility with SNMPv1, and
>>> Counter64s, to support high capacity devices.
>>> Since SNMPv1 has been declared Historic, the YANG module
>>> contains only the 64 bit counters.
>> Ok, make sense.
> yes, even better
>>
>>>> Adding the prefix to all of them makes the table look bad (too long
>>>> rows...)  I propose that we add the prefix in all cases where there's
>>>> a conflict, but do not use the prefix where there is no conflict.
>>>> Specifically, this means that the "type" node gets a prefix:
>>>>
>>>> Proposal:
>>>>
>>>> OLD:
>>>>
>>>>         | /interfaces-state/interface      | ifEntry                |
>>>>         | /interfaces-state/name           | ifName                 |
>>>>         | description                      | ifAlias                |
>>>>         | type                             | ifType                 |
>>>>
>>>> NEW:
>>>>
>>>>         | /interfaces-state/interface      | ifEntry                |
>>>>         | /interfaces-state/name           | ifName                 |
>>>>         | description                      | ifAlias                |
>>>>         | /interfaces-state/type           | ifType                 |
>>>>
>>> I think it is less ambiguous to include the prefix consistently.
>> What is the ambiguity?
> As Dave, I have a small preference for the consistent addition of prefix.

+1

>>
>>> In a standard, avoiding ambiguity is more important than avoiding
>>> looking
>>> bad (long rows).
>> I certainly agree.
>>
>>>>> -
>>>>>                If the device supports pre-provisioning of interface
>>>>>                configuration, the feature 'pre-provisioning' is
>>>>>                advertised.
>>>>>
>>>>>                If the device allows arbitrarily named user-controlled
>>>>>                interfaces, the feature 'arbitrary-names' is 
>>>>> advertised.
>>>>>
>>>>> Is this common practice to repeat this within a leaf, while the
>>>>> features are specified at the beginning of the YANG document.
>>>>> I could understand for the first entry because it makes the link with
>>>>> the previous paragraph, but the second comes out of the blue.
>>>>> I'm simply trying to understand what the conventions are.
>>>> There are no such conventions; we're just trying to make the
>>>> description text as clear as possible.  I think this helps in this
>>>> case, but if people think it makes the text confusing we can remove
>>>> it.
>>>>
>>> I'm a little concerned about the use of "arbitrary-names".
>>> You don't have any **useful** definition of what arbitrary means.
>> The feature is currently described like this:
>>
>>        "This feature indicates that the device allows user-controlled
>>         interfaces to be named arbitrarily.";
>>
>> How about NEW:
>>
>>        "This feature indicates that the device allows user-controlled
>>         interfaces to be named arbitrarily by the client.";
>>
>> (since it is 'user-controller', adding "by the client" is kind of
>> redundant, but might help to make it more clear).
> If it helps, fine.
>>
>>> The definition of arbitrary names uses arbitrary in the definition
>>> (usually
>>> considered a bad thing).
>>> I think, but am not sure, that what you mean is that the "arbitrary"
>>> constraints on naming are implementation-specific.
>> No, it means that there are no constraints.  The client can put an
>> arbitrary name there.
>>
>>> For reasons I mentioned above, I think "arbitrary constraints" are a
>>> bad
>>> thing.
>>> At a minimum, I think the document should standardize some constraints
>>> on
>>> the naming, even if those constraints are not DisplayString, otherwise
>>> it
>>> can be difficult for implementations to interoperate.
>>
>>
>> /martin
>> .
>>
> Thanks and regards, Benoit
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From j.schoenwaelder@jacobs-university.de  Fri Dec  6 02:36:49 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508681ADBCB for ; Fri,  6 Dec 2013 02:36:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urUINSPyO744 for ; Fri,  6 Dec 2013 02:36: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 CB3F61AD694 for ; Fri,  6 Dec 2013 02:36:46 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C24BC2002F; Fri,  6 Dec 2013 11:36:42 +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 pbyEY5QuEdi9; Fri,  6 Dec 2013 11:36:42 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AA8B200B0; Fri,  6 Dec 2013 11:36:42 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id DDD6629E5134; Fri,  6 Dec 2013 11:36:36 +0100 (CET)
Date: Fri, 6 Dec 2013 11:36:36 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20131206103635.GA35073@elstar.local>
Mail-Followup-To: Martin Bjorklund , ietfdbh@comcast.net, netmod@ietf.org
References: <529F5B4E.70406@cisco.com> <20131205.123210.2269861100175493083.mbj@tail-f.com> <029401cef1db$1ab5ffb0$5021ff10$@comcast.net> <20131205.220552.467577048.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131205.220552.467577048.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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 Dec 2013 10:36:49 -0000

On Thu, Dec 05, 2013 at 10:05:52PM +0100, Martin Bjorklund wrote:

> > It might be helpful to explain why:
> > NEW:
> > There are a number of counters in the IF-MIB that are duplicated in
> > two
> > versions; Counter32s, for backwards compatibility with SNMPv1, and
> > Counter64s, to support high capacity devices.  
> > Since SNMPv1 has been declared Historic, the YANG module
> > contains only the 64 bit counters.
> 
> Ok, make sense.

I am not sure this design decision had something to do with SNMPv1
officially been labeled Historic by the IETF.

As far as I recall, when the WG discussed this, the point was made
that today's implementations (~20 years after the introduction of
64-bit counters in RFC 1573) generally support 64-bit counters and
NETCONF does fine shipping 64-bit counters - so there is no need to
have additional 32-bit counters.  Perhaps instead of discussing SNMP's
history, we should write down why those counters are 64-bit only:

NEW:

  To support high-speed interfaces with a data rate greater than
  20,000,000 bits/second, RFC 1573 (published in 1994) added 64-bit
  counters to the IF-MIB. Today's implementations generally support
  such high-speed interfaces and hence only 64-bit counters are
  provided in this data model.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From bclaise@cisco.com  Fri Dec  6 02:54:52 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238671AE331 for ; Fri,  6 Dec 2013 02:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.501
X-Spam-Level: 
X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge8aCE4n6ZiA for ; Fri,  6 Dec 2013 02:54:49 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 09F061AD9AD for ; Fri,  6 Dec 2013 02:54:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7776; q=dns/txt; s=iport; t=1386327285; x=1387536885; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=v7LJ+Vxfai9qeEZUlTbufN/aMBqAcDpQYigjt1mw5F8=; b=ZWn3ZfqqGfNYTscU2nT2fazFGTvqLQ46gH3Vebzuz7JzhQ59v/DNmQ5v occxaQtmyCnOhfbu5r0ruTRuieo3f0YZwIUgsu3WGMIBVXer5Q5s0DRY6 BJA0TmKlnsXAUbVSsO/O3RSYMrigxzyiU8jENwckEPNEdpkOyWFCjG1i5 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiwFAECsoVKQ/khM/2dsb2JhbABZgwe6B4EkFnSCJQEBAQRuCgEMBBwDAQIBCRYECwkDAgECATQHAggGDQEFAgEBh37BBxeObxEHBoQtA4xZh1iDY4ZFe4pTgWuBPzs
X-IronPort-AV: E=Sophos;i="4.93,840,1378857600"; d="scan'208,217";a="1778248"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 06 Dec 2013 10:54:44 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB6Asd4b018920; Fri, 6 Dec 2013 10:54:40 GMT
Message-ID: <52A1ACEF.6080307@cisco.com>
Date: Fri, 06 Dec 2013 11:54:39 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: NETMOD Working Group 
References: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net>
In-Reply-To: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net>
X-Forwarded-Message-Id: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net>
Content-Type: multipart/alternative; boundary="------------010107060409060702080209"
Cc: SM 
Subject: [netmod] Fwd: Re: Last Call:  (IANA Timezone Database YANG Module) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 10:54:52 -0000

This is a multi-part message in MIME format.
--------------010107060409060702080209
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Here is some feedback from the IETF discussion list.
I would appreciate if the author and document shepherd could follow up. 
Ideally on the IETF discussion list.

Regards, Benoit


-------- Original Message --------
Subject: 	Re: Last Call:  (IANA 
Timezone Database YANG Module) to Proposed Standard
Date: 	Tue, 3 Dec 2013 19:36:31 -0800
From: 	SM 
To: 	



At 12:46 03-12-2013, The IESG wrote:
>The IESG has received a request from the NETCONF Data Modeling Language
>WG (netmod) to consider the following document:
>- 'IANA Timezone Database YANG Module'
>    as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>ietf@ietf.org mailing lists by 2013-12-17. Exceptionally, comments may be

There is the following question in the document shepherd write-up:

   Why is this the proper type of RFC?

I did not see an answer to that question.

The WGLC was from 5 July to 22 July.  There wasn't any comments
during the WGLC.  The only comment I found was one posted on 9 August.

In Section 1:

   "The iana-timezones YANG module defines the iana-
    timezone type, which is a serialization of the existing IANA Time
    Zone registry [RFC6557] into YANG format."

The terminology in RFC 6557 defines a TZ Database sometimes referred
to as the "Olson Database".  There isn't any mention of a "IANA Time
Zone registry".  I suggest using the same name as in RFC 6557.

 From Section 3:

   'The iana-timezones module is intended to reflect the IANA "timezone
    database" [RFC6557].  When a timezone location is added to the
    database, the "iana-timezone" enumeration MUST be updated as defined
    in RFC 6020 Section 10 to add the newly created timezone location to
    the enumeration.  The new "enum" statement MUST be added to the
    "iana-timezone" typedef with the same name as the newly added
    timezone location.  A new enum value MUST be allocated by IANA and
    applied to the newly created enum entry.  New entries MAY be placed
    in any order in the enumeration as long as the previously assigned
    enumeration values are not changed.

    If a timezone location is removed from the IANA timezone database,
    the corresponding existing enum statement is kept and a status
    statement is added to mark the enum entry as 'obsolete'.'

The maintainer of the TZ database is responsible for the TZ
Database.  The person does not work for IANA.  I don't think that
IANA keeps track of the contents of the TZ Database as it was not
asked to do that work.  I don't see the value of using RFC 2119 key
word for the IANA Considerations.

I suggest not creating the registry proposed in this draft.  The TZ
database has strived to keep out of political issues.  Adding such a
registry will pave the way for such issues.

Regards,
-sm

.




--------------010107060409060702080209
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    Here is some feedback from the IETF discussion list.

    I would appreciate if the author and document shepherd could follow
    up. Ideally on the IETF discussion list.

    

    Regards, Benoit

    


      

      -------- Original Message --------
      

        
          

            Subject:
            
            Re: Last Call:
              <draft-ietf-netmod-iana-timezones-03.txt> (IANA
              Timezone Database YANG Module) to Proposed Standard
          

          

            Date: 
            Tue, 3 Dec 2013 19:36:31 -0800
          

          

            From: 
            SM <sm@resistor.net>
          

          

            To: 
            <ietf@ietf.org>
          

        
      

      

      

      
At 12:46 03-12-2013, The IESG wrote:
>The IESG has received a request from the NETCONF Data Modeling Language
>WG (netmod) to consider the following document:
>- 'IANA Timezone Database YANG Module'
>   <draft-ietf-netmod-iana-timezones-03.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>ietf@ietf.org mailing lists by 2013-12-17. Exceptionally, comments may be

There is the following question in the document shepherd write-up:

  Why is this the proper type of RFC?

I did not see an answer to that question.

The WGLC was from 5 July to 22 July.  There wasn't any comments 
during the WGLC.  The only comment I found was one posted on 9 August.

In Section 1:

  "The iana-timezones YANG module defines the iana-
   timezone type, which is a serialization of the existing IANA Time
   Zone registry [RFC6557] into YANG format."

The terminology in RFC 6557 defines a TZ Database sometimes referred 
to as the "Olson Database".  There isn't any mention of a "IANA Time 
Zone registry".  I suggest using the same name as in RFC 6557.

>From Section 3:

  'The iana-timezones module is intended to reflect the IANA "timezone
   database" [RFC6557].  When a timezone location is added to the
   database, the "iana-timezone" enumeration MUST be updated as defined
   in RFC 6020 Section 10 to add the newly created timezone location to
   the enumeration.  The new "enum" statement MUST be added to the
   "iana-timezone" typedef with the same name as the newly added
   timezone location.  A new enum value MUST be allocated by IANA and
   applied to the newly created enum entry.  New entries MAY be placed
   in any order in the enumeration as long as the previously assigned
   enumeration values are not changed.

   If a timezone location is removed from the IANA timezone database,
   the corresponding existing enum statement is kept and a status
   statement is added to mark the enum entry as 'obsolete'.'

The maintainer of the TZ database is responsible for the TZ 
Database.  The person does not work for IANA.  I don't think that 
IANA keeps track of the contents of the TZ Database as it was not 
asked to do that work.  I don't see the value of using RFC 2119 key 
word for the IANA Considerations.

I suggest not creating the registry proposed in this draft.  The TZ 
database has strived to keep out of political issues.  Adding such a 
registry will pave the way for such issues.

Regards,
-sm 

.



      

    

    

  


--------------010107060409060702080209--

From bclaise@cisco.com  Fri Dec  6 05:52:53 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976631ADF9D for ; Fri,  6 Dec 2013 05:52:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgtHp3eM2DIV for ; Fri,  6 Dec 2013 05:52:52 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 449901ADF89 for ; Fri,  6 Dec 2013 05:52:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=637; q=dns/txt; s=iport; t=1386337969; x=1387547569; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=rYtYBC6RMiXv5neHtMmKQqympP7WiTsSstqQEQP1Tnw=; b=HyuMctiiTBAtsR+62qtmRfRWJcLqmDIXfHnToAWgv6degyWnFcmn99dr DEjUFQdLk6J/WLPpkDiTczy4aeIyHJ7nwRGmvYvoX2SxXofPgj1LgqAoo G+CrNea15LxaO+FmeY4aefJCbmIlJvNvmVq0LG94WcNnpqFQ+5TrzbCpR I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAFTWoVKQ/khN/2dsb2JhbABQCYMHuguBJRZ0gmRBKRM0AkwNAQcBAYd+wRMXjjVbhDoDmBSGRYtOgyo7
X-IronPort-AV: E=Sophos;i="4.93,841,1378857600";  d="scan'208";a="1176796"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 06 Dec 2013 13:52:48 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB6DqiSE005050; Fri, 6 Dec 2013 13:52:44 GMT
Message-ID: <52A1D6AC.10105@cisco.com>
Date: Fri, 06 Dec 2013 14:52:44 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Martin Bjorklund 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: NETMOD Working Group 
Subject: [netmod] AD review of draft-ietf-netmod-iana-if-type
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 13:52:53 -0000

Dear all,

Two small points.

1.
      Copyright (c) 2011 IETF Trust and the persons identified as
         authors of the code.  All rights reserved.

2011. I guess it shows how long we've been working on that module


2.
Really a small editorial improvement. Take it or leave it

OLD:
  This YANG module imports an identity from
    [I-D.ietf-netmod-interfaces-cfg].

NEW
  This YANG module imports the interface-type identity from
    [I-D.ietf-netmod-interfaces-cfg]


Please post a new version.
I'll progress it to IETF LC with ietf-netmod-interfaces-cfg, which is a normative reference.

Regards, Benoit


From mbj@tail-f.com  Fri Dec  6 06:13:42 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77A51AE3AE for ; Fri,  6 Dec 2013 06:13:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ2gNNBxC0dh for ; Fri,  6 Dec 2013 06:13:41 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id AE9291ADF9D for ; Fri,  6 Dec 2013 06:13: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 004C037C009; Fri,  6 Dec 2013 15:13:35 +0100 (CET)
Date: Fri, 06 Dec 2013 15:13:35 +0100 (CET)
Message-Id: <20131206.151335.2010514698101736744.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <52A19966.3020903@cisco.com>
References: <529F5B4E.70406@cisco.com> <20131205.123210.2269861100175493083.mbj@tail-f.com> <52A19966.3020903@cisco.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 14:13:42 -0000

Hi,

Benoit Claise  wrote:
> > Benoit Claise  wrote:
> > I wondered about the correlation between the entries in /interface/
> > and /interfaces-state/ ?
> > In the section 3.1, an extra paragraph would help, explaining the
> > correlation of entries in/interfaces/ and/interfaces-state/
> > * In the normal case, ie, if all interfaces are configured, entries in/
> > * //interface/ = entries in/interfaces-state/
> > * On top of that, if some interfaces are pre-provisioned, extra entries
> > * will appear in the/interfaces/
> > * However, it could also happen that not all interfaces are configured:
> >    in this case, all existing interfaces would appear in/
> >    //interfaces-state/ while only the configured ones appear
> >    in/interface/
> >
> You don't consider this one above as a useful piece of information for
> the draft?

Sorry I missed this one.

I don't think we can say that the normal case is that all interfaces
are configured.  This might be different in different situations.

I think the current text, which has been discussed for some time on
the ML, explains the relationship between the two lists.



/martin

From bclaise@cisco.com  Fri Dec  6 06:17:28 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860AF1ADFE2 for ; Fri,  6 Dec 2013 06:17:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5ur4HaEeoeD for ; Fri,  6 Dec 2013 06:17:27 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 468C21ADF99 for ; Fri,  6 Dec 2013 06:17:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1355; q=dns/txt; s=iport; t=1386339444; x=1387549044; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Olwb2y7uvS0JBbF+fgVyvEDHR8XWmVzpm4yjNTn0jFc=; b=HxSYCQ4Hua/91jk23zdQ5zyjKstsNVKNiwN6W2Bec+RwPh1zYF6KdUIV jokYFLUckSnXsO8GLppQsn/K+HwgpUfBm2lN9Ib4DvFTEnescNorLoW9w iuAg7OQ6N7PyHV3vLoCT0NtnA4u+3HvwKwNz88FIDOzKbkWEQa5jaBQab w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAGXboVKQ/khR/2dsb2JhbABZgwe6C4EjFnSCJQEBAQQ4OgYBEAsOCgkWDwkDAgECAUUGDQEFAgEBh37BGhePEAeEMwOYFIZFi06DKjs
X-IronPort-AV: E=Sophos;i="4.93,841,1378857600";  d="scan'208";a="1787463"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 06 Dec 2013 14:17:22 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB6EHJn8006017; Fri, 6 Dec 2013 14:17:19 GMT
Message-ID: <52A1DC6F.8040500@cisco.com>
Date: Fri, 06 Dec 2013 15:17:19 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Martin Bjorklund 
References: <529F5B4E.70406@cisco.com>	<20131205.123210.2269861100175493083.mbj@tail-f.com>	<52A19966.3020903@cisco.com> <20131206.151335.2010514698101736744.mbj@tail-f.com>
In-Reply-To: <20131206.151335.2010514698101736744.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] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 14:17:28 -0000

On 6/12/2013 15:13, Martin Bjorklund wrote:
> Hi,
>
> Benoit Claise  wrote:
>>> Benoit Claise  wrote:
>>> I wondered about the correlation between the entries in /interface/
>>> and /interfaces-state/ ?
>>> In the section 3.1, an extra paragraph would help, explaining the
>>> correlation of entries in/interfaces/ and/interfaces-state/
>>> * In the normal case, ie, if all interfaces are configured, entries in/
>>> * //interface/ = entries in/interfaces-state/
>>> * On top of that, if some interfaces are pre-provisioned, extra entries
>>> * will appear in the/interfaces/
>>> * However, it could also happen that not all interfaces are configured:
>>>     in this case, all existing interfaces would appear in/
>>>     //interfaces-state/ while only the configured ones appear
>>>     in/interface/
>>>
>> You don't consider this one above as a useful piece of information for
>> the draft?
> Sorry I missed this one.
>
> I don't think we can say that the normal case is that all interfaces
> are configured.  This might be different in different situations.
>
> I think the current text, which has been discussed for some time on
> the ML, explains the relationship between the two lists.
Ok then.

Please publish a new draft version.

Regards, Benoit
>
>
>
> /martin
> .
>


From mbj@tail-f.com  Fri Dec  6 06:23:14 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFA01AE3B0 for ; Fri,  6 Dec 2013 06:23:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luW73KfOzUMY for ; Fri,  6 Dec 2013 06:23:13 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3FF1AE3AE for ; Fri,  6 Dec 2013 06:23:13 -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 E3E3037C009; Fri,  6 Dec 2013 15:23:08 +0100 (CET)
Date: Fri, 06 Dec 2013 15:23:08 +0100 (CET)
Message-Id: <20131206.152308.1512371708738730632.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <52A199AD.3060409@cisco.com>
References: <029401cef1db$1ab5ffb0$5021ff10$@comcast.net> <20131205.220552.467577048.mbj@tail-f.com> <52A199AD.3060409@cisco.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 14:23:14 -0000

Benoit Claise  wrote:
> On 5/12/2013 22:05, Martin Bjorklund wrote:
> > Hi David,
> >
> > "ietfdbh"  wrote:
> >> Comments inline
> >>
> >> David Harrington
> >> ietfdbh@comcast.net
> >> +1-603-828-1401
> >>
> >>> Proposal:
> >>>
> >>> OLD:
> >>>
> >>>      The data model includes configuration data, state data and counters
> >>>      for the collection of statistics.
> >>>
> >>> NEW:
> >>>
> >>>      The data model includes configuration data, status information and
> >>>      counters for the collection of statistics.
> >>>
> >>> (in the Abstract and Introduction).
> >> Why not simply:
> >>       The data model includes configuration data and state data.
> > Ok, that's better.
> I would go for
>     The data model includes configuration data and state data (status
>     information and counters)
> 
> People will get this key message without the need to look up the
> "state data" definition in the other RFC.

Ok with me.

> >>>> -
> >>>>    There are a number of counters in the IF-MIB that exist in two
> >>>>     versions; one with 32 bits and one with 64 bits.  The YANG module
> >>>>     contains the 64 bits counters only.
> >>>>
> >>>> NEW:
> >>>>     There are a number of counters in the IF-MIB that exist in two
> >>>>     versions; one with 32 bits and one with 64 bits.  Amongst those, the
> >>>>     YANG module
> >>>>     contains the 64 bits counters only.
> >> It might be helpful to explain why:
> >> NEW:
> >> There are a number of counters in the IF-MIB that are duplicated in
> >> two
> >> versions; Counter32s, for backwards compatibility with SNMPv1, and
> >> Counter64s, to support high capacity devices.
> >> Since SNMPv1 has been declared Historic, the YANG module
> >> contains only the 64 bit counters.
> > Ok, make sense.
> yes, even better

Benoit, do you think Juergen's newer propsal is ok?

> >>> Adding the prefix to all of them makes the table look bad (too long
> >>> rows...)  I propose that we add the prefix in all cases where there's
> >>> a conflict, but do not use the prefix where there is no conflict.
> >>> Specifically, this means that the "type" node gets a prefix:
> >>>
> >>> Proposal:
> >>>
> >>> OLD:
> >>>
> >>>         | /interfaces-state/interface      | ifEntry                |
> >>>         | /interfaces-state/name           | ifName                 |
> >>>         | description                      | ifAlias                |
> >>>         | type                             | ifType                 |
> >>>
> >>> NEW:
> >>>
> >>>         | /interfaces-state/interface      | ifEntry                |
> >>>         | /interfaces-state/name           | ifName                 |
> >>>         | description                      | ifAlias                |
> >>>         | /interfaces-state/type           | ifType                 |
> >>>
> >> I think it is less ambiguous to include the prefix consistently.
> > What is the ambiguity?
> As Dave, I have a small preference for the consistent addition of
> prefix.

This is what the table would look like:

   +------------------------------------------+------------------------+
   | YANG data node                           | IF-MIB object          |
   +------------------------------------------+------------------------+
   | /interfaces-state/interface              | ifEntry                |
   | /interfaces-state/interface/name         | ifName                 |
   | /interfaces/interface/description        | ifAlias                |
   | /interfaces-state/interface/type         | ifType                 |
   | /interfaces-state/interface/admin-status | ifAdminStatus          |
   | /interfaces-state/interface/oper-status  | ifOperStatus           |
   | /interfaces-state/interface/last-change  | ifLastChange           |
   | /interfaces-state/interface/if-index     | ifIndex                |
   | /interfaces-state/interface/             | ifLinkUpDownTrapEnable |
   | link-up-down-trap-enable                 |                        |
   | /interfaces-state/interface/phys-address | ifPhysAddress          |
   | /interfaces-state/interface/             | ifStackTable           |
   | higher-layer-if                          |                        |
   | /interfaces-state/interface/             | ifStackTable           |
   | lower-layer-if                           |                        |
   | /interfaces-state/interface/speed        | ifSpeed                |
   | /interfaces-state/interface/in-octets    | ifHCInOctets           |
   | /interfaces-state/interface/             | ifHCInUcastPkts        |
   | in-unicast-pkts                          |                        |
   | /interfaces-state/interface/             | ifHCInBroadcastPkts    |
   | in-broadcast-pkts                        |                        |
   | /interfaces-state/interface/             | ifHCInMulticastPkts    |
   | in-multicast-pkts                        |                        |
   | /interfaces-state/interface/in-discards  | ifInDiscards           |
   | /interfaces-state/interface/in-errors    | ifInErrors             |
   | /interfaces-state/interface/             | ifInUnknownProtos      |
   | in-unknown-protos                        |                        |
   | /interfaces-state/interface/out-octets   | ifHCOutOctets          |
   | /interfaces-state/interface/             | ifHCOutUcastPkts       |
   | out-unicast-pkts                         |                        |
   | /interfaces-state/interface/             | ifHCOutBroadcastPkts   |
   | out-broadcast-pkts                       |                        |
   | /interfaces-state/interface/             | ifHCOutMulticastPkts   |
   | out-multicast-pkts                       |                        |
   | /interfaces-state/interface/out-discards | ifOutDiscards          |
   | /interfaces-state/interface/out-errors   | ifOutErrors            |
   +------------------------------------------+------------------------+

                YANG data nodes and related IF-MIB objects


Personally, I think it is harder to read, and doesn't solve anything,
since there was no ambiguity.



/martin

From bclaise@cisco.com  Fri Dec  6 06:51:25 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FB61AE050 for ; Fri,  6 Dec 2013 06:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEo9wc1uJ-9y for ; Fri,  6 Dec 2013 06:51:23 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id DF46D1AE3AD for ; Fri,  6 Dec 2013 06:51:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8482; q=dns/txt; s=iport; t=1386341463; x=1387551063; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3HOpwEx9DionC0TJW+DPkE5Ka+rf4OxgJk+m9D01y+w=; b=ZtpErQZuegaE0hDfRDsLfBuD9znlXKxY5AFxvkK+DW5sanN/tgoXTHCx +53LdUH3UtCpmCUSPth05xWDQJpfom0vPMaE1vGbuBpMVYndr/jzf0vrR wh0n4pJYVuSO6qaAHElMhEnEp0JERxWKjdoM+H6ZFPv3BpTdzdL6fF8LX k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFAIvjoVKQ/khR/2dsb2JhbABZgwe6C4EhFnSCJgEBBDhBEAsOEyUPAkYGDQEHAQGHfsEGF48QB4QzA5gUhkWLToMqOw
X-IronPort-AV: E=Sophos;i="4.93,841,1378857600";  d="scan'208";a="1789046"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 06 Dec 2013 14:51:02 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB6EowTS016649; Fri, 6 Dec 2013 14:50:59 GMT
Message-ID: <52A1E452.20902@cisco.com>
Date: Fri, 06 Dec 2013 15:50:58 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Martin Bjorklund 
References: <029401cef1db$1ab5ffb0$5021ff10$@comcast.net>	<20131205.220552.467577048.mbj@tail-f.com>	<52A199AD.3060409@cisco.com> <20131206.152308.1512371708738730632.mbj@tail-f.com>
In-Reply-To: <20131206.152308.1512371708738730632.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] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 14:51:25 -0000

Martin,
>
>>>>>> -
>>>>>>     There are a number of counters in the IF-MIB that exist in two
>>>>>>      versions; one with 32 bits and one with 64 bits.  The YANG module
>>>>>>      contains the 64 bits counters only.
>>>>>>
>>>>>> NEW:
>>>>>>      There are a number of counters in the IF-MIB that exist in two
>>>>>>      versions; one with 32 bits and one with 64 bits.  Amongst those, the
>>>>>>      YANG module
>>>>>>      contains the 64 bits counters only.
>>>> It might be helpful to explain why:
>>>> NEW:
>>>> There are a number of counters in the IF-MIB that are duplicated in
>>>> two
>>>> versions; Counter32s, for backwards compatibility with SNMPv1, and
>>>> Counter64s, to support high capacity devices.
>>>> Since SNMPv1 has been declared Historic, the YANG module
>>>> contains only the 64 bit counters.
>>> Ok, make sense.
>> yes, even better
> Benoit, do you think Juergen's newer propsal is ok?
Yes.
>
>>>>> Adding the prefix to all of them makes the table look bad (too long
>>>>> rows...)  I propose that we add the prefix in all cases where there's
>>>>> a conflict, but do not use the prefix where there is no conflict.
>>>>> Specifically, this means that the "type" node gets a prefix:
>>>>>
>>>>> Proposal:
>>>>>
>>>>> OLD:
>>>>>
>>>>>          | /interfaces-state/interface      | ifEntry                |
>>>>>          | /interfaces-state/name           | ifName                 |
>>>>>          | description                      | ifAlias                |
>>>>>          | type                             | ifType                 |
>>>>>
>>>>> NEW:
>>>>>
>>>>>          | /interfaces-state/interface      | ifEntry                |
>>>>>          | /interfaces-state/name           | ifName                 |
>>>>>          | description                      | ifAlias                |
>>>>>          | /interfaces-state/type           | ifType                 |
>>>>>
>>>> I think it is less ambiguous to include the prefix consistently.
>>> What is the ambiguity?
>> As Dave, I have a small preference for the consistent addition of
>> prefix.
> This is what the table would look like:
>
>     +------------------------------------------+------------------------+
>     | YANG data node                           | IF-MIB object          |
>     +------------------------------------------+------------------------+
>     | /interfaces-state/interface              | ifEntry                |
>     | /interfaces-state/interface/name         | ifName                 |
>     | /interfaces/interface/description        | ifAlias                |
>     | /interfaces-state/interface/type         | ifType                 |
>     | /interfaces-state/interface/admin-status | ifAdminStatus          |
>     | /interfaces-state/interface/oper-status  | ifOperStatus           |
>     | /interfaces-state/interface/last-change  | ifLastChange           |
>     | /interfaces-state/interface/if-index     | ifIndex                |
>     | /interfaces-state/interface/             | ifLinkUpDownTrapEnable |
>     | link-up-down-trap-enable                 |                        |
>     | /interfaces-state/interface/phys-address | ifPhysAddress          |
>     | /interfaces-state/interface/             | ifStackTable           |
>     | higher-layer-if                          |                        |
>     | /interfaces-state/interface/             | ifStackTable           |
>     | lower-layer-if                           |                        |
>     | /interfaces-state/interface/speed        | ifSpeed                |
>     | /interfaces-state/interface/in-octets    | ifHCInOctets           |
>     | /interfaces-state/interface/             | ifHCInUcastPkts        |
>     | in-unicast-pkts                          |                        |
>     | /interfaces-state/interface/             | ifHCInBroadcastPkts    |
>     | in-broadcast-pkts                        |                        |
>     | /interfaces-state/interface/             | ifHCInMulticastPkts    |
>     | in-multicast-pkts                        |                        |
>     | /interfaces-state/interface/in-discards  | ifInDiscards           |
>     | /interfaces-state/interface/in-errors    | ifInErrors             |
>     | /interfaces-state/interface/             | ifInUnknownProtos      |
>     | in-unknown-protos                        |                        |
>     | /interfaces-state/interface/out-octets   | ifHCOutOctets          |
>     | /interfaces-state/interface/             | ifHCOutUcastPkts       |
>     | out-unicast-pkts                         |                        |
>     | /interfaces-state/interface/             | ifHCOutBroadcastPkts   |
>     | out-broadcast-pkts                       |                        |
>     | /interfaces-state/interface/             | ifHCOutMulticastPkts   |
>     | out-multicast-pkts                       |                        |
>     | /interfaces-state/interface/out-discards | ifOutDiscards          |
>     | /interfaces-state/interface/out-errors   | ifOutErrors            |
>     +------------------------------------------+------------------------+
>
>                  YANG data nodes and related IF-MIB objects
>
>
> Personally, I think it is harder to read, and doesn't solve anything,
> since there was no ambiguity.
Well, there was one ambiguity, with the type, which I assumed was 
/interfaces/interface/type AND /interfaces-state/interface/type. Now 
,there is only one under /interfaces/interface/, description
If you believe that's unreadable, make it two tables

    +----------------------------------------------+------------------------+
    | YANG data node (/interfaces/interface/)      | IF-MIB object          |
    +----------------------------------------------+------------------------+
    | description                                  | ifAlias                |
    +----------------------------------------------+------------------------+

    +----------------------------------------------+------------------------+
    | YANG data node (/interfaces-state/interface) | IF-MIB object          |
    +----------------------------------------------+------------------------+
    | interface                                    | ifEntry                |
    | name                                         | ifName                 |
    | description                                  | ifAlias                |
    | type                                         | ifType                 |
    | admin-status                                 | ifAdminStatus          |
    | oper-status                                  | ifOperStatus           |
    | last-change                                  | ifLastChange           |
    | if-index                                     | ifIndex                |
    | link-up-down-trap-enable                     | ifLinkUpDownTrapEnable |
    | phys-address                                 | ifPhysAddress          |
    | higher-layer-if                              | ifStackTable           |
    | lower-layer-if                               | ifStackTable           |
    | speed                                        | ifSpeed                |
    | in-octets                                    | ifHCInOctets           |
    | in-unicast-pkts                              | ifHCInUcastPkts        |
    | in-broadcast-pkts                            | ifHCInBroadcastPkts    |
    | in-multicast-pkts                            | ifHCInMulticastPkts    |
    | in-discards                                  | ifInDiscards           |
    | in-errors                                    | ifInErrors             |
    | in-unknown-protos                            | ifInUnknownProtos      |
    | out-octets                                   | ifHCOutOctets          |
    | out-unicast-pkts                             | ifHCOutUcastPkts       |
    | out-broadcast-pkts                           | ifHCOutBroadcastPkts   |
    | out-multicast-pkts                           | ifHCOutMulticastPkts   |
    | out-discards                                 | ifOutDiscards          |
    | out-errors                                   | ifOutErrors            |
    +----------------------------------------------+------------------------+



Regards, Benoit

From jonathan@hansfords.net  Fri Dec  6 07:05:52 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0481AE050 for ; Fri,  6 Dec 2013 07:05:52 -0800 (PST)
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=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpAbrt3nmuWw for ; Fri,  6 Dec 2013 07:05:49 -0800 (PST)
Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) by ietfa.amsl.com (Postfix) with ESMTP id D405F1ADFF3 for ; Fri,  6 Dec 2013 07:05:47 -0800 (PST)
Received: from [192.168.1.100] ([84.92.149.4]) by avasout01 with smtp id yF5h1m00305w0Nk01F5iEs; Fri, 06 Dec 2013 15:05:43 +0000
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=IvYnLtPg c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=crK2bTrhSLoA:10 a=m-qb6kl8J2YA:10 a=0B8HqoTn75oA:10 a=8nJEP1OIZ-IA:10 a=6bkCdLdQAAAA:8 a=GWxWy9ZvW1UA:10 a=48vgC7mUAAAA:8 a=Bmw2EzSTSbyQMPgGMy0A:9 a=9x-LLM7_dMFmlZcR:21 a=GNuuGBo2nLMC_C-y:21 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10
Message-ID: <52A1E7C6.1000504@hansfords.net>
Date: Fri, 06 Dec 2013 15:05:42 +0000
From: Jonathan Hansford 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Benoit Claise , Martin Bjorklund 
References: <029401cef1db$1ab5ffb0$5021ff10$@comcast.net>	<20131205.220552.467577048.mbj@tail-f.com>	<52A199AD.3060409@cisco.com> <20131206.152308.1512371708738730632.mbj@tail-f.com> <52A1E452.20902@cisco.com>
In-Reply-To: <52A1E452.20902@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 15:05:52 -0000

On 06/12/2013 14:50, Benoit Claise wrote:
> Martin,
>>
>>>>>>> -
>>>>>>>     There are a number of counters in the IF-MIB that exist in two
>>>>>>>      versions; one with 32 bits and one with 64 bits. The YANG 
>>>>>>> module
>>>>>>>      contains the 64 bits counters only.
>>>>>>>
>>>>>>> NEW:
>>>>>>>      There are a number of counters in the IF-MIB that exist in two
>>>>>>>      versions; one with 32 bits and one with 64 bits. Amongst 
>>>>>>> those, the
>>>>>>>      YANG module
>>>>>>>      contains the 64 bits counters only.
>>>>> It might be helpful to explain why:
>>>>> NEW:
>>>>> There are a number of counters in the IF-MIB that are duplicated in
>>>>> two
>>>>> versions; Counter32s, for backwards compatibility with SNMPv1, and
>>>>> Counter64s, to support high capacity devices.
>>>>> Since SNMPv1 has been declared Historic, the YANG module
>>>>> contains only the 64 bit counters.
>>>> Ok, make sense.
>>> yes, even better
>> Benoit, do you think Juergen's newer propsal is ok?
> Yes.
>>
>>>>>> Adding the prefix to all of them makes the table look bad (too long
>>>>>> rows...)  I propose that we add the prefix in all cases where 
>>>>>> there's
>>>>>> a conflict, but do not use the prefix where there is no conflict.
>>>>>> Specifically, this means that the "type" node gets a prefix:
>>>>>>
>>>>>> Proposal:
>>>>>>
>>>>>> OLD:
>>>>>>
>>>>>>          | /interfaces-state/interface      | 
>>>>>> ifEntry                |
>>>>>>          | /interfaces-state/name           | 
>>>>>> ifName                 |
>>>>>>          | description                      | 
>>>>>> ifAlias                |
>>>>>>          | type                             | 
>>>>>> ifType                 |
>>>>>>
>>>>>> NEW:
>>>>>>
>>>>>>          | /interfaces-state/interface      | 
>>>>>> ifEntry                |
>>>>>>          | /interfaces-state/name           | 
>>>>>> ifName                 |
>>>>>>          | description                      | 
>>>>>> ifAlias                |
>>>>>>          | /interfaces-state/type           | 
>>>>>> ifType                 |
>>>>>>
>>>>> I think it is less ambiguous to include the prefix consistently.
>>>> What is the ambiguity?
>>> As Dave, I have a small preference for the consistent addition of
>>> prefix.
>> This is what the table would look like:
>>
>> +------------------------------------------+------------------------+
>>     | YANG data node                           | IF-MIB 
>> object          |
>> +------------------------------------------+------------------------+
>>     | /interfaces-state/interface              | 
>> ifEntry                |
>>     | /interfaces-state/interface/name         | 
>> ifName                 |
>>     | /interfaces/interface/description        | 
>> ifAlias                |
>>     | /interfaces-state/interface/type         | 
>> ifType                 |
>>     | /interfaces-state/interface/admin-status | 
>> ifAdminStatus          |
>>     | /interfaces-state/interface/oper-status  | 
>> ifOperStatus           |
>>     | /interfaces-state/interface/last-change  | 
>> ifLastChange           |
>>     | /interfaces-state/interface/if-index     | 
>> ifIndex                |
>>     | /interfaces-state/interface/             | 
>> ifLinkUpDownTrapEnable |
>>     | link-up-down-trap-enable |                        |
>>     | /interfaces-state/interface/phys-address | 
>> ifPhysAddress          |
>>     | /interfaces-state/interface/             | 
>> ifStackTable           |
>>     | higher-layer-if |                        |
>>     | /interfaces-state/interface/             | 
>> ifStackTable           |
>>     | lower-layer-if |                        |
>>     | /interfaces-state/interface/speed        | 
>> ifSpeed                |
>>     | /interfaces-state/interface/in-octets    | 
>> ifHCInOctets           |
>>     | /interfaces-state/interface/             | 
>> ifHCInUcastPkts        |
>>     | in-unicast-pkts |                        |
>>     | /interfaces-state/interface/             | 
>> ifHCInBroadcastPkts    |
>>     | in-broadcast-pkts |                        |
>>     | /interfaces-state/interface/             | 
>> ifHCInMulticastPkts    |
>>     | in-multicast-pkts |                        |
>>     | /interfaces-state/interface/in-discards  | 
>> ifInDiscards           |
>>     | /interfaces-state/interface/in-errors    | 
>> ifInErrors             |
>>     | /interfaces-state/interface/             | 
>> ifInUnknownProtos      |
>>     | in-unknown-protos |                        |
>>     | /interfaces-state/interface/out-octets   | 
>> ifHCOutOctets          |
>>     | /interfaces-state/interface/             | 
>> ifHCOutUcastPkts       |
>>     | out-unicast-pkts |                        |
>>     | /interfaces-state/interface/             | 
>> ifHCOutBroadcastPkts   |
>>     | out-broadcast-pkts |                        |
>>     | /interfaces-state/interface/             | 
>> ifHCOutMulticastPkts   |
>>     | out-multicast-pkts |                        |
>>     | /interfaces-state/interface/out-discards | 
>> ifOutDiscards          |
>>     | /interfaces-state/interface/out-errors   | 
>> ifOutErrors            |
>> +------------------------------------------+------------------------+
>>
>>                  YANG data nodes and related IF-MIB objects
>>
>>
>> Personally, I think it is harder to read, and doesn't solve anything,
>> since there was no ambiguity.
> Well, there was one ambiguity, with the type, which I assumed was 
> /interfaces/interface/type AND /interfaces-state/interface/type. Now 
> ,there is only one under /interfaces/interface/, description
> If you believe that's unreadable, make it two tables
>
> +----------------------------------------------+------------------------+
>    | YANG data node (/interfaces/interface/)      | IF-MIB 
> object          |
> +----------------------------------------------+------------------------+
>    | description                                  | 
> ifAlias                |
> +----------------------------------------------+------------------------+
>
> +----------------------------------------------+------------------------+
>    | YANG data node (/interfaces-state/interface) | IF-MIB 
> object          |
> +----------------------------------------------+------------------------+
>    | interface                                    | 
> ifEntry                |
>    | name                                         | 
> ifName                 |
>    | description                                  | 
> ifAlias                |
>    | type                                         | 
> ifType                 |
>    | admin-status                                 | 
> ifAdminStatus          |
>    | oper-status                                  | 
> ifOperStatus           |
>    | last-change                                  | 
> ifLastChange           |
>    | if-index                                     | 
> ifIndex                |
>    | link-up-down-trap-enable                     | 
> ifLinkUpDownTrapEnable |
>    | phys-address                                 | 
> ifPhysAddress          |
>    | higher-layer-if                              | 
> ifStackTable           |
>    | lower-layer-if                               | 
> ifStackTable           |
>    | speed                                        | 
> ifSpeed                |
>    | in-octets                                    | 
> ifHCInOctets           |
>    | in-unicast-pkts                              | 
> ifHCInUcastPkts        |
>    | in-broadcast-pkts                            | 
> ifHCInBroadcastPkts    |
>    | in-multicast-pkts                            | 
> ifHCInMulticastPkts    |
>    | in-discards                                  | 
> ifInDiscards           |
>    | in-errors                                    | 
> ifInErrors             |
>    | in-unknown-protos                            | 
> ifInUnknownProtos      |
>    | out-octets                                   | 
> ifHCOutOctets          |
>    | out-unicast-pkts                             | 
> ifHCOutUcastPkts       |
>    | out-broadcast-pkts                           | 
> ifHCOutBroadcastPkts   |
>    | out-multicast-pkts                           | 
> ifHCOutMulticastPkts   |
>    | out-discards                                 | 
> ifOutDiscards          |
>    | out-errors                                   | 
> ifOutErrors            |
> +----------------------------------------------+------------------------+
>

+1

>
>
> Regards, Benoit
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From mbj@tail-f.com  Fri Dec  6 07:24:11 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44151ADA5D for ; Fri,  6 Dec 2013 07:24:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLpCvT0fvbQ2 for ; Fri,  6 Dec 2013 07:24:11 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C73121AC863 for ; Fri,  6 Dec 2013 07:24:10 -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 A422737C006; Fri,  6 Dec 2013 16:24:04 +0100 (CET)
Date: Fri, 06 Dec 2013 16:24:04 +0100 (CET)
Message-Id: <20131206.162404.577060907804849871.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20131206103635.GA35073@elstar.local>
References: <029401cef1db$1ab5ffb0$5021ff10$@comcast.net> <20131205.220552.467577048.mbj@tail-f.com> <20131206103635.GA35073@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 15:24:12 -0000

Juergen Schoenwaelder  wrote:
> On Thu, Dec 05, 2013 at 10:05:52PM +0100, Martin Bjorklund wrote:
> 
> > > It might be helpful to explain why:
> > > NEW:
> > > There are a number of counters in the IF-MIB that are duplicated in
> > > two
> > > versions; Counter32s, for backwards compatibility with SNMPv1, and
> > > Counter64s, to support high capacity devices.  
> > > Since SNMPv1 has been declared Historic, the YANG module
> > > contains only the 64 bit counters.
> > 
> > Ok, make sense.
> 
> I am not sure this design decision had something to do with SNMPv1
> officially been labeled Historic by the IETF.
> 
> As far as I recall, when the WG discussed this, the point was made
> that today's implementations (~20 years after the introduction of
> 64-bit counters in RFC 1573) generally support 64-bit counters and
> NETCONF does fine shipping 64-bit counters - so there is no need to
> have additional 32-bit counters.  Perhaps instead of discussing SNMP's
> history, we should write down why those counters are 64-bit only:
> 
> NEW:
> 
>   To support high-speed interfaces with a data rate greater than
>   20,000,000 bits/second, RFC 1573 (published in 1994) added 64-bit
>   counters to the IF-MIB. Today's implementations generally support
>   such high-speed interfaces and hence only 64-bit counters are
>   provided in this data model.

How about this (complete paragraphs):

OLD:

   There are a number of counters in the IF-MIB that exist in two
   versions; one with 32 bits and one with 64 bits.  The YANG module
   contains the 64 bits counters only.  Note that NETCONF and SNMP may
   differ in the time granularity in which they provide access to the
   counters.  For example, it is common that SNMP implementations cache
   counter values for some time.

NEW:

  There are a number of counters in the IF-MIB that exist in two
  versions; one with 32 bits and one with 64 bits.  The 64-bit
  versions were added to support high-speed interfaces with a data
  rate greater than 20,000,000 bits/second.  Today's implementations
  generally support such high-speed interfaces and hence only 64-bit
  counters are provided in this data model.  Note that NETCONF and
  SNMP may differ in the time granularity in which they provide access
  to the counters.  For example, it is common that SNMP
  implementations cache counter values for some time.


(or did you want the 1573 reference and the 1994 date?)



/martin

From j.schoenwaelder@jacobs-university.de  Fri Dec  6 09:12:28 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79F21AE020 for ; Fri,  6 Dec 2013 09:12:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF2P4GMM7J_Q for ; Fri,  6 Dec 2013 09:12:26 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B71581AE0A9 for ; Fri,  6 Dec 2013 09:12:26 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 944B620082; Fri,  6 Dec 2013 18:12:22 +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 fkid0Nuy7lKA; Fri,  6 Dec 2013 18:12:22 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EFE820043; Fri,  6 Dec 2013 18:12:21 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 7F16D29E6502; Fri,  6 Dec 2013 18:12:17 +0100 (CET)
Date: Fri, 6 Dec 2013 18:12:17 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20131206171217.GA36262@elstar.local>
Mail-Followup-To: Martin Bjorklund , ietfdbh@comcast.net, netmod@ietf.org
References: <029401cef1db$1ab5ffb0$5021ff10$@comcast.net> <20131205.220552.467577048.mbj@tail-f.com> <20131206103635.GA35073@elstar.local> <20131206.162404.577060907804849871.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131206.162404.577060907804849871.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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 Dec 2013 17:12:29 -0000

On Fri, Dec 06, 2013 at 04:24:04PM +0100, Martin Bjorklund wrote:
> 
> (or did you want the 1573 reference and the 1994 date?)
> 

The year was added to make it clear that almost 20 years have passed
since the introduction of 64-bit counters. The year does not have to
be in the final text - the 20 Mbps also make it kind of clear what
high-speed interface meant back then.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From ietfdbh@comcast.net  Fri Dec  6 11:48:59 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087A71ADF81 for ; Fri,  6 Dec 2013 11:48:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuLDbegiw9GJ for ; Fri,  6 Dec 2013 11:48:57 -0800 (PST)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id E539C1AD84D for ; Fri,  6 Dec 2013 11:48:56 -0800 (PST)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA11.westchester.pa.mail.comcast.net with comcast id yDyx1m0020ldTLk5BKoshN; Fri, 06 Dec 2013 19:48:52 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta04.westchester.pa.mail.comcast.net with comcast id yKos1m0022yZEBF01Koszx; Fri, 06 Dec 2013 19:48:52 +0000
From: "ietfdbh" 
To: "'Martin Bjorklund'" , 
References: <029401cef1db$1ab5ffb0$5021ff10$@comcast.net>	<20131205.220552.467577048.mbj@tail-f.com>	<52A199AD.3060409@cisco.com> <20131206.152308.1512371708738730632.mbj@tail-f.com>
In-Reply-To: <20131206.152308.1512371708738730632.mbj@tail-f.com>
Date: Fri, 6 Dec 2013 14:48:50 -0500
Message-ID: <002101cef2bc$2fabe150$8f03a3f0$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKy5gAVQgblnroms60hq4/pMLWh0wFYuqr7AhsWv0gCx6w7qZhN0F3Q
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386359332; bh=UZhZBQonDRhUws4N1qFLADyCLY+qv6G4F+766/ufZ6Y=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=G2cQLar99AcT/21pC3C7k25d7S+CdhSHXe3MZ8Bl+i0KFgoRkEz+kP3kupaXIUeNa ltieIR+yi8IxZ1Nxv8n6Cv32nUBzBuFxH9n3iBIy+egm2pLopyUgNeYcijuA/OuvcZ oSJX8238Hjhz1kRDKAFcZ3+LLuObkALcua2pYvVN1ZNHIpEnF9UITYpd6GDXDkqJgE Hy4V7CzqiTd39Rv7LeR7YJORzfSMoc/xbLEavYMXWrD57q9irE1k8kuh6nm8ZKe4Mo siYe26SZsFqZJseazsiPylGkBNXHRyKDddySxna9xhbrToaUQlxfnpLvI8N0kDXznD lR7TlOUcG6dYg==
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review draft-ietf-netmod-interfaces-cfg-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 06 Dec 2013 19:48:59 -0000

I think Juergen's proposal is fine.

David Harrington
ietfdbh@comcast.net
+1-603-828-1401
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Friday, December 06, 2013 9:23 AM
> To: bclaise@cisco.com
> Cc: ietfdbh@comcast.net; netmod@ietf.org
> Subject: Re: [netmod] AD review draft-ietf-netmod-interfaces-cfg-13
> 
> Benoit Claise  wrote:
> > On 5/12/2013 22:05, Martin Bjorklund wrote:
> > > Hi David,
> > >
> > > "ietfdbh"  wrote:
> > >> Comments inline
> > >>
> > >> David Harrington
> > >> ietfdbh@comcast.net
> > >> +1-603-828-1401
> > >>
> > >>> Proposal:
> > >>>
> > >>> OLD:
> > >>>
> > >>>      The data model includes configuration data, state data and
counters
> > >>>      for the collection of statistics.
> > >>>
> > >>> NEW:
> > >>>
> > >>>      The data model includes configuration data, status information
and
> > >>>      counters for the collection of statistics.
> > >>>
> > >>> (in the Abstract and Introduction).
> > >> Why not simply:
> > >>       The data model includes configuration data and state data.
> > > Ok, that's better.
> > I would go for
> >     The data model includes configuration data and state data (status
> >     information and counters)
> >
> > People will get this key message without the need to look up the
> > "state data" definition in the other RFC.
> 
> Ok with me.
> 
> > >>>> -
> > >>>>    There are a number of counters in the IF-MIB that exist in two
> > >>>>     versions; one with 32 bits and one with 64 bits.  The YANG
module
> > >>>>     contains the 64 bits counters only.
> > >>>>
> > >>>> NEW:
> > >>>>     There are a number of counters in the IF-MIB that exist in two
> > >>>>     versions; one with 32 bits and one with 64 bits.  Amongst
those, the
> > >>>>     YANG module
> > >>>>     contains the 64 bits counters only.
> > >> It might be helpful to explain why:
> > >> NEW:
> > >> There are a number of counters in the IF-MIB that are duplicated in
> > >> two
> > >> versions; Counter32s, for backwards compatibility with SNMPv1, and
> > >> Counter64s, to support high capacity devices.
> > >> Since SNMPv1 has been declared Historic, the YANG module
> > >> contains only the 64 bit counters.
> > > Ok, make sense.
> > yes, even better
> 
> Benoit, do you think Juergen's newer propsal is ok?
> 
> > >>> Adding the prefix to all of them makes the table look bad (too long
> > >>> rows...)  I propose that we add the prefix in all cases where
there's
> > >>> a conflict, but do not use the prefix where there is no conflict.
> > >>> Specifically, this means that the "type" node gets a prefix:
> > >>>
> > >>> Proposal:
> > >>>
> > >>> OLD:
> > >>>
> > >>>         | /interfaces-state/interface      | ifEntry
|
> > >>>         | /interfaces-state/name           | ifName
|
> > >>>         | description                      | ifAlias
|
> > >>>         | type                             | ifType
|
> > >>>
> > >>> NEW:
> > >>>
> > >>>         | /interfaces-state/interface      | ifEntry
|
> > >>>         | /interfaces-state/name           | ifName
|
> > >>>         | description                      | ifAlias
|
> > >>>         | /interfaces-state/type           | ifType
|
> > >>>
> > >> I think it is less ambiguous to include the prefix consistently.
> > > What is the ambiguity?
> > As Dave, I have a small preference for the consistent addition of
> > prefix.
> 
> This is what the table would look like:
> 
>    +------------------------------------------+------------------------+
>    | YANG data node                           | IF-MIB object          |
>    +------------------------------------------+------------------------+
>    | /interfaces-state/interface              | ifEntry                |
>    | /interfaces-state/interface/name         | ifName                 |
>    | /interfaces/interface/description        | ifAlias                |
>    | /interfaces-state/interface/type         | ifType                 |
>    | /interfaces-state/interface/admin-status | ifAdminStatus          |
>    | /interfaces-state/interface/oper-status  | ifOperStatus           |
>    | /interfaces-state/interface/last-change  | ifLastChange           |
>    | /interfaces-state/interface/if-index     | ifIndex                |
>    | /interfaces-state/interface/             | ifLinkUpDownTrapEnable |
>    | link-up-down-trap-enable                 |                        |
>    | /interfaces-state/interface/phys-address | ifPhysAddress          |
>    | /interfaces-state/interface/             | ifStackTable           |
>    | higher-layer-if                          |                        |
>    | /interfaces-state/interface/             | ifStackTable           |
>    | lower-layer-if                           |                        |
>    | /interfaces-state/interface/speed        | ifSpeed                |
>    | /interfaces-state/interface/in-octets    | ifHCInOctets           |
>    | /interfaces-state/interface/             | ifHCInUcastPkts        |
>    | in-unicast-pkts                          |                        |
>    | /interfaces-state/interface/             | ifHCInBroadcastPkts    |
>    | in-broadcast-pkts                        |                        |
>    | /interfaces-state/interface/             | ifHCInMulticastPkts    |
>    | in-multicast-pkts                        |                        |
>    | /interfaces-state/interface/in-discards  | ifInDiscards           |
>    | /interfaces-state/interface/in-errors    | ifInErrors             |
>    | /interfaces-state/interface/             | ifInUnknownProtos      |
>    | in-unknown-protos                        |                        |
>    | /interfaces-state/interface/out-octets   | ifHCOutOctets          |
>    | /interfaces-state/interface/             | ifHCOutUcastPkts       |
>    | out-unicast-pkts                         |                        |
>    | /interfaces-state/interface/             | ifHCOutBroadcastPkts   |
>    | out-broadcast-pkts                       |                        |
>    | /interfaces-state/interface/             | ifHCOutMulticastPkts   |
>    | out-multicast-pkts                       |                        |
>    | /interfaces-state/interface/out-discards | ifOutDiscards          |
>    | /interfaces-state/interface/out-errors   | ifOutErrors            |
>    +------------------------------------------+------------------------+
> 
>                 YANG data nodes and related IF-MIB objects
> 
> 
> Personally, I think it is harder to read, and doesn't solve anything,
> since there was no ambiguity.
> 
> 
> 
> /martin


From internet-drafts@ietf.org  Sat Dec  7 04:56:21 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E377C1AE32C; Sat,  7 Dec 2013 04:56:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3CXvBHuv1ab; Sat,  7 Dec 2013 04:56:19 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1981AE31C; Sat,  7 Dec 2013 04:56:19 -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: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131207125619.15747.40014.idtracker@ietfa.amsl.com>
Date: Sat, 07 Dec 2013 04:56:19 -0800
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-14.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 07 Dec 2013 12:56:21 -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 Working Gr=
oup of the IETF.

	Title           : A YANG Data Model for Interface Management
	Author(s)       : Martin Bjorklund
	Filename        : draft-ietf-netmod-interfaces-cfg-14.txt
	Pages           : 45
	Date            : 2013-12-07

Abstract:
   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface type specific data models
   augment the generic interfaces data model defined in this document.
   The data model includes configuration data and state data (status
   information and counters for the collection of statistics).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-interfaces-cfg-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Sat Dec  7 04:56:49 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C0A1AE345; Sat,  7 Dec 2013 04:56:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1DeYDfCwd3D; Sat,  7 Dec 2013 04:56:48 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8781AE31C; Sat,  7 Dec 2013 04:56:48 -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: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131207125648.15791.43867.idtracker@ietfa.amsl.com>
Date: Sat, 07 Dec 2013 04:56:48 -0800
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-09.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 07 Dec 2013 12:56:50 -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 Working Gr=
oup of the IETF.

	Title           : IANA Interface Type YANG Module
	Author(s)       : Martin Bjorklund
	Filename        : draft-ietf-netmod-iana-if-type-09.txt
	Pages           : 40
	Date            : 2013-12-07

Abstract:
   This document defines the initial version of the iana-if-type YANG
   module.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-if-type-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From bclaise@cisco.com  Sat Dec  7 07:11:53 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5AA1ADFD5 for ; Sat,  7 Dec 2013 07:11:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXPm0_2dsK7Q for ; Sat,  7 Dec 2013 07:11:52 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2711ADF7A for ; Sat,  7 Dec 2013 07:11:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=74; q=dns/txt; s=iport; t=1386429108; x=1387638708; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=oZuFWAmmnuzJFu2HElhvdmOLX8/9V0ekPijZOf5cfpM=; b=T8kzuuZhkkn+tbWNihB3QErBOS/oGIKo6TqeUM4wRbaXA9rMYKzWRwLU I9zXh/aE0kzyDmksEGa+H2MSFkafaxJYzQoaVVTh/ycYg9VydptJw8H4W PLsPLgF0aq9dvnH4bv1Z5INA9ZXMCVYK+cBb5Z6ExBQ7KZ739/J6iMKFg Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFAL45o1KQ/khL/2dsb2JhbABZgwe7NhZ0gmRAPRYYAwIBAgFLDQgBAYd+ogyeXheTSgOYFIZFi06Ba4E/Ow
X-IronPort-AV: E=Sophos;i="4.93,847,1378857600";  d="scan'208";a="1223148"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 07 Dec 2013 15:11:47 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB7FBh35012279 for ; Sat, 7 Dec 2013 15:11:43 GMT
Message-ID: <52A33AAF.2020401@cisco.com>
Date: Sat, 07 Dec 2013 16:11:43 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: NETMOD Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [netmod] draft-ietf-netmod-interfaces-cfg and draft-ietf-netmod-iana-if-type are sent the IETF LC
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 07 Dec 2013 15:11:53 -0000

Dear all,

The next AD reviews will follow shortly.

Regards, Benoit

From bclaise@cisco.com  Mon Dec  9 08:11:35 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F7A1ADFBD for ; Mon,  9 Dec 2013 08:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.501
X-Spam-Level: 
X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTwDd6wxS6Ei for ; Mon,  9 Dec 2013 08:11:27 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 54AE71ADF62 for ; Mon,  9 Dec 2013 08:11:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9390; q=dns/txt; s=iport; t=1386605479; x=1387815079; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=r7t5XPe/U/OLfwj02QmMcIH0mAKEH7su91HErAegSo0=; b=ALrcP0bvrq6htUfm+cHvCrWvk2mZbD+PCVJyYSO3aK/QTbi2bFfxUovc DO51OggJO2pqMPd5OxJz5EfMx27mPY0Fh1IDsbSirqmFHUvKwpsoeHyIw 5C/S50tRmnFTAgZFaqGpLl3Kc1ByaC6Ck4dbQs55X5TIAOf3Y8Vgou0PA k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFAGvqpVKQ/khN/2dsb2JhbABZgwc4uWiBLxZ0giYBAQSBCSwlDwJGBg0IAQGHfg3BUxePF4QzA5Qxg2OBMIUVi06DKjs
X-IronPort-AV: E=Sophos;i="4.93,858,1378857600"; d="scan'208,217";a="1916203"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 09 Dec 2013 16:11:17 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB9GBDMS009286 for ; Mon, 9 Dec 2013 16:11:14 GMT
Message-ID: <52A5EBA1.50802@cisco.com>
Date: Mon, 09 Dec 2013 17:11:13 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: NETMOD Working Group 
References: <52A5CCD2.7030903@cisco.com>
In-Reply-To: <52A5CCD2.7030903@cisco.com>
X-Forwarded-Message-Id: <52A5CCD2.7030903@cisco.com>
Content-Type: multipart/alternative; boundary="------------040007070204000300030804"
Subject: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 16:11:35 -0000

This is a multi-part message in MIME format.
--------------040007070204000300030804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear authors,

Here is my AD review.

-
exactly like indraft-ietf-netmod-interfaces-cfg  , which contains a summary table with MIB variable table, this document should contain a similar mapping table
For example
       +--rw system
       |  +--rw contact?          string
       |  +--rw hostname?         inet:domain-name
       |  +--rw location?         string
       +--ro system-state
          +--ro platform
             +--ro os-name?       string
             +--ro os-release?    string
             +--ro os-version?    string
             +--ro machine?       string

This maps to the system group MIB variables. Some leavs definitions already refer to some MIB variables: sysContact, sysLocation, etc.
I understand the MIB variables don't map 1:1, but telling that
             os-name        part of the sysDescr MIB variable
             os-release     part of the sysDescr MIB variable
             os-version     part of the sysDescr MIB variable
             machine?       part of the sysDescr MIB variable
... is also useful info.

Considering that NETCONF is now also used for monitoring, and that people were used to SNMP, such mapping tables would be a good practice in all NETMOD documents to help SNMP people/NMS make the transition.
There might be some read-only MIB variables in the following RFCs:
RFC 4668 RADIUS Authentication Client MIB
RFC 4669 RADIUS Authentication Server MIB
RFC 5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)
...

So it needs a little bit of research, but shouldn't be too hard.


-
   leaf location {
          type string;
          description
            "The system location. The server MAY restrict the size
             and characters in order to maintain compatibility with
             the sysLocation MIB object.";
          reference
            "RFC 3418  : Management Information Base (MIB) for the
                       Simple Network Management Protocol (SNMP)
                       SNMPv2-MIB.sysLocation";
        }

Question: do we want to be aligned with the leaf name logic inhttps://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/  ?

leaf name {
    ...
    In most cases, the "name" of an "interface" entry is mapped to
    ifName. ifName is defined as a DisplayString [RFC2579] which uses a
    7-bit ASCII character set.  An implementation that performs this
    mapping MUST restrict the allowed values for "name" to match the
    restrictions of ifName.

So basically
NEW:
   leaf location {
          type string;
          description
            "The system location. In most cases, the "location" of an "interface" entry
            is mapped to sysLocation. sysLocation is defined as a DisplayString [RFC2579]
            which uses a 7-bit ASCII character set. An implementation that performs this
            mapping MUST restrict the allowed values for "location" to match the
            restrictions of sysLocation.";
          reference
            "RFC 3418  : Management Information Base (MIB) for the
                       Simple Network Management Protocol (SNMP)
                       SNMPv2-MIB.sysLocation";
        }


-
+--rw system
       |  +--rw clock
       |  |  +--rw (timezone)?
       |  |     +--:(timezone-location)
       |  |     |  +--rw timezone-location?     ianatz:iana-timezone
       |  |     +--:(timezone-utc-offset)
       |  |        +--rw timezone-utc-offset?   int16
       |  +--rw ntp!
       |     +--rw enabled?   boolean

  leaf enabled {
            type boolean;
            default true;
            description
              "Indicates that the system should attempt
               to synchronize the system clock with an
               NTP server from the 'ntp/server' list.";
          }


How come that enabled is marked as optional while there is a default value?
Aren't they slightly conflicting statements?
Disclaimer: no strong feeling about that one.
  
-
Do we need the NTP version, 3 or 4, as a config field?

Regards, Benoit (OPS AD)









--------------040007070204000300030804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear authors, 

    

      
Here is my AD review.

- 
exactly like in draft-ietf-netmod-interfaces-cfg, which contains a summary table with MIB variable table, this document should contain a similar mapping table
For example
      +--rw system
      |  +--rw contact?          string
      |  +--rw hostname?         inet:domain-name
      |  +--rw location?         string
      +--ro system-state
         +--ro platform
            +--ro os-name?       string
            +--ro os-release?    string
            +--ro os-version?    string
            +--ro machine?       string

This maps to the system group MIB variables. Some leavs definitions already refer to some MIB variables: sysContact, sysLocation, etc.
I understand the MIB variables don't map 1:1, but telling that 
            os-name        part of the sysDescr MIB variable
            os-release     part of the sysDescr MIB variable
            os-version     part of the sysDescr MIB variable
            machine?       part of the sysDescr MIB variable
... is also useful info.

Considering that NETCONF is now also used for monitoring, and that people were used to SNMP, such mapping tables would be a good practice in all NETMOD documents to help SNMP people/NMS make the transition.
There might be some read-only MIB variables in the following RFCs:
RFC 4668 RADIUS Authentication Client MIB
RFC 4669 RADIUS Authentication Server MIB 
RFC 5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)
...

So it needs a little bit of research, but shouldn't be too hard.


-
  leaf location {
         type string;
         description
           "The system location. The server MAY restrict the size
            and characters in order to maintain compatibility with
            the sysLocation MIB object.";
         reference
           "RFC 3418: Management Information Base (MIB) for the
                      Simple Network Management Protocol (SNMP)
                      SNMPv2-MIB.sysLocation";
       }

Question: do we want to be aligned with the leaf name logic in https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ ?

leaf name {
   ...
   In most cases, the "name" of an "interface" entry is mapped to
   ifName. ifName is defined as a DisplayString [RFC2579] which uses a
   7-bit ASCII character set.  An implementation that performs this
   mapping MUST restrict the allowed values for "name" to match the
   restrictions of ifName.

So basically
NEW:
  leaf location {
         type string;
         description
           "The system location. In most cases, the "location" of an "interface" entry 
           is mapped to sysLocation. sysLocation is defined as a DisplayString [RFC2579] 
           which uses a 7-bit ASCII character set. An implementation that performs this
           mapping MUST restrict the allowed values for "location" to match the
           restrictions of sysLocation.";
         reference
           "RFC 3418: Management Information Base (MIB) for the
                      Simple Network Management Protocol (SNMP)
                      SNMPv2-MIB.sysLocation";
       }


-
+--rw system
      |  +--rw clock
      |  |  +--rw (timezone)?
      |  |     +--:(timezone-location)
      |  |     |  +--rw timezone-location?     ianatz:iana-timezone
      |  |     +--:(timezone-utc-offset)
      |  |        +--rw timezone-utc-offset?   int16
      |  +--rw ntp!
      |     +--rw enabled?   boolean

 leaf enabled {
           type boolean;
           default true;
           description
             "Indicates that the system should attempt
              to synchronize the system clock with an
              NTP server from the 'ntp/server' list.";
         }


How come that enabled is marked as optional while there is a default value? 
Aren't they slightly conflicting statements?
Disclaimer: no strong feeling about that one. 
 
- 
Do we need the NTP version, 3 or 4, as a config field?

Regards, Benoit (OPS AD)








      

    

    

  


--------------040007070204000300030804--

From bclaise@cisco.com  Mon Dec  9 08:22:04 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39481ADFCC for ; Mon,  9 Dec 2013 08:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.501
X-Spam-Level: 
X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH3T1nXhSVmQ for ; Mon,  9 Dec 2013 08:22:02 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2627A1ADFBE for ; Mon,  9 Dec 2013 08:22:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11961; q=dns/txt; s=iport; t=1386606116; x=1387815716; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=UMJ2urbwoJPmjdX76WtES6wP3PQNQ2VekKwtSD9PUnw=; b=Wp31ZLXni5QtBjhT1ANyaPx/WjJovuDfkf3FxzDOSj7A9DARuh/pcI5+ I5oJWJe/9uEz1DMqShRugnU85c0LOix61SgympqweSR7K/3sterGAM8or YdtqBe5DEZwvoiaBcycsB5A9EXAHJ9T/1ExxK86uaeNofg8VXJjEbqDD0 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FAOzspVKQ/khR/2dsb2JhbABZgwc4uRpOgS8WdIImAQEEAQEBawoRCyEWDwkDAgECARUwBg0GAgEBh34NwTkXjxeEMwOUMYNjgTCFFYtOgyo7
X-IronPort-AV: E=Sophos;i="4.93,858,1378857600"; d="scan'208,217";a="1916718"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 09 Dec 2013 16:21:55 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB9GLpte013738 for ; Mon, 9 Dec 2013 16:21:51 GMT
Message-ID: <52A5EE1F.7020902@cisco.com>
Date: Mon, 09 Dec 2013 17:21:51 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: NETMOD Working Group 
References: <52A5CCD2.7030903@cisco.com> <52A5EBA1.50802@cisco.com>
In-Reply-To: <52A5EBA1.50802@cisco.com>
Content-Type: multipart/alternative; boundary="------------060704080308050802080300"
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 16:22:05 -0000

This is a multi-part message in MIME format.
--------------060704080308050802080300
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

And one last I forgot.

I was confused by

      leaf-list search {
            type inet:domain-name;
            ordered-by user;
            description
              "An ordered list of domains to search when resolving
               a host name.";
          }

I could not get the link between the "search" and  "An ordered list of 
domains to search when resolving a host name."
I would have called that "domain" or "search-domain". I had to be 
pointed to the "search" keyword in the resolv.conf as a hint!
Might be worth changing the name or adding a sentence: "the search name 
comes from the search keyword in resolv.conf type in UNIX-like operating 
systems"

Regards, Benoit
> Dear authors,
> Here is my AD review.
>
> -
> exactly like indraft-ietf-netmod-interfaces-cfg  , which contains a summary table with MIB variable table, this document should contain a similar mapping table
> For example
>        +--rw system
>        |  +--rw contact?          string
>        |  +--rw hostname?         inet:domain-name
>        |  +--rw location?         string
>        +--ro system-state
>           +--ro platform
>              +--ro os-name?       string
>              +--ro os-release?    string
>              +--ro os-version?    string
>              +--ro machine?       string
>
> This maps to the system group MIB variables. Some leavs definitions already refer to some MIB variables: sysContact, sysLocation, etc.
> I understand the MIB variables don't map 1:1, but telling that
>              os-name        part of the sysDescr MIB variable
>              os-release     part of the sysDescr MIB variable
>              os-version     part of the sysDescr MIB variable
>              machine?       part of the sysDescr MIB variable
> ... is also useful info.
>
> Considering that NETCONF is now also used for monitoring, and that people were used to SNMP, such mapping tables would be a good practice in all NETMOD documents to help SNMP people/NMS make the transition.
> There might be some read-only MIB variables in the following RFCs:
> RFC 4668 RADIUS Authentication Client MIB
> RFC 4669 RADIUS Authentication Server MIB
> RFC 5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)
> ...
>
> So it needs a little bit of research, but shouldn't be too hard.
>
>
> -
>    leaf location {
>           type string;
>           description
>             "The system location. The server MAY restrict the size
>              and characters in order to maintain compatibility with
>              the sysLocation MIB object.";
>           reference
>             "RFC 3418  : Management Information Base (MIB) for the
>                        Simple Network Management Protocol (SNMP)
>                        SNMPv2-MIB.sysLocation";
>         }
>
> Question: do we want to be aligned with the leaf name logic inhttps://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/  ?
>
> leaf name {
>     ...
>     In most cases, the "name" of an "interface" entry is mapped to
>     ifName. ifName is defined as a DisplayString [RFC2579] which uses a
>     7-bit ASCII character set.  An implementation that performs this
>     mapping MUST restrict the allowed values for "name" to match the
>     restrictions of ifName.
>
> So basically
> NEW:
>    leaf location {
>           type string;
>           description
>             "The system location. In most cases, the "location" of an "interface" entry
>             is mapped to sysLocation. sysLocation is defined as a DisplayString [RFC2579]
>             which uses a 7-bit ASCII character set. An implementation that performs this
>             mapping MUST restrict the allowed values for "location" to match the
>             restrictions of sysLocation.";
>           reference
>             "RFC 3418  : Management Information Base (MIB) for the
>                        Simple Network Management Protocol (SNMP)
>                        SNMPv2-MIB.sysLocation";
>         }
>
>
> -
> +--rw system
>        |  +--rw clock
>        |  |  +--rw (timezone)?
>        |  |     +--:(timezone-location)
>        |  |     |  +--rw timezone-location?     ianatz:iana-timezone
>        |  |     +--:(timezone-utc-offset)
>        |  |        +--rw timezone-utc-offset?   int16
>        |  +--rw ntp!
>        |     +--rw enabled?   boolean
>
>   leaf enabled {
>             type boolean;
>             default true;
>             description
>               "Indicates that the system should attempt
>                to synchronize the system clock with an
>                NTP server from the 'ntp/server' list.";
>           }
>
>
> How come that enabled is marked as optional while there is a default value?
> Aren't they slightly conflicting statements?
> Disclaimer: no strong feeling about that one.
>   
> -
> Do we need the NTP version, 3 or 4, as a config field?
>
> Regards, Benoit (OPS AD)
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------060704080308050802080300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Dear all,

      

      And one last I forgot.

      

      I was confused by 

      
     leaf-list search {
           type inet:domain-name;
           ordered-by user;
           description
             "An ordered list of domains to search when resolving
              a host name.";
         }

      I could not get the link between the "search" and  "An ordered
      list of domains to search when resolving a host name."
      

      I would have called that "domain" or "search-domain". I had to be
      pointed to the "search" keyword in the resolv.conf as a hint!

      Might be worth changing the name or adding a sentence: "the search
      name comes from the search keyword in resolv.conf type in
      UNIX-like operating systems"

      

      Regards, Benoit

    

    

      
      Dear authors, 

      

        
Here is my AD review.

- 
exactly like in draft-ietf-netmod-interfaces-cfg, which contains a summary table with MIB variable table, this document should contain a similar mapping table
For example
      +--rw system
      |  +--rw contact?          string
      |  +--rw hostname?         inet:domain-name
      |  +--rw location?         string
      +--ro system-state
         +--ro platform
            +--ro os-name?       string
            +--ro os-release?    string
            +--ro os-version?    string
            +--ro machine?       string

This maps to the system group MIB variables. Some leavs definitions already refer to some MIB variables: sysContact, sysLocation, etc.
I understand the MIB variables don't map 1:1, but telling that 
            os-name        part of the sysDescr MIB variable
            os-release     part of the sysDescr MIB variable
            os-version     part of the sysDescr MIB variable
            machine?       part of the sysDescr MIB variable
... is also useful info.

Considering that NETCONF is now also used for monitoring, and that people were used to SNMP, such mapping tables would be a good practice in all NETMOD documents to help SNMP people/NMS make the transition.
There might be some read-only MIB variables in the following RFCs:
RFC 4668 RADIUS Authentication Client MIB
RFC 4669 RADIUS Authentication Server MIB 
RFC 5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)
...

So it needs a little bit of research, but shouldn't be too hard.


-
  leaf location {
         type string;
         description
           "The system location. The server MAY restrict the size
            and characters in order to maintain compatibility with
            the sysLocation MIB object.";
         reference
           "RFC 3418: Management Information Base (MIB) for the
                      Simple Network Management Protocol (SNMP)
                      SNMPv2-MIB.sysLocation";
       }

Question: do we want to be aligned with the leaf name logic in https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ ?

leaf name {
   ...
   In most cases, the "name" of an "interface" entry is mapped to
   ifName. ifName is defined as a DisplayString [RFC2579] which uses a
   7-bit ASCII character set.  An implementation that performs this
   mapping MUST restrict the allowed values for "name" to match the
   restrictions of ifName.

So basically
NEW:
  leaf location {
         type string;
         description
           "The system location. In most cases, the "location" of an "interface" entry 
           is mapped to sysLocation. sysLocation is defined as a DisplayString [RFC2579] 
           which uses a 7-bit ASCII character set. An implementation that performs this
           mapping MUST restrict the allowed values for "location" to match the
           restrictions of sysLocation.";
         reference
           "RFC 3418: Management Information Base (MIB) for the
                      Simple Network Management Protocol (SNMP)
                      SNMPv2-MIB.sysLocation";
       }


-
+--rw system
      |  +--rw clock
      |  |  +--rw (timezone)?
      |  |     +--:(timezone-location)
      |  |     |  +--rw timezone-location?     ianatz:iana-timezone
      |  |     +--:(timezone-utc-offset)
      |  |        +--rw timezone-utc-offset?   int16
      |  +--rw ntp!
      |     +--rw enabled?   boolean

 leaf enabled {
           type boolean;
           default true;
           description
             "Indicates that the system should attempt
              to synchronize the system clock with an
              NTP server from the 'ntp/server' list.";
         }


How come that enabled is marked as optional while there is a default value? 
Aren't they slightly conflicting statements?
Disclaimer: no strong feeling about that one. 
 
- 
Do we need the NTP version, 3 or 4, as a config field?

Regards, Benoit (OPS AD)








        

      

      

      

      

      

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


    

    

  


--------------060704080308050802080300--

From bclaise@cisco.com  Mon Dec  9 08:51:54 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588B41ADFDA for ; Mon,  9 Dec 2013 08:51:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F14EOSy2L-c7 for ; Mon,  9 Dec 2013 08:51:52 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5033C1ADFCD for ; Mon,  9 Dec 2013 08:51:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2186; q=dns/txt; s=iport; t=1386607907; x=1387817507; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=OiFYQyia8HlXmzWAroPlbaSF4nPCJDpurqkF9oVGYuA=; b=OcusK/T+hMj/9jFLyyFFB3txfodXbHisCTSTudmm3ZmPCuFD9kfa41c3 H5zSagdCfol13E1Zak405N0YnBEsCZ0KoUUje/VmCmK7ZnqlEQwCUSYZA ER4mNN66uBd6zDo7CahmyZ+waLsVnbHcHrsCoZPwt16UfdYTApcCe7mPx I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFAL/0pVKQ/khM/2dsb2JhbABZgwe7TxZ0gmRAPRYYAwIBAgFLDQgBAYd+ow2eQReTSgOYFIZFi06DKjs
X-IronPort-AV: E=Sophos;i="4.93,859,1378857600";  d="scan'208";a="1309055"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 09 Dec 2013 16:51:46 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB9GphL5021151 for ; Mon, 9 Dec 2013 16:51:43 GMT
Message-ID: <52A5F51E.2010705@cisco.com>
Date: Mon, 09 Dec 2013 17:51:42 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: NETMOD Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [netmod] AD review of draft-ietf-netmod-ip-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 16:51:54 -0000

Dear NETMOD WG,

Here is my AD review for draft-ietf-netmod-ip-cfg.
Nothing serious about this draft, but a couple of editorial changes could improve the draft.

-
draft-ietf-netmod-interfaces-cfg-14 abstract

    This document defines a YANG data model for the management of network
    interfaces.  It is expected that interface type specific data models
    augment the generic interfaces data model defined in this document.
    The data model includes configuration data and state data (status
    information and counters for the collection of statistics).


This draft draft-ietf-netmod-ip-cfg-11 abstract is a little light in comparison

Abstract

    This document defines a YANG data model for management of IP
    implementations.

You should express:
    The data model includes configuration data and state data (status
    information but no counters for the collection of statistics).


- Introduction

  Parameters to manage IP routing are defined in
    [I-D.ietf-netmod-routing-cfg].

This is maybe interesting, but it seems way more interesting to speak about the connection with
draft-ietf-netmod-interfaces-cfg, which is a normative reference.

-
add state data in the terminology

-
Below ...
    The data model defines two state containers per interface, "ipv4" and
    "ipv6", representing the IPv4 and IPv6 address families.  In each
    container, there is a leaf "forwarding" that indicates if IP packet
    forwarding is enabled on that interface.  In each container there is
    also a list of all addresses in use, and a list of known mappings
    from IP addresses to link-layer addresses.

... it might be interesting to add a sentence or two on the difference between the the /interfaces/ and /interfaces-state/.
At first glance they look similar, but there are not:
  * the origin has been added in multiple containers
  * the IPv6 status has been added (and not IPv4), because they're the SLAAC state
  * the IPv6 neighbor state has been added.

-
Appendix A.  Example: NETCONF  reply

You might want to mention that there are no neighbor for IPv4, or add one.

Regards, Benoit (OPS AD)






From iesg-secretary@ietf.org  Mon Dec  9 08:58:17 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C02A1AE000; Mon,  9 Dec 2013 08:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHBhdPRyb1QB; Mon,  9 Dec 2013 08:58:15 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F401ADFCD; Mon,  9 Dec 2013 08:58:15 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20131209165815.8332.83320.idtracker@ietfa.amsl.com>
Date: Mon, 09 Dec 2013 08:58:15 -0800
Cc: netmod@ietf.org
Subject: [netmod] Last Call:  (A YANG Data Model for Interface Management) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 16:58:17 -0000

The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'A YANG Data Model for Interface Management'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface type specific data models
   augment the generic interfaces data model defined in this document.
   The data model includes configuration data and state data (status
   information and counters for the collection of statistics).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ballot/


No IPR declarations have been submitted directly on this I-D.



From iesg-secretary@ietf.org  Mon Dec  9 08:59:41 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09111AE366; Mon,  9 Dec 2013 08:59:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B7U_GwEzjNg; Mon,  9 Dec 2013 08:59:40 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEF01ADFF5; Mon,  9 Dec 2013 08:59:40 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20131209165940.12331.80905.idtracker@ietfa.amsl.com>
Date: Mon, 09 Dec 2013 08:59:40 -0800
Cc: netmod@ietf.org
Subject: [netmod] Last Call:  (IANA Interface Type YANG Module) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 16:59:42 -0000

The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'IANA Interface Type YANG Module'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document defines the initial version of the iana-if-type YANG
   module.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/ballot/


No IPR declarations have been submitted directly on this I-D.



From randy_presuhn@mindspring.com  Mon Dec  9 11:40:48 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8954A1AE4E8 for ; Mon,  9 Dec 2013 11:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHEVnYGJ9-s8 for ; Mon,  9 Dec 2013 11:40:46 -0800 (PST)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id BB3941AE4E2 for ; Mon,  9 Dec 2013 11:40:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VS8V3O/4/i8kYSnwps/5mLU9o0yO/uFaEWPT/3CLrDRumQtQ5Y1YnU1uH5E7CAF0; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.51] (helo=mswamui-thinleaf.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Vq6h7-0006kd-ES; Mon, 09 Dec 2013 14:40:41 -0500
Received: from 76.254.54.123 by webmail.earthlink.net with HTTP; Mon, 9 Dec 2013 14:40:41 -0500
Message-ID: <16284021.1386618041338.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
Date: Mon, 9 Dec 2013 11:40:41 -0800 (GMT-08:00)
From: Randy Presuhn 
To: Benoit Claise , NETMOD Working Group 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb126d02d174379c25b0a064814b73383c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.51
X-Mailman-Approved-At: Mon, 09 Dec 2013 12:16:00 -0800
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 19:45:13 -0000

Hi -

>From: Benoit Claise 
>Sent: Dec 9, 2013 8:11 AM
>To: NETMOD Working Group 
>Subject: [netmod] AD review of draft-ietf-netmod-system-mgmt
...
>I understand the MIB variables don't map 1:1, but telling that
>             os-name        part of the sysDescr MIB variable
>             os-release     part of the sysDescr MIB variable
>             os-version     part of the sysDescr MIB variable
>             machine?       part of the sysDescr MIB variable
>... is also useful info.

Kinda sorta.  One *might* find os-name, os-release, and os-version
in sysDescr, but their presence is only a "should", and cannot be
relied upon.  Same goes for "machine" if one treats that as "hardware
type".

...
>NEW:
>   leaf location {
>          type string;
>          description
>            "The system location. In most cases, the "location" of an "interface" entry

This text is broken.  The "location" is *not* the location of an interface;
it is the location of the system.

>            is mapped to sysLocation. sysLocation is defined as a DisplayString [RFC2579]
>            which uses a 7-bit ASCII character set. An implementation that performs this
>            mapping MUST restrict the allowed values for "location" to match the
>            restrictions of sysLocation.";

I understand why folks might do this, but it still gives
me heartburn.  I believe it was a mistake when we failed
to extend the syntax of these MIB objects to permit
Unicode, and I believe it's a mistake to perpetuate the
limitation here. I recognize that this is a messy problem,
but surely we can do better than this, even if it's as
simple a hack as having "location" and "legacy-location".

Randy


From david.kessens@gmail.com  Mon Dec  9 14:25:38 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6981AE613 for ; Mon,  9 Dec 2013 14:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV3RUVjlo4NX for ; Mon,  9 Dec 2013 14:25:36 -0800 (PST)
Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 55D8F1AE607 for ; Mon,  9 Dec 2013 14:25:36 -0800 (PST)
Received: by mail-la0-f50.google.com with SMTP id el20so2061469lab.37 for ; Mon, 09 Dec 2013 14:25:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TMYiNXo7aPIuNLFxiDPD1Zj4D4wlaXeXSBVODiyKHAQ=; b=nka+qcJsqkQNDj3liCkcnuxwHRIEYq963dmHeBzt/nAj/bcmBwveXpRj8Kv4TftmKU AFsNlok7arNf3i18ob3OegMmVW0X7tCF/oYcYnk0GC6ur6cReS+lD/q68LtdXg/BWwuK XfY/z0eo7okmkWNiLM5rnzcBt/h/Uo2v9VuhkVCUI+g9FWSHBwWYUqgAT3cRestV1rgH o3d+3w6tM8nufrBNiYZMslz3AMcGD3bXtyKHYJBichDAavV1cMpXBpkjfr5ZmyX4rCnP XNJirHWNT05ReI1WsWh9FP2G+IDr1qAkqxDYIO3rA+b81sViUkc0p9qw0kqFJIOMljjM y3UQ==
MIME-Version: 1.0
X-Received: by 10.152.5.163 with SMTP id t3mr3594667lat.39.1386627930697; Mon, 09 Dec 2013 14:25:30 -0800 (PST)
Received: by 10.152.22.3 with HTTP; Mon, 9 Dec 2013 14:25:30 -0800 (PST)
Date: Mon, 9 Dec 2013 14:25:30 -0800
Message-ID: 
From: David Kessens 
To: netmod@ietf.org
Content-Type: multipart/alternative; boundary=089e01419e363eb29504ed217989
Subject: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 22:25:38 -0000

--089e01419e363eb29504ed217989
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I would hereby like to start a Last Call for:

http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-03

Please indicate your support by Dec 20, 2013. We appreciate any type of
feedback, from "I have read the document and I like it" to more lengthy
reviews and implementation reports.

Thanks!

David Kessens
co-chair netmod wg
---

--089e01419e363eb29504ed217989
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Hi,

I would hereby like to sta=
rt a Last Call for:=A0=A0=A0=A0=A0=A0 

http://tools.ietf.org/html/draft-ie=
tf-netmod-snmp-cfg-03

=A0=A0=A0 =A0
Please indicate your support by Dec 20, 2013. We appreciat=
e any type of
feedback, from "I have read the document and I like i=
t" to more lengthy
reviews and implementation reports.

Thank=
s!


David Kessens
co-chair netmod wg
---=A0 





--089e01419e363eb29504ed217989--

From randy_presuhn@mindspring.com  Mon Dec  9 15:58:03 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD9A1ADF9C for ; Mon,  9 Dec 2013 15:58:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-UKpj6F10XT for ; Mon,  9 Dec 2013 15:57:59 -0800 (PST)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 464791ADF95 for ; Mon,  9 Dec 2013 15:57:58 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=L/UW8POpPMXIKfQOA/aYTe0kPRUOvO5khTgc+ARZjF7chx9zWBu7t0QjOTUdTZob; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [76.254.54.123] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VqAi1-0005dv-7q; Mon, 09 Dec 2013 18:57:53 -0500
Message-ID: <006b01cef53a$addd68c0$6b01a8c0@oemcomputer>
From: "Randy Presuhn" 
To: "David Kessens" , 
References: 
Date: Mon, 9 Dec 2013 15:59:19 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb3cf24c7f1a2ffde716576eec9205bc2a350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 76.254.54.123
Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 09 Dec 2013 23:58:03 -0000

Hi -

> From: "David Kessens" 
> To: 
> Sent: Monday, December 09, 2013 2:25 PM
> Subject: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
...
> I would hereby like to start a Last Call for:
> 
> http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-03
> 
> Please indicate your support by Dec 20, 2013. We appreciate any type of
> feedback, from "I have read the document and I like it" to more lengthy
> reviews and implementation reports.

I haven't the time or interest to spend a lot of time on this, but a cursory
look at the VACM section leaves me quite concerned.


On page 49, the draft states:
             "VACM Groups.

              This data model has a different structure than the MIB.
              Groups are explicitly defined in this list, and group
              members are defined in the 'member' list (mapped to
              vacmSecurityToGroupTable), and access for the group is
              defined in the 'access' list (mapped to
              vacmAccessTable).";

It's not clear to me whether the Yang model can represent all valid
configurations of the MIB, and (see below) I have an uneasy feeling
that in some cases it cannot.   Constraints like "A certain combination 
of security-name and security-model MUST NOT be present in
more than one group" strongly suggest to me that this is a very
unnatural way of modeling this.   What is gained by making this
model substantially different from the resource being managed?

I recognize that the transactional model is different here, but I'm
also concerned how some VACM usage scenarios would play
out in this model.  Consider, for example, a routine task like
re-assigning a "user" (identified by a [SecurityModel, SecurityName]
tuple) from one group to another.  It's trivial and seamless in VACM
(simply set a new value to vacmGroupName) but it's unclear what
the recommended sequence of operations would be in this proposal.


On page 49, the draft states:

         list member {
             key "security-name";
             min-elements 1;
             description
               "A member of this VACM group. According to VACM, every
                group must have at least one member.

AFAICT, RFC 3415 contains no such statement, and there are legal
VACM configurations that seem at odds with it.  The notion of a
"member" of a group is only mentioned in passing, and in a set-
theoretical sense at that.  Consider the case where one or more
entries exist in the vacmAccessTable with an index of
vacmGroupName="foo", but no corresponding entries exist in
the vacmSecurityToGroupTable.  Such configurations are
explicitly supported by RFC 3415.


A quick look at the Security Considerations section leaves me even
more worried.   An important consideration in the design of the
VACM MIB was to be absolutely clear on the impact of the order
of operations on security so that, for example, provisioning access
permissions for a new user (or set of users) could be interrupted
without creating security holes.  This is an extension of my concern
about how trivial VACM operations could become quite elaborate in
this model.

Randy


From mbj@tail-f.com  Tue Dec 10 03:26:38 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DC91AD8F7 for ; Tue, 10 Dec 2013 03:26:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dHgNkV-XO2s for ; Tue, 10 Dec 2013 03:26:37 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id F32C21AD7C0 for ; Tue, 10 Dec 2013 03:26:36 -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 E01EF37C02B; Tue, 10 Dec 2013 12:26:30 +0100 (CET)
Date: Tue, 10 Dec 2013 12:26:30 +0100 (CET)
Message-Id: <20131210.122630.261274424571283115.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <52A5F51E.2010705@cisco.com>
References: <52A5F51E.2010705@cisco.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] AD review of draft-ietf-netmod-ip-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 11:26:38 -0000

Hi,

Benoit Claise  wrote:
> Dear NETMOD WG,
> 
> Here is my AD review for draft-ietf-netmod-ip-cfg.
> Nothing serious about this draft, but a couple of editorial changes
> could improve the draft.
> 
> -
> draft-ietf-netmod-interfaces-cfg-14 abstract
> 
>    This document defines a YANG data model for the management of network
>    interfaces.  It is expected that interface type specific data models
>    augment the generic interfaces data model defined in this document.
>    The data model includes configuration data and state data (status
>    information and counters for the collection of statistics).
> 
> 
> This draft draft-ietf-netmod-ip-cfg-11 abstract is a little light in
> comparison
> 
> Abstract
> 
>    This document defines a YANG data model for management of IP
>    implementations.
> 
> You should express:
>    The data model includes configuration data and state data (status
>    information but no counters for the collection of statistics).
> 
> 

Ok.  I'd prefer to mention what we do, and not what we don't do, so I
suggest:

NEW:

  This document defines a YANG data model for management of IP
  implementations.  The data model includes configuration data and
  state data.

> - Introduction
> 
>  Parameters to manage IP routing are defined in
>    [I-D.ietf-netmod-routing-cfg].
> 
> This is maybe interesting, but it seems way more interesting to speak
> about the connection with
> draft-ietf-netmod-interfaces-cfg, which is a normative reference.

I agree.  So remove the reference to routing:

OLD:

The data model covers configuration of per-interface IPv4 and IPv6
parameters, and mappings of IP addresses to link-layer addresses.  It
also provides information about which IP addresses are operationally
used, and which link-layer mappings exist.

Parameters to manage IP routing are defined in
^I-D.ietf-netmod-routing-cfg^.


NEW:

The data model covers configuration of per-interface IPv4 and IPv6
parameters, and mappings of IP addresses to link-layer addresses.  It
also provides information about which IP addresses are operationally
used, and which link-layer mappings exist.  Per-interface parameters
are added through augmentation of the interface data model defined in
^I-D-ietf-netmod-interfaces-cfg^.

> -
> add state data in the terminology

Ok.

> -
> Below ...
>    The data model defines two state containers per interface, "ipv4" and
>    "ipv6", representing the IPv4 and IPv6 address families.  In each
>    container, there is a leaf "forwarding" that indicates if IP packet
>    forwarding is enabled on that interface.  In each container there is
>    also a list of all addresses in use, and a list of known mappings
>    from IP addresses to link-layer addresses.
> 
> ... it might be interesting to add a sentence or two on the difference
> between the the /interfaces/ and /interfaces-state/.
> At first glance they look similar, but there are not:
>  * the origin has been added in multiple containers
>  * the IPv6 status has been added (and not IPv4), because they're the
>  * SLAAC state
>  * the IPv6 neighbor state has been added.

I am not sure that this is the right way to view these structures.
They have very different semantics; which is why they are separate.
One is the "manual config", and the other one reflects what is
currently in operational use.  So I do not know what/if to add.


> -
> Appendix A.  Example: NETCONF  reply
> 
> You might want to mention that there are no neighbor for IPv4, or add
> one.

Ok, I'll add one.


/martin

From bclaise@cisco.com  Tue Dec 10 03:42:35 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680651ADBCB for ; Tue, 10 Dec 2013 03:42:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.501
X-Spam-Level: 
X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwSPYu7RMMPn for ; Tue, 10 Dec 2013 03:42:33 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8661AD8E1 for ; Tue, 10 Dec 2013 03:42:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1853; q=dns/txt; s=iport; t=1386675748; x=1387885348; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=IKp8V6dNyvS3S/oGbftM/I2h7fKqXrnfY3GULsPZjhc=; b=WJS5CQneKLQ4udgZ7S2QNreOwwu4cH8E1BTNiuzkWBjctOrST0ycqo4s bXzkKKS9r3kaHbB9l00fTqhOcgIGLSf9B3RhQgjJShCUOjN4mp2DbjMYu FE2ZViWqsUE45ZXEjqYkbOe8vJpVJ3yAmAk4K0G57d6eys1XarwJqfPxS 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjMFAMz9plKQ/khN/2dsb2JhbABZgwc4iS+vcU6BHxZ0giYBAQQBAQFrChELBAEcFg8JAwIBAgEVMAYNBgIBAYd+DcBiEwSPDIQzA5gUhkWLToMqOw
X-IronPort-AV: E=Sophos;i="4.93,865,1378857600"; d="scan'208,217";a="1954894"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 10 Dec 2013 11:42:27 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBABgNJU011983 for ; Tue, 10 Dec 2013 11:42:24 GMT
Message-ID: <52A6FE1F.9060507@cisco.com>
Date: Tue, 10 Dec 2013 12:42:23 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: NETMOD Working Group 
References: <52A5CCD2.7030903@cisco.com> <52A5EBA1.50802@cisco.com>
In-Reply-To: <52A5EBA1.50802@cisco.com>
Content-Type: multipart/alternative; boundary="------------050802050809080601010309"
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 11:42:35 -0000

This is a multi-part message in MIME format.
--------------050802050809080601010309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Answering my own question:
- Do we need the NTP version, 3 or 4, as a config field?

Did some investigations.
Apparently it's not needed because there is an indication of the version 
during the NTP message exchange.

Regards, Benoit

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


--------------050802050809080601010309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Dear all,

    

    Answering my own question:

    - Do we need the NTP version, 3 or 4, as a config field?

    

    Did some investigations.

    Apparently it's not needed because there is an indication of the
    version during the NTP message exchange.

    

    Regards, Benoit

     

    

      
 

      

      

      

      

      

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


    

    

  


--------------050802050809080601010309--

From mbj@tail-f.com  Tue Dec 10 04:18:46 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D921AE01E for ; Tue, 10 Dec 2013 04:18:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.497
X-Spam-Level: *
X-Spam-Status: No, score=1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_45=0.6, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQFVhJDvpJ0s for ; Tue, 10 Dec 2013 04:18:45 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id A418B1ADF5E for ; Tue, 10 Dec 2013 04:18:44 -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 9FF2B37C02A; Tue, 10 Dec 2013 13:18:38 +0100 (CET)
Date: Tue, 10 Dec 2013 13:18:38 +0100 (CET)
Message-Id: <20131210.131838.821365541466219199.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <52A5EBA1.50802@cisco.com>
References: <52A5CCD2.7030903@cisco.com> <52A5EBA1.50802@cisco.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 12:18:46 -0000

Benoit Claise  wrote:
> Dear authors,
> 
> Here is my AD review.
> 
> -
> exactly like indraft-ietf-netmod-interfaces-cfg
> ,
> which contains a summary table with MIB variable table, this document
> should contain a similar mapping table
> For example
>       +--rw system
>       |  +--rw contact?          string
>       |  +--rw hostname?         inet:domain-name
>       |  +--rw location?         string
>       +--ro system-state
>          +--ro platform
>             +--ro os-name?       string
>             +--ro os-release?    string
>             +--ro os-version?    string
>             +--ro machine?       string
> 
> This maps to the system group MIB variables. Some leavs definitions
> already refer to some MIB variables: sysContact, sysLocation, etc.
> I understand the MIB variables don't map 1:1, but telling that
>             os-name        part of the sysDescr MIB variable
>             os-release     part of the sysDescr MIB variable
>             os-version     part of the sysDescr MIB variable
>             machine?       part of the sysDescr MIB variable
> ... is also useful info.

For the 1-1 mapped object, we'll have this table:

                  +----------------+-------------------+
                  | YANG data node | SNMPv2-MIB object |
                  +----------------+-------------------+
                  | contact        | sysContact        |
                  | location       | sysLocation       |
                  +----------------+-------------------+


> Considering that NETCONF is now also used for monitoring, and that
> people were used to SNMP, such mapping tables would be a good practice
> in all NETMOD documents to help SNMP people/NMS make the transition.
> There might be some read-only MIB variables in the following RFCs:
> RFC 4668 RADIUS Authentication Client MIB

Our model provides parameters for configuring the radius client; this
MIB has objects for read-only monitoring.   The config objects affect
what is operationally used, but there is no 1-1 mapping.  The "related"
objects are:

 radius/server/transport/udp/udp/address
                 radiusAuthServerInetAddressType
                 radiusAuthServerInetAddress

 radius/server/transport/udp/udp/authentication-port
                 radiusAuthClientServerInetPortNumber

But I am not sure that listing these adds any value...?

> RFC 4669 RADIUS Authentication Server MIB

This is not applicable; we don't have any parameters for RADIUS
servers.

> RFC 5907 Definitions of Managed Objects for Network Time Protocol
> Version 4 (NTPv4)

Same situation as for the radius client.

> ...
> 
> So it needs a little bit of research, but shouldn't be too hard.
> 
> 
> -
>   leaf location {
>          type string;
>          description
>            "The system location. The server MAY restrict the size
>             and characters in order to maintain compatibility with
>             the sysLocation MIB object.";
>          reference
>            "RFC 3418 : Management
>            Information Base (MIB) for the
>                       Simple Network Management Protocol (SNMP)
>                       SNMPv2-MIB.sysLocation";
>        }
> 
> Question: do we want to be aligned with the leaf name logic
> inhttps://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ ?
> 
> leaf name {
>    ...
>    In most cases, the "name" of an "interface" entry is mapped to
>    ifName. ifName is defined as a DisplayString [RFC2579] which uses a
>    7-bit ASCII character set.  An implementation that performs this
>    mapping MUST restrict the allowed values for "name" to match the
>    restrictions of ifName.
> 
> So basically
> NEW:
>   leaf location {
>          type string;
>          description
>            "The system location. In most cases, the "location" of an
>            "interface" entry
>            is mapped to sysLocation. sysLocation is defined as a DisplayString
>            [RFC2579]
>            which uses a 7-bit ASCII character set. An implementation that
>            performs this
>            mapping MUST restrict the allowed values for "location" to match
>            the
>            restrictions of sysLocation.";
>          reference
>            "RFC 3418 : Management
>            Information Base (MIB) for the
>                       Simple Network Management Protocol (SNMP)
>                       SNMPv2-MIB.sysLocation";
>        }

As Randy pointed out, the text above has some copy&paste errors.

OLD:

         The server MAY restrict the size and characters in
         order to maintain compatibility with the sysContact
         MIB object.";

NEW:

         This leaf MAY be mapped to the sysContact MIB object by an
         implementation.  Such an implementation MUST restrict the
         allowed values for this leaf so that it matches the
         restrictions of sysContact."

... but I am not convinced the new text is better than the old.  If
you think it is, I am fine with adding it.

(and same for location).



> +--rw system
>       |  +--rw clock
>       |  |  +--rw (timezone)?
>       |  |     +--:(timezone-location)
>       |  |     |  +--rw timezone-location?     ianatz:iana-timezone
>       |  |     +--:(timezone-utc-offset)
>       |  |        +--rw timezone-utc-offset?   int16
>       |  +--rw ntp!
>       |     +--rw enabled?   boolean
> 
>  leaf enabled {
>            type boolean;
>            default true;
>            description
>              "Indicates that the system should attempt
>               to synchronize the system clock with an
>               NTP server from the 'ntp/server' list.";
>          }
> 
> 
> How come that enabled is marked as optional while there is a default
> value?
> Aren't they slightly conflicting statements?
> Disclaimer: no strong feeling about that one.

It is optional to set for the client.

>  -
> Do we need the NTP version, 3 or 4, as a config field?

I saw that you answered this one yourself!


/martin

From mbj@tail-f.com  Tue Dec 10 04:23:36 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC981ADFA2 for ; Tue, 10 Dec 2013 04:23:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iGA_E3bo_uW for ; Tue, 10 Dec 2013 04:23:36 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 06D9C1ADEB7 for ; Tue, 10 Dec 2013 04:23:36 -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 6FAFB37C02A; Tue, 10 Dec 2013 13:23:30 +0100 (CET)
Date: Tue, 10 Dec 2013 13:23:30 +0100 (CET)
Message-Id: <20131210.132330.264841086201302929.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund 
In-Reply-To: <16284021.1386618041338.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
References: <16284021.1386618041338.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 12:23:36 -0000

Randy Presuhn  wrote:
> Hi -
> 
> >From: Benoit Claise 
> >
> >            is mapped to sysLocation. sysLocation is defined as a
> >            DisplayString [RFC2579]
> >            which uses a 7-bit ASCII character set. An implementation that
> >            performs this
> >            mapping MUST restrict the allowed values for "location" to match
> >            the
> >            restrictions of sysLocation.";
> 
> I understand why folks might do this, but it still gives
> me heartburn.  I believe it was a mistake when we failed
> to extend the syntax of these MIB objects to permit
> Unicode, and I believe it's a mistake to perpetuate the
> limitation here. I recognize that this is a messy problem,
> but surely we can do better than this, even if it's as
> simple a hack as having "location" and "legacy-location".

I don't think it makes much sense to have two such similar objects in
this data model.

One option would be to simply remove the connection between
sysLocation and this new location leaf (and same for contact),
essentially making the snmp object the "legacy" object.


/martin



From j.schoenwaelder@jacobs-university.de  Tue Dec 10 04:50:59 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CC81AE078 for ; Tue, 10 Dec 2013 04:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buD1kngC6os6 for ; Tue, 10 Dec 2013 04:50:57 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 03FA91AE080 for ; Tue, 10 Dec 2013 04:50:57 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7661820074; Tue, 10 Dec 2013 13:50:51 +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 QyKHl9njGBww; Tue, 10 Dec 2013 13:50:51 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 757EC20062; Tue, 10 Dec 2013 13:50:50 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 27E0929F7EE2; Tue, 10 Dec 2013 13:50:42 +0100 (CET)
Date: Tue, 10 Dec 2013 13:50:41 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20131210125041.GA72958@elstar.local>
Mail-Followup-To: Martin Bjorklund , randy_presuhn@mindspring.com, netmod@ietf.org
References: <16284021.1386618041338.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> <20131210.132330.264841086201302929.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131210.132330.264841086201302929.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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 Dec 2013 12:50:59 -0000

On Tue, Dec 10, 2013 at 01:23:30PM +0100, Martin Bjorklund wrote:
> Randy Presuhn  wrote:
> > Hi -
> > 
> > >From: Benoit Claise 
> > >
> > >            is mapped to sysLocation. sysLocation is defined as a
> > >            DisplayString [RFC2579]
> > >            which uses a 7-bit ASCII character set. An implementation that
> > >            performs this
> > >            mapping MUST restrict the allowed values for "location" to match
> > >            the
> > >            restrictions of sysLocation.";
> > 
> > I understand why folks might do this, but it still gives
> > me heartburn.  I believe it was a mistake when we failed
> > to extend the syntax of these MIB objects to permit
> > Unicode, and I believe it's a mistake to perpetuate the
> > limitation here. I recognize that this is a messy problem,
> > but surely we can do better than this, even if it's as
> > simple a hack as having "location" and "legacy-location".
> 
> I don't think it makes much sense to have two such similar objects in
> this data model.
> 
> One option would be to simply remove the connection between
> sysLocation and this new location leaf (and same for contact),
> essentially making the snmp object the "legacy" object.

Another option is to turn the logic around. That is, if there is a
non-ASCII character in the YANG object, the mapping to the
corresponding MIB object must take precautions to comply with the MIB
restrictions (e.g., representing the non-ASCII character using \u and
\U escape sequences). The mapping to the MIB object would also have to
do proper truncations. The details of the mapping I assume would be
implementation specific.

This approach allows us to move to a unicode-based world rather than
carrying old ASCII restrictions forward endlessly (which is what I
think Randy is concerned about).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From mbj@tail-f.com  Tue Dec 10 10:22:24 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3151AE040 for ; Tue, 10 Dec 2013 10:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDjrFxOojYMr for ; Tue, 10 Dec 2013 10:22:22 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C8B571ADFA6 for ; Tue, 10 Dec 2013 10:22:21 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id EF704240C047; Tue, 10 Dec 2013 19:22:14 +0100 (CET)
Date: Tue, 10 Dec 2013 19:22:14 +0100 (CET)
Message-Id: <20131210.192214.326782560.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20131210125041.GA72958@elstar.local>
References: <16284021.1386618041338.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> <20131210.132330.264841086201302929.mbj@tail-f.com> <20131210125041.GA72958@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 18:22:24 -0000

Juergen Schoenwaelder  wrote:
> On Tue, Dec 10, 2013 at 01:23:30PM +0100, Martin Bjorklund wrote:
> > Randy Presuhn  wrote:
> > > Hi -
> > > 
> > > >From: Benoit Claise 
> > > >
> > > >            is mapped to sysLocation. sysLocation is defined as a
> > > >            DisplayString [RFC2579]
> > > >            which uses a 7-bit ASCII character set. An implementation that
> > > >            performs this
> > > >            mapping MUST restrict the allowed values for "location" to
> > > >            match
> > > >            the
> > > >            restrictions of sysLocation.";
> > > 
> > > I understand why folks might do this, but it still gives
> > > me heartburn.  I believe it was a mistake when we failed
> > > to extend the syntax of these MIB objects to permit
> > > Unicode, and I believe it's a mistake to perpetuate the
> > > limitation here. I recognize that this is a messy problem,
> > > but surely we can do better than this, even if it's as
> > > simple a hack as having "location" and "legacy-location".
> > 
> > I don't think it makes much sense to have two such similar objects in
> > this data model.
> > 
> > One option would be to simply remove the connection between
> > sysLocation and this new location leaf (and same for contact),
> > essentially making the snmp object the "legacy" object.
> 
> Another option is to turn the logic around. That is, if there is a
> non-ASCII character in the YANG object, the mapping to the
> corresponding MIB object must take precautions to comply with the MIB
> restrictions (e.g., representing the non-ASCII character using \u and
> \U escape sequences). The mapping to the MIB object would also have to
> do proper truncations. The details of the mapping I assume would be
> implementation specific.

An implementation MUST NOT restrict?  Note that the current text
simply says MAY restrict.

> This approach allows us to move to a unicode-based world rather than
> carrying old ASCII restrictions forward endlessly (which is what I
> think Randy is concerned about).


/martin

From randy_presuhn@mindspring.com  Tue Dec 10 10:55:38 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1851AE077 for ; Tue, 10 Dec 2013 10:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00IjrH7FFKeR for ; Tue, 10 Dec 2013 10:55:36 -0800 (PST)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 222B31AE0E0 for ; Tue, 10 Dec 2013 10:55:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sOeFjJamAj55Hf1oRyEGeCXlmw2pHd/nSl9cWzsCH8fLZkC1rMWmBeepdvosqhZq; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VqSSu-00074X-CI; Tue, 10 Dec 2013 13:55:28 -0500
Received: from 76.254.54.123 by webmail.earthlink.net with HTTP; Tue, 10 Dec 2013 13:55:28 -0500
Message-ID: <12817633.1386701728243.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
Date: Tue, 10 Dec 2013 10:55:28 -0800 (GMT-08:00)
From: Randy Presuhn 
To: Juergen Schoenwaelder ,  Martin Bjorklund 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb8991f18ca1a45ea86846ba2c55e18067350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.36
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 18:55:38 -0000

Hi -

>From: Juergen Schoenwaelder 
>Sent: Dec 10, 2013 4:50 AM
>To: Martin Bjorklund 
>Cc: randy_presuhn@mindspring.com, netmod@ietf.org
>Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
>On Tue, Dec 10, 2013 at 01:23:30PM +0100, Martin Bjorklund wrote:
>> Randy Presuhn  wrote:
>> > Hi -
>> > 
>> > >From: Benoit Claise 
>> > >
>> > >            is mapped to sysLocation. sysLocation is defined as a
>> > >            DisplayString [RFC2579]
>> > >            which uses a 7-bit ASCII character set. An implementation that
>> > >            performs this
>> > >            mapping MUST restrict the allowed values for "location" to match
>> > >            the
>> > >            restrictions of sysLocation.";
>> > 
>> > I understand why folks might do this, but it still gives
>> > me heartburn.  I believe it was a mistake when we failed
>> > to extend the syntax of these MIB objects to permit
>> > Unicode, and I believe it's a mistake to perpetuate the
>> > limitation here. I recognize that this is a messy problem,
>> > but surely we can do better than this, even if it's as
>> > simple a hack as having "location" and "legacy-location".
>> 
>> I don't think it makes much sense to have two such similar objects in
>> this data model.
>> 
>> One option would be to simply remove the connection between
>> sysLocation and this new location leaf (and same for contact),
>> essentially making the snmp object the "legacy" object.
>
>Another option is to turn the logic around. That is, if there is a
>non-ASCII character in the YANG object, the mapping to the
>corresponding MIB object must take precautions to comply with the MIB
>restrictions (e.g., representing the non-ASCII character using \u and
>\U escape sequences). The mapping to the MIB object would also have to
>do proper truncations. The details of the mapping I assume would be
>implementation specific.
>
>This approach allows us to move to a unicode-based world rather than
>carrying old ASCII restrictions forward endlessly (which is what I
>think Randy is concerned about).

I really like this idea, though I'm not sure which of the various
ways of doing escape sequences would be most helpful.  For example,
the &#mumble; convention of HTML would also be a possibility.  But
whatever the mechanism, I think something like this would be a huge
win.  (Note that there are obnoxious corner cases, such as the SNMP
interface being used to configure an sequence which would, if interpreted
as an escape, result in a forbidden or impossible code point.)  Still,
I really like this idea.

Randy

From randy_presuhn@mindspring.com  Tue Dec 10 11:07:20 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994571AE03C for ; Tue, 10 Dec 2013 11:07:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL2QMrhADljG for ; Tue, 10 Dec 2013 11:07:18 -0800 (PST)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 532491ADFDA for ; Tue, 10 Dec 2013 11:07:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RUntPY2q+J8V6d1e2ziVAupmWBBZPyeMVEgkG1Cyx2zyMxQsrNkkgc970t+Pokvs; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VqSeG-0002ms-D6 for netmod@ietf.org; Tue, 10 Dec 2013 14:07:12 -0500
Received: from 76.254.54.123 by webmail.earthlink.net with HTTP; Tue, 10 Dec 2013 14:07:11 -0500
Message-ID: <848296.1386702432191.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
Date: Tue, 10 Dec 2013 11:07:12 -0800 (GMT-08:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbd6e12a9db077b0e62286cd77112faf56350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.36
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 19:07:20 -0000

Hi -

>From: Randy Presuhn 
>Sent: Dec 10, 2013 10:55 AM
>To: Juergen Schoenwaelder , Martin Bjorklund 
>Cc: randy_presuhn@mindspring.com, netmod@ietf.org
>Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
...
>I really like this idea, though I'm not sure which of the various
>ways of doing escape sequences would be most helpful.  For example,
>the &#mumble; convention of HTML would also be a possibility.  But
>whatever the mechanism, I think something like this would be a huge
>win.  (Note that there are obnoxious corner cases, such as the SNMP
>interface being used to configure an sequence which would, if interpreted
>as an escape, result in a forbidden or impossible code point.)  Still,
>I really like this idea.

To elaborate slightly: I like this idea as the basis for
a standardized approach (*not* merely a "MAY") to be used
whenever practical for migrating ASCII-only SNMP objects
intended for human consumption.

Randy

From mbj@tail-f.com  Tue Dec 10 11:42:58 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FFD1AE211 for ; Tue, 10 Dec 2013 11:42:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptX84G0n90UT for ; Tue, 10 Dec 2013 11:42:57 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49D1ADFF5 for ; Tue, 10 Dec 2013 11:42:57 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 76759240C0C2; Tue, 10 Dec 2013 20:42:50 +0100 (CET)
Date: Tue, 10 Dec 2013 20:42:49 +0100 (CET)
Message-Id: <20131210.204249.358076643.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund 
In-Reply-To: <848296.1386702432191.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
References: <848296.1386702432191.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 19:42:58 -0000

Randy Presuhn  wrote:
> Hi -
> 
> >From: Randy Presuhn 
> >Sent: Dec 10, 2013 10:55 AM
> >To: Juergen Schoenwaelder , Martin
> >Bjorklund 
> >Cc: randy_presuhn@mindspring.com, netmod@ietf.org
> >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> ...
> >I really like this idea, though I'm not sure which of the various
> >ways of doing escape sequences would be most helpful.  For example,
> >the &#mumble; convention of HTML would also be a possibility.  But
> >whatever the mechanism, I think something like this would be a huge
> >win.  (Note that there are obnoxious corner cases, such as the SNMP
> >interface being used to configure an sequence which would, if interpreted
> >as an escape, result in a forbidden or impossible code point.)  Still,
> >I really like this idea.
> 
> To elaborate slightly: I like this idea as the basis for
> a standardized approach (*not* merely a "MAY") to be used
> whenever practical for migrating ASCII-only SNMP objects
> intended for human consumption.

Do you think the same applies to ifAlias?  I don't know if it is too
late to change that object though.


/martin


From randy_presuhn@mindspring.com  Tue Dec 10 11:44:38 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFD21AE1BA for ; Tue, 10 Dec 2013 11:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKb2n__SDZCk for ; Tue, 10 Dec 2013 11:44:36 -0800 (PST)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 21CBC1AE232 for ; Tue, 10 Dec 2013 11:44:36 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sgHP6eH8+vlql4gntDTjgbu5RkfRi1doskDrJIqv6Dks4MP7Xc9U9kljIZu1M4fx; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VqTEC-00045a-Co; Tue, 10 Dec 2013 14:44:20 -0500
Received: from 76.254.54.123 by webmail.earthlink.net with HTTP; Tue, 10 Dec 2013 14:44:20 -0500
Message-ID: <17758395.1386704660388.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
Date: Tue, 10 Dec 2013 11:44:20 -0800 (GMT-08:00)
From: Randy Presuhn 
To: Martin Bjorklund 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb20ad90e6f8f03a1f0e69c2bdd7ae66d2350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.36
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 19:44:38 -0000

Hi -

>From: Martin Bjorklund 
>Sent: Dec 10, 2013 11:42 AM
>To: randy_presuhn@mindspring.com
>Cc: netmod@ietf.org
>Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
>Randy Presuhn  wrote:
>> Hi -
>> 
>> >From: Randy Presuhn 
>> >Sent: Dec 10, 2013 10:55 AM
>> >To: Juergen Schoenwaelder , Martin
>> >Bjorklund 
>> >Cc: randy_presuhn@mindspring.com, netmod@ietf.org
>> >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>> ...
>> >I really like this idea, though I'm not sure which of the various
>> >ways of doing escape sequences would be most helpful.  For example,
>> >the &#mumble; convention of HTML would also be a possibility.  But
>> >whatever the mechanism, I think something like this would be a huge
>> >win.  (Note that there are obnoxious corner cases, such as the SNMP
>> >interface being used to configure an sequence which would, if interpreted
>> >as an escape, result in a forbidden or impossible code point.)  Still,
>> >I really like this idea.
>> 
>> To elaborate slightly: I like this idea as the basis for
>> a standardized approach (*not* merely a "MAY") to be used
>> whenever practical for migrating ASCII-only SNMP objects
>> intended for human consumption.
>
>Do you think the same applies to ifAlias?  I don't know if it is too
>late to change that object though.

Yes.  (Probably for both questions.)

Randy

From j.schoenwaelder@jacobs-university.de  Tue Dec 10 11:58:00 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738AF1ADFD6 for ; Tue, 10 Dec 2013 11:58:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNbS5ad8rxVv for ; Tue, 10 Dec 2013 11:57:57 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 21CC81ADEC8 for ; Tue, 10 Dec 2013 11:57:57 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6773820085; Tue, 10 Dec 2013 20:57:50 +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 6qCNGPikeMqA; Tue, 10 Dec 2013 20:57:50 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C422F2006F; Tue, 10 Dec 2013 20:57:49 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 829EB29F90A0; Tue, 10 Dec 2013 20:57:45 +0100 (CET)
Date: Tue, 10 Dec 2013 20:57:45 +0100
From: Juergen Schoenwaelder 
To: Randy Presuhn 
Message-ID: <20131210195745.GA74616@elstar.local>
Mail-Followup-To: Randy Presuhn , Martin Bjorklund , netmod@ietf.org
References: <12817633.1386701728243.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <12817633.1386701728243.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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 Dec 2013 19:58:00 -0000

On Tue, Dec 10, 2013 at 10:55:28AM -0800, Randy Presuhn wrote:

> >Another option is to turn the logic around. That is, if there is a
> >non-ASCII character in the YANG object, the mapping to the
> >corresponding MIB object must take precautions to comply with the MIB
> >restrictions (e.g., representing the non-ASCII character using \u and
> >\U escape sequences). The mapping to the MIB object would also have to
> >do proper truncations. The details of the mapping I assume would be
> >implementation specific.
> >
> >This approach allows us to move to a unicode-based world rather than
> >carrying old ASCII restrictions forward endlessly (which is what I
> >think Randy is concerned about).
> 
> I really like this idea, though I'm not sure which of the various
> ways of doing escape sequences would be most helpful.  For example,
> the &#mumble; convention of HTML would also be a possibility.  But
> whatever the mechanism, I think something like this would be a huge
> win.  (Note that there are obnoxious corner cases, such as the SNMP
> interface being used to configure an sequence which would, if interpreted
> as an escape, result in a forbidden or impossible code point.)  Still,
> I really like this idea.
>
> To elaborate slightly: I like this idea as the basis for
> a standardized approach (*not* merely a "MAY") to be used
> whenever practical for migrating ASCII-only SNMP objects
> intended for human consumption.

I am sure we discussed this option back in a day and I am sure there
were people who said that an SNMP agent could store something that may
accidentally now might look like an escaped unicode sequence but it
was not intended to be one. And there might be interesting
interactions with the size (length) restriction. Such thinking will
force the conclusion that neither the HTML convention nor the \u
convention can be used. So the only alternative is to use one of the
25 ASCII code points as an escape character that per RFC 2579 have no
meaning in a DisplayString, e.g. ESC (ASCII code 0x1b). While this
approach avoids any conflicts, it leads to a very SNMP specific
solution, which is not commonly understood and needs special
processing by both machines and human brains. But then, SNMP would
only add a little bit more to the noise out there already:

http://billposer.org/Software/ListOfRepresentations.html

Anyway, for a standardized approach, someone would have to write a
document that defines how unicode code points are represented as
escaped charater sequences in DisplayStrings. I do not think that this
document is in charge of doing this. Hence, until such a standard is
written, I think things need to be implementation specific.

/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 Dec 10 12:29:26 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013021AE20B for ; Tue, 10 Dec 2013 12:29:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ici2nqmIglC9 for ; Tue, 10 Dec 2013 12:29:22 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 379A01AE1F2 for ; Tue, 10 Dec 2013 12:29:22 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6B012008D; Tue, 10 Dec 2013 21:29:15 +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 8iTn3t9wAAYo; Tue, 10 Dec 2013 21:29:15 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 295C420075; Tue, 10 Dec 2013 21:29:15 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id ACDA329F9175; Tue, 10 Dec 2013 21:29:11 +0100 (CET)
Date: Tue, 10 Dec 2013 21:29:11 +0100
From: Juergen Schoenwaelder 
To: Randy Presuhn 
Message-ID: <20131210202911.GA74654@elstar.local>
Mail-Followup-To: Randy Presuhn , David Kessens , netmod@ietf.org
References:  <006b01cef53a$addd68c0$6b01a8c0@oemcomputer>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <006b01cef53a$addd68c0$6b01a8c0@oemcomputer>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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 Dec 2013 20:29:26 -0000

On Mon, Dec 09, 2013 at 03:59:19PM -0800, Randy Presuhn wrote:
> Hi -
> 
> > From: "David Kessens" 
> > To: 
> > Sent: Monday, December 09, 2013 2:25 PM
> > Subject: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> ...
> > I would hereby like to start a Last Call for:
> > 
> > http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-03
> > 
> > Please indicate your support by Dec 20, 2013. We appreciate any type of
> > feedback, from "I have read the document and I like it" to more lengthy
> > reviews and implementation reports.
> 
> I haven't the time or interest to spend a lot of time on this, but a cursory
> look at the VACM section leaves me quite concerned.
> 
> 
> On page 49, the draft states:
>              "VACM Groups.
> 
>               This data model has a different structure than the MIB.
>               Groups are explicitly defined in this list, and group
>               members are defined in the 'member' list (mapped to
>               vacmSecurityToGroupTable), and access for the group is
>               defined in the 'access' list (mapped to
>               vacmAccessTable).";
> 
> It's not clear to me whether the Yang model can represent all valid
> configurations of the MIB, and (see below) I have an uneasy feeling
> that in some cases it cannot.   Constraints like "A certain combination 
> of security-name and security-model MUST NOT be present in
> more than one group" strongly suggest to me that this is a very
> unnatural way of modeling this.   What is gained by making this
> model substantially different from the resource being managed?

The cited constraint "A certain combination of security-name and
security-model MUST NOT be present in more than one group." comes from
the way the VACM tables are organized. The vacmSecurityToGroupTable
table is indexed by (vacmSecurityModel, vacmSecurityName). We are
simply documenting a VACM constraint.

What is gained by the model layout? Groups become a first class
citizen and members are naturally assigned to groups and most
importantly you do not have to perform a join of several tables in
order to understand the access policy of a certain group. With SNMP,
the editing semantics cause a table organization that seems more
complex than needed and that have certain side effects.
 
> I recognize that the transactional model is different here, but I'm
> also concerned how some VACM usage scenarios would play
> out in this model.  Consider, for example, a routine task like
> re-assigning a "user" (identified by a [SecurityModel, SecurityName]
> tuple) from one group to another.  It's trivial and seamless in VACM
> (simply set a new value to vacmGroupName) but it's unclear what
> the recommended sequence of operations would be in this proposal.

You delete the user form one group and at the same time add it to the
target group. This feels quite natural and NETCONF can do such changes
in an atomic edit-config.
 
> On page 49, the draft states:
> 
>          list member {
>              key "security-name";
>              min-elements 1;
>              description
>                "A member of this VACM group. According to VACM, every
>                 group must have at least one member.
> 
> AFAICT, RFC 3415 contains no such statement, and there are legal
> VACM configurations that seem at odds with it.  The notion of a
> "member" of a group is only mentioned in passing, and in a set-
> theoretical sense at that.

The question is what really defines a group in VACM. Section 7.2. says:

   [...] Within the View-Based Access Control Model, a groupName is
   considered to exist if that groupName is listed in the
   vacmSecurityToGroupTable.

In order to be listed in the vacmSecurityToGroupTable, the group must
have a member (since the vacmSecurityName is part of the INDEX). Hence
the above statement.

> Consider the case where one or more entries exist in the
> vacmAccessTable with an index of vacmGroupName="foo", but no
> corresponding entries exist in the vacmSecurityToGroupTable.  Such
> configurations are explicitly supported by RFC 3415.

We could easily allow for that as well by removing "According to VACM,
every group must have at least one member.".

> A quick look at the Security Considerations section leaves me even
> more worried.   An important consideration in the design of the
> VACM MIB was to be absolutely clear on the impact of the order
> of operations on security so that, for example, provisioning access
> permissions for a new user (or set of users) could be interrupted
> without creating security holes.  This is an extension of my concern
> about how trivial VACM operations could become quite elaborate in
> this model.

I have re-read the Security Considerations section and I am not sure
what makes you worried regarding order of operations and such things.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From randy_presuhn@mindspring.com  Tue Dec 10 13:16:50 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB151AE1F5 for ; Tue, 10 Dec 2013 13:16:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level: 
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcEFClwMd0yy for ; Tue, 10 Dec 2013 13:16:47 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id B7B281AE04B for ; Tue, 10 Dec 2013 13:16:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MPS7xVYIe9nCi1Njss12b7PzpJIaQqWxMyQlKx+scDVX57J0NrCyR91zEcHglEtY; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [76.254.54.123] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VqUfZ-0001Ds-AO for netmod@ietf.org; Tue, 10 Dec 2013 16:16:41 -0500
Message-ID: <001001cef5ed$54d320e0$6b01a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
References: <12817633.1386701728243.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> <20131210195745.GA74616@elstar.local>
Date: Tue, 10 Dec 2013 13:18:10 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb5e81f228aa40fedeccbc69d588185cf9350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 76.254.54.123
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 21:16:50 -0000

Hi -

> From: "Juergen Schoenwaelder" 
> To: "Randy Presuhn" 
> Cc: "Martin Bjorklund" ; 
> Sent: Tuesday, December 10, 2013 11:57 AM
> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt


...
> I am sure we discussed this option back in a day and I am sure there
> were people who said that an SNMP agent could store something that may
> accidentally now might look like an escaped unicode sequence but it
> was not intended to be one. And there might be interesting
> interactions with the size (length) restriction. Such thinking will
> force the conclusion that neither the HTML convention nor the \u
> convention can be used. So the only alternative is to use one of the
> 25 ASCII code points as an escape character that per RFC 2579 have no
> meaning in a DisplayString, e.g. ESC (ASCII code 0x1b).

Nope.  The escaped sequence is still longer, so the length-based
rationale doesn't work.

> approach avoids any conflicts, it leads to a very SNMP specific
> solution, which is not commonly understood and needs special
> processing by both machines and human brains. But then, SNMP would
> only add a little bit more to the noise out there already:
 
> http://billposer.org/Software/ListOfRepresentations.html

Whatever is easy, if not trivial to support with the scripting tools used by
operators would probably the best bet.  A C-like \u or HTML-like
&# convention is probably a really good bet.  I think the HTML escapes
might be less dangerous than the C-like ones (considering exotic formatting
capabilities), but am not married to one or the other.

> Anyway, for a standardized approach, someone would have to write a
> document that defines how unicode code points are represented as
> escaped charater sequences in DisplayStrings. I do not think that this
> document is in charge of doing this. Hence, until such a standard is
> written, I think things need to be implementation specific.

Perhaps, though that is the route to being stuck with ASCII until the
successor to Netconf rolls along.

Randy


From mbj@tail-f.com  Tue Dec 10 13:24:55 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089811AE16E for ; Tue, 10 Dec 2013 13:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level: 
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E91_YoPbaZSM for ; Tue, 10 Dec 2013 13:24:53 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 372A71AE04B for ; Tue, 10 Dec 2013 13:24:53 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 0E417240C080; Tue, 10 Dec 2013 22:24:46 +0100 (CET)
Date: Tue, 10 Dec 2013 22:24:45 +0100 (CET)
Message-Id: <20131210.222445.216011946.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20131210195745.GA74616@elstar.local>
References: <12817633.1386701728243.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> <20131210195745.GA74616@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 21:24:55 -0000

Juergen Schoenwaelder  wrote:
> On Tue, Dec 10, 2013 at 10:55:28AM -0800, Randy Presuhn wrote:
> 
> > >Another option is to turn the logic around. That is, if there is a
> > >non-ASCII character in the YANG object, the mapping to the
> > >corresponding MIB object must take precautions to comply with the MIB
> > >restrictions (e.g., representing the non-ASCII character using \u and
> > >\U escape sequences). The mapping to the MIB object would also have to
> > >do proper truncations. The details of the mapping I assume would be
> > >implementation specific.
> > >
> > >This approach allows us to move to a unicode-based world rather than
> > >carrying old ASCII restrictions forward endlessly (which is what I
> > >think Randy is concerned about).
> > 
> > I really like this idea, though I'm not sure which of the various
> > ways of doing escape sequences would be most helpful.  For example,
> > the &#mumble; convention of HTML would also be a possibility.  But
> > whatever the mechanism, I think something like this would be a huge
> > win.  (Note that there are obnoxious corner cases, such as the SNMP
> > interface being used to configure an sequence which would, if interpreted
> > as an escape, result in a forbidden or impossible code point.)  Still,
> > I really like this idea.
> >
> > To elaborate slightly: I like this idea as the basis for
> > a standardized approach (*not* merely a "MAY") to be used
> > whenever practical for migrating ASCII-only SNMP objects
> > intended for human consumption.
> 
> I am sure we discussed this option back in a day and I am sure there
> were people who said that an SNMP agent could store something that may
> accidentally now might look like an escaped unicode sequence but it
> was not intended to be one. And there might be interesting
> interactions with the size (length) restriction. Such thinking will
> force the conclusion that neither the HTML convention nor the \u
> convention can be used. So the only alternative is to use one of the
> 25 ASCII code points as an escape character that per RFC 2579 have no
> meaning in a DisplayString, e.g. ESC (ASCII code 0x1b). While this
> approach avoids any conflicts, it leads to a very SNMP specific
> solution, which is not commonly understood and needs special
> processing by both machines and human brains. But then, SNMP would
> only add a little bit more to the noise out there already:
> 
> http://billposer.org/Software/ListOfRepresentations.html
> 
> Anyway, for a standardized approach, someone would have to write a
> document that defines how unicode code points are represented as
> escaped charater sequences in DisplayStrings. I do not think that this
> document is in charge of doing this. Hence, until such a standard is
> written, I think things need to be implementation specific.

So what is the proposal?  All implementations MUST allow arbitrary
strings, and implementations that map this to the SNMP object MUST be
careful...?

My original idea was that implementations should be free to either
restrict the values to match the DisplayString, or do some
implemenation-specific translation.  From -00:

              This leaf MAY be mapped to ifAlias by an implementation.
              Such an implementation MAY restrict the length of the
              value of this leaf so that it matches the restrictions
              of ifAlias.

But the WG decided that the current specified behavior was more
correct.



/martin

From randy_presuhn@mindspring.com  Tue Dec 10 14:10:51 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564DF1AE053 for ; Tue, 10 Dec 2013 14:10:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYZxdfk98-GX for ; Tue, 10 Dec 2013 14:10:48 -0800 (PST)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 15F131AE06D for ; Tue, 10 Dec 2013 14:10:47 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lPOfkAJfajGrwAD5tWgyqBcBGXUl6100Jks2CWz6HY3b6XV9VW9sF9k58SsEk1IA; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [76.254.54.123] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VqVVo-0005Fn-GQ; Tue, 10 Dec 2013 17:10:41 -0500
Message-ID: <001701cef5f4$dfa6d0c0$6b01a8c0@oemcomputer>
From: "Randy Presuhn" 
To: "Juergen Schoenwaelder" 
References:  <006b01cef53a$addd68c0$6b01a8c0@oemcomputer> <20131210202911.GA74654@elstar.local>
Date: Tue, 10 Dec 2013 14:12:09 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb8bd28168aac867c9a4810f8076e42e0f350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 76.254.54.123
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Dec 2013 22:10:51 -0000

Hi -

> From: "Juergen Schoenwaelder" 
> To: "Randy Presuhn" 
> Cc: "David Kessens" ; 
> Sent: Tuesday, December 10, 2013 12:29 PM
> Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
>

> On Mon, Dec 09, 2013 at 03:59:19PM -0800, Randy Presuhn wrote:
> > Hi -
> > 
> > > From: "David Kessens" 
> > > To: 
> > > Sent: Monday, December 09, 2013 2:25 PM
> > > Subject: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> > ...
> > > I would hereby like to start a Last Call for:
> > > 
> > > http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-03
> > > 
> > > Please indicate your support by Dec 20, 2013. We appreciate any type of
> > > feedback, from "I have read the document and I like it" to more lengthy
> > > reviews and implementation reports.
> > 
> > I haven't the time or interest to spend a lot of time on this, but a cursory
> > look at the VACM section leaves me quite concerned.
> > 
> > 
> > On page 49, the draft states:
> >              "VACM Groups.
> > 
> >               This data model has a different structure than the MIB.
> >               Groups are explicitly defined in this list, and group
> >               members are defined in the 'member' list (mapped to
> >               vacmSecurityToGroupTable), and access for the group is
> >               defined in the 'access' list (mapped to
> >               vacmAccessTable).";
> > 
> > It's not clear to me whether the Yang model can represent all valid
> > configurations of the MIB, and (see below) I have an uneasy feeling
> > that in some cases it cannot.   Constraints like "A certain combination 
> > of security-name and security-model MUST NOT be present in
> > more than one group" strongly suggest to me that this is a very
> > unnatural way of modeling this.   What is gained by making this
> > model substantially different from the resource being managed?
> 
> The cited constraint "A certain combination of security-name and
> security-model MUST NOT be present in more than one group." comes from
> the way the VACM tables are organized. The vacmSecurityToGroupTable
> table is indexed by (vacmSecurityModel, vacmSecurityName). We are
> simply documenting a VACM constraint.

I understand that the constraint is a consequence of VACM's indexing
structure (and a logical requirement for non-ambiguity).  My point is
that in the Yang model (1) the reason for such a constraint becomes
non-obvious and (2) it has implications for operations like changing
a user's group membership.

> What is gained by the model layout? Groups become a first class
> citizen and members are naturally assigned to groups and most
> importantly you do not have to perform a join of several tables in
> order to understand the access policy of a certain group. With SNMP,
> the editing semantics cause a table organization that seems more
> complex than needed and that have certain side effects.

The structural change comes with what to me seems an important
semantic change.    In VACM, a "user" ([securityLevel,securityName]
tuple) is associated with a group whose members should enjoy the
same access permissions, and that association is easily changed
by the security administrator.  In the propose Yang model, what
was merely an associated becomes a *structural* "element-of"
relationship.

In VACM, the administrator may delete the group, but leave
the "members" in place (though deletion of the group means
a categorical "access-denied" for those "orphaned" members.)
Not possible in the Yang model.

> > I recognize that the transactional model is different here, but I'm
> > also concerned how some VACM usage scenarios would play
> > out in this model.  Consider, for example, a routine task like
> > re-assigning a "user" (identified by a [SecurityModel, SecurityName]
> > tuple) from one group to another.  It's trivial and seamless in VACM
> > (simply set a new value to vacmGroupName) but it's unclear what
> > the recommended sequence of operations would be in this proposal.
> 
> You delete the user form one group and at the same time add it to the
> target group. This feels quite natural and NETCONF can do such changes
> in an atomic edit-config.

Requiring deletion of a user in order to change access permissions seems
odd.  Yes, it would work, but it seems very unnatural to me.  I guess it
depends on how one thinks about this stuff.
  
> > On page 49, the draft states:
> > 
> >          list member {
> >              key "security-name";
> >              min-elements 1;
> >              description
> >                "A member of this VACM group. According to VACM, every
> >                 group must have at least one member.
> > 
> > AFAICT, RFC 3415 contains no such statement, and there are legal
> > VACM configurations that seem at odds with it.  The notion of a
> > "member" of a group is only mentioned in passing, and in a set-
> > theoretical sense at that.
> 
> The question is what really defines a group in VACM. Section 7.2. says:
> 
>    [...] Within the View-Based Access Control Model, a groupName is
>    considered to exist if that groupName is listed in the
>    vacmSecurityToGroupTable.
> 
> In order to be listed in the vacmSecurityToGroupTable, the group must
> have a member (since the vacmSecurityName is part of the INDEX). Hence
> the above statement.

Ok, I see how you came to that understanding, though FWIW that text was
put there to explain the behaviour of the ASI "noGroupName" status.

When I think about "groups", I generally have in mind the set of
vacmAccessTable entries with the same vacmGroupName, and
when I think about "members", it's the set of vacmSecurityToGroupTable
entries with a matching value of vacmGroupName.

In *that* frame of reference (which more closely maps to what I'd
expect a user interface to present) it's perfectly reasonable to talk
about a group with no members.

Thus my example:

> > Consider the case where one or more entries exist in the
> > vacmAccessTable with an index of vacmGroupName="foo", but no
> > corresponding entries exist in the vacmSecurityToGroupTable.  Such
> > configurations are explicitly supported by RFC 3415.
> 
> We could easily allow for that as well by removing "According to VACM,
> every group must have at least one member.".

That would be fine with me.
 
> > A quick look at the Security Considerations section leaves me even
> > more worried.   An important consideration in the design of the
> > VACM MIB was to be absolutely clear on the impact of the order
> > of operations on security so that, for example, provisioning access
> > permissions for a new user (or set of users) could be interrupted
> > without creating security holes.  This is an extension of my concern
> > about how trivial VACM operations could become quite elaborate in
> > this model.
> 
> I have re-read the Security Considerations section and I am not sure
> what makes you worried regarding order of operations and such things.

Simple example.  Consider an access control policy expressed in the
vacmViewTreeFamilyTable containing entries with overlapping
vacmViewTreeFamilySubtree / vacmViewTreeFamilyMask and
vacmViewTreeFamilyType values of both included(1) and excluded(2).

There are lots of ways to formulate the constraints on how to "safely"
bring such a policy into being, but in general one needs to ensure that
any given "excluded" entry is put into service no earlier than any
"included" entry that would overlap that portion of the OID tree.
The Netconf user must ensure that "commits" don't happen in a
way that would defeat this, and the implementation, in its interface
into VACM, needs to make sure that however it causes the MIB
updates to happen honors these constraints as well.

Another example: security administrator updating his/her own
group membership. (Analogous to a sysadmin conscientiously
using "su" only when absolutely necessary.)  If this becomes a
"delete-and-re-instantiate" operation with netconf, then the
instrumentation needs to be done in such a way that the
delete/create is somehow interpreted to be a single MIB
attribute write.  (If it is blindly mapped to a delete/create
cycle internally, then there need to be sufficient protections
in place so that, for example, power fail immediately after delete
doesn't leave the administrator locked out.)

Perhaps all this is blindingly obvious to implementors, in which
case the document doesn't need to mention it.

Randy


From j.schoenwaelder@jacobs-university.de  Wed Dec 11 00:38:55 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46A1AE20A for ; Wed, 11 Dec 2013 00:38:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mAhKzmru7WV for ; Wed, 11 Dec 2013 00:38: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 2ACB41ADF63 for ; Wed, 11 Dec 2013 00:38:52 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 59DBE20075; Wed, 11 Dec 2013 09:38:46 +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 fc9lBJN096vL; Wed, 11 Dec 2013 09:38: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 59E9820035; Wed, 11 Dec 2013 09:38:45 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id EF15429FA119; Wed, 11 Dec 2013 09:38:39 +0100 (CET)
Date: Wed, 11 Dec 2013 09:38:39 +0100
From: Juergen Schoenwaelder 
To: Randy Presuhn 
Message-ID: <20131211083837.GA76435@elstar.local>
Mail-Followup-To: Randy Presuhn , netmod@ietf.org
References: <12817633.1386701728243.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> <20131210195745.GA74616@elstar.local> <001001cef5ed$54d320e0$6b01a8c0@oemcomputer>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001001cef5ed$54d320e0$6b01a8c0@oemcomputer>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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 Dec 2013 08:38:55 -0000

On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
 
> > Anyway, for a standardized approach, someone would have to write a
> > document that defines how unicode code points are represented as
> > escaped charater sequences in DisplayStrings. I do not think that this
> > document is in charge of doing this. Hence, until such a standard is
> > written, I think things need to be implementation specific.
> 
> Perhaps, though that is the route to being stuck with ASCII until the
> successor to Netconf rolls along.

Not necessarily. If you configure via NETCONF (or most CLIs these
days), you can use unicode characters. The code that maps names to
legacy non-unicode interfaces then needs to do suitable translations
to fit whatever constraint there is.

If someone configures via legacy non-unicode interfaces, well then
there is no unicode in the configured names. I do not think we can fix
that problem. This requires to change the legacy non-unicode
interfaces, which I think is not the task of this WG.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From bclaise@cisco.com  Wed Dec 11 08:20:36 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9891AE09E for ; Wed, 11 Dec 2013 08:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.901
X-Spam-Level: 
X-Spam-Status: No, score=-8.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXpugRigMI1Q for ; Wed, 11 Dec 2013 08:20:33 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id A86431AE078 for ; Wed, 11 Dec 2013 08:20:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16520; q=dns/txt; s=iport; t=1386778827; x=1387988427; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=zWEiuu0Cxr1qi0TJeE2LoKDDHAq1uvtYzezM8GwcpaQ=; b=VEx4LpdaKJxJLsMr3VM107CG5Qm0EbfNnpkkthUn0blYxnfWFwl6rWPU iGyADX8uABUXfKrRJyYXSToYl8KqBEfzTFvm146jczO9X3eQ924VDDFOB Fykia728tMb067JwAQJ6gjRnmoU2iYZGdHuCFyWfpoSVq0F2rcXMcoxql w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8FAPaPqFKQ/khL/2dsb2JhbABZgwc4iTOwOYEdFnSCJQEBAQMBeAEQCw4KCRYPCQMCAQIBRQYNAQUCAQGHeAYNwgcXjiYRAVAHCYQrBJQxg2OBMIUVi06DKjuBNQ
X-IronPort-AV: E=Sophos;i="4.93,872,1378857600"; d="scan'208,217";a="1411980"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 11 Dec 2013 16:20:26 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBBGKJMj027423; Wed, 11 Dec 2013 16:20:20 GMT
Message-ID: <52A890C3.3020504@cisco.com>
Date: Wed, 11 Dec 2013 17:20:19 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Martin Bjorklund 
References: <52A5CCD2.7030903@cisco.com>	<52A5EBA1.50802@cisco.com> <20131210.131838.821365541466219199.mbj@tail-f.com>
In-Reply-To: <20131210.131838.821365541466219199.mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="------------060307010800090403060207"
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 16:20:36 -0000

This is a multi-part message in MIME format.
--------------060307010800090403060207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Martin,
> Benoit Claise  wrote:
>> Dear authors,
>>
>> Here is my AD review.
>>
>> -
>> exactly like indraft-ietf-netmod-interfaces-cfg
>> ,
>> which contains a summary table with MIB variable table, this document
>> should contain a similar mapping table
>> For example
>>        +--rw system
>>        |  +--rw contact?          string
>>        |  +--rw hostname?         inet:domain-name
>>        |  +--rw location?         string
>>        +--ro system-state
>>           +--ro platform
>>              +--ro os-name?       string
>>              +--ro os-release?    string
>>              +--ro os-version?    string
>>              +--ro machine?       string
>>
>> This maps to the system group MIB variables. Some leavs definitions
>> already refer to some MIB variables: sysContact, sysLocation, etc.
>> I understand the MIB variables don't map 1:1, but telling that
>>              os-name        part of the sysDescr MIB variable
>>              os-release     part of the sysDescr MIB variable
>>              os-version     part of the sysDescr MIB variable
>>              machine?       part of the sysDescr MIB variable
>> ... is also useful info.
> For the 1-1 mapped object, we'll have this table:
>
>                    +----------------+-------------------+
>                    | YANG data node | SNMPv2-MIB object |
>                    +----------------+-------------------+
>                    | contact        | sysContact        |
>                    | location       | sysLocation       |
>                    +----------------+-------------------+
>
>
>> Considering that NETCONF is now also used for monitoring, and that
>> people were used to SNMP, such mapping tables would be a good practice
>> in all NETMOD documents to help SNMP people/NMS make the transition.
>> There might be some read-only MIB variables in the following RFCs:
>> RFC 4668 RADIUS Authentication Client MIB
> Our model provides parameters for configuring the radius client; this
> MIB has objects for read-only monitoring.   The config objects affect
> what is operationally used, but there is no 1-1 mapping.  The "related"
> objects are:
>
>   radius/server/transport/udp/udp/address
>                   radiusAuthServerInetAddressType
>                   radiusAuthServerInetAddress
>
>   radius/server/transport/udp/udp/authentication-port
>                   radiusAuthClientServerInetPortNumber
>
> But I am not sure that listing these adds any value...?
If there is no 1:1 mapping, that's different.
Up to you to mention a sentence such as:

    The YANG module provides parameters for configuring the radius client; the
    RFC 4668 RADIUS Authentication Client MIB has objects for read-only monitoring.
    There is no 1-1 mapping between the YANG module and MIB module objects.
    The "related" objects are:

      radius/server/transport/udp/udp/address
                      radiusAuthServerInetAddressType
                      radiusAuthServerInetAddress

      radius/server/transport/udp/udp/authentication-port
                      radiusAuthClientServerInetPortNumber


>
>> RFC 4669 RADIUS Authentication Server MIB
> This is not applicable; we don't have any parameters for RADIUS
> servers.
>
>> RFC 5907 Definitions of Managed Objects for Network Time Protocol
>> Version 4 (NTPv4)
> Same situation as for the radius client.
>
>> ...
>>
>> So it needs a little bit of research, but shouldn't be too hard.
>>
>>
>> -
>>    leaf location {
>>           type string;
>>           description
>>             "The system location. The server MAY restrict the size
>>              and characters in order to maintain compatibility with
>>              the sysLocation MIB object.";
>>           reference
>>             "RFC 3418 : Management
>>             Information Base (MIB) for the
>>                        Simple Network Management Protocol (SNMP)
>>                        SNMPv2-MIB.sysLocation";
>>         }
>>
>> Question: do we want to be aligned with the leaf name logic
>> inhttps://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ ?
>>
>> leaf name {
>>     ...
>>     In most cases, the "name" of an "interface" entry is mapped to
>>     ifName. ifName is defined as a DisplayString [RFC2579] which uses a
>>     7-bit ASCII character set.  An implementation that performs this
>>     mapping MUST restrict the allowed values for "name" to match the
>>     restrictions of ifName.
>>
>> So basically
>> NEW:
>>    leaf location {
>>           type string;
>>           description
>>             "The system location. In most cases, the "location" of an
>>             "interface" entry
>>             is mapped to sysLocation. sysLocation is defined as a DisplayString
>>             [RFC2579]
>>             which uses a 7-bit ASCII character set. An implementation that
>>             performs this
>>             mapping MUST restrict the allowed values for "location" to match
>>             the
>>             restrictions of sysLocation.";
>>           reference
>>             "RFC 3418 : Management
>>             Information Base (MIB) for the
>>                        Simple Network Management Protocol (SNMP)
>>                        SNMPv2-MIB.sysLocation";
>>         }
> As Randy pointed out, the text above has some copy&paste errors.
>
> OLD:
>
>           The server MAY restrict the size and characters in
>           order to maintain compatibility with the sysContact
>           MIB object.";
>
> NEW:
>
>           This leaf MAY be mapped to the sysContact MIB object by an
>           implementation.  Such an implementation MUST restrict the
>           allowed values for this leaf so that it matches the
>           restrictions of sysContact."
>
> ... but I am not convinced the new text is better than the old.  If
> you think it is, I am fine with adding it.
>
> (and same for location).
Let's follow up in the other email thread.
>
>
>
>> +--rw system
>>        |  +--rw clock
>>        |  |  +--rw (timezone)?
>>        |  |     +--:(timezone-location)
>>        |  |     |  +--rw timezone-location?     ianatz:iana-timezone
>>        |  |     +--:(timezone-utc-offset)
>>        |  |        +--rw timezone-utc-offset?   int16
>>        |  +--rw ntp!
>>        |     +--rw enabled?   boolean
>>
>>   leaf enabled {
>>             type boolean;
>>             default true;
>>             description
>>               "Indicates that the system should attempt
>>                to synchronize the system clock with an
>>                NTP server from the 'ntp/server' list.";
>>           }
>>
>>
>> How come that enabled is marked as optional while there is a default
>> value?
>> Aren't they slightly conflicting statements?
>> Disclaimer: no strong feeling about that one.
> It is optional to set for the client.
ok

Regards, Benoit
>
>>   -
>> Do we need the NTP version, 3 or 4, as a config field?
> I saw that you answered this one yourself!
>
>
> /martin
> .
>


--------------060307010800090403060207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Martin,

    

    

      
Benoit Claise <bclaise@cisco.com> wrote:


      

        
Dear authors,

Here is my AD review.

-
exactly like indraft-ietf-netmod-interfaces-cfg
<https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/>,
which contains a summary table with MIB variable table, this document
should contain a similar mapping table
For example
      +--rw system
      |  +--rw contact?          string
      |  +--rw hostname?         inet:domain-name
      |  +--rw location?         string
      +--ro system-state
         +--ro platform
            +--ro os-name?       string
            +--ro os-release?    string
            +--ro os-version?    string
            +--ro machine?       string

This maps to the system group MIB variables. Some leavs definitions
already refer to some MIB variables: sysContact, sysLocation, etc.
I understand the MIB variables don't map 1:1, but telling that
            os-name        part of the sysDescr MIB variable
            os-release     part of the sysDescr MIB variable
            os-version     part of the sysDescr MIB variable
            machine?       part of the sysDescr MIB variable
... is also useful info.


      

      
For the 1-1 mapped object, we'll have this table:

                  +----------------+-------------------+
                  | YANG data node | SNMPv2-MIB object |
                  +----------------+-------------------+
                  | contact        | sysContact        |
                  | location       | sysLocation       |
                  +----------------+-------------------+




      

        
Considering that NETCONF is now also used for monitoring, and that
people were used to SNMP, such mapping tables would be a good practice
in all NETMOD documents to help SNMP people/NMS make the transition.
There might be some read-only MIB variables in the following RFCs:
RFC 4668 RADIUS Authentication Client MIB


      

      
Our model provides parameters for configuring the radius client; this
MIB has objects for read-only monitoring.   The config objects affect
what is operationally used, but there is no 1-1 mapping.  The "related"
objects are:

 radius/server/transport/udp/udp/address
                 radiusAuthServerInetAddressType
                 radiusAuthServerInetAddress

 radius/server/transport/udp/udp/authentication-port
                 radiusAuthClientServerInetPortNumber

But I am not sure that listing these adds any value...?

    

    If there is no 1:1 mapping, that's different.

    Up to you to mention a sentence such as:

    

      
The YANG module provides parameters for configuring the radius client; the 
RFC 4668 RADIUS Authentication Client MIB has objects for read-only monitoring. 
There is no 1-1 mapping between the YANG module and MIB module objects.
The "related" objects are:

 radius/server/transport/udp/udp/address
                 radiusAuthServerInetAddressType
                 radiusAuthServerInetAddress

 radius/server/transport/udp/udp/authentication-port
                 radiusAuthClientServerInetPortNumber

    

    

    

      



      

        
RFC 4669 RADIUS Authentication Server MIB


      

      
This is not applicable; we don't have any parameters for RADIUS
servers.



      

        
RFC 5907 Definitions of Managed Objects for Network Time Protocol
Version 4 (NTPv4)


      

      
Same situation as for the radius client.



      

        
...

So it needs a little bit of research, but shouldn't be too hard.


-
  leaf location {
         type string;
         description
           "The system location. The server MAY restrict the size
            and characters in order to maintain compatibility with
            the sysLocation MIB object.";
         reference
           "RFC 3418 <http://tools.ietf.org/html/rfc3418>: Management
           Information Base (MIB) for the
                      Simple Network Management Protocol (SNMP)
                      SNMPv2-MIB.sysLocation";
       }

Question: do we want to be aligned with the leaf name logic
inhttps://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ ?

leaf name {
   ...
   In most cases, the "name" of an "interface" entry is mapped to
   ifName. ifName is defined as a DisplayString [RFC2579] which uses a
   7-bit ASCII character set.  An implementation that performs this
   mapping MUST restrict the allowed values for "name" to match the
   restrictions of ifName.

So basically
NEW:
  leaf location {
         type string;
         description
           "The system location. In most cases, the "location" of an
           "interface" entry
           is mapped to sysLocation. sysLocation is defined as a DisplayString
           [RFC2579]
           which uses a 7-bit ASCII character set. An implementation that
           performs this
           mapping MUST restrict the allowed values for "location" to match
           the
           restrictions of sysLocation.";
         reference
           "RFC 3418 <http://tools.ietf.org/html/rfc3418>: Management
           Information Base (MIB) for the
                      Simple Network Management Protocol (SNMP)
                      SNMPv2-MIB.sysLocation";
       }


      

      
As Randy pointed out, the text above has some copy&paste errors.

OLD:

         The server MAY restrict the size and characters in
         order to maintain compatibility with the sysContact
         MIB object.";

NEW:

         This leaf MAY be mapped to the sysContact MIB object by an
         implementation.  Such an implementation MUST restrict the
         allowed values for this leaf so that it matches the
         restrictions of sysContact."

... but I am not convinced the new text is better than the old.  If
you think it is, I am fine with adding it.

(and same for location).

    

    Let's follow up in the other email thread.

    

      





      

        
+--rw system
      |  +--rw clock
      |  |  +--rw (timezone)?
      |  |     +--:(timezone-location)
      |  |     |  +--rw timezone-location?     ianatz:iana-timezone
      |  |     +--:(timezone-utc-offset)
      |  |        +--rw timezone-utc-offset?   int16
      |  +--rw ntp!
      |     +--rw enabled?   boolean

 leaf enabled {
           type boolean;
           default true;
           description
             "Indicates that the system should attempt
              to synchronize the system clock with an
              NTP server from the 'ntp/server' list.";
         }


How come that enabled is marked as optional while there is a default
value?
Aren't they slightly conflicting statements?
Disclaimer: no strong feeling about that one.


      

      
It is optional to set for the client.

    

    ok

    

    Regards, Benoit

    

      



      

        
 -
Do we need the NTP version, 3 or 4, as a config field?


      

      
I saw that you answered this one yourself!


/martin
.



    

    

  


--------------060307010800090403060207--

From bclaise@cisco.com  Wed Dec 11 08:26:29 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49651A1F5D for ; Wed, 11 Dec 2013 08:26:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ezwMSVecYVMy for ; Wed, 11 Dec 2013 08:26:27 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 480FD1ADFCA for ; Wed, 11 Dec 2013 08:26:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1913; q=dns/txt; s=iport; t=1386779181; x=1387988781; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Z1U6vP0ujL3jI96tkCi7AtjTa622XVjBPAXiwEamGdI=; b=IyAYGBFY7ebfmphSEhQYGsH8uyD4cu1lP4mSVc3hWyMJKihhKi0yLN7a N7a7ZevLFEHF6E/WZs8QNyTQlip+VeUX8L4b+LJt0XUQUEISu6I4brO6N oQETmq3ZaLdkDK6RFnXX8T4jbDpa8m8V9f977ir5jIny6MZEL+0k9lVM9 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAGqRqFKQ/khN/2dsb2JhbABZgweEDrYWgR0WdIIlAQEBBCMVQBELEQQBAQMCBRYLAgIJAwIBAgE9CAYBDAYCAQGHfrI/j0YXgSmNZoJsgUgEmBSGRYtOgyo7
X-IronPort-AV: E=Sophos;i="4.93,872,1378857600";  d="scan'208";a="2020762"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 11 Dec 2013 16:26:20 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBBGQDPF007339; Wed, 11 Dec 2013 16:26:15 GMT
Message-ID: <52A89224.5070709@cisco.com>
Date: Wed, 11 Dec 2013 17:26:12 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Randy Presuhn , NETMOD Working Group 
References: <16284021.1386618041338.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
In-Reply-To: <16284021.1386618041338.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 16:26:30 -0000

Randy,
> Hi -
>
>> From: Benoit Claise 
>> Sent: Dec 9, 2013 8:11 AM
>> To: NETMOD Working Group 
>> Subject: [netmod] AD review of draft-ietf-netmod-system-mgmt
> ...
>> I understand the MIB variables don't map 1:1, but telling that
>>              os-name        part of the sysDescr MIB variable
>>              os-release     part of the sysDescr MIB variable
>>              os-version     part of the sysDescr MIB variable
>>              machine?       part of the sysDescr MIB variable
>> ... is also useful info.
> Kinda sorta.  One *might* find os-name, os-release, and os-version
> in sysDescr, but their presence is only a "should", and cannot be
> relied upon.  Same goes for "machine" if one treats that as "hardware
> type".
Ack. That should be mentioned then.

Regards, Benoit
>
> ...
>> NEW:
>>    leaf location {
>>           type string;
>>           description
>>             "The system location. In most cases, the "location" of an "interface" entry
> This text is broken.  The "location" is *not* the location of an interface;
> it is the location of the system.
>
>>             is mapped to sysLocation. sysLocation is defined as a DisplayString [RFC2579]
>>             which uses a 7-bit ASCII character set. An implementation that performs this
>>             mapping MUST restrict the allowed values for "location" to match the
>>             restrictions of sysLocation.";
> I understand why folks might do this, but it still gives
> me heartburn.  I believe it was a mistake when we failed
> to extend the syntax of these MIB objects to permit
> Unicode, and I believe it's a mistake to perpetuate the
> limitation here. I recognize that this is a messy problem,
> but surely we can do better than this, even if it's as
> simple a hack as having "location" and "legacy-location".
>
> Randy
>
> .
>


From bclaise@cisco.com  Wed Dec 11 08:30:20 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031291AE0EA for ; Wed, 11 Dec 2013 08:30:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BV_kqe0V__1 for ; Wed, 11 Dec 2013 08:30:17 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA0E1ADFCA for ; Wed, 11 Dec 2013 08:30:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1382; q=dns/txt; s=iport; t=1386779411; x=1387989011; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=sVu4p53Bt1GI0V2szVYnxrHeEqEQ88CnHDD0CogdIyI=; b=QciW+0m3LTq1bqNeZqLM3nTq078PXzU+kB1cV9h/dUmWVn2sq6uegIt0 a5MiysfIrVZFeM/tW2/bm7ssPs8owG9Px5OuZ13ySj96WhAENbaw3OldD GDwQfvseGkI+D1sVFjtRHFfawNXRWzC1SI2902e7HNeYrSeiOW9hqVjFI 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAMWSqFKQ/khR/2dsb2JhbABZgwe6JIEdFnSCJQEBAQMBOEARCxgJFg8JAwIBAgFFBgEMCAEBh3gGwgUXjw+ENASYFIZFi06DKjs
X-IronPort-AV: E=Sophos;i="4.93,872,1378857600";  d="scan'208";a="2020915"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 11 Dec 2013 16:30:09 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBBGU3UV018457; Wed, 11 Dec 2013 16:30:04 GMT
Message-ID: <52A8930B.3000502@cisco.com>
Date: Wed, 11 Dec 2013 17:30:03 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Randy Presuhn , netmod@ietf.org
References: <12817633.1386701728243.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> <20131210195745.GA74616@elstar.local> <001001cef5ed$54d320e0$6b01a8c0@oemcomputer> <20131211083837.GA76435@elstar.local>
In-Reply-To: <20131211083837.GA76435@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 16:30:20 -0000

Dear all,
> On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
>   
>>> Anyway, for a standardized approach, someone would have to write a
>>> document that defines how unicode code points are represented as
>>> escaped charater sequences in DisplayStrings. I do not think that this
>>> document is in charge of doing this. Hence, until such a standard is
>>> written, I think things need to be implementation specific.
>> Perhaps, though that is the route to being stuck with ASCII until the
>> successor to Netconf rolls along.
> Not necessarily. If you configure via NETCONF (or most CLIs these
> days), you can use unicode characters. The code that maps names to
> legacy non-unicode interfaces then needs to do suitable translations
> to fit whatever constraint there is.
If the WG is fine with this proposal, fine with me.  You should adapt 
the proposal then.
For consistency reasons, that principle should be applied to 
description/ifAlias in draft-ietf-netmod-interfaces-cfg.
This could be considered as IETF LC comment, I guess.

>
> If someone configures via legacy non-unicode interfaces, well then
> there is no unicode in the configured names. I do not think we can fix
> that problem. This requires to change the legacy non-unicode
> interfaces, which I think is not the task of this WG.
Agreed.

Regards, Benoit
>
> /js
>


From bclaise@cisco.com  Wed Dec 11 08:48:46 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872AB1AE14D for ; Wed, 11 Dec 2013 08:48:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.301
X-Spam-Level: 
X-Spam-Status: No, score=-8.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, J_CHICKENPOX_27=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TivzZsKuBH8r for ; Wed, 11 Dec 2013 08:48:44 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8781AE139 for ; Wed, 11 Dec 2013 08:48:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19626; q=dns/txt; s=iport; t=1386780518; x=1387990118; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=YRp1I9rVJIgzHM6a51Y3F4SMhJgxIEfHIuDNSDMRTyc=; b=KuIgG4nEA6LfVuoSkrhNT5ShF9+BNLVe66ZhIesLFULRqnouP6y8sZuc XpbmmiPOxuoiGQiQyixOqnBvkqw3ZQm7j2vvh6weZ9hPg0NrvsOkEcY2b NPMnvDWiFN32Mc2V6IUIUpyvLuRpGUusnbmz+hy+lp4uIIA4sAUKCT3I5 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai8FAAiXqFKQ/khR/2dsb2JhbABZgweJa7A6gR0WdIIlAQEBAwF4AQULCw4KCRYPCQMCAQIBRQYNAQUCAQGHeAbBfxePCAeENASYFIZFi06DKjuBLCQ
X-IronPort-AV: E=Sophos;i="4.93,872,1378857600"; d="scan'208,217";a="1413071"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 11 Dec 2013 16:48:36 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBBGmVOc023688; Wed, 11 Dec 2013 16:48:32 GMT
Message-ID: <52A8975F.8050709@cisco.com>
Date: Wed, 11 Dec 2013 17:48:31 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Martin Bjorklund 
References: <52A5F51E.2010705@cisco.com> <20131210.122630.261274424571283115.mbj@tail-f.com>
In-Reply-To: <20131210.122630.261274424571283115.mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="------------060605020200080701050008"
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-ip-cfg
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 16:48:46 -0000

This is a multi-part message in MIME format.
--------------060605020200080701050008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Martin,
> Hi,
>
> Benoit Claise  wrote:
>> Dear NETMOD WG,
>>
>> Here is my AD review for draft-ietf-netmod-ip-cfg.
>> Nothing serious about this draft, but a couple of editorial changes
>> could improve the draft.
>>
>> -
>> draft-ietf-netmod-interfaces-cfg-14 abstract
>>
>>     This document defines a YANG data model for the management of network
>>     interfaces.  It is expected that interface type specific data models
>>     augment the generic interfaces data model defined in this document.
>>     The data model includes configuration data and state data (status
>>     information and counters for the collection of statistics).
>>
>>
>> This draft draft-ietf-netmod-ip-cfg-11 abstract is a little light in
>> comparison
>>
>> Abstract
>>
>>     This document defines a YANG data model for management of IP
>>     implementations.
>>
>> You should express:
>>     The data model includes configuration data and state data (status
>>     information but no counters for the collection of statistics).
>>
>>
> Ok.  I'd prefer to mention what we do, and not what we don't do, so I
> suggest:
>
> NEW:
>
>    This document defines a YANG data model for management of IP
>    implementations.  The data model includes configuration data and
>    state data.
fine.
>
>> - Introduction
>>
>>   Parameters to manage IP routing are defined in
>>     [I-D.ietf-netmod-routing-cfg].
>>
>> This is maybe interesting, but it seems way more interesting to speak
>> about the connection with
>> draft-ietf-netmod-interfaces-cfg, which is a normative reference.
> I agree.  So remove the reference to routing:
>
> OLD:
>
> The data model covers configuration of per-interface IPv4 and IPv6
> parameters, and mappings of IP addresses to link-layer addresses.  It
> also provides information about which IP addresses are operationally
> used, and which link-layer mappings exist.
>
> Parameters to manage IP routing are defined in
> ^I-D.ietf-netmod-routing-cfg^.
>
>
> NEW:
>
> The data model covers configuration of per-interface IPv4 and IPv6
> parameters, and mappings of IP addresses to link-layer addresses.  It
> also provides information about which IP addresses are operationally
> used, and which link-layer mappings exist.  Per-interface parameters
> are added through augmentation of the interface data model defined in
> ^I-D-ietf-netmod-interfaces-cfg^.
Fine.
>
>> -
>> add state data in the terminology
> Ok.
>
>> -
>> Below ...
>>     The data model defines two state containers per interface, "ipv4" and
>>     "ipv6", representing the IPv4 and IPv6 address families.  In each
>>     container, there is a leaf "forwarding" that indicates if IP packet
>>     forwarding is enabled on that interface.  In each container there is
>>     also a list of all addresses in use, and a list of known mappings
>>     from IP addresses to link-layer addresses.
>>
>> ... it might be interesting to add a sentence or two on the difference
>> between the the /interfaces/ and /interfaces-state/.
>> At first glance they look similar, but there are not:
>>   * the origin has been added in multiple containers
>>   * the IPv6 status has been added (and not IPv4), because they're the
>>   * SLAAC state
>>   * the IPv6 neighbor state has been added.
> I am not sure that this is the right way to view these structures.
> They have very different semantics; which is why they are separate.
> One is the "manual config", and the other one reflects what is
> currently in operational use.
Sure, I understand that.

Here is how I went through the draft: I read through the two structures 
(I like that high level structure very much) to quickly understand the 
YANG module content.

        The data model has the following structure for IP configuration per
        interface:

           +--rw if:interfaces
              +--rw if:interface* [name]
                 ...
                 +--rw ipv4!
                 |  +--rw enabled?            boolean
                 |  +--rw forwarding?         boolean
                 |  +--rw mtu?                uint16
                 |  +--rw address* [ip]
                 |  |  +--rw ip               inet:ipv4-address-no-zone
                 |  |  +--rw (subnet)
                 |  |     +--:(prefix-length)
                 |  |     |  +--rw ip:prefix-length?   uint8
                 |  |     +--:(netmask)
                 |  |        +--rw ip:netmask?         yang:dotted-quad
                 |  +--rw neighbor* [ip]
                 |     +--rw ip                    inet:ipv4-address-no-zone
                 |     +--rw link-layer-address    yang:phys-address
                 +--rw ipv6!
                    +--rw enabled?            boolean
                    +--rw forwarding?         boolean
                    +--rw mtu?                uint32
                    +--rw address* [ip]
                    |  +--rw ip               inet:ipv6-address-no-zone
                    |  +--rw prefix-length    uint8
                    +--rw neighbor* [ip]
                    |  +--rw ip                    inet:ipv6-address-no-zone
                    |  +--rw link-layer-address    yang:phys-address
                    +--rw dup-addr-detect-transmits?   uint32
                    +--rw autoconf
                       +--rw create-global-addresses?        boolean
                       +--rw create-temporary-addresses?     boolean
                       +--rw temporary-valid-lifetime?       uint32
                       +--rw temporary-preferred-lifetime?   uint32

        The data model defines two configuration containers per interface,
        "ipv4" and "ipv6", representing the IPv4 and IPv6 address families.
        In each container, there is a leaf "enabled" that controls if the
        address family is enabled on that interface, and a leaf "forwarding"
        that controls if IP packet forwarding for the address family is
        enabled on the interface.  In each container, there is also a list of
        configured addresses, and a list of configured mappings from IP
        addresses to link-layer addresses.

        The data model has the following structure for IP state per
        interface:

           +--ro if:interfaces-state
              +--ro if:interface* [name]
                 ...
                 +--ro ipv4!
                 |  +--ro forwarding?   boolean
                 |  +--ro mtu?          uint16
                 |  +--ro address* [ip]
                 |  |  +--ro ip               inet:ipv4-address-no-zone
                 |  |  +--ro (subnet)?
                 |  |  |  +--:(prefix-length)
                 |  |  |  |  +--ro prefix-length?   uint8
                 |  |  |  +--:(netmask)
                 |  |  |     +--ro netmask?         yang:dotted-quad
                 |  |  +--ro origin?          ip-address-origin
                 |  +--ro neighbor* [ip]
                 |     +--ro ip                    inet:ipv4-address-no-zone
                 |     +--ro link-layer-address?   yang:phys-address
                 |     +--ro origin?               neighbor-origin
                 +--ro ipv6!
                    +--ro forwarding?   boolean
                    +--ro mtu?          uint32
                    +--ro address* [ip]
                    |  +--ro ip               inet:ipv6-address-no-zone
                    |  +--ro prefix-length    uint8
                    |  +--ro origin?          ip-address-origin
                    |  +--ro status?          enumeration
                    +--ro neighbor* [ip]
                       +--ro ip                    inet:ipv6-address-no-zone
                       +--ro link-layer-address?   yang:phys-address
                       +--ro origin?               neighbor-origin
                       +--ro is-router?            empty
                       +--ro state?                enumeration

Browsing through the two structures, the first thing I realized is that 
they're similar.
The second thing I realized is that they're almost similar, not quite!
Then, logically, I started to wonder what the differences were, and I 
tried to compare the two with some page up/page down.
Hence my feedback:

    it might be interesting to add a sentence or two on the difference
    between the the /interfaces/ and /interfaces-state/.
    At first glance they look similar, but there are not:
      * the origin has been added in multiple containers
      * the IPv6 status has been added (and not IPv4), because they're the
      * SLAAC state
      * the IPv6 neighbor state has been added.

If it's only me, leave that comment alone.
If some other people believe it makes sense...

Regards, Benoit

> So I do not know what/if to add.
>
>
>> -
>> Appendix A.  Example: NETCONF  reply
>>
>> You might want to mention that there are no neighbor for IPv4, or add
>> one.
> Ok, I'll add one.
>
>
> /martin
> .
>


--------------060605020200080701050008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Martin,

    

    

      
Hi,

Benoit Claise <bclaise@cisco.com> wrote:


      

        
Dear NETMOD WG,

Here is my AD review for draft-ietf-netmod-ip-cfg.
Nothing serious about this draft, but a couple of editorial changes
could improve the draft.

-
draft-ietf-netmod-interfaces-cfg-14 abstract

   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface type specific data models
   augment the generic interfaces data model defined in this document.
   The data model includes configuration data and state data (status
   information and counters for the collection of statistics).


This draft draft-ietf-netmod-ip-cfg-11 abstract is a little light in
comparison

Abstract

   This document defines a YANG data model for management of IP
   implementations.

You should express:
   The data model includes configuration data and state data (status
   information but no counters for the collection of statistics).




      

      
Ok.  I'd prefer to mention what we do, and not what we don't do, so I
suggest:

NEW:

  This document defines a YANG data model for management of IP
  implementations.  The data model includes configuration data and
  state data.

    

    fine.

    

      



      

        
- Introduction

 Parameters to manage IP routing are defined in
   [I-D.ietf-netmod-routing-cfg].

This is maybe interesting, but it seems way more interesting to speak
about the connection with
draft-ietf-netmod-interfaces-cfg, which is a normative reference.


      

      
I agree.  So remove the reference to routing:

OLD:

The data model covers configuration of per-interface IPv4 and IPv6
parameters, and mappings of IP addresses to link-layer addresses.  It
also provides information about which IP addresses are operationally
used, and which link-layer mappings exist.

Parameters to manage IP routing are defined in
^I-D.ietf-netmod-routing-cfg^.


NEW:

The data model covers configuration of per-interface IPv4 and IPv6
parameters, and mappings of IP addresses to link-layer addresses.  It
also provides information about which IP addresses are operationally
used, and which link-layer mappings exist.  Per-interface parameters
are added through augmentation of the interface data model defined in
^I-D-ietf-netmod-interfaces-cfg^.

    

    Fine.

    

      



      

        
-
add state data in the terminology


      

      
Ok.



      

        
-
Below ...
   The data model defines two state containers per interface, "ipv4" and
   "ipv6", representing the IPv4 and IPv6 address families.  In each
   container, there is a leaf "forwarding" that indicates if IP packet
   forwarding is enabled on that interface.  In each container there is
   also a list of all addresses in use, and a list of known mappings
   from IP addresses to link-layer addresses.

... it might be interesting to add a sentence or two on the difference
between the the /interfaces/ and /interfaces-state/.
At first glance they look similar, but there are not:
 * the origin has been added in multiple containers
 * the IPv6 status has been added (and not IPv4), because they're the
 * SLAAC state
 * the IPv6 neighbor state has been added.


      

      
I am not sure that this is the right way to view these structures.
They have very different semantics; which is why they are separate.
One is the "manual config", and the other one reflects what is
currently in operational use.  

    

    Sure, I understand that.

    

    Here is how I went through the draft: I read through the two
    structures (I like that high level structure very much) to quickly
    understand the YANG module content.

    

      
   The data model has the following structure for IP configuration per
   interface:

      +--rw if:interfaces
         +--rw if:interface* [name]
            ...
            +--rw ipv4!
            |  +--rw enabled?            boolean
            |  +--rw forwarding?         boolean
            |  +--rw mtu?                uint16
            |  +--rw address* [ip]
            |  |  +--rw ip               inet:ipv4-address-no-zone
            |  |  +--rw (subnet)
            |  |     +--:(prefix-length)
            |  |     |  +--rw ip:prefix-length?   uint8
            |  |     +--:(netmask)
            |  |        +--rw ip:netmask?         yang:dotted-quad
            |  +--rw neighbor* [ip]
            |     +--rw ip                    inet:ipv4-address-no-zone
            |     +--rw link-layer-address    yang:phys-address
            +--rw ipv6!
               +--rw enabled?            boolean
               +--rw forwarding?         boolean
               +--rw mtu?                uint32
               +--rw address* [ip]
               |  +--rw ip               inet:ipv6-address-no-zone
               |  +--rw prefix-length    uint8
               +--rw neighbor* [ip]
               |  +--rw ip                    inet:ipv6-address-no-zone
               |  +--rw link-layer-address    yang:phys-address
               +--rw dup-addr-detect-transmits?   uint32
               +--rw autoconf
                  +--rw create-global-addresses?        boolean
                  +--rw create-temporary-addresses?     boolean
                  +--rw temporary-valid-lifetime?       uint32
                  +--rw temporary-preferred-lifetime?   uint32

   The data model defines two configuration containers per interface,
   "ipv4" and "ipv6", representing the IPv4 and IPv6 address families.
   In each container, there is a leaf "enabled" that controls if the
   address family is enabled on that interface, and a leaf "forwarding"
   that controls if IP packet forwarding for the address family is
   enabled on the interface.  In each container, there is also a list of
   configured addresses, and a list of configured mappings from IP
   addresses to link-layer addresses.

   The data model has the following structure for IP state per
   interface:

      +--ro if:interfaces-state
         +--ro if:interface* [name]
            ...
            +--ro ipv4!
            |  +--ro forwarding?   boolean
            |  +--ro mtu?          uint16
            |  +--ro address* [ip]
            |  |  +--ro ip               inet:ipv4-address-no-zone
            |  |  +--ro (subnet)?
            |  |  |  +--:(prefix-length)
            |  |  |  |  +--ro prefix-length?   uint8
            |  |  |  +--:(netmask)
            |  |  |     +--ro netmask?         yang:dotted-quad
            |  |  +--ro origin?          ip-address-origin
            |  +--ro neighbor* [ip]
            |     +--ro ip                    inet:ipv4-address-no-zone
            |     +--ro link-layer-address?   yang:phys-address
            |     +--ro origin?               neighbor-origin
            +--ro ipv6!
               +--ro forwarding?   boolean
               +--ro mtu?          uint32
               +--ro address* [ip]
               |  +--ro ip               inet:ipv6-address-no-zone
               |  +--ro prefix-length    uint8
               |  +--ro origin?          ip-address-origin
               |  +--ro status?          enumeration
               +--ro neighbor* [ip]
                  +--ro ip                    inet:ipv6-address-no-zone
                  +--ro link-layer-address?   yang:phys-address
                  +--ro origin?               neighbor-origin
                  +--ro is-router?            empty
                  +--ro state?                enumeration

    

    Browsing through the two structures, the first thing I realized is
    that they're similar. 

    The second thing I realized is that they're almost similar, not
    quite!

    Then, logically, I started to wonder what the differences were, and
    I tried to compare the two with some page up/page down.

    Hence my feedback:

    

      
it might be interesting to add a sentence or two on the difference
between the the /interfaces/ and /interfaces-state/.
At first glance they look similar, but there are not:
 * the origin has been added in multiple containers
 * the IPv6 status has been added (and not IPv4), because they're the
 * SLAAC state
 * the IPv6 neighbor state has been added.

    

    If it's only me, leave that comment alone.

    If some other people believe it makes sense...

    

    Regards, Benoit

    

    

      
So I do not know what/if to add.




      

        
-
Appendix A.  Example: NETCONF <get> reply

You might want to mention that there are no neighbor for IPv4, or add
one.


      

      
Ok, I'll add one.


/martin
.



    

    

  


--------------060605020200080701050008--

From randy_presuhn@mindspring.com  Wed Dec 11 09:48:05 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1251AE0F9 for ; Wed, 11 Dec 2013 09:48:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0WGxoLM8CK1 for ; Wed, 11 Dec 2013 09:48:03 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 100F11ADF66 for ; Wed, 11 Dec 2013 09:48:02 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rPxoLA8FqvrW0XQ0mBCJFFO3NSL/kZ4hoNWIpCsMP/VsM3+UrMclb8cih+IG1afk; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.37] (helo=elwamui-karabash.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Vqnt6-0007Gb-Iq; Wed, 11 Dec 2013 12:47:56 -0500
Received: from 76.254.54.123 by webmail.earthlink.net with HTTP; Wed, 11 Dec 2013 12:47:56 -0500
Message-ID: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net>
Date: Wed, 11 Dec 2013 09:47:56 -0800 (GMT-08:00)
From: Randy Presuhn 
To: Juergen Schoenwaelder 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb701e4df5d8648a5a819d6e2cd881a00b350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.37
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Dec 2013 17:48:06 -0000

Hi -

>From: Juergen Schoenwaelder 
>Sent: Dec 11, 2013 12:38 AM
>To: Randy Presuhn 
>Cc: netmod@ietf.org
>Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
>On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> 
>> > Anyway, for a standardized approach, someone would have to write a
>> > document that defines how unicode code points are represented as
>> > escaped charater sequences in DisplayStrings. I do not think that this
>> > document is in charge of doing this. Hence, until such a standard is
>> > written, I think things need to be implementation specific.
>> 
>> Perhaps, though that is the route to being stuck with ASCII until the
>> successor to Netconf rolls along.
>
>Not necessarily. If you configure via NETCONF (or most CLIs these
>days), you can use unicode characters. The code that maps names to
>legacy non-unicode interfaces then needs to do suitable translations
>to fit whatever constraint there is.

Not if the data definition restricts the values to an ASCII
subset, as has been proposed.  What's in the draft at the
moment will bring its own interoperability problems, but
at least it's a baby step forward.

Randy

From mbj@tail-f.com  Wed Dec 11 23:52:18 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3211AD7C5 for ; Wed, 11 Dec 2013 23:52:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8Cn2lPyMYbB for ; Wed, 11 Dec 2013 23:52:17 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 110F71A1F62 for ; Wed, 11 Dec 2013 23:52:17 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 39637240C027; Thu, 12 Dec 2013 08:52:10 +0100 (CET)
Date: Thu, 12 Dec 2013 08:52:09 +0100 (CET)
Message-Id: <20131212.085209.387856404.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund 
In-Reply-To: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net>
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 07:52:18 -0000

Randy Presuhn  wrote:
> Hi -
> 
> >From: Juergen Schoenwaelder 
> >Sent: Dec 11, 2013 12:38 AM
> >To: Randy Presuhn 
> >Cc: netmod@ietf.org
> >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> >
> >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > 
> >> > Anyway, for a standardized approach, someone would have to write a
> >> > document that defines how unicode code points are represented as
> >> > escaped charater sequences in DisplayStrings. I do not think that this
> >> > document is in charge of doing this. Hence, until such a standard is
> >> > written, I think things need to be implementation specific.
> >> 
> >> Perhaps, though that is the route to being stuck with ASCII until the
> >> successor to Netconf rolls along.
> >
> >Not necessarily. If you configure via NETCONF (or most CLIs these
> >days), you can use unicode characters. The code that maps names to
> >legacy non-unicode interfaces then needs to do suitable translations
> >to fit whatever constraint there is.
> 
> Not if the data definition restricts the values to an ASCII
> subset, as has been proposed.  What's in the draft at the
> moment will bring its own interoperability problems, but
> at least it's a baby step forward.

So it seems we have a chance to fix this now.  But I need to
understand what exactly you and/or Juergen propose.  Preferrably
concrete text.  I *think* that the proposal is something like this:

   o  An implementation MUST allow any legal "string" (YANG string).

   o  An implementation that maps this value to the corresponding MIB
      object, which has size and character set limitations, MUST use
      some mechanism out of the scope for this document to ensure that
      the MIB object syntax is still valid.

Also, just to make sure, we are talking about:

   system/location        -- sysLocation
   system/contact         -- sysContact
   interface/description  -- ifAlias




/martin

From randy_presuhn@mindspring.com  Thu Dec 12 00:41:35 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4F31AE1E9 for ; Thu, 12 Dec 2013 00:41:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiBpks5VUA8X for ; Thu, 12 Dec 2013 00:41:33 -0800 (PST)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 046291AE13E for ; Thu, 12 Dec 2013 00:41:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=j9rTOvsWroESlFWAcE9fXpptWmyVniOnS0FiLs5KQGDeWI04LtMYoToI3XU4OLze; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.187.239.161] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Vr1pj-0000yE-OZ; Thu, 12 Dec 2013 03:41:24 -0500
Message-ID: <001b01cef716$295e2520$6b01a8c0@oemcomputer>
From: "Randy Presuhn" 
To: "Martin Bjorklund" 
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com>
Date: Thu, 12 Dec 2013 00:42:57 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb5c0273e24c6a174dcfc74d7f1f07fe22350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.187.239.161
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 08:41:35 -0000

Hi -

> From: "Martin Bjorklund" 
> To: 
> Cc: ; 
> Sent: Wednesday, December 11, 2013 11:52 PM
> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
> Randy Presuhn  wrote:
> > Hi -
> > 
> > >From: Juergen Schoenwaelder 
> > >Sent: Dec 11, 2013 12:38 AM
> > >To: Randy Presuhn 
> > >Cc: netmod@ietf.org
> > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > >
> > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > 
> > >> > Anyway, for a standardized approach, someone would have to write a
> > >> > document that defines how unicode code points are represented as
> > >> > escaped charater sequences in DisplayStrings. I do not think that this
> > >> > document is in charge of doing this. Hence, until such a standard is
> > >> > written, I think things need to be implementation specific.
> > >> 
> > >> Perhaps, though that is the route to being stuck with ASCII until the
> > >> successor to Netconf rolls along.
> > >
> > >Not necessarily. If you configure via NETCONF (or most CLIs these
> > >days), you can use unicode characters. The code that maps names to
> > >legacy non-unicode interfaces then needs to do suitable translations
> > >to fit whatever constraint there is.
> > 
> > Not if the data definition restricts the values to an ASCII
> > subset, as has been proposed.  What's in the draft at the
> > moment will bring its own interoperability problems, but
> > at least it's a baby step forward.
> 
> So it seems we have a chance to fix this now.  But I need to
> understand what exactly you and/or Juergen propose.  Preferrably
> concrete text.  I *think* that the proposal is something like this:
> 
>    o  An implementation MUST allow any legal "string" (YANG string).

There are good reasons to restrict formatting and control characters -
I'll assume YANG strings do this already.  If not, that's another long
discussion.
 
>    o  An implementation that maps this value to the corresponding MIB
>       object, which has size and character set limitations, MUST use
>       some mechanism out of the scope for this document to ensure that
>       the MIB object syntax is still valid.

Yes this seems reasonable.

But it doesn't cover a "round trip".  If the value is modified via the MIB
interface to include what looks like the implementation-specific encoding
into ASCII of a non-ASCII Unicode code point, does retrieving that value
via the Netconf interface get the Unicode code point or the implementation-
specific ASCII encoding of it?  If it does (and I think it should) then there
needs to be some though put into what happens when the code point
encoded using ASCII would, if converted to Unicode, be illegal (for
whatever reason) in the YANG string.  It's probably best to keep the
SNMP instrumentation ignorant of all this, so code in the Netconf side
would need determine whether any of the ASCII "escape sequences"
would produce forbidden code points, and, in such cases, *not* evaluate
those sequences and just pass them through unevaluated.

 
> Also, just to make sure, we are talking about:
> 
>    system/location        -- sysLocation
>    system/contact         -- sysContact
>    interface/description  -- ifAlias

Perhaps also sysDescr (even though read-only, my comment above seems applicable,
particularly since on at least some systems this comes from a static configuration
file, and would be useful to support local language in some minimal way.)

sysName (think IDN) might also be worth thinking about.  There was a long debate
about this a while back; I don't know what current thinking is.

Randy


From j.schoenwaelder@jacobs-university.de  Thu Dec 12 03:41:53 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419FB1A1F58 for ; Thu, 12 Dec 2013 03:41:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GA0qckmMPTJ1 for ; Thu, 12 Dec 2013 03:41:50 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 034FA1A1F55 for ; Thu, 12 Dec 2013 03:41:47 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B75B12009E; Thu, 12 Dec 2013 12:41:40 +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 y5wnP0p0mWOH; Thu, 12 Dec 2013 12:41:40 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18D982002F; Thu, 12 Dec 2013 12:41:40 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id AD0EF29FC743; Thu, 12 Dec 2013 12:41:34 +0100 (CET)
Date: Thu, 12 Dec 2013 12:41:32 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20131212114131.GA80315@elstar.local>
Mail-Followup-To: Martin Bjorklund , randy_presuhn@mindspring.com, netmod@ietf.org
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131212.085209.387856404.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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 Dec 2013 11:41:53 -0000

On Thu, Dec 12, 2013 at 08:52:09AM +0100, Martin Bjorklund wrote:
> Randy Presuhn  wrote:
> > Hi -
> > 
> > >From: Juergen Schoenwaelder 
> > >Sent: Dec 11, 2013 12:38 AM
> > >To: Randy Presuhn 
> > >Cc: netmod@ietf.org
> > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > >
> > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > 
> > >> > Anyway, for a standardized approach, someone would have to write a
> > >> > document that defines how unicode code points are represented as
> > >> > escaped charater sequences in DisplayStrings. I do not think that this
> > >> > document is in charge of doing this. Hence, until such a standard is
> > >> > written, I think things need to be implementation specific.
> > >> 
> > >> Perhaps, though that is the route to being stuck with ASCII until the
> > >> successor to Netconf rolls along.
> > >
> > >Not necessarily. If you configure via NETCONF (or most CLIs these
> > >days), you can use unicode characters. The code that maps names to
> > >legacy non-unicode interfaces then needs to do suitable translations
> > >to fit whatever constraint there is.
> > 
> > Not if the data definition restricts the values to an ASCII
> > subset, as has been proposed.  What's in the draft at the
> > moment will bring its own interoperability problems, but
> > at least it's a baby step forward.
> 
> So it seems we have a chance to fix this now.  But I need to
> understand what exactly you and/or Juergen propose.  Preferrably
> concrete text.  I *think* that the proposal is something like this:
> 
>    o  An implementation MUST allow any legal "string" (YANG string).

I do not think we need to state this since this is the default anyway
for an object using the string type.
 
>    o  An implementation that maps this value to the corresponding MIB
>       object, which has size and character set limitations, MUST use
>       some mechanism out of the scope for this document to ensure that
>       the MIB object syntax is still valid.

Yes.

> Also, just to make sure, we are talking about:
> 
>    system/location        -- sysLocation
>    system/contact         -- sysContact
>    interface/description  -- ifAlias

It might also apply to interface/name (ifName).

/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 Dec 12 03:52:47 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8971A1F7B for ; Thu, 12 Dec 2013 03:52:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avAVuokhy7KZ for ; Thu, 12 Dec 2013 03:52:43 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7E62F1AC441 for ; Thu, 12 Dec 2013 03:52:43 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D312200A1; Thu, 12 Dec 2013 12:52: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 B2SKprdwLsZL; Thu, 12 Dec 2013 12:52: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 A632B2009E; Thu, 12 Dec 2013 12:52:36 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 8A72E29FC7D7; Thu, 12 Dec 2013 12:52:30 +0100 (CET)
Date: Thu, 12 Dec 2013 12:52:30 +0100
From: Juergen Schoenwaelder 
To: Randy Presuhn , h@elstar.local
Message-ID: <20131212115229.GB80315@elstar.local>
Mail-Followup-To: Randy Presuhn , h@elstar.local, Martin Bjorklund , netmod@ietf.org
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com> <001b01cef716$295e2520$6b01a8c0@oemcomputer>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001b01cef716$295e2520$6b01a8c0@oemcomputer>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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 Dec 2013 11:52:47 -0000

On Thu, Dec 12, 2013 at 12:42:57AM -0800, Randy Presuhn wrote:
>
> >    o  An implementation MUST allow any legal "string" (YANG string).
> 
> There are good reasons to restrict formatting and control characters -
> I'll assume YANG strings do this already.  If not, that's another long
> discussion.

RFC 6020 says:

   The string built-in type represents human-readable strings in YANG.
   Legal characters are tab, carriage return, line feed, and the legal
   characters of Unicode and ISO/IEC 10646 [ISO.10646]:

     ;; any Unicode character, excluding the surrogate blocks,
     ;; FFFE, and FFFF.
     string = *char
     char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
            %x10000-10FFFF

And so far, we have used these strings without further restrictions in
data models when there was something to be named.
  
> >    o  An implementation that maps this value to the corresponding MIB
> >       object, which has size and character set limitations, MUST use
> >       some mechanism out of the scope for this document to ensure that
> >       the MIB object syntax is still valid.
> 
> Yes this seems reasonable.
> 
> But it doesn't cover a "round trip".  If the value is modified via the MIB
> interface to include what looks like the implementation-specific encoding
> into ASCII of a non-ASCII Unicode code point, does retrieving that value
> via the Netconf interface get the Unicode code point or the implementation-
> specific ASCII encoding of it?  If it does (and I think it should) then there
> needs to be some though put into what happens when the code point
> encoded using ASCII would, if converted to Unicode, be illegal (for
> whatever reason) in the YANG string.  It's probably best to keep the
> SNMP instrumentation ignorant of all this, so code in the Netconf side
> would need determine whether any of the ASCII "escape sequences"
> would produce forbidden code points, and, in such cases, *not* evaluate
> those sequences and just pass them through unevaluated.

It might not be the job of these documents to engineer a round-trip
solution if one is required.
 
> sysName (think IDN) might also be worth thinking about.  There was a long debate
> about this a while back; I don't know what current thinking is.

sysName is defined like this:

            "An administratively-assigned name for this managed
            node.  By convention, this is the node's fully-qualified
            domain name.  If the name is unknown, the value is
            the zero-length string."

Since it is a DisplayString, sysName can represent IDNs only in their
ASCII representation. The .../system/hostname leaf in the system data
model is of type inet:domain-name and RFC 6991 says in the description
of domain-name:

         Domain-name values use the US-ASCII encoding.  Their canonical
         format uses lowercase US-ASCII characters.  Internationalized
         domain names MUST be A-labels as per RFC 5890.

This lines up - you can of course argue whether this is what operators
will prefer to have in their config files since it is not cut'n'paste
friendly.

/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 Dec 12 05:37:53 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEE91AE226 for ; Thu, 12 Dec 2013 05:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mpofUdaDLit for ; Thu, 12 Dec 2013 05:37:51 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8707C1ADBCF for ; Thu, 12 Dec 2013 05:37:50 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id C9992240C119; Thu, 12 Dec 2013 14:37:43 +0100 (CET)
Date: Thu, 12 Dec 2013 14:37:43 +0100 (CET)
Message-Id: <20131212.143743.502541833.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20131212115229.GB80315@elstar.local>
References: <20131212.085209.387856404.mbj@tail-f.com> <001b01cef716$295e2520$6b01a8c0@oemcomputer> <20131212115229.GB80315@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: randy_presuhn@mindspring.com, h@elstar.local, netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 13:37:53 -0000

Juergen Schoenwaelder  wrote:
> On Thu, Dec 12, 2013 at 12:42:57AM -0800, Randy Presuhn wrote:
> > sysName (think IDN) might also be worth thinking about.  There was a long
> > debate
> > about this a while back; I don't know what current thinking is.
> 
> sysName is defined like this:
> 
>             "An administratively-assigned name for this managed
>             node.  By convention, this is the node's fully-qualified
>             domain name.  If the name is unknown, the value is
>             the zero-length string."

Note that /system/hostname has different semantics - sysName is *by
convention* the *fqdn*.  For this reason, /system/hostname is not
mapped to sysName in the document.


/martin

From ietfdbh@comcast.net  Thu Dec 12 09:08:16 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985D71AE046 for ; Thu, 12 Dec 2013 09:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZrPHK6umN1O for ; Thu, 12 Dec 2013 09:08:14 -0800 (PST)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id DA29A1AD8EC for ; Thu, 12 Dec 2013 09:08:13 -0800 (PST)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 0dRL1n0051wpRvQ5Bh87sD; Thu, 12 Dec 2013 17:08:07 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta18.westchester.pa.mail.comcast.net with comcast id 0h871n00C2yZEBF3eh87tt; Thu, 12 Dec 2013 17:08:07 +0000
From: "ietfdbh" 
To: "'Randy Presuhn'" , "'Martin Bjorklund'" 
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com> <001b01cef716$295e2520$6b01a8c0@oemcomputer>
In-Reply-To: <001b01cef716$295e2520$6b01a8c0@oemcomputer>
Date: Thu, 12 Dec 2013 12:08:03 -0500
Message-ID: <004a01cef75c$b8610120$29230360$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHRWvhskhnOaPbMPUajuprGlXhfOwJKF7QAAdpcnciaKs+QQA==
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386868087; bh=0xF2cW2YxBwXpr+OAwGEQ9VJZeOgc9OIL8ME+6qicPI=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=emvA/lFwjfJub0wf0fZk+FheTpGOMtGo/HtWQsUrL0w+RSHYEA8oArkScqdjb5ECl FnWnsAFO6jEkqwSMjk1GsgnJ8CZnjlJHQbu9IAAR10+xnq+M5Cg9vB/O9lqnfcOuKp o0YkVFwmjbN7GiK8ZuU4gKrouJwAbqxMG2jErB8Y3GmOj3BCx3hrTSeg+KeoH7oVZe Cju4UHGJRLzejbqpZp3buB9/qB/63rCT33QJajEo2vTz3rYBXx1MG3G8w2NSNnAa8r N9/K832zLusNZrdyxCJB3Zl5U8DywQi5//6FlzJB0t+25tdRkmdDS3QtrgRtxpU7/5 2E7Xxp79QIozQ==
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 17:08:16 -0000

Hi,

Personally, I think it would be simpler to just have the YANG objects be
constrained by DisplayString syntax, but then, I come from a country where
7-bit ASCII covers my language of choice. It would be nice to have a
consistent underlying instrumentation without duplication of effort and
resources, but that would require choosing the least common denominator
(DisplayString). 

My second choice would be to treat them as separate instances, one of
DisplayString syntax, one of YANG string syntax. That way, we don't have to
worry about side effects of changing the YANG object via the MIB, or
changing the MIB object via YANG. If we want to internationalize the syntax,
you cannot do that to the MIB within SMI limits. Mapping between them if
they support different syntax raises a whole lot of issues for the database
handling and UI of an NMS, stands the chance of breaking existing
implementations if implementers handle the translations wrong or in a
non-interoperable manner, and stands the chance of misleading operators (and
applications) if the value of the MIB object is changed dynamically because
the value is changed (in any way) via translation from the YANG object. 

I think it would be better for standardization and interoperability if we do
not try to force-feed new syntax into the existing MIB object(s). If you
were trying to do this by updating the MIB, you would most certainly need to
define a new object (much like we had to do with Counter64s to replace
Counter32s). If the YANG object is treated as a separate object from the MIB
object, then if and when the MIB is updated, the MIB can add an object to
map to the YANG object, and deprecate the DisplayString syntax object.

If the YANG object says it can be mapped, then I think the YANG object must
REQUIRE that it be implemented with DisplayString constraints, whether a
server implementation maps to the MIB or not. Assuming an NMS supports both
MIB and YANG queries, and an implementer MAY treat them as separate, then
the NMS must treat them as separate. If the implementer MAY treat them as
mapped, the NMS still needs to implement them as separate because they MAY
be separate, but the NMS probably must treat the NMS-side variables as
mapped to ensure they are in sync; otherwise reading the value via the MIB
without simultaneously reading the value via YANG would lead to the NMS
potentially displaying different values even though on the device the values
are the same. This optionality greatly increases the complexity of
implementing these objects on the NMS side. An NMS would need to determine
whether the agent/server implemented these as mapped or separate, presumably
by changing one and seeing if it affected the other, so it knew whether to
try to perform synchronization between the two. Lots of work for limited
benefit to the operator. And if NMS implementations handled synchronization
differently, the operator is stuck trying to manage with conflicting
information from different NMSs.

It would be much better to standardize the expectation - either these
objects MUST be mapped and constrained by DisplayString syntax per the IETF,
or MUST be defined as separate objects of different syntax per the IETF
standard. Then an NMS implementer knows what to expect.

David Harrington
ietfdbh@comcast.net
+1-603-828-1401
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy
> Presuhn
> Sent: Thursday, December 12, 2013 3:43 AM
> To: Martin Bjorklund
> Cc: netmod@ietf.org
> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> 
> Hi -
> 
> > From: "Martin Bjorklund" 
> > To: 
> > Cc: ; 
> > Sent: Wednesday, December 11, 2013 11:52 PM
> > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> >
> > Randy Presuhn  wrote:
> > > Hi -
> > >
> > > >From: Juergen Schoenwaelder  university.de>
> > > >Sent: Dec 11, 2013 12:38 AM
> > > >To: Randy Presuhn 
> > > >Cc: netmod@ietf.org
> > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > >
> > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > >
> > > >> > Anyway, for a standardized approach, someone would have to write
> a
> > > >> > document that defines how unicode code points are represented as
> > > >> > escaped charater sequences in DisplayStrings. I do not think that
this
> > > >> > document is in charge of doing this. Hence, until such a standard
is
> > > >> > written, I think things need to be implementation specific.
> > > >>
> > > >> Perhaps, though that is the route to being stuck with ASCII until
the
> > > >> successor to Netconf rolls along.
> > > >
> > > >Not necessarily. If you configure via NETCONF (or most CLIs these
> > > >days), you can use unicode characters. The code that maps names to
> > > >legacy non-unicode interfaces then needs to do suitable translations
> > > >to fit whatever constraint there is.
> > >
> > > Not if the data definition restricts the values to an ASCII
> > > subset, as has been proposed.  What's in the draft at the
> > > moment will bring its own interoperability problems, but
> > > at least it's a baby step forward.
> >
> > So it seems we have a chance to fix this now.  But I need to
> > understand what exactly you and/or Juergen propose.  Preferrably
> > concrete text.  I *think* that the proposal is something like this:
> >
> >    o  An implementation MUST allow any legal "string" (YANG string).
> 
> There are good reasons to restrict formatting and control characters -
> I'll assume YANG strings do this already.  If not, that's another long
> discussion.
> 
> >    o  An implementation that maps this value to the corresponding MIB
> >       object, which has size and character set limitations, MUST use
> >       some mechanism out of the scope for this document to ensure that
> >       the MIB object syntax is still valid.
> 
> Yes this seems reasonable.
> 
> But it doesn't cover a "round trip".  If the value is modified via the MIB
> interface to include what looks like the implementation-specific encoding
> into ASCII of a non-ASCII Unicode code point, does retrieving that value
> via the Netconf interface get the Unicode code point or the
implementation-
> specific ASCII encoding of it?  If it does (and I think it should) then
there
> needs to be some though put into what happens when the code point
> encoded using ASCII would, if converted to Unicode, be illegal (for
> whatever reason) in the YANG string.  It's probably best to keep the
> SNMP instrumentation ignorant of all this, so code in the Netconf side
> would need determine whether any of the ASCII "escape sequences"
> would produce forbidden code points, and, in such cases, *not* evaluate
> those sequences and just pass them through unevaluated.
> 
> 
> > Also, just to make sure, we are talking about:
> >
> >    system/location        -- sysLocation
> >    system/contact         -- sysContact
> >    interface/description  -- ifAlias
> 
> Perhaps also sysDescr (even though read-only, my comment above seems
> applicable,
> particularly since on at least some systems this comes from a static
> configuration
> file, and would be useful to support local language in some minimal way.)
> 
> sysName (think IDN) might also be worth thinking about.  There was a long
> debate
> about this a while back; I don't know what current thinking is.
> 
> Randy
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From andy@yumaworks.com  Thu Dec 12 09:19:39 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9B21AE059 for ; Thu, 12 Dec 2013 09:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teDGIyfrX4_N for ; Thu, 12 Dec 2013 09:19:35 -0800 (PST)
Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7359E1AE36F for ; Thu, 12 Dec 2013 09:19:34 -0800 (PST)
Received: by mail-qe0-f46.google.com with SMTP id a11so578367qen.5 for ; Thu, 12 Dec 2013 09:19:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YSfrQMqaDeWxrJwLZWDcqNGHGBMoQF5PVyhWUyaUQYU=; b=U0a5vPnsD/ihFDMh/4OzBJYnf9J5Qht16qmBhgLvdbW/3B09anDZPiGsNWRdazcFfN 55BU+MWmUHmmJ2rzvCbMtkqwrvbJ+K9cof3a/6uw/Q8VK2wnQeH3CwaQ5JPdBz8UEtEN 0Jco7yJXGvkOlbinj3Yz1uniu2Y4QSo9Azcw2lMkxPkOQRLBCFiA+GdFIeZMZ6IV/Nwo 97MVIj0VSyIAIEqKOgOfhp2CkUdglkePI1d9jEWpxoQPSu2vxzJ4oubZhxWeBOSq355I HKMPAwgHreF0vZi5MA4ra2VZv88RGP2rJhJVDaHzReKhs194TnSYOLRR5SpP7ZhFNb2Z 6OXQ==
X-Gm-Message-State: ALoCoQlZoWLclRcpXfZy70MSaQ4U2kPJHGTx7WLtOMfAdx5oKmJUBv7qbyftMf3ADrJ0XjX8wRzA
MIME-Version: 1.0
X-Received: by 10.224.151.209 with SMTP id d17mr8130071qaw.87.1386868768298; Thu, 12 Dec 2013 09:19:28 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 12 Dec 2013 09:19:28 -0800 (PST)
In-Reply-To: <004a01cef75c$b8610120$29230360$@comcast.net>
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com> <001b01cef716$295e2520$6b01a8c0@oemcomputer> <004a01cef75c$b8610120$29230360$@comcast.net>
Date: Thu, 12 Dec 2013 09:19:28 -0800
Message-ID: 
From: Andy Bierman 
To: ietfdbh 
Content-Type: multipart/alternative; boundary=089e0149d2c448e9b404ed598cbb
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 17:19:39 -0000

--089e0149d2c448e9b404ed598cbb
Content-Type: text/plain; charset=ISO-8859-1

Hi,

What if these objects do not have corresponding SNMP values on the device?
What if the device does not implement SNMP?

Are you suggesting we need duplicate versions for devices that do support
SNMP,
with an "if-feature snmp" statement to make it conditional?  What does it
mean
if the 2 variants have different values?

I think the new proposed text forces a device to limit the object to 7-bit
ASCII
if the SNMP version of the object is supported.

It seems old syntax is being forced on devices, not new syntax.


Andy

On Thu, Dec 12, 2013 at 9:08 AM, ietfdbh  wrote:

> Hi,
>
> Personally, I think it would be simpler to just have the YANG objects be
> constrained by DisplayString syntax, but then, I come from a country where
> 7-bit ASCII covers my language of choice. It would be nice to have a
> consistent underlying instrumentation without duplication of effort and
> resources, but that would require choosing the least common denominator
> (DisplayString).
>
> My second choice would be to treat them as separate instances, one of
> DisplayString syntax, one of YANG string syntax. That way, we don't have to
> worry about side effects of changing the YANG object via the MIB, or
> changing the MIB object via YANG. If we want to internationalize the
> syntax,
> you cannot do that to the MIB within SMI limits. Mapping between them if
> they support different syntax raises a whole lot of issues for the database
> handling and UI of an NMS, stands the chance of breaking existing
> implementations if implementers handle the translations wrong or in a
> non-interoperable manner, and stands the chance of misleading operators
> (and
> applications) if the value of the MIB object is changed dynamically because
> the value is changed (in any way) via translation from the YANG object.
>
> I think it would be better for standardization and interoperability if we
> do
> not try to force-feed new syntax into the existing MIB object(s). If you
> were trying to do this by updating the MIB, you would most certainly need
> to
> define a new object (much like we had to do with Counter64s to replace
> Counter32s). If the YANG object is treated as a separate object from the
> MIB
> object, then if and when the MIB is updated, the MIB can add an object to
> map to the YANG object, and deprecate the DisplayString syntax object.
>
> If the YANG object says it can be mapped, then I think the YANG object must
> REQUIRE that it be implemented with DisplayString constraints, whether a
> server implementation maps to the MIB or not. Assuming an NMS supports both
> MIB and YANG queries, and an implementer MAY treat them as separate, then
> the NMS must treat them as separate. If the implementer MAY treat them as
> mapped, the NMS still needs to implement them as separate because they MAY
> be separate, but the NMS probably must treat the NMS-side variables as
> mapped to ensure they are in sync; otherwise reading the value via the MIB
> without simultaneously reading the value via YANG would lead to the NMS
> potentially displaying different values even though on the device the
> values
> are the same. This optionality greatly increases the complexity of
> implementing these objects on the NMS side. An NMS would need to determine
> whether the agent/server implemented these as mapped or separate,
> presumably
> by changing one and seeing if it affected the other, so it knew whether to
> try to perform synchronization between the two. Lots of work for limited
> benefit to the operator. And if NMS implementations handled synchronization
> differently, the operator is stuck trying to manage with conflicting
> information from different NMSs.
>
> It would be much better to standardize the expectation - either these
> objects MUST be mapped and constrained by DisplayString syntax per the
> IETF,
> or MUST be defined as separate objects of different syntax per the IETF
> standard. Then an NMS implementer knows what to expect.
>
> David Harrington
> ietfdbh@comcast.net
> +1-603-828-1401
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy
> > Presuhn
> > Sent: Thursday, December 12, 2013 3:43 AM
> > To: Martin Bjorklund
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> >
> > Hi -
> >
> > > From: "Martin Bjorklund" 
> > > To: 
> > > Cc: ; 
> > > Sent: Wednesday, December 11, 2013 11:52 PM
> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > >
> > > Randy Presuhn  wrote:
> > > > Hi -
> > > >
> > > > >From: Juergen Schoenwaelder  > university.de>
> > > > >Sent: Dec 11, 2013 12:38 AM
> > > > >To: Randy Presuhn 
> > > > >Cc: netmod@ietf.org
> > > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > > >
> > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > > >
> > > > >> > Anyway, for a standardized approach, someone would have to write
> > a
> > > > >> > document that defines how unicode code points are represented as
> > > > >> > escaped charater sequences in DisplayStrings. I do not think
> that
> this
> > > > >> > document is in charge of doing this. Hence, until such a
> standard
> is
> > > > >> > written, I think things need to be implementation specific.
> > > > >>
> > > > >> Perhaps, though that is the route to being stuck with ASCII until
> the
> > > > >> successor to Netconf rolls along.
> > > > >
> > > > >Not necessarily. If you configure via NETCONF (or most CLIs these
> > > > >days), you can use unicode characters. The code that maps names to
> > > > >legacy non-unicode interfaces then needs to do suitable translations
> > > > >to fit whatever constraint there is.
> > > >
> > > > Not if the data definition restricts the values to an ASCII
> > > > subset, as has been proposed.  What's in the draft at the
> > > > moment will bring its own interoperability problems, but
> > > > at least it's a baby step forward.
> > >
> > > So it seems we have a chance to fix this now.  But I need to
> > > understand what exactly you and/or Juergen propose.  Preferrably
> > > concrete text.  I *think* that the proposal is something like this:
> > >
> > >    o  An implementation MUST allow any legal "string" (YANG string).
> >
> > There are good reasons to restrict formatting and control characters -
> > I'll assume YANG strings do this already.  If not, that's another long
> > discussion.
> >
> > >    o  An implementation that maps this value to the corresponding MIB
> > >       object, which has size and character set limitations, MUST use
> > >       some mechanism out of the scope for this document to ensure that
> > >       the MIB object syntax is still valid.
> >
> > Yes this seems reasonable.
> >
> > But it doesn't cover a "round trip".  If the value is modified via the
> MIB
> > interface to include what looks like the implementation-specific encoding
> > into ASCII of a non-ASCII Unicode code point, does retrieving that value
> > via the Netconf interface get the Unicode code point or the
> implementation-
> > specific ASCII encoding of it?  If it does (and I think it should) then
> there
> > needs to be some though put into what happens when the code point
> > encoded using ASCII would, if converted to Unicode, be illegal (for
> > whatever reason) in the YANG string.  It's probably best to keep the
> > SNMP instrumentation ignorant of all this, so code in the Netconf side
> > would need determine whether any of the ASCII "escape sequences"
> > would produce forbidden code points, and, in such cases, *not* evaluate
> > those sequences and just pass them through unevaluated.
> >
> >
> > > Also, just to make sure, we are talking about:
> > >
> > >    system/location        -- sysLocation
> > >    system/contact         -- sysContact
> > >    interface/description  -- ifAlias
> >
> > Perhaps also sysDescr (even though read-only, my comment above seems
> > applicable,
> > particularly since on at least some systems this comes from a static
> > configuration
> > file, and would be useful to support local language in some minimal way.)
> >
> > sysName (think IDN) might also be worth thinking about.  There was a long
> > debate
> > about this a while back; I don't know what current thinking is.
> >
> > Randy
> >
> > _______________________________________________
> > 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
>

--089e0149d2c448e9b404ed598cbb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi,

What if these objects do not have c=
orresponding SNMP values on the device?
What if the device does n=
ot implement SNMP?

Are you suggesting we need dupl=
icate versions for devices that do support SNMP,


with an "if-feature snmp" statement to make it conditional? =
=A0What does it mean
if the 2 variants have different values?

I think the new proposed text forces a device to limi=
t the object to 7-bit ASCII


if the SNMP version of the object is supported.

It seems old syntax is being forced on devices, not new syntax.


Andy


On Thu, Dec 12, 2013 at 9:08 AM, ietfdbh <ietfdbh@comcast.net> wrote:

Hi,



Personally, I think it would be simpler to just have the YANG objects be
constrained by DisplayString syntax, but then, I come from a country where<=
br>
7-bit ASCII covers my language of choice. It would be nice to have a

consistent underlying instrumentation without duplication of effort and

resources, but that would require choosing the least common denominator

(DisplayString).



My second choice would be to treat them as separate instances, one of

DisplayString syntax, one of YANG string syntax. That way, we don't hav=
e to

worry about side effects of changing the YANG object via the MIB, or

changing the MIB object via YANG. If we want to internationalize the syntax=
,

you cannot do that to the MIB within SMI limits. Mapping between them if
they support different syntax raises a whole lot of issues for the database=


handling and UI of an NMS, stands the chance of breaking existing

implementations if implementers handle the translations wrong or in a

non-interoperable manner, and stands the chance of misleading operators (an=
d

applications) if the value of the MIB object is changed dynamically because=


the value is changed (in any way) via translation from the YANG object.



I think it would be better for standardization and interoperability if we d=
o

not try to force-feed new syntax into the existing MIB object(s). If you
were trying to do this by updating the MIB, you would most certainly need t=
o

define a new object (much like we had to do with Counter64s to replace

Counter32s). If the YANG object is treated as a separate object from the MI=
B

object, then if and when the MIB is updated, the MIB can add an object to
map to the YANG object, and deprecate the DisplayString syntax object.



If the YANG object says it can be mapped, then I think the YANG object must=


REQUIRE that it be implemented with DisplayString constraints, whether a
server implementation maps to the MIB or not. Assuming an NMS supports both=


MIB and YANG queries, and an implementer MAY treat them as separate, then
the NMS must treat them as separate. If the implementer MAY treat them as
mapped, the NMS still needs to implement them as separate because they MAY<=
br>
be separate, but the NMS probably must treat the NMS-side variables as

mapped to ensure they are in sync; otherwise reading the value via the MIB<=
br>
without simultaneously reading the value via YANG would lead to the NMS

potentially displaying different values even though on the device the value=
s

are the same. This optionality greatly increases the complexity of

implementing these objects on the NMS side. An NMS would need to determine<=
br>
whether the agent/server implemented these as mapped or separate, presumabl=
y

by changing one and seeing if it affected the other, so it knew whether to<=
br>
try to perform synchronization between the two. Lots of work for limited
benefit to the operator. And if NMS implementations handled synchronization=


differently, the operator is stuck trying to manage with conflicting

information from different NMSs.



It would be much better to standardize the expectation - either these

objects MUST be mapped and constrained by DisplayString syntax per the IETF=
,

or MUST be defined as separate objects of different syntax per the IETF

standard. Then an NMS implementer knows what to expect.



David Harrington

ietfdbh@comcast.net

+1-603-828-1401

> -----Original Message-----

> From: netmod [mailto:netmod=
-bounces@ietf.org] On Behalf Of Randy

> Presuhn

> Sent: Thursday, December 12, 2013 3:43 AM

> To: Martin Bjorklund

> Cc: netmod@ietf.org

> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt

>

> Hi -

>

> > From: "Martin Bjorklund" <mbj@tail-f.com>

> > To: <randy_pre=
suhn@mindspring.com>

> > Cc: <j=
.schoenwaelder@jacobs-university.de>; <netmod@ietf.org>

> > Sent: Wednesday, December 11, 2013 11:52 PM

> > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt<=
br>
> >

> > Randy Presuhn <randy_presuhn@mindspring.com> wrote:

> > > Hi -

> > >

> > > >From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-<=
br>
> university.de&g=
t;

> > > >Sent: Dec 11, 2013 12:38 AM

> > > >To: Randy Presuhn <randy_presuhn@mindspring.com>

> > > >Cc: netmod@ietf.org

> > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-sys=
tem-mgmt

> > > >

> > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn =
wrote:

> > > >

> > > >> > Anyway, for a standardized approach, someone w=
ould have to write

> a

> > > >> > document that defines how unicode code points =
are represented as

> > > >> > escaped charater sequences in DisplayStrings. =
I do not think that

this

> > > >> > document is in charge of doing this. Hence, un=
til such a standard

is

> > > >> > written, I think things need to be implementat=
ion specific.

> > > >>

> > > >> Perhaps, though that is the route to being stuck wi=
th ASCII until

the

> > > >> successor to Netconf rolls along.

> > > >

> > > >Not necessarily. If you configure via NETCONF (or most C=
LIs these

> > > >days), you can use unicode characters. The code that map=
s names to

> > > >legacy non-unicode interfaces then needs to do suitable =
translations

> > > >to fit whatever constraint there is.

> > >

> > > Not if the data definition restricts the values to an ASCII<=
br>
> > > subset, as has been proposed. =A0What's in the draft at =
the

> > > moment will bring its own interoperability problems, but

> > > at least it's a baby step forward.

> >

> > So it seems we have a chance to fix this now. =A0But I need to
> > understand what exactly you and/or Juergen propose. =A0Preferrabl=
y

> > concrete text. =A0I *think* that the proposal is something like t=
his:

> >

> > =A0 =A0o =A0An implementation MUST allow any legal "string&q=
uot; (YANG string).

>

> There are good reasons to restrict formatting and control characters -=


> I'll assume YANG strings do this already. =A0If not, that's an=
other long

> discussion.

>

> > =A0 =A0o =A0An implementation that maps this value to the corresp=
onding MIB

> > =A0 =A0 =A0 object, which has size and character set limitations,=
 MUST use

> > =A0 =A0 =A0 some mechanism out of the scope for this document to =
ensure that

> > =A0 =A0 =A0 the MIB object syntax is still valid.

>

> Yes this seems reasonable.

>

> But it doesn't cover a "round trip". =A0If the value is =
modified via the MIB

> interface to include what looks like the implementation-specific encod=
ing

> into ASCII of a non-ASCII Unicode code point, does retrieving that val=
ue

> via the Netconf interface get the Unicode code point or the

implementation-

> specific ASCII encoding of it? =A0If it does (and I think it should) t=
hen

there

> needs to be some though put into what happens when the code point

> encoded using ASCII would, if converted to Unicode, be illegal (for
> whatever reason) in the YANG string. =A0It's probably best to keep=
 the

> SNMP instrumentation ignorant of all this, so code in the Netconf side=


> would need determine whether any of the ASCII "escape sequences&q=
uot;

> would produce forbidden code points, and, in such cases, *not* evaluat=
e

> those sequences and just pass them through unevaluated.

>

>

> > Also, just to make sure, we are talking about:

> >

> > =A0 =A0system/location =A0 =A0 =A0 =A0-- sysLocation

> > =A0 =A0system/contact =A0 =A0 =A0 =A0 -- sysContact

> > =A0 =A0interface/description =A0-- ifAlias

>

> Perhaps also sysDescr (even though read-only, my comment above seems
> applicable,

> particularly since on at least some systems this comes from a static
> configuration

> file, and would be useful to support local language in some minimal wa=
y.)

>

> sysName (think IDN) might also be worth thinking about. =A0There was a=
 long

> debate

> about this a while back; I don't know what current thinking is.
>

> Randy

>

> _______________________________________________

> 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





--089e0149d2c448e9b404ed598cbb--

From lhotka@nic.cz  Thu Dec 12 09:32:03 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942A01ADF4E for ; Thu, 12 Dec 2013 09:32:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osIe1b_Cvi6u for ; Thu, 12 Dec 2013 09:32:00 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6501ADF12 for ; Thu, 12 Dec 2013 09:32:00 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9DF7813FACF; Thu, 12 Dec 2013 18:31:53 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386869514; bh=/yKQWpzR4S6ratnSpkQc3eq6PjlsIe8oWKzQiFlzZHg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=A3c3waxFsAKyWgQTapBWY8krI5Uzl3wpFIqiirr2vFNrynppf4DLu6wSUGMGuo3YO MUjmbKUeHYq8T23gTdndt0AfvVfD23yIRb+QcXUeiuQ7clFmdYfxpyh75ghVOsGCRS ZmHnATHAMFZwpbP/pgBCiQYRCDLn2AKy8I/44WS8=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Thu, 12 Dec 2013 18:31:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com> <001b01cef716$295e2520$6b01a8c0@oemcomputer> <004a01cef75c$b8610120$29230360$@comcast.net> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.1822)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 17:32:03 -0000

Hi,

just an idea: would it help if the server simply records the mapped =
DisplayString version in state data?

Lada

On 12 Dec 2013, at 18:19, Andy Bierman  wrote:

> Hi,
>=20
> What if these objects do not have corresponding SNMP values on the =
device?
> What if the device does not implement SNMP?
>=20
> Are you suggesting we need duplicate versions for devices that do =
support SNMP,
> with an "if-feature snmp" statement to make it conditional?  What does =
it mean
> if the 2 variants have different values?
>=20
> I think the new proposed text forces a device to limit the object to =
7-bit ASCII
> if the SNMP version of the object is supported.
>=20
> It seems old syntax is being forced on devices, not new syntax.
>=20
>=20
> Andy
>=20
> On Thu, Dec 12, 2013 at 9:08 AM, ietfdbh  wrote:
> Hi,
>=20
> Personally, I think it would be simpler to just have the YANG objects =
be
> constrained by DisplayString syntax, but then, I come from a country =
where
> 7-bit ASCII covers my language of choice. It would be nice to have a
> consistent underlying instrumentation without duplication of effort =
and
> resources, but that would require choosing the least common =
denominator
> (DisplayString).
>=20
> My second choice would be to treat them as separate instances, one of
> DisplayString syntax, one of YANG string syntax. That way, we don't =
have to
> worry about side effects of changing the YANG object via the MIB, or
> changing the MIB object via YANG. If we want to internationalize the =
syntax,
> you cannot do that to the MIB within SMI limits. Mapping between them =
if
> they support different syntax raises a whole lot of issues for the =
database
> handling and UI of an NMS, stands the chance of breaking existing
> implementations if implementers handle the translations wrong or in a
> non-interoperable manner, and stands the chance of misleading =
operators (and
> applications) if the value of the MIB object is changed dynamically =
because
> the value is changed (in any way) via translation from the YANG =
object.
>=20
> I think it would be better for standardization and interoperability if =
we do
> not try to force-feed new syntax into the existing MIB object(s). If =
you
> were trying to do this by updating the MIB, you would most certainly =
need to
> define a new object (much like we had to do with Counter64s to replace
> Counter32s). If the YANG object is treated as a separate object from =
the MIB
> object, then if and when the MIB is updated, the MIB can add an object =
to
> map to the YANG object, and deprecate the DisplayString syntax object.
>=20
> If the YANG object says it can be mapped, then I think the YANG object =
must
> REQUIRE that it be implemented with DisplayString constraints, whether =
a
> server implementation maps to the MIB or not. Assuming an NMS supports =
both
> MIB and YANG queries, and an implementer MAY treat them as separate, =
then
> the NMS must treat them as separate. If the implementer MAY treat them =
as
> mapped, the NMS still needs to implement them as separate because they =
MAY
> be separate, but the NMS probably must treat the NMS-side variables as
> mapped to ensure they are in sync; otherwise reading the value via the =
MIB
> without simultaneously reading the value via YANG would lead to the =
NMS
> potentially displaying different values even though on the device the =
values
> are the same. This optionality greatly increases the complexity of
> implementing these objects on the NMS side. An NMS would need to =
determine
> whether the agent/server implemented these as mapped or separate, =
presumably
> by changing one and seeing if it affected the other, so it knew =
whether to
> try to perform synchronization between the two. Lots of work for =
limited
> benefit to the operator. And if NMS implementations handled =
synchronization
> differently, the operator is stuck trying to manage with conflicting
> information from different NMSs.
>=20
> It would be much better to standardize the expectation - either these
> objects MUST be mapped and constrained by DisplayString syntax per the =
IETF,
> or MUST be defined as separate objects of different syntax per the =
IETF
> standard. Then an NMS implementer knows what to expect.
>=20
> David Harrington
> ietfdbh@comcast.net
> +1-603-828-1401
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy
> > Presuhn
> > Sent: Thursday, December 12, 2013 3:43 AM
> > To: Martin Bjorklund
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> >
> > Hi -
> >
> > > From: "Martin Bjorklund" 
> > > To: 
> > > Cc: ; 
> > > Sent: Wednesday, December 11, 2013 11:52 PM
> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > >
> > > Randy Presuhn  wrote:
> > > > Hi -
> > > >
> > > > >From: Juergen Schoenwaelder  > university.de>
> > > > >Sent: Dec 11, 2013 12:38 AM
> > > > >To: Randy Presuhn 
> > > > >Cc: netmod@ietf.org
> > > > >Subject: Re: [netmod] AD review of =
draft-ietf-netmod-system-mgmt
> > > > >
> > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > > >
> > > > >> > Anyway, for a standardized approach, someone would have to =
write
> > a
> > > > >> > document that defines how unicode code points are =
represented as
> > > > >> > escaped charater sequences in DisplayStrings. I do not =
think that
> this
> > > > >> > document is in charge of doing this. Hence, until such a =
standard
> is
> > > > >> > written, I think things need to be implementation specific.
> > > > >>
> > > > >> Perhaps, though that is the route to being stuck with ASCII =
until
> the
> > > > >> successor to Netconf rolls along.
> > > > >
> > > > >Not necessarily. If you configure via NETCONF (or most CLIs =
these
> > > > >days), you can use unicode characters. The code that maps names =
to
> > > > >legacy non-unicode interfaces then needs to do suitable =
translations
> > > > >to fit whatever constraint there is.
> > > >
> > > > Not if the data definition restricts the values to an ASCII
> > > > subset, as has been proposed.  What's in the draft at the
> > > > moment will bring its own interoperability problems, but
> > > > at least it's a baby step forward.
> > >
> > > So it seems we have a chance to fix this now.  But I need to
> > > understand what exactly you and/or Juergen propose.  Preferrably
> > > concrete text.  I *think* that the proposal is something like =
this:
> > >
> > >    o  An implementation MUST allow any legal "string" (YANG =
string).
> >
> > There are good reasons to restrict formatting and control characters =
-
> > I'll assume YANG strings do this already.  If not, that's another =
long
> > discussion.
> >
> > >    o  An implementation that maps this value to the corresponding =
MIB
> > >       object, which has size and character set limitations, MUST =
use
> > >       some mechanism out of the scope for this document to ensure =
that
> > >       the MIB object syntax is still valid.
> >
> > Yes this seems reasonable.
> >
> > But it doesn't cover a "round trip".  If the value is modified via =
the MIB
> > interface to include what looks like the implementation-specific =
encoding
> > into ASCII of a non-ASCII Unicode code point, does retrieving that =
value
> > via the Netconf interface get the Unicode code point or the
> implementation-
> > specific ASCII encoding of it?  If it does (and I think it should) =
then
> there
> > needs to be some though put into what happens when the code point
> > encoded using ASCII would, if converted to Unicode, be illegal (for
> > whatever reason) in the YANG string.  It's probably best to keep the
> > SNMP instrumentation ignorant of all this, so code in the Netconf =
side
> > would need determine whether any of the ASCII "escape sequences"
> > would produce forbidden code points, and, in such cases, *not* =
evaluate
> > those sequences and just pass them through unevaluated.
> >
> >
> > > Also, just to make sure, we are talking about:
> > >
> > >    system/location        -- sysLocation
> > >    system/contact         -- sysContact
> > >    interface/description  -- ifAlias
> >
> > Perhaps also sysDescr (even though read-only, my comment above seems
> > applicable,
> > particularly since on at least some systems this comes from a static
> > configuration
> > file, and would be useful to support local language in some minimal =
way.)
> >
> > sysName (think IDN) might also be worth thinking about.  There was a =
long
> > debate
> > about this a while back; I don't know what current thinking is.
> >
> > Randy
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From andy@yumaworks.com  Thu Dec 12 09:51:28 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2D31AE39C for ; Thu, 12 Dec 2013 09:51:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqpqjZWPxEbp for ; Thu, 12 Dec 2013 09:51:23 -0800 (PST)
Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3709D1ADE86 for ; Thu, 12 Dec 2013 09:51:23 -0800 (PST)
Received: by mail-qc0-f175.google.com with SMTP id e9so593274qcy.34 for ; Thu, 12 Dec 2013 09:51:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=33Ms22TNA+Kr4LkRaiEhDhB2uZpum66HT96a6zoZ5IE=; b=QeekJUhtCNotI5Kkg6hpudlQMBJFPjEAGyJ2V72IRVfOaitdmQLjAV7DDsKRgzXEQm fz+yXRdTe1dm1XtCdkhbo//ml/OE5cdgMtu6obKOn+wlpBmS+h3YznuGSdVCeUAadx6m p3pIQfHxZEsvgpFbGz/j4BSce15ef0jfvlSBm7diaiGcqA7tDjxXVAXvQCb/oj96uwIb 3cO4bQEvqSXZwkh0Smm3BxZ6OPVv17JDD5q4VD8XIqm5ELD6aSYu42kkStZecDygo05x HorTWBr8qyTqEi6NHlllbs6V3fmSl4f8SzDylppoSJ8U7tIxbAF6Zoj3OjMNHd6ruvMF eBew==
X-Gm-Message-State: ALoCoQn2WFM1k5D7sE/pLUeQEGojAU8HHnOhOQwbgqHbo+5ovI6u5P/RQ+jyEOWhUNutZfUfEqHy
MIME-Version: 1.0
X-Received: by 10.49.94.177 with SMTP id dd17mr15865438qeb.14.1386870676939; Thu, 12 Dec 2013 09:51:16 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 12 Dec 2013 09:51:16 -0800 (PST)
In-Reply-To: 
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com> <001b01cef716$295e2520$6b01a8c0@oemcomputer> <004a01cef75c$b8610120$29230360$@comcast.net>  
Date: Thu, 12 Dec 2013 09:51:16 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=047d7b6731b20c947804ed59fed4
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 17:51:28 -0000

--047d7b6731b20c947804ed59fed4
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka  wrote:

> Hi,
>
> just an idea: would it help if the server simply records the mapped
> DisplayString version in state data?
>
>
No.  I am OK with the proposal to force the server to constrain the objects
to DisplayString if the device supports the SNMP objects.
I prefer that the  request get rejected with an 'invalid-value' error
than lie and return .  The configured value is never going
to be a valid value on a device that supports SNMP. I am not
a big fan of separate config and state versions of the same object,
especially since the protocol has no real way to discover why the
operational value is different than the configured value.





> Lada
>
>

Andy


On 12 Dec 2013, at 18:19, Andy Bierman  wrote:
>
> > Hi,
> >
> > What if these objects do not have corresponding SNMP values on the
> device?
> > What if the device does not implement SNMP?
> >
> > Are you suggesting we need duplicate versions for devices that do
> support SNMP,
> > with an "if-feature snmp" statement to make it conditional?  What does
> it mean
> > if the 2 variants have different values?
> >
> > I think the new proposed text forces a device to limit the object to
> 7-bit ASCII
> > if the SNMP version of the object is supported.
> >
> > It seems old syntax is being forced on devices, not new syntax.
> >
> >
> > Andy
> >
> > On Thu, Dec 12, 2013 at 9:08 AM, ietfdbh  wrote:
> > Hi,
> >
> > Personally, I think it would be simpler to just have the YANG objects be
> > constrained by DisplayString syntax, but then, I come from a country
> where
> > 7-bit ASCII covers my language of choice. It would be nice to have a
> > consistent underlying instrumentation without duplication of effort and
> > resources, but that would require choosing the least common denominator
> > (DisplayString).
> >
> > My second choice would be to treat them as separate instances, one of
> > DisplayString syntax, one of YANG string syntax. That way, we don't have
> to
> > worry about side effects of changing the YANG object via the MIB, or
> > changing the MIB object via YANG. If we want to internationalize the
> syntax,
> > you cannot do that to the MIB within SMI limits. Mapping between them if
> > they support different syntax raises a whole lot of issues for the
> database
> > handling and UI of an NMS, stands the chance of breaking existing
> > implementations if implementers handle the translations wrong or in a
> > non-interoperable manner, and stands the chance of misleading operators
> (and
> > applications) if the value of the MIB object is changed dynamically
> because
> > the value is changed (in any way) via translation from the YANG object.
> >
> > I think it would be better for standardization and interoperability if
> we do
> > not try to force-feed new syntax into the existing MIB object(s). If you
> > were trying to do this by updating the MIB, you would most certainly
> need to
> > define a new object (much like we had to do with Counter64s to replace
> > Counter32s). If the YANG object is treated as a separate object from the
> MIB
> > object, then if and when the MIB is updated, the MIB can add an object to
> > map to the YANG object, and deprecate the DisplayString syntax object.
> >
> > If the YANG object says it can be mapped, then I think the YANG object
> must
> > REQUIRE that it be implemented with DisplayString constraints, whether a
> > server implementation maps to the MIB or not. Assuming an NMS supports
> both
> > MIB and YANG queries, and an implementer MAY treat them as separate, then
> > the NMS must treat them as separate. If the implementer MAY treat them as
> > mapped, the NMS still needs to implement them as separate because they
> MAY
> > be separate, but the NMS probably must treat the NMS-side variables as
> > mapped to ensure they are in sync; otherwise reading the value via the
> MIB
> > without simultaneously reading the value via YANG would lead to the NMS
> > potentially displaying different values even though on the device the
> values
> > are the same. This optionality greatly increases the complexity of
> > implementing these objects on the NMS side. An NMS would need to
> determine
> > whether the agent/server implemented these as mapped or separate,
> presumably
> > by changing one and seeing if it affected the other, so it knew whether
> to
> > try to perform synchronization between the two. Lots of work for limited
> > benefit to the operator. And if NMS implementations handled
> synchronization
> > differently, the operator is stuck trying to manage with conflicting
> > information from different NMSs.
> >
> > It would be much better to standardize the expectation - either these
> > objects MUST be mapped and constrained by DisplayString syntax per the
> IETF,
> > or MUST be defined as separate objects of different syntax per the IETF
> > standard. Then an NMS implementer knows what to expect.
> >
> > David Harrington
> > ietfdbh@comcast.net
> > +1-603-828-1401
> > > -----Original Message-----
> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy
> > > Presuhn
> > > Sent: Thursday, December 12, 2013 3:43 AM
> > > To: Martin Bjorklund
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > >
> > > Hi -
> > >
> > > > From: "Martin Bjorklund" 
> > > > To: 
> > > > Cc: ; 
> > > > Sent: Wednesday, December 11, 2013 11:52 PM
> > > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > >
> > > > Randy Presuhn  wrote:
> > > > > Hi -
> > > > >
> > > > > >From: Juergen Schoenwaelder  > > university.de>
> > > > > >Sent: Dec 11, 2013 12:38 AM
> > > > > >To: Randy Presuhn 
> > > > > >Cc: netmod@ietf.org
> > > > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > > > >
> > > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > > > >
> > > > > >> > Anyway, for a standardized approach, someone would have to
> write
> > > a
> > > > > >> > document that defines how unicode code points are represented
> as
> > > > > >> > escaped charater sequences in DisplayStrings. I do not think
> that
> > this
> > > > > >> > document is in charge of doing this. Hence, until such a
> standard
> > is
> > > > > >> > written, I think things need to be implementation specific.
> > > > > >>
> > > > > >> Perhaps, though that is the route to being stuck with ASCII
> until
> > the
> > > > > >> successor to Netconf rolls along.
> > > > > >
> > > > > >Not necessarily. If you configure via NETCONF (or most CLIs these
> > > > > >days), you can use unicode characters. The code that maps names to
> > > > > >legacy non-unicode interfaces then needs to do suitable
> translations
> > > > > >to fit whatever constraint there is.
> > > > >
> > > > > Not if the data definition restricts the values to an ASCII
> > > > > subset, as has been proposed.  What's in the draft at the
> > > > > moment will bring its own interoperability problems, but
> > > > > at least it's a baby step forward.
> > > >
> > > > So it seems we have a chance to fix this now.  But I need to
> > > > understand what exactly you and/or Juergen propose.  Preferrably
> > > > concrete text.  I *think* that the proposal is something like this:
> > > >
> > > >    o  An implementation MUST allow any legal "string" (YANG string).
> > >
> > > There are good reasons to restrict formatting and control characters -
> > > I'll assume YANG strings do this already.  If not, that's another long
> > > discussion.
> > >
> > > >    o  An implementation that maps this value to the corresponding MIB
> > > >       object, which has size and character set limitations, MUST use
> > > >       some mechanism out of the scope for this document to ensure
> that
> > > >       the MIB object syntax is still valid.
> > >
> > > Yes this seems reasonable.
> > >
> > > But it doesn't cover a "round trip".  If the value is modified via the
> MIB
> > > interface to include what looks like the implementation-specific
> encoding
> > > into ASCII of a non-ASCII Unicode code point, does retrieving that
> value
> > > via the Netconf interface get the Unicode code point or the
> > implementation-
> > > specific ASCII encoding of it?  If it does (and I think it should) then
> > there
> > > needs to be some though put into what happens when the code point
> > > encoded using ASCII would, if converted to Unicode, be illegal (for
> > > whatever reason) in the YANG string.  It's probably best to keep the
> > > SNMP instrumentation ignorant of all this, so code in the Netconf side
> > > would need determine whether any of the ASCII "escape sequences"
> > > would produce forbidden code points, and, in such cases, *not* evaluate
> > > those sequences and just pass them through unevaluated.
> > >
> > >
> > > > Also, just to make sure, we are talking about:
> > > >
> > > >    system/location        -- sysLocation
> > > >    system/contact         -- sysContact
> > > >    interface/description  -- ifAlias
> > >
> > > Perhaps also sysDescr (even though read-only, my comment above seems
> > > applicable,
> > > particularly since on at least some systems this comes from a static
> > > configuration
> > > file, and would be useful to support local language in some minimal
> way.)
> > >
> > > sysName (think IDN) might also be worth thinking about.  There was a
> long
> > > debate
> > > about this a while back; I don't know what current thinking is.
> > >
> > > Randy
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--047d7b6731b20c947804ed59fed4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:


Hi,



just an idea: would it help if the server simply records the mapped Display=
String version in state data?



No. =A0I am OK with the proposal to fo=
rce the server to constrain the objects
to DisplayString if the d=
evice supports the SNMP objects.
I prefer that the <rpc> re=
quest get rejected with an 'invalid-value' error


than lie and return <ok>. =A0The configured value is never going=

to be a valid value on a device that supports SNMP. I am not
a big fan of separate config and state versions of the same object,<=
/div>

especially since the protocol has no real way to discover why the
operational value is different than the configured value.
<=
br>


=A0


Lada



=A0
Andy



On 12 Dec 2013, at 18:19, Andy Bierman <andy@yumaworks.com> wrote:



> Hi,

>

> What if these objects do not have corresponding SNMP values on the dev=
ice?

> What if the device does not implement SNMP?

>

> Are you suggesting we need duplicate versions for devices that do supp=
ort SNMP,

> with an "if-feature snmp" statement to make it conditional? =
=A0What does it mean

> if the 2 variants have different values?

>

> I think the new proposed text forces a device to limit the object to 7=
-bit ASCII

> if the SNMP version of the object is supported.

>

> It seems old syntax is being forced on devices, not new syntax.

>

>

> Andy

>

> On Thu, Dec 12, 2013 at 9:08 AM, ietfdbh <ietfdbh@comcast.net> wrote:

> Hi,

>

> Personally, I think it would be simpler to just have the YANG objects =
be

> constrained by DisplayString syntax, but then, I come from a country w=
here

> 7-bit ASCII covers my language of choice. It would be nice to have a
> consistent underlying instrumentation without duplication of effort an=
d

> resources, but that would require choosing the least common denominato=
r

> (DisplayString).

>

> My second choice would be to treat them as separate instances, one of<=
br>
> DisplayString syntax, one of YANG string syntax. That way, we don'=
t have to

> worry about side effects of changing the YANG object via the MIB, or
> changing the MIB object via YANG. If we want to internationalize the s=
yntax,

> you cannot do that to the MIB within SMI limits. Mapping between them =
if

> they support different syntax raises a whole lot of issues for the dat=
abase

> handling and UI of an NMS, stands the chance of breaking existing

> implementations if implementers handle the translations wrong or in a<=
br>
> non-interoperable manner, and stands the chance of misleading operator=
s (and

> applications) if the value of the MIB object is changed dynamically be=
cause

> the value is changed (in any way) via translation from the YANG object=
.

>

> I think it would be better for standardization and interoperability if=
 we do

> not try to force-feed new syntax into the existing MIB object(s). If y=
ou

> were trying to do this by updating the MIB, you would most certainly n=
eed to

> define a new object (much like we had to do with Counter64s to replace=


> Counter32s). If the YANG object is treated as a separate object from t=
he MIB

> object, then if and when the MIB is updated, the MIB can add an object=
 to

> map to the YANG object, and deprecate the DisplayString syntax object.=


>

> If the YANG object says it can be mapped, then I think the YANG object=
 must

> REQUIRE that it be implemented with DisplayString constraints, whether=
 a

> server implementation maps to the MIB or not. Assuming an NMS supports=
 both

> MIB and YANG queries, and an implementer MAY treat them as separate, t=
hen

> the NMS must treat them as separate. If the implementer MAY treat them=
 as

> mapped, the NMS still needs to implement them as separate because they=
 MAY

> be separate, but the NMS probably must treat the NMS-side variables as=


> mapped to ensure they are in sync; otherwise reading the value via the=
 MIB

> without simultaneously reading the value via YANG would lead to the NM=
S

> potentially displaying different values even though on the device the =
values

> are the same. This optionality greatly increases the complexity of

> implementing these objects on the NMS side. An NMS would need to deter=
mine

> whether the agent/server implemented these as mapped or separate, pres=
umably

> by changing one and seeing if it affected the other, so it knew whethe=
r to

> try to perform synchronization between the two. Lots of work for limit=
ed

> benefit to the operator. And if NMS implementations handled synchroniz=
ation

> differently, the operator is stuck trying to manage with conflicting
> information from different NMSs.

>

> It would be much better to standardize the expectation - either these<=
br>
> objects MUST be mapped and constrained by DisplayString syntax per the=
 IETF,

> or MUST be defined as separate objects of different syntax per the IET=
F

> standard. Then an NMS implementer knows what to expect.

>

> David Harrington

> ietfdbh@comcast.net

> +1-603-828-1401

> > -----Original Message-----

> > From: netmod [mailto:n=
etmod-bounces@ietf.org] On Behalf Of Randy

> > Presuhn

> > Sent: Thursday, December 12, 2013 3:43 AM

> > To: Martin Bjorklund

> > Cc: netmod@ietf.org

> > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt<=
br>
> >

> > Hi -

> >

> > > From: "Martin Bjorklund" <mbj@tail-f.com>

> > > To: <rand=
y_presuhn@mindspring.com>

> > > Cc: <j.schoenwaelder@jacobs-university.de>; <netmod@ietf.org>

> > > Sent: Wednesday, December 11, 2013 11:52 PM

> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-=
mgmt

> > >

> > > Randy Presuhn <randy_presuhn@mindspring.com> wrote:

> > > > Hi -

> > > >

> > > > >From: Juergen Schoenwaelder <j.schoenwaelder@jac=
obs-

> > university.de<=
/a>>

> > > > >Sent: Dec 11, 2013 12:38 AM

> > > > >To: Randy Presuhn <randy_presuhn@mindspring.com>

> > > > >Cc: netmod@ietf.=
org

> > > > >Subject: Re: [netmod] AD review of draft-ietf-netmo=
d-system-mgmt

> > > > >

> > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Pre=
suhn wrote:

> > > > >

> > > > >> > Anyway, for a standardized approach, some=
one would have to write

> > a

> > > > >> > document that defines how unicode code po=
ints are represented as

> > > > >> > escaped charater sequences in DisplayStri=
ngs. I do not think that

> this

> > > > >> > document is in charge of doing this. Henc=
e, until such a standard

> is

> > > > >> > written, I think things need to be implem=
entation specific.

> > > > >>

> > > > >> Perhaps, though that is the route to being stu=
ck with ASCII until

> the

> > > > >> successor to Netconf rolls along.

> > > > >

> > > > >Not necessarily. If you configure via NETCONF (or m=
ost CLIs these

> > > > >days), you can use unicode characters. The code tha=
t maps names to

> > > > >legacy non-unicode interfaces then needs to do suit=
able translations

> > > > >to fit whatever constraint there is.

> > > >

> > > > Not if the data definition restricts the values to an A=
SCII

> > > > subset, as has been proposed. =A0What's in the draf=
t at the

> > > > moment will bring its own interoperability problems, bu=
t

> > > > at least it's a baby step forward.

> > >

> > > So it seems we have a chance to fix this now. =A0But I need =
to

> > > understand what exactly you and/or Juergen propose. =A0Prefe=
rrably

> > > concrete text. =A0I *think* that the proposal is something l=
ike this:

> > >

> > > =A0 =A0o =A0An implementation MUST allow any legal "str=
ing" (YANG string).

> >

> > There are good reasons to restrict formatting and control charact=
ers -

> > I'll assume YANG strings do this already. =A0If not, that'=
;s another long

> > discussion.

> >

> > > =A0 =A0o =A0An implementation that maps this value to the co=
rresponding MIB

> > > =A0 =A0 =A0 object, which has size and character set limitat=
ions, MUST use

> > > =A0 =A0 =A0 some mechanism out of the scope for this documen=
t to ensure that

> > > =A0 =A0 =A0 the MIB object syntax is still valid.

> >

> > Yes this seems reasonable.

> >

> > But it doesn't cover a "round trip". =A0If the valu=
e is modified via the MIB

> > interface to include what looks like the implementation-specific =
encoding

> > into ASCII of a non-ASCII Unicode code point, does retrieving tha=
t value

> > via the Netconf interface get the Unicode code point or the

> implementation-

> > specific ASCII encoding of it? =A0If it does (and I think it shou=
ld) then

> there

> > needs to be some though put into what happens when the code point=


> > encoded using ASCII would, if converted to Unicode, be illegal (f=
or

> > whatever reason) in the YANG string. =A0It's probably best to=
 keep the

> > SNMP instrumentation ignorant of all this, so code in the Netconf=
 side

> > would need determine whether any of the ASCII "escape sequen=
ces"

> > would produce forbidden code points, and, in such cases, *not* ev=
aluate

> > those sequences and just pass them through unevaluated.

> >

> >

> > > Also, just to make sure, we are talking about:

> > >

> > > =A0 =A0system/location =A0 =A0 =A0 =A0-- sysLocation

> > > =A0 =A0system/contact =A0 =A0 =A0 =A0 -- sysContact

> > > =A0 =A0interface/description =A0-- ifAlias

> >

> > Perhaps also sysDescr (even though read-only, my comment above se=
ems

> > applicable,

> > particularly since on at least some systems this comes from a sta=
tic

> > configuration

> > file, and would be useful to support local language in some minim=
al way.)

> >

> > sysName (think IDN) might also be worth thinking about. =A0There =
was a long

> > debate

> > about this a while back; I don't know what current thinking i=
s.

> >

> > Randy

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/netmod

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--047d7b6731b20c947804ed59fed4--

From ietfdbh@comcast.net  Thu Dec 12 10:12:13 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713F81AE00E for ; Thu, 12 Dec 2013 10:12:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYkkGr0N0-VV for ; Thu, 12 Dec 2013 10:12:06 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id E06D31ADDCA for ; Thu, 12 Dec 2013 10:12:05 -0800 (PST)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id 0eCK1n0061uE5Es54iBzV9; Thu, 12 Dec 2013 18:11:59 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta16.westchester.pa.mail.comcast.net with comcast id 0iBz1n0092yZEBF3ciBzin; Thu, 12 Dec 2013 18:11:59 +0000
From: "ietfdbh" 
To: "'Andy Bierman'" 
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net>	<20131212.085209.387856404.mbj@tail-f.com>	<001b01cef716$295e2520$6b01a8c0@oemcomputer>	<004a01cef75c$b8610120$29230360$@comcast.net> 
In-Reply-To: 
Date: Thu, 12 Dec 2013 13:11:55 -0500
Message-ID: <006201cef765$a461e640$ed25b2c0$@comcast.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01CEF73B.BB910E60"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHRWvhskhnOaPbMPUajuprGlXhfOwJKF7QAAdpcncgBqti1+wGEM/uhmhFraeA=
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386871919; bh=yQM7u40mlTuRNOGZT4E3aRUPY2H3usA1OPVz0SBuDTU=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=NagG7EP7gPLphSwGRC58w+ZuJHsP57otDxt2emmbKLdZwBFUAv4n2COtsJMQkdGAd j/ohe3o1XcHqLyYGGj0lVwn5GDFb3pDArSwcX7AGQVQ+pYj3dV/FvbTdhxYg3T8dNA haArUiukjQLrqtW5nLLxD8hL8ydlWiFCNpdlavY14KMucPlOSn9L/cEs+RgC9+8JGC OSA1G/JzNrgC+TflQnjOpmmXX6HFcd1JYd322PC7rZPJ7cskdrHA6pN8ZrmE5gZlrE Da/M4Cl9rZRxWDyJ6V2UVrTf362R8SiGydWPRSWNaj5u0sEFQUyqcBkXsbt7Zt6l+C 2/g4GWb6JmLkg==
Cc: 'Randy Presuhn' , netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 18:12:13 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0063_01CEF73B.BB910E60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

 

Comments inline

 

David Harrington

  ietfdbh@comcast.net

+1-603-828-1401

From: Andy Bierman [mailto:andy@yumaworks.com] 
Sent: Thursday, December 12, 2013 12:19 PM
To: ietfdbh
Cc: Randy Presuhn; Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt

 

Hi,

 

What if these objects do not have corresponding SNMP values on the device?

What if the device does not implement SNMP?

 

I don't really care whether SNMP is implemented on the device or not.

I care about standardizing consistent syntax for the YANG object.

 

Are you suggesting we need duplicate versions for devices that do support
SNMP,

with an "if-feature snmp" statement to make it conditional?  

 

Absolutely not. I am saying the syntax should not be conditional. Period. No
if-feature needed.

 

Either make the syntax of the YANG object the same as DisplayString (which
would force old syntax on new implementations, sometimes unnecessarily from
a device perspective, but would allow mapping) or make it two separate
objects with different syntax (to support internationalization in the newer
standard, while the old object supports the old syntax, and it doesn't
support mapping by the implementation). 

 

Making it optional is a problem for the NMS side which has to support
multiple devices that are allowed to make different implementation choices
for the same object. 

Making it optional is a problem for the device side which has to deal with
translations between values of different syntax.

Allowing the objects to be separate OR mapped, and allowing side-effects to
change the values seems especially problematic from a synchronization
standpoint for the NMS (and the operators) who have to consider the results
of queries by two different protocols of the MAYBE-MAYBENOT-mapped objects.

 

Get rid of the optionality. Standardize the syntax of the YANG object one
way or the other.

 

What does it mean

if the 2 variants have different values?

 

If they are separate variables, they can have different values and different
syntax. No big deal.

If the **operator** wants them to be the same value, they limit themselves
to DisplayString syntax when setting the YANG object, and it is their
responsibility to keep the two variables in sync, not the implementer's
responsibility.

If the **operator** wants internationalized YANG names, they can with YANG
strings.

If the **operator** wants internationalized MIB names, too bad; the MIB
standard doesn't permit that. 

 

I think the new proposed text forces a device to limit the object to 7-bit
ASCII

if the SNMP version of the object is supported.

 

It seems old syntax is being forced on devices, not new syntax.


If you don't want the new object to be constrained by old syntax, then make
it a separate object, unconstrained by any mapping to the standard MIB
object.

>From the perspective of this NMS developer, I would MUCH prefer separate
objects, each with a consistently standardized syntax, over separate objects
for whom the syntax may or may not be the same. 

 

The operators who spoke up around the time of rfc3535 said they don't trust
applications to necessarily get things right, so asking the implementations
to do some type of automated lossless translation between objects of
different syntax and size sounds like you're asking for trouble.


Andy

 

On Thu, Dec 12, 2013 at 9:08 AM, ietfdbh  wrote:

Hi,

Personally, I think it would be simpler to just have the YANG objects be
constrained by DisplayString syntax, but then, I come from a country where
7-bit ASCII covers my language of choice. It would be nice to have a
consistent underlying instrumentation without duplication of effort and
resources, but that would require choosing the least common denominator
(DisplayString).

My second choice would be to treat them as separate instances, one of
DisplayString syntax, one of YANG string syntax. That way, we don't have to
worry about side effects of changing the YANG object via the MIB, or
changing the MIB object via YANG. If we want to internationalize the syntax,
you cannot do that to the MIB within SMI limits. Mapping between them if
they support different syntax raises a whole lot of issues for the database
handling and UI of an NMS, stands the chance of breaking existing
implementations if implementers handle the translations wrong or in a
non-interoperable manner, and stands the chance of misleading operators (and
applications) if the value of the MIB object is changed dynamically because
the value is changed (in any way) via translation from the YANG object.

I think it would be better for standardization and interoperability if we do
not try to force-feed new syntax into the existing MIB object(s). If you
were trying to do this by updating the MIB, you would most certainly need to
define a new object (much like we had to do with Counter64s to replace
Counter32s). If the YANG object is treated as a separate object from the MIB
object, then if and when the MIB is updated, the MIB can add an object to
map to the YANG object, and deprecate the DisplayString syntax object.

If the YANG object says it can be mapped, then I think the YANG object must
REQUIRE that it be implemented with DisplayString constraints, whether a
server implementation maps to the MIB or not. Assuming an NMS supports both
MIB and YANG queries, and an implementer MAY treat them as separate, then
the NMS must treat them as separate. If the implementer MAY treat them as
mapped, the NMS still needs to implement them as separate because they MAY
be separate, but the NMS probably must treat the NMS-side variables as
mapped to ensure they are in sync; otherwise reading the value via the MIB
without simultaneously reading the value via YANG would lead to the NMS
potentially displaying different values even though on the device the values
are the same. This optionality greatly increases the complexity of
implementing these objects on the NMS side. An NMS would need to determine
whether the agent/server implemented these as mapped or separate, presumably
by changing one and seeing if it affected the other, so it knew whether to
try to perform synchronization between the two. Lots of work for limited
benefit to the operator. And if NMS implementations handled synchronization
differently, the operator is stuck trying to manage with conflicting
information from different NMSs.

It would be much better to standardize the expectation - either these
objects MUST be mapped and constrained by DisplayString syntax per the IETF,
or MUST be defined as separate objects of different syntax per the IETF
standard. Then an NMS implementer knows what to expect.

David Harrington
ietfdbh@comcast.net
+1-603-828-1401
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy
> Presuhn
> Sent: Thursday, December 12, 2013 3:43 AM
> To: Martin Bjorklund
> Cc: netmod@ietf.org
> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
> Hi -
>
> > From: "Martin Bjorklund" 
> > To: 
> > Cc: ; 
> > Sent: Wednesday, December 11, 2013 11:52 PM
> > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> >
> > Randy Presuhn  wrote:
> > > Hi -
> > >
> > > >From: Juergen Schoenwaelder  
> university.de>
> > > >Sent: Dec 11, 2013 12:38 AM
> > > >To: Randy Presuhn 
> > > >Cc: netmod@ietf.org
> > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > >
> > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > >
> > > >> > Anyway, for a standardized approach, someone would have to write
> a
> > > >> > document that defines how unicode code points are represented as
> > > >> > escaped charater sequences in DisplayStrings. I do not think that
this
> > > >> > document is in charge of doing this. Hence, until such a standard
is
> > > >> > written, I think things need to be implementation specific.
> > > >>
> > > >> Perhaps, though that is the route to being stuck with ASCII until
the
> > > >> successor to Netconf rolls along.
> > > >
> > > >Not necessarily. If you configure via NETCONF (or most CLIs these
> > > >days), you can use unicode characters. The code that maps names to
> > > >legacy non-unicode interfaces then needs to do suitable translations
> > > >to fit whatever constraint there is.
> > >
> > > Not if the data definition restricts the values to an ASCII
> > > subset, as has been proposed.  What's in the draft at the
> > > moment will bring its own interoperability problems, but
> > > at least it's a baby step forward.
> >
> > So it seems we have a chance to fix this now.  But I need to
> > understand what exactly you and/or Juergen propose.  Preferrably
> > concrete text.  I *think* that the proposal is something like this:
> >
> >    o  An implementation MUST allow any legal "string" (YANG string).
>
> There are good reasons to restrict formatting and control characters -
> I'll assume YANG strings do this already.  If not, that's another long
> discussion.
>
> >    o  An implementation that maps this value to the corresponding MIB
> >       object, which has size and character set limitations, MUST use
> >       some mechanism out of the scope for this document to ensure that
> >       the MIB object syntax is still valid.
>
> Yes this seems reasonable.
>
> But it doesn't cover a "round trip".  If the value is modified via the MIB
> interface to include what looks like the implementation-specific encoding
> into ASCII of a non-ASCII Unicode code point, does retrieving that value
> via the Netconf interface get the Unicode code point or the
implementation-
> specific ASCII encoding of it?  If it does (and I think it should) then
there
> needs to be some though put into what happens when the code point
> encoded using ASCII would, if converted to Unicode, be illegal (for
> whatever reason) in the YANG string.  It's probably best to keep the
> SNMP instrumentation ignorant of all this, so code in the Netconf side
> would need determine whether any of the ASCII "escape sequences"
> would produce forbidden code points, and, in such cases, *not* evaluate
> those sequences and just pass them through unevaluated.
>
>
> > Also, just to make sure, we are talking about:
> >
> >    system/location        -- sysLocation
> >    system/contact         -- sysContact
> >    interface/description  -- ifAlias
>
> Perhaps also sysDescr (even though read-only, my comment above seems
> applicable,
> particularly since on at least some systems this comes from a static
> configuration
> file, and would be useful to support local language in some minimal way.)
>
> sysName (think IDN) might also be worth thinking about.  There was a long
> debate
> about this a while back; I don't know what current thinking is.
>
> Randy
>
> _______________________________________________
> 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

 


------=_NextPart_000_0063_01CEF73B.BB910E60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
 
Comments inline
 
David Harrington
ietfdbh@comca=
st.net
+1-603-828-1401
From:=
 =
Andy Bierman [mailto:andy@yumaworks.com] 
Sent: Thursday, =
December 12, 2013 12:19 PM
To: ietfdbh
Cc: Randy =
Presuhn; Martin Bjorklund; netmod@ietf.org
Subject: Re: =
[netmod] AD review of =
draft-ietf-netmod-system-mgmt
 
Hi,
 
What if these objects do not have corresponding SNMP =
values on the device?
What =
if the device does not implement SNMP?
 
I=
 don’t really care whether SNMP is implemented on the device or =
not.
I=
 care about standardizing consistent syntax for the YANG =
object.
 
Are you suggesting we need duplicate versions for =
devices that do support SNMP,
with an "if-feature snmp" statement to make =
it conditional?  
 
A=
bsolutely not. I am saying the syntax should not be conditional. Period. =
No if-feature needed.
 
E=
ither make the syntax of the YANG object the same as DisplayString =
(which would force old syntax on new implementations, sometimes =
unnecessarily from a device perspective, but would allow mapping) or =
make it two separate objects with different syntax (to support =
internationalization in the newer standard, while the old object =
supports the old syntax, and it doesn’t support mapping by the =
implementation). 
<=
o:p> 
M=
aking it optional is a problem for the NMS side which has to support =
multiple devices that are allowed to make different implementation =
choices for the same object. 
M=
aking it optional is a problem for the device side which has to deal =
with translations between values of different =
syntax.
A=
llowing the objects to be separate OR mapped, and allowing side-effects =
to change the values seems especially problematic from a synchronization =
standpoint for the NMS (and the operators) who have to consider the =
results of queries by two different protocols of the =
MAYBE-MAYBENOT-mapped objects.
<=
o:p> 
G=
et rid of the optionality. Standardize the syntax of the YANG object one =
way or the other.
 
What does it =
mean
if the 2 variants =
have different values?
 
I=
f they are separate variables, they can have different values and =
different syntax. No big deal.
I=
f the **operator** wants them to be the same value, they limit =
themselves to DisplayString syntax when setting the YANG object, and it =
is their responsibility to keep the two variables in sync, not the =
implementer’s responsibility.
I=
f the **operator** wants internationalized YANG names, they can with =
YANG strings.
I=
f the **operator** wants internationalized MIB names, too bad; the MIB =
standard doesn’t permit that. 
 
I =
think the new proposed text forces a device to limit the object to 7-bit =
ASCII
if the SNMP version =
of the object is supported.
 
It seems old syntax is being forced on devices, not =
new syntax.

If you don’t want the new object to be =
constrained by old syntax, then make it a separate object, unconstrained =
by any mapping to the standard MIB object.
From the perspective of this =
NMS developer, I would MUCH prefer separate objects, each with a =
consistently standardized syntax, over separate objects for whom the =
syntax may or may not be the same. 
 
The operators who spoke up =
around the time of rfc3535 said they don’t trust applications to =
necessarily get things right, so asking the implementations to do some =
type of automated lossless translation between objects of different =
syntax and size sounds like you’re asking for =
trouble.

Andy
 
On Thu, =
Dec 12, 2013 at 9:08 AM, ietfdbh <ietfdbh@comcast.net> wrote:
Hi,

Personally, I think it would be simpler to =
just have the YANG objects be
constrained by DisplayString syntax, =
but then, I come from a country where
7-bit ASCII covers my language =
of choice. It would be nice to have a
consistent underlying =
instrumentation without duplication of effort and
resources, but that =
would require choosing the least common =
denominator
(DisplayString).

My second choice would be to =
treat them as separate instances, one of
DisplayString syntax, one of =
YANG string syntax. That way, we don't have to
worry about side =
effects of changing the YANG object via the MIB, or
changing the MIB =
object via YANG. If we want to internationalize the syntax,
you =
cannot do that to the MIB within SMI limits. Mapping between them =
if
they support different syntax raises a whole lot of issues for the =
database
handling and UI of an NMS, stands the chance of breaking =
existing
implementations if implementers handle the translations =
wrong or in a
non-interoperable manner, and stands the chance of =
misleading operators (and
applications) if the value of the MIB =
object is changed dynamically because
the value is changed (in any =
way) via translation from the YANG object.

I think it would be =
better for standardization and interoperability if we do
not try to =
force-feed new syntax into the existing MIB object(s). If you
were =
trying to do this by updating the MIB, you would most certainly need =
to
define a new object (much like we had to do with Counter64s to =
replace
Counter32s). If the YANG object is treated as a separate =
object from the MIB
object, then if and when the MIB is updated, the =
MIB can add an object to
map to the YANG object, and deprecate the =
DisplayString syntax object.

If the YANG object says it can be =
mapped, then I think the YANG object must
REQUIRE that it be =
implemented with DisplayString constraints, whether a
server =
implementation maps to the MIB or not. Assuming an NMS supports =
both
MIB and YANG queries, and an implementer MAY treat them as =
separate, then
the NMS must treat them as separate. If the =
implementer MAY treat them as
mapped, the NMS still needs to =
implement them as separate because they MAY
be separate, but the NMS =
probably must treat the NMS-side variables as
mapped to ensure they =
are in sync; otherwise reading the value via the MIB
without =
simultaneously reading the value via YANG would lead to the =
NMS
potentially displaying different values even though on the device =
the values
are the same. This optionality greatly increases the =
complexity of
implementing these objects on the NMS side. An NMS =
would need to determine
whether the agent/server implemented these as =
mapped or separate, presumably
by changing one and seeing if it =
affected the other, so it knew whether to
try to perform =
synchronization between the two. Lots of work for limited
benefit to =
the operator. And if NMS implementations handled =
synchronization
differently, the operator is stuck trying to manage =
with conflicting
information from different NMSs.

It would be =
much better to standardize the expectation - either these
objects =
MUST be mapped and constrained by DisplayString syntax per the =
IETF,
or MUST be defined as separate objects of different syntax per =
the IETF
standard. Then an NMS implementer knows what to =
expect.

David Harrington
ietfdbh@comcast.net
+1-603-828=
-1401
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On =
Behalf Of Randy
> Presuhn
> Sent: Thursday, December 12, =
2013 3:43 AM
> To: Martin Bjorklund
> Cc: netmod@ietf.org
> Subject: Re: =
[netmod] AD review of draft-ietf-netmod-system-mgmt
>
> Hi =
-
>
> > From: "Martin Bjorklund" <mbj@tail-f.com>
> > To: =
<randy_presuhn@mindspring.com=
>
> > Cc: <j.schoenwaelder@jaco=
bs-university.de>; <netmod@ietf.org>
> > =
Sent: Wednesday, December 11, 2013 11:52 PM
> > Subject: Re: =
[netmod] AD review of draft-ietf-netmod-system-mgmt
> >
> =
> Randy Presuhn <randy_presuhn@mindspring.com=
> wrote:
> > > Hi -
> > >
> > =
> >From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-
> university.de>
> > > >Sent: Dec =
11, 2013 12:38 AM
> > > >To: Randy Presuhn <randy_presuhn@mindspring.com=
>
> > > >Cc: netmod@ietf.org
> > > =
>Subject: Re: [netmod] AD review of =
draft-ietf-netmod-system-mgmt
> > > >
> > > =
>On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn =
wrote:
> > > >
> > > >> > Anyway, =
for a standardized approach, someone would have to write
> =
a
> > > >> > document that defines how unicode code =
points are represented as
> > > >> > escaped =
charater sequences in DisplayStrings. I do not think =
that
this
> > > >> > document is in charge of =
doing this. Hence, until such a standard
is
> > > =
>> > written, I think things need to be implementation =
specific.
> > > >>
> > > >> Perhaps, =
though that is the route to being stuck with ASCII until
the
> =
> > >> successor to Netconf rolls along.
> > > =
>
> > > >Not necessarily. If you configure via NETCONF =
(or most CLIs these
> > > >days), you can use unicode =
characters. The code that maps names to
> > > >legacy =
non-unicode interfaces then needs to do suitable translations
> =
> > >to fit whatever constraint there is.
> > =
>
> > > Not if the data definition restricts the values =
to an ASCII
> > > subset, as has been proposed.  What's =
in the draft at the
> > > moment will bring its own =
interoperability problems, but
> > > at least it's a baby =
step forward.
> >
> > So it seems we have a chance to =
fix this now.  But I need to
> > understand what exactly =
you and/or Juergen propose.  Preferrably
> > concrete =
text.  I *think* that the proposal is something like this:
> =
>
> >    o  An implementation MUST allow any =
legal "string" (YANG string).
>
> There are good =
reasons to restrict formatting and control characters -
> I'll =
assume YANG strings do this already.  If not, that's another =
long
> discussion.
>
> >    o  An =
implementation that maps this value to the corresponding MIB
> =
>       object, which has size and character set =
limitations, MUST use
> >       some mechanism =
out of the scope for this document to ensure that
> >   =
    the MIB object syntax is still valid.
>
> Yes =
this seems reasonable.
>
> But it doesn't cover a =
"round trip".  If the value is modified via the =
MIB
> interface to include what looks like the =
implementation-specific encoding
> into ASCII of a non-ASCII =
Unicode code point, does retrieving that value
> via the Netconf =
interface get the Unicode code point or the
implementation-
> =
specific ASCII encoding of it?  If it does (and I think it should) =
then
there
> needs to be some though put into what happens when =
the code point
> encoded using ASCII would, if converted to =
Unicode, be illegal (for
> whatever reason) in the YANG string. =
 It's probably best to keep the
> SNMP instrumentation =
ignorant of all this, so code in the Netconf side
> would need =
determine whether any of the ASCII "escape sequences"
> =
would produce forbidden code points, and, in such cases, *not* =
evaluate
> those sequences and just pass them through =
unevaluated.
>
>
> > Also, just to make sure, we =
are talking about:
> >
> >   =
 system/location        -- sysLocation
> =
>    system/contact         -- =
sysContact
> >    interface/description  -- =
ifAlias
>
> Perhaps also sysDescr (even though read-only, my =
comment above seems
> applicable,
> particularly since on at =
least some systems this comes from a static
> =
configuration
> file, and would be useful to support local =
language in some minimal way.)
>
> sysName (think IDN) might =
also be worth thinking about.  There was a long
> =
debate
> about this a while back; I don't know what current =
thinking is.
>
> Randy
>
> =
_______________________________________________
> 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
 

------=_NextPart_000_0063_01CEF73B.BB910E60--


From andy@yumaworks.com  Thu Dec 12 10:31:20 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF691AE3C7 for ; Thu, 12 Dec 2013 10:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8Sx1jaRk6Vr for ; Thu, 12 Dec 2013 10:31:16 -0800 (PST)
Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1171AE0BE for ; Thu, 12 Dec 2013 10:31:16 -0800 (PST)
Received: by mail-qe0-f44.google.com with SMTP id nd7so675580qeb.17 for ; Thu, 12 Dec 2013 10:31:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Dg+f90qQK4MTo8SmlU9fQVsPvc2r1pyqYE3Fxq0Hvwo=; b=ll2Xg2dF2/E655762YuZ3/6cK0+ucCxkxNo+RIHY3mC1GYz2e8uvlUg+pp21oY9gbl uhu2AsOuQPwu39eav8GJhaPTzmnmeVut0YWekbXk+ups7sw3zS/AJn2Peg6x/WNWJ6Mf xf9/NeRi3lA94SJ8TnUull/C/kiElHTWxGBinVWvcOavxcNB4uQ6w11KGDfD83FknZNU jJhL4eeFrpG8b/yVUQs27FuIECEAC59unXh2eJBQOJAsSTHEW/4MuG0EBGkjGtP+Nnsg rdlJPl39UFwy4sOhUG/R1UHyZda3pr+muotPn/z1pyRwB2MMALNk/+o9674K/Yx3sle9 YKIw==
X-Gm-Message-State: ALoCoQlv9f6nkUU2bSCl0vd7Nf2L02gymWR5iNrDfMQNtNHosKPpob1WJnRfCUI2AF1zvHicuon5
MIME-Version: 1.0
X-Received: by 10.49.25.109 with SMTP id b13mr16057484qeg.3.1386873070136; Thu, 12 Dec 2013 10:31:10 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 12 Dec 2013 10:31:10 -0800 (PST)
In-Reply-To: <006201cef765$a461e640$ed25b2c0$@comcast.net>
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com> <001b01cef716$295e2520$6b01a8c0@oemcomputer> <004a01cef75c$b8610120$29230360$@comcast.net>  <006201cef765$a461e640$ed25b2c0$@comcast.net>
Date: Thu, 12 Dec 2013 10:31:10 -0800
Message-ID: 
From: Andy Bierman 
To: ietfdbh 
Content-Type: multipart/alternative; boundary=047d7b677f1eb1beba04ed5a8c4c
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 18:31:21 -0000

--047d7b677f1eb1beba04ed5a8c4c
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

Here is Martin's suggestion:

> I don't think it makes much sense to have two such similar objects in
> this data model.
>
> One option would be to simply remove the connection between
> sysLocation and this new location leaf (and same for contact),
> essentially making the snmp object the "legacy" object.

I like this idea.  The client can decide if it wants the location leaf
and sysLocation SNMP object to have the same value.

There are many languages that cannot use 7-bit ASCII. We should be
using UTF-8 for all administrative strings.


Andy



On Thu, Dec 12, 2013 at 10:11 AM, ietfdbh  wrote:

> Hi,
>
>
>
> Comments inline
>
>
>
> David Harrington
>
> ietfdbh@comcast.net
>
> +1-603-828-1401
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* Thursday, December 12, 2013 12:19 PM
> *To:* ietfdbh
> *Cc:* Randy Presuhn; Martin Bjorklund; netmod@ietf.org
> *Subject:* Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
>
>
> Hi,
>
>
>
> What if these objects do not have corresponding SNMP values on the device=
?
>
> What if the device does not implement SNMP?
>
>
>
> I don=92t really care whether SNMP is implemented on the device or not.
>
> I care about standardizing consistent syntax for the YANG object.
>
>
>
> Are you suggesting we need duplicate versions for devices that do support
> SNMP,
>
> with an "if-feature snmp" statement to make it conditional?
>
>
>
> *Absolutely not. I am saying the syntax should not be conditional. Period=
.
> No if-feature needed.*
>
>
>
> Either make the syntax of the YANG object the same as DisplayString (whic=
h
> would force old syntax on new implementations, sometimes unnecessarily fr=
om
> a device perspective, but would allow mapping) or make it two separate
> objects with different syntax (to support internationalization in the new=
er
> standard, while the old object supports the old syntax, and it doesn=92t
> support mapping by the implementation).
>
>
>
> Making it optional is a problem for the NMS side which has to support
> multiple devices that are allowed to make different implementation choice=
s
> for the same object.
>
> Making it optional is a problem for the device side which has to deal wit=
h
> translations between values of different syntax.
>
> Allowing the objects to be separate OR mapped, and allowing side-effects
> to change the values seems especially problematic from a synchronization
> standpoint for the NMS (and the operators) who have to consider the resul=
ts
> of queries by two different protocols of the MAYBE-MAYBENOT-mapped object=
s.
>
>
>
> *Get rid of the optionality. Standardize the syntax of the YANG object on=
e
> way or the other.*
>
>
>
> What does it mean
>
> if the 2 variants have different values?
>
>
>
> If they are separate variables, they can have different values and
> different syntax. No big deal.
>
> If the **operator** wants them to be the same value, they limit themselve=
s
> to DisplayString syntax when setting the YANG object, and it is their
> responsibility to keep the two variables in sync, not the implementer=92s
> responsibility.
>
> If the **operator** wants internationalized YANG names, they can with YAN=
G
> strings.
>
> If the **operator** wants internationalized MIB names, too bad; the MIB
> standard doesn=92t permit that.
>
>
>
> I think the new proposed text forces a device to limit the object to 7-bi=
t
> ASCII
>
> if the SNMP version of the object is supported.
>
>
>
> It seems old syntax is being forced on devices, not new syntax.
>
>
> If you don=92t want the new object to be constrained by old syntax, then
> make it a separate object, unconstrained by any mapping to the standard M=
IB
> object.
>
> From the perspective of this NMS developer, I would MUCH prefer separate
> objects, each with a consistently standardized syntax, over separate
> objects for whom the syntax may or may not be the same.
>
>
>
> The operators who spoke up around the time of rfc3535 said they don=92t
> trust applications to necessarily get things right, so asking the
> implementations to do some type of automated lossless translation between
> objects of different syntax and size sounds like you=92re asking for trou=
ble.
>
>
> Andy
>
>
>
> On Thu, Dec 12, 2013 at 9:08 AM, ietfdbh  wrote:
>
> Hi,
>
> Personally, I think it would be simpler to just have the YANG objects be
> constrained by DisplayString syntax, but then, I come from a country wher=
e
> 7-bit ASCII covers my language of choice. It would be nice to have a
> consistent underlying instrumentation without duplication of effort and
> resources, but that would require choosing the least common denominator
> (DisplayString).
>
> My second choice would be to treat them as separate instances, one of
> DisplayString syntax, one of YANG string syntax. That way, we don't have =
to
> worry about side effects of changing the YANG object via the MIB, or
> changing the MIB object via YANG. If we want to internationalize the
> syntax,
> you cannot do that to the MIB within SMI limits. Mapping between them if
> they support different syntax raises a whole lot of issues for the databa=
se
> handling and UI of an NMS, stands the chance of breaking existing
> implementations if implementers handle the translations wrong or in a
> non-interoperable manner, and stands the chance of misleading operators
> (and
> applications) if the value of the MIB object is changed dynamically becau=
se
> the value is changed (in any way) via translation from the YANG object.
>
> I think it would be better for standardization and interoperability if we
> do
> not try to force-feed new syntax into the existing MIB object(s). If you
> were trying to do this by updating the MIB, you would most certainly need
> to
> define a new object (much like we had to do with Counter64s to replace
> Counter32s). If the YANG object is treated as a separate object from the
> MIB
> object, then if and when the MIB is updated, the MIB can add an object to
> map to the YANG object, and deprecate the DisplayString syntax object.
>
> If the YANG object says it can be mapped, then I think the YANG object mu=
st
> REQUIRE that it be implemented with DisplayString constraints, whether a
> server implementation maps to the MIB or not. Assuming an NMS supports bo=
th
> MIB and YANG queries, and an implementer MAY treat them as separate, then
> the NMS must treat them as separate. If the implementer MAY treat them as
> mapped, the NMS still needs to implement them as separate because they MA=
Y
> be separate, but the NMS probably must treat the NMS-side variables as
> mapped to ensure they are in sync; otherwise reading the value via the MI=
B
> without simultaneously reading the value via YANG would lead to the NMS
> potentially displaying different values even though on the device the
> values
> are the same. This optionality greatly increases the complexity of
> implementing these objects on the NMS side. An NMS would need to determin=
e
> whether the agent/server implemented these as mapped or separate,
> presumably
> by changing one and seeing if it affected the other, so it knew whether t=
o
> try to perform synchronization between the two. Lots of work for limited
> benefit to the operator. And if NMS implementations handled synchronizati=
on
> differently, the operator is stuck trying to manage with conflicting
> information from different NMSs.
>
> It would be much better to standardize the expectation - either these
> objects MUST be mapped and constrained by DisplayString syntax per the
> IETF,
> or MUST be defined as separate objects of different syntax per the IETF
> standard. Then an NMS implementer knows what to expect.
>
> David Harrington
> ietfdbh@comcast.net
> +1-603-828-1401
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy
> > Presuhn
> > Sent: Thursday, December 12, 2013 3:43 AM
> > To: Martin Bjorklund
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> >
> > Hi -
> >
> > > From: "Martin Bjorklund" 
> > > To: 
> > > Cc: ; 
> > > Sent: Wednesday, December 11, 2013 11:52 PM
> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > >
> > > Randy Presuhn  wrote:
> > > > Hi -
> > > >
> > > > >From: Juergen Schoenwaelder  > university.de>
> > > > >Sent: Dec 11, 2013 12:38 AM
> > > > >To: Randy Presuhn 
> > > > >Cc: netmod@ietf.org
> > > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > > >
> > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > > >
> > > > >> > Anyway, for a standardized approach, someone would have to wri=
te
> > a
> > > > >> > document that defines how unicode code points are represented =
as
> > > > >> > escaped charater sequences in DisplayStrings. I do not think
> that
> this
> > > > >> > document is in charge of doing this. Hence, until such a
> standard
> is
> > > > >> > written, I think things need to be implementation specific.
> > > > >>
> > > > >> Perhaps, though that is the route to being stuck with ASCII unti=
l
> the
> > > > >> successor to Netconf rolls along.
> > > > >
> > > > >Not necessarily. If you configure via NETCONF (or most CLIs these
> > > > >days), you can use unicode characters. The code that maps names to
> > > > >legacy non-unicode interfaces then needs to do suitable translatio=
ns
> > > > >to fit whatever constraint there is.
> > > >
> > > > Not if the data definition restricts the values to an ASCII
> > > > subset, as has been proposed.  What's in the draft at the
> > > > moment will bring its own interoperability problems, but
> > > > at least it's a baby step forward.
> > >
> > > So it seems we have a chance to fix this now.  But I need to
> > > understand what exactly you and/or Juergen propose.  Preferrably
> > > concrete text.  I *think* that the proposal is something like this:
> > >
> > >    o  An implementation MUST allow any legal "string" (YANG string).
> >
> > There are good reasons to restrict formatting and control characters -
> > I'll assume YANG strings do this already.  If not, that's another long
> > discussion.
> >
> > >    o  An implementation that maps this value to the corresponding MIB
> > >       object, which has size and character set limitations, MUST use
> > >       some mechanism out of the scope for this document to ensure tha=
t
> > >       the MIB object syntax is still valid.
> >
> > Yes this seems reasonable.
> >
> > But it doesn't cover a "round trip".  If the value is modified via the
> MIB
> > interface to include what looks like the implementation-specific encodi=
ng
> > into ASCII of a non-ASCII Unicode code point, does retrieving that valu=
e
> > via the Netconf interface get the Unicode code point or the
> implementation-
> > specific ASCII encoding of it?  If it does (and I think it should) then
> there
> > needs to be some though put into what happens when the code point
> > encoded using ASCII would, if converted to Unicode, be illegal (for
> > whatever reason) in the YANG string.  It's probably best to keep the
> > SNMP instrumentation ignorant of all this, so code in the Netconf side
> > would need determine whether any of the ASCII "escape sequences"
> > would produce forbidden code points, and, in such cases, *not* evaluate
> > those sequences and just pass them through unevaluated.
> >
> >
> > > Also, just to make sure, we are talking about:
> > >
> > >    system/location        -- sysLocation
> > >    system/contact         -- sysContact
> > >    interface/description  -- ifAlias
> >
> > Perhaps also sysDescr (even though read-only, my comment above seems
> > applicable,
> > particularly since on at least some systems this comes from a static
> > configuration
> > file, and would be useful to support local language in some minimal way=
.)
> >
> > sysName (think IDN) might also be worth thinking about.  There was a lo=
ng
> > debate
> > about this a while back; I don't know what current thinking is.
> >
> > Randy
> >
> > _______________________________________________
> > 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
>
>
>

--047d7b677f1eb1beba04ed5a8c4c
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Hi,

Here is Martin's suggestion:

> I don't think it makes much sense to have two such similar=
 objects in

> this data =
model.
>=

> One option would be to simp=
ly remove the connection between

> sysLocatio=
n and this new location leaf (and same for contact),
> essentially making the snmp object the &quo=
t;legacy" object.



=

I like this idea. =A0The client can decide if=A0it wants the location leaf


and sysLoc=
ation SNMP object to have the same value.

There are=
 many languages that cannot use 7-bit ASCII. We should be


using UTF-8 for all administrative strings.

<=
br>
Andy


On Thu, Dec 12, 2013 at 10:11 AM, ietfdbh <=
span dir=3D"ltr"><ietfdbh@comcast.net> wrote:


Hi,


=A0<=
/p>
Comments inline=



=A0<=
/p>
David Harrington<=
span style=3D"color:#1f497d">


ietfdbh@comcast.net


+1-603-828-1401


From:=
 Andy Bierman [mailto:andy@yumaworks.com] 

Sent: Thursday, December 12, 2013 12:19 PM
To: ietfdbh
=
Cc: Randy Presuhn; Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] A=
D review of draft-ietf-netmod-system-mgmt


=A0
Hi,
=A0=

What if these objects do not have cor=
responding SNMP values on the device?


What if the device does not implement SNM=
P?
=A0


I don=92t really care whether=
 SNMP is implemented on the device or not.

I care about standardizing consistent syntax for the=
 YANG object.
=
=A0


Are you suggesting we need duplicate vers=
ions for devices that do support SNMP,
with an "if-feature snmp" statement to make it con=
ditional? =A0


=A0<=
/p>
Absolutely not. I am sa=
ying the syntax should not be conditional. Period. No if-feature needed.=



=A0<=
/p>
Either make the syntax of =
the YANG object the same as DisplayString (which would force old syntax on =
new implementations, sometimes unnecessarily from a device perspective, but=
 would allow mapping) or make it two separate objects with different syntax=
 (to support internationalization in the newer standard, while the old obje=
ct supports the old syntax, and it doesn=92t support mapping by the impleme=
ntation). 


=A0
<=
p class=3D"MsoNormal">Making it optional is a proble=
m for the NMS side which has to support multiple devices that are allowed t=
o make different implementation choices for the same object. =



Making it optional is a probl=
em for the device side which has to deal with translations between values o=
f different syntax.


Allowing the objects to be se=
parate OR mapped, and allowing side-effects to change the values seems espe=
cially problematic from a synchronization standpoint for the NMS (and the o=
perators) who have to consider the results of queries by two different prot=
ocols of the MAYBE-MAYBENOT-mapped objects.


=A0
<=
p class=3D"MsoNormal">Get rid of the optionality.=
 Standardize the syntax of the YANG object one way or the other.<=
/u>


=A0
What does it mean
=
if the 2 variants have different values?


=A0<=
/p>
If they are separate varia=
bles, they can have different values and different syntax. No big deal.<=
/u>


If the **operator** wants the=
m to be the same value, they limit themselves to DisplayString syntax when =
setting the YANG object, and it is their responsibility to keep the two var=
iables in sync, not the implementer=92s responsibility.


If the **operator** wants int=
ernationalized YANG names, they can with YANG strings.=



If the **operator** wants int=
ernationalized MIB names, too bad; the MIB standard doesn=92t permit that. =



=A0
I think the new proposed text forces a device to limit the o=
bject to 7-bit ASCII
if =
the SNMP version of the object is supported.


=A0
It seems old syntax is being forced on devices, not new synt=
ax.

If you don=92t want the new object to be constrained by old syntax, the=
n make it a separate object, unconstrained by any mapping to the standard M=
IB object.


From the perspective of th=
is NMS developer, I would MUCH prefer separate objects, each with a consist=
ently standardized syntax, over separate objects for whom the syntax may or=
 may not be the same. 


=A0
The operators who spoke =
up around the time of rfc3535 said they don=92t trust applications to neces=
sarily get things right, so asking the implementations to do some type of a=
utomated lossless translation between objects of different syntax and size =
sounds like you=92re asking for trouble.



Andy
=A0
On Thu, Dec 12, 20=
13 at 9:08 AM, ietfdbh <ietfdbh@comcast.net> wrote:


Hi,

Personally, I think it would be simpler t=
o just have the YANG objects be
constrained by DisplayString syntax, but=
 then, I come from a country where
7-bit ASCII covers my language of cho=
ice. It would be nice to have a

consistent underlying instrumentation without duplication of effort and
=
resources, but that would require choosing the least common denominator
=
(DisplayString).

My second choice would be to treat them as separate=
 instances, one of

DisplayString syntax, one of YANG string syntax. That way, we don't hav=
e to
worry about side effects of changing the YANG object via the MIB, o=
r
changing the MIB object via YANG. If we want to internationalize the s=
yntax,

you cannot do that to the MIB within SMI limits. Mapping between them ifthey support different syntax raises a whole lot of issues for the databas=
e
handling and UI of an NMS, stands the chance of breaking existing

implementations if implementers handle the translations wrong or in a
no=
n-interoperable manner, and stands the chance of misleading operators (and<=
br>applications) if the value of the MIB object is changed dynamically beca=
use

the value is changed (in any way) via translation from the YANG object.
=

I think it would be better for standardization and interoperability if =
we do
not try to force-feed new syntax into the existing MIB object(s). =
If you

were trying to do this by updating the MIB, you would most certainly need t=
o
define a new object (much like we had to do with Counter64s to replace=

Counter32s). If the YANG object is treated as a separate object from th=
e MIB

object, then if and when the MIB is updated, the MIB can add an object tomap to the YANG object, and deprecate the DisplayString syntax object.
If the YANG object says it can be mapped, then I think the YANG object=
 must

REQUIRE that it be implemented with DisplayString constraints, whether aserver implementation maps to the MIB or not. Assuming an NMS supports bot=
h
MIB and YANG queries, and an implementer MAY treat them as separate, t=
hen

the NMS must treat them as separate. If the implementer MAY treat them asmapped, the NMS still needs to implement them as separate because they MA=
Y
be separate, but the NMS probably must treat the NMS-side variables as=


mapped to ensure they are in sync; otherwise reading the value via the MIB<=
br>without simultaneously reading the value via YANG would lead to the NMS<=
br>potentially displaying different values even though on the device the va=
lues

are the same. This optionality greatly increases the complexity of
imple=
menting these objects on the NMS side. An NMS would need to determine
wh=
ether the agent/server implemented these as mapped or separate, presumably<=
br>
by changing one and seeing if it affected the other, so it knew whether to<=
br>try to perform synchronization between the two. Lots of work for limited=

benefit to the operator. And if NMS implementations handled synchroniza=
tion

differently, the operator is stuck trying to manage with conflicting
inf=
ormation from different NMSs.

It would be much better to standardize=
 the expectation - either these
objects MUST be mapped and constrained b=
y DisplayString syntax per the IETF,

or MUST be defined as separate objects of different syntax per the IETF
=
standard. Then an NMS implementer knows what to expect.

David Harrin=
gton
ietfdbh@co=
mcast.net

+1-603-828-1401
> -----Original Message-----
> From: netmod [ma=
ilto:netmod-bo=
unces@ietf.org] On Behalf Of Randy
> Presuhn
> Sent: Thursd=
ay, December 12, 2013 3:43 AM

> To: Martin Bjorklund
> Cc: netmod@ietf.org
> Subject: Re: [netmod] AD review=
 of draft-ietf-netmod-system-mgmt
>
> Hi -
>
> >=
 From: "Martin Bjorklund" <mbj@tail-f.com>

> > To: <randy_presuhn@mindspring.com>
> > Cc: <j.schoen=
waelder@jacobs-university.de>; <netmod@ietf.org>

> > Sent: Wednesday, December 11, 2013 11:52 PM
> > Subject:=
 Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> >
&g=
t; > Randy Presuhn <randy_presuhn@mindspring.com> wrote:

> > > Hi -
> > >
> > > >From: Juergen S=
choenwaelder <j.schoenwaelder@jacobs-
> university.de>

> > > >Sent: Dec 11, 2013 12:38 AM
> > > >To: Ra=
ndy Presuhn <randy_presuhn@mindspring.com>
> > > >Cc: netmod@ietf.org

> > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-sys=
tem-mgmt
> > > >
> > > >On Tue, Dec 10, 2013 =
at 01:18:10PM -0800, Randy Presuhn wrote:
> > > >
> &g=
t; > >> > Anyway, for a standardized approach, someone would ha=
ve to write

> a
> > > >> > document that defines how unicode co=
de points are represented as
> > > >> > escaped charat=
er sequences in DisplayStrings. I do not think that
this
> > &g=
t; >> > document is in charge of doing this. Hence, until such a s=
tandard

is
> > > >> > written, I think things need to be imple=
mentation specific.
> > > >>
> > > >> P=
erhaps, though that is the route to being stuck with ASCII until
the

> > > >> successor to Netconf rolls along.
> > >=
 >
> > > >Not necessarily. If you configure via NETCONF (=
or most CLIs these
> > > >days), you can use unicode charact=
ers. The code that maps names to

> > > >legacy non-unicode interfaces then needs to do suitable =
translations
> > > >to fit whatever constraint there is.
=
> > >
> > > Not if the data definition restricts the v=
alues to an ASCII

> > > subset, as has been proposed. =A0What's in the draft at =
the
> > > moment will bring its own interoperability problems, =
but
> > > at least it's a baby step forward.
> >
> > So it seems we have a chance to fix this now. =A0But I need to> > understand what exactly you and/or Juergen propose. =A0Preferrab=
ly
> > concrete text. =A0I *think* that the proposal is something =
like this:

> >
> > =A0 =A0o =A0An implementation MUST allow any legal &=
quot;string" (YANG string).
>
> There are good reasons to =
restrict formatting and control characters -
> I'll assume YANG s=
trings do this already. =A0If not, that's another long

> discussion.
>
> > =A0 =A0o =A0An implementation that ma=
ps this value to the corresponding MIB
> > =A0 =A0 =A0 object, whi=
ch has size and character set limitations, MUST use
> > =A0 =A0 =
=A0 some mechanism out of the scope for this document to ensure that

> > =A0 =A0 =A0 the MIB object syntax is still valid.
>
>=
 Yes this seems reasonable.
>
> But it doesn't cover a &quo=
t;round trip". =A0If the value is modified via the MIB
> interfa=
ce to include what looks like the implementation-specific encoding

> into ASCII of a non-ASCII Unicode code point, does retrieving that val=
ue
> via the Netconf interface get the Unicode code point or the
i=
mplementation-
> specific ASCII encoding of it? =A0If it does (and I =
think it should) then

there
> needs to be some though put into what happens when the code p=
oint
> encoded using ASCII would, if converted to Unicode, be illegal=
 (for
> whatever reason) in the YANG string. =A0It's probably bes=
t to keep the

> SNMP instrumentation ignorant of all this, so code in the Netconf side=

> would need determine whether any of the ASCII "escape sequenc=
es"
> would produce forbidden code points, and, in such cases, *=
not* evaluate

> those sequences and just pass them through unevaluated.
>
>=
;
> > Also, just to make sure, we are talking about:
> ><=
br>> > =A0 =A0system/location =A0 =A0 =A0 =A0-- sysLocation
> &=
gt; =A0 =A0system/contact =A0 =A0 =A0 =A0 -- sysContact

> > =A0 =A0interface/description =A0-- ifAlias
>
> Perhap=
s also sysDescr (even though read-only, my comment above seems
> appl=
icable,
> particularly since on at least some systems this comes from=
 a static

> configuration
> file, and would be useful to support local langu=
age in some minimal way.)
>
> sysName (think IDN) might also be=
 worth thinking about. =A0There was a long
> debate
> about thi=
s a while back; I don't know what current thinking is.

>
> Randy
>
> ________________________________________=
_______
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mail=
man/listinfo/netmod


_______________________________________________
netmod mailing list<=
br>netmod@ietf.org=

https://www.ietf.org/mailman/listinfo/netmod


=A0
<=
/div>



--047d7b677f1eb1beba04ed5a8c4c--

From j.schoenwaelder@jacobs-university.de  Thu Dec 12 12:28:12 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8071AE459 for ; Thu, 12 Dec 2013 12:28:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3j4RiMYPulI for ; Thu, 12 Dec 2013 12:28:10 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 518031AE12E for ; Thu, 12 Dec 2013 12:28:10 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07F4B20081; Thu, 12 Dec 2013 21:28:04 +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 3U-UNr_mnaQe; Thu, 12 Dec 2013 21:28: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 210A2200AA; Thu, 12 Dec 2013 21:28:03 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C20D329FDAF0; Thu, 12 Dec 2013 21:27:58 +0100 (CET)
Date: Thu, 12 Dec 2013 21:27:58 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20131212202758.GE81732@elstar.local>
Mail-Followup-To: Martin Bjorklund , randy_presuhn@mindspring.com, netmod@ietf.org
References: <12817633.1386701728243.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> <20131210195745.GA74616@elstar.local> <20131210.222445.216011946.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131210.222445.216011946.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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 Dec 2013 20:28:12 -0000

On Tue, Dec 10, 2013 at 10:24:45PM +0100, Martin Bjorklund wrote:
> 
> So what is the proposal?  All implementations MUST allow arbitrary
> strings, and implementations that map this to the SNMP object MUST be
> careful...?
> 
> My original idea was that implementations should be free to either
> restrict the values to match the DisplayString, or do some
> implemenation-specific translation.  From -00:
> 
>               This leaf MAY be mapped to ifAlias by an implementation.
>               Such an implementation MAY restrict the length of the
>               value of this leaf so that it matches the restrictions
>               of ifAlias.
> 
> But the WG decided that the current specified behavior was more
> correct.

This text only talks about length restrictions, not about character
set differences. I have to re-read the mailing list archive to see
what exactly happened.

As a technical contributor, I think we look kind of foolish if we
restrict unicode usage due to some legacy interfaces.  The guideline
"Use 7-bit ASCII because of some protocols designed in the late 80s."
can't be the long term answer to internationalization. OSes really
have moved on. I can put fancy characters into my interface name on
Linux. The kernel does not care and the tools do work well with it.

/js (speaking as a technical contributor)

-- 
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 Dec 12 12:37:26 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240E51AE1A3 for ; Thu, 12 Dec 2013 12:37:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCn9QSM2kusq for ; Thu, 12 Dec 2013 12:37:22 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5151AE042 for ; Thu, 12 Dec 2013 12:37:22 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDD2720081; Thu, 12 Dec 2013 21:37:15 +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 XGRtndRwcVRO; Thu, 12 Dec 2013 21:37:15 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 726E42009F; Thu, 12 Dec 2013 21:37:15 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 0426729FDB2F; Thu, 12 Dec 2013 21:37:09 +0100 (CET)
Date: Thu, 12 Dec 2013 21:37:09 +0100
From: Juergen Schoenwaelder 
To: ietfdbh 
Message-ID: <20131212203709.GF81732@elstar.local>
Mail-Followup-To: ietfdbh , 'Randy Presuhn' , 'Martin Bjorklund' , netmod@ietf.org
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com> <001b01cef716$295e2520$6b01a8c0@oemcomputer> <004a01cef75c$b8610120$29230360$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <004a01cef75c$b8610120$29230360$@comcast.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: 'Randy Presuhn' , netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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 Dec 2013 20:37:26 -0000

Hi,

I believe we need a reality check here. Unfortunately, I do not have
access to many recent devices. I would like to know what todays devices
do if you configure properties via the CLI that are export via SNMP
agents.

- Do boxes reject anything at the CLI that does not conform to
  DisplayStrings?
- Or do CLIs accept stuff and the agents provide strings not
  conforming to DisplayStrings?
- Or do CLIs accept stuff and there is implementation specific
  translation happening?

For me, US 7-bit ASCII forever can't really be the answer.

/js

PS: At least on common *nix systems, the SNMP agent is a completely
    separate process - one out of many. If I change the name of my
    interface (and I can change it pretty arbitrarily), the SNMP agent
    is not being asked and it has to deal with the name it finds the
    kernel using. Some of the popular SNMP code bases out there not
    even manage to properly truncate strings to DisplayString size. I
    know it is a weak argument but in the real world, I am sure
    management systems already have to deal with these issues.

On Thu, Dec 12, 2013 at 12:08:03PM -0500, ietfdbh wrote:
> Hi,
> 
> Personally, I think it would be simpler to just have the YANG objects be
> constrained by DisplayString syntax, but then, I come from a country where
> 7-bit ASCII covers my language of choice. It would be nice to have a
> consistent underlying instrumentation without duplication of effort and
> resources, but that would require choosing the least common denominator
> (DisplayString). 
> 
> My second choice would be to treat them as separate instances, one of
> DisplayString syntax, one of YANG string syntax. That way, we don't have to
> worry about side effects of changing the YANG object via the MIB, or
> changing the MIB object via YANG. If we want to internationalize the syntax,
> you cannot do that to the MIB within SMI limits. Mapping between them if
> they support different syntax raises a whole lot of issues for the database
> handling and UI of an NMS, stands the chance of breaking existing
> implementations if implementers handle the translations wrong or in a
> non-interoperable manner, and stands the chance of misleading operators (and
> applications) if the value of the MIB object is changed dynamically because
> the value is changed (in any way) via translation from the YANG object. 
> 
> I think it would be better for standardization and interoperability if we do
> not try to force-feed new syntax into the existing MIB object(s). If you
> were trying to do this by updating the MIB, you would most certainly need to
> define a new object (much like we had to do with Counter64s to replace
> Counter32s). If the YANG object is treated as a separate object from the MIB
> object, then if and when the MIB is updated, the MIB can add an object to
> map to the YANG object, and deprecate the DisplayString syntax object.
> 
> If the YANG object says it can be mapped, then I think the YANG object must
> REQUIRE that it be implemented with DisplayString constraints, whether a
> server implementation maps to the MIB or not. Assuming an NMS supports both
> MIB and YANG queries, and an implementer MAY treat them as separate, then
> the NMS must treat them as separate. If the implementer MAY treat them as
> mapped, the NMS still needs to implement them as separate because they MAY
> be separate, but the NMS probably must treat the NMS-side variables as
> mapped to ensure they are in sync; otherwise reading the value via the MIB
> without simultaneously reading the value via YANG would lead to the NMS
> potentially displaying different values even though on the device the values
> are the same. This optionality greatly increases the complexity of
> implementing these objects on the NMS side. An NMS would need to determine
> whether the agent/server implemented these as mapped or separate, presumably
> by changing one and seeing if it affected the other, so it knew whether to
> try to perform synchronization between the two. Lots of work for limited
> benefit to the operator. And if NMS implementations handled synchronization
> differently, the operator is stuck trying to manage with conflicting
> information from different NMSs.
> 
> It would be much better to standardize the expectation - either these
> objects MUST be mapped and constrained by DisplayString syntax per the IETF,
> or MUST be defined as separate objects of different syntax per the IETF
> standard. Then an NMS implementer knows what to expect.
> 
> David Harrington
> ietfdbh@comcast.net
> +1-603-828-1401
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy
> > Presuhn
> > Sent: Thursday, December 12, 2013 3:43 AM
> > To: Martin Bjorklund
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > 
> > Hi -
> > 
> > > From: "Martin Bjorklund" 
> > > To: 
> > > Cc: ; 
> > > Sent: Wednesday, December 11, 2013 11:52 PM
> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > >
> > > Randy Presuhn  wrote:
> > > > Hi -
> > > >
> > > > >From: Juergen Schoenwaelder  > university.de>
> > > > >Sent: Dec 11, 2013 12:38 AM
> > > > >To: Randy Presuhn 
> > > > >Cc: netmod@ietf.org
> > > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > > >
> > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > > >
> > > > >> > Anyway, for a standardized approach, someone would have to write
> > a
> > > > >> > document that defines how unicode code points are represented as
> > > > >> > escaped charater sequences in DisplayStrings. I do not think that
> this
> > > > >> > document is in charge of doing this. Hence, until such a standard
> is
> > > > >> > written, I think things need to be implementation specific.
> > > > >>
> > > > >> Perhaps, though that is the route to being stuck with ASCII until
> the
> > > > >> successor to Netconf rolls along.
> > > > >
> > > > >Not necessarily. If you configure via NETCONF (or most CLIs these
> > > > >days), you can use unicode characters. The code that maps names to
> > > > >legacy non-unicode interfaces then needs to do suitable translations
> > > > >to fit whatever constraint there is.
> > > >
> > > > Not if the data definition restricts the values to an ASCII
> > > > subset, as has been proposed.  What's in the draft at the
> > > > moment will bring its own interoperability problems, but
> > > > at least it's a baby step forward.
> > >
> > > So it seems we have a chance to fix this now.  But I need to
> > > understand what exactly you and/or Juergen propose.  Preferrably
> > > concrete text.  I *think* that the proposal is something like this:
> > >
> > >    o  An implementation MUST allow any legal "string" (YANG string).
> > 
> > There are good reasons to restrict formatting and control characters -
> > I'll assume YANG strings do this already.  If not, that's another long
> > discussion.
> > 
> > >    o  An implementation that maps this value to the corresponding MIB
> > >       object, which has size and character set limitations, MUST use
> > >       some mechanism out of the scope for this document to ensure that
> > >       the MIB object syntax is still valid.
> > 
> > Yes this seems reasonable.
> > 
> > But it doesn't cover a "round trip".  If the value is modified via the MIB
> > interface to include what looks like the implementation-specific encoding
> > into ASCII of a non-ASCII Unicode code point, does retrieving that value
> > via the Netconf interface get the Unicode code point or the
> implementation-
> > specific ASCII encoding of it?  If it does (and I think it should) then
> there
> > needs to be some though put into what happens when the code point
> > encoded using ASCII would, if converted to Unicode, be illegal (for
> > whatever reason) in the YANG string.  It's probably best to keep the
> > SNMP instrumentation ignorant of all this, so code in the Netconf side
> > would need determine whether any of the ASCII "escape sequences"
> > would produce forbidden code points, and, in such cases, *not* evaluate
> > those sequences and just pass them through unevaluated.
> > 
> > 
> > > Also, just to make sure, we are talking about:
> > >
> > >    system/location        -- sysLocation
> > >    system/contact         -- sysContact
> > >    interface/description  -- ifAlias
> > 
> > Perhaps also sysDescr (even though read-only, my comment above seems
> > applicable,
> > particularly since on at least some systems this comes from a static
> > configuration
> > file, and would be useful to support local language in some minimal way.)
> > 
> > sysName (think IDN) might also be worth thinking about.  There was a long
> > debate
> > about this a while back; I don't know what current thinking is.
> > 
> > Randy
> > 
> > _______________________________________________
> > 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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From andy@yumaworks.com  Thu Dec 12 12:52:54 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C1D1AE4B8 for ; Thu, 12 Dec 2013 12:52:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUtrMpiGFH5i for ; Thu, 12 Dec 2013 12:52:51 -0800 (PST)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id C37581AE4B6 for ; Thu, 12 Dec 2013 12:52:50 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id w5so121214qac.13 for ; Thu, 12 Dec 2013 12:52:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=hCvx076VFg3KYnO5RfqQPun5Hd9jpeGhJZItod0bTWY=; b=H9ZzC4TwrT3cZVoF5p3wVwf1Oy9Rz+v2k9yCT4OZ6nmmLzKkYpaQjAXjl+I7OUgGSF cT6VZ9bmfpTy4XQ9IUu4RwQzIw0j7rQnFal3tTOSNbw3SAMBa5E7KhiGX9Li2STr3zSa ovJCOpKY6EfAoyyg9JJZOj+BOcM034uxehG+0uMjIDXKB/P1TXEvlXRzDxuYB2JieurO wY+v95XgcXOYy3w4sAiAJBrMiXQGz9FIKe8oL712Ix5dj9ggb7issZcnAGO264AEXUYK yeKYZAAiboDhk6HP86tGJzGM6sVdkhwIVsnN2xwdGho+5epRcWInQ2pLjnsF+yMeeAP4 7h0g==
X-Gm-Message-State: ALoCoQl/JoHnNVcyWs6jgX8dbhq3FMuDqp8WvOJjX2nmrBCP8ZZVrbuaqmnazCcsYk5CKrqF62Uv
MIME-Version: 1.0
X-Received: by 10.49.35.52 with SMTP id e20mr17046430qej.63.1386881564325; Thu, 12 Dec 2013 12:52:44 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 12 Dec 2013 12:52:44 -0800 (PST)
In-Reply-To: <20131212203709.GF81732@elstar.local>
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com> <001b01cef716$295e2520$6b01a8c0@oemcomputer> <004a01cef75c$b8610120$29230360$@comcast.net> <20131212203709.GF81732@elstar.local>
Date: Thu, 12 Dec 2013 12:52:44 -0800
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , ietfdbh ,  Randy Presuhn , Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b6d9b1cfcd41204ed5c863d
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 20:52:54 -0000

--047d7b6d9b1cfcd41204ed5c863d
Content-Type: text/plain; charset=ISO-8859-1

Hi,

If the proposal is to move beyond DisplayString, then +1 from me.
It's easy for people in the US to say "no problem" to using US-ASCII.

This thread started over the use of MAY vs. MUST wrt/ DisplayString
compatibility.  Now it has jumped to MUST use DisplayString even
if the device is capable of using UTF-8.

Perhaps the original text was good enough.  The server MAY reject values
it does not support.


Andy




On Thu, Dec 12, 2013 at 12:37 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,
>
> I believe we need a reality check here. Unfortunately, I do not have
> access to many recent devices. I would like to know what todays devices
> do if you configure properties via the CLI that are export via SNMP
> agents.
>
> - Do boxes reject anything at the CLI that does not conform to
>   DisplayStrings?
> - Or do CLIs accept stuff and the agents provide strings not
>   conforming to DisplayStrings?
> - Or do CLIs accept stuff and there is implementation specific
>   translation happening?
>
> For me, US 7-bit ASCII forever can't really be the answer.
>
> /js
>
> PS: At least on common *nix systems, the SNMP agent is a completely
>     separate process - one out of many. If I change the name of my
>     interface (and I can change it pretty arbitrarily), the SNMP agent
>     is not being asked and it has to deal with the name it finds the
>     kernel using. Some of the popular SNMP code bases out there not
>     even manage to properly truncate strings to DisplayString size. I
>     know it is a weak argument but in the real world, I am sure
>     management systems already have to deal with these issues.
>
> On Thu, Dec 12, 2013 at 12:08:03PM -0500, ietfdbh wrote:
> > Hi,
> >
> > Personally, I think it would be simpler to just have the YANG objects be
> > constrained by DisplayString syntax, but then, I come from a country
> where
> > 7-bit ASCII covers my language of choice. It would be nice to have a
> > consistent underlying instrumentation without duplication of effort and
> > resources, but that would require choosing the least common denominator
> > (DisplayString).
> >
> > My second choice would be to treat them as separate instances, one of
> > DisplayString syntax, one of YANG string syntax. That way, we don't have
> to
> > worry about side effects of changing the YANG object via the MIB, or
> > changing the MIB object via YANG. If we want to internationalize the
> syntax,
> > you cannot do that to the MIB within SMI limits. Mapping between them if
> > they support different syntax raises a whole lot of issues for the
> database
> > handling and UI of an NMS, stands the chance of breaking existing
> > implementations if implementers handle the translations wrong or in a
> > non-interoperable manner, and stands the chance of misleading operators
> (and
> > applications) if the value of the MIB object is changed dynamically
> because
> > the value is changed (in any way) via translation from the YANG object.
> >
> > I think it would be better for standardization and interoperability if
> we do
> > not try to force-feed new syntax into the existing MIB object(s). If you
> > were trying to do this by updating the MIB, you would most certainly
> need to
> > define a new object (much like we had to do with Counter64s to replace
> > Counter32s). If the YANG object is treated as a separate object from the
> MIB
> > object, then if and when the MIB is updated, the MIB can add an object to
> > map to the YANG object, and deprecate the DisplayString syntax object.
> >
> > If the YANG object says it can be mapped, then I think the YANG object
> must
> > REQUIRE that it be implemented with DisplayString constraints, whether a
> > server implementation maps to the MIB or not. Assuming an NMS supports
> both
> > MIB and YANG queries, and an implementer MAY treat them as separate, then
> > the NMS must treat them as separate. If the implementer MAY treat them as
> > mapped, the NMS still needs to implement them as separate because they
> MAY
> > be separate, but the NMS probably must treat the NMS-side variables as
> > mapped to ensure they are in sync; otherwise reading the value via the
> MIB
> > without simultaneously reading the value via YANG would lead to the NMS
> > potentially displaying different values even though on the device the
> values
> > are the same. This optionality greatly increases the complexity of
> > implementing these objects on the NMS side. An NMS would need to
> determine
> > whether the agent/server implemented these as mapped or separate,
> presumably
> > by changing one and seeing if it affected the other, so it knew whether
> to
> > try to perform synchronization between the two. Lots of work for limited
> > benefit to the operator. And if NMS implementations handled
> synchronization
> > differently, the operator is stuck trying to manage with conflicting
> > information from different NMSs.
> >
> > It would be much better to standardize the expectation - either these
> > objects MUST be mapped and constrained by DisplayString syntax per the
> IETF,
> > or MUST be defined as separate objects of different syntax per the IETF
> > standard. Then an NMS implementer knows what to expect.
> >
> > David Harrington
> > ietfdbh@comcast.net
> > +1-603-828-1401
> > > -----Original Message-----
> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy
> > > Presuhn
> > > Sent: Thursday, December 12, 2013 3:43 AM
> > > To: Martin Bjorklund
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > >
> > > Hi -
> > >
> > > > From: "Martin Bjorklund" 
> > > > To: 
> > > > Cc: ; 
> > > > Sent: Wednesday, December 11, 2013 11:52 PM
> > > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > >
> > > > Randy Presuhn  wrote:
> > > > > Hi -
> > > > >
> > > > > >From: Juergen Schoenwaelder  > > university.de>
> > > > > >Sent: Dec 11, 2013 12:38 AM
> > > > > >To: Randy Presuhn 
> > > > > >Cc: netmod@ietf.org
> > > > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > > > >
> > > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > > > >
> > > > > >> > Anyway, for a standardized approach, someone would have to
> write
> > > a
> > > > > >> > document that defines how unicode code points are represented
> as
> > > > > >> > escaped charater sequences in DisplayStrings. I do not think
> that
> > this
> > > > > >> > document is in charge of doing this. Hence, until such a
> standard
> > is
> > > > > >> > written, I think things need to be implementation specific.
> > > > > >>
> > > > > >> Perhaps, though that is the route to being stuck with ASCII
> until
> > the
> > > > > >> successor to Netconf rolls along.
> > > > > >
> > > > > >Not necessarily. If you configure via NETCONF (or most CLIs these
> > > > > >days), you can use unicode characters. The code that maps names to
> > > > > >legacy non-unicode interfaces then needs to do suitable
> translations
> > > > > >to fit whatever constraint there is.
> > > > >
> > > > > Not if the data definition restricts the values to an ASCII
> > > > > subset, as has been proposed.  What's in the draft at the
> > > > > moment will bring its own interoperability problems, but
> > > > > at least it's a baby step forward.
> > > >
> > > > So it seems we have a chance to fix this now.  But I need to
> > > > understand what exactly you and/or Juergen propose.  Preferrably
> > > > concrete text.  I *think* that the proposal is something like this:
> > > >
> > > >    o  An implementation MUST allow any legal "string" (YANG string).
> > >
> > > There are good reasons to restrict formatting and control characters -
> > > I'll assume YANG strings do this already.  If not, that's another long
> > > discussion.
> > >
> > > >    o  An implementation that maps this value to the corresponding MIB
> > > >       object, which has size and character set limitations, MUST use
> > > >       some mechanism out of the scope for this document to ensure
> that
> > > >       the MIB object syntax is still valid.
> > >
> > > Yes this seems reasonable.
> > >
> > > But it doesn't cover a "round trip".  If the value is modified via the
> MIB
> > > interface to include what looks like the implementation-specific
> encoding
> > > into ASCII of a non-ASCII Unicode code point, does retrieving that
> value
> > > via the Netconf interface get the Unicode code point or the
> > implementation-
> > > specific ASCII encoding of it?  If it does (and I think it should) then
> > there
> > > needs to be some though put into what happens when the code point
> > > encoded using ASCII would, if converted to Unicode, be illegal (for
> > > whatever reason) in the YANG string.  It's probably best to keep the
> > > SNMP instrumentation ignorant of all this, so code in the Netconf side
> > > would need determine whether any of the ASCII "escape sequences"
> > > would produce forbidden code points, and, in such cases, *not* evaluate
> > > those sequences and just pass them through unevaluated.
> > >
> > >
> > > > Also, just to make sure, we are talking about:
> > > >
> > > >    system/location        -- sysLocation
> > > >    system/contact         -- sysContact
> > > >    interface/description  -- ifAlias
> > >
> > > Perhaps also sysDescr (even though read-only, my comment above seems
> > > applicable,
> > > particularly since on at least some systems this comes from a static
> > > configuration
> > > file, and would be useful to support local language in some minimal
> way.)
> > >
> > > sysName (think IDN) might also be worth thinking about.  There was a
> long
> > > debate
> > > about this a while back; I don't know what current thinking is.
> > >
> > > Randy
> > >
> > > _______________________________________________
> > > 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
>
> --
> 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
>

--047d7b6d9b1cfcd41204ed5c863d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi,

If the proposal is to move beyond D=
isplayString, then +1 from me.
It's easy for people in the US=
 to say "no problem" to using US-ASCII.


This thread started over the use of MAY vs. MUST wrt/ DisplayString
compatibility. =A0Now it has jumped to MUST use DisplayString even
=

if the device is capable of using UTF-8.

Perh=
aps the original text was good enough. =A0The server MAY reject values

it does not support.


Andy




On Thu, Dec 12, 2013 at 12:37 PM, Juergen Schoenwae=
lder <j.schoenwaelder@jacobs-university.de> wrote:


Hi,



I believe we need a reality check here. Unfortunately, I do not have

access to many recent devices. I would like to know what todays devices

do if you configure properties via the CLI that are export via SNMP

agents.



- Do boxes reject anything at the CLI that does not conform to

=A0 DisplayStrings?

- Or do CLIs accept stuff and the agents provide strings not

=A0 conforming to DisplayStrings?

- Or do CLIs accept stuff and there is implementation specific

=A0 translation happening?



For me, US 7-bit ASCII forever can't really be the answer.



/js



PS: At least on common *nix systems, the SNMP agent is a completely

=A0 =A0 separate process - one out of many. If I change the name of my

=A0 =A0 interface (and I can change it pretty arbitrarily), the SNMP agent<=
br>
=A0 =A0 is not being asked and it has to deal with the name it finds the
=A0 =A0 kernel using. Some of the popular SNMP code bases out there not

=A0 =A0 even manage to properly truncate strings to DisplayString size. I
=A0 =A0 know it is a weak argument but in the real world, I am sure

=A0 =A0 management systems already have to deal with these issues.



On Thu, Dec 12, 2013 at 12:08:03PM -0500, ietfdbh wrote:

> Hi,

>

> Personally, I think it would be simpler to just have the YANG objects =
be

> constrained by DisplayString syntax, but then, I come from a country w=
here

> 7-bit ASCII covers my language of choice. It would be nice to have a
> consistent underlying instrumentation without duplication of effort an=
d

> resources, but that would require choosing the least common denominato=
r

> (DisplayString).

>

> My second choice would be to treat them as separate instances, one of<=
br>
> DisplayString syntax, one of YANG string syntax. That way, we don'=
t have to

> worry about side effects of changing the YANG object via the MIB, or
> changing the MIB object via YANG. If we want to internationalize the s=
yntax,

> you cannot do that to the MIB within SMI limits. Mapping between them =
if

> they support different syntax raises a whole lot of issues for the dat=
abase

> handling and UI of an NMS, stands the chance of breaking existing

> implementations if implementers handle the translations wrong or in a<=
br>
> non-interoperable manner, and stands the chance of misleading operator=
s (and

> applications) if the value of the MIB object is changed dynamically be=
cause

> the value is changed (in any way) via translation from the YANG object=
.

>

> I think it would be better for standardization and interoperability if=
 we do

> not try to force-feed new syntax into the existing MIB object(s). If y=
ou

> were trying to do this by updating the MIB, you would most certainly n=
eed to

> define a new object (much like we had to do with Counter64s to replace=


> Counter32s). If the YANG object is treated as a separate object from t=
he MIB

> object, then if and when the MIB is updated, the MIB can add an object=
 to

> map to the YANG object, and deprecate the DisplayString syntax object.=


>

> If the YANG object says it can be mapped, then I think the YANG object=
 must

> REQUIRE that it be implemented with DisplayString constraints, whether=
 a

> server implementation maps to the MIB or not. Assuming an NMS supports=
 both

> MIB and YANG queries, and an implementer MAY treat them as separate, t=
hen

> the NMS must treat them as separate. If the implementer MAY treat them=
 as

> mapped, the NMS still needs to implement them as separate because they=
 MAY

> be separate, but the NMS probably must treat the NMS-side variables as=


> mapped to ensure they are in sync; otherwise reading the value via the=
 MIB

> without simultaneously reading the value via YANG would lead to the NM=
S

> potentially displaying different values even though on the device the =
values

> are the same. This optionality greatly increases the complexity of

> implementing these objects on the NMS side. An NMS would need to deter=
mine

> whether the agent/server implemented these as mapped or separate, pres=
umably

> by changing one and seeing if it affected the other, so it knew whethe=
r to

> try to perform synchronization between the two. Lots of work for limit=
ed

> benefit to the operator. And if NMS implementations handled synchroniz=
ation

> differently, the operator is stuck trying to manage with conflicting
> information from different NMSs.

>

> It would be much better to standardize the expectation - either these<=
br>
> objects MUST be mapped and constrained by DisplayString syntax per the=
 IETF,

> or MUST be defined as separate objects of different syntax per the IET=
F

> standard. Then an NMS implementer knows what to expect.

>

> David Harrington

> ietfdbh@comcast.net

> +1-603-828-1401

> > -----Original Message-----

> > From: netmod [mailto:n=
etmod-bounces@ietf.org] On Behalf Of Randy

> > Presuhn

> > Sent: Thursday, December 12, 2013 3:43 AM

> > To: Martin Bjorklund

> > Cc: netmod@ietf.org

> > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt<=
br>
> >

> > Hi -

> >

> > > From: "Martin Bjorklund" <mbj@tail-f.com>

> > > To: <rand=
y_presuhn@mindspring.com>

> > > Cc: <j.schoenwaelder@jacobs-university.de>; <netmod@ietf.org>

> > > Sent: Wednesday, December 11, 2013 11:52 PM

> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-=
mgmt

> > >

> > > Randy Presuhn <randy_presuhn@mindspring.com> wrote:

> > > > Hi -

> > > >

> > > > >From: Juergen Schoenwaelder <j.schoenwaelder@jac=
obs-

> > university.de<=
/a>>

> > > > >Sent: Dec 11, 2013 12:38 AM

> > > > >To: Randy Presuhn <randy_presuhn@mindspring.com>

> > > > >Cc: netmod@ietf.=
org

> > > > >Subject: Re: [netmod] AD review of draft-ietf-netmo=
d-system-mgmt

> > > > >

> > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Pre=
suhn wrote:

> > > > >

> > > > >> > Anyway, for a standardized approach, some=
one would have to write

> > a

> > > > >> > document that defines how unicode code po=
ints are represented as

> > > > >> > escaped charater sequences in DisplayStri=
ngs. I do not think that

> this

> > > > >> > document is in charge of doing this. Henc=
e, until such a standard

> is

> > > > >> > written, I think things need to be implem=
entation specific.

> > > > >>

> > > > >> Perhaps, though that is the route to being stu=
ck with ASCII until

> the

> > > > >> successor to Netconf rolls along.

> > > > >

> > > > >Not necessarily. If you configure via NETCONF (or m=
ost CLIs these

> > > > >days), you can use unicode characters. The code tha=
t maps names to

> > > > >legacy non-unicode interfaces then needs to do suit=
able translations

> > > > >to fit whatever constraint there is.

> > > >

> > > > Not if the data definition restricts the values to an A=
SCII

> > > > subset, as has been proposed. =A0What's in the draf=
t at the

> > > > moment will bring its own interoperability problems, bu=
t

> > > > at least it's a baby step forward.

> > >

> > > So it seems we have a chance to fix this now. =A0But I need =
to

> > > understand what exactly you and/or Juergen propose. =A0Prefe=
rrably

> > > concrete text. =A0I *think* that the proposal is something l=
ike this:

> > >

> > > =A0 =A0o =A0An implementation MUST allow any legal "str=
ing" (YANG string).

> >

> > There are good reasons to restrict formatting and control charact=
ers -

> > I'll assume YANG strings do this already. =A0If not, that'=
;s another long

> > discussion.

> >

> > > =A0 =A0o =A0An implementation that maps this value to the co=
rresponding MIB

> > > =A0 =A0 =A0 object, which has size and character set limitat=
ions, MUST use

> > > =A0 =A0 =A0 some mechanism out of the scope for this documen=
t to ensure that

> > > =A0 =A0 =A0 the MIB object syntax is still valid.

> >

> > Yes this seems reasonable.

> >

> > But it doesn't cover a "round trip". =A0If the valu=
e is modified via the MIB

> > interface to include what looks like the implementation-specific =
encoding

> > into ASCII of a non-ASCII Unicode code point, does retrieving tha=
t value

> > via the Netconf interface get the Unicode code point or the

> implementation-

> > specific ASCII encoding of it? =A0If it does (and I think it shou=
ld) then

> there

> > needs to be some though put into what happens when the code point=


> > encoded using ASCII would, if converted to Unicode, be illegal (f=
or

> > whatever reason) in the YANG string. =A0It's probably best to=
 keep the

> > SNMP instrumentation ignorant of all this, so code in the Netconf=
 side

> > would need determine whether any of the ASCII "escape sequen=
ces"

> > would produce forbidden code points, and, in such cases, *not* ev=
aluate

> > those sequences and just pass them through unevaluated.

> >

> >

> > > Also, just to make sure, we are talking about:

> > >

> > > =A0 =A0system/location =A0 =A0 =A0 =A0-- sysLocation

> > > =A0 =A0system/contact =A0 =A0 =A0 =A0 -- sysContact

> > > =A0 =A0interface/description =A0-- ifAlias

> >

> > Perhaps also sysDescr (even though read-only, my comment above se=
ems

> > applicable,

> > particularly since on at least some systems this comes from a sta=
tic

> > configuration

> > file, and would be useful to support local language in some minim=
al way.)

> >

> > sysName (think IDN) might also be worth thinking about. =A0There =
was a long

> > debate

> > about this a while back; I don't know what current thinking i=
s.

> >

> > Randy

> >

> > _______________________________________________

> > 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



--

Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German=
y

Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><=
br>
_______________________________________________

netmod mailing list

netmod@ietf.org

=
https://www.ietf.org/mailman/listinfo/netmod





--047d7b6d9b1cfcd41204ed5c863d--

From wwwrun@rfc-editor.org  Thu Dec 12 14:32:59 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0431AE50F for ; Thu, 12 Dec 2013 14:32:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBhAcyRBfCVd for ; Thu, 12 Dec 2013 14:32:56 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id A71771AE50E for ; Thu, 12 Dec 2013 14:32:56 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 499547FC38F; Thu, 12 Dec 2013 14:32:50 -0800 (PST)
To: mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, david.kessens@gmail.com
From: RFC Errata System 
Message-Id: <20131212223250.499547FC38F@rfc-editor.org>
Date: Thu, 12 Dec 2013 14:32:50 -0800 (PST)
Cc: jiminychris@gmail.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Technical Errata Reported] RFC6020 (3832)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 22:32:59 -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=3832

--------------------------------------
Type: Technical
Reported by: Chris LaBauve 

Section: 7.4.1

Original Text
-------------
               +------------------+---------+-------------+
               | substatement     | section | cardinality |
               +------------------+---------+-------------+
               | bit              | 9.7.4   | 0..n        |
               | enum             | 9.6.4   | 0..n        |
               | length           | 9.4.4   | 0..1        |
               | path             | 9.9.2   | 0..1        |
               | pattern          | 9.4.6   | 0..n        |
               | range            | 9.2.4   | 0..1        |
               | require-instance | 9.13.2  | 0..1        |
               | type             | 7.4     | 0..n        |
               +------------------+---------+-------------+

Corrected Text
--------------
               +------------------+---------+-------------+
               | substatement     | section | cardinality |
               +------------------+---------+-------------+
               | base             | 9.10.2  | 0..1        |
               | bit              | 9.7.4   | 0..n        |
               | enum             | 9.6.4   | 0..n        |
               | fraction-digits  | 9.3.4   | 0..1        |
               | length           | 9.4.4   | 0..1        |
               | path             | 9.9.2   | 0..1        |
               | pattern          | 9.4.6   | 0..n        |
               | range            | 9.2.4   | 0..1        |
               | require-instance | 9.13.2  | 0..1        |
               | type             | 7.4     | 0..n        |
               +------------------+---------+-------------+

Notes
-----
9.3.4. states 'The "fraction-digits" statement, which is a substatement to the "type" statement' but 7.4.1 does not list "fraction-digits" as one of the substatements of "type".

9.10.2. states 'The "base" statement, which is a substatement to the "type" statement' but 7.4.1 does not list "base" as one of the substatements of "type".

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 wwwrun@rfc-editor.org  Thu Dec 12 14:42:48 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F631AE529 for ; Thu, 12 Dec 2013 14:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M4bQEeCNh77 for ; Thu, 12 Dec 2013 14:42:47 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id B10861AE116 for ; Thu, 12 Dec 2013 14:42:45 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id B3D4D7FC157; Thu, 12 Dec 2013 14:42:39 -0800 (PST)
To: mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, david.kessens@gmail.com
From: RFC Errata System 
Message-Id: <20131212224239.B3D4D7FC157@rfc-editor.org>
Date: Thu, 12 Dec 2013 14:42:39 -0800 (PST)
Cc: jiminychris@gmail.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Technical Errata Reported] RFC6020 (3833)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 22:42:49 -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=3833

--------------------------------------
Type: Technical
Reported by: Chris LaBauve 

Section: 12

Original Text
-------------
decimal64-specification = fraction-digits-stmt

Corrected Text
--------------
decimal64-specification = ;; these stmts can appear in any order
                          fraction-digits-stmt stmtsep
                          [range-stmt stmtsep]

Notes
-----
decimal64 types should allow for a range substatement; 9.2.4 states the range statement "is used to restrict integer and decimal built-in types."

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 wwwrun@rfc-editor.org  Thu Dec 12 15:01:25 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4341D1AE16A for ; Thu, 12 Dec 2013 15:01:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO22byO46CuS for ; Thu, 12 Dec 2013 15:01:23 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3D71AE14B for ; Thu, 12 Dec 2013 15:01:23 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 8AF207FC177; Thu, 12 Dec 2013 15:01:17 -0800 (PST)
To: mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, david.kessens@gmail.com
From: RFC Errata System 
Message-Id: <20131212230117.8AF207FC177@rfc-editor.org>
Date: Thu, 12 Dec 2013 15:01:17 -0800 (PST)
Cc: jiminychris@gmail.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Technical Errata Reported] RFC6020 (3834)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 23:01:25 -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=3834

--------------------------------------
Type: Technical
Reported by: Chris LaBauve 

Section: 9.7.5

Original Text
-------------
    Given the following leaf:

     leaf mybits {
         type bits {
             bit disable-nagle {
                 position 0;
             }
             bit auto-sense-speed {
                 position 1;
             }
             bit 10-Mb-only {
                 position 2;
             }
         }
         default "auto-sense-speed";
     }

   The lexical representation of this leaf with bit values disable-nagle
   and 10-Mb-only set would be:

     disable-nagle 10-Mb-only

Corrected Text
--------------
    Given the following leaf:

     leaf mybits {
         type bits {
             bit disable-nagle {
                 position 0;
             }
             bit auto-sense-speed {
                 position 1;
             }
             bit ten-Mb-only {
                 position 2;
             }
         }
         default "auto-sense-speed";
     }

   The lexical representation of this leaf with bit values disable-nagle
   and ten-Mb-only set would be:

     disable-nagle ten-Mb-only

Notes
-----
9.7.5. Shows a usage example of the bit statement wherein the identifier '10-Mb-only' begins with a digit, which contradicts the ABNF rule 'identifier' (identifier must begin with [_A-Za-z])

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 wwwrun@rfc-editor.org  Thu Dec 12 15:06:47 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A781AE4C8 for ; Thu, 12 Dec 2013 15:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 489TlX_OtXfx for ; Thu, 12 Dec 2013 15:06:45 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 93B251AE10C for ; Thu, 12 Dec 2013 15:06:45 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 8839D7FC177; Thu, 12 Dec 2013 15:06:39 -0800 (PST)
To: mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, david.kessens@gmail.com
From: RFC Errata System 
Message-Id: <20131212230639.8839D7FC177@rfc-editor.org>
Date: Thu, 12 Dec 2013 15:06:39 -0800 (PST)
Cc: jiminychris@gmail.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Technical Errata Reported] RFC6020 (3835)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 23:06:47 -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=3835

--------------------------------------
Type: Technical
Reported by: Chris LaBauve 

Section: 12

Original Text
-------------
   type-body-stmts     = numerical-restrictions /
                         decimal64-specification /
                         string-restrictions /
                         enum-specification /
                         leafref-specification /
                         identityref-specification /
                         instance-identifier-specification /
                         bits-specification /
                         union-specification

Corrected Text
--------------
   type-body-stmts     = numerical-restrictions /
                         decimal64-specification /
                         string-restrictions /
                         enum-specification /
                         leafref-specification /
                         identityref-specification /
                         instance-identifier-specification /
                         bits-specification /
                         union-specification / 
                         binary-specification

   binary-specification = [length-stmt stmtsep]

Notes
-----
Grammar rule 'type-body-stmts' does not provide for the case when type is 'binary'; this would be a rule allowing 0 or 1 length substatements according to 9.8.1.

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 randy_presuhn@mindspring.com  Thu Dec 12 15:45:09 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB971AE569 for ; Thu, 12 Dec 2013 15:45:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I73KNMClpsb2 for ; Thu, 12 Dec 2013 15:45:07 -0800 (PST)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 228941AE566 for ; Thu, 12 Dec 2013 15:45:05 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VKiW2Z95Kr+KVb1MWZlT9qMYR0kmwMCHYRCNhmCE+ZOhHS4V9F4JKT13tm04rGza; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.40] (helo=elwamui-milano.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VrFwB-00071l-46 for netmod@ietf.org; Thu, 12 Dec 2013 18:44:59 -0500
Received: from 76.254.55.132 by webmail.earthlink.net with HTTP; Thu, 12 Dec 2013 18:44:59 -0500
Message-ID: <7884374.1386891899108.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
Date: Thu, 12 Dec 2013 15:44:59 -0800 (GMT-08:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb4234fccbb884d0c07848f33d361c386c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.40
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Dec 2013 23:45:09 -0000

Hi -

>From: Juergen Schoenwaelder 
>Sent: Dec 12, 2013 3:52 AM
>To: Randy Presuhn , h@elstar.local
>Cc: netmod@ietf.org
>Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
>On Thu, Dec 12, 2013 at 12:42:57AM -0800, Randy Presuhn wrote:
>>
>> >    o  An implementation MUST allow any legal "string" (YANG string).
>> 
>> There are good reasons to restrict formatting and control characters -
>> I'll assume YANG strings do this already.  If not, that's another long
>> discussion.
>
>RFC 6020 says:
>
>   The string built-in type represents human-readable strings in YANG.
>   Legal characters are tab, carriage return, line feed, and the legal
>   characters of Unicode and ISO/IEC 10646 [ISO.10646]:
>
>     ;; any Unicode character, excluding the surrogate blocks,
>     ;; FFFE, and FFFF.
>     string = *char
>     char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
>            %x10000-10FFFF
>
>And so far, we have used these strings without further restrictions in
>data models when there was something to be named.

Very odd.  It restricts the C0 controls, but permits the C1
control codes?  I hope someone thought that through carefully.

Randy

From mbj@tail-f.com  Thu Dec 12 23:22:39 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D401AE18D for ; Thu, 12 Dec 2013 23:22:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oek0CCW82epg for ; Thu, 12 Dec 2013 23:22:34 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id BE0691AE12A for ; Thu, 12 Dec 2013 23:22: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 CA74337C041; Fri, 13 Dec 2013 08:22:25 +0100 (CET)
Date: Fri, 13 Dec 2013 08:22:25 +0100 (CET)
Message-Id: <20131213.082225.2137464918470103242.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund 
In-Reply-To: <7884374.1386891899108.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
References: <7884374.1386891899108.JavaMail.root@elwamui-milano.atl.sa.earthlink.net>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 07:22:39 -0000
X-List-Received-Date: Fri, 13 Dec 2013 07:22:39 -0000

Randy Presuhn  wrote:
> Hi -
> 
> >From: Juergen Schoenwaelder 
> >Sent: Dec 12, 2013 3:52 AM
> >To: Randy Presuhn , h@elstar.local
> >Cc: netmod@ietf.org
> >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> >
> >On Thu, Dec 12, 2013 at 12:42:57AM -0800, Randy Presuhn wrote:
> >>
> >> >    o  An implementation MUST allow any legal "string" (YANG string).
> >> 
> >> There are good reasons to restrict formatting and control characters -
> >> I'll assume YANG strings do this already.  If not, that's another long
> >> discussion.
> >
> >RFC 6020 says:
> >
> >   The string built-in type represents human-readable strings in YANG.
> >   Legal characters are tab, carriage return, line feed, and the legal
> >   characters of Unicode and ISO/IEC 10646 [ISO.10646]:
> >
> >     ;; any Unicode character, excluding the surrogate blocks,
> >     ;; FFFE, and FFFF.
> >     string = *char
> >     char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
> >            %x10000-10FFFF
> >
> >And so far, we have used these strings without further restrictions in
> >data models when there was something to be named.
> 
> Very odd.  It restricts the C0 controls, but permits the C1
> control codes?  I hope someone thought that through carefully.

It is what XML Schema 1.0 says is a string.  See
http://www.w3.org/TR/xmlschema-2/#string and the reference to
http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Char


/martin

From jernej.tuljak@mg-soft.si  Fri Dec 13 00:38:20 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EEB1AE1D9 for ; Fri, 13 Dec 2013 00:38:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kV_LCXyV4bR9 for ; Fri, 13 Dec 2013 00:38:10 -0800 (PST)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 61ADD1AE2D1 for ; Fri, 13 Dec 2013 00:38:09 -0800 (PST)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id rBD8bqf5013686; Fri, 13 Dec 2013 09:37:52 +0100
Message-ID: <52AAC75E.3070203@mg-soft.com>
Date: Fri, 13 Dec 2013 09:37:50 +0100
From: Jernej Tuljak 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: RFC Errata System 
References: <20131212224239.B3D4D7FC157@rfc-editor.org>
In-Reply-To: <20131212224239.B3D4D7FC157@rfc-editor.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org, joelja@bogus.com, jiminychris@gmail.com
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3833)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 08:38:20 -0000

I believe Errata 3290 has already dealt with this. 
http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3290

Jernej

Dne 12.12.2013 23:42, pie RFC Errata System:
> 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=3833
>
> --------------------------------------
> Type: Technical
> Reported by: Chris LaBauve 
>
> Section: 12
>
> Original Text
> -------------
> decimal64-specification = fraction-digits-stmt
>
> Corrected Text
> --------------
> decimal64-specification = ;; these stmts can appear in any order
>                            fraction-digits-stmt stmtsep
>                            [range-stmt stmtsep]
>
> Notes
> -----
> decimal64 types should allow for a range substatement; 9.2.4 states the range statement "is used to restrict integer and decimal built-in types."
>
> 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
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From lhotka@nic.cz  Fri Dec 13 01:27:28 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD74F1ADFD4 for ; Fri, 13 Dec 2013 01:27:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlZzBLihDzmv for ; Fri, 13 Dec 2013 01:27:27 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EAC1F1A802A for ; Fri, 13 Dec 2013 01:27:25 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id B3EA8140355; Fri, 13 Dec 2013 10:27:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386926839; bh=X922vVKbf80zF+0kcli272dj1IzizvBSrRg+oaOm3DA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=n1wHNJJuxWDpVAOqmVQAMxm0z+TgpOu2Qb5xPtlgdKaJGrBteTgVfCTxr9r0bxfCI bkippJuwBMExtk3kJrc4bxht/m1+Eal9aAMmUPh5NoLprEOYqYYHNfV+3CFghNFYdN jieG8VGH31GJ2IVdfkFi0jU4cozqwy9EgEibMYjg=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ladislav Lhotka 
In-Reply-To: <52AAC75E.3070203@mg-soft.com>
Date: Fri, 13 Dec 2013 10:27:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20131212224239.B3D4D7FC157@rfc-editor.org> <52AAC75E.3070203@mg-soft.com>
To: Jernej Tuljak 
X-Mailer: Apple Mail (2.1822)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: joelja@bogus.com, jiminychris@gmail.com, netmod@ietf.org, RFC Errata System 
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3833)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 09:27:29 -0000

On 13 Dec 2013, at 09:37, Jernej Tuljak  =
wrote:

> I believe Errata 3290 has already dealt with this. =
http://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D3290

Indeed.

I would be actually very useful if RFCs/I-Ds had some marks in places =
for which errata exist, ideally with links to the corresponding erratum.

Lada

>=20
> Jernej
>=20
> Dne 12.12.2013 23:42, pi=9Ae RFC Errata System:
>> 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=3D3833
>>=20
>> --------------------------------------
>> Type: Technical
>> Reported by: Chris LaBauve 
>>=20
>> Section: 12
>>=20
>> Original Text
>> -------------
>> decimal64-specification =3D fraction-digits-stmt
>>=20
>> Corrected Text
>> --------------
>> decimal64-specification =3D ;; these stmts can appear in any order
>>                           fraction-digits-stmt stmtsep
>>                           [range-stmt stmtsep]
>>=20
>> Notes
>> -----
>> decimal64 types should allow for a range substatement; 9.2.4 states =
the range statement "is used to restrict integer and decimal built-in =
types."
>>=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
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From lhotka@nic.cz  Fri Dec 13 01:37:57 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93E41ADED8 for ; Fri, 13 Dec 2013 01:37:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level: 
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwRPXuysUFW8 for ; Fri, 13 Dec 2013 01:37:56 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id DEB421A802A for ; Fri, 13 Dec 2013 01:37:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 81ED2540294; Fri, 13 Dec 2013 10:37:48 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J5IOQSPH1nH; Fri, 13 Dec 2013 10:37:43 +0100 (CET)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id AFCEF5400BE; Fri, 13 Dec 2013 10:37:38 +0100 (CET)
From: Ladislav Lhotka 
To: RFC Errata System , mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, david.kessens@gmail.com
In-Reply-To: <20131212230639.8839D7FC177@rfc-editor.org>
References: <20131212230639.8839D7FC177@rfc-editor.org>
User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0)
Mail-Followup-To: RFC Errata System , mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, david.kessens@gmail.com, jiminychris@gmail.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Date: Fri, 13 Dec 2013 10:37:37 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: jiminychris@gmail.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3835)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 09:37:58 -0000

The text in sec. 9.4.4 also needs updating:

OLD

   It is used to restrict the built-in type "string", or types derived
   from "string".

NEW

   It is used to restrict the built-in types "string" and "binary", or
   types derived from them.

Lada

RFC Errata System  writes:

> 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=3835
>
> --------------------------------------
> Type: Technical
> Reported by: Chris LaBauve 
>
> Section: 12
>
> Original Text
> -------------
>    type-body-stmts     = numerical-restrictions /
>                          decimal64-specification /
>                          string-restrictions /
>                          enum-specification /
>                          leafref-specification /
>                          identityref-specification /
>                          instance-identifier-specification /
>                          bits-specification /
>                          union-specification
>
> Corrected Text
> --------------
>    type-body-stmts     = numerical-restrictions /
>                          decimal64-specification /
>                          string-restrictions /
>                          enum-specification /
>                          leafref-specification /
>                          identityref-specification /
>                          instance-identifier-specification /
>                          bits-specification /
>                          union-specification / 
>                          binary-specification
>
>    binary-specification = [length-stmt stmtsep]
>
> Notes
> -----
> Grammar rule 'type-body-stmts' does not provide for the case when type is 'binary'; this would be a rule allowing 0 or 1 length substatements according to 9.8.1.
>
> 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
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

From lhotka@nic.cz  Fri Dec 13 02:14:47 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C2B1AE09D for ; Fri, 13 Dec 2013 02:14:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level: 
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b65uiakGvj7m for ; Fri, 13 Dec 2013 02:14:44 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9EF1ADDAC for ; Fri, 13 Dec 2013 02:14:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 100C0540294 for ; Fri, 13 Dec 2013 11:14:37 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Aq2AHk+3wEq for ; Fri, 13 Dec 2013 11:14:29 +0100 (CET)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id CC59D540216 for ; Fri, 13 Dec 2013 11:14:24 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: 
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com> <001b01cef716$295e2520$6b01a8c0@oemcomputer> <004a01cef75c$b8610120$29230360$@comcast.net>   
User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0)
Mail-Followup-To: netmod@ietf.org
Date: Fri, 13 Dec 2013 11:14:23 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 10:14:47 -0000

Andy Bierman  writes:

> On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka  wrote:
>
>> Hi,
>>
>> just an idea: would it help if the server simply records the mapped
>> DisplayString version in state data?
>>
>>
> No.  I am OK with the proposal to force the server to constrain the objec=
ts

Why not, actually? I mean something like this:

{ "system-state" : {
    ...
    "location" : "Schr=C3=B6dingerstra=C3=9Fe",
    "mib:sysLocation" : "Schroedingerstrasse",
    ...
}

This is similar to what Randy proposed with "legacy-location", but it is in=
 *state*, so it doesn't introduce a second configuration object.

Lada

> to DisplayString if the device supports the SNMP objects.
> I prefer that the  request get rejected with an 'invalid-value' error
> than lie and return .  The configured value is never going
> to be a valid value on a device that supports SNMP. I am not
> a big fan of separate config and state versions of the same object,
> especially since the protocol has no real way to discover why the
> operational value is different than the configured value.
>
>
>
>
>
>> Lada
>>
>>
>
> Andy
>
>
> On 12 Dec 2013, at 18:19, Andy Bierman  wrote:
>>
>> > Hi,
>> >
>> > What if these objects do not have corresponding SNMP values on the
>> device?
>> > What if the device does not implement SNMP?
>> >
>> > Are you suggesting we need duplicate versions for devices that do
>> support SNMP,
>> > with an "if-feature snmp" statement to make it conditional?  What does
>> it mean
>> > if the 2 variants have different values?
>> >
>> > I think the new proposed text forces a device to limit the object to
>> 7-bit ASCII
>> > if the SNMP version of the object is supported.
>> >
>> > It seems old syntax is being forced on devices, not new syntax.
>> >
>> >
>> > Andy
>> >
>> > On Thu, Dec 12, 2013 at 9:08 AM, ietfdbh  wrote:
>> > Hi,
>> >
>> > Personally, I think it would be simpler to just have the YANG objects =
be
>> > constrained by DisplayString syntax, but then, I come from a country
>> where
>> > 7-bit ASCII covers my language of choice. It would be nice to have a
>> > consistent underlying instrumentation without duplication of effort and
>> > resources, but that would require choosing the least common denominator
>> > (DisplayString).
>> >
>> > My second choice would be to treat them as separate instances, one of
>> > DisplayString syntax, one of YANG string syntax. That way, we don't ha=
ve
>> to
>> > worry about side effects of changing the YANG object via the MIB, or
>> > changing the MIB object via YANG. If we want to internationalize the
>> syntax,
>> > you cannot do that to the MIB within SMI limits. Mapping between them =
if
>> > they support different syntax raises a whole lot of issues for the
>> database
>> > handling and UI of an NMS, stands the chance of breaking existing
>> > implementations if implementers handle the translations wrong or in a
>> > non-interoperable manner, and stands the chance of misleading operators
>> (and
>> > applications) if the value of the MIB object is changed dynamically
>> because
>> > the value is changed (in any way) via translation from the YANG object.
>> >
>> > I think it would be better for standardization and interoperability if
>> we do
>> > not try to force-feed new syntax into the existing MIB object(s). If y=
ou
>> > were trying to do this by updating the MIB, you would most certainly
>> need to
>> > define a new object (much like we had to do with Counter64s to replace
>> > Counter32s). If the YANG object is treated as a separate object from t=
he
>> MIB
>> > object, then if and when the MIB is updated, the MIB can add an object=
 to
>> > map to the YANG object, and deprecate the DisplayString syntax object.
>> >
>> > If the YANG object says it can be mapped, then I think the YANG object
>> must
>> > REQUIRE that it be implemented with DisplayString constraints, whether=
 a
>> > server implementation maps to the MIB or not. Assuming an NMS supports
>> both
>> > MIB and YANG queries, and an implementer MAY treat them as separate, t=
hen
>> > the NMS must treat them as separate. If the implementer MAY treat them=
 as
>> > mapped, the NMS still needs to implement them as separate because they
>> MAY
>> > be separate, but the NMS probably must treat the NMS-side variables as
>> > mapped to ensure they are in sync; otherwise reading the value via the
>> MIB
>> > without simultaneously reading the value via YANG would lead to the NMS
>> > potentially displaying different values even though on the device the
>> values
>> > are the same. This optionality greatly increases the complexity of
>> > implementing these objects on the NMS side. An NMS would need to
>> determine
>> > whether the agent/server implemented these as mapped or separate,
>> presumably
>> > by changing one and seeing if it affected the other, so it knew whether
>> to
>> > try to perform synchronization between the two. Lots of work for limit=
ed
>> > benefit to the operator. And if NMS implementations handled
>> synchronization
>> > differently, the operator is stuck trying to manage with conflicting
>> > information from different NMSs.
>> >
>> > It would be much better to standardize the expectation - either these
>> > objects MUST be mapped and constrained by DisplayString syntax per the
>> IETF,
>> > or MUST be defined as separate objects of different syntax per the IETF
>> > standard. Then an NMS implementer knows what to expect.
>> >
>> > David Harrington
>> > ietfdbh@comcast.net
>> > +1-603-828-1401
>> > > -----Original Message-----
>> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy
>> > > Presuhn
>> > > Sent: Thursday, December 12, 2013 3:43 AM
>> > > To: Martin Bjorklund
>> > > Cc: netmod@ietf.org
>> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>> > >
>> > > Hi -
>> > >
>> > > > From: "Martin Bjorklund" 
>> > > > To: 
>> > > > Cc: ; 
>> > > > Sent: Wednesday, December 11, 2013 11:52 PM
>> > > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>> > > >
>> > > > Randy Presuhn  wrote:
>> > > > > Hi -
>> > > > >
>> > > > > >From: Juergen Schoenwaelder > > > university.de>
>> > > > > >Sent: Dec 11, 2013 12:38 AM
>> > > > > >To: Randy Presuhn 
>> > > > > >Cc: netmod@ietf.org
>> > > > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>> > > > > >
>> > > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
>> > > > > >
>> > > > > >> > Anyway, for a standardized approach, someone would have to
>> write
>> > > a
>> > > > > >> > document that defines how unicode code points are represent=
ed
>> as
>> > > > > >> > escaped charater sequences in DisplayStrings. I do not think
>> that
>> > this
>> > > > > >> > document is in charge of doing this. Hence, until such a
>> standard
>> > is
>> > > > > >> > written, I think things need to be implementation specific.
>> > > > > >>
>> > > > > >> Perhaps, though that is the route to being stuck with ASCII
>> until
>> > the
>> > > > > >> successor to Netconf rolls along.
>> > > > > >
>> > > > > >Not necessarily. If you configure via NETCONF (or most CLIs the=
se
>> > > > > >days), you can use unicode characters. The code that maps names=
 to
>> > > > > >legacy non-unicode interfaces then needs to do suitable
>> translations
>> > > > > >to fit whatever constraint there is.
>> > > > >
>> > > > > Not if the data definition restricts the values to an ASCII
>> > > > > subset, as has been proposed.  What's in the draft at the
>> > > > > moment will bring its own interoperability problems, but
>> > > > > at least it's a baby step forward.
>> > > >
>> > > > So it seems we have a chance to fix this now.  But I need to
>> > > > understand what exactly you and/or Juergen propose.  Preferrably
>> > > > concrete text.  I *think* that the proposal is something like this:
>> > > >
>> > > >    o  An implementation MUST allow any legal "string" (YANG string=
).
>> > >
>> > > There are good reasons to restrict formatting and control characters=
 -
>> > > I'll assume YANG strings do this already.  If not, that's another lo=
ng
>> > > discussion.
>> > >
>> > > >    o  An implementation that maps this value to the corresponding =
MIB
>> > > >       object, which has size and character set limitations, MUST u=
se
>> > > >       some mechanism out of the scope for this document to ensure
>> that
>> > > >       the MIB object syntax is still valid.
>> > >
>> > > Yes this seems reasonable.
>> > >
>> > > But it doesn't cover a "round trip".  If the value is modified via t=
he
>> MIB
>> > > interface to include what looks like the implementation-specific
>> encoding
>> > > into ASCII of a non-ASCII Unicode code point, does retrieving that
>> value
>> > > via the Netconf interface get the Unicode code point or the
>> > implementation-
>> > > specific ASCII encoding of it?  If it does (and I think it should) t=
hen
>> > there
>> > > needs to be some though put into what happens when the code point
>> > > encoded using ASCII would, if converted to Unicode, be illegal (for
>> > > whatever reason) in the YANG string.  It's probably best to keep the
>> > > SNMP instrumentation ignorant of all this, so code in the Netconf si=
de
>> > > would need determine whether any of the ASCII "escape sequences"
>> > > would produce forbidden code points, and, in such cases, *not* evalu=
ate
>> > > those sequences and just pass them through unevaluated.
>> > >
>> > >
>> > > > Also, just to make sure, we are talking about:
>> > > >
>> > > >    system/location        -- sysLocation
>> > > >    system/contact         -- sysContact
>> > > >    interface/description  -- ifAlias
>> > >
>> > > Perhaps also sysDescr (even though read-only, my comment above seems
>> > > applicable,
>> > > particularly since on at least some systems this comes from a static
>> > > configuration
>> > > file, and would be useful to support local language in some minimal
>> way.)
>> > >
>> > > sysName (think IDN) might also be worth thinking about.  There was a
>> long
>> > > debate
>> > > about this a while back; I don't know what current thinking is.
>> > >
>> > > Randy
>> > >
>> > > _______________________________________________
>> > > netmod mailing list
>> > > netmod@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/netmod
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>>

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

From mbj@tail-f.com  Fri Dec 13 03:15:19 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DA41AE2D1 for ; Fri, 13 Dec 2013 03:15:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5g6Z13k4rFB for ; Fri, 13 Dec 2013 03:15:17 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA461ADEDC for ; Fri, 13 Dec 2013 03:15: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 A04B737C041; Fri, 13 Dec 2013 12:15:09 +0100 (CET)
Date: Fri, 13 Dec 2013 12:15:09 +0100 (CET)
Message-Id: <20131213.121509.688716145908885068.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:   
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 11:15:19 -0000

Ladislav Lhotka  wrote:
> Andy Bierman  writes:
> =

> > On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka 
> > wrote:
> >
> >> Hi,
> >>
> >> just an idea: would it help if the server simply records the mappe=
d
> >> DisplayString version in state data?
> >>
> >>
> > No.  I am OK with the proposal to force the server to constrain the=

> > objects
> =

> Why not, actually? I mean something like this:
> =

> { "system-state" : {
>     ...
>     "location" : "Schr=F6dingerstra=DFe",
>     "mib:sysLocation" : "Schroedingerstrasse",
>     ...
> }
> =

> This is similar to what Randy proposed with "legacy-location", but it=

> is in *state*, so it doesn't introduce a second configuration object.=


But why report the MIB object at all in this case?

If we decide these objects are really separate, I don't see the need
to report the MIB object.  A manager that wants to see the SNMP object
in addition to the NETCONF object (for some reason) can use SNMP.


/martin

From lhotka@nic.cz  Fri Dec 13 03:59:00 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C680D1AE23A for ; Fri, 13 Dec 2013 03:59:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level: 
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn80XwOmiGv3 for ; Fri, 13 Dec 2013 03:58:59 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE6B1AE1F9 for ; Fri, 13 Dec 2013 03:58:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 22F64540294 for ; Fri, 13 Dec 2013 12:58:52 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQxiCJSHZSej for ; Fri, 13 Dec 2013 12:58:42 +0100 (CET)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id CBB76540216 for ; Fri, 13 Dec 2013 12:58:37 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: <20131213.121509.688716145908885068.mbj@tail-f.com>
References:    <20131213.121509.688716145908885068.mbj@tail-f.com>
User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0)
Mail-Followup-To: netmod@ietf.org
Date: Fri, 13 Dec 2013 12:58:36 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 11:59:01 -0000

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> Andy Bierman  writes:
>>=20
>> > On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka 
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> just an idea: would it help if the server simply records the mapped
>> >> DisplayString version in state data?
>> >>
>> >>
>> > No.  I am OK with the proposal to force the server to constrain the
>> > objects
>>=20
>> Why not, actually? I mean something like this:
>>=20
>> { "system-state" : {
>>     ...
>>     "location" : "Schr=C3=B6dingerstra=C3=9Fe",
>>     "mib:sysLocation" : "Schroedingerstrasse",
>>     ...
>> }
>>=20
>> This is similar to what Randy proposed with "legacy-location", but it
>> is in *state*, so it doesn't introduce a second configuration object.
>
> But why report the MIB object at all in this case?
>
> If we decide these objects are really separate, I don't see the need
> to report the MIB object.  A manager that wants to see the SNMP object
> in addition to the NETCONF object (for some reason) can use SNMP.

But the two object are not separate, they are coupled!

If a NETCONF client configures "location", the server maps the value to a D=
isplayString, records the result in "mib:sysLocation" and updates the MIB o=
bject with it.

Conversely, if "sysLocation" is set via SNMP, both "mib:sysLocation" and "l=
ocation" are updated to that (DisplayString) value - "location" in state an=
d possibly also in configuration, though the latter is IMO problematic due =
to possible locks or pending to-be-confirmed commits.

Lada
=20
>
>
> /martin

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

From mbj@tail-f.com  Fri Dec 13 04:56:01 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E781ACCE8 for ; Fri, 13 Dec 2013 04:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M-wcgnQCfdk for ; Fri, 13 Dec 2013 04:55:59 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B27F31ACCE4 for ; Fri, 13 Dec 2013 04:55:59 -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 2652037C041; Fri, 13 Dec 2013 13:55:51 +0100 (CET)
Date: Fri, 13 Dec 2013 13:55:50 +0100 (CET)
Message-Id: <20131213.135550.900710914311144743.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References:  <20131213.121509.688716145908885068.mbj@tail-f.com> 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 12:56:01 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> =

> > Ladislav Lhotka  wrote:
> >> Andy Bierman  writes:
> >> =

> >> > On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka =

> >> > wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> just an idea: would it help if the server simply records the ma=
pped
> >> >> DisplayString version in state data?
> >> >>
> >> >>
> >> > No.  I am OK with the proposal to force the server to constrain =
the
> >> > objects
> >> =

> >> Why not, actually? I mean something like this:
> >> =

> >> { "system-state" : {
> >>     ...
> >>     "location" : "Schr=F6dingerstra=DFe",
> >>     "mib:sysLocation" : "Schroedingerstrasse",
> >>     ...
> >> }
> >> =

> >> This is similar to what Randy proposed with "legacy-location", but=
 it
> >> is in *state*, so it doesn't introduce a second configuration obje=
ct.
> >
> > But why report the MIB object at all in this case?
> >
> > If we decide these objects are really separate, I don't see the nee=
d
> > to report the MIB object.  A manager that wants to see the SNMP obj=
ect
> > in addition to the NETCONF object (for some reason) can use SNMP.
> =

> But the two object are not separate, they are coupled!
> =

> If a NETCONF client configures "location", the server maps the value
> to a DisplayString, records the result in "mib:sysLocation" and
> updates the MIB object with it.

Aha, so this is an alternative where an implementation MAY map, and if
it maps, it MUST (?) use some vendor-specific translation, and it MUST
record this in the read-only variable mib-sys-location.

If this is what you meant, I still don't think the read-only variable
is necessary.  The value is available over SNMP.


/martin

From mbj@tail-f.com  Fri Dec 13 04:58:52 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D681ACCE4 for ; Fri, 13 Dec 2013 04:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS5kqqB3OUfX for ; Fri, 13 Dec 2013 04:58:50 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 728121A1F48 for ; Fri, 13 Dec 2013 04:58:50 -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 B87D737C041; Fri, 13 Dec 2013 13:58:43 +0100 (CET)
Date: Fri, 13 Dec 2013 13:58:43 +0100 (CET)
Message-Id: <20131213.135843.1255579532320740486.mbj@tail-f.com>
To: rfc-editor@rfc-editor.org
From: Martin Bjorklund 
In-Reply-To: <20131212223250.499547FC38F@rfc-editor.org>
References: <20131212223250.499547FC38F@rfc-editor.org>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org, joelja@bogus.com, jiminychris@gmail.com
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3832)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 12:58:53 -0000

Hi,

I think the proposed new text is correct.


/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=3832
> 
> --------------------------------------
> Type: Technical
> Reported by: Chris LaBauve 
> 
> Section: 7.4.1
> 
> Original Text
> -------------
>                +------------------+---------+-------------+
>                | substatement     | section | cardinality |
>                +------------------+---------+-------------+
>                | bit              | 9.7.4   | 0..n        |
>                | enum             | 9.6.4   | 0..n        |
>                | length           | 9.4.4   | 0..1        |
>                | path             | 9.9.2   | 0..1        |
>                | pattern          | 9.4.6   | 0..n        |
>                | range            | 9.2.4   | 0..1        |
>                | require-instance | 9.13.2  | 0..1        |
>                | type             | 7.4     | 0..n        |
>                +------------------+---------+-------------+
> 
> Corrected Text
> --------------
>                +------------------+---------+-------------+
>                | substatement     | section | cardinality |
>                +------------------+---------+-------------+
>                | base             | 9.10.2  | 0..1        |
>                | bit              | 9.7.4   | 0..n        |
>                | enum             | 9.6.4   | 0..n        |
>                | fraction-digits  | 9.3.4   | 0..1        |
>                | length           | 9.4.4   | 0..1        |
>                | path             | 9.9.2   | 0..1        |
>                | pattern          | 9.4.6   | 0..n        |
>                | range            | 9.2.4   | 0..1        |
>                | require-instance | 9.13.2  | 0..1        |
>                | type             | 7.4     | 0..n        |
>                +------------------+---------+-------------+
> 
> Notes
> -----
> 9.3.4. states 'The "fraction-digits" statement, which is a substatement to the "type" statement' but 7.4.1 does not list "fraction-digits" as one of the substatements of "type".
> 
> 9.10.2. states 'The "base" statement, which is a substatement to the "type" statement' but 7.4.1 does not list "base" as one of the substatements of "type".
> 
> 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  Fri Dec 13 05:01:22 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA80B1AE256 for ; Fri, 13 Dec 2013 05:01:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXMYejdoi8qR for ; Fri, 13 Dec 2013 05:01:17 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8941B1AE255 for ; Fri, 13 Dec 2013 05:01: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 33C5237C041; Fri, 13 Dec 2013 14:01:10 +0100 (CET)
Date: Fri, 13 Dec 2013 14:01:09 +0100 (CET)
Message-Id: <20131213.140109.369240059337261031.mbj@tail-f.com>
To: rfc-editor@rfc-editor.org
From: Martin Bjorklund 
In-Reply-To: <20131212230117.8AF207FC177@rfc-editor.org>
References: <20131212230117.8AF207FC177@rfc-editor.org>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org, joelja@bogus.com, jiminychris@gmail.com
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3834)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 13:01:22 -0000

Hi,

I think the proposed new text is correct.


/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=3834
> 
> --------------------------------------
> Type: Technical
> Reported by: Chris LaBauve 
> 
> Section: 9.7.5
> 
> Original Text
> -------------
>     Given the following leaf:
> 
>      leaf mybits {
>          type bits {
>              bit disable-nagle {
>                  position 0;
>              }
>              bit auto-sense-speed {
>                  position 1;
>              }
>              bit 10-Mb-only {
>                  position 2;
>              }
>          }
>          default "auto-sense-speed";
>      }
> 
>    The lexical representation of this leaf with bit values disable-nagle
>    and 10-Mb-only set would be:
> 
>      disable-nagle 10-Mb-only
> 
> Corrected Text
> --------------
>     Given the following leaf:
> 
>      leaf mybits {
>          type bits {
>              bit disable-nagle {
>                  position 0;
>              }
>              bit auto-sense-speed {
>                  position 1;
>              }
>              bit ten-Mb-only {
>                  position 2;
>              }
>          }
>          default "auto-sense-speed";
>      }
> 
>    The lexical representation of this leaf with bit values disable-nagle
>    and ten-Mb-only set would be:
> 
>      disable-nagle ten-Mb-only
> 
> Notes
> -----
> 9.7.5. Shows a usage example of the bit statement wherein the identifier '10-Mb-only' begins with a digit, which contradicts the ABNF rule 'identifier' (identifier must begin with [_A-Za-z])
> 
> 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  Fri Dec 13 05:03:25 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BA31AE255 for ; Fri, 13 Dec 2013 05:03:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85IsKAGvAvE2 for ; Fri, 13 Dec 2013 05:03:23 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E22C81AD7C2 for ; Fri, 13 Dec 2013 05:03:22 -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 BA68237C043; Fri, 13 Dec 2013 14:03:15 +0100 (CET)
Date: Fri, 13 Dec 2013 14:03:15 +0100 (CET)
Message-Id: <20131213.140315.1085466487006884220.mbj@tail-f.com>
To: rfc-editor@rfc-editor.org
From: Martin Bjorklund 
In-Reply-To: <20131212230639.8839D7FC177@rfc-editor.org>
References: <20131212230639.8839D7FC177@rfc-editor.org>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org, joelja@bogus.com, jiminychris@gmail.com
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3835)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 13:03:26 -0000

Hi,

I think the proposed new text is correct.


/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=3835
> 
> --------------------------------------
> Type: Technical
> Reported by: Chris LaBauve 
> 
> Section: 12
> 
> Original Text
> -------------
>    type-body-stmts     = numerical-restrictions /
>                          decimal64-specification /
>                          string-restrictions /
>                          enum-specification /
>                          leafref-specification /
>                          identityref-specification /
>                          instance-identifier-specification /
>                          bits-specification /
>                          union-specification
> 
> Corrected Text
> --------------
>    type-body-stmts     = numerical-restrictions /
>                          decimal64-specification /
>                          string-restrictions /
>                          enum-specification /
>                          leafref-specification /
>                          identityref-specification /
>                          instance-identifier-specification /
>                          bits-specification /
>                          union-specification / 
>                          binary-specification
> 
>    binary-specification = [length-stmt stmtsep]
> 
> Notes
> -----
> Grammar rule 'type-body-stmts' does not provide for the case when type is 'binary'; this would be a rule allowing 0 or 1 length substatements according to 9.8.1.
> 
> 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 lhotka@nic.cz  Fri Dec 13 05:19:24 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C6E1AE26D for ; Fri, 13 Dec 2013 05:19:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnnhzAM3npvx for ; Fri, 13 Dec 2013 05:19:22 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3C61AE26C for ; Fri, 13 Dec 2013 05:19:22 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 85944140858 for ; Fri, 13 Dec 2013 14:19:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386940755; bh=mvlbHvxAqHyRAmwqYZgda9JyFEE0p+gadcCSXyhgMx8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=F0TIoWs13YItwV8/CGjcfDk3NvRxD47MjyrZiXyNVqHerekJToDjJYcw+bdyMYptu K+X5wL8eCye3vUyye/mZc2arDsh3BRTQVFfgzlleMQRCjvXV7r7z+66OjIJd1NAAek 9NJazonSzqq1Y58VFS2gpxZclghZcniKsfr+cFuA=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ladislav Lhotka 
In-Reply-To: <20131213.135550.900710914311144743.mbj@tail-f.com>
Date: Fri, 13 Dec 2013 14:19:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <67AE73D5-6415-4B05-8387-76120665A1C2@nic.cz>
References:  <20131213.121509.688716145908885068.mbj@tail-f.com>  <20131213.135550.900710914311144743.mbj@tail-f.com>
To: netmod@ietf.org
X-Mailer: Apple Mail (2.1822)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 13:19:24 -0000

On 13 Dec 2013, at 13:55, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>>=20
>>> Ladislav Lhotka  wrote:
>>>> Andy Bierman  writes:
>>>>=20
>>>>> On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka 
>>>>> wrote:
>>>>>=20
>>>>>> Hi,
>>>>>>=20
>>>>>> just an idea: would it help if the server simply records the =
mapped
>>>>>> DisplayString version in state data?
>>>>>>=20
>>>>>>=20
>>>>> No.  I am OK with the proposal to force the server to constrain =
the
>>>>> objects
>>>>=20
>>>> Why not, actually? I mean something like this:
>>>>=20
>>>> { "system-state" : {
>>>>   ...
>>>>   "location" : "Schr=F6dingerstra=DFe",
>>>>   "mib:sysLocation" : "Schroedingerstrasse",
>>>>   ...
>>>> }
>>>>=20
>>>> This is similar to what Randy proposed with "legacy-location", but =
it
>>>> is in *state*, so it doesn't introduce a second configuration =
object.
>>>=20
>>> But why report the MIB object at all in this case?
>>>=20
>>> If we decide these objects are really separate, I don't see the need
>>> to report the MIB object.  A manager that wants to see the SNMP =
object
>>> in addition to the NETCONF object (for some reason) can use SNMP.
>>=20
>> But the two object are not separate, they are coupled!
>>=20
>> If a NETCONF client configures "location", the server maps the value
>> to a DisplayString, records the result in "mib:sysLocation" and
>> updates the MIB object with it.
>=20
> Aha, so this is an alternative where an implementation MAY map, and if
> it maps, it MUST (?) use some vendor-specific translation, and it MUST
> record this in the read-only variable mib-sys-location.

Yup.

>=20
> If this is what you meant, I still don't think the read-only variable
> is necessary.  The value is available over SNMP.

Right, but performing the mapping *and* recording the result is probably =
the maximum of what a NETCONF server can be expected to do, unless we =
restrict the =93location=94 value to a DisplayString. Of course, the =
mib-sys-location leaf can be only optional, either feature-dependent or =
defined in a separate module. I am assuming it can be useful to be able =
to learn the mapped value without going to SNMP.

Lada

>=20
>=20
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From bclaise@cisco.com  Fri Dec 13 07:35:52 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040F01ADF9F for ; Fri, 13 Dec 2013 07:35:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WGtBDLUO6jy for ; Fri, 13 Dec 2013 07:35:50 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id BA7221AE1E8 for ; Fri, 13 Dec 2013 07:35:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=282; q=dns/txt; s=iport; t=1386948942; x=1388158542; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Mj62wcNdQD8o2hd3cLel5VhpFU62amLvrfuo4FGvymw=; b=Z4PoxRDoXvMeTxGiOgr1q+HEhmwMxXOLT9F6qoHEwydtMGf7aZz1Nf/J jo+OZYYdCFzD1wa3kd7vGx3B7Jo7Pyr45jpwdeTG7Kh62BPPs7Q8RH7+M VDZzL5fa5TFfapt0vwvyjILOvggr+ZIlWNMFmEML8uUn6m1kGxdNUgHRe Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAOMnq1KQ/khN/2dsb2JhbABZgwq2ZIJ8CoEjFnSCJQEBAQQ4QAEQCxgJFg8JAwIBAgFFBgEMAQcBAYgAyysXjxUHhDYBA5gWhkWLT4MrOw
X-IronPort-AV: E=Sophos;i="4.95,479,1384300800";  d="scan'208";a="2214632"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 13 Dec 2013 15:35:41 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBDFZcuk004674; Fri, 13 Dec 2013 15:35:38 GMT
Message-ID: <52AB294A.7040005@cisco.com>
Date: Fri, 13 Dec 2013 16:35:38 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ladislav Lhotka , Jernej Tuljak 
References: <20131212224239.B3D4D7FC157@rfc-editor.org> <52AAC75E.3070203@mg-soft.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Cc: joelja@bogus.com, jiminychris@gmail.com, Sean Turner , netmod@ietf.org, RFC Errata System 
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3833)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 15:35:52 -0000

On 13/12/2013 10:27, Ladislav Lhotka wrote:
> I would be actually very useful if RFCs/I-Ds had some marks in places for which errata exist, ideally with links to the corresponding erratum.
That would be nice, indeed.
Including Sean, the tools liaison manager.

Regards,Benoit






From wwwrun@rfc-editor.org  Fri Dec 13 07:40:44 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0451ADF9F; Fri, 13 Dec 2013 07:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTBB9Ldl7JpK; Fri, 13 Dec 2013 07:40:43 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id E404C1ADDD1; Fri, 13 Dec 2013 07:40:42 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 8D4A97FC390; Fri, 13 Dec 2013 07:40:36 -0800 (PST)
To: jiminychris@gmail.com, mbj@tail-f.com
From: RFC Errata System 
Message-Id: <20131213154036.8D4A97FC390@rfc-editor.org>
Date: Fri, 13 Dec 2013 07:40:36 -0800 (PST)
Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Errata Rejected] RFC6020 (3841)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 15:40:44 -0000

The following errata report has been rejected 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=3841

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Chris LaBauve 
Date Reported: 2013-12-12
Rejected by: Benoit Claise (IESG)

Section: 12

Original Text
-------------
decimal64-specification = fraction-digits-stmt

Corrected Text
--------------
decimal64-specification = ;; these stmts can appear in any order
                          fraction-digits-stmt stmtsep
                          [range-stmt stmtsep]

Notes
-----
decimal64 types should allow for a range substatement; 9.2.4 states the range statement "is used to restrict integer and decimal built-in types."
 --VERIFIER NOTES-- 
Duplicate of http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3290

--------------------------------------
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 wwwrun@rfc-editor.org  Fri Dec 13 08:23:03 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B3C1AE301; Fri, 13 Dec 2013 08:23:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYVWXmNRLmL4; Fri, 13 Dec 2013 08:23:00 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 766F81AE22D; Fri, 13 Dec 2013 08:23:00 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 18BFC7FC38F; Fri, 13 Dec 2013 08:22:54 -0800 (PST)
To: jiminychris@gmail.com, mbj@tail-f.com
From: RFC Errata System 
Message-Id: <20131213162254.18BFC7FC38F@rfc-editor.org>
Date: Fri, 13 Dec 2013 08:22:54 -0800 (PST)
Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Errata Verified] RFC6020 (3832)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 16:23:03 -0000

The following errata report has been verified 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=3832

--------------------------------------
Status: Verified
Type: Technical

Reported by: Chris LaBauve 
Date Reported: 2013-12-12
Verified by: Benoit Claise (IESG)

Section: 7.4.1

Original Text
-------------
               +------------------+---------+-------------+
               | substatement     | section | cardinality |
               +------------------+---------+-------------+
               | bit              | 9.7.4   | 0..n        |
               | enum             | 9.6.4   | 0..n        |
               | length           | 9.4.4   | 0..1        |
               | path             | 9.9.2   | 0..1        |
               | pattern          | 9.4.6   | 0..n        |
               | range            | 9.2.4   | 0..1        |
               | require-instance | 9.13.2  | 0..1        |
               | type             | 7.4     | 0..n        |
               +------------------+---------+-------------+

Corrected Text
--------------
               +------------------+---------+-------------+
               | substatement     | section | cardinality |
               +------------------+---------+-------------+
               | base             | 9.10.2  | 0..1        |
               | bit              | 9.7.4   | 0..n        |
               | enum             | 9.6.4   | 0..n        |
               | fraction-digits  | 9.3.4   | 0..1        |
               | length           | 9.4.4   | 0..1        |
               | path             | 9.9.2   | 0..1        |
               | pattern          | 9.4.6   | 0..n        |
               | range            | 9.2.4   | 0..1        |
               | require-instance | 9.13.2  | 0..1        |
               | type             | 7.4     | 0..n        |
               +------------------+---------+-------------+

Notes
-----
9.3.4. states 'The "fraction-digits" statement, which is a substatement to the "type" statement' but 7.4.1 does not list "fraction-digits" as one of the substatements of "type".

9.10.2. states 'The "base" statement, which is a substatement to the "type" statement' but 7.4.1 does not list "base" as one of the substatements of "type".

--------------------------------------
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 wwwrun@rfc-editor.org  Fri Dec 13 08:25:04 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AE91AE306; Fri, 13 Dec 2013 08:25:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsk4rCCcnnWM; Fri, 13 Dec 2013 08:25:01 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id B73A11AE22D; Fri, 13 Dec 2013 08:25:01 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 7D8E97FC390; Fri, 13 Dec 2013 08:24:55 -0800 (PST)
To: jiminychris@gmail.com, mbj@tail-f.com
From: RFC Errata System 
Message-Id: <20131213162455.7D8E97FC390@rfc-editor.org>
Date: Fri, 13 Dec 2013 08:24:55 -0800 (PST)
Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Errata Held for Document Update] RFC6020 (3834)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 16:25:04 -0000

The following errata report has been held for document update 
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=3834

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Chris LaBauve 
Date Reported: 2013-12-12
Held by: Benoit Claise (IESG)

Section: 9.7.5

Original Text
-------------
    Given the following leaf:

     leaf mybits {
         type bits {
             bit disable-nagle {
                 position 0;
             }
             bit auto-sense-speed {
                 position 1;
             }
             bit 10-Mb-only {
                 position 2;
             }
         }
         default "auto-sense-speed";
     }

   The lexical representation of this leaf with bit values disable-nagle
   and 10-Mb-only set would be:

     disable-nagle 10-Mb-only

Corrected Text
--------------
    Given the following leaf:

     leaf mybits {
         type bits {
             bit disable-nagle {
                 position 0;
             }
             bit auto-sense-speed {
                 position 1;
             }
             bit ten-Mb-only {
                 position 2;
             }
         }
         default "auto-sense-speed";
     }

   The lexical representation of this leaf with bit values disable-nagle
   and ten-Mb-only set would be:

     disable-nagle ten-Mb-only

Notes
-----
9.7.5. Shows a usage example of the bit statement wherein the identifier '10-Mb-only' begins with a digit, which contradicts the ABNF rule 'identifier' (identifier must begin with [_A-Za-z])

--------------------------------------
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 bclaise@cisco.com  Fri Dec 13 08:31:02 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A191AE35A for ; Fri, 13 Dec 2013 08:31:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level: 
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVtECA35R41t for ; Fri, 13 Dec 2013 08:31:00 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 321431AE323 for ; Fri, 13 Dec 2013 08:31:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3326; q=dns/txt; s=iport; t=1386952254; x=1388161854; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=hHV85eEw4GAcZQtah9mGLkf7fssyEpPj74yGfV0FSws=; b=MiqoLlI71qzPiDuLafhXfonOvT4b2/Wmxe5/Q5hZk5dFAlnaftOkdITX K/ep5YkIGVpH36CeXi3y5aSyXi/K0aajIosvx/fQTY2er2+I5RRDeezWP cUL87mdpFIIfqyet4ueIzDn6A4gdaj5f/v9zvDZ+lRdhWDoedsF8x1AmZ k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAPg1q1KQ/khL/2dsb2JhbAA/GoMKOLhkToEkFnSCJgEBBAEBATU2ChELIRYPCQMCAQIBDwYwBgEMBgIBAYdsAxENNsNFDYcKF40CghqENgEDliuBa4ZFhhWFOoMrOz0
X-IronPort-AV: E=Sophos;i="4.95,480,1384300800";  d="scan'208";a="1606228"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 13 Dec 2013 16:30:53 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBDGUmxi002363; Fri, 13 Dec 2013 16:30:48 GMT
Message-ID: <52AB3638.2020802@cisco.com>
Date: Fri, 13 Dec 2013 17:30:48 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: RFC Errata System , mbj@tail-f.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, david.kessens@gmail.com, jiminychris@gmail.com, netmod@ietf.org
References: <20131212230639.8839D7FC177@rfc-editor.org> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3835)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 16:31:02 -0000

Lada,

It seems I can only select a single section for an errata.
Can you please file a new errata for this correction below.

Thanks and regards, Benoit
> The text in sec. 9.4.4 also needs updating:
>
> OLD
>
>     It is used to restrict the built-in type "string", or types derived
>     from "string".
>
> NEW
>
>     It is used to restrict the built-in types "string" and "binary", or
>     types derived from them.
>
> Lada
>
> RFC Errata System  writes:
>
>> 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=3835
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Chris LaBauve 
>>
>> Section: 12
>>
>> Original Text
>> -------------
>>     type-body-stmts     = numerical-restrictions /
>>                           decimal64-specification /
>>                           string-restrictions /
>>                           enum-specification /
>>                           leafref-specification /
>>                           identityref-specification /
>>                           instance-identifier-specification /
>>                           bits-specification /
>>                           union-specification
>>
>> Corrected Text
>> --------------
>>     type-body-stmts     = numerical-restrictions /
>>                           decimal64-specification /
>>                           string-restrictions /
>>                           enum-specification /
>>                           leafref-specification /
>>                           identityref-specification /
>>                           instance-identifier-specification /
>>                           bits-specification /
>>                           union-specification /
>>                           binary-specification
>>
>>     binary-specification = [length-stmt stmtsep]
>>
>> Notes
>> -----
>> Grammar rule 'type-body-stmts' does not provide for the case when type is 'binary'; this would be a rule allowing 0 or 1 length substatements according to 9.8.1.
>>
>> 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
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From lhotka@nic.cz  Fri Dec 13 09:05:51 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CE31AE0CC for ; Fri, 13 Dec 2013 09:05:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDrL_wwgox53 for ; Fri, 13 Dec 2013 09:05:47 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B0BD61AE014 for ; Fri, 13 Dec 2013 09:05:46 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5E4FA13F7AE; Fri, 13 Dec 2013 18:05:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386954339; bh=c3Vaw3nqqA9XV62PII5OQQlJJoF/87pJttxXryQ/Gog=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tdRh7katKckEabeAomNMKkVAu1cgmgP/Ev6f52MzFGXd/uX0qnHG3/0LuYb/WArNU Vo1rfjJU0PGUe7WyZKCJnRUOSvcQmdyv1Cv/QHoErDKYeqq2kk8+MNb+g2H1gNUVBc HQ5F7wM/BQn+VYxKE1BgOITR6I4GhWhjAvk+lgnM=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ladislav Lhotka 
In-Reply-To: <52AB3638.2020802@cisco.com>
Date: Fri, 13 Dec 2013 18:05:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0025BD41-3BA8-4AA1-BA5E-A45C180D14DD@nic.cz>
References: <20131212230639.8839D7FC177@rfc-editor.org>  <52AB3638.2020802@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.1822)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org, joelja@bogus.com, jiminychris@gmail.com, RFC Errata System 
Subject: Re: [netmod] [Technical Errata Reported] RFC6020 (3835)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 17:05:51 -0000

On 13 Dec 2013, at 17:30, Benoit Claise  wrote:

> Lada,
>=20
> It seems I can only select a single section for an errata.
> Can you please file a new errata for this correction below.

OK, will do.

Lada

>=20
> Thanks and regards, Benoit
>> The text in sec. 9.4.4 also needs updating:
>>=20
>> OLD
>>=20
>>    It is used to restrict the built-in type "string", or types =
derived
>>    from "string".
>>=20
>> NEW
>>=20
>>    It is used to restrict the built-in types "string" and "binary", =
or
>>    types derived from them.
>>=20
>> Lada
>>=20
>> RFC Errata System  writes:
>>=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=3D3835
>>>=20
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Chris LaBauve 
>>>=20
>>> Section: 12
>>>=20
>>> Original Text
>>> -------------
>>>    type-body-stmts     =3D numerical-restrictions /
>>>                          decimal64-specification /
>>>                          string-restrictions /
>>>                          enum-specification /
>>>                          leafref-specification /
>>>                          identityref-specification /
>>>                          instance-identifier-specification /
>>>                          bits-specification /
>>>                          union-specification
>>>=20
>>> Corrected Text
>>> --------------
>>>    type-body-stmts     =3D numerical-restrictions /
>>>                          decimal64-specification /
>>>                          string-restrictions /
>>>                          enum-specification /
>>>                          leafref-specification /
>>>                          identityref-specification /
>>>                          instance-identifier-specification /
>>>                          bits-specification /
>>>                          union-specification /
>>>                          binary-specification
>>>=20
>>>    binary-specification =3D [length-stmt stmtsep]
>>>=20
>>> Notes
>>> -----
>>> Grammar rule 'type-body-stmts' does not provide for the case when =
type is 'binary'; this would be a rule allowing 0 or 1 length =
substatements according to 9.8.1.
>>>=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
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From wwwrun@rfc-editor.org  Fri Dec 13 09:18:35 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216091ADD9D for ; Fri, 13 Dec 2013 09:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6f7U5T4Rztm for ; Fri, 13 Dec 2013 09:18:33 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4931AD8CD for ; Fri, 13 Dec 2013 09:18:33 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 065457FC390; Fri, 13 Dec 2013 09:18:27 -0800 (PST)
To: mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, david.kessens@gmail.com
From: RFC Errata System 
Message-Id: <20131213171827.065457FC390@rfc-editor.org>
Date: Fri, 13 Dec 2013 09:18:27 -0800 (PST)
Cc: ladislav@lhotka.name, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Technical Errata Reported] RFC6020 (3842)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 17:18:35 -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=3842

--------------------------------------
Type: Technical
Reported by: Ladislav Lhotka 

Section: 9.4.4

Original Text
-------------
It is used to restrict the built-in type "string", or types derived
from "string".

Corrected Text
--------------
It is used to restrict the built-in types "string" and "binary", or
types derived from them.

Notes
-----
The "length" statement can also restrict the "binary" type. See also erratum 3835.

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 wwwrun@rfc-editor.org  Fri Dec 13 09:23:30 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EBF1ADD9D; Fri, 13 Dec 2013 09:23:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJzfWLI7RnTq; Fri, 13 Dec 2013 09:23:26 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 421BE1AD8CD; Fri, 13 Dec 2013 09:23:26 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 03B9C7FC390; Fri, 13 Dec 2013 09:23:20 -0800 (PST)
To: jiminychris@gmail.com, mbj@tail-f.com
From: RFC Errata System 
Message-Id: <20131213172320.03B9C7FC390@rfc-editor.org>
Date: Fri, 13 Dec 2013 09:23:20 -0800 (PST)
Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Errata Verified] RFC6020 (3835)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 17:23:30 -0000

The following errata report has been verified 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=3835

--------------------------------------
Status: Verified
Type: Technical

Reported by: Chris LaBauve 
Date Reported: 2013-12-12
Verified by: Benoit Claise (IESG)

Section: 12

Original Text
-------------
   type-body-stmts     = numerical-restrictions /
                         decimal64-specification /
                         string-restrictions /
                         enum-specification /
                         leafref-specification /
                         identityref-specification /
                         instance-identifier-specification /
                         bits-specification /
                         union-specification

Corrected Text
--------------
   type-body-stmts     = numerical-restrictions /
                         decimal64-specification /
                         string-restrictions /
                         enum-specification /
                         leafref-specification /
                         identityref-specification /
                         instance-identifier-specification /
                         bits-specification /
                         union-specification / 
                         binary-specification

   binary-specification = [length-stmt stmtsep]

Notes
-----
Grammar rule 'type-body-stmts' does not provide for the case when type is 'binary'; this would be a rule allowing 0 or 1 length substatements according to 9.8.1.

--------------------------------------
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 ietfdbh@comcast.net  Fri Dec 13 09:38:10 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A111ADF7E for ; Fri, 13 Dec 2013 09:38:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqFyCA251Pi7 for ; Fri, 13 Dec 2013 09:38:08 -0800 (PST)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 07E2F1ADF70 for ; Fri, 13 Dec 2013 09:38:07 -0800 (PST)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta10.westchester.pa.mail.comcast.net with comcast id 11n11n0060vyq2s5A5e15C; Fri, 13 Dec 2013 17:38:01 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta05.westchester.pa.mail.comcast.net with comcast id 15e01n00o2yZEBF3R5e1Qo; Fri, 13 Dec 2013 17:38:01 +0000
From: "ietfdbh" 
To: "'Martin Bjorklund'" , 
References:    <20131213.121509.688716145908885068.mbj@tail-f.com>
In-Reply-To: <20131213.121509.688716145908885068.mbj@tail-f.com>
Date: Fri, 13 Dec 2013 12:37:57 -0500
Message-ID: <010501cef82a$101f6190$305e24b0$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKqL//JvrIVXxVh2Om29tt5U964mAHCAgUrAkJ4W0kAfEe0GJh36O6A
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386956281; bh=ClWbMFaMcXBu42KAsd0njTj+nPrAYOIpDaJ3URcB28E=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=AR4XmQpOjfvqmcmYI+8/wduEbtB1WJdTyaUd/2nMGjBhShD9Gqm2hn28j2jp+V3Dn guyaqCtdR6+Y4bQzl8Yb+P4VOzOiRm6+OW+G5ioXr+OtRYxSagoVzTc7JZVfYjv9tN 7vJ9CuTCCzowfMFc9hLzB4G6QBnkuFtFNo5rSp05g7L5B0lDrb8wcHTiMkRXAjYMvP 5YGM6BfTWQgOxSvE3Qn50DWqekgTfZ41cqq4N9BfrfOLzRKEdN/zgsF2mf5cLwnQWJ BMEPcQI0GxQQAKL97BqOjtKLQu9541CfKs4MFamKMiovpzWiYV3Mznv/GeGIwFUqPK sEXERewTwYXuA==
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 17:38:10 -0000

Hi,

I agree with the approach of treating these as separate objects, both as =
an
SNMP greybeard and as an (ex-)NMS developer.

Following the general philosophy of good MIB design, keep the agent =
simple
and let the NMS handle complexity.
That is normally seen with the following design guideline:
"Exclude objects that are simply derivable from others in this or other =
MIB
modules."
But would also include handling correlation/synchronization between MIB
queries and YANG queries - let the NMS handle that.

Soapbox:
[Originally the IAB recommended having one data modeling language and =
one
virtual database of management objects, accessible by multiple =
protocols.
But that approach was found to be unrealistic, because the SMI became
outdated - it cannot effectively model some aspects of real-world device
implementations, such as nested tables, and would seriously limit the
functionality of non-SNMP protocols like NETCONF and ipfix and syslog. =
While
it would be nice to be able to access MIB data via other protocols,
sometimes that just isn't going to be viable without hampering new =
models
with outdated syntax and data structures. When that is the case, I think =
we
need to move on and use the new, more capable DMLs.]

David Harrington
ietfdbh@comcast.net
+1-603-828-1401

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin
> Bjorklund
> Sent: Friday, December 13, 2013 6:15 AM
> To: lhotka@nic.cz
> Cc: netmod@ietf.org
> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>=20
> Ladislav Lhotka  wrote:
> > Andy Bierman  writes:
> >
> > > On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka 
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> just an idea: would it help if the server simply records the =
mapped
> > >> DisplayString version in state data?
> > >>
> > >>
> > > No.  I am OK with the proposal to force the server to constrain =
the
> > > objects
> >
> > Why not, actually? I mean something like this:
> >
> > { "system-state" : {
> >     ...
> >     "location" : "Schr=F6dingerstra=DFe",
> >     "mib:sysLocation" : "Schroedingerstrasse",
> >     ...
> > }
> >
> > This is similar to what Randy proposed with "legacy-location", but =
it
> > is in *state*, so it doesn't introduce a second configuration =
object.
>=20
> But why report the MIB object at all in this case?
>=20
> If we decide these objects are really separate, I don't see the need
> to report the MIB object.  A manager that wants to see the SNMP object
> in addition to the NETCONF object (for some reason) can use SNMP.
>=20
>=20
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From ietfdbh@comcast.net  Fri Dec 13 10:09:57 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E145C1AE390 for ; Fri, 13 Dec 2013 10:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5rgs7u7363s for ; Fri, 13 Dec 2013 10:09:55 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id DF5A41AE375 for ; Fri, 13 Dec 2013 10:09:54 -0800 (PST)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id 15iM1n0051uE5Es5469o6f; Fri, 13 Dec 2013 18:09:48 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta16.westchester.pa.mail.comcast.net with comcast id 169n1n0102yZEBF3c69oc6; Fri, 13 Dec 2013 18:09:48 +0000
From: "ietfdbh" 
To: "'Juergen Schoenwaelder'" , "'Randy Presuhn'" 
References:  <006b01cef53a$addd68c0$6b01a8c0@oemcomputer> <20131210202911.GA74654@elstar.local>
In-Reply-To: <20131210202911.GA74654@elstar.local>
Date: Fri, 13 Dec 2013 13:09:44 -0500
Message-ID: <011501cef82e$80adf030$8209d090$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEFIaVxF7P1RbQmFWx54UHXjRq/AAHA4XdZAa43BwWbyptq8A==
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386958188; bh=BQUJT9YS8zGs3i7lCwKYHcoHTRk4o348mP3bcTM9wTg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=b84yxIFPPvWv7hRhdmq48v2nUQDY5GQU4E4NK3lN7j8oO3nK2H1S7XYXUFwiTqLxz DBhpuuo9DB4Pn6/pjKYqLfnyrL5ocYlvdKpyIRxoG8731bRM/jOnN6YArDyhW94M9H 9OvI6XumgGP6a4ZUE5mKMMgh9218HYmAARkxoYORgSgc+XWj8Ym4Ta6J92Fhlt9i0L GPV2SvOOHSNWUgUje086H/OJOsC7j/G/51gbXZkzLmnz7kXhDyb28ULVdFlTi5oDrE NjRtE/+xRU//GfLHzigVhYVjc3FLhNEFCrXudWH2VbFQD5jU7YaDuqAoeEOzyRk7ib aYmI1ubQMsGKw==
Cc: netmod@ietf.org
Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 18:09:58 -0000

Hi,

I have a question.
This document says the model is based on real-world CLI configuration of the
SNMP system.
Which vendor's CLI's were used as the basis for this model?
Are the vendors approach to CLI configuration of SNMP substantially
different or similar?

I am interested in understanding whether the bases for the model have
substantially different approaches, so we can see that the YANG model can
handle a significant range of implementation differences. 
I would be concerned if this model was derived from, for example, the Cisco
CLI and from other vendors who deliberately use a Cisco-like CLI, without
consideration of CLIs that are substantially different than Cisco's, or if
the model was derived from the configuration needs of a particular SNMP
toolkit, used by all the vendors in the sample.
I do not expect a list of the specific vendor's CLIs to be put into the
text, but I think some discussion of the size and characteristics of the
sample used to derive the new model should be discussed in the document
text.

David Harrington
ietfdbh@comcast.net
+1-603-828-1401

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> Sent: Tuesday, December 10, 2013 3:29 PM
> To: Randy Presuhn
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> 
> On Mon, Dec 09, 2013 at 03:59:19PM -0800, Randy Presuhn wrote:
> > Hi -
> >
> > > From: "David Kessens" 
> > > To: 
> > > Sent: Monday, December 09, 2013 2:25 PM
> > > Subject: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> > ...
> > > I would hereby like to start a Last Call for:
> > >
> > > http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-03
> > >
> > > Please indicate your support by Dec 20, 2013. We appreciate any type
of
> > > feedback, from "I have read the document and I like it" to more
lengthy
> > > reviews and implementation reports.
> >
> > I haven't the time or interest to spend a lot of time on this, but a
cursory
> > look at the VACM section leaves me quite concerned.
> >
> >
> > On page 49, the draft states:
> >              "VACM Groups.
> >
> >               This data model has a different structure than the MIB.
> >               Groups are explicitly defined in this list, and group
> >               members are defined in the 'member' list (mapped to
> >               vacmSecurityToGroupTable), and access for the group is
> >               defined in the 'access' list (mapped to
> >               vacmAccessTable).";
> >
> > It's not clear to me whether the Yang model can represent all valid
> > configurations of the MIB, and (see below) I have an uneasy feeling
> > that in some cases it cannot.   Constraints like "A certain combination
> > of security-name and security-model MUST NOT be present in
> > more than one group" strongly suggest to me that this is a very
> > unnatural way of modeling this.   What is gained by making this
> > model substantially different from the resource being managed?
> 
> The cited constraint "A certain combination of security-name and
> security-model MUST NOT be present in more than one group." comes from
> the way the VACM tables are organized. The vacmSecurityToGroupTable
> table is indexed by (vacmSecurityModel, vacmSecurityName). We are
> simply documenting a VACM constraint.
> 
> What is gained by the model layout? Groups become a first class
> citizen and members are naturally assigned to groups and most
> importantly you do not have to perform a join of several tables in
> order to understand the access policy of a certain group. With SNMP,
> the editing semantics cause a table organization that seems more
> complex than needed and that have certain side effects.
> 
> > I recognize that the transactional model is different here, but I'm
> > also concerned how some VACM usage scenarios would play
> > out in this model.  Consider, for example, a routine task like
> > re-assigning a "user" (identified by a [SecurityModel, SecurityName]
> > tuple) from one group to another.  It's trivial and seamless in VACM
> > (simply set a new value to vacmGroupName) but it's unclear what
> > the recommended sequence of operations would be in this proposal.
> 
> You delete the user form one group and at the same time add it to the
> target group. This feels quite natural and NETCONF can do such changes
> in an atomic edit-config.
> 
> > On page 49, the draft states:
> >
> >          list member {
> >              key "security-name";
> >              min-elements 1;
> >              description
> >                "A member of this VACM group. According to VACM, every
> >                 group must have at least one member.
> >
> > AFAICT, RFC 3415 contains no such statement, and there are legal
> > VACM configurations that seem at odds with it.  The notion of a
> > "member" of a group is only mentioned in passing, and in a set-
> > theoretical sense at that.
> 
> The question is what really defines a group in VACM. Section 7.2. says:
> 
>    [...] Within the View-Based Access Control Model, a groupName is
>    considered to exist if that groupName is listed in the
>    vacmSecurityToGroupTable.
> 
> In order to be listed in the vacmSecurityToGroupTable, the group must
> have a member (since the vacmSecurityName is part of the INDEX). Hence
> the above statement.
> 
> > Consider the case where one or more entries exist in the
> > vacmAccessTable with an index of vacmGroupName="foo", but no
> > corresponding entries exist in the vacmSecurityToGroupTable.  Such
> > configurations are explicitly supported by RFC 3415.
> 
> We could easily allow for that as well by removing "According to VACM,
> every group must have at least one member.".
> 
> > A quick look at the Security Considerations section leaves me even
> > more worried.   An important consideration in the design of the
> > VACM MIB was to be absolutely clear on the impact of the order
> > of operations on security so that, for example, provisioning access
> > permissions for a new user (or set of users) could be interrupted
> > without creating security holes.  This is an extension of my concern
> > about how trivial VACM operations could become quite elaborate in
> > this model.
> 
> I have re-read the Security Considerations section and I am not sure
> what makes you worried regarding order of operations and such things.
> 
> /js
> 
> --
> 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 ietfdbh@comcast.net  Fri Dec 13 11:31:37 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646071ADF79 for ; Fri, 13 Dec 2013 11:31:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy5AFyMX4r0h for ; Fri, 13 Dec 2013 11:31:34 -0800 (PST)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7551ADF74 for ; Fri, 13 Dec 2013 11:31:34 -0800 (PST)
Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta06.westchester.pa.mail.comcast.net with comcast id 16uy1n0071wpRvQ567XTLJ; Fri, 13 Dec 2013 19:31:27 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta18.westchester.pa.mail.comcast.net with comcast id 17XT1n00b2yZEBF3e7XTWE; Fri, 13 Dec 2013 19:31:27 +0000
From: "ietfdbh" 
To: 
References:  <006b01cef53a$addd68c0$6b01a8c0@oemcomputer> <20131210202911.GA74654@elstar.local> <011501cef82e$80adf030$8209d090$@comcast.net>
In-Reply-To: <011501cef82e$80adf030$8209d090$@comcast.net>
Date: Fri, 13 Dec 2013 14:31:24 -0500
Message-ID: <011f01cef839$e8fb4a10$baf1de30$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEFIaVxF7P1RbQmFWx54UHXjRq/AAHA4XdZAa43BwUBZ8QSMZu/eMvg
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386963087; bh=tTvF+t8x00xwMu6vRxYctwKmsOIG/ePPqR+csAaCyEw=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=AIpwW8sU3juXn36qGv5pDSMpLFWYJvChb8gn28FM7dGflkzjni2INuODI+Ca89cl0 xhqi3PJczn/415YRub4a2gG+Q7URexSSTrkYJYb/o/8S2t4UMv3XWN99JaoxxizJyW zYaXHFxJ76u+vJNo+it21679nDH13FsvKLew2CpDY8HbmvUFXEIX6S5zW0WWuOs674 vh2X89W/qOrHk6o9HPAdGkyS/yVccKvPmQiU5rMbcVB+4gZwjoJeQxsOSVSY0qnm3C PUC5ht1l6JqFD2s+CwXxjgYAl+UmjdjovHJCj3gvgEu6cnZXHu/4rEM/Fvz9uRtByL N0tGCzrMLbEuw==
Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 19:31:37 -0000

Hi,

It occurs to me that another question should be asked about the
implementations used as the basis for this model.
Were all the SNMP/MIB implementations used fully compliant to the relevant
SNMP and MIB standards?

David Harrington
ietfdbh@comcast.net
+1-603-828-1401

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of ietfdbh
> Sent: Friday, December 13, 2013 1:10 PM
> To: 'Juergen Schoenwaelder'; 'Randy Presuhn'
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> 
> Hi,
> 
> I have a question.
> This document says the model is based on real-world CLI configuration of
the
> SNMP system.
> Which vendor's CLI's were used as the basis for this model?
> Are the vendors approach to CLI configuration of SNMP substantially
> different or similar?
> 
> I am interested in understanding whether the bases for the model have
> substantially different approaches, so we can see that the YANG model can
> handle a significant range of implementation differences.
> I would be concerned if this model was derived from, for example, the
Cisco
> CLI and from other vendors who deliberately use a Cisco-like CLI, without
> consideration of CLIs that are substantially different than Cisco's, or if
> the model was derived from the configuration needs of a particular SNMP
> toolkit, used by all the vendors in the sample.
> I do not expect a list of the specific vendor's CLIs to be put into the
> text, but I think some discussion of the size and characteristics of the
> sample used to derive the new model should be discussed in the document
> text.
> 
> David Harrington
> ietfdbh@comcast.net
> +1-603-828-1401
> 
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen
> > Schoenwaelder
> > Sent: Tuesday, December 10, 2013 3:29 PM
> > To: Randy Presuhn
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03
(20131220)
> >
> > On Mon, Dec 09, 2013 at 03:59:19PM -0800, Randy Presuhn wrote:
> > > Hi -
> > >
> > > > From: "David Kessens" 
> > > > To: 
> > > > Sent: Monday, December 09, 2013 2:25 PM
> > > > Subject: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03
(20131220)
> > > ...
> > > > I would hereby like to start a Last Call for:
> > > >
> > > > http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-03
> > > >
> > > > Please indicate your support by Dec 20, 2013. We appreciate any type
> of
> > > > feedback, from "I have read the document and I like it" to more
> lengthy
> > > > reviews and implementation reports.
> > >
> > > I haven't the time or interest to spend a lot of time on this, but a
> cursory
> > > look at the VACM section leaves me quite concerned.
> > >
> > >
> > > On page 49, the draft states:
> > >              "VACM Groups.
> > >
> > >               This data model has a different structure than the MIB.
> > >               Groups are explicitly defined in this list, and group
> > >               members are defined in the 'member' list (mapped to
> > >               vacmSecurityToGroupTable), and access for the group is
> > >               defined in the 'access' list (mapped to
> > >               vacmAccessTable).";
> > >
> > > It's not clear to me whether the Yang model can represent all valid
> > > configurations of the MIB, and (see below) I have an uneasy feeling
> > > that in some cases it cannot.   Constraints like "A certain
combination
> > > of security-name and security-model MUST NOT be present in
> > > more than one group" strongly suggest to me that this is a very
> > > unnatural way of modeling this.   What is gained by making this
> > > model substantially different from the resource being managed?
> >
> > The cited constraint "A certain combination of security-name and
> > security-model MUST NOT be present in more than one group." comes
> from
> > the way the VACM tables are organized. The vacmSecurityToGroupTable
> > table is indexed by (vacmSecurityModel, vacmSecurityName). We are
> > simply documenting a VACM constraint.
> >
> > What is gained by the model layout? Groups become a first class
> > citizen and members are naturally assigned to groups and most
> > importantly you do not have to perform a join of several tables in
> > order to understand the access policy of a certain group. With SNMP,
> > the editing semantics cause a table organization that seems more
> > complex than needed and that have certain side effects.
> >
> > > I recognize that the transactional model is different here, but I'm
> > > also concerned how some VACM usage scenarios would play
> > > out in this model.  Consider, for example, a routine task like
> > > re-assigning a "user" (identified by a [SecurityModel, SecurityName]
> > > tuple) from one group to another.  It's trivial and seamless in VACM
> > > (simply set a new value to vacmGroupName) but it's unclear what
> > > the recommended sequence of operations would be in this proposal.
> >
> > You delete the user form one group and at the same time add it to the
> > target group. This feels quite natural and NETCONF can do such changes
> > in an atomic edit-config.
> >
> > > On page 49, the draft states:
> > >
> > >          list member {
> > >              key "security-name";
> > >              min-elements 1;
> > >              description
> > >                "A member of this VACM group. According to VACM, every
> > >                 group must have at least one member.
> > >
> > > AFAICT, RFC 3415 contains no such statement, and there are legal
> > > VACM configurations that seem at odds with it.  The notion of a
> > > "member" of a group is only mentioned in passing, and in a set-
> > > theoretical sense at that.
> >
> > The question is what really defines a group in VACM. Section 7.2. says:
> >
> >    [...] Within the View-Based Access Control Model, a groupName is
> >    considered to exist if that groupName is listed in the
> >    vacmSecurityToGroupTable.
> >
> > In order to be listed in the vacmSecurityToGroupTable, the group must
> > have a member (since the vacmSecurityName is part of the INDEX). Hence
> > the above statement.
> >
> > > Consider the case where one or more entries exist in the
> > > vacmAccessTable with an index of vacmGroupName="foo", but no
> > > corresponding entries exist in the vacmSecurityToGroupTable.  Such
> > > configurations are explicitly supported by RFC 3415.
> >
> > We could easily allow for that as well by removing "According to VACM,
> > every group must have at least one member.".
> >
> > > A quick look at the Security Considerations section leaves me even
> > > more worried.   An important consideration in the design of the
> > > VACM MIB was to be absolutely clear on the impact of the order
> > > of operations on security so that, for example, provisioning access
> > > permissions for a new user (or set of users) could be interrupted
> > > without creating security holes.  This is an extension of my concern
> > > about how trivial VACM operations could become quite elaborate in
> > > this model.
> >
> > I have re-read the Security Considerations section and I am not sure
> > what makes you worried regarding order of operations and such things.
> >
> > /js
> >
> > --
> > 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
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From randy_presuhn@mindspring.com  Fri Dec 13 11:34:48 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429011AE0F3 for ; Fri, 13 Dec 2013 11:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS0g7uArnUbS for ; Fri, 13 Dec 2013 11:34:46 -0800 (PST)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id EDCB61AE066 for ; Fri, 13 Dec 2013 11:34:45 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=d8bsl9Lp5YSG32S4TSDFazZluHLnSKAQOmpvkfKwqvo0GImm6da3boRAA9BxXY4G; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VrYVI-0001xE-Rn; Fri, 13 Dec 2013 14:34:28 -0500
Received: from 76.254.55.132 by webmail.earthlink.net with HTTP; Fri, 13 Dec 2013 14:34:28 -0500
Message-ID: <26823763.1386963268732.JavaMail.root@elwamui-huard.atl.sa.earthlink.net>
Date: Fri, 13 Dec 2013 11:34:28 -0800 (GMT-08:00)
From: Randy Presuhn 
To: Martin Bjorklund 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb36f9def786f04adbd0fe1c8f2c49a64f350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.35
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 19:34:48 -0000

Hi -

>From: Martin Bjorklund 
>Sent: Dec 12, 2013 11:22 PM
>To: randy_presuhn@mindspring.com
>Cc: netmod@ietf.org
>Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
>Randy Presuhn  wrote:
>> Hi -
>> 
>> >From: Juergen Schoenwaelder 
>> >Sent: Dec 12, 2013 3:52 AM
>> >To: Randy Presuhn , h@elstar.local
>> >Cc: netmod@ietf.org
>> >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>> >
>> >On Thu, Dec 12, 2013 at 12:42:57AM -0800, Randy Presuhn wrote:
>> >>
>> >> >    o  An implementation MUST allow any legal "string" (YANG string).
>> >> 
>> >> There are good reasons to restrict formatting and control characters -
>> >> I'll assume YANG strings do this already.  If not, that's another long
>> >> discussion.
>> >
>> >RFC 6020 says:
>> >
>> >   The string built-in type represents human-readable strings in YANG.
>> >   Legal characters are tab, carriage return, line feed, and the legal
>> >   characters of Unicode and ISO/IEC 10646 [ISO.10646]:
>> >
>> >     ;; any Unicode character, excluding the surrogate blocks,
>> >     ;; FFFE, and FFFF.
>> >     string = *char
>> >     char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
>> >            %x10000-10FFFF
>> >
>> >And so far, we have used these strings without further restrictions in
>> >data models when there was something to be named.
>> 
>> Very odd.  It restricts the C0 controls, but permits the C1
>> control codes?  I hope someone thought that through carefully.
>
>It is what XML Schema 1.0 says is a string.  See
>http://www.w3.org/TR/xmlschema-2/#string and the reference to
>http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Char

Let me be more direct.  To exclude, for example,
VT (vertical tab) but at the same time to include
RI (reverse line feed) in the set of permitted
characters seems ill-advised, to say the least.

I hope the rationale for including the C1 controls
(%x80-9F) while quite correctly severely limiting
the C0 controls is documented somewhere.

Randy

From lhotka@nic.cz  Fri Dec 13 11:38:49 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157C01ADF6B for ; Fri, 13 Dec 2013 11:38:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zu05ckqEnv3v for ; Fri, 13 Dec 2013 11:38:46 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6B91AD8D5 for ; Fri, 13 Dec 2013 11:38:46 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A577913FAC3; Fri, 13 Dec 2013 20:38:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386963519; bh=INXcJ8tl2nTPyfN8Sk6jHSyFrCLSnFi4Eh62DZz3EFQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=G/Met/AWUmrL3pIbdg9PEr+nn8ocgNk6/IVHvgr80wzia36Erpm/8RJ+mkxKptZyL ExrWS8AwCkT8/M01ZoTIDBnfecs5oN489aqWtcGjQtRtuuUSiBNNCMUBd9u/qlUwiK qxVIxzxFsx2/C/7Vrid1nhRzV7qWCOKUvtCBhhVs=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ladislav Lhotka 
In-Reply-To: <010501cef82a$101f6190$305e24b0$@comcast.net>
Date: Fri, 13 Dec 2013 20:38:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <92DCC53F-FE9B-4C80-B500-5C7C91492F2C@nic.cz>
References:    <20131213.121509.688716145908885068.mbj@tail-f.com> <010501cef82a$101f6190$305e24b0$@comcast.net>
To: David Harrington 
X-Mailer: Apple Mail (2.1822)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 19:38:49 -0000

On 13 Dec 2013, at 18:37, ietfdbh  wrote:

> Hi,
>=20
> I agree with the approach of treating these as separate objects, both =
as an
> SNMP greybeard and as an (ex-)NMS developer.
>=20
> Following the general philosophy of good MIB design, keep the agent =
simple
> and let the NMS handle complexity.
> That is normally seen with the following design guideline:
> "Exclude objects that are simply derivable from others in this or =
other MIB
> modules.=94

In our case, derivable would mean a standardized mapping procedure, =
right? I think it is easier to leave it to the server and just make the =
result available.

Lada

> But would also include handling correlation/synchronization between =
MIB
> queries and YANG queries - let the NMS handle that.
>=20
> Soapbox:
> [Originally the IAB recommended having one data modeling language and =
one
> virtual database of management objects, accessible by multiple =
protocols.
> But that approach was found to be unrealistic, because the SMI became
> outdated - it cannot effectively model some aspects of real-world =
device
> implementations, such as nested tables, and would seriously limit the
> functionality of non-SNMP protocols like NETCONF and ipfix and syslog. =
While
> it would be nice to be able to access MIB data via other protocols,
> sometimes that just isn't going to be viable without hampering new =
models
> with outdated syntax and data structures. When that is the case, I =
think we
> need to move on and use the new, more capable DMLs.]
>=20
> David Harrington
> ietfdbh@comcast.net
> +1-603-828-1401
>=20
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin
>> Bjorklund
>> Sent: Friday, December 13, 2013 6:15 AM
>> To: lhotka@nic.cz
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>>=20
>> Ladislav Lhotka  wrote:
>>> Andy Bierman  writes:
>>>=20
>>>> On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka 
>>>> wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> just an idea: would it help if the server simply records the =
mapped
>>>>> DisplayString version in state data?
>>>>>=20
>>>>>=20
>>>> No.  I am OK with the proposal to force the server to constrain the
>>>> objects
>>>=20
>>> Why not, actually? I mean something like this:
>>>=20
>>> { "system-state" : {
>>>    ...
>>>    "location" : "Schr=F6dingerstra=DFe",
>>>    "mib:sysLocation" : "Schroedingerstrasse",
>>>    ...
>>> }
>>>=20
>>> This is similar to what Randy proposed with "legacy-location", but =
it
>>> is in *state*, so it doesn't introduce a second configuration =
object.
>>=20
>> But why report the MIB object at all in this case?
>>=20
>> If we decide these objects are really separate, I don't see the need
>> to report the MIB object.  A manager that wants to see the SNMP =
object
>> in addition to the NETCONF object (for some reason) can use SNMP.
>>=20
>>=20
>> /martin
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From lhotka@nic.cz  Fri Dec 13 11:58:42 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C88C1AE321 for ; Fri, 13 Dec 2013 11:58:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level: 
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIKFMOi5OvwH for ; Fri, 13 Dec 2013 11:58:41 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id ADB971AD8D5 for ; Fri, 13 Dec 2013 11:58:40 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BD8A413FAC3; Fri, 13 Dec 2013 20:58:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386964714; bh=XZOdCziPvqnYACUKje5iR3ChLhZPs2TeNwJqvPSDnkg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LBEHN22IQ8u6H/JIdBJbgfqKZZcri1pBVCoumzp08Ug2ck5mewAuYnHZHC5mAwTna OGCL2bUxafYn4gjwPvcUdPoFqFCtq93AcVRABmhyaFi3OSzWyloBNv/tsxhVcGUeTV uOeL9JXXXuDALXPNuXzM79JIwhXa6B5n4R0fS2a4=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ladislav Lhotka 
In-Reply-To: <26823763.1386963268732.JavaMail.root@elwamui-huard.atl.sa.earthlink.net>
Date: Fri, 13 Dec 2013 20:58:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4EBD5CDC-81C1-480F-B214-C4380AE54953@nic.cz>
References: <26823763.1386963268732.JavaMail.root@elwamui-huard.atl.sa.earthlink.net>
To: Randy Presuhn 
X-Mailer: Apple Mail (2.1822)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 19:58:42 -0000

On 13 Dec 2013, at 20:34, Randy Presuhn  =
wrote:

> Hi -
>=20
>> From: Martin Bjorklund 
>> Sent: Dec 12, 2013 11:22 PM
>> To: randy_presuhn@mindspring.com
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>>=20
>> Randy Presuhn  wrote:
>>> Hi -
>>>=20
>>>> From: Juergen Schoenwaelder 
>>>> Sent: Dec 12, 2013 3:52 AM
>>>> To: Randy Presuhn , h@elstar.local
>>>> Cc: netmod@ietf.org
>>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>>>>=20
>>>> On Thu, Dec 12, 2013 at 12:42:57AM -0800, Randy Presuhn wrote:
>>>>>=20
>>>>>>   o  An implementation MUST allow any legal "string" (YANG =
string).
>>>>>=20
>>>>> There are good reasons to restrict formatting and control =
characters -
>>>>> I'll assume YANG strings do this already.  If not, that's another =
long
>>>>> discussion.
>>>>=20
>>>> RFC 6020 says:
>>>>=20
>>>>  The string built-in type represents human-readable strings in =
YANG.
>>>>  Legal characters are tab, carriage return, line feed, and the =
legal
>>>>  characters of Unicode and ISO/IEC 10646 [ISO.10646]:
>>>>=20
>>>>    ;; any Unicode character, excluding the surrogate blocks,
>>>>    ;; FFFE, and FFFF.
>>>>    string =3D *char
>>>>    char =3D %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
>>>>           %x10000-10FFFF
>>>>=20
>>>> And so far, we have used these strings without further restrictions =
in
>>>> data models when there was something to be named.
>>>=20
>>> Very odd.  It restricts the C0 controls, but permits the C1
>>> control codes?  I hope someone thought that through carefully.
>>=20
>> It is what XML Schema 1.0 says is a string.  See
>> http://www.w3.org/TR/xmlschema-2/#string and the reference to
>> http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Char
>=20
> Let me be more direct.  To exclude, for example,
> VT (vertical tab) but at the same time to include
> RI (reverse line feed) in the set of permitted
> characters seems ill-advised, to say the least.

That was the (somewhat arbitrary) decision taken for XML 1.0. And since =
it is the serialization format for NETCONF, it was quite logical to =
adopt it for YANG, too.

>=20
> I hope the rationale for including the C1 controls
> (%x80-9F) while quite correctly severely limiting
> the C0 controls is documented somewhere.

Note that XML 1.1 allows #x1..#x1f, represented as character references. =
BTW, an ultra-long discussion about hairy Unicode issues is now going on =
in the JSON WG mailing list.

Lada


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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From randy_presuhn@mindspring.com  Fri Dec 13 14:00:10 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A671AE41A for ; Fri, 13 Dec 2013 14:00:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCqiSibm6sQz for ; Fri, 13 Dec 2013 14:00:07 -0800 (PST)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9F21AE409 for ; Fri, 13 Dec 2013 14:00:07 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XQvpWFdH6tbnIMhYKP4qibt2iCHZPQbWHXySDolrilhb2cfnYVONUD+sLy8Tntxy; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.34] (helo=elwamui-hound.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Vram8-000434-7a for netmod@ietf.org; Fri, 13 Dec 2013 17:00:00 -0500
Received: from 99.187.237.104 by webmail.earthlink.net with HTTP; Fri, 13 Dec 2013 17:00:00 -0500
Message-ID: <30185064.1386972000252.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
Date: Fri, 13 Dec 2013 14:00:00 -0800 (GMT-08:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb326bf927e494a4e52e7da4c61fa2474f350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.34
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 22:00:10 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Dec 13, 2013 11:58 AM
>To: Randy Presuhn 
>Cc: Martin Bj=C3=B6rklund , netmod@ietf.org
>Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
>
>On 13 Dec 2013, at 20:34, Randy Presuhn  wro=
te:
>
>> Hi -
>>=20
>>> From: Martin Bjorklund 
>>> Sent: Dec 12, 2013 11:22 PM
>>> To: randy_presuhn@mindspring.com
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>>>=20
>>> Randy Presuhn  wrote:
>>>> Hi -
>>>>=20
>>>>> From: Juergen Schoenwaelder 
>>>>> Sent: Dec 12, 2013 3:52 AM
>>>>> To: Randy Presuhn , h@elstar.local
>>>>> Cc: netmod@ietf.org
>>>>> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>>>>>=20
>>>>> On Thu, Dec 12, 2013 at 12:42:57AM -0800, Randy Presuhn wrote:
>>>>>>=20
>>>>>>>   o  An implementation MUST allow any legal "string" (YANG string).
>>>>>>=20
>>>>>> There are good reasons to restrict formatting and control characters=
 -
>>>>>> I'll assume YANG strings do this already.  If not, that's another lo=
ng
>>>>>> discussion.
>>>>>=20
>>>>> RFC 6020 says:
>>>>>=20
>>>>>  The string built-in type represents human-readable strings in YANG.
>>>>>  Legal characters are tab, carriage return, line feed, and the legal
>>>>>  characters of Unicode and ISO/IEC 10646 [ISO.10646]:
>>>>>=20
>>>>>    ;; any Unicode character, excluding the surrogate blocks,
>>>>>    ;; FFFE, and FFFF.
>>>>>    string =3D *char
>>>>>    char =3D %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
>>>>>           %x10000-10FFFF
>>>>>=20
>>>>> And so far, we have used these strings without further restrictions i=
n
>>>>> data models when there was something to be named.
>>>>=20
>>>> Very odd.  It restricts the C0 controls, but permits the C1
>>>> control codes?  I hope someone thought that through carefully.
>>>=20
>>> It is what XML Schema 1.0 says is a string.  See
>>> http://www.w3.org/TR/xmlschema-2/#string and the reference to
>>> http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Char
>>=20
>> Let me be more direct.  To exclude, for example,
>> VT (vertical tab) but at the same time to include
>> RI (reverse line feed) in the set of permitted
>> characters seems ill-advised, to say the least.
>
>That was the (somewhat arbitrary) decision taken for XML 1.0.
>And since it is the serialization format for NETCONF, it was
>quite logical to adopt it for YANG, too.

This has nothing to do with serialization.  This is
a question of which code points are permitted within
strings intended for human consumption.

>> I hope the rationale for including the C1 controls
>> (%x80-9F) while quite correctly severely limiting
>> the C0 controls is documented somewhere.
>
>Note that XML 1.1 allows #x1..#x1f, represented as
>character references.
...

That's beside the point.  Permitting a reverse line feed
(or any of the other C1 controls) in sysContact, while
prohibiting a vertical tab, makes no sense at all.  See
http://en.wikipedia.org/wiki/C0_and_C1_control_codes#C1_set
for an overview of this rogues' gallery of characters,
and consider whether it's really a good idea to permit
them for use in labeling interfaces, etc.


Note that we took a somewhat different course in defining
SnmpAdminString in RFC 3411, and this results in a technical
incompatibility.  RFC 3411 addresses the issue of C0 and C1
with a mere recommendation: "The use of control codes should
be avoided."  What this means is that it is perfectly legal,
though operationally not recommended, for a MIB object with
syntax SnmpAdminString (not further constrained by the object-
type's description) to contain code points *prohibited*
by the RFC 6020 string type.

Randy

From ietfdbh@comcast.net  Fri Dec 13 15:32:08 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96361AE10C for ; Fri, 13 Dec 2013 15:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Zif57oAMY6j for ; Fri, 13 Dec 2013 15:32:03 -0800 (PST)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 31C761ADFD6 for ; Fri, 13 Dec 2013 15:32:03 -0800 (PST)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta14.westchester.pa.mail.comcast.net with comcast id 1BDF1n0010bG4ec5EBXwB6; Fri, 13 Dec 2013 23:31:56 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta03.westchester.pa.mail.comcast.net with comcast id 1BXw1n0012yZEBF3PBXwyL; Fri, 13 Dec 2013 23:31:56 +0000
From: "ietfdbh" 
To: "'David Kessens'" , 
References: 
In-Reply-To: 
Date: Fri, 13 Dec 2013 18:31:52 -0500
Message-ID: <014201cef85b$81260cf0$837226d0$@comcast.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0143_01CEF831.98538760"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEFIaVxF7P1RbQmFWx54UHXjRq/AJvmG00g
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386977516; bh=lTRUntdI7IvG8tSC/XW7W4dor9H2o89ABU9xpbHyf+c=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=dmzQ5ybxbnRqwFGnquGyAe4B2U81GPh2XEetG1nSht/sT0Vxveyf8qAOHMYMLW27Q b9UI07VKWGrEaeO2Tj1UQHSREW0JNDaCiZKzlw5aOCMiFR0pui+oKyDir2+20Wf+Ha mLqetMxvbl1cy350UBkT+rLk8HESKCey+tuFY+YA8ekKTMLxCcrTGdpw8qEq8yQ60X rq2MECN7i/m3ygqT1VrX7K50svGKQMyj3uohEkgBS7q3kOLhHCy2awq3oQhsU33W0b PjdRqHcL+bn3okReTdzXItYLWmF87LRnScftzvQrJ+x89YCeMaddXC8x5hJ6VP4Uiw gWpsVBdRLceZw==
Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Dec 2013 23:32:09 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0143_01CEF831.98538760
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,

 

I apologize for not getting a review done earlier in the process.

After a quick comparison between rfc3413 and ietf-snmp-common, I have some
comments and concerns.

 

I question the statement in the Introduction, "The configuration model is
consistent

   with the MIB modules defined in ."

 

 

1) I am concerned that StorageType is not modeled.

I understand the different persistence approaches; I don't consider
StorageType to be only about persistence of dynamically-set data, and which
datastore to use, but rather reporting on implementation choices. 

Looking at RFC3413 as an example, I would think an operator might want to
know whether an SnmpTargetAddrEntry is implemented in RAM or ROM. Being able
to read the StorageType of the existing table could save a client the chore
of weeding out rows of configuration data that are sure to fail, if the row
is not writable. At a minimum, I think this should be reported as
operational state, so an operator can determine why a particular
configuration attempt is failing.

 

2) I am concerned that RowStatus is not modeled. Rowstatus objects
constrains how configuration can be performed on the row. For example,
snmpTargetAddrRowStatus states that TDomain and TAddress may not be modified
if the value of RowStatus is active(1). I assume there was a very good
reason for putting that constraint into this table. Does NETCONF get to just
ignore that constraint, and overwrite the values of TDomain and TAddress
even if RowStatus is active? 

 

This has nothing to do with persistence across reboots; it has to do with
controlling how the row can be modified at runtime, and how a row can be
created and deleted. Some of these constraints are to ensure that changes
cannot be made in the middle of an operation, thereby affecting the
operation. Some of these constraints relate to security, such as the control
of who gets notified of a security violation. Having NETCONF
create/modify/delete rows while ignoring the RowStatus rules would seem to
create both operational and security risks.

 

3) "When the snmpTargetAddrParams object contains a reference

              to a non-existing snmpTargetParamsEntry, this choice does

              not contain any case, and vice versa.";

Is this consistent with RFC3413: 

"            Until instances of all corresponding columns are

            appropriately configured, the value of the

            corresponding instance of the snmpTargetAddrRowStatus

            column is 'notReady'.

 

            In particular, a newly created row cannot be made

            active until the corresponding instances of

            snmpTargetAddrTDomain, snmpTargetAddrTAddress, and

            snmpTargetAddrParams have all been set."

Are all required objects in target and params required when using NETCONF to
create a row?

 

3) From RFC3414: "The use of usmUserSpinlock is to avoid conflicts with
another SNMP command generator application which may also be acting on the
usmUserTable." The YANG model doesn't support spinlock; how does Netconf
avoid conflicts with other command generators working on the usmUserTable?
Let's assume a command generator has started building the necessary tables,
using spinlock to differentiate their processes from other processes, and
Netconf interrupts that process. 

 

4) Is there a reason the example for configuring the engine in appendix A
uses ip=0.0.0.0 and ip=::? I didn't notice any special semantics associated
with this value in the description of  or inet:ip-address. RFC5737
contains blocks of addresses reserved for documentation purposes.

 

5) The security implications of not using the RFC3414 method for cloning and
key change are not discussed.

 

6) I think the examples could benefit from a few comment lines to indicate
why the choice of values, such as the value of engineID, the values of IP
addresses, and the value of the key in the usm config example.

 

7) I am having some difficulty understanding the purpose of the YANG snmp
models. I would assume one might use the YANG model with NETCONF to
initially configure the SNMP subsystem on a device, and then to subsequently
use SNMP based on that configuration. But the YANG model is omitting objects
that are REQUIRED for some aspects of SNMP to work properly. For example, as
far as I can tell, an SNMP admin (or security admin or SNMP application)
could not perform a keychange operation using SNMP because the YANG model
would not have initialized the necessary SNMP objects, such as clonefrom.
But other than to say that the YANG doesn't include some of the objects
defined in the MIB, there is no discussion of the operational and security
implications of not configuring these objects for subsequent use in SNMP.

 

I guess the answer is that if you use Netconf and YANG to initially
configure USM, then you can only manage it in the future using NETCONF and
YANG; it seems that it stops being manageable via SNMP. SNMP-manageable
security and SNMP-manageable access control were important goals of the
SNMPv3 WG, as documented in RFC3411 design requirement sections A.1.2 and
A.4.

 

I question whether this document should be allowed to advance given this
lack of complete configuration of the targeted SNMP MIB modules, but if it
is, then I think it is really important to spell out the implications in an
operational considerations section, and in the security considerations
section.

 

 

David Harrington

  ietfdbh@comcast.net

+1-603-828-1401

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of David Kessens
Sent: Monday, December 09, 2013 5:26 PM
To: netmod@ietf.org
Subject: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)

 

 

Hi,

I would hereby like to start a Last Call for:       

http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-03
     
Please indicate your support by Dec 20, 2013. We appreciate any type of
feedback, from "I have read the document and I like it" to more lengthy
reviews and implementation reports.

Thanks!

David Kessens
co-chair netmod wg
---  


------=_NextPart_000_0143_01CEF831.98538760
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,
 
I apologize for not getting a review done earlier in =
the process.
After =
a quick comparison between rfc3413 and ietf-snmp-common, I have some =
comments and concerns.
 
I question the statement in the Introduction, “The configuration model is =
consistent
   with the MIB modules defined in =
…”
 
 
1) I am concerned that StorageType is not =
modeled.
I =
understand the different persistence approaches; I don’t consider =
StorageType to be only about persistence of dynamically-set data, and =
which datastore to use, but rather reporting on implementation choices. =

Looking at RFC3413 as an example, I would think an =
operator might want to know whether an SnmpTargetAddrEntry =
is implemented in RAM or ROM. Being able to read the StorageType of the =
existing table could save a client the chore of weeding out rows of =
configuration data that are sure to fail, if the row is not writable. At =
a minimum, I think this should be reported as operational state, so an =
operator can determine why a particular configuration attempt is =
failing.
 
2) I am concerned =
that RowStatus is not modeled. Rowstatus objects constrains how =
configuration can be performed on the row. For example, =
snmpTargetAddrRowStatus states that TDomain and TAddress may not be =
modified if the value of RowStatus is active(1). I assume there was a =
very good reason for putting that constraint into this table. Does =
NETCONF get to just ignore that constraint, and overwrite the values of =
TDomain and TAddress even if RowStatus is active? =

 
This has nothing to =
do with persistence across reboots; it has to do with controlling how =
the row can be modified at runtime, and how a row can be created and =
deleted. Some of these constraints are to ensure that changes cannot be =
made in the middle of an operation, thereby affecting the operation. =
Some of these constraints relate to security, such as the control of who =
gets notified of a security violation. Having NETCONF =
create/modify/delete rows while ignoring the RowStatus rules would seem =
to create both operational and security risks.
 
3) “When the snmpTargetAddrParams object =
contains a reference
           &=
nbsp;  to a non-existing snmpTargetParamsEntry, this choice =
does
           &=
nbsp;  not contain any case, and vice =
versa.";
Is this consistent with RFC3413: =

“            =
Until instances of all corresponding columns are
            =
appropriately configured, the value of the
            =
corresponding instance of the =
snmpTargetAddrRowStatus
            =
column is 'notReady'.
 
            =
In particular, a newly created row cannot be =
made
            =
active until the corresponding instances of
            =
snmpTargetAddrTDomain, snmpTargetAddrTAddress, =
and
            =
snmpTargetAddrParams have all been set.”
Are all required objects in target =
and params required when using NETCONF to create a =
row?
 
3) From RFC3414: “The use of =
usmUserSpinlock is to avoid conflicts with another SNMP command =
generator application which may also be acting on the =
usmUserTable.” The YANG model doesn’t support spinlock; how =
does Netconf avoid conflicts with other command generators working on =
the usmUserTable? Let’s assume a command generator has started =
building the necessary tables, using spinlock to differentiate their =
processes from other processes, and Netconf interrupts that process. =

 
4) Is there a reason the example for configuring the engine in =
appendix A uses ip=3D0.0.0.0 and ip=3D::? I didn’t notice any =
special semantics associated with this value in the description of =
<ip> or inet:ip-address. RFC5737 contains blocks of addresses =
reserved for documentation purposes.
 
5) The security =
implications of not using the RFC3414 method for cloning and key change =
are not discussed.
 
6) I think the =
examples could benefit from a few comment lines to indicate why the =
choice of values, such as the value of engineID, the values of IP =
addresses, and the value of the key in the usm config =
example.
 
7) I am having some difficulty understanding the purpose of the YANG =
snmp models. I would assume one might use the YANG model with NETCONF to =
initially configure the SNMP subsystem on a device, and then to =
subsequently use SNMP based on that configuration. But the YANG model is =
omitting objects that are REQUIRED for some aspects of SNMP to work =
properly. For example, as far as I can tell, an SNMP admin (or security =
admin or SNMP application) could not perform a keychange operation using =
SNMP because the YANG model would not have initialized the necessary =
SNMP objects, such as clonefrom. But other than to say that the YANG =
doesn’t include some of the objects defined in the MIB, there is =
no discussion of the operational and security implications of not =
configuring these objects for subsequent use in =
SNMP.
 
I guess the answer is that if you use Netconf and YANG to initially =
configure USM, then you can only manage it in the future using NETCONF =
and YANG; it seems that it stops being manageable via SNMP. =
SNMP-manageable security and SNMP-manageable access control were =
important goals of the SNMPv3 WG, as documented in RFC3411 design =
requirement sections A.1.2 and A.4.
 
I question whether this document should be allowed to advance given =
this lack of complete configuration of the targeted SNMP MIB modules, =
but if it is, then I think it is really important to spell out the =
implications in an operational considerations section, and in the =
security considerations section.
 
 
David Harrington
ietfdbh@comca=
st.net
+1-603-828-1401
From:=
 =
netmod [mailto:netmod-bounces@ietf.org] On Behalf Of David =
Kessens
Sent: Monday, December 09, 2013 5:26 PM
To: =
netmod@ietf.org
Subject: [netmod] Last Call: =
draft-ietf-netmod-snmp-cfg-03 =
(20131220)
 
 
Hi,

I would hereby like to start a =
Last Call for:       

http://=
tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-03
  &nbs=
p;  
Please indicate your support by Dec 20, 2013. We appreciate =
any type of
feedback, from "I have read the document and I like =
it" to more lengthy
reviews and implementation =
reports.

Thanks!

David Kessens
co-chair netmod =
wg
---  

------=_NextPart_000_0143_01CEF831.98538760--


From lhotka@nic.cz  Sat Dec 14 02:21:43 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA441ADFB7 for ; Sat, 14 Dec 2013 02:21:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level: 
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dav7IhMF5QqI for ; Sat, 14 Dec 2013 02:21:31 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD731ADF80 for ; Sat, 14 Dec 2013 02:17:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 47539540623 for ; Sat, 14 Dec 2013 11:17:21 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9YsiQnUw+m8 for ; Sat, 14 Dec 2013 11:17:18 +0100 (CET)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id EB24B540113 for ; Sat, 14 Dec 2013 11:17:17 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: <30185064.1386972000252.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
References: <30185064.1386972000252.JavaMail.root@elwamui-hound.atl.sa.earthlink.net>
User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0)
Mail-Followup-To: netmod@ietf.org
Date: Sat, 14 Dec 2013 11:17:16 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Dec 2013 10:21:43 -0000

Randy Presuhn  writes:

...

>>> Let me be more direct.  To exclude, for example,
>>> VT (vertical tab) but at the same time to include
>>> RI (reverse line feed) in the set of permitted
>>> characters seems ill-advised, to say the least.
>>
>>That was the (somewhat arbitrary) decision taken for XML 1.0.
>>And since it is the serialization format for NETCONF, it was
>>quite logical to adopt it for YANG, too.
>
> This has nothing to do with serialization.  This is
> a question of which code points are permitted within
> strings intended for human consumption.

So you are advocating a more restricted string type, rather than more liberal, right? That wasn't clear to me. In this case I tend to agree. It should be possible to find a subset of UCS that satisfies all thinkable needs of network management and yet avoids the dark alleys of Unicode and possible pitfalls for interoperability.

Judging from another ongoing discussion in the JSON WG, it was a very good decision to remove floating-point numbers from YANG.

Lada
 
>
>>> I hope the rationale for including the C1 controls
>>> (%x80-9F) while quite correctly severely limiting
>>> the C0 controls is documented somewhere.
>>
>>Note that XML 1.1 allows #x1..#x1f, represented as
>>character references.
> ...
>
> That's beside the point.  Permitting a reverse line feed
> (or any of the other C1 controls) in sysContact, while
> prohibiting a vertical tab, makes no sense at all.  See
> http://en.wikipedia.org/wiki/C0_and_C1_control_codes#C1_set
> for an overview of this rogues' gallery of characters,
> and consider whether it's really a good idea to permit
> them for use in labeling interfaces, etc.
>
>
> Note that we took a somewhat different course in defining
> SnmpAdminString in RFC 3411, and this results in a technical
> incompatibility.  RFC 3411 addresses the issue of C0 and C1
> with a mere recommendation: "The use of control codes should
> be avoided."  What this means is that it is perfectly legal,
> though operationally not recommended, for a MIB object with
> syntax SnmpAdminString (not further constrained by the object-
> type's description) to contain code points *prohibited*
> by the RFC 6020 string type.
>
> Randy
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

From mbj@tail-f.com  Sun Dec 15 13:03:43 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6F41AC4AB for ; Sun, 15 Dec 2013 13:03:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.539
X-Spam-Level: 
X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gySfenbqvjtx for ; Sun, 15 Dec 2013 13:03:41 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7523C1A1F62 for ; Sun, 15 Dec 2013 13:03:41 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C98A37C049; Sun, 15 Dec 2013 22:03:39 +0100 (CET)
Date: Sun, 15 Dec 2013 22:03:38 +0100 (CET)
Message-Id: <20131215.220338.304654767.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20131203151610.GB71692@elstar.local>
References: <20131203151610.GB71692@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Dec 2013 21:03:43 -0000

Hi,

I have reviewed this document, and here are my comments:


I plan to implement this data model for a non-router (host).  In the
introduction and objectives section it is mentioned that this data
model is suitable for such a device.  I think the document should
include a section that discusses what such an implementation should
do.  For example, implement the "static" and "direct"
pseudo-protocols, allow exactly one user-controlled routing instance
(?), do not implement "multiple-ribs".  What does router-id mean for a
host?  Does a host have to implement the configuration tree for ribs?

-----------

In v{4,6}ur, the term "gateway" is used.  Should this be "next-hop"
instead?

-----------

In the document, term "netxhop" is used.  Should this be "next hop"
(in text) and "next-hop" (in data models).

-----------

5.1

   A routing instance together with its operational status is
   represented as an entry of the list "/routing-state/
   routing-instance", and identified by a unique numeric identifier.
   Configuration of that router instance appears as entry of the list
   "/routing/routing-instance" whose key is a routing instance name
   selected by the client.

But there is no numeric identifier anymore.

And: s/operational status/operational state/

-----------

Since the /routing-state/routing-instance list has a name, and the
name is the key, why does it also have an "id", and why is the "id"
used in references to the routing-instance?  When I invoke the
"active-route" operation, I have to first figure out the "id" of the
routing-instance, and then use this id.  It seems simpler to always
use the name.   Also, the "id" is optional, which makes it unsuitable
to be used as an identifier.

The same comment applies to /routing-state/ribs/rib.

Also, for the lists that do need an "id" (route, nexthop), the id leaf
needs to be mandatory.

-----------

In 5.4.1:

   Every routing instance MUST implement exactly one instance of the
   "direct" pseudo-protocol type.  The name of this instance MUST also
   be "direct".

Why does this name have to be "direct"?  I think this should be
removed or explained, b/c now if seems arbitrary.

------------

Editorial nit:  your yin2yang script adds (or doesn't strip) empty
lines in some cases:

       description
         "Return the current number of routes in a RIB.

          If the RIB with 'id' equal to 'rib-id' doesn't exist, then
          this operation SHALL fail with error-tag 'data-missing' and
          error-app-tag 'rib-not-found'.
         ";

-----------

Editorial: s/RIBS/RIBs/



/martin



Juergen Schoenwaelder  wrote:
> Hi,
> 
> I hereby like to start a WG last call for the document "A YANG Data
> Model for Routing Management":
> 
>   http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-12
> 
> Please indicate your support by Friday December 20th. We are not only
> interested in receiving defect reports, we are equally interested in
> statements of the form:
> 
>   "I have reviewed I-D XYZ and I found no issues"
>   "I have implemented the data model in I-D XYZ"
>   "I am implementing the data model in I-D XYZ"
>   "I am considering to implement the data model in I-D XYZ"
> 
> This is the 1st WG last call on this document.
> 
> /js

From mbj@tail-f.com  Sun Dec 15 13:58:03 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0211AE1D3 for ; Sun, 15 Dec 2013 13:58:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.539
X-Spam-Level: 
X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r38uKlXdSUiH for ; Sun, 15 Dec 2013 13:58:01 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 95F181AE10E for ; Sun, 15 Dec 2013 13:58:00 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 6B7E3240C0F8; Sun, 15 Dec 2013 22:57:59 +0100 (CET)
Date: Sun, 15 Dec 2013 22:57:59 +0100 (CET)
Message-Id: <20131215.225759.156246264.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20131212203709.GF81732@elstar.local>
References: <001b01cef716$295e2520$6b01a8c0@oemcomputer> <004a01cef75c$b8610120$29230360$@comcast.net> <20131212203709.GF81732@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Dec 2013 21:58:03 -0000

Juergen Schoenwaelder  wrote:
> Hi,
> 
> I believe we need a reality check here. Unfortunately, I do not have
> access to many recent devices. I would like to know what todays devices
> do if you configure properties via the CLI that are export via SNMP
> agents.
> 
> - Do boxes reject anything at the CLI that does not conform to
>   DisplayStrings?

One router I tried did this.

> - Or do CLIs accept stuff and the agents provide strings not
>   conforming to DisplayStrings?

One router I tried did this.

> - Or do CLIs accept stuff and there is implementation specific
>   translation happening?
> 
> For me, US 7-bit ASCII forever can't really be the answer.
> 
> /js
> 
> PS: At least on common *nix systems, the SNMP agent is a completely
>     separate process - one out of many. If I change the name of my
>     interface (and I can change it pretty arbitrarily), the SNMP agent
>     is not being asked and it has to deal with the name it finds the
>     kernel using. Some of the popular SNMP code bases out there not
>     even manage to properly truncate strings to DisplayString size. I
>     know it is a weak argument but in the real world, I am sure
>     management systems already have to deal with these issues.

This seems to indicate that it would be best to remove the current
mapping between YANG and SNMP objects.

I'll start a new thread on this issue...


/martin



> 
> On Thu, Dec 12, 2013 at 12:08:03PM -0500, ietfdbh wrote:
> > Hi,
> > 
> > Personally, I think it would be simpler to just have the YANG objects be
> > constrained by DisplayString syntax, but then, I come from a country where
> > 7-bit ASCII covers my language of choice. It would be nice to have a
> > consistent underlying instrumentation without duplication of effort and
> > resources, but that would require choosing the least common denominator
> > (DisplayString). 
> > 
> > My second choice would be to treat them as separate instances, one of
> > DisplayString syntax, one of YANG string syntax. That way, we don't have to
> > worry about side effects of changing the YANG object via the MIB, or
> > changing the MIB object via YANG. If we want to internationalize the syntax,
> > you cannot do that to the MIB within SMI limits. Mapping between them if
> > they support different syntax raises a whole lot of issues for the database
> > handling and UI of an NMS, stands the chance of breaking existing
> > implementations if implementers handle the translations wrong or in a
> > non-interoperable manner, and stands the chance of misleading operators (and
> > applications) if the value of the MIB object is changed dynamically because
> > the value is changed (in any way) via translation from the YANG object. 
> > 
> > I think it would be better for standardization and interoperability if we do
> > not try to force-feed new syntax into the existing MIB object(s). If you
> > were trying to do this by updating the MIB, you would most certainly need to
> > define a new object (much like we had to do with Counter64s to replace
> > Counter32s). If the YANG object is treated as a separate object from the MIB
> > object, then if and when the MIB is updated, the MIB can add an object to
> > map to the YANG object, and deprecate the DisplayString syntax object.
> > 
> > If the YANG object says it can be mapped, then I think the YANG object must
> > REQUIRE that it be implemented with DisplayString constraints, whether a
> > server implementation maps to the MIB or not. Assuming an NMS supports both
> > MIB and YANG queries, and an implementer MAY treat them as separate, then
> > the NMS must treat them as separate. If the implementer MAY treat them as
> > mapped, the NMS still needs to implement them as separate because they MAY
> > be separate, but the NMS probably must treat the NMS-side variables as
> > mapped to ensure they are in sync; otherwise reading the value via the MIB
> > without simultaneously reading the value via YANG would lead to the NMS
> > potentially displaying different values even though on the device the values
> > are the same. This optionality greatly increases the complexity of
> > implementing these objects on the NMS side. An NMS would need to determine
> > whether the agent/server implemented these as mapped or separate, presumably
> > by changing one and seeing if it affected the other, so it knew whether to
> > try to perform synchronization between the two. Lots of work for limited
> > benefit to the operator. And if NMS implementations handled synchronization
> > differently, the operator is stuck trying to manage with conflicting
> > information from different NMSs.
> > 
> > It would be much better to standardize the expectation - either these
> > objects MUST be mapped and constrained by DisplayString syntax per the IETF,
> > or MUST be defined as separate objects of different syntax per the IETF
> > standard. Then an NMS implementer knows what to expect.
> > 
> > David Harrington
> > ietfdbh@comcast.net
> > +1-603-828-1401
> > > -----Original Message-----
> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy
> > > Presuhn
> > > Sent: Thursday, December 12, 2013 3:43 AM
> > > To: Martin Bjorklund
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > 
> > > Hi -
> > > 
> > > > From: "Martin Bjorklund" 
> > > > To: 
> > > > Cc: ; 
> > > > Sent: Wednesday, December 11, 2013 11:52 PM
> > > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > >
> > > > Randy Presuhn  wrote:
> > > > > Hi -
> > > > >
> > > > > >From: Juergen Schoenwaelder  > > university.de>
> > > > > >Sent: Dec 11, 2013 12:38 AM
> > > > > >To: Randy Presuhn 
> > > > > >Cc: netmod@ietf.org
> > > > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> > > > > >
> > > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
> > > > > >
> > > > > >> > Anyway, for a standardized approach, someone would have to write
> > > a
> > > > > >> > document that defines how unicode code points are represented as
> > > > > >> > escaped charater sequences in DisplayStrings. I do not think that
> > this
> > > > > >> > document is in charge of doing this. Hence, until such a standard
> > is
> > > > > >> > written, I think things need to be implementation specific.
> > > > > >>
> > > > > >> Perhaps, though that is the route to being stuck with ASCII until
> > the
> > > > > >> successor to Netconf rolls along.
> > > > > >
> > > > > >Not necessarily. If you configure via NETCONF (or most CLIs these
> > > > > >days), you can use unicode characters. The code that maps names to
> > > > > >legacy non-unicode interfaces then needs to do suitable translations
> > > > > >to fit whatever constraint there is.
> > > > >
> > > > > Not if the data definition restricts the values to an ASCII
> > > > > subset, as has been proposed.  What's in the draft at the
> > > > > moment will bring its own interoperability problems, but
> > > > > at least it's a baby step forward.
> > > >
> > > > So it seems we have a chance to fix this now.  But I need to
> > > > understand what exactly you and/or Juergen propose.  Preferrably
> > > > concrete text.  I *think* that the proposal is something like this:
> > > >
> > > >    o  An implementation MUST allow any legal "string" (YANG string).
> > > 
> > > There are good reasons to restrict formatting and control characters -
> > > I'll assume YANG strings do this already.  If not, that's another long
> > > discussion.
> > > 
> > > >    o  An implementation that maps this value to the corresponding MIB
> > > >       object, which has size and character set limitations, MUST use
> > > >       some mechanism out of the scope for this document to ensure that
> > > >       the MIB object syntax is still valid.
> > > 
> > > Yes this seems reasonable.
> > > 
> > > But it doesn't cover a "round trip".  If the value is modified via the MIB
> > > interface to include what looks like the implementation-specific encoding
> > > into ASCII of a non-ASCII Unicode code point, does retrieving that value
> > > via the Netconf interface get the Unicode code point or the
> > implementation-
> > > specific ASCII encoding of it?  If it does (and I think it should) then
> > there
> > > needs to be some though put into what happens when the code point
> > > encoded using ASCII would, if converted to Unicode, be illegal (for
> > > whatever reason) in the YANG string.  It's probably best to keep the
> > > SNMP instrumentation ignorant of all this, so code in the Netconf side
> > > would need determine whether any of the ASCII "escape sequences"
> > > would produce forbidden code points, and, in such cases, *not* evaluate
> > > those sequences and just pass them through unevaluated.
> > > 
> > > 
> > > > Also, just to make sure, we are talking about:
> > > >
> > > >    system/location        -- sysLocation
> > > >    system/contact         -- sysContact
> > > >    interface/description  -- ifAlias
> > > 
> > > Perhaps also sysDescr (even though read-only, my comment above seems
> > > applicable,
> > > particularly since on at least some systems this comes from a static
> > > configuration
> > > file, and would be useful to support local language in some minimal way.)
> > > 
> > > sysName (think IDN) might also be worth thinking about.  There was a long
> > > debate
> > > about this a while back; I don't know what current thinking is.
> > > 
> > > Randy
> > > 
> > > _______________________________________________
> > > 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
> 
> -- 
> 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  Sun Dec 15 13:58:09 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD811AE1EC for ; Sun, 15 Dec 2013 13:58:09 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TXOZGqt1C47 for ; Sun, 15 Dec 2013 13:58:08 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 094DF1AE1EA for ; Sun, 15 Dec 2013 13:58:08 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 3494C240C0F8 for ; Sun, 15 Dec 2013 22:58:07 +0100 (CET)
Date: Sun, 15 Dec 2013 22:58:06 +0100 (CET)
Message-Id: <20131215.225806.136583521.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Dec 2013 21:58:09 -0000

Hi,

I am starting a new thread for this issue.  We need to resolve this
pretty soon.

We have a couple of YANG leafs that the current documents (interface
and system) specify that an implementation MAY map to corresponding
SMIv2 objects.  The YANG leafs allow XML 1.0 characters (unicode w/
exceptions), and have no hard length limits, whereas the SMIv2 objects
are DisplayStrings - nvt-ascii of size max 255.

The current documents say that if an implementation map the YANG leaf
to the SMIv2 object, it MUST restrict the YANG values to match the
SMIv2 restrictions.

One (theoretical?) problem that is not handled in the documents is
that some C0 control codes are valid in DisplayStrings but not valid
in a YANG string (e.g. BEL and VT).

The mappings are:

   /interfaces/interface/description - ifAlias
   /interfaces-state/interface/name  - ifName
   /system/contact                   - sysContact
   /system/location                  - sysLocation

Note that the interfaces document is in IETF Last Call.

Here are some options:

  1.  Do nothing; keep current text.

      NOTE: not clear how we handle DisplayString characters
      that are not legal YANG string characters.

  2.  Say that implementations MAY map, but that they need to do some
      vendor-specific translation procedure to handle the difference
      in character sets and lengths.

  3.  Like 2 + add an additional config false leaf in the YANG model
      to inform the YANG client about the resulting value.  (NOTE:
      this value is of course already available over SNMP).

  4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
      specify that there is a mapping between them.

Comments?

My preference is 4, followed by 2.


/martin

      

From randy_presuhn@mindspring.com  Sun Dec 15 15:51:50 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4C91AE22C for ; Sun, 15 Dec 2013 15:51:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level: 
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSBLwcR-pB8o for ; Sun, 15 Dec 2013 15:51:47 -0800 (PST)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF321AE226 for ; Sun, 15 Dec 2013 15:51:46 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HgKObq7meR4MvjHdBnnUb4Fvdrt8g9jqa2LhOPLYLCbg6OuTkT6TMkl+lhiN34Qv; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [76.254.54.154] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VsLTN-0002fi-4M for netmod@ietf.org; Sun, 15 Dec 2013 18:51:45 -0500
Message-ID: <005001cef9f0$da5390e0$6b01a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
References: <20131215.225806.136583521.mbj@tail-f.com>
Date: Sun, 15 Dec 2013 15:53:27 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01CEF9AD.CB887820"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb23185c81d763d16ab71cc4c88c22bee5350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 76.254.54.154
Subject: Re: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Dec 2013 23:51:50 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_004D_01CEF9AD.CB887820
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi -

To Martin's helpful summary I'd add this chart that I hope makes
it a little easier to see the differences between the two SMI
textual conventions (relevant to the system management and
SNMP configuration documents) and the RFC 6020 string type,


Codepoints    | SnmpAdminString    | DisplayString    | RFC 6020 string
--------------+--------------------+------------------+-----------------
0x00 (NUL)    | allowed, but       | specific usage(s)| illegal
              | should be avoided  | described        |
--------------+--------------------+------------------+-----------------
0x01-0x06     | allowed, but       | allowed, but no  | illegal
              | should be avoided  | standard meaning |
--------------+--------------------+------------------+-----------------
0x07-0x09     | allowed, but       | specific usage(s)| illegal
(BEL, BS, HT) | should be avoided  | described        |
--------------+--------------------+------------------+-----------------
0x0A (LF)     | recommended usage  | recommended usage| allowed
              | as part of CR LF   | as part of CR LF |
--------------+--------------------+------------------+-----------------
0x0B (VT)     | allowed, but       | specific usage(s)| illegal
0x0C (FF)     | should be avoided  | described        |
--------------+--------------------+------------------+-----------------
0x0D (CR)     | recommended usage  | allowed in the   | allowed
              | as part of CR LF   | sequence CR LF or|
              |                    | CR NUL. Any other|
              |                    | CR xx sequence   |        =20
              |                    | is illegal,      |
              |                    | including as last|
              |                    | character in a   |
              |                    | string           |
--------------+--------------------+------------------+-----------------
0x0E..0x1F    | allowed, but       | allowed, but no  | illegal
(SO-US)       | should be avoided  | standard meaning |
--------------+--------------------+------------------+-----------------
0x20-0x7F     | allowed            | allowed          | allowed
--------------+--------------------+------------------+-----------------
0x80-0x9f     | allowed, but       | illegal          | allowed
              | should be avoided  |                  |
--------------+--------------------+------------------+-----------------
0xa0-0xff     | allowed            | illegal          | allowed
--------------+--------------------+------------------+-----------------
0x100-0xD7FF  | allowed            | illegal / really | allowed
              |                    | impossible       |
--------------+--------------------+------------------+-----------------
0xD800-0xDFF  | allowed            | illegal / really | illegal
              |                    | impossible       |
--------------+--------------------+------------------+-----------------
0xE000-0xFFFD | allowed            | illegal / really | allowed
              |                    | impossible       |
--------------+--------------------+------------------+-----------------
0xFFFE-0xFFFF | allowed            | illegal / really | illegal
              |                    | impossible       |
--------------+--------------------+------------------+-----------------
0x10000-      | allowed            | illegal / really | allowed
0x10FFFF      |                    | impossible       |
--------------+--------------------+------------------+-----------------
0x110000-     | allowed by RFC 3411| illegal / really | illegal
0x7fffffff    | RFC 3629 later     | impossible       |
              | restricted UTF-8 to|                  |
              | exclude this range |                  |
--------------+--------------------+------------------+-----------------

Randy
------=_NextPart_000_004D_01CEF9AD.CB887820
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hi -


 


To Martin's helpful summary I'd =
add this=20
chart that I hope makes


it a little easier to see the =
differences=20
between the two SMI


textual conventions (relevant =
to the system=20
management and


SNMP configuration documents) =
and the RFC=20
6020 string type,



 


Codepoints    |=20
SnmpAdminString    | DisplayString    | =
RFC 6020=20
string


--------------+--------------------+------------------+---------=
--------


0x00=20
(NUL)    | allowed,=20
but       | specific usage(s)|=20
illegal


          &nbs=
p;   | should=20
be avoided  | described     =20
  |


--------------+--------------------+------------------+---------=
--------


0x01-0x06     |=20
allowed, but       | allowed,=20
but no  | illegal


          &nbs=
p;   | should=20
be avoided  | standard meaning |


--------------+--------------------+------------------+---------=
--------


0x07-0x09     | allowed, but&=
nbsp;      |=20
specific usage(s)| illegal




(BEL, BS, HT) | should be =
avoided=20
 | described      =
  |


--------------+--------------------+------------------+---------=
--------


0x0A =
(LF)     |=20
recommended usage  | recommended usage| allowed


          &nbs=
p;  =20
| as part of CR LF   | as part of CR LF |


--------------+--------------------+------------------+---------=
--------


0x0B=20
(VT)     | allowed,=20
but       | specific usage(s)|=20
illegal


0x0C =
(FF)     | should=20
be avoided  | described       =20
|


--------------+--------------------+------------------+---------=
--------


0x0D =
(CR)     |=20
recommended usage  | allowed in the   | =
allowed


          &nbs=
p;   |=20
as part of CR LF   | sequence CR LF or|


          &nbs=
p;   |        &nbs=
p;           |=20
CR NUL. Any other|


          &nbs=
p;   |        &nbs=
p;          =20
| CR xx sequence  =20
|         


          &nbs=
p;  =20
|            =
       =20
| is illegal,      |


          &nbs=
p;  =20
|            =
        |=20
including as last|


          &nbs=
p;   |        &nbs=
p;          =20
| character in a   |


          &nbs=
p;   |        &nbs=
p;           |=20
string          =20
|


--------------+--------------------+------------------+---------=
--------


0x0E..0x1F    | =
allowed,=20
but       | allowed, but no  |=20
illegal


(SO-US)      =20
| should be avoided  | standard meaning |


--------------+--------------------+------------------+---------=
--------


0x20-0x7F     | allowed=20
           | =
allowed=20
         | =
allowed


--------------+--------------------+------------------+---------=
--------


0x80-0x9f     |=20
allowed, but       |=20
illegal          |=20
allowed


          &nbs=
p;  =20
| should be avoided =20
|            =
      |


--------------+--------------------+------------------+---------=
--------


0xa0-0xff     |=20
allowed           =
 |=20
illegal          |=20
allowed


--------------+--------------------+------------------+---------=
--------


0x100-0xD7FF  |=20
allowed           =
 |=20
illegal / really | allowed


          &nbs=
p;   |        &nbs=
p;          =20
|=20
impossible       |


--------------+--------------------+------------------+---------=
--------


0xD800-0xDFF  |=20
allowed           =
 |=20
illegal / really | illegal


          &nbs=
p;   |        &nbs=
p;           |=20
impossible       |


--------------+--------------------+------------------+---------=
--------


0xE000-0xFFFD |=20
allowed           =
 |=20
illegal / really | allowed




          &nbs=
p;   |        &nbs=
p;           |=20
impossible       |


--------------+--------------------+------------------+---------=
--------


0xFFFE-0xFFFF |=20
allowed           =
 |=20
illegal / really | illegal




          &nbs=
p;   |        &nbs=
p;           |=20
impossible       |


--------------+--------------------+------------------+---------=
--------


0x10000-      |=20
allowed           =
 |=20
illegal / really | allowed


0x10FFFF      |    =
;            =
    |=20
impossible       |




--------------+--------------------+------------------+---------=
--------


0x110000-     | allowed by RFC 3411| illegal / =
really |=20
illegal


0x7fffffff    | RFC=20
3629 later     |=20
impossible       |


          &nbs=
p;   |=20
restricted=20
UTF-8 to|          =
;        |


          &nbs=
p;   |=20
exclude this range=20
|            =
     =20
|


--------------+--------------------+------------------+---------=
--------


 


Randy


------=_NextPart_000_004D_01CEF9AD.CB887820--



From randy_presuhn@mindspring.com  Sun Dec 15 15:58:23 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F931AE23D for ; Sun, 15 Dec 2013 15:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9_oC39GndNR for ; Sun, 15 Dec 2013 15:58:21 -0800 (PST)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id CE9631AE24A for ; Sun, 15 Dec 2013 15:58:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=d3wlXyBhf/JF21t1VWODzJdtI/aiQ6K+oR3W3gOHHnxBZj/ruU+EaZ59nJkB/1wJ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [76.254.54.154] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VsLZj-0000bz-W9 for netmod@ietf.org; Sun, 15 Dec 2013 18:58:20 -0500
Message-ID: <005501cef9f1$c59da2c0$6b01a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
References: <20131215.225806.136583521.mbj@tail-f.com>
Date: Sun, 15 Dec 2013 16:00:02 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb993b65a13eea55a555a4ae54657ff1e3350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 76.254.54.154
Subject: Re: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 15 Dec 2013 23:58:23 -0000

Hi -

> From: "Martin Bjorklund" 
> To: 
> Sent: Sunday, December 15, 2013 1:58 PM
> Subject: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
...
> Here are some options:
> 
>   1.  Do nothing; keep current text.
> 
>       NOTE: not clear how we handle DisplayString characters
>       that are not legal YANG string characters.
> 
>   2.  Say that implementations MAY map, but that they need to do some
>       vendor-specific translation procedure to handle the difference
>       in character sets and lengths.
> 
>   3.  Like 2 + add an additional config false leaf in the YANG model
>       to inform the YANG client about the resulting value.  (NOTE:
>       this value is of course already available over SNMP).
> 
>   4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
>       specify that there is a mapping between them.
> 
> Comments?

I'd add an option:

5) Implementations MUST map in both directions using a *standardized*
mapping, with provision for pathological cases due to length constraints
and the inherent limitations of superimposing escape schemes onto existing
methods.

Randy


From mbj@tail-f.com  Sun Dec 15 23:01:58 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539D21AE2BA for ; Sun, 15 Dec 2013 23:01:58 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQW1ww7SO9Lo for ; Sun, 15 Dec 2013 23:01:55 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 534F11ADEA1 for ; Sun, 15 Dec 2013 23:01:55 -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 C6FA7240C109; Mon, 16 Dec 2013 08:01:48 +0100 (CET)
Date: Mon, 16 Dec 2013 08:01:48 +0100 (CET)
Message-Id: <20131216.080148.184897316515837009.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund 
In-Reply-To: <005501cef9f1$c59da2c0$6b01a8c0@oemcomputer>
References: <20131215.225806.136583521.mbj@tail-f.com> <005501cef9f1$c59da2c0$6b01a8c0@oemcomputer>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 07:01:58 -0000

Randy,

Do you have a preference?


/martin


"Randy Presuhn"  wrote:
> Hi -
> 
> > From: "Martin Bjorklund" 
> > To: 
> > Sent: Sunday, December 15, 2013 1:58 PM
> > Subject: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
> ...
> > Here are some options:
> > 
> >   1.  Do nothing; keep current text.
> > 
> >       NOTE: not clear how we handle DisplayString characters
> >       that are not legal YANG string characters.
> > 
> >   2.  Say that implementations MAY map, but that they need to do some
> >       vendor-specific translation procedure to handle the difference
> >       in character sets and lengths.
> > 
> >   3.  Like 2 + add an additional config false leaf in the YANG model
> >       to inform the YANG client about the resulting value.  (NOTE:
> >       this value is of course already available over SNMP).
> > 
> >   4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
> >       specify that there is a mapping between them.
> > 
> > Comments?
> 
> I'd add an option:
> 
> 5) Implementations MUST map in both directions using a *standardized*
> mapping, with provision for pathological cases due to length constraints
> and the inherent limitations of superimposing escape schemes onto existing
> methods.
> 
> Randy
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

From j.schoenwaelder@jacobs-university.de  Mon Dec 16 01:42:03 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C58B1AD2EC for ; Mon, 16 Dec 2013 01:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.788
X-Spam-Level: 
X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jv65DtjOcKz for ; Mon, 16 Dec 2013 01:42: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 D9B231A1F5F for ; Mon, 16 Dec 2013 01:42:00 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C988E2018D; Mon, 16 Dec 2013 10:41:59 +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 uOSbmOluSiK8; Mon, 16 Dec 2013 10:41:59 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 567BF20186; Mon, 16 Dec 2013 10:41:59 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 5F91E2A028E6; Mon, 16 Dec 2013 10:41:54 +0100 (CET)
Date: Mon, 16 Dec 2013 10:41:54 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20131216094153.GA92296@elstar.local>
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References:  <20131213.121509.688716145908885068.mbj@tail-f.com>  <20131213.135550.900710914311144743.mbj@tail-f.com> <67AE73D5-6415-4B05-8387-76120665A1C2@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <67AE73D5-6415-4B05-8387-76120665A1C2@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Dec 2013 09:42:03 -0000

On Fri, Dec 13, 2013 at 02:19:14PM +0100, Ladislav Lhotka wrote:
> 
> > Aha, so this is an alternative where an implementation MAY map, and if
> > it maps, it MUST (?) use some vendor-specific translation, and it MUST
> > record this in the read-only variable mib-sys-location.
> 
> Yup.
> 
> > 
> > If this is what you meant, I still don't think the read-only variable
> > is necessary.  The value is available over SNMP.
> 
> Right, but performing the mapping *and* recording the result is probably the maximum of what a NETCONF server can be expected to do, unless we restrict the location value to a DisplayString. Of course, the mib-sys-location leaf can be only optional, either feature-dependent or defined in a separate module. I am assuming it can be useful to be able to learn the mapped value without going to SNMP.
> 

RFC 6643 gives you already read-only access to MIB objects.

/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  Mon Dec 16 02:00:58 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A95B1AD8F9 for ; Mon, 16 Dec 2013 02:00:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.788
X-Spam-Level: 
X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2eMBdLhYZ72 for ; Mon, 16 Dec 2013 02:00:54 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 401121AC3FA for ; Mon, 16 Dec 2013 02:00:54 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F162201AD; Mon, 16 Dec 2013 11:00:53 +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 ShAGD7pHGRIx; Mon, 16 Dec 2013 11:00:53 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA293201AC; Mon, 16 Dec 2013 11:00:52 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 8388F2A02A5E; Mon, 16 Dec 2013 11:00:48 +0100 (CET)
Date: Mon, 16 Dec 2013 11:00:48 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20131216100048.GB92296@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20131215.225806.136583521.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131215.225806.136583521.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Dec 2013 10:00:58 -0000

On Sun, Dec 15, 2013 at 10:58:06PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> I am starting a new thread for this issue.  We need to resolve this
> pretty soon.
> 
> We have a couple of YANG leafs that the current documents (interface
> and system) specify that an implementation MAY map to corresponding
> SMIv2 objects.  The YANG leafs allow XML 1.0 characters (unicode w/
> exceptions), and have no hard length limits, whereas the SMIv2 objects
> are DisplayStrings - nvt-ascii of size max 255.
> 
> The current documents say that if an implementation map the YANG leaf
> to the SMIv2 object, it MUST restrict the YANG values to match the
> SMIv2 restrictions.
> 
> One (theoretical?) problem that is not handled in the documents is
> that some C0 control codes are valid in DisplayStrings but not valid
> in a YANG string (e.g. BEL and VT).
> 
> The mappings are:
> 
>    /interfaces/interface/description - ifAlias
>    /interfaces-state/interface/name  - ifName
>    /system/contact                   - sysContact
>    /system/location                  - sysLocation
> 
> Note that the interfaces document is in IETF Last Call.
> 
> Here are some options:
> 
>   1.  Do nothing; keep current text.
> 
>       NOTE: not clear how we handle DisplayString characters
>       that are not legal YANG string characters.
> 
>   2.  Say that implementations MAY map, but that they need to do some
>       vendor-specific translation procedure to handle the difference
>       in character sets and lengths.
> 
>   3.  Like 2 + add an additional config false leaf in the YANG model
>       to inform the YANG client about the resulting value.  (NOTE:
>       this value is of course already available over SNMP).
> 
>   4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
>       specify that there is a mapping between them.
> 
> Comments?
> 
> My preference is 4, followed by 2.

Speaking as technical contributor, my preference is 2. I do not see
how 4 would work (if I change the name of an interface, I assue this
name change will eventually become visible via other interfaces such
as SNMP - hence 4 practically seems to lead to 2 anyway, no?).

/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  Mon Dec 16 02:15:16 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC7B1ADD9A for ; Mon, 16 Dec 2013 02:15:16 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTsyBUXB8sYD for ; Mon, 16 Dec 2013 02:15:14 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id F06931AD73F for ; Mon, 16 Dec 2013 02:15:13 -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 6A4C837C049; Mon, 16 Dec 2013 11:15:12 +0100 (CET)
Date: Mon, 16 Dec 2013 11:15:12 +0100 (CET)
Message-Id: <20131216.111512.1890561833469404338.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20131216100048.GB92296@elstar.local>
References: <20131215.225806.136583521.mbj@tail-f.com> <20131216100048.GB92296@elstar.local>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 10:15:16 -0000

Juergen Schoenwaelder  wrote:
> On Sun, Dec 15, 2013 at 10:58:06PM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > I am starting a new thread for this issue.  We need to resolve this
> > pretty soon.
> > 
> > We have a couple of YANG leafs that the current documents (interface
> > and system) specify that an implementation MAY map to corresponding
> > SMIv2 objects.  The YANG leafs allow XML 1.0 characters (unicode w/
> > exceptions), and have no hard length limits, whereas the SMIv2 objects
> > are DisplayStrings - nvt-ascii of size max 255.
> > 
> > The current documents say that if an implementation map the YANG leaf
> > to the SMIv2 object, it MUST restrict the YANG values to match the
> > SMIv2 restrictions.
> > 
> > One (theoretical?) problem that is not handled in the documents is
> > that some C0 control codes are valid in DisplayStrings but not valid
> > in a YANG string (e.g. BEL and VT).
> > 
> > The mappings are:
> > 
> >    /interfaces/interface/description - ifAlias
> >    /interfaces-state/interface/name  - ifName
> >    /system/contact                   - sysContact
> >    /system/location                  - sysLocation
> > 
> > Note that the interfaces document is in IETF Last Call.
> > 
> > Here are some options:
> > 
> >   1.  Do nothing; keep current text.
> > 
> >       NOTE: not clear how we handle DisplayString characters
> >       that are not legal YANG string characters.
> > 
> >   2.  Say that implementations MAY map, but that they need to do some
> >       vendor-specific translation procedure to handle the difference
> >       in character sets and lengths.
> > 
> >   3.  Like 2 + add an additional config false leaf in the YANG model
> >       to inform the YANG client about the resulting value.  (NOTE:
> >       this value is of course already available over SNMP).
> > 
> >   4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
> >       specify that there is a mapping between them.
> > 
> > Comments?
> > 
> > My preference is 4, followed by 2.
> 
> Speaking as technical contributor, my preference is 2. I do not see
> how 4 would work (if I change the name of an interface, I assue this
> name change will eventually become visible via other interfaces such
> as SNMP - hence 4 practically seems to lead to 2 anyway, no?).

This is a special case for ifName.  The SNMP object says that this is
the name used at the "console", and assumes that the "console" can
only have ascii.  So what happens when the "console" can do unicode?
As you pointed out the device will do whatever it does, and the SNMP
agent will have to deal with it somehow.  The addition of the YANG
module doesn't change this situation.

Note that arbitrary unicode names are applicable to user-controlled
interfaces only.  system-controlled interfaces will be called whatever
name the system assigns to them.

Did you mean that 4 will be a problem for contact, location and
interface/description as well?


/martin

From j.schoenwaelder@jacobs-university.de  Mon Dec 16 02:19:15 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF001AE101 for ; Mon, 16 Dec 2013 02:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.788
X-Spam-Level: 
X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ekw_7J-kkVCP for ; Mon, 16 Dec 2013 02:19: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 AB5201AE0B4 for ; Mon, 16 Dec 2013 02:19:11 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9D63200B7; Mon, 16 Dec 2013 11:19:10 +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 AyZpLrBVms7o; Mon, 16 Dec 2013 11:19: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 7518E200AC; Mon, 16 Dec 2013 11:19:10 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 352722A02BF5; Mon, 16 Dec 2013 11:19:06 +0100 (CET)
Date: Mon, 16 Dec 2013 11:19:06 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20131216101906.GA92492@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20131215.225806.136583521.mbj@tail-f.com> <20131216100048.GB92296@elstar.local> <20131216.111512.1890561833469404338.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131216.111512.1890561833469404338.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Dec 2013 10:19:15 -0000

On Mon, Dec 16, 2013 at 11:15:12AM +0100, Martin Bjorklund wrote:
> > 
> > Speaking as technical contributor, my preference is 2. I do not see
> > how 4 would work (if I change the name of an interface, I assue this
> > name change will eventually become visible via other interfaces such
> > as SNMP - hence 4 practically seems to lead to 2 anyway, no?).
> 
> This is a special case for ifName.  The SNMP object says that this is
> the name used at the "console", and assumes that the "console" can
> only have ascii.  So what happens when the "console" can do unicode?
> As you pointed out the device will do whatever it does, and the SNMP
> agent will have to deal with it somehow.  The addition of the YANG
> module doesn't change this situation.
> 
> Note that arbitrary unicode names are applicable to user-controlled
> interfaces only.  system-controlled interfaces will be called whatever
> name the system assigns to them.
> 
> Did you mean that 4 will be a problem for contact, location and
> interface/description as well?

For contact and location, you could treat them different but I doubt
it increases user experience by treating them different at the end of
the day. As a customer, I want to configure a contact only once and
not multiple times and hence even then, I suspect that implementations
will find reasons to actually do 2.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From lhotka@nic.cz  Mon Dec 16 07:04:01 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE76C1AE014 for ; Mon, 16 Dec 2013 07:04:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level: 
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nnQjhWcvPpN for ; Mon, 16 Dec 2013 07:03:59 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id AF6481AE2D2 for ; Mon, 16 Dec 2013 07:03:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 6276254027A for ; Mon, 16 Dec 2013 16:03:56 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtE2e01vyjaR for ; Mon, 16 Dec 2013 16:03:48 +0100 (CET)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 356A1540113 for ; Mon, 16 Dec 2013 16:03:44 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: <20131215.220338.304654767.mbj@tail-f.com>
References: <20131203151610.GB71692@elstar.local> <20131215.220338.304654767.mbj@tail-f.com>
User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0)
Mail-Followup-To: netmod@ietf.org
Date: Mon, 16 Dec 2013 16:03:43 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [netmod] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 15:04:01 -0000

Hi Martin,

thank you for the review.

Martin Bjorklund  writes:

> Hi,
>
> I have reviewed this document, and here are my comments:
>
>
> I plan to implement this data model for a non-router (host).  In the

Good. Do you plan to generate some platform-specific init scripts, or use another mechanism for getting the configuration into the system guts?  

> introduction and objectives section it is mentioned that this data
> model is suitable for such a device.  I think the document should
> include a section that discusses what such an implementation should
> do.  For example, implement the "static" and "direct"

I can add this, perhaps as an appendix, although it won't be as straightforward as you might think, see below.  

> pseudo-protocols, allow exactly one user-controlled routing instance
> (?), do not implement "multiple-ribs".  What does router-id mean for a

It depends on where you draw the line between a host and a router. For example, in Linux you can configure user-defined routing tables straight in the kernel.

router-id is only useful for (some) routing protocols. On the other hand, configuring it on a host is OK, it will only have no effect. 
 
> host?  Does a host have to implement the configuration tree for ribs?

It depends, see above, but probably only when implementing "multiple-ribs".

>
> -----------
>
> In v{4,6}ur, the term "gateway" is used.  Should this be "next-hop"
> instead?
>
> -----------
>
> In the document, term "netxhop" is used.  Should this be "next hop"
> (in text) and "next-hop" (in data models).
>
> -----------

We have "leaf gateway" and "list nexhop" appearing in two different cases of the same choice ("nexthop-options"), so due to YANG rules they cannot have the same name. In my view, the term "gateway" is acceptable for this purpose, it only should be also mentioned in the text of the document.

Or do you have another proposal for modelling that choice? 
 
>
> 5.1
>
>    A routing instance together with its operational status is
>    represented as an entry of the list "/routing-state/
>    routing-instance", and identified by a unique numeric identifier.
>    Configuration of that router instance appears as entry of the list
>    "/routing/routing-instance" whose key is a routing instance name
>    selected by the client.
>
> But there is no numeric identifier anymore.

OK, this has to be updated.

>
> And: s/operational status/operational state/

OK, although I consider "status" and "state" to be synonyms.


>
> -----------
>
> Since the /routing-state/routing-instance list has a name, and the
> name is the key, why does it also have an "id", and why is the "id"
> used in references to the routing-instance?  When I invoke the

It was a specific request from I2RS to have numeric entry identifiers for the lists they are interested in, mainly because these IDs will be sent back and forth in their protocol data and they strongly prefer fixed-size integers to free-form strings.

> "active-route" operation, I have to first figure out the "id" of the

Either way, you have to figure out the name or id, and the number seems safer than an arbitrary-length string in terms of type validation.

> routing-instance, and then use this id.  It seems simpler to always
> use the name.   Also, the "id" is optional, which makes it unsuitable
> to be used as an identifier.

They should be mandatory in any case, that's a mistake. As you know, I intended to have the numeric ids in the role of opstate list keys.

>
> The same comment applies to /routing-state/ribs/rib.
>
> Also, for the lists that do need an "id" (route, nexthop), the id leaf
> needs to be mandatory.

Yes.

>
> -----------
>
> In 5.4.1:
>
>    Every routing instance MUST implement exactly one instance of the
>    "direct" pseudo-protocol type.  The name of this instance MUST also
>    be "direct".
>
> Why does this name have to be "direct"?  I think this should be
> removed or explained, b/c now if seems arbitrary.

Yes, now that "source-protocol" contains the protocol type rather than protocol instance name, the name is not important. I will remove the last sentence.

>
> ------------
>
> Editorial nit:  your yin2yang script adds (or doesn't strip) empty
> lines in some cases:
>
>        description
>          "Return the current number of routes in a RIB.
>
>           If the RIB with 'id' equal to 'rib-id' doesn't exist, then
>           this operation SHALL fail with error-tag 'data-missing' and
>           error-app-tag 'rib-not-found'.
>          ";
>

We already talked privately about the closing quote and semicolon, and I changed the stylesheet so that they will be placed immediately after the text.

But if you mean the empty line inside the description, then I think it is important there.

> -----------
>
> Editorial: s/RIBS/RIBs/

OK, that's my "systematic" typo.

Thanks, Lada

>
>
>
> /martin
>
>
>
> Juergen Schoenwaelder  wrote:
>> Hi,
>> 
>> I hereby like to start a WG last call for the document "A YANG Data
>> Model for Routing Management":
>> 
>>   http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-12
>> 
>> Please indicate your support by Friday December 20th. We are not only
>> interested in receiving defect reports, we are equally interested in
>> statements of the form:
>> 
>>   "I have reviewed I-D XYZ and I found no issues"
>>   "I have implemented the data model in I-D XYZ"
>>   "I am implementing the data model in I-D XYZ"
>>   "I am considering to implement the data model in I-D XYZ"
>> 
>> This is the 1st WG last call on this document.
>> 
>> /js
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

From lhotka@nic.cz  Mon Dec 16 07:33:44 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466D71AE339 for ; Mon, 16 Dec 2013 07:33:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level: 
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZyoAL8CcxO3 for ; Mon, 16 Dec 2013 07:33:42 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD851ADF30 for ; Mon, 16 Dec 2013 07:33:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 557E954027A; Mon, 16 Dec 2013 16:33:41 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yDKvO8rjftY; Mon, 16 Dec 2013 16:33:37 +0100 (CET)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 7EB70540113; Mon, 16 Dec 2013 16:33:37 +0100 (CET)
From: Ladislav Lhotka 
To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de
In-Reply-To: <20131216.111512.1890561833469404338.mbj@tail-f.com>
References: <20131215.225806.136583521.mbj@tail-f.com> <20131216100048.GB92296@elstar.local> <20131216.111512.1890561833469404338.mbj@tail-f.com>
User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0)
Mail-Followup-To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de, netmod@ietf.org
Date: Mon, 16 Dec 2013 16:33:36 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: netmod@ietf.org
Subject: Re: [netmod] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 15:33:44 -0000

Martin Bjorklund  writes:

> Juergen Schoenwaelder  wrote:
>> On Sun, Dec 15, 2013 at 10:58:06PM +0100, Martin Bjorklund wrote:
>> > Hi,
>> > 
>> > I am starting a new thread for this issue.  We need to resolve this
>> > pretty soon.
>> > 
>> > We have a couple of YANG leafs that the current documents (interface
>> > and system) specify that an implementation MAY map to corresponding
>> > SMIv2 objects.  The YANG leafs allow XML 1.0 characters (unicode w/
>> > exceptions), and have no hard length limits, whereas the SMIv2 objects
>> > are DisplayStrings - nvt-ascii of size max 255.
>> > 
>> > The current documents say that if an implementation map the YANG leaf
>> > to the SMIv2 object, it MUST restrict the YANG values to match the
>> > SMIv2 restrictions.
>> > 
>> > One (theoretical?) problem that is not handled in the documents is
>> > that some C0 control codes are valid in DisplayStrings but not valid
>> > in a YANG string (e.g. BEL and VT).
>> > 
>> > The mappings are:
>> > 
>> >    /interfaces/interface/description - ifAlias
>> >    /interfaces-state/interface/name  - ifName
>> >    /system/contact                   - sysContact
>> >    /system/location                  - sysLocation
>> > 
>> > Note that the interfaces document is in IETF Last Call.
>> > 
>> > Here are some options:
>> > 
>> >   1.  Do nothing; keep current text.
>> > 
>> >       NOTE: not clear how we handle DisplayString characters
>> >       that are not legal YANG string characters.
>> > 
>> >   2.  Say that implementations MAY map, but that they need to do some
>> >       vendor-specific translation procedure to handle the difference
>> >       in character sets and lengths.
>> > 
>> >   3.  Like 2 + add an additional config false leaf in the YANG model
>> >       to inform the YANG client about the resulting value.  (NOTE:
>> >       this value is of course already available over SNMP).
>> > 
>> >   4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
>> >       specify that there is a mapping between them.
>> > 
>> > Comments?
>> > 
>> > My preference is 4, followed by 2.
>> 
>> Speaking as technical contributor, my preference is 2. I do not see
>> how 4 would work (if I change the name of an interface, I assue this
>> name change will eventually become visible via other interfaces such
>> as SNMP - hence 4 practically seems to lead to 2 anyway, no?).
>
> This is a special case for ifName.  The SNMP object says that this is
> the name used at the "console", and assumes that the "console" can
> only have ascii.  So what happens when the "console" can do unicode?
> As you pointed out the device will do whatever it does, and the SNMP
> agent will have to deal with it somehow.  The addition of the YANG
> module doesn't change this situation.

Right, I think we have to make sure that the *system* can use the configured names.

>
> Note that arbitrary unicode names are applicable to user-controlled
> interfaces only.  system-controlled interfaces will be called whatever
> name the system assigns to them.

Hmm... I can assign a juicy unicode name to eth0 in an init script and then from the NETCONF point of view the name is assigned by the system.

Lada

>
> Did you mean that 4 will be a problem for contact, location and
> interface/description as well?
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

From mbj@tail-f.com  Mon Dec 16 08:14:11 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51BE1AE34D for ; Mon, 16 Dec 2013 08:14:11 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nERHNYgMuMwW for ; Mon, 16 Dec 2013 08:14:09 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id A14501AE357 for ; Mon, 16 Dec 2013 08:14:09 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 2F8BD37C04A; Mon, 16 Dec 2013 17:14:08 +0100 (CET)
Date: Mon, 16 Dec 2013 17:14:07 +0100 (CET)
Message-Id: <20131216.171407.410749820.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20131216100048.GB92296@elstar.local> <20131216.111512.1890561833469404338.mbj@tail-f.com> 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 16:14:11 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> > Note that arbitrary unicode names are applicable to user-controlled
> > interfaces only.  system-controlled interfaces will be called whatever
> > name the system assigns to them.
> 
> Hmm... I can assign a juicy unicode name to eth0 in an init script and then
> from the NETCONF point of view the name is assigned by the system.

Yes.  Is this a problem?


/martin

From lhotka@nic.cz  Mon Dec 16 08:18:23 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F021AE338 for ; Mon, 16 Dec 2013 08:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leFCAcbhBRui for ; Mon, 16 Dec 2013 08:18:22 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E1EE81AE053 for ; Mon, 16 Dec 2013 08:18:19 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9BDD014016C; Mon, 16 Dec 2013 17:18:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1387210698; bh=NwN121bO1lwteJQspvnDEeVHkXTcQLGuaR/Gjj+0ZQs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=db3bwOiGLfwMoVMscCg+lhLwwN91TF8lFoyGkMJOBGglKI3Chtv9Hoz5OpV63/4ae eOWrhKyh2YnGR2RNl/LOwRRcxYnSA8Ovhqb7RY79TNKjnvQJdCSQLwtOkMV2Iw2xOU VSBaxEX8GCvPug2IckyqYOM70BrDxjCTTGth2NmY=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ladislav Lhotka 
In-Reply-To: <20131216.171407.410749820.mbj@tail-f.com>
Date: Mon, 16 Dec 2013 17:18:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20131216100048.GB92296@elstar.local> <20131216.111512.1890561833469404338.mbj@tail-f.com>  <20131216.171407.410749820.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= 
X-Mailer: Apple Mail (2.1822)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 16:18:23 -0000

On 16 Dec 2013, at 17:14, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>>> Note that arbitrary unicode names are applicable to user-controlled
>>> interfaces only.  system-controlled interfaces will be called =
whatever
>>> name the system assigns to them.
>>=20
>> Hmm... I can assign a juicy unicode name to eth0 in an init script =
and then
>> from the NETCONF point of view the name is assigned by the system.
>=20
> Yes.  Is this a problem?

Probably not, but it is not true that =93... arbitrary unicode names are =
applicable to user-controlled interfaces only.=94

Lada

>=20
>=20
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From randy_presuhn@mindspring.com  Mon Dec 16 10:00:59 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1931AE300 for ; Mon, 16 Dec 2013 10:00:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2WP6wx3eZx9 for ; Mon, 16 Dec 2013 10:00:56 -0800 (PST)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA8C1AE338 for ; Mon, 16 Dec 2013 10:00:56 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kFvkNluqGFyK4VHXaaOoUMeC/2KNDsc8Mr1vaYfSl+olmHsvuMJIq9BnTrCEMuUc; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.33] (helo=elwamui-darkeyed.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VscTP-0003eO-6J for netmod@ietf.org; Mon, 16 Dec 2013 13:00:55 -0500
Received: from 76.254.54.154 by webmail.earthlink.net with HTTP; Mon, 16 Dec 2013 13:00:54 -0500
Message-ID: <15451657.1387216855147.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net>
Date: Mon, 16 Dec 2013 10:00:54 -0800 (GMT-08:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbd807507359fb1fb4fbb7c680c60aad3a350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.33
Subject: Re: [netmod] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Dec 2013 18:00:59 -0000

Hi -

>From: Martin Bjorklund 
>Sent: Dec 15, 2013 11:01 PM
>To: randy_presuhn@mindspring.com
>Cc: netmod@ietf.org
>Subject: Re: [netmod] mapping to snmp strings
>
>Randy,
>
>Do you have a preference?

Yes. (5) would be my first choice, maximizing interoperability,
though it also has the biggest impact on code.  The pathological
"failure" cases are IMO within the bounds of what would be
acceptable under the principle of least astonishment.

(2) would be a distant second.  It has potentially significant
impact on code without helping interoperability.

(4) would be an even more distant third, and it begs the question
of "why bother".

Take these all with a grain of salt.  I'm no longer in this
line of business, so I have comparatively little stake in
the outcome.

Randy

>
>/martin
>
>
>"Randy Presuhn"  wrote:
>> Hi -
>> 
>> > From: "Martin Bjorklund" 
>> > To: 
>> > Sent: Sunday, December 15, 2013 1:58 PM
>> > Subject: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
>> ...
>> > Here are some options:
>> > 
>> >   1.  Do nothing; keep current text.
>> > 
>> >       NOTE: not clear how we handle DisplayString characters
>> >       that are not legal YANG string characters.
>> > 
>> >   2.  Say that implementations MAY map, but that they need to do some
>> >       vendor-specific translation procedure to handle the difference
>> >       in character sets and lengths.
>> > 
>> >   3.  Like 2 + add an additional config false leaf in the YANG model
>> >       to inform the YANG client about the resulting value.  (NOTE:
>> >       this value is of course already available over SNMP).
>> > 
>> >   4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
>> >       specify that there is a mapping between them.
>> > 
>> > Comments?
>> 
>> I'd add an option:
>> 
>> 5) Implementations MUST map in both directions using a *standardized*
>> mapping, with provision for pathological cases due to length constraints
>> and the inherent limitations of superimposing escape schemes onto existing
>> methods.
>> 
>> Randy
>> 
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 


From lhotka@nic.cz  Mon Dec 16 23:38:31 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136A61AE0EC for ; Mon, 16 Dec 2013 23:38:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level: 
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NSKbAxtMX5s for ; Mon, 16 Dec 2013 23:38:29 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 305861AE0F1 for ; Mon, 16 Dec 2013 23:38:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id AE4F254039A for ; Tue, 17 Dec 2013 08:38:26 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAmLQx1VKYyp for ; Tue, 17 Dec 2013 08:38:21 +0100 (CET)
Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9D7E0540230 for ; Tue, 17 Dec 2013 08:38:17 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: <005501cef9f1$c59da2c0$6b01a8c0@oemcomputer>
References: <20131215.225806.136583521.mbj@tail-f.com> <005501cef9f1$c59da2c0$6b01a8c0@oemcomputer>
User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0)
Mail-Followup-To: netmod@ietf.org
Date: Tue, 17 Dec 2013 08:38:16 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 07:38:31 -0000

Randy Presuhn  writes:

> Hi -
>
>> From: "Martin Bjorklund" 
>> To: 
>> Sent: Sunday, December 15, 2013 1:58 PM
>> Subject: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
> ...
>> Here are some options:
>> 
>>   1.  Do nothing; keep current text.
>> 
>>       NOTE: not clear how we handle DisplayString characters
>>       that are not legal YANG string characters.
>> 
>>   2.  Say that implementations MAY map, but that they need to do some
>>       vendor-specific translation procedure to handle the difference
>>       in character sets and lengths.
>> 
>>   3.  Like 2 + add an additional config false leaf in the YANG model
>>       to inform the YANG client about the resulting value.  (NOTE:
>>       this value is of course already available over SNMP).
>> 
>>   4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
>>       specify that there is a mapping between them.
>> 
>> Comments?
>
> I'd add an option:
>
> 5) Implementations MUST map in both directions using a *standardized*
> mapping, with provision for pathological cases due to length constraints
> and the inherent limitations of superimposing escape schemes onto existing
> methods.

In regard to the current set of documents, I prefer #4. Anything else should be potentially addressed in a separate document. The problem actually appears to be broader than just the system module and just the interaction with SMIv2 objects.

Lada

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

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

From wwwrun@rfc-editor.org  Tue Dec 17 07:31:30 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7615C1AE197; Tue, 17 Dec 2013 07:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU1RdLrR06LD; Tue, 17 Dec 2013 07:31:22 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id B7BCC1AE14F; Tue, 17 Dec 2013 07:31:22 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id B46757FC397; Tue, 17 Dec 2013 07:31:21 -0800 (PST)
To: ladislav@lhotka.name, mbj@tail-f.com
From: RFC Errata System 
Message-Id: <20131217153121.B46757FC397@rfc-editor.org>
Date: Tue, 17 Dec 2013 07:31:21 -0800 (PST)
Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Errata Verified] RFC6020 (3842)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 15:31:30 -0000

The following errata report has been verified 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=3842

--------------------------------------
Status: Verified
Type: Technical

Reported by: Ladislav Lhotka 
Date Reported: 2013-12-13
Verified by: Benoit Claise (IESG)

Section: 9.4.4

Original Text
-------------
It is used to restrict the built-in type "string", or types derived
from "string".

Corrected Text
--------------
It is used to restrict the built-in types "string" and "binary", or
types derived from them.

Notes
-----
The "length" statement can also restrict the "binary" type. See also erratum 3835.

--------------------------------------
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 wwwrun@rfc-editor.org  Tue Dec 17 07:35:10 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C961AE18B; Tue, 17 Dec 2013 07:35:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBTnV7B3rdS7; Tue, 17 Dec 2013 07:35:08 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id C7BAC1AE168; Tue, 17 Dec 2013 07:35:08 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id C716E7FC397; Tue, 17 Dec 2013 07:35:07 -0800 (PST)
To: jiminychris@gmail.com, mbj@tail-f.com
From: RFC Errata System 
Message-Id: <20131217153507.C716E7FC397@rfc-editor.org>
Date: Tue, 17 Dec 2013 07:35:07 -0800 (PST)
Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Errata Rejected] RFC6020 (3833)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 15:35:10 -0000

The following errata report has been rejected 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=3833

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Chris LaBauve 
Date Reported: 2013-12-12
Rejected by: Benoit Claise (IESG)

Section: 12

Original Text
-------------
decimal64-specification = fraction-digits-stmt

Corrected Text
--------------
decimal64-specification = ;; these stmts can appear in any order
                          fraction-digits-stmt stmtsep
                          [range-stmt stmtsep]

Notes
-----
decimal64 types should allow for a range substatement; 9.2.4 states the range statement "is used to restrict integer and decimal built-in types."
 --VERIFIER NOTES-- 
Errata 3290 has already dealt with this issue.

--------------------------------------
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 bclaise@cisco.com  Tue Dec 17 08:53:39 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24401AE04A for ; Tue, 17 Dec 2013 08:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level: 
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubF0su5NFXm9 for ; Tue, 17 Dec 2013 08:53:38 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id C4B721AE02D for ; Tue, 17 Dec 2013 08:53:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2493; q=dns/txt; s=iport; t=1387299217; x=1388508817; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=zRVHgrGeVrx8iqZ0E6+Hh8tU2Y7RoSZFIm2I1R5CS0U=; b=LrG1UgglHc3mouimroHC+sDwGGCkuVXEwGRhXEkm5UANYuQ+CkAKzrHv JP/nis4dNf1naaLqHgTMalC8G0uAkP6YfoA6AwFt2M4fQlJBNM/COBYG6 yIAhW+0rmwUVl8kxMz/XKUbaGH9nMgdk7OGgIqie7zy6nHydLdqwdMlNI k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aj0FAHeAsFKQ/khM/2dsb2JhbABZgwo4uG5PgR8WdIIlAQEBBAEBAS8BBTYKEQsRBAEBChYPCQMCAQIBFSgIBgEMBgIBAReHaQ3JXRMEjjARAVeENgEDmBaGRYtPgW2BPzuBNQ
X-IronPort-AV: E=Sophos;i="4.95,502,1384300800";  d="scan'208";a="1760215"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 17 Dec 2013 16:53:36 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBHGrZ6g030104; Tue, 17 Dec 2013 16:53:35 GMT
Message-ID: <52B0818F.9040005@cisco.com>
Date: Tue, 17 Dec 2013 17:53:35 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Randy Presuhn , netmod@ietf.org
References: <20131215.225806.136583521.mbj@tail-f.com> <005501cef9f1$c59da2c0$6b01a8c0@oemcomputer>
In-Reply-To: <005501cef9f1$c59da2c0$6b01a8c0@oemcomputer>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 16:53:39 -0000

Dear all,

[I read all emails in this thread till now, but selected this email for 
my answer as it contains the 5 proposals]

We should be solving this issue once for all, for the current and future 
YANG modules.
For the ones who not provided feedback yet, it's about time now.

As a contributor, here are my preferences.
- 5 would be ideal. However, we don't have this standardized mapping 
now. We should not delay this work further.
This standardized mapping work could be developed and apply later.
- Next: 2 and 4.
I agree with Jrgen S. that the 2 solutions are linked.
So basically, it means in my mind:
     the YANG leafs and SMIv2 objects are separate objects.
     reason: string internalization
     the following objects may map depending on the characters set selected
         /interfaces/interface/description - ifAlias
         /interfaces-state/interface/name - ifName
         /system/contact - sysContact
         /system/location - sysLocation
    However, mapping rules are outside the scope of this document.

Regards, Benoit
> Hi -
>
>> From: "Martin Bjorklund" 
>> To: 
>> Sent: Sunday, December 15, 2013 1:58 PM
>> Subject: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
> ...
>> Here are some options:
>>
>>    1.  Do nothing; keep current text.
>>
>>        NOTE: not clear how we handle DisplayString characters
>>        that are not legal YANG string characters.
>>
>>    2.  Say that implementations MAY map, but that they need to do some
>>        vendor-specific translation procedure to handle the difference
>>        in character sets and lengths.
>>
>>    3.  Like 2 + add an additional config false leaf in the YANG model
>>        to inform the YANG client about the resulting value.  (NOTE:
>>        this value is of course already available over SNMP).
>>
>>    4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
>>        specify that there is a mapping between them.
>>
>> Comments?
> I'd add an option:
>
> 5) Implementations MUST map in both directions using a *standardized*
> mapping, with provision for pathological cases due to length constraints
> and the inherent limitations of superimposing escape schemes onto existing
> methods.
>
> Randy
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From andy@yumaworks.com  Tue Dec 17 09:00:54 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315CA1AE1BD for ; Tue, 17 Dec 2013 09:00:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ojwRlpb64pX for ; Tue, 17 Dec 2013 09:00:52 -0800 (PST)
Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id CB2141AE1AD for ; Tue, 17 Dec 2013 09:00:51 -0800 (PST)
Received: by mail-qe0-f47.google.com with SMTP id t7so5506166qeb.34 for ; Tue, 17 Dec 2013 09:00:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oj+2Yn7Mn8Kx0xxh+OJx9KS661thkMNJ8cC1XKPb5ts=; b=iTOjRfAOI2ndg8BgnOjQX0XJ/tPv1DpSN4BwzYSEdyqvJJGQ86kdx1BBsAo65HJmIS n+GzGT/0kK6MUVUYjEVyRdo81aVX1ud0OjC7TP0uzprZfnGj+9z258MkcpQGS2wo8kPU yMX/n7weHT1HRhux1Fb4PztLbk7O/Y/Qcy+4VaTL6OPit4nwPVDbWw+ffC1R1Op3VOnU CMftusO+LpQv5g+LHPeg6In2knpYkPAQaro2CNfL3WkfmR6xBvsqo58Mt6gwPujGqccF /52g1DGGYkGSTF9O2xckCq85HkCNCBQ/keAge2kjMjpZLS3BBvOKhrYdqpktGaL/N4OF j4sA==
X-Gm-Message-State: ALoCoQmpfuxu+L3V6qrIU1cHegC6FYcjYIRGqqhI3lUtZ00MlwmwTUSKQ8Fr1Ij8MV7NaD9Pdxx0
MIME-Version: 1.0
X-Received: by 10.49.94.177 with SMTP id dd17mr44841331qeb.14.1387299650313; Tue, 17 Dec 2013 09:00:50 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 17 Dec 2013 09:00:50 -0800 (PST)
In-Reply-To: <52B0818F.9040005@cisco.com>
References: <20131215.225806.136583521.mbj@tail-f.com> <005501cef9f1$c59da2c0$6b01a8c0@oemcomputer> <52B0818F.9040005@cisco.com>
Date: Tue, 17 Dec 2013 09:00:50 -0800
Message-ID: 
From: Andy Bierman 
To: Benoit Claise 
Content-Type: multipart/alternative; boundary=047d7b6731b2daba1304edbdde3f
Cc: Randy Presuhn , "netmod@ietf.org" 
Subject: Re: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 17:00:54 -0000

--047d7b6731b2daba1304edbdde3f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 17, 2013 at 8:53 AM, Benoit Claise  wrote:

> Dear all,
>
> [I read all emails in this thread till now, but selected this email for m=
y
> answer as it contains the 5 proposals]
>
> We should be solving this issue once for all, for the current and future
> YANG modules.
> For the ones who not provided feedback yet, it's about time now.
>
>

Slight variant:

  SHOULD (5); if not implemented then MAY (2)




> As a contributor, here are my preferences.
> - 5 would be ideal. However, we don't have this standardized mapping now.
> We should not delay this work further.
> This standardized mapping work could be developed and apply later.
> - Next: 2 and 4.
> I agree with J=FCrgen S. that the 2 solutions are linked.
> So basically, it means in my mind:
>     the YANG leafs and SMIv2 objects are separate objects.
>     reason: string internalization
>     the following objects may map depending on the characters set selecte=
d
>         /interfaces/interface/description - ifAlias
>         /interfaces-state/interface/name - ifName
>         /system/contact - sysContact
>         /system/location - sysLocation
>    However, mapping rules are outside the scope of this document.
>
> Regards, Benoit
>


Andy


>  Hi -
>>
>>  From: "Martin Bjorklund" 
>>> To: 
>>> Sent: Sunday, December 15, 2013 1:58 PM
>>> Subject: [netmod] mapping to snmp strings [Was: AD review of
>>> draft-ietf-netmod-system-mgmt]
>>>
>> ...
>>
>>> Here are some options:
>>>
>>>    1.  Do nothing; keep current text.
>>>
>>>        NOTE: not clear how we handle DisplayString characters
>>>        that are not legal YANG string characters.
>>>
>>>    2.  Say that implementations MAY map, but that they need to do some
>>>        vendor-specific translation procedure to handle the difference
>>>        in character sets and lengths.
>>>
>>>    3.  Like 2 + add an additional config false leaf in the YANG model
>>>        to inform the YANG client about the resulting value.  (NOTE:
>>>        this value is of course already available over SNMP).
>>>
>>>    4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
>>>        specify that there is a mapping between them.
>>>
>>> Comments?
>>>
>> I'd add an option:
>>
>> 5) Implementations MUST map in both directions using a *standardized*
>> mapping, with provision for pathological cases due to length constraints
>> and the inherent limitations of superimposing escape schemes onto existi=
ng
>> methods.
>>
>> Randy
>>
>> _______________________________________________
>> 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
>

--047d7b6731b2daba1304edbdde3f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Tue, Dec 17, 2013 at 8:53 AM, Benoit Claise &l=
t;bclaise@cisco.com<=
/a>> wrote:


Dear all,



[I read all emails in this thread till now, but selected this email for my =
answer as it contains the 5 proposals]



We should be solving this issue once for all, for the current and future YA=
NG modules.

For the ones who not provided feedback yet, it's about time now.




Slight variant:





As a contributor, here are my preferences.

- 5 would be ideal. However, we don't have this standardized mapping no=
w. We should not delay this work further.

This standardized mapping work could be developed and apply later.

- Next: 2 and 4.

I agree with J=FCrgen S. that the 2 solutions are linked.

So basically, it means in my mind:

=A0 =A0 the YANG leafs and SMIv2 objects are separate objects.

=A0 =A0 reason: string internalization

=A0 =A0 the following objects may map depending on the characters set selec=
ted

=A0 =A0 =A0 =A0 /interfaces/interface/description - ifAlias

=A0 =A0 =A0 =A0 /interfaces-state/interface/name - ifName

=A0 =A0 =A0 =A0 /system/contact - sysContact

=A0 =A0 =A0 =A0 /system/location - sysLocation

=A0 =A0However, mapping rules are outside the scope of this document.



Regards, Benoit


Andy
=A0



Hi -





From: "Martin Bjorklund" <mbj@tail-f.com>

To: <netmod@ietf.or=
g>

Sent: Sunday, December 15, 2013 1:58 PM

Subject: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-net=
mod-system-mgmt]



...



Here are some options:



=A0 =A01. =A0Do nothing; keep current text.



=A0 =A0 =A0 =A0NOTE: not clear how we handle DisplayString characters

=A0 =A0 =A0 =A0that are not legal YANG string characters.



=A0 =A02. =A0Say that implementations MAY map, but that they need to do som=
e

=A0 =A0 =A0 =A0vendor-specific translation procedure to handle the differen=
ce

=A0 =A0 =A0 =A0in character sets and lengths.



=A0 =A03. =A0Like 2 + add an additional config false leaf in the YANG model=


=A0 =A0 =A0 =A0to inform the YANG client about the resulting value. =A0(NOT=
E:

=A0 =A0 =A0 =A0this value is of course already available over SNMP).



=A0 =A04. =A0Make the YANG leafs and SMIv2 objects separate, i.e., do not
=A0 =A0 =A0 =A0specify that there is a mapping between them.



Comments?



I'd add an option:



5) Implementations MUST map in both directions using a *standardized*

mapping, with provision for pathological cases due to length constraints
and the inherent limitations of superimposing escape schemes onto existing<=
br>
methods.



Randy



_______________________________________________

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





--047d7b6731b2daba1304edbdde3f--

From bclaise@cisco.com  Wed Dec 18 09:13:32 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D941ADF10 for ; Wed, 18 Dec 2013 09:13:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level: 
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l73GHaZHb03h for ; Wed, 18 Dec 2013 09:13:31 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFF71ADEBA for ; Wed, 18 Dec 2013 09:13:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=478; q=dns/txt; s=iport; t=1387386810; x=1388596410; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2oSeLIQj72lHPeX6bq5RE/5ngqwCjA58BWllTd4CuvY=; b=T3UzkOZ0kPAO+4K8E5S0GvUQ9NGVfRSF2GR3CDM1hYFpeBu8Um1NQPlI kcDYlzoOkCzSA7bHf1GNWpquJWK7ngtUhrAjwON0Z3fdf9FBHN7Nqe+Du ViC8sj+6ZAou+y0o4+A95ks3d0Cbc4WEjR8u4wGbItTABFuVEcfa4mchf g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAPfWsVKQ/khM/2dsb2JhbABZgwq5dQEJgRsWdIImAQEEOEABECwWDwkDAgECAUUGDQEHAQGIAMpBF48SB4Q2AQOYFoZFi0+DLDs
X-IronPort-AV: E=Sophos;i="4.95,508,1384300800";  d="scan'208";a="1813672"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 18 Dec 2013 17:13:28 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBIHDS03016602; Wed, 18 Dec 2013 17:13:28 GMT
Message-ID: <52B1D7B8.3050006@cisco.com>
Date: Wed, 18 Dec 2013 18:13:28 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: NETMOD Working Group 
References: <52A76055.6040902@bogus.com>
In-Reply-To: <52A76055.6040902@bogus.com>
X-Forwarded-Message-Id: <52A76055.6040902@bogus.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Joel jaeggli 
Subject: [netmod] New chair selection process
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Dec 2013 17:13:32 -0000

Dear all,

As you probably know (from the last IETF meeting) , David Kessens 
decided to step down.
Let me thanks David for his years of service in the NETMOD WG.

If you would like to be considered for the role of NEMOD co-chair, 
please consider doing so soon.
This will complete the list of WG chair candidate that Joel and I 
compiled over time.
I am mindful that there are impending holidays for many participants so 
we'll work around that.

Regards, Benoit



From mbj@tail-f.com  Thu Dec 19 10:36:40 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6761AE005 for ; Thu, 19 Dec 2013 10:36:40 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYMqE1DhgXDy for ; Thu, 19 Dec 2013 10:36:38 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7351AC448 for ; Thu, 19 Dec 2013 10:36:38 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id E032437C068; Thu, 19 Dec 2013 19:36:34 +0100 (CET)
Date: Thu, 19 Dec 2013 19:36:33 +0100 (CET)
Message-Id: <20131219.193633.88151738.mbj@tail-f.com>
To: bclaise@cisco.com
From: Martin Bjorklund 
In-Reply-To: <52B0818F.9040005@cisco.com>
References: <20131215.225806.136583521.mbj@tail-f.com> <005501cef9f1$c59da2c0$6b01a8c0@oemcomputer> <52B0818F.9040005@cisco.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Dec 2013 18:36:40 -0000

Hi,

It seems to me that alternative 2 can be accepted by most people.

Here's a proposal for text to put into system/contact.  The others
would be similar:

    leaf contact {
      type string;
      description
        "The administrator contact information for the system.

         A server implementation MAY map this leaf to the sysContact
         MIB object.  Such an implementation MUST use some mechanism
         to handle the differences in size and characters allowed
         between this leaf and sysContact.  The definition of such
         a mechanism is outside the scope of this document.";
      reference
        "RFC 3418: Management Information Base (MIB) for the
                   Simple Network Management Protocol (SNMP)
                   SNMPv2-MIB.sysContact";
    }


/martin



Benoit Claise  wrote:
> > Hi -
> >
> >> From: "Martin Bjorklund" 
> >> To: 
> >> Sent: Sunday, December 15, 2013 1:58 PM
> >> Subject: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
> > ...
> >> Here are some options:
> >>
> >>    1.  Do nothing; keep current text.
> >>
> >>        NOTE: not clear how we handle DisplayString characters
> >>        that are not legal YANG string characters.
> >>
> >>    2.  Say that implementations MAY map, but that they need to do some
> >>        vendor-specific translation procedure to handle the difference
> >>        in character sets and lengths.
> >>
> >>    3.  Like 2 + add an additional config false leaf in the YANG model
> >>        to inform the YANG client about the resulting value.  (NOTE:
> >>        this value is of course already available over SNMP).
> >>
> >>    4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
> >>        specify that there is a mapping between them.
> >>
> >> Comments?
> > I'd add an option:
> >
> > 5) Implementations MUST map in both directions using a *standardized*
> > mapping, with provision for pathological cases due to length constraints
> > and the inherent limitations of superimposing escape schemes onto existing
> > methods.
> >
> > Randy
> >
> > _______________________________________________
> > 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 randy_presuhn@mindspring.com  Thu Dec 19 17:10:06 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424861AEEED for ; Thu, 19 Dec 2013 17:10:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6kbI-2R_isp for ; Thu, 19 Dec 2013 17:10:03 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id CA4551AEEC8 for ; Thu, 19 Dec 2013 17:10:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=d5Nhx1atGxvKOckjPOGRAjDUckUUcTma97xDwxvZPHIm7T8SQAlLa+0Cfd1S+fG/; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VtobI-0000Z3-VV for netmod@ietf.org; Thu, 19 Dec 2013 20:10:00 -0500
Received: from 76.254.54.154 by webmail.earthlink.net with HTTP; Thu, 19 Dec 2013 20:10:00 -0500
Message-ID: <20464301.1387501800659.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
Date: Thu, 19 Dec 2013 17:10:00 -0800 (GMT-08:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb00c8c495291707cc2792171cc2932d70350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.52
Subject: Re: [netmod] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Dec 2013 01:10:06 -0000

Hi -

>From: Martin Bjorklund 
>Sent: Dec 19, 2013 10:36 AM
>To: bclaise@cisco.com
>Cc: randy_presuhn@mindspring.com, netmod@ietf.org
>Subject: Re: [netmod] mapping to snmp strings
...
>         A server implementation MAY map this leaf to the sysContact
>         MIB object.  Such an implementation MUST use some mechanism
>         to handle the differences in size and characters allowed
>         between this leaf and sysContact.  The definition of such
>         a mechanism is outside the scope of this document.";
...

This brings to mind an old Sidney Harris cartoon.

Am I the only one bothered by putting a MUST on an
undefined behaviour?

Randy



From mbj@tail-f.com  Thu Dec 19 23:11:54 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655EA1AF6E2 for ; Thu, 19 Dec 2013 23:11:54 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMoZlvmnh6C4 for ; Thu, 19 Dec 2013 23:11:52 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id A3DF31AE14A for ; Thu, 19 Dec 2013 23:11:52 -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 E9F8437C06F; Fri, 20 Dec 2013 08:11:48 +0100 (CET)
Date: Fri, 20 Dec 2013 08:11:48 +0100 (CET)
Message-Id: <20131220.081148.1253080928240298313.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund 
In-Reply-To: <20464301.1387501800659.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
References: <20464301.1387501800659.JavaMail.root@mswamui-valley.atl.sa.earthlink.net>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Dec 2013 07:11:54 -0000

Randy Presuhn  wrote:
> Hi -
> 
> >From: Martin Bjorklund 
> >Sent: Dec 19, 2013 10:36 AM
> >To: bclaise@cisco.com
> >Cc: randy_presuhn@mindspring.com, netmod@ietf.org
> >Subject: Re: [netmod] mapping to snmp strings
> ...
> >         A server implementation MAY map this leaf to the sysContact
> >         MIB object.  Such an implementation MUST use some mechanism
> >         to handle the differences in size and characters allowed
> >         between this leaf and sysContact.  The definition of such
> >         a mechanism is outside the scope of this document.";
> ...
> 
> This brings to mind an old Sidney Harris cartoon.
> 
> Am I the only one bothered by putting a MUST on an
> undefined behaviour?

s/MUST/must/
or
s/MUST/need to/


/martin

From bclaise@cisco.com  Fri Dec 20 08:04:21 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE811ADFB6 for ; Fri, 20 Dec 2013 08:04:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level: 
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLLL_MQHj2SA for ; Fri, 20 Dec 2013 08:04:20 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id A97FD1ADFA7 for ; Fri, 20 Dec 2013 08:04:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1407; q=dns/txt; s=iport; t=1387555458; x=1388765058; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=J0qiWwWXGAv89SFi0x8favPW4al3zshg8stEnA/BBa0=; b=Wtl6rgrLBVZLP8KFxiicrllbYVofLj+u/+h2M0uczOj1ia+CzXXsL+uC yjXgOjSnBuJ57M13NejA0OZS9zrfA728KijsJ2i88UM+WJYkIsX/IfAr2 69zzsltFMUscAm7c+wRiBi07o3Jcp1XXIJ+fnxV4HBOwbqKcl4+xJZOs/ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFABBqtFKQ/khM/2dsb2JhbABZgws4uTxPgRwWdIIlAQEBBAEBATU2CgEQCw4DBAEBAQkWDwkDAgECARUoCAYBDAEFAgEBiAANymoTBI8SB4Q2AQOYFoZFi0+DLDs
X-IronPort-AV: E=Sophos;i="4.95,521,1384300800";  d="scan'208";a="2585594"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 20 Dec 2013 16:04:16 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBKG4FTZ008677; Fri, 20 Dec 2013 16:04:15 GMT
Message-ID: <52B46A7F.7090903@cisco.com>
Date: Fri, 20 Dec 2013 17:04:15 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Martin Bjorklund , randy_presuhn@mindspring.com
References: <20464301.1387501800659.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <20131220.081148.1253080928240298313.mbj@tail-f.com>
In-Reply-To: <20131220.081148.1253080928240298313.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] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Dec 2013 16:04:21 -0000

Dear all,

If someone can NOT live with the proposal below, it's time to speak up.
If no answers (allow a couple of working days), Martin, please post a 
new draft-ietf-netmod-system-mgmt version. I'll progress the draft from 
there.

Also, please include the similar changes in 
draft-ietf-netmod-interfaces-cfg, and post a new version when the IETF 
LC ends (December 23rd)

Regards, Benoit
> Randy Presuhn  wrote:
>> Hi -
>>
>>> From: Martin Bjorklund 
>>> Sent: Dec 19, 2013 10:36 AM
>>> To: bclaise@cisco.com
>>> Cc: randy_presuhn@mindspring.com, netmod@ietf.org
>>> Subject: Re: [netmod] mapping to snmp strings
>> ...
>>>          A server implementation MAY map this leaf to the sysContact
>>>          MIB object.  Such an implementation MUST use some mechanism
>>>          to handle the differences in size and characters allowed
>>>          between this leaf and sysContact.  The definition of such
>>>          a mechanism is outside the scope of this document.";
>> ...
>>
>> This brings to mind an old Sidney Harris cartoon.
>>
>> Am I the only one bothered by putting a MUST on an
>> undefined behaviour?
> s/MUST/must/
> or
> s/MUST/need to/
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From arusso@amsl.com  Tue Dec 17 13:20:28 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF15C1A8028; Tue, 17 Dec 2013 13:20:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level: 
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zt4l1A9MJJT0; Tue, 17 Dec 2013 13:20:26 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:126c::1:15]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE031ACCEE; Tue, 17 Dec 2013 13:20:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c9a.amsl.com (Postfix) with ESMTP id 65D6EA6121; Tue, 17 Dec 2013 13:20:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c9a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3sRT2m_iCSI; Tue, 17 Dec 2013 13:20:15 -0800 (PST)
Received: from rfc2.home (pool-68-238-162-118.washdc.fios.verizon.net [68.238.162.118]) by c9a.amsl.com (Postfix) with ESMTPSA id 889D59FB9A; Tue, 17 Dec 2013 13:20:14 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Alice Russo 
In-Reply-To: <20131217153507.C716E7FC397@rfc-editor.org>
Date: Tue, 17 Dec 2013 16:20:23 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <9546823D-6DA4-4AA2-832E-381DB14B41BE@amsl.com>
References: <20131217153507.C716E7FC397@rfc-editor.org>
To: jiminychris@gmail.com, Benoit Claise 
X-Mailer: Apple Mail (2.1085)
X-Mailman-Approved-At: Fri, 20 Dec 2013 08:17:15 -0800
Cc: IESG IESG , netmod@ietf.org, RFC Editor 
Subject: Re: [netmod] [Errata Rejected] RFC6020 (3833)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 21:20:28 -0000

FYI, with the AD's approval, Errata ID 3833 has been removed from the =
system (rather than being listed as Rejected) because it was a duplicate =
of http://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D3290.

Thank you.
RFC Editor/ar

On Dec 17, 2013, at 10:35 AM, RFC Errata System wrote:

> The following errata report has been rejected 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=3D3833
>=20
> --------------------------------------
> Status: Rejected
> Type: Technical
>=20
> Reported by: Chris LaBauve 
> Date Reported: 2013-12-12
> Rejected by: Benoit Claise (IESG)
>=20
> Section: 12
>=20
> Original Text
> -------------
> decimal64-specification =3D fraction-digits-stmt
>=20
> Corrected Text
> --------------
> decimal64-specification =3D ;; these stmts can appear in any order
>                          fraction-digits-stmt stmtsep
>                          [range-stmt stmtsep]
>=20
> Notes
> -----
> decimal64 types should allow for a range substatement; 9.2.4 states =
the range statement "is used to restrict integer and decimal built-in =
types."
> --VERIFIER NOTES--=20
> Errata 3290 has already dealt with this issue.
>=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
>=20


From arusso@amsl.com  Tue Dec 17 13:20:33 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535B61A1F79; Tue, 17 Dec 2013 13:20:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level: 
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shaLHYNcsJ8y; Tue, 17 Dec 2013 13:20:29 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:126c::1:15]) by ietfa.amsl.com (Postfix) with ESMTP id 69A191A8028; Tue, 17 Dec 2013 13:20:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c9a.amsl.com (Postfix) with ESMTP id 82064A6121; Tue, 17 Dec 2013 13:20:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c9a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmp0skRwlrkj; Tue, 17 Dec 2013 13:20:18 -0800 (PST)
Received: from rfc2.home (pool-68-238-162-118.washdc.fios.verizon.net [68.238.162.118]) by c9a.amsl.com (Postfix) with ESMTPSA id A1F329FB9A; Tue, 17 Dec 2013 13:20:17 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Alice Russo 
In-Reply-To: <20131213154036.8D4A97FC390@rfc-editor.org>
Date: Tue, 17 Dec 2013 16:20:27 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <62AE4B8E-6FF0-43D0-993A-DBD103AEA069@amsl.com>
References: <20131213154036.8D4A97FC390@rfc-editor.org>
To: jiminychris@gmail.com, Benoit Claise 
X-Mailer: Apple Mail (2.1085)
X-Mailman-Approved-At: Fri, 20 Dec 2013 08:17:15 -0800
Cc: IESG IESG , netmod@ietf.org, RFC Editor 
Subject: Re: [netmod] [Errata Rejected] RFC6020 (3841)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Dec 2013 21:20:33 -0000

FYI, with the AD's approval, Errata ID 3841 has been removed from the =
system (rather than being listed as Rejected) because it was a duplicate =
of http://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D3290.

Thank you.
RFC Editor/ar

On Dec 13, 2013, at 10:40 AM, RFC Errata System wrote:

> The following errata report has been rejected 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=3D3841
>=20
> --------------------------------------
> Status: Rejected
> Type: Technical
>=20
> Reported by: Chris LaBauve 
> Date Reported: 2013-12-12
> Rejected by: Benoit Claise (IESG)
>=20
> Section: 12
>=20
> Original Text
> -------------
> decimal64-specification =3D fraction-digits-stmt
>=20
> Corrected Text
> --------------
> decimal64-specification =3D ;; these stmts can appear in any order
>                          fraction-digits-stmt stmtsep
>                          [range-stmt stmtsep]
>=20
> Notes
> -----
> decimal64 types should allow for a range substatement; 9.2.4 states =
the range statement "is used to restrict integer and decimal built-in =
types."
> --VERIFIER NOTES--=20
> Duplicate of =
http://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D3290
>=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
>=20


From blukovic@ndt-inc.com  Fri Dec 20 08:38:32 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96861ADBCF for ; Fri, 20 Dec 2013 08:38:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fixDcchogg8M for ; Fri, 20 Dec 2013 08:38:31 -0800 (PST)
Received: from mail19f.g19.rapidsite.net (mail19f.g19.rapidsite.net [204.202.242.19]) by ietfa.amsl.com (Postfix) with ESMTP id D03121ACCF5 for ; Fri, 20 Dec 2013 08:38:30 -0800 (PST)
Received: from mx120.stngva01.us.mxservers.net (198.173.112.49) by mail19f.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 1-0178437506 for ; Fri, 20 Dec 2013 11:38:26 -0500 (EST)
Received: from unknown [161.58.75.15] (EHLO mmm1913.dulles19-verio.com) by va1-mx120.stngva01.us.mxservers.net (mxl_mta-3.1.0-05) with ESMTP id 28274b25.2713701280.703983.00-002.va1-mx120.stngva01.us.mxservers.net (envelope-from );  Fri, 20 Dec 2013 11:38:26 -0500 (EST)
Received: (qmail 48922 invoked from network); 20 Dec 2013 16:38:26 -0000
Received: from unknown (HELO ?192.168.0.21?) (blukovic@135.23.154.141) by  with ESMTPA; 20 Dec 2013 16:38:26 -0000
Message-ID: <52B47282.1020703@ndt-inc.com>
Date: Fri, 20 Dec 2013 11:38:26 -0500
From: B Lukovic 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: netmod@ietf.org
References: <20464301.1387501800659.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <20131220.081148.1253080928240298313.mbj@tail-f.com> <52B46A7F.7090903@cisco.com>
In-Reply-To: <52B46A7F.7090903@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam: [F=0.2000000000; S=0.200(2010122901); MH=0.500(2013122013)]
X-MAIL-FROM: 
X-SOURCE-IP: [161.58.75.15]
X-SF-Loop: 1
X-Mailman-Approved-At: Fri, 20 Dec 2013 09:08:57 -0800
Subject: Re: [netmod] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Dec 2013 17:03:46 -0000

Based on incompatibility between NetConf string, and 
DisplayString/SnmpAdminString
I don't think that any description that suggests mapping of "string" 
yang object
to "DisplayString/SnmpAdminString" MIB object should use word MUST.
Unless we can come up with mapping algorithm (option 5) this is simply 
going to create interoperability problem.

Regards
     Borislav
     blukovic@ndt-inc.com

On 12/20/2013 11:04 AM, Benoit Claise wrote:
> Dear all,
>
> If someone can NOT live with the proposal below, it's time to speak up.
> If no answers (allow a couple of working days), Martin, please post a 
> new draft-ietf-netmod-system-mgmt version. I'll progress the draft 
> from there.
>
> Also, please include the similar changes in 
> draft-ietf-netmod-interfaces-cfg, and post a new version when the IETF 
> LC ends (December 23rd)
>
> Regards, Benoit
>> Randy Presuhn  wrote:
>>> Hi -
>>>
>>>> From: Martin Bjorklund 
>>>> Sent: Dec 19, 2013 10:36 AM
>>>> To: bclaise@cisco.com
>>>> Cc: randy_presuhn@mindspring.com, netmod@ietf.org
>>>> Subject: Re: [netmod] mapping to snmp strings
>>> ...
>>>>          A server implementation MAY map this leaf to the sysContact
>>>>          MIB object.  Such an implementation MUST use some mechanism
>>>>          to handle the differences in size and characters allowed
>>>>          between this leaf and sysContact.  The definition of such
>>>>          a mechanism is outside the scope of this document.";
>>> ...
>>>
>>> This brings to mind an old Sidney Harris cartoon.
>>>
>>> Am I the only one bothered by putting a MUST on an
>>> undefined behaviour?
>> s/MUST/must/
>> or
>> s/MUST/need to/
>>
>>
>> /martin
>> _______________________________________________
>> 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 randy_presuhn@mindspring.com  Fri Dec 20 10:14:19 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA7C1AE09E for ; Fri, 20 Dec 2013 10:14:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYC_eRirbEKN for ; Fri, 20 Dec 2013 10:14:18 -0800 (PST)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECCB1AE09D for ; Fri, 20 Dec 2013 10:14:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RAtQL4Ajpe+3rbmk4zCqkRrn3U8LNtAHnsCyYNde333zUOqiFbtTvo+u5XdOnP/j; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.41] (helo=elwamui-mouette.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Vu4aV-0000LR-50 for netmod@ietf.org; Fri, 20 Dec 2013 13:14:15 -0500
Received: from 76.254.54.154 by webmail.earthlink.net with HTTP; Fri, 20 Dec 2013 13:14:15 -0500
Message-ID: <21533987.1387563255169.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net>
Date: Fri, 20 Dec 2013 10:14:15 -0800 (GMT-08:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb59690674f843f11c2ef3eea80b2c85c4350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.41
Subject: Re: [netmod] mapping to snmp strings
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Dec 2013 18:14:19 -0000

Hi -

>From: Benoit Claise 
>Sent: Dec 20, 2013 8:04 AM
>To: Martin Bjorklund , randy_presuhn@mindspring.com
>Cc: netmod@ietf.org
>Subject: Re: [netmod] mapping to snmp strings
>
>Dear all,
>
>If someone can NOT live with the proposal below, it's time to speak up.
>If no answers (allow a couple of working days), Martin, please post a 
>new draft-ietf-netmod-system-mgmt version. I'll progress the draft from 
>there.

I think the "MUST" and "must" variants of (2) are untenable.

*If* I were implementing this stuff, I'd still push for option
(5) because it would provide the most useful and predictable
interoperability.  However, I'm not implementing this, so I
could live with the "need to" variant of option 2.

(But I reserve the right to say "told you so" at a later date.  :-)

In fairness, while writing a first approximation of
a standardized mapping proposal would be pretty easy,
it quickly becomes messy when one considers how normalization
forms (unfortunately not specified in the definition of
SnmpAdminString) enter the picture, especially when the
DisplayString or SnmpAdminString is used as an index.

Randy

From internet-drafts@ietf.org  Mon Dec 23 01:29:19 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F921ADF48; Mon, 23 Dec 2013 01:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm3t3OajgQRT; Mon, 23 Dec 2013 01:29:18 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F87E1ADF12; Mon, 23 Dec 2013 01:29:18 -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: 4.90
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131223092917.19765.68981.idtracker@ietfa.amsl.com>
Date: Mon, 23 Dec 2013 01:29:17 -0800
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-15.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Dec 2013 09:29:19 -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 Working Gr=
oup of the IETF.

        Title           : A YANG Data Model for Interface Management
        Author          : Martin Bjorklund
	Filename        : draft-ietf-netmod-interfaces-cfg-15.txt
	Pages           : 45
	Date            : 2013-12-23

Abstract:
   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface type specific data models
   augment the generic interfaces data model defined in this document.
   The data model includes configuration data and state data (status
   information and counters for the collection of statistics).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-15

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-interfaces-cfg-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Mon Dec 23 01:31:02 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8986C1ADF56; Mon, 23 Dec 2013 01:31:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_mY2gKp5TNK; Mon, 23 Dec 2013 01:31:01 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 067611AC82A; Mon, 23 Dec 2013 01:31:00 -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: 4.90
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131223093100.19070.29366.idtracker@ietfa.amsl.com>
Date: Mon, 23 Dec 2013 01:31:00 -0800
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Dec 2013 09:31:02 -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 Working Gr=
oup of the IETF.

        Title           : A YANG Data Model for System Management
        Authors         : Andy Bierman
                          Martin Bjorklund
	Filename        : draft-ietf-netmod-system-mgmt-10.txt
	Pages           : 39
	Date            : 2013-12-23

Abstract:
   This document defines a YANG data model for the configuration and
   identification of some common system properties within a device
   containing a NETCONF server.  This includes data node definitions for
   system identification, time-of-day management, user management, DNS
   resolver configuration, and some protocol operations for system
   management.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From j.schoenwaelder@jacobs-university.de  Mon Dec 23 10:51:42 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931B21AE25D for ; Mon, 23 Dec 2013 10:51:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.788
X-Spam-Level: 
X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etWkvN-lfLcl for ; Mon, 23 Dec 2013 10:51:40 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 809C31ADFD5 for ; Mon, 23 Dec 2013 10:51:39 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D152020069; Mon, 23 Dec 2013 19:51:35 +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 rr1pcw1beH27; Mon, 23 Dec 2013 19:51:35 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6933020065; Mon, 23 Dec 2013 19:51:35 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 599F32A25094; Mon, 23 Dec 2013 19:51:31 +0100 (CET)
Date: Mon, 23 Dec 2013 19:51:31 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20131223185131.GB7170@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] interfaces-cfg-15 and system-mgmt-10
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Dec 2013 18:51:42 -0000

Hi,

Martin has posted revised I-Ds in order to resolve the issues that
were raised. The diffs are here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-interfaces-cfg-15.txt
http://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-system-mgmt-10.txt

I believe the changes document concensus. If you believe otherwise,
please tell us over xmas. I believe Benoit wants to move these
documents to the IESG.

/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  Mon Dec 23 10:56:36 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5631AE251 for ; Mon, 23 Dec 2013 10:56:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.788
X-Spam-Level: 
X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIy7gHH6D0SK for ; Mon, 23 Dec 2013 10:56:35 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 05E601ADFD5 for ; Mon, 23 Dec 2013 10:56:35 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A5622006B; Mon, 23 Dec 2013 19:56:31 +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 MH7WzfHp7ukF; Mon, 23 Dec 2013 19:56:31 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1286720069; Mon, 23 Dec 2013 19:56:31 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 1E3252A25121; Mon, 23 Dec 2013 19:56:27 +0100 (CET)
Date: Mon, 23 Dec 2013 19:56:27 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20131223185627.GC7170@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20131203151610.GB71692@elstar.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20131203151610.GB71692@elstar.local>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [netmod] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Dec 2013 18:56:36 -0000

On Tue, Dec 03, 2013 at 04:16:10PM +0100, Juergen Schoenwaelder wrote:
> Hi,
> 
> I hereby like to start a WG last call for the document "A YANG Data
> Model for Routing Management":
> 
>   http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-12
> 
> Please indicate your support by Friday December 20th. We are not only
> interested in receiving defect reports, we are equally interested in
> statements of the form:
> 
>   "I have reviewed I-D XYZ and I found no issues"
>   "I have implemented the data model in I-D XYZ"
>   "I am implementing the data model in I-D XYZ"
>   "I am considering to implement the data model in I-D XYZ"
> 
> This is the 1st WG last call on this document.
> 

This WG last call did end. We received a detailed review by Martin
(but I am not sure all issues got resolved) and a review by Lisa. I
contacted the routing area but have not received anything from them.
It would not hurt to receive another review as an xmas present...

But assuming Martin's comments can get resolved, I will move this
document to Benoit's desk since it received significant reviews from
various routing experts before.

/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@yumaworks.com  Mon Dec 23 11:43:00 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108581AE283 for ; Mon, 23 Dec 2013 11:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsC4IHIYxSkf for ; Mon, 23 Dec 2013 11:42:58 -0800 (PST)
Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFBE1AE27D for ; Mon, 23 Dec 2013 11:42:58 -0800 (PST)
Received: by mail-qe0-f53.google.com with SMTP id nc12so5631765qeb.12 for ; Mon, 23 Dec 2013 11:42:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=vWBT7+0SZrLlNy8NGV3Yzf1yesknxp5X2bgAApzyTZE=; b=Ey3Lnv5zeYBWk+u94rFSnYd5GxCraeQHKbsWxjFKu3/fF/w+DpeUnLp6BoGHOB1wRN vTUStydn1KxMqn1T/qPjLJ6fmHMXbl2FSb+3gLiFWIDjmb0O/Rp5+zwTDcKxMjZHgNRJ AZ1vkwlPAsPcuuygpDvQG7RZ3AMa2cM3SmKpOW3MkZyALUIMvtOj7y1BuXdmCvSSwn4Y phIyO6wW8pbk5GE+yhaJOnVVuKETAmkbNsng9Q75aV6HcpXcNROGZPgeJVDJrd+gn+Ix RVxHINOvhyDc1gy1gvZpskpQJfiIxBNB2U1rX9DgIxZnFFVwzGCRMX4gS5LGchxA9Vmb W18A==
X-Gm-Message-State: ALoCoQku56JaXskU9T7E4Z5tTp3ITQe5MnltN+ogS29HXWFKHvgC1o0K+jNDxLeKlKPenBxWWc/a
MIME-Version: 1.0
X-Received: by 10.224.123.15 with SMTP id n15mr34403764qar.78.1387827774802; Mon, 23 Dec 2013 11:42:54 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Mon, 23 Dec 2013 11:42:54 -0800 (PST)
In-Reply-To: <20131223193958.22781.67826.idtracker@ietfa.amsl.com>
References: <20131223193958.22781.67826.idtracker@ietfa.amsl.com>
Date: Mon, 23 Dec 2013 11:42:54 -0800
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0149cf8086e8f504ee38d595
Subject: [netmod] Fwd: I-D Action: draft-bierman-netmod-yang-conformance-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Dec 2013 19:43:00 -0000

--089e0149cf8086e8f504ee38d595
Content-Type: text/plain; charset=ISO-8859-1

FYI,

The YANG Conformance draft has been updated based on email revirews
and discussions at the November IETF meeting.


Andy



---------- Forwarded message ----------
From: 
Date: Mon, Dec 23, 2013 at 11:39 AM
Subject: I-D Action: draft-bierman-netmod-yang-conformance-02.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts
directories.


        Title           : YANG Conformance Specification
        Author          : Andy Bierman
        Filename        : draft-bierman-netmod-yang-conformance-02.txt
        Pages           : 40
        Date            : 2013-12-23

Abstract:
   This document describes conformance specification and advertisement
   mechanisms for NETCONF servers implementing YANG data model modules.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-bierman-netmod-yang-conformance-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--089e0149cf8086e8f504ee38d595
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


FYI,

The YANG Conformance draft has bee=
n updated based on email revirews
and discussions at the November=
 IETF meeting.


Andy





---------- Forwarded message =
----------
From:  &l=
t;internet-drafts@ietf.org&=
gt;

Date: Mon, Dec 23, 2013 at 11:39 AM
Subject: I-D Action: draft-bierman-n=
etmod-yang-conformance-02.txt
To: i-d-announce@ietf.org




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : YANG Conformance Specification<=
br>
=A0 =A0 =A0 =A0 Author =A0 =A0 =A0 =A0 =A0: Andy Bierman

=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netmod-yang-conform=
ance-02.txt

=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 40

=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-23



Abstract:

=A0 =A0This document describes conformance specification and advertisement<=
br>
=A0 =A0mechanisms for NETCONF servers implementing YANG data model modules.=






The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-bierman-n=
etmod-yang-conformance/



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-bierman-netmod-yang=
-conformance-02



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-bie=
rman-netmod-yang-conformance-02





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@ietf.org

https://www.ietf.org/mailman/listinfo/i-d=
-announce

Internet-Draft directories: http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt





--089e0149cf8086e8f504ee38d595--

From bclaise@cisco.com  Tue Dec 24 03:36:47 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2061ADEDC for ; Tue, 24 Dec 2013 03:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level: 
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuES-iyfRZtf for ; Tue, 24 Dec 2013 03:36:46 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 321701A802A for ; Tue, 24 Dec 2013 03:36:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=495; q=dns/txt; s=iport; t=1387885002; x=1389094602; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=A/gFzbGIzkDqd2SmQw6IRYUuuJ25+0fA7MCVfew4H0Y=; b=NcNhySJCXDTkFzt3uRabfQzqZG0Jt8ukVhYHCj8QYW3BDZCU0sDxfXuv T2XSPXeUuGGYRY73TFQbRSwgBJxzF4e9TNg/PUDsHEvdpoJQt/CFJNGqe 0Ia/25Z3Y7Husrzi2A5P+FgBduP8udkdMfBSlMQ2B2qg9cdA0vENyH1qQ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAKFwuVKtJXHB/2dsb2JhbABZgws4ulCBHRZ0giYBAQQ4QBELIRYPCQMCAQIBRRMIAQGIAA3KbBePIhaEIAEDlDODZIEwhRWLT4MuOw
X-IronPort-AV: E=Sophos;i="4.95,542,1384300800";  d="scan'208";a="8848051"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-5.cisco.com with ESMTP; 24 Dec 2013 11:36:42 +0000
Received: from [10.82.235.103] (rtp-vpn5-868.cisco.com [10.82.235.103]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBOBafkc000351 for ; Tue, 24 Dec 2013 11:36:42 GMT
Message-ID: <52B971C9.1050709@cisco.com>
Date: Tue, 24 Dec 2013 12:36:41 +0100
From: Benoit Claise 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: netmod@ietf.org
References: <20131223185131.GB7170@elstar.local>
In-Reply-To: <20131223185131.GB7170@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] interfaces-cfg-15 and system-mgmt-10
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Dec 2013 11:36:47 -0000

Hi,
> Hi,
>
> Martin has posted revised I-Ds in order to resolve the issues that
> were raised. The diffs are here:
>
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-interfaces-cfg-15.txt
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-system-mgmt-10.txt
>
> I believe the changes document concensus. If you believe otherwise,
> please tell us over xmas. I believe Benoit wants to move these
> documents to the IESG.
That's correct :-)

Regards, Benoit
>
> /js
>


From mbj@tail-f.com  Fri Dec 27 02:45:18 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF7F1AE103 for ; Fri, 27 Dec 2013 02:45:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.262
X-Spam-Level: 
X-Spam-Status: No, score=0.262 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVNvQTlb4mh3 for ; Fri, 27 Dec 2013 02:45:16 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C37E31AE0F4 for ; Fri, 27 Dec 2013 02:45:15 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id F090037C077; Fri, 27 Dec 2013 11:45:09 +0100 (CET)
Date: Fri, 27 Dec 2013 11:45:09 +0100 (CET)
Message-Id: <20131227.114509.335814080.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20131203151610.GB71692@elstar.local> <20131215.220338.304654767.mbj@tail-f.com> 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Dec 2013 10:45:18 -0000

Ladislav Lhotka  wrote:
Hi,

> Hi Martin,
> 
> thank you for the review.
> 
> Martin Bjorklund  writes:
> 
> > Hi,
> >
> > I have reviewed this document, and here are my comments:
> >
> >
> > I plan to implement this data model for a non-router (host).  In the
> 
> Good. Do you plan to generate some platform-specific init scripts, or use
> another mechanism for getting the configuration into the system guts?

Probably init scripts and using the ip command.

> > introduction and objectives section it is mentioned that this data
> > model is suitable for such a device.  I think the document should
> > include a section that discusses what such an implementation should
> > do.  For example, implement the "static" and "direct"
> 
> I can add this, perhaps as an appendix, although it won't be as straightforward
> as you might think, see below.

This is actually a good reason for having such a text.  Otherwise an
implementor of a host that "just want some static routes" might think
that this module is overkill and not suitable.

> > pseudo-protocols, allow exactly one user-controlled routing instance
> > (?), do not implement "multiple-ribs".  What does router-id mean for a
> 
> It depends on where you draw the line between a host and a router. For example,
> in Linux you can configure user-defined routing tables straight in the kernel.
> 
> router-id is only useful for (some) routing protocols. On the other hand,
> configuring it on a host is OK, it will only have no effect.

This should probably be clarified in the description of this leaf.

> > host?  Does a host have to implement the configuration tree for ribs?
> 
> It depends, see above, but probably only when implementing "multiple-ribs".

So should the entire subtree (/routing/ribs) have an if-feature
multiple-ribs stmt?  Or would this be too limiting?  If it is too
limiting, maybe we can provide some additional info in the description
text.  As it is defined right now, I am not sure what is expected of
an implementation of a "simple host".

> > In v{4,6}ur, the term "gateway" is used.  Should this be "next-hop"
> > instead?
> >
> > -----------
> >
> > In the document, term "netxhop" is used.  Should this be "next hop"
> > (in text) and "next-hop" (in data models).
> >
> > -----------
> 
> We have "leaf gateway" and "list nexhop" appearing in two different cases of
> the same choice ("nexthop-options"), so due to YANG rules they cannot have the
> same name. In my view, the term "gateway" is acceptable for this purpose, it
> only should be also mentioned in the text of the document.
> 
> Or do you have another proposal for modelling that choice? 

Maybe:

      case next-hop-list {
        if-feature multipath-routes;
        container next-hops { // or container next-hop-list
          list next-hop {

This would also be consistent with the design of the rest of the
module.

> > 5.1
> >
> >    A routing instance together with its operational status is
> >    represented as an entry of the list "/routing-state/
> >    routing-instance", and identified by a unique numeric identifier.
> >    Configuration of that router instance appears as entry of the list
> >    "/routing/routing-instance" whose key is a routing instance name
> >    selected by the client.
> >
> > But there is no numeric identifier anymore.
> 
> OK, this has to be updated.
> 
> >
> > And: s/operational status/operational state/
> 
> OK, although I consider "status" and "state" to be synonyms.

6241 has this definition:

   o  state data: The additional data on a system that is not
      configuration data such as read-only status information and
      collected statistics.

So it seems there is some distinction between the terms...

> > -----------
> >
> > Since the /routing-state/routing-instance list has a name, and the
> > name is the key, why does it also have an "id", and why is the "id"
> > used in references to the routing-instance?  When I invoke the
> 
> It was a specific request from I2RS to have numeric entry identifiers for the
> lists they are interested in, mainly because these IDs will be sent back and
> forth in their protocol data and they strongly prefer fixed-size integers to
> free-form strings.

Ok, this motivates the "id" - I think it would be useful to explain
this in the description text, i.e, that the id can be used in
protocols that requires a fixed-size integer.

This is fine, but I still think this data model should use the list
key (string) in references.  If some (future) protocol needs to use
the id, they can do that.

Also, we discussed previously the persistency of these identifiers.
Is it required that these ids are the same after a reboot?  This
should be clarified.

> > "active-route" operation, I have to first figure out the "id" of the
> 
> Either way, you have to figure out the name or id, and the number seems safer
> than an arbitrary-length string in terms of type validation.
> 
> > routing-instance, and then use this id.  It seems simpler to always
> > use the name.   Also, the "id" is optional, which makes it unsuitable
> > to be used as an identifier.
> 
> They should be mandatory in any case, that's a mistake. As you know, I intended
> to have the numeric ids in the role of opstate list keys.
> 
> >
> > The same comment applies to /routing-state/ribs/rib.
> >
> > Also, for the lists that do need an "id" (route, nexthop), the id leaf
> > needs to be mandatory.
> 
> Yes.
> 
> >
> > -----------
> >
> > In 5.4.1:
> >
> >    Every routing instance MUST implement exactly one instance of the
> >    "direct" pseudo-protocol type.  The name of this instance MUST also
> >    be "direct".
> >
> > Why does this name have to be "direct"?  I think this should be
> > removed or explained, b/c now if seems arbitrary.
> 
> Yes, now that "source-protocol" contains the protocol type rather than protocol
> instance name, the name is not important. I will remove the last sentence.
> 
> >
> > ------------
> >
> > Editorial nit:  your yin2yang script adds (or doesn't strip) empty
> > lines in some cases:
> >
> >        description
> >          "Return the current number of routes in a RIB.
> >
> >           If the RIB with 'id' equal to 'rib-id' doesn't exist, then
> >           this operation SHALL fail with error-tag 'data-missing' and
> >           error-app-tag 'rib-not-found'.
> >          ";
> >
> 
> We already talked privately about the closing quote and semicolon, and I
> changed the stylesheet so that they will be placed immediately after the text.

Ok.

> But if you mean the empty line inside the description, then I think it is
> important there.

No I just meant the trailing newlines.  I agree that the newlines
inside the descriptions are correct.



/martin


> 
> > -----------
> >
> > Editorial: s/RIBS/RIBs/
> 
> OK, that's my "systematic" typo.
> 
> Thanks, Lada
> 
> >
> >
> >
> > /martin
> >
> >
> >
> > Juergen Schoenwaelder  wrote:
> >> Hi,
> >> 
> >> I hereby like to start a WG last call for the document "A YANG Data
> >> Model for Routing Management":
> >> 
> >>   http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-12
> >> 
> >> Please indicate your support by Friday December 20th. We are not only
> >> interested in receiving defect reports, we are equally interested in
> >> statements of the form:
> >> 
> >>   "I have reviewed I-D XYZ and I found no issues"
> >>   "I have implemented the data model in I-D XYZ"
> >>   "I am implementing the data model in I-D XYZ"
> >>   "I am considering to implement the data model in I-D XYZ"
> >> 
> >> This is the 1st WG last call on this document.
> >> 
> >> /js
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

From lhotka@nic.cz  Fri Dec 27 05:24:30 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED0A1ADED6 for ; Fri, 27 Dec 2013 05:24:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level: 
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7gzAxieiWbD for ; Fri, 27 Dec 2013 05:24:28 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 941141ADEDC for ; Fri, 27 Dec 2013 05:24:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 3B4EC540681 for ; Fri, 27 Dec 2013 14:24:21 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDOJ7tER-LZn for ; Fri, 27 Dec 2013 14:24:17 +0100 (CET)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B88575402AB for ; Fri, 27 Dec 2013 14:24:17 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Fri, 27 Dec 2013 14:24:16 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [netmod] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Dec 2013 13:24:30 -0000

Martin Bjorklund  writes:
...
>
>> > introduction and objectives section it is mentioned that this data
>> > model is suitable for such a device.  I think the document should
>> > include a section that discusses what such an implementation should
>> > do.  For example, implement the "static" and "direct"
>> 
>> I can add this, perhaps as an appendix, although it won't be as straightforward
>> as you might think, see below.
>
> This is actually a good reason for having such a text.  Otherwise an
> implementor of a host that "just want some static routes" might think
> that this module is overkill and not suitable.

OK, I will try to write an appendix describing the minimum variant.

>
>> > pseudo-protocols, allow exactly one user-controlled routing instance
>> > (?), do not implement "multiple-ribs".  What does router-id mean for a
>> 
>> It depends on where you draw the line between a host and a router. For example,
>> in Linux you can configure user-defined routing tables straight in the kernel.
>> 
>> router-id is only useful for (some) routing protocols. On the other hand,
>> configuring it on a host is OK, it will only have no effect.
>
> This should probably be clarified in the description of this leaf.

OK.

>
>> > host?  Does a host have to implement the configuration tree for ribs?
>> 
>> It depends, see above, but probably only when implementing "multiple-ribs".
>
> So should the entire subtree (/routing/ribs) have an if-feature
> multiple-ribs stmt?  Or would this be too limiting?  If it is too

Almost, there is one problem though, that even with a single (default) RIB per address family, it can be useful to be able to define import and export filters for controlling the exchange of routes between routing protocols and the RIB. To do this, one has to configure a "connected-rib" entry, which has "rib-name" as the key. And because "rib-name" is a leafref, the default RIB has to appear in the configuration, due to the CLR that a configuration leafref cannot point to state data.

Actually, "connected-ribs" is already "if-feature multiple-ribs", which is also incorrect, for the same reason.

> limiting, maybe we can provide some additional info in the description
> text.  As it is defined right now, I am not sure what is expected of
> an implementation of a "simple host".
>
>> > In v{4,6}ur, the term "gateway" is used.  Should this be "next-hop"
>> > instead?
>> >
>> > -----------
>> >
>> > In the document, term "netxhop" is used.  Should this be "next hop"
>> > (in text) and "next-hop" (in data models).
>> >
>> > -----------
>> 
>> We have "leaf gateway" and "list nexhop" appearing in two different cases of
>> the same choice ("nexthop-options"), so due to YANG rules they cannot have the
>> same name. In my view, the term "gateway" is acceptable for this purpose, it
>> only should be also mentioned in the text of the document.
>> 
>> Or do you have another proposal for modelling that choice? 
>
> Maybe:
>
>       case next-hop-list {
>         if-feature multipath-routes;
>         container next-hops { // or container next-hop-list
>           list next-hop {
>
> This would also be consistent with the design of the rest of the
> module.

I was thinking about this, too, but it means an extra container per route, and I am not sure whether this is an issue or not, i.e. whether there can be tens of thousands of multipath routes.

>
>> > 5.1
>> >
>> >    A routing instance together with its operational status is
>> >    represented as an entry of the list "/routing-state/
>> >    routing-instance", and identified by a unique numeric identifier.
>> >    Configuration of that router instance appears as entry of the list
>> >    "/routing/routing-instance" whose key is a routing instance name
>> >    selected by the client.
>> >
>> > But there is no numeric identifier anymore.
>> 
>> OK, this has to be updated.
>> 
>> >
>> > And: s/operational status/operational state/
>> 
>> OK, although I consider "status" and "state" to be synonyms.
>
> 6241 has this definition:
>
>    o  state data: The additional data on a system that is not
>       configuration data such as read-only status information and
>       collected statistics.
>
> So it seems there is some distinction between the terms...

OK.

>
>> > -----------
>> >
>> > Since the /routing-state/routing-instance list has a name, and the
>> > name is the key, why does it also have an "id", and why is the "id"
>> > used in references to the routing-instance?  When I invoke the
>> 
>> It was a specific request from I2RS to have numeric entry identifiers for the
>> lists they are interested in, mainly because these IDs will be sent back and
>> forth in their protocol data and they strongly prefer fixed-size integers to
>> free-form strings.
>
> Ok, this motivates the "id" - I think it would be useful to explain
> this in the description text, i.e, that the id can be used in
> protocols that requires a fixed-size integer.
>
> This is fine, but I still think this data model should use the list
> key (string) in references.  If some (future) protocol needs to use
> the id, they can do that.
>
> Also, we discussed previously the persistency of these identifiers.
> Is it required that these ids are the same after a reboot?  This
> should be clarified.

Actually, I was considering the option of leaving these "id" leaves out, with the assumption that I2RS can augment them as needed. The only problem with this is another YANG CLR - they might want these ids to be mandatory, and this is not allowed via "augment".

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

From lhotka@nic.cz  Fri Dec 27 05:38:40 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6461AE006 for ; Fri, 27 Dec 2013 05:38:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.704
X-Spam-Level: *
X-Spam-Status: No, score=1.704 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HOST_EQ_CZ=0.904] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enArM59fm1ur for ; Fri, 27 Dec 2013 05:38:39 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBAC1ADEDC for ; Fri, 27 Dec 2013 05:38:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id F3134540681 for ; Fri, 27 Dec 2013 14:38:33 +0100 (CET)
Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6iOVjSOH1VS for ; Fri, 27 Dec 2013 14:38:31 +0100 (CET)
Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2F4A05402AB for ; Fri, 27 Dec 2013 14:38:27 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Fri, 27 Dec 2013 14:38:26 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Subject: [netmod] multiple if-feature
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Dec 2013 13:38:40 -0000

Hi,

although it may be quite rare, it is possible that a data node has multiple "if-feature" substatements. IMO, it is not clear whether this means:

1. The node is implemented only if all listed features are supported, or

2. it is sufficient if at least one of the features is supported.

RFC 6020 says in Sec. 7.18.2: "The parent statement is implemented by servers that support this feature." This seems to imply option #2. On the other hand, pyang clearly uses #1.

I think both options might potentially make sense, in different circumstances.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

From mbj@tail-f.com  Fri Dec 27 06:38:24 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D775A1AE1CE for ; Fri, 27 Dec 2013 06:38:24 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-GoTZ4UgmNx for ; Fri, 27 Dec 2013 06:38:23 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 533EB1ADEC8 for ; Fri, 27 Dec 2013 06:38:23 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id A5FD937C077; Fri, 27 Dec 2013 15:38:17 +0100 (CET)
Date: Fri, 27 Dec 2013 15:38:17 +0100 (CET)
Message-Id: <20131227.153817.209341120.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] multiple if-feature
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Dec 2013 14:38:25 -0000

Ladislav Lhotka  wrote:
> Hi,
> 
> although it may be quite rare, it is possible that a data node has multiple
> "if-feature" substatements. IMO, it is not clear whether this means:
> 
> 1. The node is implemented only if all listed features are supported, or
> 
> 2. it is sufficient if at least one of the features is supported.
> 
> RFC 6020 says in Sec. 7.18.2: "The parent statement is implemented by servers
> that support this feature." This seems to imply option #2. On the other hand,
> pyang clearly uses #1.

It is supposed to be #1 - multiple if-features works like AND.  

7.18.1 says

   The "feature" statement is used to define a mechanism by which
   portions of the schema are marked as conditional.  A feature name is
   defined that can later be referenced using the "if-feature" statement
   (see Section 7.18.2).  Schema nodes tagged with a feature are ignored
   by the device unless the device supports the given feature.

The last sentence implies the AND.

It also says:

   Definitions tagged with "if-feature" are ignored when the
   device does not support that feature.

I agree that this should be more clear in 7.18.2

> I think both options might potentially make sense, in different circumstances.

Agreed.  In fact, sometimes you need any boolean expression.
Something to consider for YANG 1.1.


/martin

From mbj@tail-f.com  Fri Dec 27 06:54:58 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF70D1AE1E2 for ; Fri, 27 Dec 2013 06:54:58 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mhzi_4Sacmr6 for ; Fri, 27 Dec 2013 06:54:57 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 068D31AE1A6 for ; Fri, 27 Dec 2013 06:54:57 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id A6F3F37C077; Fri, 27 Dec 2013 15:54:49 +0100 (CET)
Date: Fri, 27 Dec 2013 15:54:49 +0100 (CET)
Message-Id: <20131227.155449.303411576.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / 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] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Dec 2013 14:54:58 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> ...

> > So should the entire subtree (/routing/ribs) have an if-feature
> > multiple-ribs stmt?  Or would this be too limiting?  If it is too
> 
> Almost, there is one problem though, that even with a single (default) RIB per
> address family, it can be useful to be able to define import and export filters
> for controlling the exchange of routes between routing protocols and the
> RIB. To do this, one has to configure a "connected-rib" entry, which has
> "rib-name" as the key. And because "rib-name" is a leafref, the default RIB has
> to appear in the configuration, due to the CLR that a configuration leafref
> cannot point to state data.
> 
> Actually, "connected-ribs" is already "if-feature multiple-ribs", which is also
> incorrect, for the same reason.

So this feature is not needed?  I guess it should still be defined,
since it means that ribs other than the default rib can be
configured.

> > limiting, maybe we can provide some additional info in the description
> > text.  As it is defined right now, I am not sure what is expected of
> > an implementation of a "simple host".
> >
> >> > In v{4,6}ur, the term "gateway" is used.  Should this be "next-hop"
> >> > instead?
> >> >
> >> > -----------
> >> >
> >> > In the document, term "netxhop" is used.  Should this be "next hop"
> >> > (in text) and "next-hop" (in data models).
> >> >
> >> > -----------
> >> 
> >> We have "leaf gateway" and "list nexhop" appearing in two different cases of
> >> the same choice ("nexthop-options"), so due to YANG rules they cannot have
> >> the
> >> same name. In my view, the term "gateway" is acceptable for this purpose, it
> >> only should be also mentioned in the text of the document.
> >> 
> >> Or do you have another proposal for modelling that choice? 
> >
> > Maybe:
> >
> >       case next-hop-list {
> >         if-feature multipath-routes;
> >         container next-hops { // or container next-hop-list
> >           list next-hop {
> >
> > This would also be consistent with the design of the rest of the
> > module.
> 
> I was thinking about this, too, but it means an extra container per route, and
> I am not sure whether this is an issue or not, i.e. whether there can be tens
> of thousands of multipath routes.
 
It is a NP-container so it shouldn't be a problem.  It adds some noise
to the payload, but I think it should be ok.

> >> > Since the /routing-state/routing-instance list has a name, and the
> >> > name is the key, why does it also have an "id", and why is the "id"
> >> > used in references to the routing-instance?  When I invoke the
> >> 
> >> It was a specific request from I2RS to have numeric entry identifiers for
> >> the
> >> lists they are interested in, mainly because these IDs will be sent back and
> >> forth in their protocol data and they strongly prefer fixed-size integers to
> >> free-form strings.
> >
> > Ok, this motivates the "id" - I think it would be useful to explain
> > this in the description text, i.e, that the id can be used in
> > protocols that requires a fixed-size integer.
> >
> > This is fine, but I still think this data model should use the list
> > key (string) in references.  If some (future) protocol needs to use
> > the id, they can do that.
> >
> > Also, we discussed previously the persistency of these identifiers.
> > Is it required that these ids are the same after a reboot?  This
> > should be clarified.
> 
> Actually, I was considering the option of leaving these "id" leaves out, with
> the assumption that I2RS can augment them as needed. The only problem with this
> is another YANG CLR - they might want these ids to be mandatory, and this is
> not allowed via "augment".

Right, and it not possible to declare them as "unique" either
afterwards :(


/martin

From lhotka@nic.cz  Fri Dec 27 07:52:52 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E340A1AE20E for ; Fri, 27 Dec 2013 07:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTAMhcJ2zGM6 for ; Fri, 27 Dec 2013 07:52:50 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 811F91ADF69 for ; Fri, 27 Dec 2013 07:52:50 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0F07C13FE04; Fri, 27 Dec 2013 16:52:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1388159565; bh=qtAlbBa5a+WXAsSrmCTIpdzMsnC0SKW8DadrgnD/km4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hkCWexR6ccmGaQNfsKYa5/Uql3o4NLf+nVJtGgiWiOYNQMxVJ74HU2dIel3y2UyUf t1zzI/tNefF+aYAFu2/1tXFxkMK5gg9HIl71kfHO/1sRdZ25zqSbX3rRwyFXzgkA3B fEH9gx6F7gYWu7WHxRV1PnsXVn6E3hxWYdz/pgeE=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20131227.155449.303411576.mbj@tail-f.com>
Date: Fri, 27 Dec 2013 16:52:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B2E08BE-10B4-4370-B52B-34EC9B3491B3@nic.cz>
References:  <20131227.155449.303411576.mbj@tail-f.com>
To: =?windows-1252?Q?Martin_Bj=F6rklund?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Dec 2013 15:52:53 -0000

On 27 Dec 2013, at 15:54, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>> ...
>=20
>>> So should the entire subtree (/routing/ribs) have an if-feature
>>> multiple-ribs stmt?  Or would this be too limiting?  If it is too
>>=20
>> Almost, there is one problem though, that even with a single =
(default) RIB per
>> address family, it can be useful to be able to define import and =
export filters
>> for controlling the exchange of routes between routing protocols and =
the
>> RIB. To do this, one has to configure a "connected-rib" entry, which =
has
>> "rib-name" as the key. And because "rib-name" is a leafref, the =
default RIB has
>> to appear in the configuration, due to the CLR that a configuration =
leafref
>> cannot point to state data.
>>=20
>> Actually, "connected-ribs" is already "if-feature multiple-ribs", =
which is also
>> incorrect, for the same reason.
>=20
> So this feature is not needed?  I guess it should still be defined,
> since it means that ribs other than the default rib can be
> configured.

It should mean that no user-controlled list entries are allowed. =
However, as I wrote, it is sometimes necessary to put a =
system-controlled entry into the config list in order to be able to =
refer to it elsewhere in the configuration. So it is not possible to use =
=93if-feature multiple-ribs=94 for the whole /routing/ribs container.

An alternative is to change the type of =93rib-name=94 links from =
leafref to a simple string and just say in the description that its =
value must be the key of an existing entry in /routing-state/ribs/rib, =
i.e. in the operational state list. Then we could have =93if-feature =
multiple-ribs=94 on /routing/ribs, though not on connected-ribs.

>=20
>>> limiting, maybe we can provide some additional info in the =
description
>>> text.  As it is defined right now, I am not sure what is expected of
>>> an implementation of a "simple host".
>>>=20
>>>>> In v{4,6}ur, the term "gateway" is used.  Should this be =
"next-hop"
>>>>> instead?
>>>>>=20
>>>>> -----------
>>>>>=20
>>>>> In the document, term "netxhop" is used.  Should this be "next =
hop"
>>>>> (in text) and "next-hop" (in data models).
>>>>>=20
>>>>> -----------
>>>>=20
>>>> We have "leaf gateway" and "list nexhop" appearing in two different =
cases of
>>>> the same choice ("nexthop-options"), so due to YANG rules they =
cannot have
>>>> the
>>>> same name. In my view, the term "gateway" is acceptable for this =
purpose, it
>>>> only should be also mentioned in the text of the document.
>>>>=20
>>>> Or do you have another proposal for modelling that choice?=20
>>>=20
>>> Maybe:
>>>=20
>>>      case next-hop-list {
>>>        if-feature multipath-routes;
>>>        container next-hops { // or container next-hop-list
>>>          list next-hop {
>>>=20
>>> This would also be consistent with the design of the rest of the
>>> module.
>>=20
>> I was thinking about this, too, but it means an extra container per =
route, and
>> I am not sure whether this is an issue or not, i.e. whether there can =
be tens
>> of thousands of multipath routes.
>=20
> It is a NP-container so it shouldn't be a problem.  It adds some noise
> to the payload, but I think it should be ok.

OK, if there are no objections from others, I will do that. (Maybe be =
have to leave some time after the holidays for other people to catch =
up.)

>=20
>>>>> Since the /routing-state/routing-instance list has a name, and the
>>>>> name is the key, why does it also have an "id", and why is the =
"id"
>>>>> used in references to the routing-instance?  When I invoke the
>>>>=20
>>>> It was a specific request from I2RS to have numeric entry =
identifiers for
>>>> the
>>>> lists they are interested in, mainly because these IDs will be sent =
back and
>>>> forth in their protocol data and they strongly prefer fixed-size =
integers to
>>>> free-form strings.
>>>=20
>>> Ok, this motivates the "id" - I think it would be useful to explain
>>> this in the description text, i.e, that the id can be used in
>>> protocols that requires a fixed-size integer.
>>>=20
>>> This is fine, but I still think this data model should use the list
>>> key (string) in references.  If some (future) protocol needs to use
>>> the id, they can do that.
>>>=20
>>> Also, we discussed previously the persistency of these identifiers.
>>> Is it required that these ids are the same after a reboot?  This
>>> should be clarified.
>>=20
>> Actually, I was considering the option of leaving these "id" leaves =
out, with
>> the assumption that I2RS can augment them as needed. The only problem =
with this
>> is another YANG CLR - they might want these ids to be mandatory, and =
this is
>> not allowed via "augment".
>=20
> Right, and it not possible to declare them as "unique" either
> afterwards :(

Well, unique could be simulated with a must statement, but anyway, it =
seems we have to have them in the core routing model. So maybe I can =
leave them there (perhaps introduce a new feature for them?), but avoid =
any references to them, and use =93name=94 everywhere. Would this be OK?

Concerning persistence, I *think* these ids are supposed to be ephemeral =
- they are handles to other ephemeral items.

Lada

>=20
>=20
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From mbj@tail-f.com  Fri Dec 27 09:35:22 2013
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826D71AE231 for ; Fri, 27 Dec 2013 09:35:22 -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=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVV63IDEu-Oa for ; Fri, 27 Dec 2013 09:35:20 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0653E1AE21A for ; Fri, 27 Dec 2013 09:35:19 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 4305537C073; Fri, 27 Dec 2013 18:35:14 +0100 (CET)
Date: Fri, 27 Dec 2013 18:35:13 +0100 (CET)
Message-Id: <20131227.183513.118431922.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <6B2E08BE-10B4-4370-B52B-34EC9B3491B3@nic.cz>
References:  <20131227.155449.303411576.mbj@tail-f.com> <6B2E08BE-10B4-4370-B52B-34EC9B3491B3@nic.cz>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] WG Last Call draft-ietf-netmod-routing-cfg-12 (until 2013-12-20)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Dec 2013 17:35:22 -0000

Ladislav Lhotka  wrote:
> 
> On 27 Dec 2013, at 15:54, Martin Bjorklund  wrote:
> 
> > Ladislav Lhotka  wrote:
> >> Martin Bjorklund  writes:
> >> ...
> > 
> >>> So should the entire subtree (/routing/ribs) have an if-feature
> >>> multiple-ribs stmt?  Or would this be too limiting?  If it is too
> >> 
> >> Almost, there is one problem though, that even with a single (default) RIB
> >> per
> >> address family, it can be useful to be able to define import and export
> >> filters
> >> for controlling the exchange of routes between routing protocols and the
> >> RIB. To do this, one has to configure a "connected-rib" entry, which has
> >> "rib-name" as the key. And because "rib-name" is a leafref, the default RIB
> >> has
> >> to appear in the configuration, due to the CLR that a configuration leafref
> >> cannot point to state data.
> >> 
> >> Actually, "connected-ribs" is already "if-feature multiple-ribs", which is
> >> also
> >> incorrect, for the same reason.
> > 
> > So this feature is not needed?  I guess it should still be defined,
> > since it means that ribs other than the default rib can be
> > configured.
> 
> It should mean that no user-controlled list entries are allowed.

Ok.

> However, as I
> wrote, it is sometimes necessary to put a system-controlled entry into the
> config list in order to be able to refer to it elsewhere in the
> configuration. So it is not possible to use “if-feature multiple-ribs” for the
> whole /routing/ribs container.
> 
> An alternative is to change the type of “rib-name” links from leafref to a
> simple string and just say in the description that its value must be the key of
> an existing entry in /routing-state/ribs/rib, i.e. in the operational state
> list. Then we could have “if-feature multiple-ribs” on /routing/ribs, though
> not on connected-ribs.

I'd rather not make this change now... if you do this, what happens
if the config doesn't match the oper state, e.g., after a reboot or
upgrade?

> >>>>> Since the /routing-state/routing-instance list has a name, and the
> >>>>> name is the key, why does it also have an "id", and why is the "id"
> >>>>> used in references to the routing-instance?  When I invoke the
> >>>> 
> >>>> It was a specific request from I2RS to have numeric entry identifiers for
> >>>> the
> >>>> lists they are interested in, mainly because these IDs will be sent back
> >>>> and
> >>>> forth in their protocol data and they strongly prefer fixed-size integers
> >>>> to
> >>>> free-form strings.
> >>> 
> >>> Ok, this motivates the "id" - I think it would be useful to explain
> >>> this in the description text, i.e, that the id can be used in
> >>> protocols that requires a fixed-size integer.
> >>> 
> >>> This is fine, but I still think this data model should use the list
> >>> key (string) in references.  If some (future) protocol needs to use
> >>> the id, they can do that.
> >>> 
> >>> Also, we discussed previously the persistency of these identifiers.
> >>> Is it required that these ids are the same after a reboot?  This
> >>> should be clarified.
> >> 
> >> Actually, I was considering the option of leaving these "id" leaves out,
> >> with
> >> the assumption that I2RS can augment them as needed. The only problem with
> >> this
> >> is another YANG CLR - they might want these ids to be mandatory, and this is
> >> not allowed via "augment".
> > 
> > Right, and it not possible to declare them as "unique" either
> > afterwards :(
> 
> Well, unique could be simulated with a must statement, but anyway, it seems we
> have to have them in the core routing model. So maybe I can leave them there
> (perhaps introduce a new feature for them?), but avoid any references to them,
> and use “name” everywhere. Would this be OK?

Works for me, and I don't think a feature is necessary.


> Concerning persistence, I *think* these ids are supposed to be ephemeral - they
> are handles to other ephemeral items.

Ok.  In any case it should be stated.


/martin