From j.schoenwaelder@jacobs-university.de Fri Jan 3 09:04:31 2014 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 C56341AE018 for ; Fri, 3 Jan 2014 09:04:31 -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 JbNLYdJ_3CSc for ; Fri, 3 Jan 2014 09:04:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5116B1ADFD4 for ; Fri, 3 Jan 2014 09:04:29 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C87962004B for ; Fri, 3 Jan 2014 18:04:21 +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 gttJaz55I9pg for ; Fri, 3 Jan 2014 18:04:21 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3AAE20048 for ; Fri, 3 Jan 2014 18:04:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 20AFE2A75244; Fri, 3 Jan 2014 18:04:19 +0100 (CET) Resent-From: Juergen Schoenwaelder Resent-Date: Fri, 3 Jan 2014 18:04:19 +0100 Resent-Message-ID: <20140103170419.GB28995@elstar.local> Resent-To: netmod@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by SHUBCAS02.jacobs.jacobs-university.de (10.70.0.128) with Microsoft SMTP Server id 14.3.174.1; Fri, 3 Jan 2014 18:03:15 +0100 Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28D3B20042; Fri, 3 Jan 2014 18:03:17 +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 jZb8Nfq538Jp; Fri, 3 Jan 2014 18:03: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 524A92003D; Fri, 3 Jan 2014 18:03:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DC9182A751FF; Fri, 3 Jan 2014 18:03:12 +0100 (CET) Date: Fri, 3 Jan 2014 18:03:12 +0100 From: Juergen Schoenwaelder To: Adrian Farrel Message-ID: <20140103170312.GA28995@elstar.local> References: <20140103133538.4144.83270.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20140103133538.4144.83270.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Exchange-Organization-AuthAs: Anonymous MIME-Version: 1.0 Cc: draft-ietf-netmod-iana-if-type@tools.ietf.org, netmod-chairs@tools.ietf.org, The IESG Subject: Re: [netmod] Adrian Farrel's No Objection on draft-ietf-netmod-iana-if-type-09: (with COMMENT) 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, 03 Jan 2014 17:04:32 -0000 Adrian, thanks for the review - adding the NETMOD WG to the CC, responses inline... On Fri, Jan 03, 2014 at 05:35:38AM -0800, Adrian Farrel wrote: > Adrian Farrel has entered the following ballot position for > draft-ietf-netmod-iana-if-type-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am not a YANG expert, but have a couple of concerns about the > way this module is handed to IANA. > > --- > > I think you should remove... > > This version of this YANG module is part of RFC XXXX; see > the RFC itself for full legal notices."; > // RFC Ed.: replace XXXX with actual RFC number and remove this > // note. > > ...from the main description clause. > > This is because the entire module will be lifted on to the IANA web page > preserving this note. When updates are made to the module by IANA the > note will be wrong, but is unlikely to be removed. > > Indeed, since the normative version will in any case be the web page not > the RFC, the note is de trop. Yes, this should be worded differently. > Similarly... > > // RFC Ed.: update the date below with the date of RFC publication > // and remove this note. > revision 2013-12-07 { > description > "Initial revision."; > reference > "RFC XXXX: IANA Interface Type YANG Module"; > } > > Do you expect each modification by IANA to generate a new version with > a new date? I don't think so. I think the purpose of handing it to IANA > is that it is a living module that can safely be extended at any time by > IANA without sparking a new revision. It is a living module but we expect IANA to generate a new revision evertime the module is updated. The IANA Considerations (section 3) are clear about this: When the iana-if-type YANG module is updated, a new "revision" statement must be added. This is what has been done with IANA maintained MIB modules for years and hence we are pretty sure this is workable. These revision statements are essential for YANG / NETCONF version management to work. Hence, I believe no action is needed here. /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 Jan 6 05:58:50 2014 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 8BCCF1ADBCD for ; Mon, 6 Jan 2014 05:58:50 -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 BVX4wGSCxDZQ for ; Mon, 6 Jan 2014 05:58:48 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 70B001ADF85 for ; Mon, 6 Jan 2014 05:58:48 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D336820045; Mon, 6 Jan 2014 14:58:39 +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 k0f8Jeta4uH4; Mon, 6 Jan 2014 14:58:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1322420035; Mon, 6 Jan 2014 14:58:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C64AE2A79169; Mon, 6 Jan 2014 14:58:35 +0100 (CET) Date: Mon, 6 Jan 2014 14:58:35 +0100 From: Juergen Schoenwaelder To: ietfdbh Message-ID: <20140106135835.GB36685@elstar.local> Mail-Followup-To: ietfdbh , netmod@ietf.org References: <006b01cef53a$addd68c0$6b01a8c0@oemcomputer> <20131210202911.GA74654@elstar.local> <011501cef82e$80adf030$8209d090$@comcast.net> <011f01cef839$e8fb4a10$baf1de30$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011f01cef839$e8fb4a10$baf1de30$@comcast.net> 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: Mon, 06 Jan 2014 13:58:50 -0000 On Fri, Dec 13, 2013 at 02:31:24PM -0500, ietfdbh wrote: > 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? > I suggest you go through the mailing list archive. This data model has been reviewed by people familiar with widely used SNMP code bases. I do not think it is the task of the WG to determine to what extend SNMP implementations are fully compliant to the relevant SNMP and MIB standards. (Speaking as contributor.) /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 Jan 6 06:01:22 2014 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 E7A4C1ADFA6 for ; Mon, 6 Jan 2014 06:01:22 -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 0aKZRmQvvxCb for ; Mon, 6 Jan 2014 06:01:21 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B9A0E1ADF85 for ; Mon, 6 Jan 2014 06:01:21 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27A4A20034; Mon, 6 Jan 2014 15:01:13 +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 6YGQBmWB2HQh; Mon, 6 Jan 2014 15:01:13 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4BF8320037; Mon, 6 Jan 2014 15:01:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3955F2A791DD; Mon, 6 Jan 2014 15:01:09 +0100 (CET) Date: Mon, 6 Jan 2014 15:01:08 +0100 From: Juergen Schoenwaelder To: ietfdbh Message-ID: <20140106140107.GC36685@elstar.local> Mail-Followup-To: ietfdbh , 'Randy Presuhn' , netmod@ietf.org References: <006b01cef53a$addd68c0$6b01a8c0@oemcomputer> <20131210202911.GA74654@elstar.local> <011501cef82e$80adf030$8209d090$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011501cef82e$80adf030$8209d090$@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'Randy Presuhn' , 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: Mon, 06 Jan 2014 14:01:23 -0000 On Fri, Dec 13, 2013 at 01:09:44PM -0500, ietfdbh wrote: > 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. > If you know SNMP CLI configuration interfaces out there for which the current configuration data model does not work, please let us know the details. The document has evolved over time and it will be a rather pointless exercise to determine why every detail worked out the way it is. (writing as contributor) /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 Jan 6 06:22:27 2014 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 9B9D21ADFC6 for ; Mon, 6 Jan 2014 06:22:27 -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_20=-0.001, 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 iOpHKqwJcGdw for ; Mon, 6 Jan 2014 06:22:25 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CE0D81ADFC3 for ; Mon, 6 Jan 2014 06:22:24 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38AD82004D; Mon, 6 Jan 2014 15:22:16 +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 9d9XlDCd1e8C; Mon, 6 Jan 2014 15:22:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A67242004B; Mon, 6 Jan 2014 15:22:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7182A2A79275; Mon, 6 Jan 2014 15:22:13 +0100 (CET) Date: Mon, 6 Jan 2014 15:22:13 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20140106142213.GD36685@elstar.local> Mail-Followup-To: Randy Presuhn , David Kessens , netmod@ietf.org References: <006b01cef53a$addd68c0$6b01a8c0@oemcomputer> <20131210202911.GA74654@elstar.local> <001701cef5f4$dfa6d0c0$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001701cef5f4$dfa6d0c0$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: Mon, 06 Jan 2014 14:22:27 -0000 On Tue, Dec 10, 2013 at 02:12:09PM -0800, Randy Presuhn wrote: > 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. You can create an 'orphaned' (or better empty) group as well in the Yang model if that is really useful. > > > 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. Exactly. And it seems RFC 6536 also lists members as a leaf-list of a group. To move a member in RFC 6536, you also need to make two changes. > > > 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. Well, this might have been your intention but the text quoted above actually can be read to mean something different... > 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. OK. This is seems easily to change and it removes one weird looking CLR from the YANG data model. > > > 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. But I assume SNMP had to be rather explicit about these things because you would have to potentially deal with a sequence of write operations in order to make a conceptual change. With NETCONF, you can execute much bigger atomic changes that you would typically expect with SNMP. But if your concern boils down to the following RFC 3415 text, then we can add something similiar to the YANG I-D: When creating MIB views, it is strongly advised that first the 'excluded' vacmViewTreeFamilyEntries are created and then the 'included' entries. When deleting MIB views, it is strongly advised that first the 'included' vacmViewTreeFamilyEntries are deleted and then the 'excluded' entries. (Well the last one is somewhat pointless since one would not have to delete every 'row' in the include/exclude lists individually with NETCONF.) > 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. Well it can't hurt to remind implementors that they need to ensure that a transaction stays a transaction and does not fall apart due to external events and it might be wise to remind them that failure to do so may become a security issue. We can try to find some wording for this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Mon Jan 6 10:11:56 2014 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 4DA8A1AE13F for ; Mon, 6 Jan 2014 10:11:56 -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 6epwwLn_ua4g for ; Mon, 6 Jan 2014 10:11:53 -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 D9A311AE068 for ; Mon, 6 Jan 2014 10:11:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=oGJAPp03mcMwmtLcbZRr3Xal0r4iPZ68CZEvatYflftzTDXKodMtr7ypmuMlrV5P; 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-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W0EeN-0006bt-C9; Mon, 06 Jan 2014 13:11:43 -0500 Received: from 76.254.54.255 by webmail.earthlink.net with HTTP; Mon, 6 Jan 2014 13:11:43 -0500 Message-ID: <7905973.1389031903240.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Mon, 6 Jan 2014 10:11:43 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbbfd863274eeeec9d4bc59db9476a2301350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 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: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 18:11:56 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Jan 6, 2014 6:22 AM >To: Randy Presuhn >Cc: David Kessens , netmod@ietf.org >Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) > >On Tue, Dec 10, 2013 at 02:12:09PM -0800, Randy Presuhn wrote: > >> 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. > >You can create an 'orphaned' (or better empty) group as well in the >Yang model if that is really useful. Since the group serves like a container for the members in the Yang model, I don't see how it's possible to "leave the 'members' in place" when deleting the group. It's not the empty group that's useful, but rather this: if one wants to be able to represent valid VACM configurations, then one must be able to represent configurations in which one or more "members" refer to a group which does not exist at the moment. If VACM has been configured with one or more users referring to groups that don't happen to exist at the moment, a fairly reasonable thing to do, the Yang/Netconf interface cannot represent that configuration. ... >> > > 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. > >But I assume SNMP had to be rather explicit about these things because >you would have to potentially deal with a sequence of write operations >in order to make a conceptual change. With NETCONF, you can execute >much bigger atomic changes that you would typically expect with SNMP. >But if your concern boils down to the following RFC 3415 text, then >we can add something similiar to the YANG I-D: > > When creating MIB views, it is strongly advised that > first the 'excluded' vacmViewTreeFamilyEntries are > created and then the 'included' entries. That's over-specifying things a bit. > When deleting MIB views, it is strongly advised that > first the 'included' vacmViewTreeFamilyEntries are > deleted and then the 'excluded' entries. That's also an over-specification. >(Well the last one is somewhat pointless since one would not have to >delete every 'row' in the include/exclude lists individually with >NETCONF.) > >> 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. > >Well it can't hurt to remind implementors that they need to ensure >that a transaction stays a transaction and does not fall apart due to >external events and it might be wise to remind them that failure to do >so may become a security issue. We can try to find some wording for >this. I think this, combined with your comments above, is a crucial point. There are operations, such as changing a user's group membership, that are simple atomic transactions in VACM, that the Yang/Netconf model could turn into TWO transactions in a naive implementation. Randy From ietfdbh@comcast.net Mon Jan 6 12:10:22 2014 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 241A31AE1E0 for ; Mon, 6 Jan 2014 12:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 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.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 q_9d4Jiaojpn for ; Mon, 6 Jan 2014 12:10:19 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id B993F1AE1DE for ; Mon, 6 Jan 2014 12:10:18 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta13.westchester.pa.mail.comcast.net with comcast id AcTb1n0021ZXKqc5DkAA1D; Mon, 06 Jan 2014 20:10:10 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta21.westchester.pa.mail.comcast.net with comcast id AkA91n00x2yZEBF3hkA9MT; Mon, 06 Jan 2014 20:10:10 +0000 From: "ietfdbh" To: "'Juergen Schoenwaelder'" References: <006b01cef53a$addd68c0$6b01a8c0@oemcomputer> <20131210202911.GA74654@elstar.local> <011501cef82e$80adf030$8209d090$@comcast.net> <011f01cef839$e8fb4a10$baf1de30$@comcast.net> <20140106135835.GB36685@elstar.local> In-Reply-To: <20140106135835.GB36685@elstar.local> Date: Mon, 6 Jan 2014 15:10:08 -0500 Message-ID: <015f01cf0b1b$4c540130$e4fc0390$@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/AAHA4XdZAa43BwUBZ8QSMQKLbqwXAqRdjmSbu7fY8A== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389039010; bh=cPXZqt2agKeqg2i2ayWVGiKXkcwPOXJO+BdYNY7qKRc=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=E4KhW+CYgBXgsxiRVwMuzvzPLDqQFqF8ZBeyj6Pz6heuZh6xvZv7+mhP64gItMZ/M rX7+Pp7CSnbM6tqUVkXaPEMJ9YnHFYHdqDFcK8LY4ULb5QJ8OqwmGe/eGh/XVYhY+1 aXpzcf1n2XtexQYTCVuKhcbWPBU85pvr+YFHaBXgZUeEt2d6rTr81lEhkvekldhXD3 1HozIlEF5HTe4fC0E/OfwqOnlfjz4v4iMPE3ORGGX/Y5glYyV2i4Ngvme4iD6vYbdY RJa7Qkp7RyGFGGohZ7eN//Aj1/fsYQ38mxk9kf1bdHBZJ2cHwlbTsgtLuJNS2EfuhS XA65DoucSfuXw== 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: Mon, 06 Jan 2014 20:10:22 -0000 Given that the goal of the IETF is to develop standards in support of interoperability, I am concerned about the interoperability between standards-compliant NMSs and SNMP MIBs configured using SNMP versus SNMP MIBs configured using the YANG modules. I am less concerned about the interoperability between standards-compliant NMSs and non-compliant implementations of SNMP MIBs. Will a relevant standard SNMP MIB implementation be compliant if the YANG module is used to do the configuration? Is it possible to configure an SNMP MIB using the YANG module (in a compliant manner) that would result in the implementation not being compliant to the MIB standard, whereas using SNMP (in a compliant manner) would result in the implementation being compliant? Put more simply, can using the YANG *cause* an implementation of the relevant MIB to be non-compliant to the MIB standard? David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Monday, January 06, 2014 8:59 AM > To: ietfdbh > Cc: netmod@ietf.org > Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) > > On Fri, Dec 13, 2013 at 02:31:24PM -0500, ietfdbh wrote: > > 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? > > > > I suggest you go through the mailing list archive. This data model has > been reviewed by people familiar with widely used SNMP code bases. I > do not think it is the task of the WG to determine to what extend SNMP > implementations are fully compliant to the relevant SNMP and MIB > standards. (Speaking as contributor.) > > /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 Jan 6 13:54:03 2014 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 114A21AE27A for ; Mon, 6 Jan 2014 13:54:03 -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 8YBnBSxjSpnC for ; Mon, 6 Jan 2014 13:54: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 0BF791AE1C1 for ; Mon, 6 Jan 2014 13:53:59 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id A3901240C175; Mon, 6 Jan 2014 22:53:50 +0100 (CET) Date: Mon, 06 Jan 2014 22:53:50 +0100 (CET) Message-Id: <20140106.225350.450926514.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <7905973.1389031903240.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <7905973.1389031903240.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] 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, 06 Jan 2014 21:54:03 -0000 Randy Presuhn wrote: > Hi - > > >From: Juergen Schoenwaelder > >Sent: Jan 6, 2014 6:22 AM > >To: Randy Presuhn > >Cc: David Kessens , netmod@ietf.org > >Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) > > > >On Tue, Dec 10, 2013 at 02:12:09PM -0800, Randy Presuhn wrote: > > > >> 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. > > > >You can create an 'orphaned' (or better empty) group as well in the > >Yang model if that is really useful. > > Since the group serves like a container for the members in > the Yang model, I don't see how it's possible to "leave > the 'members' in place" when deleting the group. It's > not the empty group that's useful, but rather this: if > one wants to be able to represent valid VACM configurations, > then one must be able to represent configurations in which > one or more "members" refer to a group which does not exist > at the moment. What do you mean by a "group which does not exist"? Maybe you can provide an example (MIB) configuration that is not possible to express in the YANG model? (assuming also that we remove the min-elements constraint from the "member" list). > If VACM has been configured with one or more users referring > to groups that don't happen to exist at the moment, a fairly > reasonable thing to do, the Yang/Netconf interface cannot > represent that configuration. If you mean an entry in vacmSecurityToGroupTable with a vacmGroupName that does not exist in vacmAccessTable, this is possible to express with the YANG model. /martin From randy_presuhn@mindspring.com Mon Jan 6 15:13:13 2014 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 8E7B91AE2CF for ; Mon, 6 Jan 2014 15:13:13 -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 bEEkivA6Bxmg for ; Mon, 6 Jan 2014 15:13:11 -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 5CE9D1AD8CD for ; Mon, 6 Jan 2014 15:13:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=s1+4AqZs2IGt5ucfdhxwNNPyEG0KQrhVzYrss9ENbAQ3NsSZJnMCic8s1lGRrAgB; 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.255] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W0JLx-0008Tv-NS for netmod@ietf.org; Mon, 06 Jan 2014 18:13:02 -0500 Message-ID: <008901cf0b35$3bb7b0a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <7905973.1389031903240.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> <20140106.225350.450926514.mbj@tail-f.com> Date: Mon, 6 Jan 2014 15:15:46 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbb7dcd95fb1801918effe7d3d73b2516e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.54.255 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, 06 Jan 2014 23:13:13 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Monday, January 06, 2014 1:53 PM > Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) ... > What do you mean by a "group which does not exist"? > > Maybe you can provide an example (MIB) configuration that is not > possible to express in the YANG model? (assuming also that we remove > the min-elements constraint from the "member" list). Sure. An instance of vacmGroupName with value "TBD", when no entry exists in vacmAccessTable with such a value. Note that this is explicitly permitted by the definitions of vacmGroupName. > > If VACM has been configured with one or more users referring > > to groups that don't happen to exist at the moment, a fairly > > reasonable thing to do, the Yang/Netconf interface cannot > > represent that configuration. > > If you mean an entry in vacmSecurityToGroupTable with a vacmGroupName > that does not exist in vacmAccessTable, this is possible to express > with the YANG model. Cool. I couldn't see how the Yang model would allow it, since the list "member" is contained by the list "group". Could you explain how one could create a "member" without creating the containing "group"? Randy From mbj@tail-f.com Mon Jan 6 23:13:15 2014 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 B38341AE45D for ; Mon, 6 Jan 2014 23:13:15 -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 1E_k6GXlgB3H for ; Mon, 6 Jan 2014 23:13:13 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B15E41ADFBD for ; Mon, 6 Jan 2014 23:13: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 099A5240C147; Tue, 7 Jan 2014 08:13:04 +0100 (CET) Date: Tue, 07 Jan 2014 08:13:03 +0100 (CET) Message-Id: <20140107.081303.1920544947906844357.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <008901cf0b35$3bb7b0a0$6b01a8c0@oemcomputer> References: <7905973.1389031903240.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> <20140106.225350.450926514.mbj@tail-f.com> <008901cf0b35$3bb7b0a0$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] 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, 07 Jan 2014 07:13:15 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Monday, January 06, 2014 1:53 PM > > Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) > ... > > What do you mean by a "group which does not exist"? > > > > Maybe you can provide an example (MIB) configuration that is not > > possible to express in the YANG model? (assuming also that we remove > > the min-elements constraint from the "member" list). > > Sure. An instance of vacmGroupName with value "TBD", > when no entry exists in vacmAccessTable with such a value. > Note that this is explicitly permitted by the definitions of > vacmGroupName. This is expressable, see below. > > > If VACM has been configured with one or more users referring > > > to groups that don't happen to exist at the moment, a fairly > > > reasonable thing to do, the Yang/Netconf interface cannot > > > represent that configuration. > > > > If you mean an entry in vacmSecurityToGroupTable with a vacmGroupName > > that does not exist in vacmAccessTable, this is possible to express > > with the YANG model. > > Cool. I couldn't see how the Yang model would allow it, since the > list "member" > is contained by the list "group". Could you explain how one could create > a "member" without creating the containing "group"? That's not what I wrote. Let's be concrete. vacmGroupName.3.3.b.o.b = TBD vacmGroupName.3.5.a.l.i.c.e = TBD can be represented as TBD alice usm bob usm /martin From randy_presuhn@mindspring.com Tue Jan 7 09:26:48 2014 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 BC0241AE07F for ; Tue, 7 Jan 2014 09:26: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 CgNTxRBvwE4V for ; Tue, 7 Jan 2014 09:26:46 -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 A40401ADF4B for ; Tue, 7 Jan 2014 09:26:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=etHcAT3Ka55KWbkxHeFYMecBMDVZVaUzOLQvkFF0jxzI7nvaljB+lefkprggXeaS; 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-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W0aQG-0006d5-Vn for netmod@ietf.org; Tue, 07 Jan 2014 12:26:36 -0500 Received: from 76.254.54.255 by webmail.earthlink.net with HTTP; Tue, 7 Jan 2014 12:26:36 -0500 Message-ID: <27502799.1389115596850.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Tue, 7 Jan 2014 09:26:36 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbb3ce7cef369ad97d5aaeaf88f8b4a0df350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 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: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 17:26:49 -0000 Hi - >From: Martin Bjorklund >Sent: Jan 6, 2014 11:13 PM >To: randy_presuhn@mindspring.com >Cc: netmod@ietf.org >Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) > >"Randy Presuhn" wrote: >> Hi - >> >> > From: "Martin Bjorklund" >> > To: >> > Cc: >> > Sent: Monday, January 06, 2014 1:53 PM >> > Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) >> ... >> > What do you mean by a "group which does not exist"? >> > >> > Maybe you can provide an example (MIB) configuration that is not >> > possible to express in the YANG model? (assuming also that we remove >> > the min-elements constraint from the "member" list). >> >> Sure. An instance of vacmGroupName with value "TBD", >> when no entry exists in vacmAccessTable with such a value. >> Note that this is explicitly permitted by the definitions of >> vacmGroupName. > >This is expressable, see below. > >> > > If VACM has been configured with one or more users referring >> > > to groups that don't happen to exist at the moment, a fairly >> > > reasonable thing to do, the Yang/Netconf interface cannot >> > > represent that configuration. >> > >> > If you mean an entry in vacmSecurityToGroupTable with a vacmGroupName >> > that does not exist in vacmAccessTable, this is possible to express >> > with the YANG model. >> >> Cool. I couldn't see how the Yang model would allow it, since the >> list "member" >> is contained by the list "group". Could you explain how one could create >> a "member" without creating the containing "group"? > >That's not what I wrote. Let's be concrete. > > vacmGroupName.3.3.b.o.b = TBD > vacmGroupName.3.5.a.l.i.c.e = TBD > >can be represented as > > > TBD > > alice > usm > > > bob > usm > > This is where's where you lose me. In the VACM model the group does not exist, but in the Yang model it does. Randy From mbj@tail-f.com Tue Jan 7 09:34:56 2014 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 232AC1AE04F for ; Tue, 7 Jan 2014 09:34:56 -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_25nZStGzJF for ; Tue, 7 Jan 2014 09:34:54 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF1B1AE04B for ; Tue, 7 Jan 2014 09:34:54 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 0B855240C1CB; Tue, 7 Jan 2014 18:34:44 +0100 (CET) Date: Tue, 07 Jan 2014 18:34:43 +0100 (CET) Message-Id: <20140107.183443.328999646.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <27502799.1389115596850.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <27502799.1389115596850.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] 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, 07 Jan 2014 17:34:56 -0000 Randy Presuhn wrote: > Hi - > > >From: Martin Bjorklund > >Sent: Jan 6, 2014 11:13 PM > >To: randy_presuhn@mindspring.com > >Cc: netmod@ietf.org > >Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) > > > >"Randy Presuhn" wrote: > >> Hi - > >> > >> > From: "Martin Bjorklund" > >> > To: > >> > Cc: > >> > Sent: Monday, January 06, 2014 1:53 PM > >> > Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) > >> ... > >> > What do you mean by a "group which does not exist"? > >> > > >> > Maybe you can provide an example (MIB) configuration that is not > >> > possible to express in the YANG model? (assuming also that we remove > >> > the min-elements constraint from the "member" list). > >> > >> Sure. An instance of vacmGroupName with value "TBD", > >> when no entry exists in vacmAccessTable with such a value. > >> Note that this is explicitly permitted by the definitions of > >> vacmGroupName. > > > >This is expressable, see below. > > > >> > > If VACM has been configured with one or more users referring > >> > > to groups that don't happen to exist at the moment, a fairly > >> > > reasonable thing to do, the Yang/Netconf interface cannot > >> > > represent that configuration. > >> > > >> > If you mean an entry in vacmSecurityToGroupTable with a vacmGroupName > >> > that does not exist in vacmAccessTable, this is possible to express > >> > with the YANG model. > >> > >> Cool. I couldn't see how the Yang model would allow it, since the > >> list "member" > >> is contained by the list "group". Could you explain how one could create > >> a "member" without creating the containing "group"? > > > >That's not what I wrote. Let's be concrete. > > > > vacmGroupName.3.3.b.o.b = TBD > > vacmGroupName.3.5.a.l.i.c.e = TBD > > > >can be represented as > > > > > > TBD > > > > alice > > usm > > > > > > bob > > usm > > > > > > This is where's where you lose me. In the VACM > model the group does not exist, but in the Yang model > it does. In VACM the group does not exist in vacmAccessTable, and in the YANG model there are no entries in the group/access list. So it is equivalent. BTW, 3415 says Within the View-Based Access Control Model, a groupName is considered to exist if that groupName is listed in the vacmSecurityToGroupTable. and A group is a set of zero or more tuples on whose behalf SNMP management objects can be accessed. A group defines the access rights afforded to all securityNames which belong to that group. The combination of a securityModel and a securityName maps to at most one group. A group is identified by a groupName. So it seems to me that the group TBD actually exists in this case even in VACM. /martin From randy_presuhn@mindspring.com Tue Jan 7 09:55:22 2014 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 5D4EE1AE078 for ; Tue, 7 Jan 2014 09:55:22 -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 ywqwdzI3CkDj for ; Tue, 7 Jan 2014 09:55:20 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 689D21AE077 for ; Tue, 7 Jan 2014 09:55:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=UWPxItg+q2CDI3J7hrLx1x5mc1+6oNJY36Gz9ioXK4rskzpjgOYKj69yfZygz8a0; 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-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W0arv-0004oK-8x for netmod@ietf.org; Tue, 07 Jan 2014 12:55:11 -0500 Received: from 76.254.54.255 by webmail.earthlink.net with HTTP; Tue, 7 Jan 2014 12:55:10 -0500 Message-ID: <4649698.1389117311297.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Tue, 7 Jan 2014 09:55:11 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbd006cd63bf420e1fb9460474c422725a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 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: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 17:55:22 -0000 Hi - >From: Martin Bjorklund >Sent: Jan 7, 2014 9:34 AM >To: randy_presuhn@mindspring.com >Cc: netmod@ietf.org >Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) > >Randy Presuhn wrote: >> Hi - >> >> >From: Martin Bjorklund >> >Sent: Jan 6, 2014 11:13 PM >> >To: randy_presuhn@mindspring.com >> >Cc: netmod@ietf.org >> >Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) >> > >> >"Randy Presuhn" wrote: >> >> Hi - >> >> >> >> > From: "Martin Bjorklund" >> >> > To: >> >> > Cc: >> >> > Sent: Monday, January 06, 2014 1:53 PM >> >> > Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220) >> >> ... >> >> > What do you mean by a "group which does not exist"? >> >> > >> >> > Maybe you can provide an example (MIB) configuration that is not >> >> > possible to express in the YANG model? (assuming also that we remove >> >> > the min-elements constraint from the "member" list). >> >> >> >> Sure. An instance of vacmGroupName with value "TBD", >> >> when no entry exists in vacmAccessTable with such a value. >> >> Note that this is explicitly permitted by the definitions of >> >> vacmGroupName. >> > >> >This is expressable, see below. >> > >> >> > > If VACM has been configured with one or more users referring >> >> > > to groups that don't happen to exist at the moment, a fairly >> >> > > reasonable thing to do, the Yang/Netconf interface cannot >> >> > > represent that configuration. >> >> > >> >> > If you mean an entry in vacmSecurityToGroupTable with a vacmGroupName >> >> > that does not exist in vacmAccessTable, this is possible to express >> >> > with the YANG model. >> >> >> >> Cool. I couldn't see how the Yang model would allow it, since the >> >> list "member" >> >> is contained by the list "group". Could you explain how one could create >> >> a "member" without creating the containing "group"? >> > >> >That's not what I wrote. Let's be concrete. >> > >> > vacmGroupName.3.3.b.o.b = TBD >> > vacmGroupName.3.5.a.l.i.c.e = TBD >> > >> >can be represented as >> > >> > >> > TBD >> > >> > alice >> > usm >> > >> > >> > bob >> > usm >> > >> > >> >> This is where's where you lose me. In the VACM >> model the group does not exist, but in the Yang model >> it does. > >In VACM the group does not exist in vacmAccessTable, and in the YANG >model there are no entries in the group/access list. So it is >equivalent. > >BTW, 3415 says > > Within the View-Based Access Control Model, a > groupName is considered to exist if that groupName is listed in the > vacmSecurityToGroupTable. > >and > > A group is a set of zero or more tuples > on whose behalf SNMP management objects can be accessed. A group > defines the access rights afforded to all securityNames which belong > to that group. The combination of a securityModel and a securityName > maps to at most one group. A group is identified by a groupName. > >So it seems to me that the group TBD actually exists in this case even >in VACM. > > >/martin That still seems like a badly twisted mapping to me, confusing a reference to an entity with the entity itself. Look at the indexing structure. But it's also clear that I'm the only one who thinks so. We're just repeating arguments that have already been made, so I don't think we're going to convince each other. I think the chairs will just have to declare (rough) consensus on the point and move on. Randy From lhotka@nic.cz Wed Jan 8 02:26:44 2014 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 E24EF1AE1D9 for ; Wed, 8 Jan 2014 02:26: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 anTJGzDPLpD5 for ; Wed, 8 Jan 2014 02:26:43 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id D5AEA1AE1D2 for ; Wed, 8 Jan 2014 02:26:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 852315405BE; Wed, 8 Jan 2014 11:26:32 +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 RNq-jlotkq97; Wed, 8 Jan 2014 11:26:26 +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 C3B34540193; Wed, 8 Jan 2014 11:26:22 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20131223185627.GC7170@elstar.local> References: <20131203151610.GB71692@elstar.local> <20131223185627.GC7170@elstar.local> User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Wed, 08 Jan 2014 11:26:21 +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: Wed, 08 Jan 2014 10:26:45 -0000 Hi, can we expect any more input on the current revision of the routing draft? If not, I will try to resolve all issues form Martin's review (yes, I think it can be done) and submit a new revision. Lada Juergen Schoenwaelder writes: > 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 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Jan 8 03:51:00 2014 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 555AC1AE357 for ; Wed, 8 Jan 2014 03:51:00 -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 j7rj8N3AGD2O for ; Wed, 8 Jan 2014 03:50:58 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE681AE354 for ; Wed, 8 Jan 2014 03:50:56 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39B072005C; Wed, 8 Jan 2014 12:50:47 +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 oYQfWyqynI_P; Wed, 8 Jan 2014 12:50:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE83A20046; Wed, 8 Jan 2014 12:50:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E741F2A7D399; Wed, 8 Jan 2014 12:50:42 +0100 (CET) Date: Wed, 8 Jan 2014 12:50:42 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140108115042.GA41996@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20131203151610.GB71692@elstar.local> <20131223185627.GC7170@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] 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: Wed, 08 Jan 2014 11:51:00 -0000 On Wed, Jan 08, 2014 at 11:26:21AM +0100, Ladislav Lhotka wrote: > Hi, > > can we expect any more input on the current revision of the routing draft? If not, I will try to resolve all issues form Martin's review (yes, I think it can be done) and submit a new revision. > I think you should resolve Martin's comments and post a new I-D and once Martin believes the issues have been resolved, I will hand this over to Benoit. If further reviews come in (even though the WG last call deadline has passed), we can still consider them IETF WG last call comments. I am not aware of anyone committed to provide additional reviews (even though I did notify the routing ADs - but perhaps things are being reviewed during IETF last call). /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 Wed Jan 8 03:54:40 2014 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 389A71AE35F for ; Wed, 8 Jan 2014 03:54:40 -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 aXSQ_IndytYS for ; Wed, 8 Jan 2014 03:54:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B3B2A1AE35E for ; Wed, 8 Jan 2014 03:54:37 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1C1D013F630; Wed, 8 Jan 2014 12:54:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1389182068; bh=LXm6qmDFeRT2Grcc3jTpjTuWl/i9vwl1mFJNjhCa/9Q=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UVptq4nVdtk55eYAwqK0HhOM3prVdIo8NkAV+xI4pH/ZF/uNAUdX4jq5EbWIAtMpj 1lZheuUMmu+AqEu4i6kA8o0GHq6XitW1GHE/EIzeZ+KY7pwEw/8PIWo2bGsB17q1R5 8w+NS94LAM4OmM3IEeoN55ypoDwZ9H5mngCrScUM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: <20140108115042.GA41996@elstar.local> Date: Wed, 8 Jan 2014 12:54:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <325E793E-2F58-4822-B071-8D2B35ADC3E9@nic.cz> References: <20131203151610.GB71692@elstar.local> <20131223185627.GC7170@elstar.local> <20140108115042.GA41996@elstar.local> To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= 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: Wed, 08 Jan 2014 11:54:40 -0000 On 08 Jan 2014, at 12:50, Juergen Schoenwaelder = wrote: > On Wed, Jan 08, 2014 at 11:26:21AM +0100, Ladislav Lhotka wrote: >> Hi, >>=20 >> can we expect any more input on the current revision of the routing = draft? If not, I will try to resolve all issues form Martin's review = (yes, I think it can be done) and submit a new revision. >>=20 >=20 > I think you should resolve Martin's comments and post a new I-D and > once Martin believes the issues have been resolved, I will hand this > over to Benoit. If further reviews come in (even though the WG last OK, will do. Lada > call deadline has passed), we can still consider them IETF WG last > call comments. I am not aware of anyone committed to provide > additional reviews (even though I did notify the routing ADs - but > perhaps things are being reviewed during IETF last call). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From iesg-secretary@ietf.org Wed Jan 8 05:58:00 2014 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 A46851AE3C1; Wed, 8 Jan 2014 05:58: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 C0KBKR6NtEMT; Wed, 8 Jan 2014 05:57:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 932E81AE394; Wed, 8 Jan 2014 05:57:59 -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.90.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140108135759.14194.68950.idtracker@ietfa.amsl.com> Date: Wed, 08 Jan 2014 05:57:59 -0800 Cc: netmod@ietf.org Subject: [netmod] Last Call: (A YANG Data Model for System 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: Wed, 08 Jan 2014 13:58:00 -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 System 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 2014-01-22. 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 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/ballot/ No IPR declarations have been submitted directly on this I-D. From jernej.tuljak@mg-soft.si Wed Jan 8 07:21:36 2014 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 15A4A1AE43C for ; Wed, 8 Jan 2014 07:21:36 -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 RZl41BdHjqvL for ; Wed, 8 Jan 2014 07:21:33 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3926C1AE41F for ; Wed, 8 Jan 2014 07:21:32 -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 s08FLM1G018519; Wed, 8 Jan 2014 16:21:23 +0100 Message-ID: <52CD6CF1.5010104@mg-soft.com> Date: Wed, 08 Jan 2014 16:21:21 +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: Ladislav Lhotka References: <20131203151610.GB71692@elstar.local> <20131223185627.GC7170@elstar.local> <20140108115042.GA41996@elstar.local> <325E793E-2F58-4822-B071-8D2B35ADC3E9@nic.cz> In-Reply-To: <325E793E-2F58-4822-B071-8D2B35ADC3E9@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Wed, 08 Jan 2014 15:21:36 -0000 Not sure if already reported or even if it still applies, but I think I might have found a bug in one of them must expressions. In ietf-routing module: /routing/routing-instance/routing-protocols/routing-protocol/connected-ribs/connected-rib/must[1] must "not(/routing/ribs/rib[name=current()/" + "preceding-sibling::connected-rib/" + "name and address-family=/routing/ribs/" + "rib[name=current()/name]/address-family])" There is no "//connected-rib/name" node. Perhaps it's a typo for "//connected-rib/rib-name" (appears twice in this expression!). Page 40 of the draft. Similar at /routing/ribs/recipient-ribs/recipient-rib/must (both must expressions). Page 42. Jernej Dne 8.1.2014 12:54, piše Ladislav Lhotka: > On 08 Jan 2014, at 12:50, Juergen Schoenwaelder wrote: > >> On Wed, Jan 08, 2014 at 11:26:21AM +0100, Ladislav Lhotka wrote: >>> Hi, >>> >>> can we expect any more input on the current revision of the routing draft? If not, I will try to resolve all issues form Martin's review (yes, I think it can be done) and submit a new revision. >>> >> I think you should resolve Martin's comments and post a new I-D and >> once Martin believes the issues have been resolved, I will hand this >> over to Benoit. If further reviews come in (even though the WG last > OK, will do. > > Lada > >> call deadline has passed), we can still consider them IETF WG last >> call comments. I am not aware of anyone committed to provide >> additional reviews (even though I did notify the routing ADs - but >> perhaps things are being reviewed during IETF last call). >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > -- > 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 Wed Jan 8 07:30:27 2014 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 694301AE4AF for ; Wed, 8 Jan 2014 07:30:27 -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 DR_9udT3QNER for ; Wed, 8 Jan 2014 07:30:25 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id B08801AE4AA for ; Wed, 8 Jan 2014 07:30:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id D1FFE5405BE; Wed, 8 Jan 2014 16:30:15 +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 K+Rtr39Ahr6T; Wed, 8 Jan 2014 16:30:11 +0100 (CET) Received: from [172.29.2.201] (unknown [172.29.2.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 8E193540208; Wed, 8 Jan 2014 16:30:07 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: <52CD6CF1.5010104@mg-soft.com> Date: Wed, 8 Jan 2014 16:30:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8BBB5F8A-D38D-4729-94EB-B826B7CFB8BD@nic.cz> References: <20131203151610.GB71692@elstar.local> <20131223185627.GC7170@elstar.local> <20140108115042.GA41996@elstar.local> <325E793E-2F58-4822-B071-8D2B35ADC3E9@nic.cz> <52CD6CF1.5010104@mg-soft.com> To: Jernej Tuljak X-Mailer: Apple Mail (2.1827) 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: Wed, 08 Jan 2014 15:30:27 -0000 Hi Jernej, yes, I=92ve already caught these bugs, they will be corrected in the = next revision. Thanks, Lada On 08 Jan 2014, at 16:21, Jernej Tuljak = wrote: > Not sure if already reported or even if it still applies, but I think = I might have found a bug in one of them must expressions. In = ietf-routing module: >=20 > = /routing/routing-instance/routing-protocols/routing-protocol/connected-rib= s/connected-rib/must[1] >=20 > must "not(/routing/ribs/rib[name=3Dcurrent()/" > + "preceding-sibling::connected-rib/" > + "name and address-family=3D/routing/ribs/" > + "rib[name=3Dcurrent()/name]/address-family])" >=20 > There is no "//connected-rib/name" node. Perhaps it's a typo for = "//connected-rib/rib-name" (appears twice in this expression!). Page 40 = of the draft. >=20 > Similar at >=20 > /routing/ribs/recipient-ribs/recipient-rib/must >=20 > (both must expressions). Page 42. >=20 > Jernej >=20 > Dne 8.1.2014 12:54, pi=9Ae Ladislav Lhotka: >> On 08 Jan 2014, at 12:50, Juergen Schoenwaelder = wrote: >>=20 >>> On Wed, Jan 08, 2014 at 11:26:21AM +0100, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> can we expect any more input on the current revision of the routing = draft? If not, I will try to resolve all issues form Martin's review = (yes, I think it can be done) and submit a new revision. >>>>=20 >>> I think you should resolve Martin's comments and post a new I-D and >>> once Martin believes the issues have been resolved, I will hand this >>> over to Benoit. If further reviews come in (even though the WG last >> OK, will do. >>=20 >> Lada >>=20 >>> call deadline has passed), we can still consider them IETF WG last >>> call comments. I am not aware of anyone committed to provide >>> additional reviews (even though I did notify the routing ADs - but >>> perhaps things are being reviewed during IETF last call). >>>=20 >>> /js >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bclaise@cisco.com Wed Jan 8 08:37:37 2014 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 726A51ADFA2; Wed, 8 Jan 2014 08:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.038 X-Spam-Level: X-Spam-Status: No, score=-15.038 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.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 0qNPuDoV9PZy; Wed, 8 Jan 2014 08:37:34 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id A18631ADF38; Wed, 8 Jan 2014 08:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14663; q=dns/txt; s=iport; t=1389199044; x=1390408644; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=6U/PsXVSETmYL7arIobnuTBRtQrJgHV2eOdSAL04grg=; b=LwKnvfoKckjvAc4zKQSphobltQPC41kwEGyf67/zj3oR38twYGbVH3oa x1U5iMXcOB+MYyLJf0dpaYBQqNDjIyFK1f9fx0bc0StKizg3kB0/P3URY VzP8RoCH2febRN7/tbfruCi2bt6h8mM+mDoKrZ+z8lwyYlKxH0SpgD6Ym Y=; X-IronPort-AV: E=Sophos;i="4.95,625,1384300800"; d="scan'208,217";a="37834655" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 08 Jan 2014 16:37:19 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s08GbHWS027175; Wed, 8 Jan 2014 16:37:18 GMT Message-ID: <52CD7EBD.4090506@cisco.com> Date: Wed, 08 Jan 2014 17:37:17 +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: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> In-Reply-To: <52A1ACEF.6080307@cisco.com> Content-Type: multipart/alternative; boundary="------------040502070305050605050600" Cc: SM , Paul Eggert , IETF-Discussion list , Eliot Lear Subject: Re: [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: Wed, 08 Jan 2014 16:37:37 -0000 This is a multi-part message in MIME format. --------------040502070305050605050600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Sadly, I have not seen a reply to this one. So let me start the discussion, copying both the ietf-discussion and the netmod WG mailers. See in-line. > 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. Not sure what you propose here. Proposed Standard seems right to me. From http://www.rfc-editor.org/RFCoverview.html RFC Categories Each RFC has a "category" or "status" designation. The possible categories (see *RFC 2026* "The Internet Standards Process -- Revision 3") are: * INTERNET STANDARD, DRAFT STANDARD (deprecated; see RFC 6410 ), PROPOSED STANDARD These are /Standards Track/ documents, official specifications of the Internet protocol suite defined by the Internet Engineering Task Force (IETF) and its steering group the IESG. * BEST CURRENT PRACTICE These are official guidelines and recommendations, but not standards, from the IETF. * INFORMATIONAL, EXPERIMENTAL These non-standards documents may originate in the IETF or may be independent submissions. * HISTORIC These are former standards that have been actively deprecated. > > 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. That makes sense. > > >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. Correct, but see BCP 175: Procedures for Maintaining the Time Zone Database: The TZ Coordinator is an IANA Designated Expert Are you questioning the term "IANA timezone database", which should be "TZ Database" according to BCP 175? > 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 think it does: http://www.iana.org/time-zones > 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. Well, we need to specify the system clock in the following YANG module (https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/), and hence we require a way to represent the TZ in YANG. Regards, Benoit > > Regards, > -sm > > . > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------040502070305050605050600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Sadly, I have not seen a reply to this one.
So let me start the discussion, copying both the ietf-discussion and the netmod WG mailers.
See in-line.
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.
Not sure what you propose here. Proposed Standard seems right to me.
From http://www.rfc-editor.org/RFCoverview.html

RFC Categories

Each RFC has a "category" or "status" designation. The possible categories (see RFC 2026 "The Internet Standards Process -- Revision 3") are:

  • INTERNET STANDARD, DRAFT STANDARD (deprecated; see RFC 6410), PROPOSED STANDARD

    These are Standards Track documents, official specifications of the Internet protocol suite defined by the Internet Engineering Task Force (IETF) and its steering group the IESG.

  • BEST CURRENT PRACTICE

    These are official guidelines and recommendations, but not standards, from the IETF.

  • INFORMATIONAL, EXPERIMENTAL

    These non-standards documents may originate in the IETF or may be independent submissions.

  • HISTORIC

    These are former standards that have been actively deprecated. 


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.
That makes sense.

>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.
Correct, but see BCP 175: Procedures for Maintaining the Time Zone Database:
 
   The TZ Coordinator is an IANA Designated Expert

Are you questioning the term "IANA timezone database", which should be "TZ Database" according to BCP 175?

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 think it does: http://www.iana.org/time-zones 
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.
Well, we need to specify the system clock in the following YANG module (https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/), and hence we require a way to represent the TZ in YANG.

Regards, Benoit

Regards,
-sm 

.






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

--------------040502070305050605050600-- From andy@yumaworks.com Wed Jan 8 09:09:32 2014 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 00E4F1ADFA0 for ; Wed, 8 Jan 2014 09:09:32 -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 CNxO86YN0Eqo for ; Wed, 8 Jan 2014 09:09:27 -0800 (PST) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id 275301AE049 for ; Wed, 8 Jan 2014 09:09:24 -0800 (PST) Received: by mail-qe0-f41.google.com with SMTP id gh4so2049607qeb.0 for ; Wed, 08 Jan 2014 09:09:14 -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=9RzXXPFNiyp35Y7J+A0ufHLetJh6OiDUcHNI1hAbuGY=; b=V7hR/fo4mmozSoup3P2W4KLvnQJP2Lf01wu2VpmjloUNV3rXzXAcIJXrShGO+NmwIf CpEGdJOpcF1oDsDKpnmLINakUBsmVWq7JyXyAeZMxUdIMTEJ0fojHpZaOmMkT1QALBxp /uIGBbJ9VDYzHSqClPLWmMPszi1Q0wvEwdtJ79JdDawausPLDV/HPoffaxq9neULMLKI 7WLrW4XX/dfIplNH3GleiVrRhY2yYLHyOYhqQd7T+l6OaSFu6r3HTM8ojQN5XrgvqmCs xWNGAu0j71LqGneOyoZh5Tf0lDlbiSuwJz+vX74jtqHAOYiK7eN2iaIrlUoioqCD/SAw rGCQ== X-Gm-Message-State: ALoCoQn6UphhNFFTqf9v9B8Ygi5tuHZVS6vhyWuomPWyos3RZs2jPSdpssNgHIpFZ750zSniZCSe MIME-Version: 1.0 X-Received: by 10.49.2.170 with SMTP id 10mr214464610qev.24.1389200954628; Wed, 08 Jan 2014 09:09:14 -0800 (PST) Received: by 10.140.48.75 with HTTP; Wed, 8 Jan 2014 09:09:14 -0800 (PST) In-Reply-To: <52CD7EBD.4090506@cisco.com> References: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com> Date: Wed, 8 Jan 2014 09:09:14 -0800 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=047d7b6da3d46c327e04ef788de1 Cc: SM , Paul Eggert , IETF-Discussion list , NETMOD Working Group Subject: Re: [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: Wed, 08 Jan 2014 17:09:32 -0000 --047d7b6da3d46c327e04ef788de1 Content-Type: text/plain; charset=ISO-8859-1 Hi, By "this one" I assume you mean the question "Why Proposed Standard?" This YANG module is meant to be imported by other standard YANG modules, which creates a normative reference in each importing RFC. We try to avoid standard modules that rely on non-standard modules. At first, (e.g, RFC 5277, RFC 5717) the YANG modules were not normative. But since 2010, (RFC 6020) all YANG modules are normative and XSD is no longer used. Andy On Wed, Jan 8, 2014 at 8:37 AM, Benoit Claise wrote: > Dear all, > > Sadly, I have not seen a reply to this one. > So let me start the discussion, copying both the ietf-discussion and the > netmod WG mailers. > See in-line. > > 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. > > Not sure what you propose here. Proposed Standard seems right to me. > From http://www.rfc-editor.org/RFCoverview.html > > RFC Categories > > Each RFC has a "category" or "status" designation. The possible categories > (see *RFC 2026* "The Internet > Standards Process -- Revision 3") are: > > - INTERNET STANDARD, DRAFT STANDARD (deprecated; see RFC 6410), > PROPOSED STANDARD > > These are *Standards Track* documents, official specifications of the > Internet protocol suite defined by the Internet Engineering Task Force > (IETF) and its steering group the IESG. > - BEST CURRENT PRACTICE > > These are official guidelines and recommendations, but not standards, > from the IETF. > - INFORMATIONAL, EXPERIMENTAL > > These non-standards documents may originate in the IETF or may be > independent submissions. > - HISTORIC > > These are former standards that have been actively deprecated. > > 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. > > That makes sense. > > >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. > > Correct, but see BCP 175: Procedures for Maintaining the Time Zone > Database: > > > The TZ Coordinator is an IANA Designated Expert > > Are you questioning the term "IANA timezone database", which should be "TZ Database" according to BCP 175? > > 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 think it does: http://www.iana.org/time-zones > > 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. > > Well, we need to specify the system clock in the following YANG module ( > https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/), and > hence we require a way to represent the TZ in YANG. > > Regards, Benoit > > Regards, > -sm > > . > > > > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > --047d7b6da3d46c327e04ef788de1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

By "this one" I assume yo= u mean the question "Why Proposed Standard?"

=
This YANG module is meant to be imported by other standard YANG module= s,
which creates a normative reference in each importing RFC. We try to a= void
standard modules that rely on non-standard modules. At first= , (e.g, RFC 5277,
RFC 5717) the YANG modules were not normative. = But since 2010,
(RFC 6020) all YANG modules are normative and XSD is no longer used.


Andy


O= n Wed, Jan 8, 2014 at 8:37 AM, Benoit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
Dear all,

Sadly, I have not seen a reply to this one.
So let me start the discussion, copying both the ietf-discussion and the netmod WG mailers.
See in-line.
=20 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 &= lt;sm@resistor.net>
To: <ie= tf@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 ma=
iling 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.
Not sure what you propose here. Proposed Standard seems right to me. From http://www.rfc-editor.org/RFCoverview.html

RFC Categories

Each RFC has a "category" or "status" designati= on. The possible categories (see RFC 2026 "The Internet Standards Process -- Revision 3= ") are:

  • INTERNET STANDARD, DRAFT STANDARD (deprecated; see RFC 6410), PROPOSED STANDARD

    These are Standards Track documents, official specifications of the Internet protocol suite defined by the Internet Engi= neering Task Force (IETF) and its steering group the IESG.

  • BEST CURRENT PRACTICE

    These are official guidelines and recommendations, but not standards, from the IETF.

  • INFORMATIONAL, EXPERIMENTAL

    These non-standards documents may originate in the IETF or may be independent submissions.

  • HISTORIC

    These are former standards that have been actively deprecated. 

The WGLC was from 5 July to 22 July.  There wasn't any com=
ments=20
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=20
to as the "Olson Database".  There isn't any mention of a &qu=
ot;IANA Time=20
Zone registry".  I suggest using the same name as in RFC 6557.
That makes sense.
>From Section 3:

  'The iana-timezones module is intended to reflect the IANA "time=
zone
   database" [RFC6557].  When a timezone location is added to the
   database, the "iana-timezone" enumeration MUST be updated as d=
efined
   in RFC 6020 Section 10 to add the newly created timezone location to
   the enumeration.  The new "enum" statement MUST be added to th=
e
   "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=20
Database.  The person does not work for IANA.
Correct, but see BCP 175: Procedures for Maintaining the Time Zone Database:
 
   The TZ Coordinator is an IANA Designated Expert

Are you questioning the term "IANA timezone database", which shou=
ld be "TZ Database" according to BCP 175?

I don't think that=20
IANA keeps track of the contents of the TZ Database as it was not=20
asked to do that work.
I think it does: http://www.iana.org/time-zones 
I don't see the value of using RFC 2119 key=20
word for the IANA Considerations.

I suggest not creating the registry proposed in this draft.  T=
he TZ=20
database has strived to keep out of political issues.  Adding such a=20
registry will pave the way for such issues.
Well, we need to specify the system clock in the following YANG module (https://datatracker.ietf.org/doc/draft-ietf-netmod-= system-mgmt/), and hence we require a way to represent the TZ in YANG.

Regards, Benoit
Regards,
-sm=20

.






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


--047d7b6da3d46c327e04ef788de1-- From bclaise@cisco.com Wed Jan 8 09:11:05 2014 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 437FC1ADF30 for ; Wed, 8 Jan 2014 09:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.838 X-Spam-Level: X-Spam-Status: No, score=-8.838 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.538, 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 DSipgpAOW1rd for ; Wed, 8 Jan 2014 09:11:02 -0800 (PST) Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3271AE4B5 for ; Wed, 8 Jan 2014 09:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21144; q=dns/txt; s=iport; t=1389201051; x=1390410651; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=PNns8ByU0XZJLgkAyRh8ZjV3dVPDyPkgdmTjMyTFuCw=; b=JEBJUtzeigpsUP9l3ZRMnH4+emma6QJf62P9Jv+uLRXbSCNGZSzIPT15 eRiReldOPDBnSU+psBSH+pou3/5OZRkH9q5A3rKIpCWhSXKfIHj0siYJ7 PaaEX5fub0JM4z7RENjYcD0M9jiQWs+DSwZ8d8/EEMRgQqFFk4eQSSVOL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAOSFzVJIo8UY/2dsb2JhbABZg0OJMbAIT4EqdIIlAQEBBAEBAWsKARALDgoJFg8JAwIBAgEVMAYNAQUCAQGIAA3EWhMEjwUHhDcEmBeGRYtQgy47gSwk X-IronPort-AV: E=Sophos;i="4.95,625,1384300800"; d="scan'208,217";a="7356223" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP; 08 Jan 2014 17:10:49 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s08HAlKh017770; Wed, 8 Jan 2014 17:10:48 GMT Message-ID: <52CD8697.6030809@cisco.com> Date: Wed, 08 Jan 2014 18:10:47 +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 References: <52A5F51E.2010705@cisco.com> <20131210.122630.261274424571283115.mbj@tail-f.com> <52A8975F.8050709@cisco.com> In-Reply-To: <52A8975F.8050709@cisco.com> Content-Type: multipart/alternative; boundary="------------070707070708090808000801" 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, 08 Jan 2014 17:11:06 -0000 This is a multi-part message in MIME format. --------------070707070708090808000801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Martin, Once I have a new draft version, I will progress the document through IETF LC. Regards, Benoit > 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 >> . >> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------070707070708090808000801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Martin,

Once I have a new draft version, I will progress the document through IETF LC.

Regards, Benoit
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
.



      

      

      

      

      

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


    

    

  


--------------070707070708090808000801--

From bclaise@cisco.com  Wed Jan  8 09:12:20 2014
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 74A6F1AE4B5 for ; Wed,  8 Jan 2014 09:12:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.038
X-Spam-Level: 
X-Spam-Status: No, score=-15.038 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.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 RduJO-VzX1hR for ; Wed,  8 Jan 2014 09:12:18 -0800 (PST)
Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 137721AE522 for ; Wed,  8 Jan 2014 09:12:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2862; q=dns/txt; s=iport; t=1389201127; x=1390410727; h=message-id:date:from:mime-version:to:subject; bh=lWpgTakZCukbW18MStmA9HkEDq25EDEEZYkOMJLe2T0=; b=gEs3sUo9xKuneunopfiazOcQ2Y1zE7wYd+UTBPS3AMeetrzh8MSm11N+ CAPOCt3gLOzMmT93o/0B3zbmpMIo6zKL8TuCnmplAuOV+/+8YEx6rN/8Q OxLMKPtuldKE4bRmTLd0d2c9gicnOK1RomN7NNP93aRwsdScYP1egiE5w Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqsEAJCGzVJIo8UY/2dsb2JhbABZg0OJMbBXgSp0gxoKIAEcFhgDAgECAUsNCAEBiAANmnKpahMEjwGEQgSYF4ZFi1CDLjs
X-IronPort-AV: E=Sophos;i="4.95,625,1384300800"; d="scan'208,217";a="37841058"
Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 08 Jan 2014 17:11:56 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s08HBtxZ001057 for ; Wed, 8 Jan 2014 17:11:56 GMT
Message-ID: <52CD86DB.6040107@cisco.com>
Date: Wed, 08 Jan 2014 18:11:55 +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 
Content-Type: multipart/alternative; boundary="------------020203010302080400040602"
Subject: [netmod] Documents on my plate: status
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, 08 Jan 2014 17:12:20 -0000

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

Dear all,

I have 5 netmod documents on my plate. Let me give you a status after 
this Christmas break:

draft-ietf-netmod-iana-if-type-09 

     On the IESG telechat tomorrow
     So far, so good: 
https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/ballot/

draft-ietf-netmod-interfaces-cfg-15 

     On the IESG telechat on Jan 23

draft-ietf-netmod-system-mgmt-10 

     in IETF LC till January 22nd

draft-ietf-netmod-ip-cfg-11 

     waiting for a revised ID

draft-ietf-netmod-iana-timezones-03 

     Still an open discussion on the IETF discuss mailing list

Regards, Benoit

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


  

    
  
  
    Dear all,

    

    I have 5 netmod documents on my plate. Let me give you a status
    after this Christmas break:

    

    draft-ietf-netmod-iana-if-type-09

        On the IESG telechat tomorrow

        So far, so good:
    https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/ballot/

    

    draft-ietf-netmod-interfaces-cfg-15

        On the IESG telechat on Jan 23

    

    draft-ietf-netmod-system-mgmt-10

        in IETF LC till January 22nd

    

    draft-ietf-netmod-ip-cfg-11

        waiting for a revised ID

    

    draft-ietf-netmod-iana-timezones-03

        Still an open discussion on the IETF discuss mailing list

    

    Regards, Benoit

  


--------------020203010302080400040602--

From internet-drafts@ietf.org  Wed Jan  8 13:21:32 2014
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 C735C1A1F5E; Wed,  8 Jan 2014 13:21:32 -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 KsRpwGrgMUPa; Wed,  8 Jan 2014 13:21:31 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC501A1F06; Wed,  8 Jan 2014 13:21:31 -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.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140108212131.9009.21755.idtracker@ietfa.amsl.com>
Date: Wed, 08 Jan 2014 13:21:31 -0800
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-12.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: Wed, 08 Jan 2014 21:21:33 -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 IP Management
        Author          : Martin Bjorklund
	Filename        : draft-ietf-netmod-ip-cfg-12.txt
	Pages           : 32
	Date            : 2014-01-08

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


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

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

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


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  Wed Jan  8 23:46:57 2014
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 F153F1AE119 for ; Wed,  8 Jan 2014 23:46:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.038
X-Spam-Level: 
X-Spam-Status: No, score=-15.038 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.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 U4Cz6d82EOBo for ; Wed,  8 Jan 2014 23:46:55 -0800 (PST)
Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 17E6C1ADF95 for ; Wed,  8 Jan 2014 23:46:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4301; q=dns/txt; s=iport; t=1389253606; x=1390463206; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=cdqwe7eOyiT1XOVGxLPXkNWaRslPzMMLG98AM7D+OcA=; b=e+Ue5yAOlmDIwpysznmmQIqkIiggjizQHSZ2sq71D5/e3/OB1gZSPtpO CSGMAX6MD/o9/hefX7XFM82WWm1fhqWvHkjYDuHToo08qAzkaIMyb6xS+ 8UfWgM7xDLddYaPS2w7R9FRSpY/9rvocCk3B5Qqpm2rfT5wGFBv7yRL0a U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqQEAJhSzlJIo8UY/2dsb2JhbABZg0OJMbAZT4EjdIIlAQEBBAEBAWsKEQsEFAkWDwkDAgECARUwBg0GAgEBiAANxG0TBI8MhDcEmBeGRYtQgy47
X-IronPort-AV: E=Sophos;i="4.95,629,1384300800"; d="scan'208,217";a="37851652"
Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 09 Jan 2014 07:46:44 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by bgl-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s097khwg020460 for ; Thu, 9 Jan 2014 07:46:44 GMT
Message-ID: <52CE53E3.9020101@cisco.com>
Date: Thu, 09 Jan 2014 08:46:43 +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: <52CD86DB.6040107@cisco.com>
In-Reply-To: <52CD86DB.6040107@cisco.com>
Content-Type: multipart/alternative; boundary="------------090405050508070107010900"
Subject: Re: [netmod] Documents on my plate: status
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, 09 Jan 2014 07:46:57 -0000

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

On 8/01/2014 18:11, Benoit Claise wrote:
> Dear all,
>
> I have 5 netmod documents on my plate. Let me give you a status after 
> this Christmas break:
>
> draft-ietf-netmod-iana-if-type-09 
> 
>     On the IESG telechat tomorrow
>     So far, so good: 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/ballot/
>
> draft-ietf-netmod-interfaces-cfg-15 
> 
>     On the IESG telechat on Jan 23
>
> draft-ietf-netmod-system-mgmt-10 
> 
>     in IETF LC till January 22nd
>
> draft-ietf-netmod-ip-cfg-11 
> 
>     waiting for a revised ID
Thanks to the new posted version, this one is now in "Last Call 
Requested" state.

Regards, Benoit
>
> draft-ietf-netmod-iana-timezones-03 
> 
>     Still an open discussion on the IETF discuss mailing list
>
> Regards, Benoit
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    
On 8/01/2014 18:11, Benoit Claise
      wrote:

    

    

      
      Dear all,

      

      I have 5 netmod documents on my plate. Let me give you a status
      after this Christmas break:

      

      draft-ietf-netmod-iana-if-type-09

          On the IESG telechat tomorrow

          So far, so good: https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/ballot/

      

      draft-ietf-netmod-interfaces-cfg-15

          On the IESG telechat on Jan 23

      

      draft-ietf-netmod-system-mgmt-10

          in IETF LC till January 22nd

      

      draft-ietf-netmod-ip-cfg-11

          waiting for a revised ID

    

    Thanks to the new posted version, this one is now in "Last Call
    Requested" state.

    

    Regards, Benoit

    
 

      draft-ietf-netmod-iana-timezones-03

          Still an open discussion on the IETF discuss mailing list

      

      Regards, Benoit

      

      

      

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


    

    

  


--------------090405050508070107010900--

From bclaise@cisco.com  Wed Jan  8 23:58:15 2014
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 BF61B1AE145; Wed,  8 Jan 2014 23:58:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.038
X-Spam-Level: 
X-Spam-Status: No, score=-10.038 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.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 U0F0_F-11_h7; Wed,  8 Jan 2014 23:58:12 -0800 (PST)
Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) by ietfa.amsl.com (Postfix) with ESMTP id 31B1C1AE143; Wed,  8 Jan 2014 23:58:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20061; q=dns/txt; s=iport; t=1389254282; x=1390463882; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=6WCVAPa3maq1sHtO/JJd0o4tWBakjf1u8JfDoCiN05w=; b=JhmffVA3gkKRm6uexBq8r7USywb7r5HX5+/4LMm3ntZUh38DgKjbfyph T67pacqKQEmbO2A6eGYRCFuX4PT/+aaYBFG29jOtjLzICJcevLy7WRToW r1ON87X1vL4SLEzD0WMBeO21gYziW5NsLN46h/gG0ZFFUD5vAj0+viKsL c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqUEAAVWzlJIo8UY/2dsb2JhbABZg0OJMbAZT4EjdIIlAQEBBAEBAWgDCgEMBAsRAwECAQkWBAQHCQMCAQIBFR8JCAYNAQUCAQEFh3sNxGkXjiMRAT8RBgEGA4QuBIVXhwSHWINkhkV7hR2FOIFvgT87gTU
X-IronPort-AV: E=Sophos;i="4.95,629,1384300800"; d="scan'208,217";a="3268602"
Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP; 09 Jan 2014 07:57:59 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s097vtdR014026; Thu, 9 Jan 2014 07:57:56 GMT
Message-ID: <52CE5683.5050907@cisco.com>
Date: Thu, 09 Jan 2014 08:57:55 +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: Andy Bierman 
References: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net>	<52A1ACEF.6080307@cisco.com>	<52CD7EBD.4090506@cisco.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------010505080609040308070900"
Cc: SM , Paul Eggert , IETF-Discussion list , NETMOD Working Group 
Subject: Re: [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: Thu, 09 Jan 2014 07:58:16 -0000

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

Hi Andy,
> Hi,
>
> By "this one" I assume you mean the question "Why Proposed Standard?"
I meant the other questions in this email, most importantly.
>
> This YANG module is meant to be imported by other standard YANG modules,
> which creates a normative reference in each importing RFC. We try to avoid
> standard modules that rely on non-standard modules. At first, (e.g, 
> RFC 5277,
> RFC 5717) the YANG modules were not normative. But since 2010,
> (RFC 6020) all YANG modules are normative and XSD is no longer used.
Thanks for your answer.

Regards, Benoit
>
>
> Andy
>
>
> On Wed, Jan 8, 2014 at 8:37 AM, Benoit Claise  > wrote:
>
>     Dear all,
>
>     Sadly, I have not seen a reply to this one.
>     So let me start the discussion, copying both the ietf-discussion
>     and the netmod WG mailers.
>     See in-line.
>>     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.
>     Not sure what you propose here. Proposed Standard seems right to me.
>     From http://www.rfc-editor.org/RFCoverview.html
>
>
>             RFC Categories
>
>         Each RFC has a "category" or "status" designation. The
>         possible categories (see *RFC 2026*
>          "The Internet
>         Standards Process -- Revision 3") are:
>
>           * INTERNET STANDARD, DRAFT STANDARD (deprecated; see RFC
>             6410 ),
>             PROPOSED STANDARD
>
>             These are /Standards Track/ documents, official
>             specifications of the Internet protocol suite defined by
>             the Internet Engineering Task Force (IETF)
>              and its steering group the IESG.
>
>           * BEST CURRENT PRACTICE
>
>             These are official guidelines and recommendations, but not
>             standards, from the IETF.
>
>           * INFORMATIONAL, EXPERIMENTAL
>
>             These non-standards documents may originate in the IETF or
>             may be independent submissions.
>
>           * HISTORIC
>
>             These are former standards that have been actively
>             deprecated.
>
>>     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.
>     That makes sense.
>>     >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.
>     Correct, but see BCP 175: Procedures for Maintaining the Time Zone
>     Database:
>     
>
>         The TZ Coordinator is an IANA Designated Expert
>
>     Are you questioning the term "IANA timezone database", which should be "TZ Database" according to BCP 175?
>
>>     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 think it does: http://www.iana.org/time-zones
>>     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.
>     Well, we need to specify the system clock in the following YANG
>     module
>     (https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/),
>     and hence we require a way to represent the TZ in YANG.
>
>     Regards, Benoit
>>     Regards,
>>     -sm
>>
>>     .
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     netmod mailing list
>>     netmod@ietf.org  
>>     https://www.ietf.org/mailman/listinfo/netmod
>
>


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


  
    
  
  
    
Hi Andy,

    

    

      
      
Hi,
        


        

        
By "this one" I assume you mean the question "Why Proposed
          Standard?"

      

    

    I meant the other questions in this email, most importantly.

    

      

        


        

        
This YANG module is meant to be imported by other standard
          YANG modules,

        
which creates a normative reference in each importing RFC.
          We try to avoid

        
standard modules that rely on non-standard modules. At
          first, (e.g, RFC 5277,

        
RFC 5717) the YANG modules were not normative. But since
          2010,

        
(RFC 6020) all YANG modules are normative and XSD is no
          longer used.

      

    

    Thanks for your answer.

    

    Regards, Benoit

    

      

        

          


            

            Andy

          


          

          


            
On Wed, Jan 8, 2014 at 8:37 AM,
              Benoit Claise <bclaise@cisco.com>
              wrote:

              

                

                  
Dear all,

                    

                    Sadly, I have not seen a reply to this one.

                    So let me start the discussion, copying both the
                    ietf-discussion and the netmod WG mailers.

                    See in-line.

                  

                  
 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.

                    

                  

                  Not sure what you propose here. Proposed Standard
                  seems right to me.

                  From http://www.rfc-editor.org/RFCoverview.html

                  

                    
RFC
                        Categories

                    
 Each RFC has a "category" or "status"
                      designation. The possible categories (see RFC 2026 "The
                      Internet Standards Process -- Revision 3") are: 

                    
    
                      
  •  INTERNET STANDARD, DRAFT STANDARD
                        (deprecated; see RFC 6410), PROPOSED
                        STANDARD
                        
     These are Standards Track documents,
                          official specifications of the Internet
                          protocol suite defined by the Internet
                            Engineering Task Force (IETF) and its
                          steering group the IESG. 
    
                      
    • 
                      
  •  BEST CURRENT PRACTICE
                        
     These are official guidelines and
                          recommendations, but not standards, from the
                          IETF. 
    
                      
    • 
                      
  •  INFORMATIONAL, EXPERIMENTAL
                        
     These non-standards documents may originate
                          in the IETF or may be independent submissions.
                        
    
                      
    • 
                      
  •  HISTORIC
                        
     These are former standards that have been
                          actively deprecated. 
    
                      
    • 
                    

                  

                  

                    

                      
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.

                    

                  

                  That makes sense.

                  

                    

                      
>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.  

                    

                  

                  Correct, but see BCP 175: Procedures for Maintaining
                    the Time Zone Database:

                  
                  
   The TZ Coordinator is an IANA Designated Expert

Are you questioning the term "IANA timezone database", which should be "TZ Database" according to BCP 175?


                  

                    

                      
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 think it does: http://www.iana.org/time-zones
                  

                    

                      
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.

                    

                  

                  Well, we need to specify the system clock in the
                  following YANG module (https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/),

                  and hence we require a way to represent the TZ in
                  YANG.

                  

                  Regards, Benoit

                  

                    

                      
Regards,
-sm 

.



                      

                    

                    

                    

                    

                    

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


                  

                  

                

              

            

            

          

        

      

    

    

  


--------------010505080609040308070900--

From sm@resistor.net  Thu Jan  9 02:19:22 2014
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 1FDD41AE231; Thu,  9 Jan 2014 02:19:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] 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 nBXfG4kOhoGa; Thu,  9 Jan 2014 02:19:20 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1B81AE1C7; Thu,  9 Jan 2014 02:19:20 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s09AIdLH022553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 02:18:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1389262726; bh=64uf2V4TqXeAJ+4mPGZXemkoysQgNQc3hmM8BS79Zc0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xM0T01d4iMmYP4bBzz1AOOC/nytuux2uzdkImFmW/G0N3yxhoWKl/fs49iGekRZ0W C6/yidH2hsBCXBqpVwJ0nLSwI0ViBfQwfSPysFT6FCnCk1VfxxxI/+7mj0u+Xqyrr2 HpE4GBcqyURISef8c3blbchX4SBM3xUg9a4VAy9A=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1389262726; i=@resistor.net; bh=64uf2V4TqXeAJ+4mPGZXemkoysQgNQc3hmM8BS79Zc0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ae+PJpVSgFCuhQblAJwn255CRJ7dzi8BpfSOjxzgI4kjh0xbb/jUocWxCv2L7OkI4 19QVpOaHiNnqCLcF6gNNyYCyAqFGiRcpFT0+tSyRAjju93sk9b+GQjRMkGlPFjlnn+ EY1gHj4qoF5PYDYz/f12ez1TksHBvbyO+bFbVEFA=
Message-Id: <6.2.5.6.2.20140108233958.0a849e58@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 09 Jan 2014 02:16:38 -0800
To: Benoit Claise , Andy Bierman 
From: SM 
In-Reply-To: <52CD7EBD.4090506@cisco.com> 
References: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com> <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Mailman-Approved-At: Thu, 09 Jan 2014 02:37:23 -0800
Cc: ietf@ietf.org, netmod@ietf.org
Subject: Re: [netmod] Fwd: Re: Last Call: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jan 2014 10:19:22 -0000

Hi Benoit, Andy,
At 08:37 08-01-2014, Benoit Claise wrote:
>Not sure what you propose here. Proposed Standard seems right to me.
> From http://www.rfc-editor.org/RFCoverview.html
>
>RFC Categories
>
>Each RFC has a "category" or "status" designation. The possible 
>categories (see RFC 2026 "The Internet Standards Process -- Revision 3") are:
>INTERNET STANDARD, DRAFT STANDARD (deprecated; see RFC 6410), 
>PROPOSED STANDARD
>
>These are Standards Track documents, official specifications of the 
>Internet protocol suite defined by the Internet Engineering Task 
>Force (IETF) and its steering group the IESG.
>BEST CURRENT PRACTICE
>
>These are official guidelines and recommendations, but not 
>standards, from the IETF.
>INFORMATIONAL, EXPERIMENTAL
>
>These non-standards documents may originate in the IETF or may be 
>independent submissions.
>HISTORIC
>
>These are former standards that have been actively deprecated.

At 09:09 08-01-2014, Andy Bierman wrote:
>By "this one" I assume you mean the question "Why Proposed Standard?"
>
>This YANG module is meant to be imported by other standard YANG modules,
>which creates a normative reference in each importing RFC. We try to avoid
>standard modules that rely on non-standard modules. At first, (e.g, RFC 5277,
>RFC 5717) the YANG modules were not normative. But since 2010,
>(RFC 6020) all YANG modules are normative and XSD is no longer used.

I included the comment from Andy Bierman above as it is also related 
to the document status.

If I understood the argument, it is that this YANG module would be 
referenced by other standard YANG modules and that is why the 
intended status is "Proposed Standard".  The argument from Benoit 
Claise is that the document is on the Standards Track as it is an 
official specification of the Internet protocol suite defined by the 
Internet Engineering Task Force.  I'll consider the question as 
addressed as the matter could be argued that way.

>>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.

According to the write-up, the "document has strong consensus".  In 
my opinion that determination is questionable.

>Correct, but see BCP 175: Procedures for Maintaining the Time Zone Database:
>
>    The TZ Coordinator is an IANA Designated Expert
>
>Are you questioning the term "IANA timezone database", which should 
>be "TZ Database" according to BCP 175?

I suggested using the same name as in RFC 6557.

TZ locations can be controversial every now and then.  There have 
been discussions about having a (TZ) location for an island inhabited 
by penguins. :-)   There have been arguments about changing a 
location as a matter of national pride.  There has been an attempt to 
take up a TZ mailing list disagreement with IANA.  IETF 
standardization of this information makes it look official and paves 
the way for governance questions.

>I think it does: http://www.iana.org/time-zones

What I meant was that IANA provides hosting services.  IANA does not 
track the changes.

>Well, we need to specify the system clock in the following YANG 
>module 
>(https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/), 
>and hence we require a way to represent the TZ in YANG.

Would it be possible to use "timezone-utc-offset" only and not have 
"timezone-location"?  RFC 5277 references RFC 3339 for time zones.

Regards,
-sm



From j.schoenwaelder@jacobs-university.de  Thu Jan  9 02:58:22 2014
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 8D9311AE135; Thu,  9 Jan 2014 02:58:22 -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 F_FiawAYF1aV; Thu,  9 Jan 2014 02:58: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 D4D1E1AE157; Thu,  9 Jan 2014 02:58:19 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F420D20075; Thu,  9 Jan 2014 11:58:09 +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 NRZ4WVpXzanz; Thu,  9 Jan 2014 11:58:09 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 082A520035; Thu,  9 Jan 2014 11:58:09 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 3E88D2A7F78C; Thu,  9 Jan 2014 11:58:06 +0100 (CET)
Date: Thu, 9 Jan 2014 11:58:05 +0100
From: Juergen Schoenwaelder 
To: SM 
Message-ID: <20140109105804.GA44893@elstar.local>
Mail-Followup-To: SM , Benoit Claise , Andy Bierman , ietf@ietf.org, netmod@ietf.org
References: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com> <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com>  <6.2.5.6.2.20140108233958.0a849e58@resistor.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6.2.5.6.2.20140108233958.0a849e58@resistor.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org, ietf@ietf.org
Subject: Re: [netmod] Fwd: Re: Last Call: 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jan 2014 10:58:22 -0000

On Thu, Jan 09, 2014 at 02:16:38AM -0800, SM wrote:
> 
> >>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.
> 
> According to the write-up, the "document has strong consensus".  In
> my opinion that determination is questionable.
> 

People want to be able to configure timezones using the timezone
naming scheme commonly supported by operating systems (e.g.,
Europe/Paris). This document defines a serialization of the timezone
names into YANG format for this purpose. I believe there was indeed
strong concensus on this in the WG.

> TZ locations can be controversial every now and then.  There have
> been discussions about having a (TZ) location for an island
> inhabited by penguins. :-)   There have been arguments about
> changing a location as a matter of national pride.  There has been
> an attempt to take up a TZ mailing list disagreement with IANA.
> IETF standardization of this information makes it look official and
> paves the way for governance questions.

This document aims at establishing an IANA maintained serialization of
whatever list of names the timezone database contains. It does not
change the way the TZ coordinator, an IANA Designated Expert, takes
decisions. Perhaps this needs to be stated more explicit.

So far (in the MIB world), the initial versions of IANA maintained
modules were published as Proposed Standards on the standards track
(although the only thing that really remains valid over time are the
IANA considerations, which however often require the initial module to
be available). We simply followed this practice.

> >Well, we need to specify the system clock in the following YANG
> >module
> >(https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/),
> >and hence we require a way to represent the TZ in YANG.
> 
> Would it be possible to use "timezone-utc-offset" only and not have
> "timezone-location"?  RFC 5277 references RFC 3339 for time zones.

There was concensus in the WG that it is desirable to configure
timezones by name (e.g., Europe/Paris) instead of having only hard
coded UTC offsets - the benefits should be obvious.

/js

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

From j.schoenwaelder@jacobs-university.de  Thu Jan  9 04:42:06 2014
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 AB3041AE247 for ; Thu,  9 Jan 2014 04:42:06 -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 sxBE_koHUyPt for ; Thu,  9 Jan 2014 04:42:05 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 961531AE0F7 for ; Thu,  9 Jan 2014 04:42:04 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD84D2007C; Thu,  9 Jan 2014 13:41:54 +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 PSgVCGJVOBAg; Thu,  9 Jan 2014 13:41:54 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 260F82007B; Thu,  9 Jan 2014 13:41:54 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 414662A7FB5E; Thu,  9 Jan 2014 13:41:50 +0100 (CET)
Date: Thu, 9 Jan 2014 13:41:49 +0100
From: Juergen Schoenwaelder 
To: Randy Presuhn 
Message-ID: <20140109124148.GA45136@elstar.local>
Mail-Followup-To: Randy Presuhn , netmod@ietf.org
References: <27502799.1389115596850.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: <27502799.1389115596850.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
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: Thu, 09 Jan 2014 12:42:07 -0000

On Tue, Jan 07, 2014 at 09:26:36AM -0800, Randy Presuhn wrote:
> Hi -
> 
> >From: Martin Bjorklund 
> >Sent: Jan 6, 2014 11:13 PM
> >To: randy_presuhn@mindspring.com
> >Cc: netmod@ietf.org
> >Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> >
> >"Randy Presuhn"  wrote:
> >> Hi -
> >> 
> >> > From: "Martin Bjorklund" 
> >> > To: 
> >> > Cc: 
> >> > Sent: Monday, January 06, 2014 1:53 PM
> >> > Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> >> ...
> >> > What do you mean by a "group which does not exist"?  
> >> > 
> >> > Maybe you can provide an example (MIB) configuration that is not
> >> > possible to express in the YANG model?  (assuming also that we remove
> >> > the min-elements constraint from the "member" list).
> >> 
> >> Sure.  An instance of  vacmGroupName with value "TBD",
> >> when no entry exists in vacmAccessTable with such a value.
> >> Note that this is explicitly permitted by the definitions of
> >> vacmGroupName.
> >
> >This is expressable, see below.
> >
> >> > > If VACM has been configured with one or more users referring
> >> > > to groups that don't happen to exist at the moment, a fairly
> >> > > reasonable thing to do, the Yang/Netconf interface cannot
> >> > > represent that configuration.
> >> > 
> >> > If you mean an entry in vacmSecurityToGroupTable with a vacmGroupName
> >> > that does not exist in vacmAccessTable, this is possible to express
> >> > with the YANG model.
> >> 
> >> Cool.  I couldn't see how the Yang model would allow it, since the
> >> list "member" 
> >> is contained by the list "group".  Could you explain how one could create
> >> a "member" without creating the containing "group"?
> >
> >That's not what I wrote.  Let's be concrete.
> >
> >  vacmGroupName.3.3.b.o.b = TBD
> >  vacmGroupName.3.5.a.l.i.c.e = TBD
> >
> >can be represented as
> >
> >  
> >    TBD
> >    
> >      alice
> >      usm
> >    
> >    
> >      bob
> >      usm
> >    
> >  
> 
> This is where's where you lose me.  In the VACM
> model the group does not exist, but in the Yang model
> it does.

But you can't delete vacmGroupName.3.3.b.o.b with SNMP either. Once
you assign a member to a group, it will always be associated with a
group. In other words, a member who does not belong to any group can
only exist as part of setting up group members, e.g. as part of
filling out a row. Yes, such incomplete entries may exist for a long
time if you activate the row in SNMP. Using the YANG interface, you
can't create them. If we were to change the YANG model to allow this,
we would likely end up with a mechanism to unassign members from any
groups, which I think is not possible using VACM. :-{

/js

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

From j.schoenwaelder@jacobs-university.de  Thu Jan  9 05:05:46 2014
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 93BEA1AE2AC for ; Thu,  9 Jan 2014 05:05:46 -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 r6RhNq8mXx1h for ; Thu,  9 Jan 2014 05:05:44 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6970D1AE1C7 for ; Thu,  9 Jan 2014 05:05:44 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE7AF2007B; Thu,  9 Jan 2014 14:05:34 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OVmjyBlgo9-J; Thu,  9 Jan 2014 14:05:34 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A9A520050; Thu,  9 Jan 2014 14:05:34 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 1F4C12A7FBFB; Thu,  9 Jan 2014 14:05:32 +0100 (CET)
Date: Thu, 9 Jan 2014 14:05:32 +0100
From: Juergen Schoenwaelder 
To: ietfdbh 
Message-ID: <20140109130532.GB45136@elstar.local>
Mail-Followup-To: ietfdbh , netmod@ietf.org
References:  <006b01cef53a$addd68c0$6b01a8c0@oemcomputer> <20131210202911.GA74654@elstar.local> <011501cef82e$80adf030$8209d090$@comcast.net> <011f01cef839$e8fb4a10$baf1de30$@comcast.net> <20140106135835.GB36685@elstar.local> <015f01cf0b1b$4c540130$e4fc0390$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <015f01cf0b1b$4c540130$e4fc0390$@comcast.net>
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: Thu, 09 Jan 2014 13:05:46 -0000

On Mon, Jan 06, 2014 at 03:10:08PM -0500, ietfdbh wrote:
> 
> Will a relevant standard SNMP MIB implementation be compliant if the
> YANG module is used to do the configuration?

This is fairly abstract and general question. For me, an SNMP MIB
implementation will be compliant if it complies to the SNMP MIBs it
implements. Most SNMP agents I have seen read configurations from CLIs
and/or configuration files. Hence, I believe it is possible to have
other configuration interfaces. I also believe they are being used to
setup SNMP agents. (Frankly, I never configured VACM using the SNMP
tables - I always resorted to configuration files or CLIs. But then
this might have just been my lack of having access to smart software
to do this job for me. ;-)

> Is it possible to configure an SNMP MIB using the YANG module (in a
> compliant manner) that would result in the implementation not being
> compliant to the MIB standard, whereas using SNMP (in a compliant manner)
> would result in the implementation being compliant?
> Put more simply, can using the YANG *cause* an implementation of the
> relevant MIB to be non-compliant to the MIB standard?

We are trying hard to ensure that this interworks nicely. If there are
any things that may cause problems that we might have missed, by all
means let us know so that we can take a look at it. For example, we
might have to say something about spin locks to handle situations
where a sequence of SNMP set operations in interleaved with NETCONF
updates. This is very useful input and appreciated.

The goal of this effort is to provide implementors with a YANG SNMP
configuration interface that to the best of our knowledge does not
cause conflicts with the implementation of SNMP configuration MIB
modules and I believe the IETF is the best place to do this work. The
alternative of doing this work is to let every NETCONF implementor
come up with his/her own model that may but various undocumented
constraints on the SNMP interface - I do not think this helps with
SNMP interoperability (and it surely does not help with NETCONF
interoperability either).

So please, tell us about any technical issues we might have missed.
This helps us much more than abstract discussions.

/js

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

From iesg-secretary@ietf.org  Thu Jan  9 06:29:49 2014
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 392161AE351; Thu,  9 Jan 2014 06:29: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 6Q7MMh2AVlx6; Thu,  9 Jan 2014 06:29:47 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D68181AE07F; Thu,  9 Jan 2014 06:29:47 -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.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20140109142947.16194.98784.idtracker@ietfa.amsl.com>
Date: Thu, 09 Jan 2014 06:29:47 -0800
Cc: netmod@ietf.org
Subject: [netmod] Last Call:  (A YANG Data Model for IP 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: Thu, 09 Jan 2014 14:29:49 -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 IP 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 2014-01-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 management of IP
   implementations.  The data model includes configuration data and
   state data.




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

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


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



From sm@resistor.net  Thu Jan  9 09:17:11 2014
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 04D981AE432; Thu,  9 Jan 2014 09:17:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] 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 ZJahfGxCz8IR; Thu,  9 Jan 2014 09:17:09 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFA51AE446; Thu,  9 Jan 2014 09:17:09 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s09HGO5l013101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jan 2014 09:16:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1389287796; bh=x87d+bJQ38QI3fFzdenRbWaPzPHdfjF9omleGbo3iXE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=k3OgvhVVwsZ/vl6DtETu70cnGXFj5h9R8XHVpB+yuzciC7EBUSUbaf8Vks3jyageS VT8DNKfeaweWuZiKOPDEseFEGF+awVgMs178BTJ7RMihX9pbCYwyiZTxvFNhj6ifv+ 4AmAhINJ54dvNmhNy2kifq6p8H8r88ZpvAM6gqAg=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1389287796; i=@resistor.net; bh=x87d+bJQ38QI3fFzdenRbWaPzPHdfjF9omleGbo3iXE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Juk0lAKcmM0LsogZAHYfBGl6I+8FywQvP2ZHkCrmWcGn5M0aD548A8Nu38dB7t6sK lk+XFFmFvUFC3iK8BnJppvXMpPwWO9GtabqDD6ySn3Ehyalq/mQ8ZG9DiVHsfAvo6W 3wmoNyoeQffg184F5/cYaJrIvby6sJVRgGmFvX/Q=
Message-Id: <6.2.5.6.2.20140109051548.0a951040@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 09 Jan 2014 07:47:46 -0800
To: Juergen Schoenwaelder 
From: SM 
In-Reply-To: <20140109105804.GA44893@elstar.local>
References: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com> <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com>  <6.2.5.6.2.20140108233958.0a849e58@resistor.net> <20140109105804.GA44893@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: netmod@ietf.org, ietf@ietf.org
Subject: Re: [netmod] Fwd: Re: Last Call: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jan 2014 17:17:11 -0000

Hi Juergen,
At 02:58 09-01-2014, Juergen Schoenwaelder wrote:
>People want to be able to configure timezones using the timezone
>naming scheme commonly supported by operating systems (e.g.,
>Europe/Paris). This document defines a serialization of the timezone
>names into YANG format for this purpose. I believe there was indeed
>strong concensus on this in the WG.

There was a message about a quick poll [1] to adopt 
draft-lange-netmod-iana-timezones-01 on 2 July, 2012.  Three persons 
expressed their support and the WG Chair expressed his support as a 
technical contributor [2]; there weren't any message objecting to 
adoption.  There were two comments [3][4] on 30 July, 2012.  There 
was a WG Last Call announcement [5] and two reminders [6][7] about 
it. There was a message [8] on 12 November, 2013 from a WG 
participant (I am not taking into account the message from the author 
and one of the WG Chairs).  My comment about the determination of 
consensus being questionable is based on the messages in the NETMOD 
mailing list archive.

>This document aims at establishing an IANA maintained serialization of
>whatever list of names the timezone database contains. It does not
>change the way the TZ coordinator, an IANA Designated Expert, takes
>decisions. Perhaps this needs to be stated more explicit.

There is a thread at 
http://mm.icann.org/pipermail/tz/2012-May/017711.html  The problem is 
not changing the way things are done.  I would describe the current 
TZ approach as keeping the TZ information up-to-date by posting a 
(software) release every now and then.  It works for me.

>So far (in the MIB world), the initial versions of IANA maintained
>modules were published as Proposed Standards on the standards track
>(although the only thing that really remains valid over time are the
>IANA considerations, which however often require the initial module to
>be available). We simply followed this practice.

If I understood correctly the YANG module defined in the draft 
creates IANA-registered timezones based on public domain [9] 
information about timezones.  IANA is then asked to keep the 
IANA-registered timezones up-to-date.  That sounds okay if the 
politics about time are not taken into consideration [10][11][12].

>There was concensus in the WG that it is desirable to configure
>timezones by name (e.g., Europe/Paris) instead of having only hard
>coded UTC offsets - the benefits should be obvious.

I agree that there can be benefits to that approach.  I could not 
find the (mailing list) message where that WG decision was taken.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/netmod/current/msg06810.html
2. http://www.ietf.org/mail-archive/web/netmod/current/msg06841.html
3. http://www.ietf.org/mail-archive/web/netmod/current/msg06932.html
4. http://www.ietf.org/mail-archive/web/netmod/current/msg06933.html
5. http://www.ietf.org/mail-archive/web/netmod/current/msg08327.html
6. http://www.ietf.org/mail-archive/web/netmod/current/msg08333.html
7. http://www.ietf.org/mail-archive/web/netmod/current/msg08335.html
8. http://www.ietf.org/mail-archive/web/netmod/current/msg08694.html
9. ftp://ftp.iana.org/tz/tz-link.html
10. 
http://www.theguardian.com/news/datablog/2013/sep/26/spain-countries-wrong-time-zone
11. http://972mag.com/the-worlds-only-ethnic-time-zone/81006/
12. 
http://www.theblaze.com/stories/2013/09/22/just-wait-until-you-see-how-apples-new-operating-system-lists-jerusalem/ 


From andy@yumaworks.com  Thu Jan  9 11:05:29 2014
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 EEBF61AE323 for ; Thu,  9 Jan 2014 11:05: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=unavailable
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 JRh8PP3DtMKq for ; Thu,  9 Jan 2014 11:05:26 -0800 (PST)
Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFA21AE454 for ; Thu,  9 Jan 2014 11:05:23 -0800 (PST)
Received: by mail-qe0-f52.google.com with SMTP id ne12so3535670qeb.39 for ; Thu, 09 Jan 2014 11:05:13 -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=9jqPM8SiHHWIyMZcwRJkrKbpOakxR7MFy9C5p092R/8=; b=T7YYJJIJYGvCK2wcr/ZHXP94y0THkfhzx+a1mGn9kDrWDZQWTaBU0SfHtcdB+q9JUt 0eJJx78SSNRR0aAqqoj1xIsM7F9Y7y9zzkAjIWCx660a7BEkphmopM0UTx4/Cr9ASqZ/ /H2ZAf/+v5ccO8SmE8KJIHJcPm+uetT9oDSY7TphXFAla/1yDy5yZpz5Q3kAtLlKMqIt Tte9StZh9uzn7dL99VmcJwzzhASBye8K5Q1hDow/2MBrjYi1shjqjFlWcNxOWJ/ZHHgo mZePYkygc2zZtBFiXgra9g9SSlw0VkRmq056BjskAc4bwzF4yS08g0vavCDD0mBzn8fF dPSg==
X-Gm-Message-State: ALoCoQme0ID/XMFhvyVU3DprD+p+JYOidnL/IsOhXGMM0kPFpcP9iFcopmMBc5D3a1F9aXLVS2kk
MIME-Version: 1.0
X-Received: by 10.49.84.105 with SMTP id x9mr10557787qey.65.1389294313332; Thu, 09 Jan 2014 11:05:13 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 9 Jan 2014 11:05:13 -0800 (PST)
In-Reply-To: <6.2.5.6.2.20140109051548.0a951040@resistor.net>
References: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com>  <6.2.5.6.2.20140108233958.0a849e58@resistor.net> <20140109105804.GA44893@elstar.local> <6.2.5.6.2.20140109051548.0a951040@resistor.net>
Date: Thu, 9 Jan 2014 11:05:13 -0800
Message-ID: 
From: Andy Bierman 
To: SM 
Content-Type: multipart/alternative; boundary=047d7bdc0ef00910c904ef8e4a86
Cc: IETF discussion list , "netmod@ietf.org" 
Subject: Re: [netmod] Fwd: Re: Last Call: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jan 2014 19:05:29 -0000

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

Hi,

On Thu, Jan 9, 2014 at 7:47 AM, SM  wrote:

> Hi Juergen,
> At 02:58 09-01-2014, Juergen Schoenwaelder wrote:
>
>> People want to be able to configure timezones using the timezone
>> naming scheme commonly supported by operating systems (e.g.,
>> Europe/Paris). This document defines a serialization of the timezone
>> names into YANG format for this purpose. I believe there was indeed
>> strong concensus on this in the WG.
>>
>
> There was a message about a quick poll [1] to adopt
> draft-lange-netmod-iana-timezones-01 on 2 July, 2012.  Three persons
> expressed their support and the WG Chair expressed his support as a
> technical contributor [2]; there weren't any message objecting to adoption.
>  There were two comments [3][4] on 30 July, 2012.  There was a WG Last Call
> announcement [5] and two reminders [6][7] about it. There was a message [8]
> on 12 November, 2013 from a WG participant (I am not taking into account
> the message from the author and one of the WG Chairs).  My comment about
> the determination of consensus being questionable is based on the messages
> in the NETMOD mailing list archive.
>
>  This document aims at establishing an IANA maintained serialization of
>> whatever list of names the timezone database contains. It does not
>> change the way the TZ coordinator, an IANA Designated Expert, takes
>> decisions. Perhaps this needs to be stated more explicit.
>>
>
> There is a thread at http://mm.icann.org/pipermail/tz/2012-May/017711.html The problem is not changing the way things are done.  I would describe the
> current TZ approach as keeping the TZ information up-to-date by posting a
> (software) release every now and then.  It works for me.
>
>  So far (in the MIB world), the initial versions of IANA maintained
>> modules were published as Proposed Standards on the standards track
>> (although the only thing that really remains valid over time are the
>> IANA considerations, which however often require the initial module to
>> be available). We simply followed this practice.
>>
>
> If I understood correctly the YANG module defined in the draft creates
> IANA-registered timezones based on public domain [9] information about
> timezones.  IANA is then asked to keep the IANA-registered timezones
> up-to-date.  That sounds okay if the politics about time are not taken into
> consideration [10][11][12].
>
>  There was concensus in the WG that it is desirable to configure
>> timezones by name (e.g., Europe/Paris) instead of having only hard
>> coded UTC offsets - the benefits should be obvious.
>>
>
> I agree that there can be benefits to that approach.  I could not find the
> (mailing list) message where that WG decision was taken.
>
>
After reading the IANA Considerations section closer, I have some concerns
about the use of a YANG enumeration. This section does not say who must
update the enumeration typedef and republish the RFC containing the new
YANG module, every time the TZ database is changed.
Is it the NETMOD WG? IANA?

This may not be a practical long-term solution.
The purpose of a YANG enumeration type is to allow a well-constrained
value set that can be machine-validated.  If the data type was a string
instead of an enumeration, there would be no IANA coupling or republishing
(or YANG-based machine validation). The description-stmt can say a leaf
using this data type MUST match a value in the TZ database.

The draft (sec. 3.1) also says to change the status of the old enum to
obsolete
and add a new enum, in order to change the name.  YANG definitions are
supposed to transition from current to deprecated, not current to obsolete.



> Regards,
> -sm
>


Andy


>
> 1. http://www.ietf.org/mail-archive/web/netmod/current/msg06810.html
> 2. http://www.ietf.org/mail-archive/web/netmod/current/msg06841.html
> 3. http://www.ietf.org/mail-archive/web/netmod/current/msg06932.html
> 4. http://www.ietf.org/mail-archive/web/netmod/current/msg06933.html
> 5. http://www.ietf.org/mail-archive/web/netmod/current/msg08327.html
> 6. http://www.ietf.org/mail-archive/web/netmod/current/msg08333.html
> 7. http://www.ietf.org/mail-archive/web/netmod/current/msg08335.html
> 8. http://www.ietf.org/mail-archive/web/netmod/current/msg08694.html
> 9. ftp://ftp.iana.org/tz/tz-link.html
> 10. http://www.theguardian.com/news/datablog/2013/sep/26/
> spain-countries-wrong-time-zone
> 11. http://972mag.com/the-worlds-only-ethnic-time-zone/81006/
> 12. http://www.theblaze.com/stories/2013/09/22/just-wait-
> until-you-see-how-apples-new-operating-system-lists-jerusalem/
>

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


Hi,

On Thu, Jan 9, 2014 at 7:47 AM, SM <sm@resistor.net> wr=
ote:

Hi Juergen,

At 02:58 09-01-2014, Juergen Schoenwaelder wrote:



People want to be able to configure timezones using the timezone

naming scheme commonly supported by operating systems (e.g.,

Europe/Paris). This document defines a serialization of the timezone

names into YANG format for this purpose. I believe there was indeed

strong concensus on this in the WG.





There was a message about a quick poll [1] to adopt draft-lange-netmod-iana=
-timezones-01 on 2 July, 2012. =A0Three persons expressed their supp=
ort and the WG Chair expressed his support as a technical contributor [2]; =
there weren't any message objecting to adoption. =A0There were two comm=
ents [3][4] on 30 July, 2012. =A0There was a WG Last Call announcement [5] =
and two reminders [6][7] about it. There was a message [8] on 12 November, =
2013 from a WG participant (I am not taking into account the message from t=
he author and one of the WG Chairs). =A0My comment about the determination =
of consensus being questionable is based on the messages in the NETMOD mail=
ing list archive.






This document aims at establishing an IANA maintained serialization of

whatever list of names the timezone database contains. It does not

change the way the TZ coordinator, an IANA Designated Expert, takes

decisions. Perhaps this needs to be stated more explicit.





There is a thread at http://mm.icann.org/pipermail/tz/2012-=
May/017711.html =A0The problem is not changing the way things are done.=
 =A0I would describe the current TZ approach as keeping the TZ information =
up-to-date by posting a (software) release every now and then. =A0It works =
for me.






So far (in the MIB world), the initial versions of IANA maintained

modules were published as Proposed Standards on the standards track

(although the only thing that really remains valid over time are the

IANA considerations, which however often require the initial module to

be available). We simply followed this practice.





If I understood correctly the YANG module defined in the draft creates IANA=
-registered timezones based on public domain [9] information about timezone=
s. =A0IANA is then asked to keep the IANA-registered timezones up-to-date. =
=A0That sounds okay if the politics about time are not taken into considera=
tion [10][11][12].






There was concensus in the WG that it is desirable to configure

timezones by name (e.g., Europe/Paris) instead of having only hard

coded UTC offsets - the benefits should be obvious.





I agree that there can be benefits to that approach. =A0I could not find th=
e (mailing list) message where that WG decision was taken.



After reading the IANA Considerations =
section closer, I have some concerns
about the use of a YANG enum=
eration. This section does not say who must
update the enumeratio=
n typedef and republish the RFC containing the new


YANG module, every time the TZ database is changed.
Is it th=
e NETMOD WG? IANA?

This may not be a practical lon=
g-term solution.
The purpose of a YANG enumeration type is to all=
ow a well-constrained


value set that can be machine-validated. =A0If the data type was a str=
ing
instead of an enumeration, there would be no IANA coupling or=
 republishing
(or YANG-based machine validation). The description=
-stmt can say a leaf


using this data type MUST match a value in the TZ database.
=

The draft (sec. 3.1) also says to change the status of the o=
ld enum to obsolete
and add a new enum, in order to change the na=
me. =A0YANG definitions are


supposed to transition from current to deprecated, not current to obso=
lete.

=A0

Regards,

-sm


Andy
=A0



1. http://www.ietf.org/mail-archive/web/netmod/=
current/msg06810.html

2. http://www.ietf.org/mail-archive/web/netmod/=
current/msg06841.html

3. http://www.ietf.org/mail-archive/web/netmod/=
current/msg06932.html

4. http://www.ietf.org/mail-archive/web/netmod/=
current/msg06933.html

5. http://www.ietf.org/mail-archive/web/netmod/=
current/msg08327.html

6. http://www.ietf.org/mail-archive/web/netmod/=
current/msg08333.html

7. http://www.ietf.org/mail-archive/web/netmod/=
current/msg08335.html

8. http://www.ietf.org/mail-archive/web/netmod/=
current/msg08694.html

9. ftp://f=
tp.iana.org/tz/tz-link.html

10. http://www.theguardian.com/<=
/u>news/datablog/2013/sep/26/spain-countries-wrong-time-zone<=
/a>


11. http://972mag.com/the-worlds-only-ethnic-time-zone/=
81006/

12. =
http://www.theblaze.com/stories/2013/09/22/just-wait-until-yo=
u-see-how-apples-new-operating-system-lists-jerusalem/ 





--047d7bdc0ef00910c904ef8e4a86--

From mbj@tail-f.com  Thu Jan  9 13:51:42 2014
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 BAF0B1AE0C0; Thu,  9 Jan 2014 13:51:42 -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 rPf8Py69DHUY; Thu,  9 Jan 2014 13:51: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 EC8181A1F66; Thu,  9 Jan 2014 13:51:40 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 3ACC5240C289; Thu,  9 Jan 2014 22:51:30 +0100 (CET)
Date: Thu, 09 Jan 2014 22:51:29 +0100 (CET)
Message-Id: <20140109.225129.336419021.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <20140109105804.GA44893@elstar.local> <6.2.5.6.2.20140109051548.0a951040@resistor.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: sm@resistor.net, ietf@ietf.org, netmod@ietf.org
Subject: Re: [netmod] Fwd: Re: Last Call: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jan 2014 21:51:42 -0000

Andy Bierman  wrote:
> Hi,
> 
> On Thu, Jan 9, 2014 at 7:47 AM, SM  wrote:
> 
> > Hi Juergen,
> > At 02:58 09-01-2014, Juergen Schoenwaelder wrote:
> >
> >> People want to be able to configure timezones using the timezone
> >> naming scheme commonly supported by operating systems (e.g.,
> >> Europe/Paris). This document defines a serialization of the timezone
> >> names into YANG format for this purpose. I believe there was indeed
> >> strong concensus on this in the WG.
> >>
> >
> > There was a message about a quick poll [1] to adopt
> > draft-lange-netmod-iana-timezones-01 on 2 July, 2012.  Three persons
> > expressed their support and the WG Chair expressed his support as a
> > technical contributor [2]; there weren't any message objecting to adoption.
> >  There were two comments [3][4] on 30 July, 2012.  There was a WG Last Call
> > announcement [5] and two reminders [6][7] about it. There was a message [8]
> > on 12 November, 2013 from a WG participant (I am not taking into account
> > the message from the author and one of the WG Chairs).  My comment about
> > the determination of consensus being questionable is based on the messages
> > in the NETMOD mailing list archive.
> >
> >  This document aims at establishing an IANA maintained serialization of
> >> whatever list of names the timezone database contains. It does not
> >> change the way the TZ coordinator, an IANA Designated Expert, takes
> >> decisions. Perhaps this needs to be stated more explicit.
> >>
> >
> > There is a thread at http://mm.icann.org/pipermail/tz/2012-May/017711.html
> > The problem is not changing the way things are done.  I would describe the
> > current TZ approach as keeping the TZ information up-to-date by posting a
> > (software) release every now and then.  It works for me.
> >
> >  So far (in the MIB world), the initial versions of IANA maintained
> >> modules were published as Proposed Standards on the standards track
> >> (although the only thing that really remains valid over time are the
> >> IANA considerations, which however often require the initial module to
> >> be available). We simply followed this practice.
> >>
> >
> > If I understood correctly the YANG module defined in the draft creates
> > IANA-registered timezones based on public domain [9] information about
> > timezones.  IANA is then asked to keep the IANA-registered timezones
> > up-to-date.  That sounds okay if the politics about time are not taken into
> > consideration [10][11][12].

Yes.  The idea is to extract the names from the published TZ database
and list them in a YANG module.  Nothing more.  Entries cannot be
added directly to the YANG module; they will always just mirror what's
in the TZ database.

> >  There was concensus in the WG that it is desirable to configure
> >> timezones by name (e.g., Europe/Paris) instead of having only hard
> >> coded UTC offsets - the benefits should be obvious.
> >>
> >
> > I agree that there can be benefits to that approach.  I could not find the
> > (mailing list) message where that WG decision was taken.
> >
> >
> After reading the IANA Considerations section closer, I have some concerns
> about the use of a YANG enumeration. This section does not say who must
> update the enumeration typedef and republish the RFC containing the new
> YANG module, every time the TZ database is changed.
> Is it the NETMOD WG? IANA?

I think it is clear that the intention is that is IANA.  But of course
it could be clarified.  Maybe it should even say that it is the
responsibility of the TZ Coordinator.  However, this must presumably
be verified with him first.

> This may not be a practical long-term solution.
> The purpose of a YANG enumeration type is to allow a well-constrained
> value set that can be machine-validated.  If the data type was a string
> instead of an enumeration, there would be no IANA coupling or republishing
> (or YANG-based machine validation). The description-stmt can say a leaf
> using this data type MUST match a value in the TZ database.

If it is not feasible to maintain a YANG "mirror" of the timezone
names from the TZ database, then I guess we can use a string.  I
prefer the formal enumeration though.

> The draft (sec. 3.1) also says to change the status of the old enum to
> obsolete
> and add a new enum, in order to change the name.  YANG definitions are
> supposed to transition from current to deprecated, not current to obsolete.

RFC 6020, section 10, explicitly allows a definition to go from
current to obsolete:

   o  A "status" statement may be added, or changed from "current" to
      "deprecated" or "obsolete", or from "deprecated" to "obsolete".


/martin

From randy_presuhn@mindspring.com  Thu Jan  9 16:45:43 2014
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 721DC1ADBE8 for ; Thu,  9 Jan 2014 16:45:43 -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 45vv7JntS525 for ; Thu,  9 Jan 2014 16:45:41 -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 379D81ADA74 for ; Thu,  9 Jan 2014 16:45:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=g9pPwppwTNl+1xSkQz1NvyYsxSwjz7gKXdw3/bR+WwZdYRXRHgbm6hgF74DA1d56; 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.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W1QE6-0004Yi-Ur for netmod@ietf.org; Thu, 09 Jan 2014 19:45:30 -0500
Received: from 99.23.161.2 by webmail.earthlink.net with HTTP; Thu, 9 Jan 2014 19:45:30 -0500
Message-ID: <7127897.1389314730956.JavaMail.root@mswamui-andean.atl.sa.earthlink.net>
Date: Thu, 9 Jan 2014 16:45:30 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbeb462319c19345d2172fca3c6b982f27350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.24
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: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jan 2014 00:45:43 -0000

Hi -

>From: Juergen Schoenwaelder 
>Sent: Jan 9, 2014 4:41 AM
>To: Randy Presuhn 
>Cc: netmod@ietf.org
>Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
>
>On Tue, Jan 07, 2014 at 09:26:36AM -0800, Randy Presuhn wrote:
>> Hi -
>> 
>> >From: Martin Bjorklund 
>> >Sent: Jan 6, 2014 11:13 PM
>> >To: randy_presuhn@mindspring.com
>> >Cc: netmod@ietf.org
>> >Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
>> >
>> >"Randy Presuhn"  wrote:
>> >> Hi -
>> >> 
>> >> > From: "Martin Bjorklund" 
>> >> > To: 
>> >> > Cc: 
>> >> > Sent: Monday, January 06, 2014 1:53 PM
>> >> > Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
>> >> ...
>> >> > What do you mean by a "group which does not exist"?  
>> >> > 
>> >> > Maybe you can provide an example (MIB) configuration that is not
>> >> > possible to express in the YANG model?  (assuming also that we remove
>> >> > the min-elements constraint from the "member" list).
>> >> 
>> >> Sure.  An instance of  vacmGroupName with value "TBD",
>> >> when no entry exists in vacmAccessTable with such a value.
>> >> Note that this is explicitly permitted by the definitions of
>> >> vacmGroupName.
>> >
>> >This is expressable, see below.
>> >
>> >> > > If VACM has been configured with one or more users referring
>> >> > > to groups that don't happen to exist at the moment, a fairly
>> >> > > reasonable thing to do, the Yang/Netconf interface cannot
>> >> > > represent that configuration.
>> >> > 
>> >> > If you mean an entry in vacmSecurityToGroupTable with a vacmGroupName
>> >> > that does not exist in vacmAccessTable, this is possible to express
>> >> > with the YANG model.
>> >> 
>> >> Cool.  I couldn't see how the Yang model would allow it, since the
>> >> list "member" 
>> >> is contained by the list "group".  Could you explain how one could create
>> >> a "member" without creating the containing "group"?
>> >
>> >That's not what I wrote.  Let's be concrete.
>> >
>> >  vacmGroupName.3.3.b.o.b = TBD
>> >  vacmGroupName.3.5.a.l.i.c.e = TBD
>> >
>> >can be represented as
>> >
>> >  
>> >    TBD
>> >    
>> >      alice
>> >      usm
>> >    
>> >    
>> >      bob
>> >      usm
>> >    
>> >  
>> 
>> This is where's where you lose me.  In the VACM
>> model the group does not exist, but in the Yang model
>> it does.
>
>But you can't delete vacmGroupName.3.3.b.o.b with SNMP either.

Yes you can, but that's irrelevant.  It's only a reference
to the group.  The vacmGroupName is an index of vacmAccessEntry.
That's where the group "exists".  We've already gone through
the argument about the ASI return codes.

>Once
>you assign a member to a group, it will always be associated with a
>group.

No.  It always *references* a group, which may or may not
actually exist.

> In other words, a member who does not belong to any group can
>only exist as part of setting up group members, e.g. as part of
>filling out a row. Yes, such incomplete entries may exist for a long
>time if you activate the row in SNMP. Using the YANG interface, you
>can't create them. If we were to change the YANG model to allow this,
>we would likely end up with a mechanism to unassign members from any
>groups, which I think is not possible using VACM. :-{

That's a consequence of the decision to model what in SNMP
is a reference with containment in Yang.  I think it's an
unfortunate decision, but it's clear I'm the lone dissenter.

I really don't see any point in continuing this thread.
The arguments have been repeated multiple times, and it's
obvious that no one is convincing anyone.

Randy

From internet-drafts@ietf.org  Fri Jan 10 05:30:18 2014
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 F23E01ADFB4; Fri, 10 Jan 2014 05:30: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 CdgpynwE5wAj; Fri, 10 Jan 2014 05:30:16 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9991ADF33; Fri, 10 Jan 2014 05:30:16 -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.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140110133016.24678.42711.idtracker@ietfa.amsl.com>
Date: Fri, 10 Jan 2014 05:30:16 -0800
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.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: Fri, 10 Jan 2014 13:30:18 -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 Routing Management
        Author          : Ladislav Lhotka
	Filename        : draft-ietf-netmod-routing-cfg-13.txt
	Pages           : 95
	Date            : 2014-01-10

Abstract:
   This document contains a specification of three YANG modules.
   Together they form the core routing data model which serves as a
   framework for configuring and managing a routing subsystem.  It is
   expected that these modules will be augmented by additional YANG
   modules defining data models for individual routing protocols and
   other related functions.  The core routing data model provides common
   building blocks for such extensions - routing instances, routes,
   routing information bases (RIB), routing protocols and route filters.


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

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

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


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 lhotka@nic.cz  Fri Jan 10 05:38:20 2014
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 A72A61ADFB4 for ; Fri, 10 Jan 2014 05:38:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.189
X-Spam-Level: 
X-Spam-Status: No, score=-1.189 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.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 6nH38AmCccgU for ; Fri, 10 Jan 2014 05:38:19 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C5F291ADFBC for ; Fri, 10 Jan 2014 05:38:18 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 720A513F697 for ; Fri, 10 Jan 2014 14:38:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1389361088; bh=svdbB6Pk/Q077T4T6eIWPF5NrPzadabBwbnF+rsKoLY=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=EA+UMIU05WUFmBiraHoUpXlM4X0fKJwnrbwgn734nESZBSuVXIPccO8mmXz2pV7d+ zsobd3FrvVy8BHFuf2J/hH+3fCt4UP0iG5b+ozNiSbeoyK42bPOXNCE+3k9yxpvRFA Krd97Zx1OsxDF0KEbOqf+Up8PoQBEeEXz6wHdLek=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Fri, 10 Jan 2014 14:38:03 +0100
References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com>
To: netmod@ietf.org
Message-Id: <32377793-C511-4F40-9C55-5E6A6B27969E@nic.cz>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Subject: [netmod] Fwd:  I-D Action: draft-ietf-netmod-routing-cfg-13.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: Fri, 10 Jan 2014 13:38:20 -0000

Hi,

changes in this revision mainly resulted from Martin=92s review, I =
believe all his comments were addressed.

Appendix B is new, it describes a minimum implementation of the core =
routing data model.

Lada=20

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-13.txt
> Date: 10 Jan 2014 14:30:16 GMT+1
> To: i-d-announce@ietf.org
> Cc: netmod@ietf.org
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the NETCONF Data Modeling Language =
Working Group of the IETF.
>=20
>        Title           : A YANG Data Model for Routing Management
>        Author          : Ladislav Lhotka
> 	Filename        : draft-ietf-netmod-routing-cfg-13.txt
> 	Pages           : 95
> 	Date            : 2014-01-10
>=20
> Abstract:
>   This document contains a specification of three YANG modules.
>   Together they form the core routing data model which serves as a
>   framework for configuring and managing a routing subsystem.  It is
>   expected that these modules will be augmented by additional YANG
>   modules defining data models for individual routing protocols and
>   other related functions.  The core routing data model provides =
common
>   building blocks for such extensions - routing instances, routes,
>   routing information bases (RIB), routing protocols and route =
filters.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-13
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-13
>=20
>=20
> 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.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=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 Jan 10 06:31:41 2014
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 E7BA11AE061 for ; Fri, 10 Jan 2014 06:31:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.189
X-Spam-Level: 
X-Spam-Status: No, score=-1.189 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.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 tX6lrFMmmXrm for ; Fri, 10 Jan 2014 06:31:40 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D513F1AE064 for ; Fri, 10 Jan 2014 06:31:39 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3509D13FA79 for ; Fri, 10 Jan 2014 15:31:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1389364289; bh=jgGomrIuAZEGzxxxf5tieULSgSDqLNxarit0l+oZVpU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=wWya9VOWEwyZm+doqnX6VBi0D6YXPLMmiD7PtCxVdkEH9h2+sws6gaMzmKJbpPNgw ZZ5SuLDipRW9Sr3nBzUKXDOSkcPCQZ/I6qEcnGgdGNK5YbSnDj3MObUoj3a+pabcmW 6sNwXy5yNyFu24liE/7uKJ/+kbPtYMck/2PCiKJ8=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <52CFFC73.3010002@mg-soft.com>
Date: Fri, 10 Jan 2014 15:31:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <44569F32-FD79-473A-90AF-71542E8D1714@nic.cz>
References: <20140110133233.926097FC394@rfc-editor.org> <20140110.144038.1958728126349068530.mbj@tail-f.com> <52CFFC73.3010002@mg-soft.com>
To: netmod@ietf.org
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Subject: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 10 Jan 2014 14:31:42 -0000

On 10 Jan 2014, at 14:58, Jernej Tuljak  =
wrote:

> If this is true, then it is RFC6020 that needs a clarification on =
this. Namely, that the "special character" which follows a backslash =
need not be special and that it does not represent an escape sequence in =
such a case.
>=20
>   Within a double-quoted string (enclosed within " "), a backslash
>   character introduces a special character, which depends on the
>   character that immediately follows the backslash:
>=20
>    \n      new line
>    \t      a tab character
>    \"      a double quote
>    \\      a single backslash
>=20
> My reading is that a backslash starts a YANG escape sequence and may =
therefore be removed during string dequoting. A "\*" ends up as *, which =
is not equivalent to '\*=92.

In XSD regular expressions, which are also used by YANG, it is an error =
if a backslash plus something is not defined as an escape sequence. So I =
think YANG should behave the same for double-quoted string, i.e. a =
backslash followed by something else than the four characters listed =
above should be flagged as an error (=93illegal escape=94).

Lada

>=20
> Please move this discussion over to NETMOD it that's the case.
>=20
> Jernej
>=20
> Dne 10.1.2014 14:40, pi=9Ae Martin Bjorklund:
>> Hi,
>>=20
>> This errata should be rejected.  "\*" is equvalent to '\*'.  \* in a
>> double quoted string is not an escape sequence, which means that the
>> characters are interpreted literally, i.e. the two characters \
>> followed by *.
>>=20
>> The same goes for errata 3863.
>>=20
>> /martin
>>=20
>> RFC Errata System  wrote:
>>> The following errata report has been submitted for RFC6536,
>>> "Network Configuration Protocol (NETCONF) Access Control Model".
>>>=20
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6536&eid=3D3862
>>>=20
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Jernej Tuljak 
>>>=20
>>> Section: 3.5.2.
>>>=20
>>> Original Text
>>> -------------
>>>      typedef matchall-string-type {
>>>        type string {
>>>          pattern "\*";
>>>        }
>>>        description
>>>          "The string containing a single asterisk '*' is used
>>>           to conceptually represent all possible values
>>>           for the particular leaf using this data type.";
>>>      }
>>>=20
>>> Corrected Text
>>> --------------
>>>      typedef matchall-string-type {
>>>        type string {
>>>          pattern '\*';
>>>        }
>>>        description
>>>          "The string containing a single asterisk '*' is used
>>>           to conceptually represent all possible values
>>>           for the particular leaf using this data type.";
>>>      }
>>>=20
>>> Notes
>>> -----
>>> As per RFC6020, Section 6.1.3., a backslash within a double-quoted
>>> string introduces a special character. The only valid escape =
sequences
>>> inside a double-quoted YANG string are: \n, \t, \" and \. As \* is =
not
>>> a valid escape sequence, a single quoted string should be used to
>>> specify the offending pattern statement's argument. The quotes could
>>> also be omitted.
>>>=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
>>> --------------------------------------
>>> RFC6536 (draft-ietf-netconf-access-control-07)
>>> --------------------------------------
>>> Title : Network Configuration Protocol (NETCONF) Access Control =
Model
>>> Publication Date    : March 2012
>>> Author(s)           : A. Bierman, M. Bjorklund
>>> Category            : PROPOSED STANDARD
>>> Source              : Network Configuration
>>> Area                : Operations and Management
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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





From jernej.tuljak@mg-soft.si  Fri Jan 10 07:02:04 2014
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 154B71AE07F for ; Fri, 10 Jan 2014 07:02:04 -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 B-n5eZgn1TQC for ; Fri, 10 Jan 2014 07:02:02 -0800 (PST)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id D32771AE0A1 for ; Fri, 10 Jan 2014 07:02:01 -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 s0AF1oHd009809; Fri, 10 Jan 2014 16:01:50 +0100
Message-ID: <52D00B5C.9070909@mg-soft.com>
Date: Fri, 10 Jan 2014 16:01:48 +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: Ladislav Lhotka 
References: <20140110133233.926097FC394@rfc-editor.org> <20140110.144038.1958728126349068530.mbj@tail-f.com> <52CFFC73.3010002@mg-soft.com> <44569F32-FD79-473A-90AF-71542E8D1714@nic.cz>
In-Reply-To: <44569F32-FD79-473A-90AF-71542E8D1714@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 10 Jan 2014 15:02:04 -0000

I've read that section a couple of times now and I now agree with Martin 
that "\*" is currently equivalent to '\*'. My reading would probably be 
correct if there was no second comma in the text I quoted. Oh, well...

    Within a double-quoted string (enclosed within " "), a backslash
    character may introduce a special character, which depends on the
    character that immediately follows the backslash:

would be better, no?

Jernej

Dne 10.1.2014 15:31, piše Ladislav Lhotka:
> On 10 Jan 2014, at 14:58, Jernej Tuljak  wrote:
>
>> If this is true, then it is RFC6020 that needs a clarification on this. Namely, that the "special character" which follows a backslash need not be special and that it does not represent an escape sequence in such a case.
>>
>>    Within a double-quoted string (enclosed within " "), a backslash
>>    character introduces a special character, which depends on the
>>    character that immediately follows the backslash:
>>
>>     \n      new line
>>     \t      a tab character
>>     \"      a double quote
>>     \\      a single backslash
>>
>> My reading is that a backslash starts a YANG escape sequence and may therefore be removed during string dequoting. A "\*" ends up as *, which is not equivalent to '\*’.
> In XSD regular expressions, which are also used by YANG, it is an error if a backslash plus something is not defined as an escape sequence. So I think YANG should behave the same for double-quoted string, i.e. a backslash followed by something else than the four characters listed above should be flagged as an error (“illegal escape”).
>
> Lada
>
>> Please move this discussion over to NETMOD it that's the case.
>>
>> Jernej
>>
>> Dne 10.1.2014 14:40, piše Martin Bjorklund:
>>> Hi,
>>>
>>> This errata should be rejected.  "\*" is equvalent to '\*'.  \* in a
>>> double quoted string is not an escape sequence, which means that the
>>> characters are interpreted literally, i.e. the two characters \
>>> followed by *.
>>>
>>> The same goes for errata 3863.
>>>
>>> /martin
>>>
>>> RFC Errata System  wrote:
>>>> The following errata report has been submitted for RFC6536,
>>>> "Network Configuration Protocol (NETCONF) Access Control Model".
>>>>
>>>> --------------------------------------
>>>> You may review the report below and at:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=6536&eid=3862
>>>>
>>>> --------------------------------------
>>>> Type: Technical
>>>> Reported by: Jernej Tuljak 
>>>>
>>>> Section: 3.5.2.
>>>>
>>>> Original Text
>>>> -------------
>>>>       typedef matchall-string-type {
>>>>         type string {
>>>>           pattern "\*";
>>>>         }
>>>>         description
>>>>           "The string containing a single asterisk '*' is used
>>>>            to conceptually represent all possible values
>>>>            for the particular leaf using this data type.";
>>>>       }
>>>>
>>>> Corrected Text
>>>> --------------
>>>>       typedef matchall-string-type {
>>>>         type string {
>>>>           pattern '\*';
>>>>         }
>>>>         description
>>>>           "The string containing a single asterisk '*' is used
>>>>            to conceptually represent all possible values
>>>>            for the particular leaf using this data type.";
>>>>       }
>>>>
>>>> Notes
>>>> -----
>>>> As per RFC6020, Section 6.1.3., a backslash within a double-quoted
>>>> string introduces a special character. The only valid escape sequences
>>>> inside a double-quoted YANG string are: \n, \t, \" and \. As \* is not
>>>> a valid escape sequence, a single quoted string should be used to
>>>> specify the offending pattern statement's argument. The quotes could
>>>> also be omitted.
>>>>
>>>> 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.
>>>>
>>>> --------------------------------------
>>>> RFC6536 (draft-ietf-netconf-access-control-07)
>>>> --------------------------------------
>>>> Title : Network Configuration Protocol (NETCONF) Access Control Model
>>>> Publication Date    : March 2012
>>>> Author(s)           : A. Bierman, M. Bjorklund
>>>> Category            : PROPOSED STANDARD
>>>> Source              : Network Configuration
>>>> Area                : Operations and Management
>>>> Stream              : IETF
>>>> Verifying Party     : IESG
>>>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
> --
> 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 Jan 10 07:16:46 2014
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 4C0D11AE087 for ; Fri, 10 Jan 2014 07:16:46 -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 lOFq-kG-fPDB for ; Fri, 10 Jan 2014 07:16:44 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9391AE06F for ; Fri, 10 Jan 2014 07:16:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C74D85405AF; Fri, 10 Jan 2014 16:16:32 +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 DMNgfBPDP2Au; Fri, 10 Jan 2014 16:16:26 +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 7CE4F540210; Fri, 10 Jan 2014 16:16:22 +0100 (CET)
From: Ladislav Lhotka 
To: Jernej Tuljak 
In-Reply-To: <52D00B5C.9070909@mg-soft.com>
References: <20140110133233.926097FC394@rfc-editor.org> <20140110.144038.1958728126349068530.mbj@tail-f.com> <52CFFC73.3010002@mg-soft.com> <44569F32-FD79-473A-90AF-71542E8D1714@nic.cz> <52D00B5C.9070909@mg-soft.com>
User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Fri, 10 Jan 2014 16:16:21 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: netmod@ietf.org
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 10 Jan 2014 15:16:46 -0000

Jernej Tuljak  writes:

> I've read that section a couple of times now and I now agree with Martin=
=20
> that "\*" is currently equivalent to '\*'. My reading would probably be=20
> correct if there was no second comma in the text I quoted. Oh, well...
>
>     Within a double-quoted string (enclosed within " "), a backslash
>     character may introduce a special character, which depends on the
>     character that immediately follows the backslash:
>
> would be better, no?

IMO, current wording permits three defensible interpretations:

1. "\*" =3D=3D '\*'
2. "\*" =3D=3D '*'
3. "\*' is an error

So this should be clarified.

As I wrote, I'd prefer #3 because it would be the same as the behaviour of =
"\" in regex patterns.

Lada

>
> Jernej
>
> Dne 10.1.2014 15:31, pi=C5=A1e Ladislav Lhotka:
>> On 10 Jan 2014, at 14:58, Jernej Tuljak  wrote:
>>
>>> If this is true, then it is RFC6020 that needs a clarification on this.=
 Namely, that the "special character" which follows a backslash need not be=
 special and that it does not represent an escape sequence in such a case.
>>>
>>>    Within a double-quoted string (enclosed within " "), a backslash
>>>    character introduces a special character, which depends on the
>>>    character that immediately follows the backslash:
>>>
>>>     \n      new line
>>>     \t      a tab character
>>>     \"      a double quote
>>>     \\      a single backslash
>>>
>>> My reading is that a backslash starts a YANG escape sequence and may th=
erefore be removed during string dequoting. A "\*" ends up as *, which is n=
ot equivalent to '\*=E2=80=99.
>> In XSD regular expressions, which are also used by YANG, it is an error =
if a backslash plus something is not defined as an escape sequence. So I th=
ink YANG should behave the same for double-quoted string, i.e. a backslash =
followed by something else than the four characters listed above should be =
flagged as an error (=E2=80=9Cillegal escape=E2=80=9D).
>>
>> Lada
>>
>>> Please move this discussion over to NETMOD it that's the case.
>>>
>>> Jernej
>>>
>>> Dne 10.1.2014 14:40, pi=C5=A1e Martin Bjorklund:
>>>> Hi,
>>>>
>>>> This errata should be rejected.  "\*" is equvalent to '\*'.  \* in a
>>>> double quoted string is not an escape sequence, which means that the
>>>> characters are interpreted literally, i.e. the two characters \
>>>> followed by *.
>>>>
>>>> The same goes for errata 3863.
>>>>
>>>> /martin
>>>>
>>>> RFC Errata System  wrote:
>>>>> The following errata report has been submitted for RFC6536,
>>>>> "Network Configuration Protocol (NETCONF) Access Control Model".
>>>>>
>>>>> --------------------------------------
>>>>> You may review the report below and at:
>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D6536&eid=3D3862
>>>>>
>>>>> --------------------------------------
>>>>> Type: Technical
>>>>> Reported by: Jernej Tuljak 
>>>>>
>>>>> Section: 3.5.2.
>>>>>
>>>>> Original Text
>>>>> -------------
>>>>>       typedef matchall-string-type {
>>>>>         type string {
>>>>>           pattern "\*";
>>>>>         }
>>>>>         description
>>>>>           "The string containing a single asterisk '*' is used
>>>>>            to conceptually represent all possible values
>>>>>            for the particular leaf using this data type.";
>>>>>       }
>>>>>
>>>>> Corrected Text
>>>>> --------------
>>>>>       typedef matchall-string-type {
>>>>>         type string {
>>>>>           pattern '\*';
>>>>>         }
>>>>>         description
>>>>>           "The string containing a single asterisk '*' is used
>>>>>            to conceptually represent all possible values
>>>>>            for the particular leaf using this data type.";
>>>>>       }
>>>>>
>>>>> Notes
>>>>> -----
>>>>> As per RFC6020, Section 6.1.3., a backslash within a double-quoted
>>>>> string introduces a special character. The only valid escape sequences
>>>>> inside a double-quoted YANG string are: \n, \t, \" and \. As \* is not
>>>>> a valid escape sequence, a single quoted string should be used to
>>>>> specify the offending pattern statement's argument. The quotes could
>>>>> also be omitted.
>>>>>
>>>>> 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.
>>>>>
>>>>> --------------------------------------
>>>>> RFC6536 (draft-ietf-netconf-access-control-07)
>>>>> --------------------------------------
>>>>> Title : Network Configuration Protocol (NETCONF) Access Control Model
>>>>> Publication Date    : March 2012
>>>>> Author(s)           : A. Bierman, M. Bjorklund
>>>>> Category            : PROPOSED STANDARD
>>>>> Source              : Network Configuration
>>>>> Area                : Operations and Management
>>>>> Stream              : IETF
>>>>> Verifying Party     : IESG
>>>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>

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

From randy_presuhn@mindspring.com  Fri Jan 10 11:28:23 2014
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 08D671AE10C for ; Fri, 10 Jan 2014 11:28: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 I-Q4GSc063q4 for ; Fri, 10 Jan 2014 11:28:21 -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 DF65F1AE13F for ; Fri, 10 Jan 2014 11:28:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lh4GLMGXn+K1mELcW+E+JQKd8zAM7/nkWi2F4Jsck56+pHpgeB6itmHjhX+SDgn4; 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-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W1hkW-0006bX-Sy for netmod@ietf.org; Fri, 10 Jan 2014 14:28:08 -0500
Received: from 99.23.161.2 by webmail.earthlink.net with HTTP; Fri, 10 Jan 2014 14:28:08 -0500
Message-ID: <4913899.1389382088825.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
Date: Fri, 10 Jan 2014 11:28:08 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbe0fa28cec151a022ab74dcb122cde038350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.51
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported]	RFC6536 (3862)
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, 10 Jan 2014 19:28:23 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Jan 10, 2014 7:16 AM
>To: Jernej Tuljak 
>Cc: netmod@ietf.org
>Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported]	RFC6536 (3862)
...
>IMO, current wording permits three defensible interpretations:
>
>1. "\*" == '\*'
>2. "\*" == '*'
>3. "\*' is an error
>
>So this should be clarified.
>
>As I wrote, I'd prefer #3 because it would be the same as
>the behaviour of "\" in regex patterns.

Option #3 would also be the safest in case the need ever arises
in the future to define additional escape sequences, since doing
so would not change the meaning of any existing valid sequence.

Randy

From sm@resistor.net  Sat Jan 11 00:43:51 2014
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 AA33A1AE01C; Sat, 11 Jan 2014 00:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] 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 aKvR8U8-vGR0; Sat, 11 Jan 2014 00:43:50 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C347A1ADF94; Sat, 11 Jan 2014 00:43:50 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s0B8hV6B025282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Jan 2014 00:43:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1389429820; bh=C6Z8t+l83M+TYdKDvTg0SjC8XRQpcB0h11Y1GnArE08=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QWD2CVKdDy6B66m1kfVcEeiszC3M0M1qUkRToxlsBS4xGa9Nco3XvdT36Kj6DoL8k do0r+RNSSU/ehGipG3iY/C0aACtGVeQf1FxElAdzfCOs9yu2fK8k5RsDb4ZxuV6ytA vMXjFUmmsvsubR77ZD9SsKR6ePXCzUFHFSudJLz0=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1389429820; i=@resistor.net; bh=C6Z8t+l83M+TYdKDvTg0SjC8XRQpcB0h11Y1GnArE08=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qZvvpOpxcECNCgYLmXyNF5KUxjE+YKQF7rb+5YY7f2usVXTymv9YSv57NxwXSS9X5 /Oc7tbGsg3tpxwX6ObxUYM1+7/1y7OQhZiAtrJVFEra7VgOS8O4cs+6ym+3Qk+iF8Q P3w2dyM9nCD8yAW6y70D1H79dx0Cx+CZiFnZlKzM=
Message-Id: <6.2.5.6.2.20140111002617.06fe52c8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 11 Jan 2014 00:43:17 -0800
To: Andy Bierman 
From: SM 
In-Reply-To: 
References: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com>  <6.2.5.6.2.20140108233958.0a849e58@resistor.net> <20140109105804.GA44893@elstar.local> <6.2.5.6.2.20140109051548.0a951040@resistor.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ietf@ietf.org, netmod@ietf.org
Subject: Re: [netmod] Fwd: Re: Last Call: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Jan 2014 08:43:51 -0000

Hi Andy,
At 11:05 09-01-2014, Andy Bierman wrote:
>After reading the IANA Considerations section closer, I have some concerns
>about the use of a YANG enumeration. This section does not say who must
>update the enumeration typedef and republish the RFC containing the new
>YANG module, every time the TZ database is changed.
>Is it the NETMOD WG? IANA?

That would be IANA.  There is a comment from IANA about what it is 
being asked to do.  There hasn't been any public reply from the 
author of the draft.

The Last Call was announced on December 3, 2013.  The only responses 
have been from the Area Director, one of the working group Chairs, 
Martin Bjorklund and Andy Bierman.  If the document is published as a 
RFC it will be said to represent the consensus of the IETF ...

Regards,
-sm 


From mbj@tail-f.com  Sat Jan 11 01:13:15 2014
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 E48761AE03E for ; Sat, 11 Jan 2014 01:13:15 -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 ONZnrK3-qL8F for ; Sat, 11 Jan 2014 01:13:13 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id A22AC1A9313 for ; Sat, 11 Jan 2014 01:13:12 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 78399240C187; Sat, 11 Jan 2014 10:13:01 +0100 (CET)
Date: Sat, 11 Jan 2014 10:13:00 +0100 (CET)
Message-Id: <20140111.101300.219049272.mbj@tail-f.com>
To: ietfdbh@comcast.net
From: Martin Bjorklund 
In-Reply-To: <014201cef85b$81260cf0$837226d0$@comcast.net>
References:  <014201cef85b$81260cf0$837226d0$@comcast.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] 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: Sat, 11 Jan 2014 09:13:16 -0000

Hi,

"ietfdbh"  wrote:
> 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.

Operational state is out of scope for this draft.

The RFC 6643 translated MIB modules can be used.


> 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.

RowStatus is an SNMP-specific construction.  A row that is not active
exists in the SNMP agent, but is "unavailable for use by the managed
device".

In NETCONF the transaction can be much bigger than traditional SNMP;
which means that a client can send everything in one operation, and
does not have to carefully construct multiple PDUs to first inactivate
some rows, then modify the values, then re-active the rows.

> 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?

Yes.

> 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. 

This is a good point, thank you for catching it!

Implementations allowing both write access via SNMP and NETCONF should
be recommended (required?) to bump the spinlock when NETCONF modifies
the relevant parts of the SNMP tables.

(this applies of course to all (three) spin locks in these mibs)

> 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.

These addresses are used in Appendix A.1 where it shows a listening
endpoint.  0.0.0.0 and :: are the IP any addresses used to listen on
any interface.

But we can change this to a documention-special address if the example
becomes more clear this way.

> 5) The security implications of not using the RFC3414 method for cloning and
> key change are not discussed.

NETCONF generally over a secure and encrypted transport (this is
pointed out in the Security Considerations section) hence the SNMP
cloning mechanism is not needed.  I am not sure what kind of text you
are looking for.

> 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.

The keys and the engineID have been copied from RFC 3414.

> 7) I am having some difficulty understanding the purpose of the YANG snmp
> models.

The same purpose as any YANG or MIB module - to provide a standardized
way to manage the underying subsystem if NETCONF/YANG or SNMP/MIBs are
used.

> 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.

This might be one scenario.

> 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.

usmCloneFrom is never intialized - when read it is always
zeroDotZero.  It is only used when a new user is created over SNMP.

So your statement that keychange cannot be done is not correct.

> 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.

No.

> 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,

Well, we don't think the models lack anything...

> 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.

Another scenario are deployments (operators told the IETF that they
exist long ago) where SNMP agents run in read-only mode and other
mechanism (typically proprietary CLIs) are used to configure the SNMP
agent. This YANG configuration data model clearly targets such
deployments (that apparently do exist). It still allows to interwork
with SNMP-managed applications.


/martin

From randy_presuhn@mindspring.com  Sat Jan 11 01:53:17 2014
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 04BEF1AD7C1 for ; Sat, 11 Jan 2014 01:53:17 -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 ZA3EcCwxKPku for ; Sat, 11 Jan 2014 01:53:15 -0800 (PST)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFA21AD739 for ; Sat, 11 Jan 2014 01:53:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GbdKSVt1RgJ4L30Au0LPD90l/4ujamALrENbPT0AeEKEg1T9b9+WhGOIW54VeGDr; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.23.161.2] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W1vFX-0001lU-To for netmod@ietf.org; Sat, 11 Jan 2014 04:53:04 -0500
Message-ID: <005c01cf0eb3$56649180$6b01a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
References:  <014201cef85b$81260cf0$837226d0$@comcast.net> <20140111.101300.219049272.mbj@tail-f.com>
Date: Sat, 11 Jan 2014 01:56:01 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edba77c54f760b5835fbbd3629a50501980350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.23.161.2
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: Sat, 11 Jan 2014 09:53:17 -0000

Hi -
 
> From: "Martin Bjorklund" 
> To: 
> Cc: 
> Sent: Saturday, January 11, 2014 1:13 AM
> Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
...
> > 5) The security implications of not using the RFC3414 method for cloning and
> > key change are not discussed.
> 
> NETCONF generally over a secure and encrypted transport (this is
> pointed out in the Security Considerations section) hence the SNMP
> cloning mechanism is not needed.  I am not sure what kind of text you
> are looking for.
...

There's more to cloning than transport security.  The way keyChange works
requires the cloner to know the authKey/privKey of the clone-from user as
well as the secret key(s) to be used for the new user.

The Netconf client does not need to know a cloneFrom authKey/privKey to
create new users, nor does it need to reference an existing user to clone
from.  Both of these are paths permitting the potential creation of users with
combinations of protocols not represented in the usmUserTable, or to which
clone access would have been effectively blocked by an unpublished key change.
This could, for example, result in a situation where the SNMP security administrator
has blocked the ability for delegated administrators to create a noAuth/noPriv
user, but left them the ability to create auth/priv users; yet the Netconf interface
would restore that ability to those delegated administrators.

That's a fairly obvious security implication.  There are probably subtler ones, too.
I don't know whether you consider it a problem, but the properties *are*
different and should be systematically thought through and documented.

Randy


From mbj@tail-f.com  Sat Jan 11 02:51:48 2014
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 8EE681ADF6D for ; Sat, 11 Jan 2014 02:51:48 -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 LHnZRvCETJ8C for ; Sat, 11 Jan 2014 02:51:46 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9861ADBC9 for ; Sat, 11 Jan 2014 02:51:46 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 67F1B240C187; Sat, 11 Jan 2014 11:51:35 +0100 (CET)
Date: Sat, 11 Jan 2014 11:51:34 +0100 (CET)
Message-Id: <20140111.115134.528610893.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund 
In-Reply-To: <005c01cf0eb3$56649180$6b01a8c0@oemcomputer>
References: <014201cef85b$81260cf0$837226d0$@comcast.net> <20140111.101300.219049272.mbj@tail-f.com> <005c01cf0eb3$56649180$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] 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: Sat, 11 Jan 2014 10:51:48 -0000

"Randy Presuhn"  wrote:
> Hi -
>  
> > From: "Martin Bjorklund" 
> > To: 
> > Cc: 
> > Sent: Saturday, January 11, 2014 1:13 AM
> > Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> ...
> > > 5) The security implications of not using the RFC3414 method for cloning
> > > and
> > > key change are not discussed.
> > 
> > NETCONF generally over a secure and encrypted transport (this is
> > pointed out in the Security Considerations section) hence the SNMP
> > cloning mechanism is not needed.  I am not sure what kind of text you
> > are looking for.
> ...
> 
> There's more to cloning than transport security.  The way keyChange works
> requires the cloner to know the authKey/privKey of the clone-from user as
> well as the secret key(s) to be used for the new user.
> 
> The Netconf client does not need to know a cloneFrom authKey/privKey to
> create new users, nor does it need to reference an existing user to clone
> from.  Both of these are paths permitting the potential creation of users with
> combinations of protocols not represented in the usmUserTable, or to which
> clone access would have been effectively blocked by an unpublished key change.
> This could, for example, result in a situation where the SNMP security
> administrator
> has blocked the ability for delegated administrators to create a noAuth/noPriv
> user, but left them the ability to create auth/priv users; yet the Netconf
> interface
> would restore that ability to those delegated administrators.
> 
> That's a fairly obvious security implication.  There are probably subtler ones,
> too.
> I don't know whether you consider it a problem, but the properties *are*
> different and should be systematically thought through and documented.

Ok, I agree it makes sense to document this.  It could be viewed as a
feature since we now have a standardized way for the "SNMP security
administrator" to actually set up usm entries for cloning.  These
delegated administrators don't have to have NETCONF access of course.


/martin

From mbj@tail-f.com  Sat Jan 11 04:36:47 2014
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 158171ADFB6 for ; Sat, 11 Jan 2014 04:36:47 -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 1qhlAHG_M0rW for ; Sat, 11 Jan 2014 04:36:45 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 849691ADF78 for ; Sat, 11 Jan 2014 04:36:45 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id B3FF4240C187; Sat, 11 Jan 2014 13:36:34 +0100 (CET)
Date: Sat, 11 Jan 2014 13:36:34 +0100 (CET)
Message-Id: <20140111.133634.462426147.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <32377793-C511-4F40-9C55-5E6A6B27969E@nic.cz>
References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <32377793-C511-4F40-9C55-5E6A6B27969E@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-8859-7
Content-Transfer-Encoding: base64
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-13.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: Sat, 11 Jan 2014 12:36:47 -0000

SGksDQoNCkxhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+IEhpLA0KPiAN
Cj4gY2hhbmdlcyBpbiB0aGlzIHJldmlzaW9uIG1haW5seSByZXN1bHRlZCBmcm9tIE1hcnRpbqJz
IHJldmlldywgSSBiZWxpZXZlIGFsbA0KPiBoaXMgY29tbWVudHMgd2VyZSBhZGRyZXNzZWQuDQoN
CkkgaGF2ZSByZXZpZXdlZCB0aGlzIHZlcnNpb24sIGFuZCBJIHRoaW5rIGFsbCBteSBjb21tZW50
cyBhcmUNCmFkZHJlc3NlZC4gIFRoYW5rIHlvdSENCg0KSSBoYXZlIG9uZSBxdWVzdGlvbiBhYm91
dCBhIGNoYW5nZSB0aGF0IEkgYmVsaWV2ZSB3YXMgbm90IGRpc2N1c3NlZCBvbg0KdGhlIGxpc3Q6
DQoNCiAgIG8gUmVtb3ZlICJ3aGVuIiBzdGF0ZW1lbnQgZm9yIElQdjYgcm91dGVyIGludGVyZmFj
ZSBvcGVyYXRpb25hbAkNCiAgICAgc3RhdGUgLSBpdCB3YXMgZGVwZW5kZW50IG9uIGEgY29uZmln
IHZhbHVlIHRoYXQgbWF5IG5vdCBiZQkNCiAgICAgcHJlc2VudC4JDQoJCQ0KSSBkbyBub3QgdGhp
bmsgaXMgY29ycmVjdC4gIElmIHRoZSBpcHY2IGNvbnRhaW5lciBleGlzdHMsIHRoZQ0KJ2VuYWJs
ZWQnIGxlYWYgaGFzIHRoZSBkZWZhdWx0IHZhbHVlIG9mICd0cnVlJywgYW5kIGRlZmF1bHQgdmFs
dWVzIGFyZQ0KdGFrZW4gaW50byBhY2NvdW50IHdoZW4gWFBhdGggZXhwcmVzc2lvbnMgYXJlIGV2
YWx1YXRlZC4gIEJ1dCBtYXliZSBJDQptaXN1bmRlcnN0b29kIHRoZSBwcm9ibGVtPw0KDQoNCg0K
SSBub3RpY2VkIG9uZSB0aGluZyB0aGF0IG1heSBvciBtYXkgbm90IGJlIGludGVudGlvbmFsLiAg
VGhlIGdyb3VwaW5nDQoib3V0Z29pbmctaW50ZXJmYWNlIiBoYXMgYSBsZWFmIHdpdGggYSBsZWFm
cmVmLCB3aGVyZSB0aGUgcGF0aCB1c2VzDQpub24tcHJlZml4ZWQgaWRlbnRpZmllcnMuICBJZiB0
aGlzIGdyb3VwaW5nIGlzIGV2ZXIgdXNlZCBmcm9tIGFub3RoZXINCm1vZHVsZSwgaXQgbWVhbnMg
dGhhdCB0aGF0IG1vZHVsZSBtdXN0IGhhdmUgdGhlIHNhbWUgZGF0YSBoaWVyYXJjaHkNCigvcm91
dGluZy1zdGF0ZS8uLi4pIGFzIHRoaXMgbW9kdWxlLiAgVGhlc2UgaWRlbnRpZmllcnMgc2hvdWxk
DQpwcm9iYWJseSB1c2UgcHJlZml4ZXMuDQoNCg0KDQovbWFydGluDQo=

From lhotka@nic.cz  Sat Jan 11 05:31:23 2014
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 4A5E41AD8CD for ; Sat, 11 Jan 2014 05:31:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.189
X-Spam-Level: 
X-Spam-Status: No, score=-1.189 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.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 fe4TzmtfO0Ps for ; Sat, 11 Jan 2014 05:31:21 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EAACB1AD9AC for ; Sat, 11 Jan 2014 05:31:20 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D012313F876 for ; Sat, 11 Jan 2014 14:31:09 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1389447069; bh=oHimqolIiYpalBbvmgHwxJhY0rbJYcSBODA/Q3mcpSs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=b5fn1sn6Hf0rPxKtTB5ZZqq7VG5ZHonIV8ERyaVGrEwC/6LxtKske6DsHlONtYvkg hbzXVpAQsgniiQo0IV1x1b9x1bzl5SklZdDZihHv7HCWzud4AKe8YTewzT+teS4JIG RIM6bhWMw93eF58qhEswW1HQN8dWtBgpO0fw+aTo=
Content-Type: text/plain; charset=windows-1253
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140111.133634.462426147.mbj@tail-f.com>
Date: Sat, 11 Jan 2014 14:31:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <12A63CCF-69CE-4D43-A3EC-F420635B5237@nic.cz>
References: <20140110133016.24678.42711.idtracker@ietfa.amsl.com> <32377793-C511-4F40-9C55-5E6A6B27969E@nic.cz> <20140111.133634.462426147.mbj@tail-f.com>
To: netmod@ietf.org
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-routing-cfg-13.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: Sat, 11 Jan 2014 13:31:23 -0000

On 11 Jan 2014, at 13:36, Martin Bjorklund  wrote:

> Hi,
>=20
> Ladislav Lhotka  wrote:
>> Hi,
>>=20
>> changes in this revision mainly resulted from Martin=92s review, I =
believe all
>> his comments were addressed.
>=20
> I have reviewed this version, and I think all my comments are
> addressed.  Thank you!

Good, thanks!

>=20
> I have one question about a change that I believe was not discussed on
> the list:
>=20
>   o Remove "when" statement for IPv6 router interface operational=09
>     state - it was dependent on a config value that may not be=09
>     present.=09
> 	=09
> I do not think is correct.  If the ipv6 container exists, the
> 'enabled' leaf has the default value of 'true', and default values are
> taken into account when XPath expressions are evaluated.  But maybe I
> misunderstood the problem?

If it is a system-controlled interface, there may be no entry for it in =
/if:interfaces/if:interface, and the default then doesn=92t apply.

>=20
>=20
>=20
> I noticed one thing that may or may not be intentional.  The grouping
> "outgoing-interface" has a leaf with a leafref, where the path uses
> non-prefixed identifiers.  If this grouping is ever used from another
> module, it means that that module must have the same data hierarchy
> (/routing-state/...) as this module.  These identifiers should
> probably use prefixes.

That grouping is actually intended only for local use. Modules for =
routing protocols might also define outgoing-interface but they should =
use relative path so as to limit the choice only to interfaces assigned =
to the ancestor routing instance. It is done so already for the =93static=94=
 protocol.

Maybe the =93outgoing-interface=94 grouping could be made local by =
moving it under =93routing-state=94 but that seems detrimental to the =
module organization - the definition of the grouping would be harder to =
find.

Lada=20

>=20
>=20
>=20
> /martin

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





From dromasca@avaya.com  Sun Jan 12 03:38:31 2014
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 86CC61AE018 for ; Sun, 12 Jan 2014 03:38:31 -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 OPvNVX8Lrb4o for ; Sun, 12 Jan 2014 03:38:29 -0800 (PST)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id CC9A91ADFF8 for ; Sun, 12 Jan 2014 03:38:29 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8FAOt90lLGmAcV/2dsb2JhbABagmohOFalOpQtgQYWdIIlAQEBAQMBAQEPKDQXBgEIDQQEAQELFAkuCxQHAQEFBQQTCBqHYgEMmhuEUKUWF45WPoMegRMEmUeFPIspgy2CKg
X-IronPort-AV: E=Sophos;i="4.95,647,1384318800"; d="scan'208";a="44795760"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 Jan 2014 06:38:18 -0500
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 12 Jan 2014 06:28:47 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0158.001; Sun, 12 Jan 2014 12:38:17 +0100
From: "Romascanu, Dan (Dan)" 
To: "netmod@ietf.org" 
Thread-Topic: Yang model for SFC
Thread-Index: AQHPDVcsXlQWvjkBG0m02wJUMgIr/pqA+sAw
Date: Sun, 12 Jan 2014 11:38:16 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA243C9B60@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.46]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [netmod] FW: Yang model for SFC
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, 12 Jan 2014 11:38:31 -0000

FYI.=20

Regards,=20

Dan




-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenn=
o)
Sent: Thursday, January 09, 2014 6:24 PM
To: sfc@ietf.org
Subject: [sfc] Yang model for SFC

Hi,

we submitted a draft reflecting our thoughts and efforts on the area of Yan=
g and SFC

http://tools.ietf.org/html/draft-penno-sfc-yang-00

Thanks,

Reinaldo

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

From jernej.tuljak@mg-soft.si  Mon Jan 13 02:44:33 2014
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 B90791AE118 for ; Mon, 13 Jan 2014 02:44:33 -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 rM1axbeEamJc for ; Mon, 13 Jan 2014 02:44:31 -0800 (PST)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 701751AE112 for ; Mon, 13 Jan 2014 02:44:31 -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 s0DAiJ08021756 for ; Mon, 13 Jan 2014 11:44:19 +0100
Message-ID: <52D3C380.3010003@mg-soft.com>
Date: Mon, 13 Jan 2014 11:44:16 +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: NETMOD Working Group 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [netmod] Top-level choice (and uses) with a when sub-statement
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, 13 Jan 2014 10:44:34 -0000

Just encountered some strangeness. Can top-level choice (uses) 
statements have when sub-statements? The latter don't appear to have a 
context node and therefore an accessible tree defined for the XPath 
expression.

In RFC6020, Section 7.19.5.

    o  If the "when" statement is a child of a "uses", "choice", or
       "case" statement, then the context node is the closest ancestor
       node to the "uses", "choice", or "case" node that is also a data
       node.

and later

The accessible tree depends on the context node

When combined with definition of a data node in Section 3.

    o  data node: A node in the schema tree that can be instantiated in a
       data tree.  One of container, leaf, leaf-list, list, and anyxml.

Note that top-level statements cannot have a data node ancestor (they 
are children of module or a submodule statement). I don't think the text 
above is correct, since there's no reason why top-level choice and uses 
statements should be prevented from being optional via a when statement. 
The context node should be the root node (document root) of the 
accessible tree, which should be determined the same as if the missing 
context node would represent state data.

Jernej

From mbj@tail-f.com  Mon Jan 13 02:59:49 2014
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 0DC0F1AE109 for ; Mon, 13 Jan 2014 02:59:49 -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 1RkWJZRv-Lcx for ; Mon, 13 Jan 2014 02:59:47 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5B11AE05C for ; Mon, 13 Jan 2014 02:59:47 -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 5CACB240C24B; Mon, 13 Jan 2014 11:59:35 +0100 (CET)
Date: Mon, 13 Jan 2014 11:59:34 +0100 (CET)
Message-Id: <20140113.115934.1613102529886806801.mbj@tail-f.com>
To: jernej.tuljak@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <52D3C380.3010003@mg-soft.com>
References: <52D3C380.3010003@mg-soft.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] Top-level choice (and uses) with a when sub-statement
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, 13 Jan 2014 10:59:49 -0000

Jernej Tuljak  wrote:
> Just encountered some strangeness. Can top-level choice (uses)
> statements have when sub-statements? The latter don't appear to have a
> context node and therefore an accessible tree defined for the XPath
> expression.
> 
> In RFC6020, Section 7.19.5.
> 
>    o  If the "when" statement is a child of a "uses", "choice", or
>       "case" statement, then the context node is the closest ancestor
>       node to the "uses", "choice", or "case" node that is also a data
>       node.
> 
> and later
> 
> The accessible tree depends on the context node
> 
> When combined with definition of a data node in Section 3.
> 
>    o  data node: A node in the schema tree that can be instantiated in a
>       data tree.  One of container, leaf, leaf-list, list, and anyxml.
> 
> Note that top-level statements cannot have a data node ancestor (they
> are children of module or a submodule statement). I don't think the
> text above is correct, since there's no reason why top-level choice
> and uses statements should be prevented from being optional via a when
> statement. The context node should be the root node (document root) of
> the accessible tree, which should be determined the same as if the
> missing context node would represent state data.

I agree.


/martin

From jernej.tuljak@mg-soft.si  Mon Jan 13 03:06:53 2014
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 595231AE076 for ; Mon, 13 Jan 2014 03:06:53 -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 OTyVLW-I5Mtv for ; Mon, 13 Jan 2014 03:06:51 -0800 (PST)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 869E71ADF80 for ; Mon, 13 Jan 2014 03:06:51 -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 s0DB6efO022024; Mon, 13 Jan 2014 12:06:40 +0100
Message-ID: <52D3C8BD.8080602@mg-soft.com>
Date: Mon, 13 Jan 2014 12:06:37 +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: Martin Bjorklund 
References: <52D3C380.3010003@mg-soft.com> <20140113.115934.1613102529886806801.mbj@tail-f.com>
In-Reply-To: <20140113.115934.1613102529886806801.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org
Subject: Re: [netmod] Top-level choice (and uses) with a when sub-statement
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, 13 Jan 2014 11:06:53 -0000

Dne 13.1.2014 11:59, piše Martin Bjorklund:
> Jernej Tuljak  wrote:
>> Just encountered some strangeness. Can top-level choice (uses)
>> statements have when sub-statements? The latter don't appear to have a
>> context node and therefore an accessible tree defined for the XPath
>> expression.
>>
>> In RFC6020, Section 7.19.5.
>>
>>     o  If the "when" statement is a child of a "uses", "choice", or
>>        "case" statement, then the context node is the closest ancestor
>>        node to the "uses", "choice", or "case" node that is also a data
>>        node.
>>
>> and later
>>
>> The accessible tree depends on the context node
>>
>> When combined with definition of a data node in Section 3.
>>
>>     o  data node: A node in the schema tree that can be instantiated in a
>>        data tree.  One of container, leaf, leaf-list, list, and anyxml.
>>
>> Note that top-level statements cannot have a data node ancestor (they
>> are children of module or a submodule statement). I don't think the
>> text above is correct, since there's no reason why top-level choice
>> and uses statements should be prevented from being optional via a when
>> statement. The context node should be the root node (document root) of
>> the accessible tree, which should be determined the same as if the
>> missing context node would represent state data.
> I agree.

The first two bullets in 7.19.5. should be corrected with text that 
describes what happens when no data node ancestor can be found. They are 
both affected.

Jernej

>
>
> /martin


From lhotka@nic.cz  Mon Jan 13 04:38:25 2014
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 379C91AE156 for ; Mon, 13 Jan 2014 04:38:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.189
X-Spam-Level: 
X-Spam-Status: No, score=-1.189 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.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 YskOz-EWt74t for ; Mon, 13 Jan 2014 04:38:23 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 311BE1AE134 for ; Mon, 13 Jan 2014 04:38:22 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 26D2714012E; Mon, 13 Jan 2014 13:38:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1389616690; bh=ywI/mOmKX7C/h4GkwYzuXselo7yiao5SCXrzwIztqwY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jSFWGkt0Wr4DRam/cSp5ywoseK/uNvFGMhVtrQbZxNYfPcMs2lOd+ZLMDJObu3hFM yGIEyDuG+zTxtIY2fJFz7qWPy/tyh4rxe3xfDSLhQOVkMgKW+b+Vm7/3wAGAR6UX1K i8Dq99kHpKYe2iqFMe7ii5eAG2Nz6VdE1qtgGu+8=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <52D3C8BD.8080602@mg-soft.com>
Date: Mon, 13 Jan 2014 13:38:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <00E55A55-E72B-4457-B87F-C17429290C90@nic.cz>
References: <52D3C380.3010003@mg-soft.com> <20140113.115934.1613102529886806801.mbj@tail-f.com> <52D3C8BD.8080602@mg-soft.com>
To: Jernej Tuljak 
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] Top-level choice (and uses) with a when sub-statement
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, 13 Jan 2014 12:38:25 -0000

On 13 Jan 2014, at 12:06, Jernej Tuljak  =
wrote:

> Dne 13.1.2014 11:59, pi=9Ae Martin Bjorklund:
>> Jernej Tuljak  wrote:
>>> Just encountered some strangeness. Can top-level choice (uses)
>>> statements have when sub-statements? The latter don't appear to have =
a
>>> context node and therefore an accessible tree defined for the XPath
>>> expression.
>>>=20
>>> In RFC6020, Section 7.19.5.
>>>=20
>>>    o  If the "when" statement is a child of a "uses", "choice", or
>>>       "case" statement, then the context node is the closest =
ancestor
>>>       node to the "uses", "choice", or "case" node that is also a =
data
>>>       node.
>>>=20
>>> and later
>>>=20
>>> The accessible tree depends on the context node
>>>=20
>>> When combined with definition of a data node in Section 3.
>>>=20
>>>    o  data node: A node in the schema tree that can be instantiated =
in a
>>>       data tree.  One of container, leaf, leaf-list, list, and =
anyxml.
>>>=20
>>> Note that top-level statements cannot have a data node ancestor =
(they
>>> are children of module or a submodule statement). I don't think the
>>> text above is correct, since there's no reason why top-level choice
>>> and uses statements should be prevented from being optional via a =
when
>>> statement. The context node should be the root node (document root) =
of
>>> the accessible tree, which should be determined the same as if the
>>> missing context node would represent state data.
>> I agree.
>=20
> The first two bullets in 7.19.5. should be corrected with text that =
describes what happens when no data node ancestor can be found. They are =
both affected.

The definition of =93when=94 context has other problems that need to be =
addressed:

1. The XPath expression in the argument must not refer, even indirectly, =
to the context node and its descendants.

2. The context node in the third bullet may not exist. Example:

container top {
  leaf foo {
    type boolean;
  }
  leaf bar {
    when =93../foo =3D =91true=92=94;
    type uint8;
    default 42;
  }
}

Now, if the instance document contains


  false


we get into a deadlock: the =93when=94 statement has no context node, so =
it cannot be evaluated and the =93default=94 statement applies, but then =
the context node starts to exist, so the =93when=94 statement applies, =
the server removes  form the conceptual tree, and so on.

Lada =20

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

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





From bclaise@cisco.com  Mon Jan 13 05:38:35 2014
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 5773A1AE10A for ; Mon, 13 Jan 2014 05:38:35 -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 2fly3WPyioqF for ; Mon, 13 Jan 2014 05:38:34 -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 CCCEA1AE074 for ; Mon, 13 Jan 2014 05:38:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=672; q=dns/txt; s=iport; t=1389620303; x=1390829903; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=IAIoEtwN9yrFatuAVHKwj+56ocI+LI26GOEKvKqnI6Q=; b=a5MI5K0qS9cvR7hi6T8nRZ9HHajfJYFd6LoRLV1dkOdQt5ujHp4V0E2N cSiPrlWCINylGT04WyG9PMDvoeo3c2Xa04IA3PFy/bUhU2YqD6MPR5dqA NUQrWV+6PIe4ySOCOl4/7A/UfN4YYgM1W48kOqTxWmYw1p6MRwlk4J0Px 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah8FAArr01KQ/khN/2dsb2JhbABagwu6e4EQFnSCZEABPBYYAwIBAgFLDQEHAQGIAMR/F48HhD4BA5gXhkWLUIMuOw
X-IronPort-AV: E=Sophos;i="4.95,653,1384300800";  d="scan'208";a="3563911"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 13 Jan 2014 13:38:21 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0DDcLqH028166; Mon, 13 Jan 2014 13:38:21 GMT
Message-ID: <52D3EC4D.8070102@cisco.com>
Date: Mon, 13 Jan 2014 14:38:21 +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 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [netmod] Tom Nadeau as a new NETMOD co-chair
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, 13 Jan 2014 13:38:35 -0000

Dear all,

Some time ago, David Kessens expressed his desire to step down. Let me 
thanks David for his years of service in the NETMOD WG.

Tom Nadeau accepted the position of NETMOD co-chair.
Thanks to Tom for taking over and good luck to the WG and to the chairs 
in the continuation of the activity.

I strongly believe that the YANG/NETCONF effort is currently"crossing 
the chasm" (to make a reference to the book).
As any network management standards, it takes a long period for new 
standards to be run in production networks.
We should continue to push this effort a little bit longer. However, all 
the positive signs are there.

Regards, Benoit






From bclaise@cisco.com  Mon Jan 13 07:17:49 2014
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 368991AE1F8 for ; Mon, 13 Jan 2014 07:17:49 -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 oSVcHVXJ9XgO for ; Mon, 13 Jan 2014 07:17:47 -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 15ECC1AE1B9 for ; Mon, 13 Jan 2014 07:17:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1043; q=dns/txt; s=iport; t=1389626256; x=1390835856; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=EiHzeAZci0sqDoQhqeJ4asazqxj9lwzCmE487S9kjo0=; b=j6XM8H8z+yAw6BpUcnoI/pHZXpzBolDziYhx0mexY5Z8iWnNe5rKoDYL wI0x30k2jls3u0wlipk3ylQZ7IdjgoxVojvJ5Cka4m3evKdmUMEoEjrSu sB9I0/W3xUNRjMMKOrhv4VP7qjxnY1ztyoyr87fiYn3m1JD81q42k2gH+ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFAD4D1FKQ/khL/2dsb2JhbABagws4uXRPgRMWdIIlAQEBBAEBATU2ChELEQQBAQoWDwkDAgECARUoCAYBDAYCAQGIAA3EfxMEjw6ENwEDmBeGRYtQgW+BPzs
X-IronPort-AV: E=Sophos;i="4.95,653,1384300800";  d="scan'208";a="2899191"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 13 Jan 2014 15:17:35 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0DFHY7P009324; Mon, 13 Jan 2014 15:17:35 GMT
Message-ID: <52D4038E.5080707@cisco.com>
Date: Mon, 13 Jan 2014 16:17:34 +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: <4913899.1389382088825.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
In-Reply-To: <4913899.1389382088825.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 13 Jan 2014 15:17:49 -0000

Dear all,

On this errata, I'm unclear whether a clarification is needed.
If it's the case, please update the errata and let me know.

Regards, Benoit
>> From: Ladislav Lhotka 
>> Sent: Jan 10, 2014 7:16 AM
>> To: Jernej Tuljak 
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported]	RFC6536 (3862)
> ...
>> IMO, current wording permits three defensible interpretations:
>>
>> 1. "\*" == '\*'
>> 2. "\*" == '*'
>> 3. "\*' is an error
>>
>> So this should be clarified.
>>
>> As I wrote, I'd prefer #3 because it would be the same as
>> the behaviour of "\" in regex patterns.
> Option #3 would also be the safest in case the need ever arises
> in the future to define additional escape sequences, since doing
> so would not change the meaning of any existing valid sequence.
>
> Randy
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From andy@yumaworks.com  Mon Jan 13 07:20:26 2014
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 812EE1AE1B7 for ; Mon, 13 Jan 2014 07:20:26 -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 TOlaDtM9ZY81 for ; Mon, 13 Jan 2014 07:20:23 -0800 (PST)
Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id B25351AE1EE for ; Mon, 13 Jan 2014 07:20:23 -0800 (PST)
Received: by mail-qe0-f54.google.com with SMTP id cy10so1163692qeb.13 for ; Mon, 13 Jan 2014 07:20:12 -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=3o6qRhisj7fHQ1+OJeovSW9Kau3KyUv7gJZzpnZMM+k=; b=igSjTl3kQ7AbJcTTdFOjRNlx8DHVeFCNaDlSFsv3HLWXm6cFxqSO/1MSNer8WrumfM 7iyHwJom0U0V/ffWY2Ea+1+vsCPFFycV8f0e1uB6VJEGQ8J2YWOIbLm4kXZfPoBtWGTV YdUyDi8duc/F3C4x/RFTcYRHuqRzbjqMi7kiAhl6G10q8RhEzA4cGVkX8iFku+9FfSxb hXAtGXhv6qmiavtwAyBnKlKRJGBwzXuv02Zgl+zAodL30dHwuLmY5MoO0WEXLN3As5ok bud55AS3gGFfKHD7p4RFjJmPpj8PBsRapezRgpdpfmBrgtrQV5nVgZgtYFCdURA+gWNJ VdIQ==
X-Gm-Message-State: ALoCoQlxRRZIN5ssKKsFr1RIpvF7lkBZqzvp2a0csm4wboHjcCT+ls1uGE/d5uRBvIyzyKK+1dql
MIME-Version: 1.0
X-Received: by 10.229.184.69 with SMTP id cj5mr40072229qcb.8.1389626412564; Mon, 13 Jan 2014 07:20:12 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Mon, 13 Jan 2014 07:20:12 -0800 (PST)
In-Reply-To: <00E55A55-E72B-4457-B87F-C17429290C90@nic.cz>
References: <52D3C380.3010003@mg-soft.com> <20140113.115934.1613102529886806801.mbj@tail-f.com> <52D3C8BD.8080602@mg-soft.com> <00E55A55-E72B-4457-B87F-C17429290C90@nic.cz>
Date: Mon, 13 Jan 2014 07:20:12 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11331fb4b1185b04efdb9ca5
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Top-level choice (and uses) with a when sub-statement
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, 13 Jan 2014 15:20:26 -0000

--001a11331fb4b1185b04efdb9ca5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 13, 2014 at 4:38 AM, Ladislav Lhotka  wrote:

>
> On 13 Jan 2014, at 12:06, Jernej Tuljak  wrote:
>
> > Dne 13.1.2014 11:59, pi=C5=A1e Martin Bjorklund:
> >> Jernej Tuljak  wrote:
> >>> Just encountered some strangeness. Can top-level choice (uses)
> >>> statements have when sub-statements? The latter don't appear to have =
a
> >>> context node and therefore an accessible tree defined for the XPath
> >>> expression.
> >>>
> >>> In RFC6020, Section 7.19.5.
> >>>
> >>>    o  If the "when" statement is a child of a "uses", "choice", or
> >>>       "case" statement, then the context node is the closest ancestor
> >>>       node to the "uses", "choice", or "case" node that is also a dat=
a
> >>>       node.
> >>>
> >>> and later
> >>>
> >>> The accessible tree depends on the context node
> >>>
> >>> When combined with definition of a data node in Section 3.
> >>>
> >>>    o  data node: A node in the schema tree that can be instantiated i=
n
> a
> >>>       data tree.  One of container, leaf, leaf-list, list, and anyxml=
.
> >>>
> >>> Note that top-level statements cannot have a data node ancestor (they
> >>> are children of module or a submodule statement). I don't think the
> >>> text above is correct, since there's no reason why top-level choice
> >>> and uses statements should be prevented from being optional via a whe=
n
> >>> statement. The context node should be the root node (document root) o=
f
> >>> the accessible tree, which should be determined the same as if the
> >>> missing context node would represent state data.
> >> I agree.
> >
> > The first two bullets in 7.19.5. should be corrected with text that
> describes what happens when no data node ancestor can be found. They are
> both affected.
>
> The definition of =E2=80=9Cwhen=E2=80=9D context has other problems that =
need to be
> addressed:
>
> 1. The XPath expression in the argument must not refer, even indirectly,
> to the context node and its descendants.
>
> 2. The context node in the third bullet may not exist. Example:
>
> container top {
>   leaf foo {
>     type boolean;
>   }
>   leaf bar {
>     when =E2=80=9C../foo =3D =E2=80=98true=E2=80=99=E2=80=9D;
>     type uint8;
>     default 42;
>   }
> }
>
> Now, if the instance document contains
>
> 
>   false
> 
>
> we get into a deadlock: the =E2=80=9Cwhen=E2=80=9D statement has no conte=
xt node, so it
> cannot be evaluated and the =E2=80=9Cdefault=E2=80=9D statement applies, =
but then the
> context node starts to exist, so the =E2=80=9Cwhen=E2=80=9D statement app=
lies, the server
> removes  form the conceptual tree, and so on.
>
>

These are just implementation details.

(1) is just a boolean XPath expression that is always false

(2) is just hard to implement. The server must know the XPath
evaluation result even though the context node does not exist yet.



> Lada
>
> >
> > Jernej
> >
> >>
> >>
> >> /martin
> >
>


Andy

--001a11331fb4b1185b04efdb9ca5
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable





On Mon, Jan 13, 2014 at 4:38 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:




On 13 Jan 2014, at 12:06, Jernej Tuljak <jernej.tuljak@mg-soft.si> wrote:



> Dne 13.1.2014 11:59, pi=B9e Martin Bjorklund:

>> Jernej Tuljak <jern=
ej.tuljak@mg-soft.si> wrote:

>>> Just encountered some strangeness. Can top-level choice (uses)=


>>> statements have when sub-statements? The latter don't appe=
ar to have a

>>> context node and therefore an accessible tree defined for the =
XPath

>>> expression.

>>>

>>> In RFC6020, Section 7.19.5.

>>>

>>>    o  If the "when" statement is a ch=
ild of a "uses", "choice", or

>>>       "case" statement, then the cont=
ext node is the closest ancestor

>>>       node to the "uses", "choic=
e", or "case" node that is also a data

>>>       node.

>>>

>>> and later

>>>

>>> The accessible tree depends on the context node

>>>

>>> When combined with definition of a data node in Section 3.

>>>

>>>    o  data node: A node in the schema tree that=
 can be instantiated in a

>>>       data tree.  One of container, leaf, =
leaf-list, list, and anyxml.

>>>

>>> Note that top-level statements cannot have a data node ancesto=
r (they

>>> are children of module or a submodule statement). I don't =
think the

>>> text above is correct, since there's no reason why top-lev=
el choice

>>> and uses statements should be prevented from being optional vi=
a a when

>>> statement. The context node should be the root node (document =
root) of

>>> the accessible tree, which should be determined the same as if=
 the

>>> missing context node would represent state data.

>> I agree.

>

> The first two bullets in 7.19.5. should be corrected with text that de=
scribes what happens when no data node ancestor can be found. They are both=
 affected.



The definition of “when” context has other problems that need t=
o be addressed:



1. The XPath expression in the argument must not refer, even indirectly, to=
 the context node and its descendants.



2. The context node in the third bullet may not exist. Example:



container top {

  leaf foo {

    type boolean;

  }

  leaf bar {

    when “../foo =3D ‘true’”;

    type uint8;

    default 42;

  }

}



Now, if the instance document contains



<top>

  <foo>false</foo>

</top>



we get into a deadlock: the “when” statement has no context nod=
e, so it cannot be evaluated and the “default” statement applie=
s, but then the context node starts to exist, so the “when” sta=
tement applies, the server removes <bar> form the conceptual tree, an=
d so on.





These are just implemen=
tation details. 

(1) is just a boolean XPath =
expression that is always false

(2) is just hard t=
o implement. The server must know the XPath


evaluation result even though the context node does not exist yet.

  

Lada



>

> Jernej

>

>>

>>

>> /martin

>


Andy

=



--001a11331fb4b1185b04efdb9ca5--

From lhotka@nic.cz  Mon Jan 13 09:01:54 2014
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 E94A31AE1B4 for ; Mon, 13 Jan 2014 09:01:54 -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 wx0lu9NpHy21 for ; Mon, 13 Jan 2014 09:01:53 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA141ADFA3 for ; Mon, 13 Jan 2014 09:01:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 34A4C540402; Mon, 13 Jan 2014 18:01:39 +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 bb1RDVtVcnwM; Mon, 13 Jan 2014 18:01:34 +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 B6D2B5400BE; Mon, 13 Jan 2014 18:01:30 +0100 (CET)
From: Ladislav Lhotka 
To: Andy Bierman 
In-Reply-To: 
References: <52D3C380.3010003@mg-soft.com> <20140113.115934.1613102529886806801.mbj@tail-f.com> <52D3C8BD.8080602@mg-soft.com> <00E55A55-E72B-4457-B87F-C17429290C90@nic.cz> 
User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Mon, 13 Jan 2014 18:01:29 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Top-level choice (and uses) with a when sub-statement
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, 13 Jan 2014 17:01:55 -0000

Andy Bierman  writes:

> On Mon, Jan 13, 2014 at 4:38 AM, Ladislav Lhotka  wrote:
>
>>
>> On 13 Jan 2014, at 12:06, Jernej Tuljak  wrote:
>>
>> > Dne 13.1.2014 11:59, pi=C5=A1e Martin Bjorklund:
>> >> Jernej Tuljak  wrote:
>> >>> Just encountered some strangeness. Can top-level choice (uses)
>> >>> statements have when sub-statements? The latter don't appear to have=
 a
>> >>> context node and therefore an accessible tree defined for the XPath
>> >>> expression.
>> >>>
>> >>> In RFC6020, Section 7.19.5.
>> >>>
>> >>>    o  If the "when" statement is a child of a "uses", "choice", or
>> >>>       "case" statement, then the context node is the closest ancestor
>> >>>       node to the "uses", "choice", or "case" node that is also a da=
ta
>> >>>       node.
>> >>>
>> >>> and later
>> >>>
>> >>> The accessible tree depends on the context node
>> >>>
>> >>> When combined with definition of a data node in Section 3.
>> >>>
>> >>>    o  data node: A node in the schema tree that can be instantiated =
in
>> a
>> >>>       data tree.  One of container, leaf, leaf-list, list, and anyxm=
l.
>> >>>
>> >>> Note that top-level statements cannot have a data node ancestor (they
>> >>> are children of module or a submodule statement). I don't think the
>> >>> text above is correct, since there's no reason why top-level choice
>> >>> and uses statements should be prevented from being optional via a wh=
en
>> >>> statement. The context node should be the root node (document root) =
of
>> >>> the accessible tree, which should be determined the same as if the
>> >>> missing context node would represent state data.
>> >> I agree.
>> >
>> > The first two bullets in 7.19.5. should be corrected with text that
>> describes what happens when no data node ancestor can be found. They are
>> both affected.
>>
>> The definition of =E2=80=9Cwhen=E2=80=9D context has other problems that=
 need to be
>> addressed:
>>
>> 1. The XPath expression in the argument must not refer, even indirectly,
>> to the context node and its descendants.
>>
>> 2. The context node in the third bullet may not exist. Example:
>>
>> container top {
>>   leaf foo {
>>     type boolean;
>>   }
>>   leaf bar {
>>     when =E2=80=9C../foo =3D =E2=80=98true=E2=80=99=E2=80=9D;
>>     type uint8;
>>     default 42;
>>   }
>> }
>>
>> Now, if the instance document contains
>>
>> 
>>   false
>> 
>>
>> we get into a deadlock: the =E2=80=9Cwhen=E2=80=9D statement has no cont=
ext node, so it
>> cannot be evaluated and the =E2=80=9Cdefault=E2=80=9D statement applies,=
 but then the
>> context node starts to exist, so the =E2=80=9Cwhen=E2=80=9D statement ap=
plies, the server
>> removes  form the conceptual tree, and so on.
>>
>>
>
> These are just implementation details.
>
> (1) is just a boolean XPath expression that is always false

No, it can lead to deadlocks or race conditions, too. The action od deletin=
g the node with "when" expression being "false" (mandated by last bullet in=
 sec. 8.3.2) can lead to a situation where the same expression evaluates to=
 "true". Perhaps the simplest case is:

container top {
  when "not(foo)";
  leaf foo {
    type uint8;
    default 0;
  }
}

But there can be also various mutual dependences that would be very hard to=
 detect:

leaf foo {
  when "not(../bar)";
  type uint8;
  default 1;
}
leaf bar {
  when "not(../foo)";
  type uint8;
  default 2;
}

>
> (2) is just hard to implement. The server must know the XPath
> evaluation result even though the context node does not exist yet.

But it is then a non-standard XPath evaluation. In practical terms, it rend=
ers all off-the-shelf XPath processors and libraries unusable.

Lada=20

>
>
>
>> Lada
>>
>> >
>> > Jernej
>> >
>> >>
>> >>
>> >> /martin
>> >
>>
>
>
> Andy

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

From lhotka@nic.cz  Mon Jan 13 09:09:25 2014
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 824B21AE197 for ; Mon, 13 Jan 2014 09:09:25 -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 0g_3qs49DbbN for ; Mon, 13 Jan 2014 09:09:24 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0630D1ADFA3 for ; Mon, 13 Jan 2014 09:09:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 99634540402; Mon, 13 Jan 2014 18:09:12 +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 3YMRr4ZnPh6e; Mon, 13 Jan 2014 18:09:09 +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 043525400BE; Mon, 13 Jan 2014 18:09:08 +0100 (CET)
From: Ladislav Lhotka 
To: Benoit Claise , Randy Presuhn , netmod@ietf.org
In-Reply-To: <52D4038E.5080707@cisco.com>
References: <4913899.1389382088825.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> <52D4038E.5080707@cisco.com>
User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Mon, 13 Jan 2014 18:09:08 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 13 Jan 2014 17:09:25 -0000

Benoit Claise  writes:

> Dear all,
>
> On this errata, I'm unclear whether a clarification is needed.
> If it's the case, please update the errata and let me know.

It depends - if we can agree that option #1 below is the expected behaviour, then the erratum can be rejected, otherwise it should be accepted.

The single-quoted string works in any case though.

Lada 

>
> Regards, Benoit
>>> From: Ladislav Lhotka 
>>> Sent: Jan 10, 2014 7:16 AM
>>> To: Jernej Tuljak 
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported]	RFC6536 (3862)
>> ...
>>> IMO, current wording permits three defensible interpretations:
>>>
>>> 1. "\*" == '\*'
>>> 2. "\*" == '*'
>>> 3. "\*' is an error
>>>
>>> So this should be clarified.
>>>
>>> As I wrote, I'd prefer #3 because it would be the same as
>>> the behaviour of "\" in regex patterns.
>> Option #3 would also be the safest in case the need ever arises
>> in the future to define additional escape sequences, since doing
>> so would not change the meaning of any existing valid sequence.
>>
>> 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

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

From internet-drafts@ietf.org  Wed Jan 15 00:56:43 2014
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 3A3FF1AE354; Wed, 15 Jan 2014 00:56:43 -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 1JyKo8AzuKuQ; Wed, 15 Jan 2014 00:56:41 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E81B61AE2E5; Wed, 15 Jan 2014 00:56:41 -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.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140115085641.21885.35856.idtracker@ietfa.amsl.com>
Date: Wed, 15 Jan 2014 00:56:41 -0800
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-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: Wed, 15 Jan 2014 08:56:43 -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          : Martin Bjorklund
	Filename        : draft-ietf-netmod-iana-if-type-10.txt
	Pages           : 40
	Date            : 2014-01-15

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-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-iana-if-type-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 bclaise@cisco.com  Wed Jan 15 02:04:08 2014
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 065601AE304 for ; Wed, 15 Jan 2014 02:04:08 -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 GvLbWkW_yJCF for ; Wed, 15 Jan 2014 02:04:02 -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 D3E981AE02E for ; Wed, 15 Jan 2014 02:04:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1644; q=dns/txt; s=iport; t=1389780230; x=1390989830; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=WxBzniap6s1RYzr4nG4EDPIbI3IMbQRz7Bs/E4f63SQ=; b=cNjddLjem5Ig6Tm2p18xpRD0D/yhpisbHddy5hLP/xuW1SONY8M46Z3r 23h/Hy8GPWsKHzh5Q5/yWy9fpGqkQFxEde6o/BYXk/5GSK/Z/xUQoKrSt GKrONo5aFzzCb+/Qf+HY920AwgsZ8McuiDK9jn2bLX8P4TcaQTSQc7w61 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiwFAKVc1lKQ/khR/2dsb2JhbABagws4uwNPgRYWdIIlAQEBAwEBAQE1NhsLEQQBAQEJJQ8CFigIBgEMBgIBARCHaAgNw38TBI8OhDcBA5gehkWLUIFvgT87
X-IronPort-AV: E=Sophos;i="4.95,661,1384300800";  d="scan'208";a="2982394"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 15 Jan 2014 10:03:48 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0FA3mQY025562; Wed, 15 Jan 2014 10:03:48 GMT
Message-ID: <52D65D04.10409@cisco.com>
Date: Wed, 15 Jan 2014 11:03: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: Ladislav Lhotka , Randy Presuhn , netmod@ietf.org
References: <4913899.1389382088825.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> <52D4038E.5080707@cisco.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 15 Jan 2014 10:04:08 -0000

On 13/01/2014 18:09, Ladislav Lhotka wrote:
> Benoit Claise  writes:
>
>> Dear all,
>>
>> On this errata, I'm unclear whether a clarification is needed.
>> If it's the case, please update the errata and let me know.
> It depends - if we can agree that option #1 below is the expected behaviour, then the erratum can be rejected, otherwise it should be accepted.
So what's the next step? An agreement from this community?

Regards, Benoit

>
> The single-quoted string works in any case though.
>
> Lada
>
>> Regards, Benoit
>>>> From: Ladislav Lhotka 
>>>> Sent: Jan 10, 2014 7:16 AM
>>>> To: Jernej Tuljak 
>>>> Cc: netmod@ietf.org
>>>> Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported]	RFC6536 (3862)
>>> ...
>>>> IMO, current wording permits three defensible interpretations:
>>>>
>>>> 1. "\*" == '\*'
>>>> 2. "\*" == '*'
>>>> 3. "\*' is an error
>>>>
>>>> So this should be clarified.
>>>>
>>>> As I wrote, I'd prefer #3 because it would be the same as
>>>> the behaviour of "\" in regex patterns.
>>> Option #3 would also be the safest in case the need ever arises
>>> in the future to define additional escape sequences, since doing
>>> so would not change the meaning of any existing valid sequence.
>>>
>>> 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 iesg-secretary@ietf.org  Wed Jan 15 11:18:45 2014
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 BB0B21AE0FD; Wed, 15 Jan 2014 11:18:45 -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 HjYEeIG0m_p6; Wed, 15 Jan 2014 11:18:44 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 565191AE382; Wed, 15 Jan 2014 11:18:41 -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.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140115191841.23497.87624.idtracker@ietfa.amsl.com>
Date: Wed, 15 Jan 2014 11:18:41 -0800
Cc: netmod chair , netmod mailing list , RFC Editor 
Subject: [netmod] Protocol Action: 'IANA Interface Type YANG Module' to Proposed Standard (draft-ietf-netmod-iana-if-type-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: Wed, 15 Jan 2014 19:18:46 -0000

The IESG has approved the following document:
- 'IANA Interface Type YANG Module'
  (draft-ietf-netmod-iana-if-type-10.txt) as Proposed Standard

This document is the product of the NETCONF Data Modeling Language
Working Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/




Technical Summary

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

Working Group Summary

   The normal WG process was followed and the documents reflect WG
   consensus with nothing special worth mentioning except for the following.

   While the working group felt that the set of documents was complete in
   April 2013, there was a sense of unease about disparities between
   operational state and configuration. Additional reviews during the last
   call made it clear that it was desirable to deal with this by separating
   operational state from configuration management and that this should have
   been done from the beginning. The working group pulled the document back
   from IESG review and worked to add this to the model.

Document Quality

  This set of documents received extensive review within the working group
  and ample time was spent to review and reconsider all design choices.
  The working group also reached out to the IP directorate and received
  additional review from Dave Thaler.

Personnel

  David Kessens is the document shepherd.
  Benoit Claise is the responsible Area Director. 


From j.schoenwaelder@jacobs-university.de  Thu Jan 16 01:28:45 2014
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 B91441AE0A5 for ; Thu, 16 Jan 2014 01:28:45 -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 P4Q-BWbFijsU for ; Thu, 16 Jan 2014 01:28:44 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C4AB81ACCF6 for ; Thu, 16 Jan 2014 01:28:43 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B02E20048; Thu, 16 Jan 2014 10:28:30 +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 RrPL0Hyb6WnR; Thu, 16 Jan 2014 10:28:30 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A94B2004A; Thu, 16 Jan 2014 10:28:29 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 55BB62AA69BC; Thu, 16 Jan 2014 10:28:26 +0100 (CET)
Date: Thu, 16 Jan 2014 10:28:25 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund , Andy Bierman , Jeffrey Lange , Paul Eggert , Eliot Lear , Benoit Claise , SM 
Message-ID: <20140116092825.GA1348@elstar.local>
Mail-Followup-To: Martin Bjorklund , Andy Bierman , Jeffrey Lange , Paul Eggert , Eliot Lear , Benoit Claise , SM , 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] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 09:28:45 -0000

Hi,

I like to see whether we can close the technical discussions around
, which is used by
. Let me try to summarize where we
are. Since emails were exchanged between different groups of people, I
think it is necessary to synchronize so that everybody involved is on
the same page. I am trying to summarize where I think we are. I might
get certain details wrong - if so, please correct me. If I left
someone out of the To: line, please let me know as well.

* Overall Goal

  I believe there is agreement that timezone should be configurable
  using the so called Olson database timezone names (e.g.,
  'Europe/London'). This is what the timezone-location leaf in
   tries to achieve.

* Current Solution ()

  The current I-Ds propose to have a YANG enumeration of timezone
  names, essentially a serialization of the so called Olson database
  timezone names into a YANG enumeration. The Olson database is
  currently maintained by Paul Eggert, who serves as the TZ
  Coordinator, an IANA Designated Expert as defined in RFC 6557. The
  enumeration of timezone names in 
  resulted in two technical discussion points:

  a) YANG requires that an enumerated string value is always
     associated with a number. If no number is explicitly assigned,
     YANG assigns numbers implicitly but for this to work the order
     of listed enums may not change. Hence, to avoid brittleness when
     YANG modules are revised, it is good practice to assign explicit
     numbers. Unfortunately, the timezone database does not maintain
     such numbers. Options to fix this:

     - Add numeric identifiers to the timezone names as part of the
       timezone database. Increases work for the TZ coordinator and
       they are not needed for any other purpose.
     - Generate likely unique numbers using a hash function. To
       guarantee uniqueness, the TZ coordinator would have to verify
       that hashes do not collide if new timezone names are
       introduced.
     - Generate numbers from the coordinates (second column in the
       zone.tab file), e.g., encoding the coordinates in some way into
       a 32-bit integer. This may lead to issues if coordinates of a
       zone name are updated (not sure this happens).

  b) Timezone names are sometimes (although rarely) added or deleted
     from the timezone database. The timezone database documents the
     current state, it does not track the history by itself. YANG
     modules, however, do version management internally by deprecating
     and obsoleting definitions. This means, whenever timezone names
     are added or deleted, the TZ coordinator would have to do some
     extra work in order to provide that information (either to a tool
     that generates a new version of the YANG module or by maintenance
     of the YANG serialization directly manually).

  A solution to a) and b) is required in order to move forward with
   and the solution must be
  simple enough so that it can be maintained over years with
  potentially different TZ Coordinators involved.

* Alternative Solution

  If we fail to produce a viable solution for a) and b), then an
  obvious fallback solution would be to simply define a YANG type such
  as

    typedef timezone-name {
      type string;
      description
       "A timezone name as used by the Time Zone Database, sometimes
        referred to as the 'Olson Database'.";
      reference
       "RFC 6557: Procedures for Maintaining the Time Zone Database";
    }

  and to use this type in the timezone-location leaf in
  . Generic tools would not have
  knowledge about the set of possible timezone names but tools that
  have been coded to understand this typedef could of course reach out
  to the timezone database to get access to the set of possible
  timezone names. If we were to adopt this solution, we would pull
  back  and let it expire.

I think we need to decide in a timely manner whether we can find a
workable solution for the 'Current Solution' addressing a) and b) or
whether we give up on it and instead use a timezone-name typedef as
suggested above in the 'Alternative Solution'.

/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  Thu Jan 16 01:51:27 2014
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 9771A1AE2E7 for ; Thu, 16 Jan 2014 01:51:27 -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 eAy_iFfUBmfr for ; Thu, 16 Jan 2014 01:51:25 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7A61AE1F5 for ; Thu, 16 Jan 2014 01:51:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9002254033E; Thu, 16 Jan 2014 10:51:11 +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 VAN0ArW1X33j; Thu, 16 Jan 2014 10:51:07 +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 933C654018D; Thu, 16 Jan 2014 10:51:03 +0100 (CET)
From: Ladislav Lhotka 
To: Benoit Claise , Randy Presuhn , netmod@ietf.org
In-Reply-To: <52D65D04.10409@cisco.com>
References: <4913899.1389382088825.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> <52D4038E.5080707@cisco.com>  <52D65D04.10409@cisco.com>
User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Thu, 16 Jan 2014 10:51:02 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 09:51:27 -0000

Benoit Claise  writes:

> On 13/01/2014 18:09, Ladislav Lhotka wrote:
>> Benoit Claise  writes:
>>
>>> Dear all,
>>>
>>> On this errata, I'm unclear whether a clarification is needed.
>>> If it's the case, please update the errata and let me know.
>> It depends - if we can agree that option #1 below is the expected behaviour, then the erratum can be rejected, otherwise it should be accepted.
> So what's the next step? An agreement from this community?

Yes, I guess. Or, alternatively, the errata could be accepted as Jernej sent them because the single-quoted string is correct in any case.

Lada

>
> Regards, Benoit
>
>>
>> The single-quoted string works in any case though.
>>
>> Lada
>>
>>> Regards, Benoit
>>>>> From: Ladislav Lhotka 
>>>>> Sent: Jan 10, 2014 7:16 AM
>>>>> To: Jernej Tuljak 
>>>>> Cc: netmod@ietf.org
>>>>> Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported]	RFC6536 (3862)
>>>> ...
>>>>> IMO, current wording permits three defensible interpretations:
>>>>>
>>>>> 1. "\*" == '\*'
>>>>> 2. "\*" == '*'
>>>>> 3. "\*' is an error
>>>>>
>>>>> So this should be clarified.
>>>>>
>>>>> As I wrote, I'd prefer #3 because it would be the same as
>>>>> the behaviour of "\" in regex patterns.
>>>> Option #3 would also be the safest in case the need ever arises
>>>> in the future to define additional escape sequences, since doing
>>>> so would not change the meaning of any existing valid sequence.
>>>>
>>>> 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
>

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

From mbj@tail-f.com  Thu Jan 16 01:52:23 2014
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 733EE1AE1F5 for ; Thu, 16 Jan 2014 01:52:23 -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 71hJfany86iR for ; Thu, 16 Jan 2014 01:52:21 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 76C8A1AE2FA for ; Thu, 16 Jan 2014 01:52:21 -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 AA92B240C32E; Thu, 16 Jan 2014 10:52:08 +0100 (CET)
Date: Thu, 16 Jan 2014 10:52:08 +0100 (CET)
Message-Id: <20140116.105208.698977392599000511.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20140116092825.GA1348@elstar.local>
References: <20140116092825.GA1348@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: eggert@cs.ucla.edu, netmod@ietf.org, lear@cisco.com, sm@resistor.net
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 09:52:23 -0000

Hi,

Juergen Schoenwaelder  wrote:
> Hi,
> 
> I like to see whether we can close the technical discussions around
> , which is used by
> . Let me try to summarize where we
> are. Since emails were exchanged between different groups of people, I
> think it is necessary to synchronize so that everybody involved is on
> the same page. I am trying to summarize where I think we are. I might
> get certain details wrong - if so, please correct me. If I left
> someone out of the To: line, please let me know as well.
> 
> * Overall Goal
> 
>   I believe there is agreement that timezone should be configurable
>   using the so called Olson database timezone names (e.g.,
>   'Europe/London'). This is what the timezone-location leaf in
>    tries to achieve.
> 
> * Current Solution ()
> 
>   The current I-Ds propose to have a YANG enumeration of timezone
>   names, essentially a serialization of the so called Olson database
>   timezone names into a YANG enumeration. The Olson database is
>   currently maintained by Paul Eggert, who serves as the TZ
>   Coordinator, an IANA Designated Expert as defined in RFC 6557. The
>   enumeration of timezone names in 
>   resulted in two technical discussion points:
> 
>   a) YANG requires that an enumerated string value is always
>      associated with a number. If no number is explicitly assigned,
>      YANG assigns numbers implicitly but for this to work the order
>      of listed enums may not change. Hence, to avoid brittleness when
>      YANG modules are revised, it is good practice to assign explicit
>      numbers. Unfortunately, the timezone database does not maintain
>      such numbers. Options to fix this:
> 
>      - Add numeric identifiers to the timezone names as part of the
>        timezone database. Increases work for the TZ coordinator and
>        they are not needed for any other purpose.
>      - Generate likely unique numbers using a hash function. To
>        guarantee uniqueness, the TZ coordinator would have to verify
>        that hashes do not collide if new timezone names are
>        introduced.
>      - Generate numbers from the coordinates (second column in the
>        zone.tab file), e.g., encoding the coordinates in some way into
>        a 32-bit integer. This may lead to issues if coordinates of a
>        zone name are updated (not sure this happens).

Another option is to let the numbers live only in the YANG module.
I.e., use the previous version of the YANG module ("the IANA
resgitry") as input when new timezone locations are added.

>   b) Timezone names are sometimes (although rarely) added or deleted
>      from the timezone database.

I did a quick check, and it seems 3 were deleted and 3 added during
2012 and 2013.

>      The timezone database documents the
>      current state, it does not track the history by itself. YANG
>      modules, however, do version management internally by deprecating
>      and obsoleting definitions. This means, whenever timezone names
>      are added or deleted, the TZ coordinator would have to do some
>      extra work in order to provide that information (either to a tool
>      that generates a new version of the YANG module or by maintenance
>      of the YANG serialization directly manually).

The current document explains what has to be done.  It is fairly
trivial to write a program that takes as input the current YANG module
and the new zone.tab file, and generate an updated YANG module if
needed.

So when the TZ coordinator publishes a new version of the database, he
would first run this program, and send a new YANG module to IANA, if
needed.



/martin

From per@tail-f.com  Thu Jan 16 02:16:27 2014
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 9C8221AE314 for ; Thu, 16 Jan 2014 02:16:27 -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 WE84XOirn8sv for ; Thu, 16 Jan 2014 02:16:26 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 550F21AE30E for ; Thu, 16 Jan 2014 02:16:26 -0800 (PST)
Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id BD34637C0FC; Thu, 16 Jan 2014 11:16:13 +0100 (CET)
Message-ID: <52D7B16D.1000803@tail-f.com>
Date: Thu, 16 Jan 2014 11:16:13 +0100
From: Per Hedeland 
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7
MIME-Version: 1.0
To: Martin Bjorklund 
References: <20140116092825.GA1348@elstar.local> <20140116.105208.698977392599000511.mbj@tail-f.com>
In-Reply-To: <20140116.105208.698977392599000511.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: sm@resistor.net, eggert@cs.ucla.edu, lear@cisco.com, netmod@ietf.org
Subject: Re: [netmod] technical discussion around	draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 10:16:27 -0000

On 2014-01-16 10:52, Martin Bjorklund wrote:
> Hi,
> 
> Juergen Schoenwaelder  wrote:
>> Hi,

>>   a) YANG requires that an enumerated string value is always
>>      associated with a number. If no number is explicitly assigned,
>>      YANG assigns numbers implicitly but for this to work the order
>>      of listed enums may not change. Hence, to avoid brittleness when
>>      YANG modules are revised, it is good practice to assign explicit
>>      numbers. Unfortunately, the timezone database does not maintain
>>      such numbers. Options to fix this:
>>
>>      - Add numeric identifiers to the timezone names as part of the
>>        timezone database. Increases work for the TZ coordinator and
>>        they are not needed for any other purpose.
>>      - Generate likely unique numbers using a hash function. To
>>        guarantee uniqueness, the TZ coordinator would have to verify
>>        that hashes do not collide if new timezone names are
>>        introduced.
>>      - Generate numbers from the coordinates (second column in the
>>        zone.tab file), e.g., encoding the coordinates in some way into
>>        a 32-bit integer. This may lead to issues if coordinates of a
>>        zone name are updated (not sure this happens).
> 
> Another option is to let the numbers live only in the YANG module.
> I.e., use the previous version of the YANG module ("the IANA
> resgitry") as input when new timezone locations are added.

+1. This option seems both simpler to implement and more robust than the
others.

--Per Hedeland

From j.schoenwaelder@jacobs-university.de  Thu Jan 16 02:38:26 2014
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 9B4951AE138 for ; Thu, 16 Jan 2014 02:38:26 -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 5aHyjGN7XpTK for ; Thu, 16 Jan 2014 02:38:24 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 823E61AE203 for ; Thu, 16 Jan 2014 02:38:24 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49CF22004B; Thu, 16 Jan 2014 11:38:12 +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 cE29WB3Elky8; Thu, 16 Jan 2014 11:38:12 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA2D820040; Thu, 16 Jan 2014 11:38:11 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C97F12AA6D7E; Thu, 16 Jan 2014 11:38:08 +0100 (CET)
Date: Thu, 16 Jan 2014 11:38:08 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140116103807.GC1528@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Benoit Claise , Randy Presuhn , netmod@ietf.org
References: <4913899.1389382088825.JavaMail.root@mswamui-thinleaf.atl.sa.earthlink.net> <52D4038E.5080707@cisco.com>  <52D65D04.10409@cisco.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 10:38:26 -0000

On Thu, Jan 16, 2014 at 10:51:02AM +0100, Ladislav Lhotka wrote:
> 
> Yes, I guess. Or, alternatively, the errata could be accepted as Jernej sent them because the single-quoted string is correct in any case.
> 

Makes sense to me. My take is that the behavior of backslashes in
double quoted strings that are not defined escape sequences is not
well enough defined in RFC 6020 and as such avoiding this is a good
thing to improve interoperability (and luckily we can avoid it).

/js

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

From mbj@tail-f.com  Thu Jan 16 03:08:51 2014
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 46F871AE2D2 for ; Thu, 16 Jan 2014 03:08:51 -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 IbE29yM97P-E for ; Thu, 16 Jan 2014 03:08: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 14C471AE237 for ; Thu, 16 Jan 2014 03:08: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 58D5F240C31C; Thu, 16 Jan 2014 12:08:37 +0100 (CET)
Date: Thu, 16 Jan 2014 12:08:37 +0100 (CET)
Message-Id: <20140116.120837.2141720677709595088.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20140116103807.GC1528@elstar.local>
References: <52D65D04.10409@cisco.com>  <20140116103807.GC1528@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] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 11:08:51 -0000

Juergen Schoenwaelder  wrote:
> On Thu, Jan 16, 2014 at 10:51:02AM +0100, Ladislav Lhotka wrote:
> > 
> > Yes, I guess. Or, alternatively, the errata could be accepted as
> > Jernej sent them because the single-quoted string is correct in any
> > case.
> > 
> 
> Makes sense to me.

So what does it mean that the YANG module is modified by an errata?
The YANG file that people use will have the revison 2012-02-22.  Are
you saying that there are now two slightly different versions of this
revision?

I do agree that we should avoid this situation in future modules.


/martin


From lhotka@nic.cz  Thu Jan 16 03:13:09 2014
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 4E2081AE084 for ; Thu, 16 Jan 2014 03:13:09 -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 xVuYYzHL4EI4 for ; Thu, 16 Jan 2014 03:13:08 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CA1421AE2D2 for ; Thu, 16 Jan 2014 03:13:07 -0800 (PST)
Received: from [IPv6:2001:1488:ac14:1400:a5c1:99bd:369b:96a2] (unknown [IPv6:2001:1488:ac14:1400:a5c1:99bd:369b:96a2]) by mail.nic.cz (Postfix) with ESMTPSA id 5118D13F8B2; Thu, 16 Jan 2014 12:12:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1389870774; bh=Hozo7TMh6Ck31SIDh0RRABEktObrySk50mhaL/2Wnxo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=w6M8dSPthb0VxKX/pRut4aONgPrIJxUJVTxq9eMpyR5PDeXLdbnA43pmZ10qcB5j+ ExeywSEtaA4Rb+4nhxcfkl1yIR88sAp+FkKYc3VmijsQJ/d8WhTj7fPJN1ywlqYRsf yZedzxup0Zym2LiXa8VnTyqhxBfctMa9UjIPlVDo=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140116.120837.2141720677709595088.mbj@tail-f.com>
Date: Thu, 16 Jan 2014 12:12:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <52D65D04.10409@cisco.com>  <20140116103807.GC1528@elstar.local> <20140116.120837.2141720677709595088.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: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 11:13:09 -0000

On 16 Jan 2014, at 12:08, Martin Bjorklund  wrote:

> Juergen Schoenwaelder  wrote:
>> On Thu, Jan 16, 2014 at 10:51:02AM +0100, Ladislav Lhotka wrote:
>>>=20
>>> Yes, I guess. Or, alternatively, the errata could be accepted as
>>> Jernej sent them because the single-quoted string is correct in any
>>> case.
>>>=20
>>=20
>> Makes sense to me.
>=20
> So what does it mean that the YANG module is modified by an errata?
> The YANG file that people use will have the revison 2012-02-22.  Are
> you saying that there are now two slightly different versions of this
> revision?

That=92s a good question. I think the revision should be bumped, too, =
because the two versions might potentially behave differently.

Lada

>=20
> I do agree that we should avoid this situation in future modules.
>=20
>=20
> /martin
>=20

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





From jernej.tuljak@mg-soft.si  Thu Jan 16 03:17:05 2014
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 716211AE2E9 for ; Thu, 16 Jan 2014 03:17:05 -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 sXk19w4muFnc for ; Thu, 16 Jan 2014 03:17:03 -0800 (PST)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id DE53D1AE2E7 for ; Thu, 16 Jan 2014 03:17:02 -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 s0GBGnBc028682; Thu, 16 Jan 2014 12:16:49 +0100
Message-ID: <52D7BF9E.5090506@mg-soft.com>
Date: Thu, 16 Jan 2014 12:16:46 +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: Ladislav Lhotka 
References: <52D65D04.10409@cisco.com>  <20140116103807.GC1528@elstar.local> <20140116.120837.2141720677709595088.mbj@tail-f.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 11:17:05 -0000

Dne 16.1.2014 12:12, piše Ladislav Lhotka:
> On 16 Jan 2014, at 12:08, Martin Bjorklund  wrote:
>
>> Juergen Schoenwaelder  wrote:
>>> On Thu, Jan 16, 2014 at 10:51:02AM +0100, Ladislav Lhotka wrote:
>>>> Yes, I guess. Or, alternatively, the errata could be accepted as
>>>> Jernej sent them because the single-quoted string is correct in any
>>>> case.
>>>>
>>> Makes sense to me.
>> So what does it mean that the YANG module is modified by an errata?
>> The YANG file that people use will have the revison 2012-02-22.  Are
>> you saying that there are now two slightly different versions of this
>> revision?
> That’s a good question. I think the revision should be bumped, too, because the two versions might potentially behave differently.

Would this be a valid YANG module update (Section 10)?

Jernej

>
> Lada
>
>> I do agree that we should avoid this situation in future modules.
>>
>>
>> /martin
>>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From j.schoenwaelder@jacobs-university.de  Thu Jan 16 03:17:23 2014
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 1D3EA1AE2E7 for ; Thu, 16 Jan 2014 03:17:23 -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 eeOZbOo_EeuW for ; Thu, 16 Jan 2014 03:17:21 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5FF1AE07C for ; Thu, 16 Jan 2014 03:17:21 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3093920059; Thu, 16 Jan 2014 12:17:09 +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 SCL6xYIQdIWb; Thu, 16 Jan 2014 12:17:09 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92F3120054; Thu, 16 Jan 2014 12:17:08 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id D0AEF2AA6F26; Thu, 16 Jan 2014 12:17:05 +0100 (CET)
Date: Thu, 16 Jan 2014 12:17:05 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20140116111705.GA1696@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, randy_presuhn@mindspring.com, netmod@ietf.org
References: <52D65D04.10409@cisco.com>  <20140116103807.GC1528@elstar.local> <20140116.120837.2141720677709595088.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140116.120837.2141720677709595088.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 11:17:23 -0000

On Thu, Jan 16, 2014 at 12:08:37PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Thu, Jan 16, 2014 at 10:51:02AM +0100, Ladislav Lhotka wrote:
> > > 
> > > Yes, I guess. Or, alternatively, the errata could be accepted as
> > > Jernej sent them because the single-quoted string is correct in any
> > > case.
> > > 
> > 
> > Makes sense to me.
> 
> So what does it mean that the YANG module is modified by an errata?
> The YANG file that people use will have the revison 2012-02-22.  Are
> you saying that there are now two slightly different versions of this
> revision?

Are you suggesting there never can be any erratum to any YANG module
ever since this essentially creates a new version?

I do not see that this change introduces a technical difference -
except that with the erratum applied, the likelihood increases that
YANG parsers will show the same behaviour.

/js

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

From j.schoenwaelder@jacobs-university.de  Thu Jan 16 03:22:08 2014
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 8D6381AE2FD for ; Thu, 16 Jan 2014 03:22:08 -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 6O3hGr5GCsuo for ; Thu, 16 Jan 2014 03:22: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 608621AE2E7 for ; Thu, 16 Jan 2014 03:22:07 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2504920054; Thu, 16 Jan 2014 12:21:55 +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 h-0WFIi8BpXo; Thu, 16 Jan 2014 12:21:55 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC9A820045; Thu, 16 Jan 2014 12:21:54 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 9EB6D2AA6FED; Thu, 16 Jan 2014 12:21:52 +0100 (CET)
Date: Thu, 16 Jan 2014 12:21:52 +0100
From: Juergen Schoenwaelder 
To: Randy Presuhn 
Message-ID: <20140116112152.GB1696@elstar.local>
Mail-Followup-To: Randy Presuhn , netmod@ietf.org
References: <7127897.1389314730956.JavaMail.root@mswamui-andean.atl.sa.earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7127897.1389314730956.JavaMail.root@mswamui-andean.atl.sa.earthlink.net>
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: Thu, 16 Jan 2014 11:22:08 -0000

On Thu, Jan 09, 2014 at 04:45:30PM -0800, Randy Presuhn wrote:
> Hi -
> >
> >But you can't delete vacmGroupName.3.3.b.o.b with SNMP either.
> 
> Yes you can, but that's irrelevant. 

I do wonder how though (even though it might be irrelevant).

/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  Thu Jan 16 03:23:47 2014
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 258D31AE2FD for ; Thu, 16 Jan 2014 03:23:47 -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 RM_kkfcVJOjv for ; Thu, 16 Jan 2014 03:23: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 EF2391AE2E7 for ; Thu, 16 Jan 2014 03:23:45 -0800 (PST)
Received: from [IPv6:2001:1488:ac14:1400:a5c1:99bd:369b:96a2] (unknown [IPv6:2001:1488:ac14:1400:a5c1:99bd:369b:96a2]) by mail.nic.cz (Postfix) with ESMTPSA id 7D0CA13F8B2; Thu, 16 Jan 2014 12:23:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1389871413; bh=2LHFPKqe1ka9vLnCgTGaKN6URljoraYra3+yIxd7hTg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ecxLriQGDnjx+iAw+C7c3c0Ef3ydUByM9VTFUDOiaRGQW51xtkJU61Lcn/WEED7u+ iU+NanivHeK/x2EpvZoj1rG+o9MHRAeAkDU9yBm70dMbWjY7D1Y5mR3hKIjLHs5NtP FNuQhfLEAygr5OB0wbRBjuHBE9Y3U4zxZ3L7KO8k=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140116111705.GA1696@elstar.local>
Date: Thu, 16 Jan 2014 12:23:33 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9907C338-0D65-4073-87E0-F9180C1DD579@nic.cz>
References: <52D65D04.10409@cisco.com>  <20140116103807.GC1528@elstar.local> <20140116.120837.2141720677709595088.mbj@tail-f.com> <20140116111705.GA1696@elstar.local>
To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 11:23:47 -0000

On 16 Jan 2014, at 12:17, Juergen Schoenwaelder =
 wrote:

> On Thu, Jan 16, 2014 at 12:08:37PM +0100, Martin Bjorklund wrote:
>> Juergen Schoenwaelder  wrote:
>>> On Thu, Jan 16, 2014 at 10:51:02AM +0100, Ladislav Lhotka wrote:
>>>>=20
>>>> Yes, I guess. Or, alternatively, the errata could be accepted as
>>>> Jernej sent them because the single-quoted string is correct in any
>>>> case.
>>>>=20
>>>=20
>>> Makes sense to me.
>>=20
>> So what does it mean that the YANG module is modified by an errata?
>> The YANG file that people use will have the revison 2012-02-22.  Are
>> you saying that there are now two slightly different versions of this
>> revision?
>=20
> Are you suggesting there never can be any erratum to any YANG module
> ever since this essentially creates a new version?
>=20
> I do not see that this change introduces a technical difference -
> except that with the erratum applied, the likelihood increases that
> YANG parsers will show the same behaviour.

On the other hand, a parser can exhibit different behaviour with each =
version, depending on its approach to double-quoted escapes.

Lada

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

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





From mbj@tail-f.com  Thu Jan 16 03:29:20 2014
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 CA1371AE303 for ; Thu, 16 Jan 2014 03:29:20 -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 5KW4XvL054yR for ; Thu, 16 Jan 2014 03:29:19 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7DABE1AE2FD for ; Thu, 16 Jan 2014 03:29:19 -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 1BB0F240C31C; Thu, 16 Jan 2014 12:29:07 +0100 (CET)
Date: Thu, 16 Jan 2014 12:29:06 +0100 (CET)
Message-Id: <20140116.122906.1529489901441363143.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20140116111705.GA1696@elstar.local>
References: <20140116103807.GC1528@elstar.local> <20140116.120837.2141720677709595088.mbj@tail-f.com> <20140116111705.GA1696@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] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 11:29:21 -0000

Juergen Schoenwaelder  wrote:
> On Thu, Jan 16, 2014 at 12:08:37PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Thu, Jan 16, 2014 at 10:51:02AM +0100, Ladislav Lhotka wrote:
> > > > 
> > > > Yes, I guess. Or, alternatively, the errata could be accepted as
> > > > Jernej sent them because the single-quoted string is correct in any
> > > > case.
> > > > 
> > > 
> > > Makes sense to me.
> > 
> > So what does it mean that the YANG module is modified by an errata?
> > The YANG file that people use will have the revison 2012-02-22.  Are
> > you saying that there are now two slightly different versions of this
> > revision?
> 
> Are you suggesting there never can be any erratum to any YANG module
> ever since this essentially creates a new version?

I think so.  The new version should have a new revision.

Has this situation happened with MIBs?

> I do not see that this change introduces a technical difference -
> except that with the erratum applied, the likelihood increases that
> YANG parsers will show the same behaviour.

If two parsers behave differently, and we think that they both are
6020 compliant, then we did introduce a technical difference.

IMO it would be better to publish an errata to 6020, like Jernej
suggested.  (He suggested:

   Within a double-quoted string (enclosed within " "), a backslash
   character may introduce a special character, which depends on the
   character that immediately follows the backslash:
)


/martin


From j.schoenwaelder@jacobs-university.de  Thu Jan 16 03:30:00 2014
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 CBCCA1AE313 for ; Thu, 16 Jan 2014 03:30:00 -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 p5WwkTWdCkMp for ; Thu, 16 Jan 2014 03:29:59 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 499E31AE2FD for ; Thu, 16 Jan 2014 03:29:59 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F93820054; Thu, 16 Jan 2014 12:29:47 +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 qsVvQw552GrR; Thu, 16 Jan 2014 12:29: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 78AD620045; Thu, 16 Jan 2014 12:29:46 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 6A2B62AA707B; Thu, 16 Jan 2014 12:29:44 +0100 (CET)
Date: Thu, 16 Jan 2014 12:29:44 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140116112944.GC1696@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , Randy Presuhn , netmod@ietf.org
References: <52D65D04.10409@cisco.com>  <20140116103807.GC1528@elstar.local> <20140116.120837.2141720677709595088.mbj@tail-f.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 11:30:01 -0000

On Thu, Jan 16, 2014 at 12:12:53PM +0100, Ladislav Lhotka wrote:
> 
> On 16 Jan 2014, at 12:08, Martin Bjorklund  wrote:
> 
> > Juergen Schoenwaelder  wrote:
> >> On Thu, Jan 16, 2014 at 10:51:02AM +0100, Ladislav Lhotka wrote:
> >>> 
> >>> Yes, I guess. Or, alternatively, the errata could be accepted as
> >>> Jernej sent them because the single-quoted string is correct in any
> >>> case.
> >>> 
> >> 
> >> Makes sense to me.
> > 
> > So what does it mean that the YANG module is modified by an errata?
> > The YANG file that people use will have the revison 2012-02-22.  Are
> > you saying that there are now two slightly different versions of this
> > revision?
> 
> That’s a good question. I think the revision should be bumped, too, because the two versions might potentially behave differently.
> 

I do not think we should go there. Then I propose to mark this erratum
as "Held for Document Update" and to move on. I do not think we should
use errata to create revisions of YANG modules - this will be hard to
track.

If we conclude that RFC 6020 is not fully clear about the
interpretation of non-escape backslash sequences, I would expect that
implementations will be prepared to make a reasonable decision, which
may involve throwing warnings but not errors and to process the module
using a 'best guess' interpretation or resorting to user input instead
of a machine generated 'best guess'.

/js

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

From j.schoenwaelder@jacobs-university.de  Thu Jan 16 03:36:49 2014
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 113A31AE313 for ; Thu, 16 Jan 2014 03:36:49 -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 tRw2pybzcOJm for ; Thu, 16 Jan 2014 03: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 952091AE2FD for ; Thu, 16 Jan 2014 03:36:47 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 581B82005C; Thu, 16 Jan 2014 12:36:35 +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 bBQ_gVQIX_AC; Thu, 16 Jan 2014 12:36: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 E11B920059; Thu, 16 Jan 2014 12:36:34 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id D1B7A2AA7101; Thu, 16 Jan 2014 12:36:32 +0100 (CET)
Date: Thu, 16 Jan 2014 12:36:32 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20140116113632.GA1783@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, randy_presuhn@mindspring.com, netmod@ietf.org
References: <20140116103807.GC1528@elstar.local> <20140116.120837.2141720677709595088.mbj@tail-f.com> <20140116111705.GA1696@elstar.local> <20140116.122906.1529489901441363143.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140116.122906.1529489901441363143.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 11:36:49 -0000

On Thu, Jan 16, 2014 at 12:29:06PM +0100, Martin Bjorklund wrote:

> > Are you suggesting there never can be any erratum to any YANG module
> > ever since this essentially creates a new version?
> 
> I think so.  The new version should have a new revision.
> 
> Has this situation happened with MIBs?

I am reasonably sure. I do not recall that I have seen an update of
the LAST-UPDATE clause for that reason in an erratum.
 
> > I do not see that this change introduces a technical difference -
> > except that with the erratum applied, the likelihood increases that
> > YANG parsers will show the same behaviour.
> 
> If two parsers behave differently, and we think that they both are
> 6020 compliant, then we did introduce a technical difference.

My take is that 6020 is ambiguous here. So as a matter of that, two
deployed parsers may happen to behave differently - this is what you
get our of RFC 6020.

> IMO it would be better to publish an errata to 6020, like Jernej
> suggested.

So far I have not see a clear resolution what the intended behaviour
is. Apparently implementations deal with this differently - so how do
we manage to declare some of them not compliant?

/js

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

From mbj@tail-f.com  Thu Jan 16 04:59:20 2014
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 8D1DF1AE338 for ; Thu, 16 Jan 2014 04:59:20 -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 oQHj-gg991ck for ; Thu, 16 Jan 2014 04:59:19 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4391AE31D for ; Thu, 16 Jan 2014 04:59:19 -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 3CEBD37C0FE; Thu, 16 Jan 2014 13:59:06 +0100 (CET)
Date: Thu, 16 Jan 2014 13:59:06 +0100 (CET)
Message-Id: <20140116.135906.2039988908661941403.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20140116113632.GA1783@elstar.local>
References: <20140116111705.GA1696@elstar.local> <20140116.122906.1529489901441363143.mbj@tail-f.com> <20140116113632.GA1783@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] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 12:59:20 -0000

Juergen Schoenwaelder  wrote:
> On Thu, Jan 16, 2014 at 12:29:06PM +0100, Martin Bjorklund wrote:
> 
> > > Are you suggesting there never can be any erratum to any YANG module
> > > ever since this essentially creates a new version?
> > 
> > I think so.  The new version should have a new revision.
> > 
> > Has this situation happened with MIBs?
> 
> I am reasonably sure. I do not recall that I have seen an update of
> the LAST-UPDATE clause for that reason in an erratum.

Ok, searching the Errata I found a few.  Even this:

http://www.rfc-editor.org/errata_search.php?eid=334

I noticed that the mib that gets distributed with libsmi doesn't have
this change.  This is of course the risk of doing such changes...

One might argue that the fix we're talking about is much less
intrusive...



/martin

From lhotka@nic.cz  Thu Jan 16 04:59:59 2014
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 1C1061AE346 for ; Thu, 16 Jan 2014 04:59:59 -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 wkqElH6QE4In for ; Thu, 16 Jan 2014 04:59:57 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B7B761AE34E for ; Thu, 16 Jan 2014 04:59:54 -0800 (PST)
Received: from labs.ladislav.lhotka.nb.wifi.1.office.nic.cz (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id C586D13FB62; Thu, 16 Jan 2014 13:59:41 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1389877181; bh=u/e+vRKZBeA087KbtXr1fseEhR3Vf84BnREX62ELVBk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nR+L0oK/0eOwlUDnNMWmO61Yog4ZSGa9x6N0RxsjryL8Uz7nwIrhC6iZPrVjU6i7/ JPUyfu7NHxOVFQBr10X1vq52kcvNgkdlCFIikyTKar0TBuOO+UB3Pw6FlcSVK483gj G/fyW6n4FBuszOvDwsKXx5M6+MCzb9scKCxJap5U=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140116113632.GA1783@elstar.local>
Date: Thu, 16 Jan 2014 13:59:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20140116103807.GC1528@elstar.local> <20140116.120837.2141720677709595088.mbj@tail-f.com> <20140116111705.GA1696@elstar.local> <20140116.122906.1529489901441363143.mbj@tail-f.com> <20140116113632.GA1783@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: Randy Presuhn , netmod@ietf.org
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 12:59:59 -0000

On 16 Jan 2014, at 12:36, Juergen Schoenwaelder =
 wrote:

> On Thu, Jan 16, 2014 at 12:29:06PM +0100, Martin Bjorklund wrote:
>=20
>>> Are you suggesting there never can be any erratum to any YANG module
>>> ever since this essentially creates a new version?
>>=20
>> I think so.  The new version should have a new revision.
>>=20
>> Has this situation happened with MIBs?
>=20
> I am reasonably sure. I do not recall that I have seen an update of
> the LAST-UPDATE clause for that reason in an erratum.
>=20
>>> I do not see that this change introduces a technical difference -
>>> except that with the erratum applied, the likelihood increases that
>>> YANG parsers will show the same behaviour.
>>=20
>> If two parsers behave differently, and we think that they both are
>> 6020 compliant, then we did introduce a technical difference.
>=20
> My take is that 6020 is ambiguous here. So as a matter of that, two
> deployed parsers may happen to behave differently - this is what you
> get our of RFC 6020.
>=20
>> IMO it would be better to publish an errata to 6020, like Jernej
>> suggested.
>=20
> So far I have not see a clear resolution what the intended behaviour
> is. Apparently implementations deal with this differently - so how do
> we manage to declare some of them not compliant?

I think an erratum to sec. 6.1.3 should clearly state the behaviour wrt =
to escapes that are not explicitly listed. Jernej=92s proposed text IMO =
isn=92t clear enough.

I assume that an accepted erratum becomes part of the RFC, so =
implementations that behave differently will be non-compliant and should =
be updated. But maybe there are some guidelines how to deal with =
technical ambiguity in RFCs.

Lada

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

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





From bclaise@cisco.com  Thu Jan 16 05:31:45 2014
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 B30881AE0BB for ; Thu, 16 Jan 2014 05:31:45 -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 a4UGzwCSpXPh for ; Thu, 16 Jan 2014 05:31:43 -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 46DC51AE349 for ; Thu, 16 Jan 2014 05:31:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5061; q=dns/txt; s=iport; t=1389879091; x=1391088691; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=JFKOfeHDVmbGiL+QbIBJtY12FXypioKuqWyGlF4D0Ds=; b=EzpAx2geH0GeoiVVJr25mbus4a9cRdwaeUVMK84cqZpzqau4dCrmdG/l zSruEY8StD9AmLUfGrJT5LRcY+D8wB6+W8bgZPMnbqZcNERXKSdPdDh8z IT0QO+21xTrP9ccm7KNA84+pf7bL6MH+P8kw0DgRsc2Ri10qjtuH7h7+3 Y=;
X-IronPort-AV: E=Sophos;i="4.95,667,1384300800";  d="scan'208";a="3717818"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 16 Jan 2014 13:31:30 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0GDVUE7003357; Thu, 16 Jan 2014 13:31:30 GMT
Message-ID: <52D7DF31.4000309@cisco.com>
Date: Thu, 16 Jan 2014 14:31:29 +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 , Andy Bierman , Jeffrey Lange , Paul Eggert , Eliot Lear , SM , netmod@ietf.org, Michelle Cotton 
References: <20140116092825.GA1348@elstar.local>
In-Reply-To: <20140116092825.GA1348@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 13:31:45 -0000

Juergen, Martin,

Thanks for starting the discussion.
Including Michelle Cotton, from IANA, in the discussion.
> Hi,
>
> I like to see whether we can close the technical discussions around
> , which is used by
> . Let me try to summarize where we
> are. Since emails were exchanged between different groups of people, I
> think it is necessary to synchronize so that everybody involved is on
> the same page. I am trying to summarize where I think we are. I might
> get certain details wrong - if so, please correct me. If I left
> someone out of the To: line, please let me know as well.
>
> * Overall Goal
>
>    I believe there is agreement that timezone should be configurable
>    using the so called Olson database timezone names (e.g.,
>    'Europe/London'). This is what the timezone-location leaf in
>     tries to achieve.
>
> * Current Solution ()
>
>    The current I-Ds propose to have a YANG enumeration of timezone
>    names, essentially a serialization of the so called Olson database
>    timezone names into a YANG enumeration. The Olson database is
>    currently maintained by Paul Eggert, who serves as the TZ
>    Coordinator, an IANA Designated Expert as defined in RFC 6557. The
>    enumeration of timezone names in 
>    resulted in two technical discussion points:
>
>    a) YANG requires that an enumerated string value is always
>       associated with a number. If no number is explicitly assigned,
>       YANG assigns numbers implicitly but for this to work the order
>       of listed enums may not change. Hence, to avoid brittleness when
>       YANG modules are revised, it is good practice to assign explicit
>       numbers. Unfortunately, the timezone database does not maintain
>       such numbers. Options to fix this:
>
>       - Add numeric identifiers to the timezone names as part of the
>         timezone database. Increases work for the TZ coordinator and
>         they are not needed for any other purpose.
>       - Generate likely unique numbers using a hash function. To
>         guarantee uniqueness, the TZ coordinator would have to verify
>         that hashes do not collide if new timezone names are
>         introduced.
>       - Generate numbers from the coordinates (second column in the
>         zone.tab file), e.g., encoding the coordinates in some way into
>         a 32-bit integer. This may lead to issues if coordinates of a
>         zone name are updated (not sure this happens).
>
>    b) Timezone names are sometimes (although rarely) added or deleted
>       from the timezone database. The timezone database documents the
>       current state, it does not track the history by itself. YANG
>       modules, however, do version management internally by deprecating
>       and obsoleting definitions. This means, whenever timezone names
>       are added or deleted, the TZ coordinator would have to do some
>       extra work in order to provide that information (either to a tool
>       that generates a new version of the YANG module or by maintenance
>       of the YANG serialization directly manually).
>
>    A solution to a) and b) is required in order to move forward with
>     and the solution must be
>    simple enough so that it can be maintained over years with
>    potentially different TZ Coordinators involved.
And we must have an easy and repeatable procedure for IANA.
>
> * Alternative Solution
>
>    If we fail to produce a viable solution for a) and b), then an
>    obvious fallback solution would be to simply define a YANG type such
>    as
>
>      typedef timezone-name {
>        type string;
>        description
>         "A timezone name as used by the Time Zone Database, sometimes
>          referred to as the 'Olson Database'.";
>        reference
>         "RFC 6557: Procedures for Maintaining the Time Zone Database";
>      }
>
>    and to use this type in the timezone-location leaf in
>    .
This document is currently in IETF LC, and on the IESG telechat on Jan 23rd.
I guess I should remove it from the telechat?

Regards, Benoit
> Generic tools would not have
>    knowledge about the set of possible timezone names but tools that
>    have been coded to understand this typedef could of course reach out
>    to the timezone database to get access to the set of possible
>    timezone names. If we were to adopt this solution, we would pull
>    back  and let it expire.
>
> I think we need to decide in a timely manner whether we can find a
> workable solution for the 'Current Solution' addressing a) and b) or
> whether we give up on it and instead use a timezone-name typedef as
> suggested above in the 'Alternative Solution'.
>
> /js
>


From bclaise@cisco.com  Thu Jan 16 05:34:34 2014
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 CCDA01AE34C for ; Thu, 16 Jan 2014 05:34:34 -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 xsSqR2sJsZxb for ; Thu, 16 Jan 2014 05:34: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 C14C81AE349 for ; Thu, 16 Jan 2014 05:34:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4219; q=dns/txt; s=iport; t=1389879261; x=1391088861; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gBhGzMpHNw9qpIvKdP9KxO0qTE1z/mOFC9a/Chu+Ij8=; b=LgRshV/IfRBDWabhQc+vBcWJXfna5t/c8JayS4C3pZxrzDA9ebdb78x5 4d4hgRCWTkQdBpGYNJhnYT53Zk0nsiuILMYL0dgtUR+oN4X2n7Mus6g4q 4rQAmCQS9RAs/owl/tKNE88m4w37tmfqGw6wkqK+Hvt3pW1NhjP29H1FL o=;
X-IronPort-AV: E=Sophos;i="4.95,667,1384300800";  d="scan'208";a="3048723"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 16 Jan 2014 13:34:20 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0GDYJWT031140; Thu, 16 Jan 2014 13:34:19 GMT
Message-ID: <52D7DFDB.4050902@cisco.com>
Date: Thu, 16 Jan 2014 14:34:19 +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 , j.schoenwaelder@jacobs-university.de
References: <20140116092825.GA1348@elstar.local> <20140116.105208.698977392599000511.mbj@tail-f.com>
In-Reply-To: <20140116.105208.698977392599000511.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: eggert@cs.ucla.edu, lear@cisco.com, netmod@ietf.org, sm@resistor.net, Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 13:34:35 -0000

A question for Michelle in line.
> Hi,
>
> Juergen Schoenwaelder  wrote:
>> Hi,
>>
>> I like to see whether we can close the technical discussions around
>> , which is used by
>> . Let me try to summarize where we
>> are. Since emails were exchanged between different groups of people, I
>> think it is necessary to synchronize so that everybody involved is on
>> the same page. I am trying to summarize where I think we are. I might
>> get certain details wrong - if so, please correct me. If I left
>> someone out of the To: line, please let me know as well.
>>
>> * Overall Goal
>>
>>    I believe there is agreement that timezone should be configurable
>>    using the so called Olson database timezone names (e.g.,
>>    'Europe/London'). This is what the timezone-location leaf in
>>     tries to achieve.
>>
>> * Current Solution ()
>>
>>    The current I-Ds propose to have a YANG enumeration of timezone
>>    names, essentially a serialization of the so called Olson database
>>    timezone names into a YANG enumeration. The Olson database is
>>    currently maintained by Paul Eggert, who serves as the TZ
>>    Coordinator, an IANA Designated Expert as defined in RFC 6557. The
>>    enumeration of timezone names in 
>>    resulted in two technical discussion points:
>>
>>    a) YANG requires that an enumerated string value is always
>>       associated with a number. If no number is explicitly assigned,
>>       YANG assigns numbers implicitly but for this to work the order
>>       of listed enums may not change. Hence, to avoid brittleness when
>>       YANG modules are revised, it is good practice to assign explicit
>>       numbers. Unfortunately, the timezone database does not maintain
>>       such numbers. Options to fix this:
>>
>>       - Add numeric identifiers to the timezone names as part of the
>>         timezone database. Increases work for the TZ coordinator and
>>         they are not needed for any other purpose.
>>       - Generate likely unique numbers using a hash function. To
>>         guarantee uniqueness, the TZ coordinator would have to verify
>>         that hashes do not collide if new timezone names are
>>         introduced.
>>       - Generate numbers from the coordinates (second column in the
>>         zone.tab file), e.g., encoding the coordinates in some way into
>>         a 32-bit integer. This may lead to issues if coordinates of a
>>         zone name are updated (not sure this happens).
> Another option is to let the numbers live only in the YANG module.
> I.e., use the previous version of the YANG module ("the IANA
> resgitry") as input when new timezone locations are added.
>
>>    b) Timezone names are sometimes (although rarely) added or deleted
>>       from the timezone database.
> I did a quick check, and it seems 3 were deleted and 3 added during
> 2012 and 2013.
>
>>       The timezone database documents the
>>       current state, it does not track the history by itself. YANG
>>       modules, however, do version management internally by deprecating
>>       and obsoleting definitions. This means, whenever timezone names
>>       are added or deleted, the TZ coordinator would have to do some
>>       extra work in order to provide that information (either to a tool
>>       that generates a new version of the YANG module or by maintenance
>>       of the YANG serialization directly manually).
> The current document explains what has to be done.  It is fairly
> trivial to write a program that takes as input the current YANG module
> and the new zone.tab file, and generate an updated YANG module if
> needed.
>
> So when the TZ coordinator publishes a new version of the database, he
> would first run this program, and send a new YANG module to IANA, if
> needed.
Michelle, would this procedure work for IANA?
Alternatively, does IANA work with such a program/script?

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


From j.schoenwaelder@jacobs-university.de  Thu Jan 16 06:05:01 2014
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 0A0E31AE352 for ; Thu, 16 Jan 2014 06:05:01 -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 OdUsLOvqDWYn for ; Thu, 16 Jan 2014 06:04:58 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB511AE336 for ; Thu, 16 Jan 2014 06:04:58 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B49F20069; Thu, 16 Jan 2014 15:04:46 +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 WkLhpCB2krcI; Thu, 16 Jan 2014 15:04:45 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5ABBE20066; Thu, 16 Jan 2014 15:04:45 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 262952AA7B45; Thu, 16 Jan 2014 15:04:42 +0100 (CET)
Date: Thu, 16 Jan 2014 15:04:41 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20140116140441.GA2337@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, randy_presuhn@mindspring.com, netmod@ietf.org
References: <20140116111705.GA1696@elstar.local> <20140116.122906.1529489901441363143.mbj@tail-f.com> <20140116113632.GA1783@elstar.local> <20140116.135906.2039988908661941403.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140116.135906.2039988908661941403.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] escapes - WAS: [Netconf] [Technical Errata Reported] RFC6536 (3862)
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, 16 Jan 2014 14:05:01 -0000

On Thu, Jan 16, 2014 at 01:59:06PM +0100, Martin Bjorklund wrote:
 
> Ok, searching the Errata I found a few.  Even this:
> 
> http://www.rfc-editor.org/errata_search.php?eid=334
> 
> I noticed that the mib that gets distributed with libsmi doesn't have
> this change.  This is of course the risk of doing such changes...

I am simply not able to track errata for ~300 MIB modules the IETF has
published (a remarkable number). That said, if someone would send me
an email saying a certain MIB module has a bug and points to an
approve errata for it, I would apply the patch without thinking much.

These things are trade-off decisions and in this particular case, I
personally believe the change is trivial enough to not warrant a new
version and to simply do it. The 'patched' variant will clearly
interoperate, the 'unpatched' variant may trigger undefined
behaviour. People struggling with the variant triggering undefined
behaviour likely will likely move to the 'patched' variant. For the
rest, it does not matter. But that is just my personal opinion...

/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  Thu Jan 16 07:10:19 2014
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 0C23E1AE430 for ; Thu, 16 Jan 2014 07:10:19 -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 44ItVl2UQXEg for ; Thu, 16 Jan 2014 07:10:15 -0800 (PST)
Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id B380B1AE387 for ; Thu, 16 Jan 2014 07:10:15 -0800 (PST)
Received: by mail-qe0-f52.google.com with SMTP id a11so372873qen.39 for ; Thu, 16 Jan 2014 07:10:03 -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=sLFAi/FitlChW7lzC/4p4Iyn95cT6thTNE6J7FGjiV8=; b=V2dpv3J3VaNYwuz1hWgDU46EoxuYt7cXA7gGjmkQmYLQB4S+ahJkizp81Z70J+Gqbo 1X0tuX7LDjEr0nDJ1MMpK4a7quLGG5vGbPJRWQH89aWjwlQG32kaxrWezVdIvUs2B1bC 2u6bjJGhdQT9JDxBAAwG4CrjMm5xkPAx4gQVRPYPxNrscI5A94UorVGyhCB/T7g/gCAm XTuFYw8ZjVUG288aXndBFSuGBK4HsUdRURCwVjNzuugi9C5SrWCAJ1AruCLjh8o1izav CrlBXuvHIBv4YNdXm8TcyF8u9dYdoXzozgXByckdHFz6KWA93JlpoSSMB6bDsHD0YnE+ 1Naw==
X-Gm-Message-State: ALoCoQlaqHak+RKtR3JqFRLsRVOtM19A+zMdZbOjljBP1Rmq5HGE24P0tKVJFkQz0JTv/sHqc85X
MIME-Version: 1.0
X-Received: by 10.140.85.179 with SMTP id n48mr8828671qgd.91.1389885003293; Thu, 16 Jan 2014 07:10:03 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 16 Jan 2014 07:10:03 -0800 (PST)
In-Reply-To: <52D7DF31.4000309@cisco.com>
References: <20140116092825.GA1348@elstar.local> <52D7DF31.4000309@cisco.com>
Date: Thu, 16 Jan 2014 07:10:03 -0800
Message-ID: 
From: Andy Bierman 
To: Benoit Claise 
Content-Type: multipart/alternative; boundary=001a11c133dee6ac9004f017d1c2
Cc: Eliot Lear , "netmod@ietf.org" , Paul Eggert , SM , Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 15:10:19 -0000

--001a11c133dee6ac9004f017d1c2
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I do not have any concerns about this draft if IANA has a reliable tool
to generate the YANG module.  IMO it should be very clear at
the start of the document that the YANG module in the RFC  may
not be current.  The URL of the official IANA YANG module must be
very prominent as well.

Andy



On Thu, Jan 16, 2014 at 5:31 AM, Benoit Claise  wrote:

> Juergen, Martin,
>
> Thanks for starting the discussion.
> Including Michelle Cotton, from IANA, in the discussion.
>
>> Hi,
>>
>> I like to see whether we can close the technical discussions around
>> , which is used by
>> . Let me try to summarize where we
>> are. Since emails were exchanged between different groups of people, I
>> think it is necessary to synchronize so that everybody involved is on
>> the same page. I am trying to summarize where I think we are. I might
>> get certain details wrong - if so, please correct me. If I left
>> someone out of the To: line, please let me know as well.
>>
>> * Overall Goal
>>
>>    I believe there is agreement that timezone should be configurable
>>    using the so called Olson database timezone names (e.g.,
>>    'Europe/London'). This is what the timezone-location leaf in
>>     tries to achieve.
>>
>> * Current Solution ()
>>
>>    The current I-Ds propose to have a YANG enumeration of timezone
>>    names, essentially a serialization of the so called Olson database
>>    timezone names into a YANG enumeration. The Olson database is
>>    currently maintained by Paul Eggert, who serves as the TZ
>>    Coordinator, an IANA Designated Expert as defined in RFC 6557. The
>>    enumeration of timezone names in 
>>    resulted in two technical discussion points:
>>
>>    a) YANG requires that an enumerated string value is always
>>       associated with a number. If no number is explicitly assigned,
>>       YANG assigns numbers implicitly but for this to work the order
>>       of listed enums may not change. Hence, to avoid brittleness when
>>       YANG modules are revised, it is good practice to assign explicit
>>       numbers. Unfortunately, the timezone database does not maintain
>>       such numbers. Options to fix this:
>>
>>       - Add numeric identifiers to the timezone names as part of the
>>         timezone database. Increases work for the TZ coordinator and
>>         they are not needed for any other purpose.
>>       - Generate likely unique numbers using a hash function. To
>>         guarantee uniqueness, the TZ coordinator would have to verify
>>         that hashes do not collide if new timezone names are
>>         introduced.
>>       - Generate numbers from the coordinates (second column in the
>>         zone.tab file), e.g., encoding the coordinates in some way into
>>         a 32-bit integer. This may lead to issues if coordinates of a
>>         zone name are updated (not sure this happens).
>>
>>    b) Timezone names are sometimes (although rarely) added or deleted
>>       from the timezone database. The timezone database documents the
>>       current state, it does not track the history by itself. YANG
>>       modules, however, do version management internally by deprecating
>>       and obsoleting definitions. This means, whenever timezone names
>>       are added or deleted, the TZ coordinator would have to do some
>>       extra work in order to provide that information (either to a tool
>>       that generates a new version of the YANG module or by maintenance
>>       of the YANG serialization directly manually).
>>
>>    A solution to a) and b) is required in order to move forward with
>>     and the solution must be
>>    simple enough so that it can be maintained over years with
>>    potentially different TZ Coordinators involved.
>>
> And we must have an easy and repeatable procedure for IANA.
>
>>
>> * Alternative Solution
>>
>>    If we fail to produce a viable solution for a) and b), then an
>>    obvious fallback solution would be to simply define a YANG type such
>>    as
>>
>>      typedef timezone-name {
>>        type string;
>>        description
>>         "A timezone name as used by the Time Zone Database, sometimes
>>          referred to as the 'Olson Database'.";
>>        reference
>>         "RFC 6557: Procedures for Maintaining the Time Zone Database";
>>      }
>>
>>    and to use this type in the timezone-location leaf in
>>    .
>>
> This document is currently in IETF LC, and on the IESG telechat on Jan
> 23rd.
> I guess I should remove it from the telechat?
>
> Regards, Benoit
>
>> Generic tools would not have
>>    knowledge about the set of possible timezone names but tools that
>>    have been coded to understand this typedef could of course reach out
>>    to the timezone database to get access to the set of possible
>>    timezone names. If we were to adopt this solution, we would pull
>>    back  and let it expire.
>>
>> I think we need to decide in a timely manner whether we can find a
>> workable solution for the 'Current Solution' addressing a) and b) or
>> whether we give up on it and instead use a timezone-name typedef as
>> suggested above in the 'Alternative Solution'.
>>
>> /js
>>
>>
>

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


Hi,

I do not have any concerns about th=
is draft if IANA has a reliable tool
to generate the YANG module.=
 =A0IMO it should be very clear at
the start of the document that=
 the YANG module in the RFC =A0may


not be current. =A0The URL of the official IANA YANG module must be
very prominent as well.

Andy


=
On Thu, Jan 16, 2014 at 5:31 AM, Benoit Claise <bclaise@cisco.com><=
/span> wrote:


Juergen, Martin,



Thanks for starting the discussion.

Including Michelle Cotton, from IANA, in the discussion.



Hi,



I like to see whether we can close the technical discussions around

<draft-ietf-netmod-iana-timezones-03>, which is used by

<draft-ietf-netmod-system-mgmt-10>. Let me try to summarize wh=
ere we

are. Since emails were exchanged between different groups of people, I

think it is necessary to synchronize so that everybody involved is on

the same page. I am trying to summarize where I think we are. I might

get certain details wrong - if so, please correct me. If I left

someone out of the To: line, please let me know as well.



* Overall Goal



=A0 =A0I believe there is agreement that timezone should be configurable
=A0 =A0using the so called Olson database timezone names (e.g.,

=A0 =A0'Europe/London'). This is what the timezone-location leaf in=


=A0 =A0<draft-ietf-netmod-system-mgmt-10> tries to achieve.


* Current Solution (<draft-ietf-netmod-iana-timezones-03>)



=A0 =A0The current I-Ds propose to have a YANG enumeration of timezone

=A0 =A0names, essentially a serialization of the so called Olson database
=A0 =A0timezone names into a YANG enumeration. The Olson database is

=A0 =A0currently maintained by Paul Eggert, who serves as the TZ

=A0 =A0Coordinator, an IANA Designated Expert as defined in RFC 6557. The
=A0 =A0enumeration of timezone names in <draft-ietf-netmod-iana-t=
imezones-03>

=A0 =A0resulted in two technical discussion points:



=A0 =A0a) YANG requires that an enumerated string value is always

=A0 =A0 =A0 associated with a number. If no number is explicitly assigned,<=
br>
=A0 =A0 =A0 YANG assigns numbers implicitly but for this to work the order<=
br>
=A0 =A0 =A0 of listed enums may not change. Hence, to avoid brittleness whe=
n

=A0 =A0 =A0 YANG modules are revised, it is good practice to assign explici=
t

=A0 =A0 =A0 numbers. Unfortunately, the timezone database does not maintain=


=A0 =A0 =A0 such numbers. Options to fix this:



=A0 =A0 =A0 - Add numeric identifiers to the timezone names as part of the<=
br>
=A0 =A0 =A0 =A0 timezone database. Increases work for the TZ coordinator an=
d

=A0 =A0 =A0 =A0 they are not needed for any other purpose.

=A0 =A0 =A0 - Generate likely unique numbers using a hash function. To

=A0 =A0 =A0 =A0 guarantee uniqueness, the TZ coordinator would have to veri=
fy

=A0 =A0 =A0 =A0 that hashes do not collide if new timezone names are

=A0 =A0 =A0 =A0 introduced.

=A0 =A0 =A0 - Generate numbers from the coordinates (second column in the
=A0 =A0 =A0 =A0 zone.tab file), e.g., encoding the coordinates in some way =
into

=A0 =A0 =A0 =A0 a 32-bit integer. This may lead to issues if coordinates of=
 a

=A0 =A0 =A0 =A0 zone name are updated (not sure this happens).



=A0 =A0b) Timezone names are sometimes (although rarely) added or deleted
=A0 =A0 =A0 from the timezone database. The timezone database documents the=


=A0 =A0 =A0 current state, it does not track the history by itself. YANG
=A0 =A0 =A0 modules, however, do version management internally by deprecati=
ng

=A0 =A0 =A0 and obsoleting definitions. This means, whenever timezone names=


=A0 =A0 =A0 are added or deleted, the TZ coordinator would have to do some<=
br>
=A0 =A0 =A0 extra work in order to provide that information (either to a to=
ol

=A0 =A0 =A0 that generates a new version of the YANG module or by maintenan=
ce

=A0 =A0 =A0 of the YANG serialization directly manually).



=A0 =A0A solution to a) and b) is required in order to move forward with
=A0 =A0<draft-ietf-netmod-iana-timezones-03> and the solution =
must be

=A0 =A0simple enough so that it can be maintained over years with

=A0 =A0potentially different TZ Coordinators involved.



And we must have an easy and repeatable procedure for IANA.





* Alternative Solution



=A0 =A0If we fail to produce a viable solution for a) and b), then an

=A0 =A0obvious fallback solution would be to simply define a YANG type such=


=A0 =A0as



=A0 =A0 =A0typedef timezone-name {

=A0 =A0 =A0 =A0type string;

=A0 =A0 =A0 =A0description

=A0 =A0 =A0 =A0 "A timezone name as used by the Time Zone Database, so=
metimes

=A0 =A0 =A0 =A0 =A0referred to as the 'Olson Database'.";

=A0 =A0 =A0 =A0reference

=A0 =A0 =A0 =A0 "RFC 6557: Procedures for Maintaining the Time Zone Da=
tabase";

=A0 =A0 =A0}



=A0 =A0and to use this type in the timezone-location leaf in

=A0 =A0<draft-ietf-netmod-system-mgmt-10>.



This document is currently in IETF LC, and on the IESG telechat on Jan 23rd=
.

I guess I should remove it from the telechat?



Regards, Benoit



Generic tools would not have

=A0 =A0knowledge about the set of possible timezone names but tools that
=A0 =A0have been coded to understand this typedef could of course reach out=


=A0 =A0to the timezone database to get access to the set of possible

=A0 =A0timezone names. If we were to adopt this solution, we would pull

=A0 =A0back <draft-ietf-netmod-iana-timezones-03> and let it e=
xpire.



I think we need to decide in a timely manner whether we can find a

workable solution for the 'Current Solution' addressing a) and b) o=
r

whether we give up on it and instead use a timezone-name typedef as

suggested above in the 'Alternative Solution'.



/js











--001a11c133dee6ac9004f017d1c2--

From jeffrey.K.lange@ge.com  Thu Jan 16 07:32:04 2014
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 4B68D1AE393 for ; Thu, 16 Jan 2014 07:32:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 gxSsWmFov51w for ; Thu, 16 Jan 2014 07:32:02 -0800 (PST)
Received: from exprod5og117.obsmtp.com (exprod5og117.obsmtp.com [64.18.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id BD48F1AE377 for ; Thu, 16 Jan 2014 07:32:01 -0800 (PST)
Received: from alpmlip11.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob117.postini.com ([64.18.4.12]) with SMTP ID DSNKUtf7ZUv65wRb9uFVrcw5vPPlMCkWo8K6@postini.com; Thu, 16 Jan 2014 07:31:50 PST
Received: from unknown (HELO CINMBHT01.e2k.ad.ge.com) ([3.159.212.194]) by alpmlip11.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 16 Jan 2014 10:31:39 -0500
Received: from ALPURTP01.e2k.ad.ge.com (3.159.16.200) by CINMBHT01.e2k.ad.ge.com (3.159.212.194) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 16 Jan 2014 10:31:48 -0500
Received: from CINURCNA17.e2k.ad.ge.com (3.159.212.154) by ALPURTP01.e2k.ad.ge.com (3.159.16.200) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 16 Jan 2014 10:31:47 -0500
Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.41]) by CINURCNA17.e2k.ad.ge.com ([169.254.5.190]) with mapi id 14.03.0146.000; Thu, 16 Jan 2014 10:31:47 -0500
From: "Lange, Jeffrey K (GE Energy Management)" 
To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" 
Thread-Topic: technical discussion around draft-ietf-netmod-iana-timezones-03
Thread-Index: AQHPEp1T9TH1/xWMHU6fhC+8cmfxGpqHb9MAgAALEoA=
Date: Thu, 16 Jan 2014 15:31:46 +0000
Message-ID: 
References: <20140116092825.GA1348@elstar.local> <20140116.105208.698977392599000511.mbj@tail-f.com>
In-Reply-To: <20140116.105208.698977392599000511.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [3.159.212.181]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <97AC40246A9F42419F242B115DD809CB@mail.ad.ge.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "eggert@cs.ucla.edu" , "lear@cisco.com" , "netmod@ietf.org" , "sm@resistor.net" 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 15:32:04 -0000

Sorry for not jumping in earlier but here is my $0.02..


On 1/16/14, 4:52 AM, "Martin Bjorklund"  wrote:

>Hi,
>
>Juergen Schoenwaelder  wrote:
>> Hi,
>>=20
>> I like to see whether we can close the technical discussions around
>> , which is used by
>> . Let me try to summarize where we
>> are. Since emails were exchanged between different groups of people, I
>> think it is necessary to synchronize so that everybody involved is on
>> the same page. I am trying to summarize where I think we are. I might
>> get certain details wrong - if so, please correct me. If I left
>> someone out of the To: line, please let me know as well.
>>=20
>> * Overall Goal
>>=20
>>   I believe there is agreement that timezone should be configurable
>>   using the so called Olson database timezone names (e.g.,
>>   'Europe/London'). This is what the timezone-location leaf in
>>    tries to achieve.
>>=20
>> * Current Solution ()
>>=20
>>   The current I-Ds propose to have a YANG enumeration of timezone
>>   names, essentially a serialization of the so called Olson database
>>   timezone names into a YANG enumeration. The Olson database is
>>   currently maintained by Paul Eggert, who serves as the TZ
>>   Coordinator, an IANA Designated Expert as defined in RFC 6557. The
>>   enumeration of timezone names in 
>>   resulted in two technical discussion points:
>>=20
>>   a) YANG requires that an enumerated string value is always
>>      associated with a number. If no number is explicitly assigned,
>>      YANG assigns numbers implicitly but for this to work the order
>>      of listed enums may not change. Hence, to avoid brittleness when
>>      YANG modules are revised, it is good practice to assign explicit
>>      numbers. Unfortunately, the timezone database does not maintain
>>      such numbers. Options to fix this:
>>=20
>>      - Add numeric identifiers to the timezone names as part of the
>>        timezone database. Increases work for the TZ coordinator and
>>        they are not needed for any other purpose.
>>      - Generate likely unique numbers using a hash function. To
>>        guarantee uniqueness, the TZ coordinator would have to verify
>>        that hashes do not collide if new timezone names are
>>        introduced.
>>      - Generate numbers from the coordinates (second column in the
>>        zone.tab file), e.g., encoding the coordinates in some way into
>>        a 32-bit integer. This may lead to issues if coordinates of a
>>        zone name are updated (not sure this happens).

The auto generation of numbers (by whatever means) only helps on the
creation of new zones.  It doesn=B9t address the removal (and obsoleting) o=
f
zones.

>
>Another option is to let the numbers live only in the YANG module.
>I.e., use the previous version of the YANG module ("the IANA
>resgitry") as input when new timezone locations are added.
>
>>   b) Timezone names are sometimes (although rarely) added or deleted
>>      from the timezone database.
>
>I did a quick check, and it seems 3 were deleted and 3 added during
>2012 and 2013.
>
>>      The timezone database documents the
>>      current state, it does not track the history by itself. YANG
>>      modules, however, do version management internally by deprecating
>>      and obsoleting definitions. This means, whenever timezone names
>>      are added or deleted, the TZ coordinator would have to do some
>>      extra work in order to provide that information (either to a tool
>>      that generates a new version of the YANG module or by maintenance
>>      of the YANG serialization directly manually).
>
>The current document explains what has to be done.  It is fairly
>trivial to write a program that takes as input the current YANG module
>and the new zone.tab file, and generate an updated YANG module if
>needed.

I like this idea, but who will write such a program? The initial version
of this yang model was created with a simple awk script, but taking in the
zone.tab file and a yang file and intelligently comparing them would be a
bit more work (perhaps a pyang extension?).

For posterity, the following awk script was used for the initial zone.tab
-> yang conversion:

#!/usr/bin/awk -f
BEGIN {
  FS=3D"\t";
  line=3D0;
  print "typedef iana-timezone {"
  print "  description"
  print "    \"A timezone location as defined by the IANA timezone"
  print "     database (http://www.iana.org/time-zones)";
  print "  type enumeration {"
}
{
  print "    enum \"" $3 "\" {";
  print "      value " line ";"
  if ($4 !=3D "") {
    print "      description";
    print "        \""$4"\";";
  }
  print "    }";
  line++;
}
END {
  print "  }";
  print "}";
}


- Jeff

>
>So when the TZ coordinator publishes a new version of the database, he
>would first run this program, and send a new YANG module to IANA, if
>needed.
>
>
>
>/martin


From mbj@tail-f.com  Thu Jan 16 08:02:40 2014
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 27A891AE0E2 for ; Thu, 16 Jan 2014 08:02: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 qeUosE9-y4N8 for ; Thu, 16 Jan 2014 08:02:39 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id D40951AE387 for ; Thu, 16 Jan 2014 08:02:36 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id CAB10240C34B; Thu, 16 Jan 2014 17:02:23 +0100 (CET)
Date: Thu, 16 Jan 2014 17:02:22 +0100 (CET)
Message-Id: <20140116.170222.308250923.mbj@tail-f.com>
To: eggert@cs.ucla.edu
From: Martin Bjorklund 
In-Reply-To: <52D800F1.20401@cs.ucla.edu>
References: <20140116092825.GA1348@elstar.local> <52D800F1.20401@cs.ucla.edu>
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: lear@cisco.com, netmod@ietf.org, sm@resistor.net
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 16:02:40 -0000

Paul Eggert  wrote:
> Juergen Schoenwaelder wrote:
> 
> >    The enumeration of timezone names in 
> >    resulted in two technical discussion points:
> 
> A third technical discussion point was raised:
> 
>   c) There is no canonical list of TZ time zone names.
> 
> This is deliberate, because coming up with a "canonical"
> list raises political issues, and we'd rather leave
> those sleeping dogs lie.
> 
> In particular, the zone.tab file is *not* a canonical
> list of TZ values.  It's merely a list intended to be
> used by programs like tzselect.  It contains many duplicate
> aliases, and it omits some entries.
> 
> The four solutions you proposed (including the Alternative
> Solution) all suffer from this issue.

So why is this a problem?  Can't we let the YANG model just reflect
the zone.tab?


/martin

From mbj@tail-f.com  Thu Jan 16 09:43:05 2014
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 1A8651AE0FC for ; Thu, 16 Jan 2014 09:43:05 -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 d1nRcEk6tdFN for ; Thu, 16 Jan 2014 09:43:03 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFA31AE0A0 for ; Thu, 16 Jan 2014 09:43:03 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 4B57B240C355; Thu, 16 Jan 2014 18:42:50 +0100 (CET)
Date: Thu, 16 Jan 2014 18:42:49 +0100 (CET)
Message-Id: <20140116.184249.296066285.mbj@tail-f.com>
To: eggert@cs.ucla.edu
From: Martin Bjorklund 
In-Reply-To: <52D80720.80002@cs.ucla.edu>
References: <52D800F1.20401@cs.ucla.edu> <20140116.170222.308250923.mbj@tail-f.com> <52D80720.80002@cs.ucla.edu>
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: lear@cisco.com, netmod@ietf.org, sm@resistor.net
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 17:43:05 -0000

Paul Eggert  wrote:
> Martin Bjorklund wrote:
> 
> > why is this a problem?
> 
> Because people often use names that are not in zone.tab.

Can you explain how this relates to having a YANG version of zone.tab?
In which situation does this become problematic?

The YANG module is intended to reflect zone.tab, so if there is a
problem with a location not being in the YANG module I would assume
the problem exist with zone.tab?

> Just today, for example, someone asked on the tz mailing
> about Asia/Calcutta, a name that's not in zone.tab but which
> does work.  Although Asia/Calcutta was formerly in zone.tab
> and so could presumably rely on a proleptic application of
> whatever deprecation procedure the YANG maintainers want to
> establish, some commonly-used names have never been in
> zone.tab -- US/Pacific is one example.
> 
> More generally, there is a political burden in coming up
> with a "canonical" list of names.  This is a long story, one
> that's connected to conflicts between Israelis and
> Palestinians, between the Serbs and the Croats, etc.  If the
> YANG maintainers, whoever they are, want to address this
> problem, more power to them; but it's not a burden the TZ
> coordinator should have to take up.

I am pretty sure noone wants to address this problem.  Again, we just
want a version of zone.tab expressed in YANG.


/martin

From sm@resistor.net  Thu Jan 16 10:19:16 2014
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 7C3561A1F63; Thu, 16 Jan 2014 10:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] 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 85h-ZbohK_L2; Thu, 16 Jan 2014 10:19:15 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E051A1F19; Thu, 16 Jan 2014 10:19:15 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s0GIIQbi001534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jan 2014 10:18:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1389896317; bh=iB73rZ16jyLAcFdIrNywMBADqR+r7r7aNPcf7QZbVUg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gILOAQJo/9v2cNVvIEx3uwI05CmJ6+0CkE94/lFcf0rsCX0XmAebhtYXVxkQq7KnQ HU4KfXA8KwsmF/5q3c1cz1L40k0rqjq7NFfMfQNnhrbDyvqlCKF6siFEOo2A6tkNdl BoaQjDpCVudRvQGOKYH72yXhPBmeLsW+zyJJih1U=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1389896317; i=@resistor.net; bh=iB73rZ16jyLAcFdIrNywMBADqR+r7r7aNPcf7QZbVUg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=OdBy20vKhqSc6Di7B5F56M9ejJaq+IWXeVQ/B1XzB311MrCeuKVY6jhuvKZ5b89kd eRyCiKr/ZAzWg1VBD0rIH0VEbwljj56nQMf9mYKvK8wPvT35UwigL2w0bcJe+1JgZK +SFs/CSwXhfmrv/x0cUOJYcpkh9aIRoK9KDeOi5Y=
Message-Id: <6.2.5.6.2.20140116095641.0bcc8b10@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 16 Jan 2014 10:17:09 -0800
To: Paul Eggert , Martin Bjorklund 
From: SM 
In-Reply-To: <52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com>
References: <20140116092825.GA1348@elstar.local> <52D800F1.20401@cs.ucla.edu> <20140116.170222.308250923.mbj@tail-f.com> <52D80720.80002@cs.ucla.edu> <52D800F1.20401@cs.ucla.edu> <20140116.170222.308250923.mbj@tail-f.com> <52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: lear@cisco.com, netmod@ietf.org, ietf@ietf.org
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezone
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, 16 Jan 2014 18:19:16 -0000

At 08:21 16-01-2014, Paul Eggert wrote:
>Martin Bjorklund wrote:
>
>>why is this a problem?
>
>Because people often use names that are not in zone.tab.
>Just today, for example, someone asked on the tz mailing
>about Asia/Calcutta, a name that's not in zone.tab but which
>does work.  Although Asia/Calcutta was formerly in zone.tab
>and so could presumably rely on a proleptic application of
>whatever deprecation procedure the YANG maintainers want to
>establish, some commonly-used names have never been in
>zone.tab -- US/Pacific is one example.
>
>More generally, there is a political burden in coming up
>with a "canonical" list of names.  This is a long story, one
>that's connected to conflicts between Israelis and
>Palestinians, between the Serbs and the Croats, etc.  If the
>YANG maintainers, whoever they are, want to address this
>problem, more power to them; but it's not a burden the TZ
>coordinator should have to take up.

At 09:42 16-01-2014, Martin Bjorklund wrote:
> > Palestinians, between the Serbs and the Croats, etc.  If the
> > YANG maintainers, whoever they are, want to address this
> > problem, more power to them; but it's not a burden the TZ
> > coordinator should have to take up.
>
>I am pretty sure noone wants to address this problem.  Again, we just
>want a version of zone.tab expressed in YANG.

I agree with what Paul Eggert wrote (see message at 
http://www.ietf.org/mail-archive/web/ietf/current/msg85386.html for 
the political aspect).  The NETMOD Working Group could choose YANG 
maintainers to do the work instead of pushing the political burden to 
the TZ coordinator.

Regards,
-sm 


From eggert@cs.ucla.edu  Thu Jan 16 07:55:48 2014
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 C700D1AE0E2 for ; Thu, 16 Jan 2014 07:55:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.739
X-Spam-Level: 
X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 z-ig4I_a7j1p for ; Thu, 16 Jan 2014 07:55:47 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3A58C1ADED7 for ; Thu, 16 Jan 2014 07:55:47 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 3AD57A60002; Thu, 16 Jan 2014 07:55:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbJCd80NfZMG; Thu, 16 Jan 2014 07:55:34 -0800 (PST)
Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id BEE7639E8016; Thu, 16 Jan 2014 07:55:33 -0800 (PST)
Message-ID: <52D800F1.20401@cs.ucla.edu>
Date: Thu, 16 Jan 2014 07:55:29 -0800
From: Paul Eggert 
Organization: UCLA Computer Science Department
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Martin Bjorklund , Andy Bierman ,  Jeffrey Lange , Eliot Lear , Benoit Claise ,  SM , netmod@ietf.org
References: <20140116092825.GA1348@elstar.local>
In-Reply-To: <20140116092825.GA1348@elstar.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 16 Jan 2014 10:20:46 -0800
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 15:57:04 -0000

Juergen Schoenwaelder wrote:

>    The enumeration of timezone names in 
>    resulted in two technical discussion points:

A third technical discussion point was raised:

   c) There is no canonical list of TZ time zone names.

This is deliberate, because coming up with a "canonical"
list raises political issues, and we'd rather leave
those sleeping dogs lie.

In particular, the zone.tab file is *not* a canonical
list of TZ values.  It's merely a list intended to be
used by programs like tzselect.  It contains many duplicate
aliases, and it omits some entries.

The four solutions you proposed (including the Alternative
Solution) all suffer from this issue.

One way around this issue would be to have the
maintainers of the YANG module (who would be separate
from the TZ maintainers) assume the burden of
dealing with this political issue.  The TZ
database would be upstream from the YANG module
and would continue its current maintenance practices,
and the YANG maintainers could track it using whatever
procedures and software that they like.

This is the approach taken by the Unicode CLDR project,
so there's precedent for it.  See:

http://cldr.unicode.org/

http://www.unicode.org/cldr/charts/latest/by_type/timezones.timezone_cities.html

> This may lead to issues if coordinates of a
>        zone name are updated (not sure this happens).

Yes, it does happen; errors are corrected and precision
is added.

From eggert@cs.ucla.edu  Thu Jan 16 08:22:06 2014
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 2D9A41AE363 for ; Thu, 16 Jan 2014 08:22:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.739
X-Spam-Level: 
X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 X2ec_A9wNoBS for ; Thu, 16 Jan 2014 08:22:05 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 38B571AC82B for ; Thu, 16 Jan 2014 08:22:05 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 5BE28A60002; Thu, 16 Jan 2014 08:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndEVzLcUIha9; Thu, 16 Jan 2014 08:21:52 -0800 (PST)
Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id B0FCB39E8015; Thu, 16 Jan 2014 08:21:52 -0800 (PST)
Message-ID: <52D80720.80002@cs.ucla.edu>
Date: Thu, 16 Jan 2014 08:21:52 -0800
From: Paul Eggert 
Organization: UCLA Computer Science Department
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Martin Bjorklund 
References: <20140116092825.GA1348@elstar.local>	<52D800F1.20401@cs.ucla.edu> <20140116.170222.308250923.mbj@tail-f.com>
In-Reply-To: <20140116.170222.308250923.mbj@tail-f.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 16 Jan 2014 10:20:46 -0800
Cc: lear@cisco.com, netmod@ietf.org, sm@resistor.net
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 16:22:06 -0000

Martin Bjorklund wrote:

> why is this a problem?

Because people often use names that are not in zone.tab.
Just today, for example, someone asked on the tz mailing
about Asia/Calcutta, a name that's not in zone.tab but which
does work.  Although Asia/Calcutta was formerly in zone.tab
and so could presumably rely on a proleptic application of
whatever deprecation procedure the YANG maintainers want to
establish, some commonly-used names have never been in
zone.tab -- US/Pacific is one example.

More generally, there is a political burden in coming up
with a "canonical" list of names.  This is a long story, one
that's connected to conflicts between Israelis and
Palestinians, between the Serbs and the Croats, etc.  If the
YANG maintainers, whoever they are, want to address this
problem, more power to them; but it's not a burden the TZ
coordinator should have to take up.

From eggert@cs.ucla.edu  Thu Jan 16 10:17:16 2014
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 DCE0A1A1F5E for ; Thu, 16 Jan 2014 10:17:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.739
X-Spam-Level: 
X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 z-DagWt4pAfZ for ; Thu, 16 Jan 2014 10:17:15 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id D65181A1F00 for ; Thu, 16 Jan 2014 10:17:15 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 8B6D1A60005; Thu, 16 Jan 2014 10:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnaKlqutVpOA; Thu, 16 Jan 2014 10:17:03 -0800 (PST)
Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id E67C6A60004; Thu, 16 Jan 2014 10:17:02 -0800 (PST)
Message-ID: <52D8221B.8090001@cs.ucla.edu>
Date: Thu, 16 Jan 2014 10:16:59 -0800
From: Paul Eggert 
Organization: UCLA Computer Science Department
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Martin Bjorklund 
References: <52D800F1.20401@cs.ucla.edu>	<20140116.170222.308250923.mbj@tail-f.com>	<52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com>
In-Reply-To: <20140116.184249.296066285.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 16 Jan 2014 10:20:46 -0800
Cc: lear@cisco.com, netmod@ietf.org, sm@resistor.net
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 18:17:17 -0000

On 01/16/2014 09:42 AM, Martin Bjorklund wrote:

> Can you explain how this relates to having a YANG version of zone.tab?

If the goal is merely to have a YANG version of zone.tab,
then there is no problem.  But if the goal is, as Juergen
put it, that timezones "should be configurable using the so
called Olson database timezone names", then there is a
problem, because zone.tab is not a list of all the Olson
database timezone names.

> In which situation does this become problematic?

When the user wants to specify a TZ setting that
is not in zone.tab.

> The YANG module is intended to reflect zone.tab, so if there is a
> problem with a location not being in the YANG module I would assume
> the problem exist with zone.tab?

No, there's no problem in zone.tab; as mentioned above,
zone.tab is not intended to be a list of all the TZ values.


From mbj@tail-f.com  Thu Jan 16 11:15:34 2014
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 9ECFC1A1F66 for ; Thu, 16 Jan 2014 11:15:34 -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 RJCdAxByaLDK for ; Thu, 16 Jan 2014 11:15:33 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 526B71A1F5E for ; Thu, 16 Jan 2014 11:15:32 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id B53CE240C341; Thu, 16 Jan 2014 20:15:19 +0100 (CET)
Date: Thu, 16 Jan 2014 20:15:19 +0100 (CET)
Message-Id: <20140116.201519.152036089.mbj@tail-f.com>
To: eggert@cs.ucla.edu
From: Martin Bjorklund 
In-Reply-To: <52D8221B.8090001@cs.ucla.edu>
References: <52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com> <52D8221B.8090001@cs.ucla.edu>
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: lear@cisco.com, netmod@ietf.org, sm@resistor.net
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 19:15:34 -0000

Paul Eggert  wrote:
> On 01/16/2014 09:42 AM, Martin Bjorklund wrote:
> 
> > Can you explain how this relates to having a YANG version of zone.tab?
> 
> If the goal is merely to have a YANG version of zone.tab,
> then there is no problem.  But if the goal is, as Juergen
> put it, that timezones "should be configurable using the so
> called Olson database timezone names", then there is a
> problem, because zone.tab is not a list of all the Olson
> database timezone names.

Let me see if I understand the names involved.

RFC 6557 defines the term the "TZ Database".  It also says that this
database sometimes is 'referred to as the "Olson database"'.

Are you saying that the zone.tab does not list the timezone names in
the TZ Database?  Or are you saying that the Olson database is
actually something else than the TZ database?

> > In which situation does this become problematic?
> 
> When the user wants to specify a TZ setting that
> is not in zone.tab.

The end goal of the YANG model is to allow systems that use the TZ
Database to advertise this, and let clients configure the timezone on
these systems.  The system will advertise the revision of the YANG
module that corresponds to the TZ database in use on that system.


/martin

From andy@yumaworks.com  Thu Jan 16 11:38:17 2014
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 395A31AC3FA for ; Thu, 16 Jan 2014 11:38:17 -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 l6JwnzVCcl_R for ; Thu, 16 Jan 2014 11:38:14 -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 943DA1A1F54 for ; Thu, 16 Jan 2014 11:38:14 -0800 (PST)
Received: by mail-qe0-f47.google.com with SMTP id 5so2978222qeb.20 for ; Thu, 16 Jan 2014 11:38:01 -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=df9F6UNqaj57WiOsUkqv0bdV77/oWT7w4XgnzIzkRQU=; b=NpEN744J2gYI7Ggoayph1849Zml8nUMKt4Uhniuj/kKgbVwl5UfsO/iAOAj8XWrkTi 0eujULrDjQGHQLbQTGJkb6/ChDgPwSukvrDIgGtAR2hFytLHYRXrwD1H9C/YMyn6MwuZ h7KH4l/TgFpsZTfXhE4ERwUdhe6BeAMeCr7SWjjTSM/W1phd1WlNUqpTJalnOzKr3kH8 zS7+JMDZgTShEyeLaF/d1hoFwV66RMZ7KIDfc9juLD++vZnnTHNaus/gX7Ym0xJHF3PF gzmXJAUz/EdGY8Z4K2zVGSnSuvEA9kNmeb31sBIC6Wn5REob7BDB9TiQu55WRndITwy/ PbGw==
X-Gm-Message-State: ALoCoQnSGTs3Bdx+0lj5SM0wBR35ebq3L5heldNK+pDS6GhIqcYydhsxZis+KEkAp6vTkHA7+XFK
MIME-Version: 1.0
X-Received: by 10.140.94.44 with SMTP id f41mr10954137qge.18.1389901081835; Thu, 16 Jan 2014 11:38:01 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 16 Jan 2014 11:38:01 -0800 (PST)
In-Reply-To: <20140116.201519.152036089.mbj@tail-f.com>
References: <52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com> <52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com>
Date: Thu, 16 Jan 2014 11:38:01 -0800
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a113a9378418b1304f01b9002
Cc: Paul Eggert , Eliot Lear , "netmod@ietf.org" , SM 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 19:38:17 -0000

--001a113a9378418b1304f01b9002
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 16, 2014 at 11:15 AM, Martin Bjorklund  wrote:

> Paul Eggert  wrote:
> > On 01/16/2014 09:42 AM, Martin Bjorklund wrote:
> >
> > > Can you explain how this relates to having a YANG version of zone.tab?
> >
> > If the goal is merely to have a YANG version of zone.tab,
> > then there is no problem.  But if the goal is, as Juergen
> > put it, that timezones "should be configurable using the so
> > called Olson database timezone names", then there is a
> > problem, because zone.tab is not a list of all the Olson
> > database timezone names.
>
> Let me see if I understand the names involved.
>
> RFC 6557 defines the term the "TZ Database".  It also says that this
> database sometimes is 'referred to as the "Olson database"'.
>
> Are you saying that the zone.tab does not list the timezone names in
> the TZ Database?  Or are you saying that the Olson database is
> actually something else than the TZ database?
>
> > > In which situation does this become problematic?
> >
> > When the user wants to specify a TZ setting that
> > is not in zone.tab.
>
> The end goal of the YANG model is to allow systems that use the TZ
> Database to advertise this, and let clients configure the timezone on
> these systems.  The system will advertise the revision of the YANG
> module that corresponds to the TZ database in use on that system.
>
>

It comes down to how much coupling we want between the
IANA TZ database and the YANG typedef.

IMO:

Enumeration Pros:
   - client knows in advance the values supported by server
   - YANG driven applications like AJAX auto-completion can use
     enumerations but not strings

Enumeration Cons:
   - release-specific YANG module must be maintained
     and kept in sync with the TZ database and the server code
   - values not yet in the TZ database (or will never be in
     the TZ database) cannot be supported

String Pros:
   - Publish once and be done forever with this typedef
   - Double validation avoided (server implementation
     still needs to look up GMT offset, etc. so name validation
     is probably done twice)

String Cons:
   - NOT(enumeration pros)


I am leaning slightly towards string over enumeration, but either is OK.



> /martin
>


Andy

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





On Thu, Jan 16, 2014 at 11:15 AM, Martin Bjorklund <mbj@tail-f.com> wrote:


Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 01/16/2014 09:42 AM, Martin Bjorklund wrote:

>

> > Can you explain how this relates to having a YANG version of zone=
.tab?

>

> If the goal is merely to have a YANG version of zone.tab,

> then there is no problem. =A0But if the goal is, as Juergen

> put it, that timezones "should be configurable using the so

> called Olson database timezone names", then there is a

> problem, because zone.tab is not a list of all the Olson

> database timezone names.



Let me see if I understand the names involved.



RFC 6557 defines the term the "TZ Database". =A0It also says that=
 this

database sometimes is 'referred to as the "Olson database"=
9;.



Are you saying that the zone.tab does not list the timezone names in

the TZ Database? =A0Or are you saying that the Olson database is

actually something else than the TZ database?



> > In which situation does this become problematic?

>

> When the user wants to specify a TZ setting that

> is not in zone.tab.



The end goal of the YANG model is to allow systems that use the TZ

Database to advertise this, and let clients configure the timezone on

these systems. =A0The system will advertise the revision of the YANG

module that corresponds to the TZ database in use on that system.




It comes down to how much coupling we=
 want between the
IANA TZ database and the YANG typedef.


IMO:

Enumeration Pros:
=
=A0 =A0- client knows in advance the values supported by server
=
=A0 =A0- YANG driven applications like AJAX auto-completion can use
=A0 =A0 =A0enumerations but not strings



Enumeration Cons:
=A0 =A0- release-specific Y=
ANG module must be maintained
=A0 =A0 =A0and kept in sync with th=
e TZ database and the server code
=A0 =A0- values not yet in the =
TZ database (or will never be in


=A0 =A0 =A0the TZ database) cannot be supported

String Pros:
=A0 =A0- Publish once and be done forever with th=
is typedef
=A0 =A0- Double validation avoided (server implementat=
ion

=A0 =A0 =A0still needs to look up GMT offset, etc. so name validation
=

=A0 =A0 =A0is probably done twice)

String Con=
s:
=A0 =A0- NOT(enumeration pros)


I am leaning slightly towards string over enumeration, but either =
is OK.







/martin




<=
/div>
Andy



--001a113a9378418b1304f01b9002--

From jeffrey.K.lange@ge.com  Thu Jan 16 11:49:29 2014
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 8E9491AC49D for ; Thu, 16 Jan 2014 11:49:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 1y64YWhAkhpF for ; Thu, 16 Jan 2014 11:49:27 -0800 (PST)
Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by ietfa.amsl.com (Postfix) with ESMTP id 802271A1F6F for ; Thu, 16 Jan 2014 11:49:22 -0800 (PST)
Received: from alpmlip14.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKUtg3tlYOadzeKVxjUXzN84Ztu3H7ioBw@postini.com; Thu, 16 Jan 2014 11:49:10 PST
Received: from unknown (HELO ALPMBHT01.e2k.ad.ge.com) ([3.159.19.194]) by alpmlip14.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 16 Jan 2014 14:49:47 -0500
Received: from CINURAPD13.e2k.ad.ge.com (3.159.212.141) by ALPMBHT01.e2k.ad.ge.com (3.159.19.194) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 16 Jan 2014 14:49:09 -0500
Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.41]) by CINURAPD13.e2k.ad.ge.com ([169.254.7.75]) with mapi id 14.03.0146.000; Thu, 16 Jan 2014 14:49:08 -0500
From: "Lange, Jeffrey K (GE Energy Management)" 
To: Andy Bierman , Martin Bjorklund 
Thread-Topic: technical discussion around draft-ietf-netmod-iana-timezones-03
Thread-Index: AQHPEp1T9TH1/xWMHU6fhC+8cmfxGpqH1ViAgAAB7QCAAAVyAIAAFp6AgAAJjICAABBNgIAABleA//+vRwA=
Date: Thu, 16 Jan 2014 19:49:08 +0000
Message-ID: 
References: <52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com> <52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [3.159.212.181]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: SM , Paul Eggert , "netmod@ietf.org" , Eliot Lear 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 19:49:29 -0000

From:  Andy Bierman 
Date:  Thursday, January 16, 2014 at 2:38 PM
To:  "mbj@tail-f.com" 
Cc:  Paul Eggert , Jeffrey Lange
, Eliot Lear , Benoit Claise
, SM , "netmod@ietf.org"

Subject:  Re: technical discussion around
draft-ietf-netmod-iana-timezones-03




>It comes down to how much coupling we want between the
>IANA TZ database and the YANG typedef.
>
>IMO:
>
>Enumeration Pros:
>   - client knows in advance the values supported by server
>   - YANG driven applications like AJAX auto-completion can use
>     enumerations but not strings
>
>Enumeration Cons:
>   - release-specific YANG module must be maintained
>     and kept in sync with the TZ database and the server code
>   - values not yet in the TZ database (or will never be in
>     the TZ database) cannot be supported
>
>String Pros:
>   - Publish once and be done forever with this typedef
>   - Double validation avoided (server implementation
>     still needs to look up GMT offset, etc. so name validation
>     is probably done twice)
>
>String Cons:
>   - NOT(enumeration pros)
>
>
>I am leaning slightly towards string over enumeration, but either is OK.

My feeling here is that I (Obviously) would like to see this done as an
enum.  But if this proves to be logistically/politically impossible, I=B9m
open to doing this as a typedef=B9d string as Martin previously suggested.
It=B9s not great, but at least provides a small level of context as to what
the valid values are.

-Jeff

>Andy


From eggert@cs.ucla.edu  Thu Jan 16 12:10:10 2014
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 C63541ACCDC for ; Thu, 16 Jan 2014 12:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.739
X-Spam-Level: 
X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pYUkgY7ixILE for ; Thu, 16 Jan 2014 12:10:09 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF761ACC86 for ; Thu, 16 Jan 2014 12:10:09 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 9161939E8016; Thu, 16 Jan 2014 12:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf+-g796qgIO; Thu, 16 Jan 2014 12:09:57 -0800 (PST)
Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id F006A39E8015; Thu, 16 Jan 2014 12:09:56 -0800 (PST)
Message-ID: <52D83C94.4070407@cs.ucla.edu>
Date: Thu, 16 Jan 2014 12:09:56 -0800
From: Paul Eggert 
Organization: UCLA Computer Science Department
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Martin Bjorklund 
References: <52D80720.80002@cs.ucla.edu>	<20140116.184249.296066285.mbj@tail-f.com>	<52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com>
In-Reply-To: <20140116.201519.152036089.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: lear@cisco.com, netmod@ietf.org, sm@resistor.net
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 16 Jan 2014 20:10:11 -0000

On 01/16/2014 11:15 AM, Martin Bjorklund wrote:
> Are you saying that the zone.tab does not list the timezone names in
> the TZ Database?

That's correct, in the sense that zone.tab is not an
exhaustive list.  Also, depending on what one means by "the
timezone names", some of zone.tab's names are duplicates or
aliases of each other, so zone.tab is not intended to give
unique names for zones either.

> Or are you saying that the Olson database is
> actually something else than the TZ database?

No, they're the same thing.

> The end goal of the YANG model is to allow systems that use the TZ
> Database to advertise this, and let clients configure the timezone on
> these systems.

OK, but the problem is that the YANG model seems to require
that names be numbered and advertised and standardized, even
though in practice there is no standard or canonical set of
names, and the set of supported names is often
astronomically large.

Suppose servers and clients are POSIX-compatible, and
support both TZ database names (e.g., 'America/New_York',
'Asia/Kabul') and TZ settings as specified by POSIX (e.g.,
'UTC0', 'EST+5EDT,M3.2.0/2,M11.1.0/2').  This is a fairly
common situation: how does the YANG model represent it?

From randy_presuhn@mindspring.com  Thu Jan 16 16:04:40 2014
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 AC9F11AD935 for ; Thu, 16 Jan 2014 16:04:40 -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 ukb7so-N4tFN for ; Thu, 16 Jan 2014 16:04:39 -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 262331ACCE2 for ; Thu, 16 Jan 2014 16:04:38 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=W4Ax+BeAcYhfgDXrbMz6Dm3VuqLz3gtBIE6rMvHDZVHu64Nmx4dqPJZ6xtlwqJqO; 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.48] (helo=elwamui-rustique.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W3wvC-00043G-8s for netmod@ietf.org; Thu, 16 Jan 2014 19:04:26 -0500
Received: from 99.101.142.209 by webmail.earthlink.net with HTTP; Thu, 16 Jan 2014 19:04:26 -0500
Message-ID: <11032708.1389917066287.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>
Date: Thu, 16 Jan 2014 16:04:26 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbe0b134014e6161f56f7ad2872defcd0b350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.48
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: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jan 2014 00:04:40 -0000

Hi -

>From: Juergen Schoenwaelder 
>Sent: Jan 16, 2014 3:21 AM
>To: Randy Presuhn 
>Cc: netmod@ietf.org
>Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
>
>On Thu, Jan 09, 2014 at 04:45:30PM -0800, Randy Presuhn wrote:
>> Hi -
>> >
>> >But you can't delete vacmGroupName.3.3.b.o.b with SNMP either.
>> 
>> Yes you can, but that's irrelevant. 
>
>I do wonder how though (even though it might be irrelevant).

Setting vacmSecurityToGroupStatus.3.3.b.o.b to 'destroy'
will get rid of the reference,
setting vacmAccessStatus.3.bob.* will get rid of the group.

Randy


From lear@cisco.com  Thu Jan 16 22:06:47 2014
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 8202C1ADF94 for ; Thu, 16 Jan 2014 22:06: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 ctDw93I0oA8b for ; Thu, 16 Jan 2014 22:06:46 -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 B321C1ADF92 for ; Thu, 16 Jan 2014 22:06:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=969; q=dns/txt; s=iport; t=1389938793; x=1391148393; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yhHNEHP3vXCzQonI4Q6uWxnFAfWt9mMgEJi8JDJzXRk=; b=iWvwkJBn19VtHwPY63D8ouuBrk4834Sd+Sn9hD7ScJoNQD6qMjuoJ86E 2ZEVbGnakp15owx6sKU30m+A/ap8maYZfgV/g53xuuehi88Xlkn2PHmZQ TuubfV8cZ4XV823jzbIyPXmG7tSSmaYIW3gkcLzGWeFGant9ATtGf6nEJ U=;
X-IronPort-AV: E=Sophos;i="4.95,670,1384300800";  d="scan'208";a="3082871"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 17 Jan 2014 06:06:32 +0000
Received: from ams3-vpn-dhcp5383.cisco.com (ams3-vpn-dhcp5383.cisco.com [10.61.85.6]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0H66VPD003465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jan 2014 06:06:32 GMT
Message-ID: <52D8C867.30402@cisco.com>
Date: Fri, 17 Jan 2014 07:06:31 +0100
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Paul Eggert , Martin Bjorklund 
References: <52D80720.80002@cs.ucla.edu>	<20140116.184249.296066285.mbj@tail-f.com>	<52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com> <52D83C94.4070407@cs.ucla.edu>
In-Reply-To: <52D83C94.4070407@cs.ucla.edu>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 16 Jan 2014 22:55:52 -0800
Cc: sm@resistor.net, netmod@ietf.org
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 17 Jan 2014 06:06:47 -0000

Paul,

On 1/16/14 9:09 PM, Paul Eggert wrote:

> OK, but the problem is that the YANG model seems to require
> that names be numbered and advertised and standardized, even
> though in practice there is no standard or canonical set of
> names, and the set of supported names is often
> astronomically large.
>
> Suppose servers and clients are POSIX-compatible, and
> support both TZ database names (e.g., 'America/New_York',
> 'Asia/Kabul') and TZ settings as specified by POSIX (e.g.,
> 'UTC0', 'EST+5EDT,M3.2.0/2,M11.1.0/2').  This is a fairly
> common situation: how does the YANG model represent it?
>
>

It is possible to traipse through each of the files and grep for "Zone"
and "Link".  The IETF doesn't have to be consistent with everyone else's
use.  We just have to be self-consistent.  The question is whether that
raises any political issue, and I don't think it does.  It does,
however, raise a maintenance issue with IANA.

Eliot

From j.schoenwaelder@jacobs-university.de  Thu Jan 16 23:01:39 2014
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 0386E1ADF99 for ; Thu, 16 Jan 2014 23:01:39 -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 na1z8W2Jon_u for ; Thu, 16 Jan 2014 23:01:36 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B46501ADF98 for ; Thu, 16 Jan 2014 23:01:36 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 083B720053; Fri, 17 Jan 2014 08:01:24 +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 LanOV6Fwh5F2; Fri, 17 Jan 2014 08:01:23 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15E772004F; Fri, 17 Jan 2014 08:01:23 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 3FF212AA9914; Fri, 17 Jan 2014 08:01:20 +0100 (CET)
Date: Fri, 17 Jan 2014 08:01:19 +0100
From: Juergen Schoenwaelder 
To: Randy Presuhn 
Message-ID: <20140117070119.GA4945@elstar.local>
Mail-Followup-To: Randy Presuhn , netmod@ietf.org
References: <11032708.1389917066287.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <11032708.1389917066287.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net>
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: Fri, 17 Jan 2014 07:01:39 -0000

On Thu, Jan 16, 2014 at 04:04:26PM -0800, Randy Presuhn wrote:
> Hi -
> 
> >From: Juergen Schoenwaelder 
> >Sent: Jan 16, 2014 3:21 AM
> >To: Randy Presuhn 
> >Cc: netmod@ietf.org
> >Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> >
> >On Thu, Jan 09, 2014 at 04:45:30PM -0800, Randy Presuhn wrote:
> >> Hi -
> >> >
> >> >But you can't delete vacmGroupName.3.3.b.o.b with SNMP either.
> >> 
> >> Yes you can, but that's irrelevant. 
> >
> >I do wonder how though (even though it might be irrelevant).
> 
> Setting vacmSecurityToGroupStatus.3.3.b.o.b to 'destroy'
> will get rid of the reference,
> setting vacmAccessStatus.3.bob.* will get rid of the group.

In other words, you have to delete and re-create the user in order to
set him to no group (or you have to set the group to a magic value
that does not match anything to mean no group).

/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  Thu Jan 16 23:17:34 2014
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 CBCED1ADF9C for ; Thu, 16 Jan 2014 23:17:34 -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 dGZebz6-ZfX7 for ; Thu, 16 Jan 2014 23:17:33 -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 EC8BC1ADF9B for ; Thu, 16 Jan 2014 23:17:32 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=NR0J6Yu5jkRkF+mX6P4JUXJQcMoq6pptQrp6GU6J7QZjtJK8OAY36KSY5X11m0JN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.101.142.209] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W43g7-0000Kx-Ca for netmod@ietf.org; Fri, 17 Jan 2014 02:17:19 -0500
Message-ID: <001a01cf1354$9befd340$6b01a8c0@oemcomputer>
From: "Randy Presuhn" 
To: 
References: <11032708.1389917066287.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> <20140117070119.GA4945@elstar.local>
Date: Thu, 16 Jan 2014 23:20:31 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edba9e240394ad0fea99a98140eac01aa08350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.101.142.209
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, 17 Jan 2014 07:17:35 -0000

Hi -

> From: "Juergen Schoenwaelder" 
> To: "Randy Presuhn" 
> Cc: 
> Sent: Thursday, January 16, 2014 11:01 PM
> Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
>

> On Thu, Jan 16, 2014 at 04:04:26PM -0800, Randy Presuhn wrote:
> > Hi -
> > 
> > >From: Juergen Schoenwaelder 
> > >Sent: Jan 16, 2014 3:21 AM
> > >To: Randy Presuhn 
> > >Cc: netmod@ietf.org
> > >Subject: Re: [netmod] Last Call: draft-ietf-netmod-snmp-cfg-03 (20131220)
> > >
> > >On Thu, Jan 09, 2014 at 04:45:30PM -0800, Randy Presuhn wrote:
> > >> Hi -
> > >> >
> > >> >But you can't delete vacmGroupName.3.3.b.o.b with SNMP either.
> > >> 
> > >> Yes you can, but that's irrelevant. 
> > >
> > >I do wonder how though (even though it might be irrelevant).
> > 
> > Setting vacmSecurityToGroupStatus.3.3.b.o.b to 'destroy'
> > will get rid of the reference,
> > setting vacmAccessStatus.3.bob.* will get rid of the group.
> 
> In other words, you have to delete and re-create the user in order to
> set him to no group (or you have to set the group to a magic value
> that does not match anything to mean no group).

No "magic value" required.  If there are no corresponding entries in
vacmAccessTable, then there's a reference but no group, from a
data model perspective if not from the quirkily-defined ASI.  Likewise,
setting vacmAccessStatus.3.bob.* to 'destroy' will get rid of the group

Randy


From eggert@cs.ucla.edu  Thu Jan 16 23:21:10 2014
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 18ABF1ADFA1 for ; Thu, 16 Jan 2014 23:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.739
X-Spam-Level: 
X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 lucX2EMB0xqm for ; Thu, 16 Jan 2014 23:21:08 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 36FB91ADF9C for ; Thu, 16 Jan 2014 23:21:08 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id EE83BA60003; Thu, 16 Jan 2014 23:20:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiW5hnLcxURl; Thu, 16 Jan 2014 23:20:55 -0800 (PST)
Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 61B8FA60002; Thu, 16 Jan 2014 23:20:55 -0800 (PST)
Message-ID: <52D8D9D4.50902@cs.ucla.edu>
Date: Thu, 16 Jan 2014 23:20:52 -0800
From: Paul Eggert 
Organization: UCLA Computer Science Department
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Eliot Lear , Martin Bjorklund 
References: <52D80720.80002@cs.ucla.edu>	<20140116.184249.296066285.mbj@tail-f.com>	<52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com> <52D83C94.4070407@cs.ucla.edu> <52D8C867.30402@cisco.com>
In-Reply-To: <52D8C867.30402@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: sm@resistor.net, netmod@ietf.org
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 17 Jan 2014 07:21:10 -0000

Eliot Lear wrote:
> It is possible to traipse through each of the files and grep for "Zone"
> and "Link".

Sure, one could do that, and that would sidestep many
of the political problems.  This would generate a longer list,
one that I expect doesn't match up to CLDR or with
any other widely-used time zone resource.  And the list
would omit commonly-used names like 'UTC0'.  But these
issues may well not matter to users of the YANG module.

From mbj@tail-f.com  Fri Jan 17 02:04:28 2014
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 270BD1ADFC2 for ; Fri, 17 Jan 2014 02:04:28 -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 qWaypNkHj1MI for ; Fri, 17 Jan 2014 02:04:27 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E935E1ADFBA for ; Fri, 17 Jan 2014 02:04:26 -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 307C2240C2DE; Fri, 17 Jan 2014 11:04:13 +0100 (CET)
Date: Fri, 17 Jan 2014 11:04:13 +0100 (CET)
Message-Id: <20140117.110413.518038697080561533.mbj@tail-f.com>
To: eggert@cs.ucla.edu
From: Martin Bjorklund 
In-Reply-To: <52D8D9D4.50902@cs.ucla.edu>
References: <52D83C94.4070407@cs.ucla.edu> <52D8C867.30402@cisco.com> <52D8D9D4.50902@cs.ucla.edu>
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: lear@cisco.com, netmod@ietf.org, sm@resistor.net
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 17 Jan 2014 10:04:28 -0000

Paul Eggert  wrote:
> Eliot Lear wrote:
> > It is possible to traipse through each of the files and grep for
> > "Zone"
> > and "Link".
> 
> Sure, one could do that, and that would sidestep many
> of the political problems.  This would generate a longer list,
> one that I expect doesn't match up to CLDR or with
> any other widely-used time zone resource.  And the list
> would omit commonly-used names like 'UTC0'.  But these
> issues may well not matter to users of the YANG module.

We want the YANG module to match what the underlying system is
actually using, provided they support the TZ Database available from
IANA.

Due to my ignorance I thought that zone.tab provided this list.  But
the underlying idea doesn't change: the YANG module should list all
timezone names in the TZ Database, including the links.

I did the grep excerice and found 579 names marked as Zone or Link,
and 415 in zone.tab.  UTC0 is not in the list, but UTC is.  I think it
is ok that the system actually would internally accept e.g. UTC0, even
if it is not available in the YANG module.

This puts a heavier burden on IANA I guess.  It is of course still
trivial to write the program that takes as input the current YANG
module and the new tzdata.tar.gz file and produces a new YANG
module.  If this is what we want to do, I can write that program.  But
the question is if this procedure is ok for IANA?


Also, you asked previously about the POSIX TZ format.  The YANG
module does not support that, but it would be trivial to add, if we
believe that it would be useful.  Currently the module support a
choice of a location string or utc-offset.


/martin




From lhotka@nic.cz  Fri Jan 17 03:44:30 2014
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 CCFA71ADEBA for ; Fri, 17 Jan 2014 03:44:30 -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 jsMsUJ6ddpLK for ; Fri, 17 Jan 2014 03:44:28 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 7409A1ADFFF for ; Fri, 17 Jan 2014 03:44:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DA2FB5404F3; Fri, 17 Jan 2014 12:44:14 +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 sF64edA9Cdm8; Fri, 17 Jan 2014 12:44:11 +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 A246254018D; Fri, 17 Jan 2014 12:44:05 +0100 (CET)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Martin Bjorklund , Andy Bierman , Jeffrey Lange , Paul Eggert , Eliot Lear , Benoit Claise , SM 
In-Reply-To: <20140116092825.GA1348@elstar.local>
References: <20140116092825.GA1348@elstar.local>
User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Fri, 17 Jan 2014 12:44:04 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Cc: netmod@ietf.org
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 17 Jan 2014 11:44:30 -0000

Juergen Schoenwaelder  writes:

> Hi,
>
> I like to see whether we can close the technical discussions around
> , which is used by
> . Let me try to summarize where we
> are. Since emails were exchanged between different groups of people, I
> think it is necessary to synchronize so that everybody involved is on
> the same page. I am trying to summarize where I think we are. I might
> get certain details wrong - if so, please correct me. If I left
> someone out of the To: line, please let me know as well.
>
> * Overall Goal
>
>   I believe there is agreement that timezone should be configurable
>   using the so called Olson database timezone names (e.g.,
>   'Europe/London'). This is what the timezone-location leaf in
>    tries to achieve.
>
> * Current Solution ()
>
>   The current I-Ds propose to have a YANG enumeration of timezone
>   names, essentially a serialization of the so called Olson database
>   timezone names into a YANG enumeration. The Olson database is
>   currently maintained by Paul Eggert, who serves as the TZ
>   Coordinator, an IANA Designated Expert as defined in RFC 6557. The
>   enumeration of timezone names in 
>   resulted in two technical discussion points:
>
>   a) YANG requires that an enumerated string value is always
>      associated with a number. If no number is explicitly assigned,
>      YANG assigns numbers implicitly but for this to work the order
>      of listed enums may not change. Hence, to avoid brittleness when

RFC 6020 says:

"The value is unused by YANG and the XML encoding, but is carried as a convenience to implementors."

This makes me wonder why it is that important to standardize the numeric values. They only have local meaning, they are not carried in NETCONF messages, and everything should work fine even if different servers or clients used different values.

Lada 

>      YANG modules are revised, it is good practice to assign explicit
>      numbers. Unfortunately, the timezone database does not maintain
>      such numbers. Options to fix this:
>
>      - Add numeric identifiers to the timezone names as part of the
>        timezone database. Increases work for the TZ coordinator and
>        they are not needed for any other purpose.
>      - Generate likely unique numbers using a hash function. To
>        guarantee uniqueness, the TZ coordinator would have to verify
>        that hashes do not collide if new timezone names are
>        introduced.
>      - Generate numbers from the coordinates (second column in the
>        zone.tab file), e.g., encoding the coordinates in some way into
>        a 32-bit integer. This may lead to issues if coordinates of a
>        zone name are updated (not sure this happens).
>
>   b) Timezone names are sometimes (although rarely) added or deleted
>      from the timezone database. The timezone database documents the
>      current state, it does not track the history by itself. YANG
>      modules, however, do version management internally by deprecating
>      and obsoleting definitions. This means, whenever timezone names
>      are added or deleted, the TZ coordinator would have to do some
>      extra work in order to provide that information (either to a tool
>      that generates a new version of the YANG module or by maintenance
>      of the YANG serialization directly manually).
>
>   A solution to a) and b) is required in order to move forward with
>    and the solution must be
>   simple enough so that it can be maintained over years with
>   potentially different TZ Coordinators involved.
>
> * Alternative Solution
>
>   If we fail to produce a viable solution for a) and b), then an
>   obvious fallback solution would be to simply define a YANG type such
>   as
>
>     typedef timezone-name {
>       type string;
>       description
>        "A timezone name as used by the Time Zone Database, sometimes
>         referred to as the 'Olson Database'.";
>       reference
>        "RFC 6557: Procedures for Maintaining the Time Zone Database";
>     }
>
>   and to use this type in the timezone-location leaf in
>   . Generic tools would not have
>   knowledge about the set of possible timezone names but tools that
>   have been coded to understand this typedef could of course reach out
>   to the timezone database to get access to the set of possible
>   timezone names. If we were to adopt this solution, we would pull
>   back  and let it expire.
>
> I think we need to decide in a timely manner whether we can find a
> workable solution for the 'Current Solution' addressing a) and b) or
> whether we give up on it and instead use a timezone-name typedef as
> suggested above in the 'Alternative Solution'.
>
> /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

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

From spakes@snmp.com  Fri Jan 17 08:04:33 2014
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 1C2881AE160 for ; Fri, 17 Jan 2014 08:04:33 -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 9TTL24YN5-cJ for ; Fri, 17 Jan 2014 08:04:31 -0800 (PST)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 34C0C1AE155 for ; Fri, 17 Jan 2014 08:04:25 -0800 (PST)
Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA27861; Fri, 17 Jan 2014 11:03:52 -0500 (EST)
Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA21831; Fri, 17 Jan 2014 11:03:42 -0500 (EST)
X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs
Date: Fri, 17 Jan 2014 11:03:41 -0500 (EST)
From: David Spakes 
X-X-Sender: spakes@adminfs
To: netmod@ietf.org
In-Reply-To: 
Message-ID: 
References: <20140116092825.GA1348@elstar.local> 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 17 Jan 2014 16:04:33 -0000

On Thu, 16 Jan 2014, Juergen Schoenwaelder wrote:

>   Generic tools would not have
>   knowledge about the set of possible timezone names but tools that
>   have been coded to understand this typedef could of course reach out
>   to the timezone database to get access to the set of possible
>   timezone names.


On Thu, 16 Jan 2014, Lange, Jeffrey K (GE Energy Management) wrote:

> My feeling here is that I (Obviously) would like to see this done as an
> enum.
> ...
> It¹s not great, but at least provides a small level of context as to what
> the valid values are.


On 16-17 Jan 2014, Martin Bjorklund wrote:

> The end goal of the YANG model is to allow systems that use the TZ
> Database to advertise this, and let clients configure the timezone on
> these systems.  The system will advertise the revision of the YANG
> module that corresponds to the TZ database in use on that system.
...
> We want the YANG module to match what the underlying system is
> actually using, provided they support the TZ Database available from
> IANA.


On Thu, 16 Jan 2014, Andy Bierman wrote:

> I am leaning slightly towards string over enumeration, but either is OK.


I am only casually following this thread, but I wanted to say that I
would also choose the string over enumeration.

The TZ Database seems too volatile to be the basis for enums.  Compound
that with developers making their own additions (e.g., US/Pacific, for
user convenience/preference) and subtractions (e.g., because of political
bias).  Would implementations even advertise their deviations for changes
based on politics?  Probably not.  And on a personal level, whenever I am
contemplating the decision to make work for someone else (i.e., IANA), I
try to be discriminating to ensure that the task is truly worthy of their
effort.  In this case, it feels too much like "busy work".

If the client needs to be able to see the list of strings that the
server is actually using, then the client should not reach out to the
TZ Database; it should consult the server.  In addition to the typedef,
the document should define a config false list of strings that the server
actually supports.

I would also suggest adding another leaf that is an optional descriptor
for the contents of the list of strings.  So if a developer grabs the
TZ Database on a particular date, makes a couple of changes, and drops it
into their server instrumentation, the descriptor could summarize
``based on TZ Database dated xx-xx-xxxx''.

-dss


-------------------------------------------------------------
 David Spakes                       email:   spakes@snmp.com
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------

From blukovic@ndt-inc.com  Fri Jan 17 15:16:50 2014
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 C48BD1ACCE6 for ; Fri, 17 Jan 2014 15:16:50 -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 1Eez8Q0ANTH9 for ; Fri, 17 Jan 2014 15:16:47 -0800 (PST)
Received: from mail19k.g19.rapidsite.net (mail19k.g19.rapidsite.net [204.202.242.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7251ACCEC for ; Fri, 17 Jan 2014 15:16:47 -0800 (PST)
Received: from mx43.stngva01.us.mxservers.net (204.202.242.108) by mail19k.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 3-030948593 for ; Fri, 17 Jan 2014 18:16:34 -0500 (EST)
Received: from unknown [161.58.75.15] (EHLO mmm1913.dulles19-verio.com) by va1-mx43.stngva01.us.mxservers.net (mxl_mta-3.1.0-05) with ESMTP id 1d9b9d25.2676911008.1351954.00-001.va1-mx43.stngva01.us.mxservers.net (envelope-from );  Fri, 17 Jan 2014 18:16:33 -0500 (EST)
Received: (qmail 93946 invoked from network); 17 Jan 2014 23:16:33 -0000
Received: from unknown (HELO ?192.168.0.21?) (blukovic@135.23.154.141) by  with ESMTPA; 17 Jan 2014 23:16:33 -0000
Message-ID: <52D9B9CF.5010605@ndt-inc.com>
Date: Fri, 17 Jan 2014 18:16:31 -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:  <014201cef85b$81260cf0$837226d0$@comcast.net> <20140111.101300.219049272.mbj@tail-f.com>
In-Reply-To: <20140111.101300.219049272.mbj@tail-f.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(2014011720)]
X-MAIL-FROM: 
X-SOURCE-IP: [161.58.75.15]
X-SF-Loop: 1
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, 17 Jan 2014 23:16:51 -0000

Hi,

Re: target address/target params tables.
snmpTargetParamsName is not mapped into yang module.
This prevents agent from restoring snmp configuration after 
restart/reload (assuming configuration is yang based).
E.g. agent is configured through snmp, "t1" and "t2" are rows in 
targetAddress, "p1" is row in targetParams.
Both rows in targetAddressTable:
     "t1",...,"p1",...
     "t2",...,"p1",...
"point" to the same row in targetParamsTable:
     "p1", "v2c", "public"
saved as yang, targetParams row(s) are merged with rows of targetAddress:
     
       t1
       ...
       
         public
       
     ..
     
     
       t2
       ...
       
         public
       
     ..
     

SNMP agent initialized from this config would not know the original 
index ("p1") used in targetParamsTable.
One can argue that "locally arbitrary" in description of 
snmpTargetParamsName allows agent to reassign indices,
but I believe this would lead to confusion.

Possible solutions:
-  create "targetparams" list (index = leaf "name"), replace "params" 
choice with leaf "params" with type leafref { path 
"/snmp/targetparams/name" }
-  leave "params" choice, replace optional "notify-filter-profile" leaf 
with mandatory "param-name" leaf,
    explain relation between "param-name" and 
"notify-filter-profile/name" in description of "param-name"


     Borislav


On 1/11/2014 4:13 AM, Martin Bjorklund wrote:
> Hi,
>
> "ietfdbh"  wrote:
>> 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.
> Operational state is out of scope for this draft.
>
> The RFC 6643 translated MIB modules can be used.
>
>
>> 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.
> RowStatus is an SNMP-specific construction.  A row that is not active
> exists in the SNMP agent, but is "unavailable for use by the managed
> device".
>
> In NETCONF the transaction can be much bigger than traditional SNMP;
> which means that a client can send everything in one operation, and
> does not have to carefully construct multiple PDUs to first inactivate
> some rows, then modify the values, then re-active the rows.
>
>> 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?
> Yes.
>
>> 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.
> This is a good point, thank you for catching it!
>
> Implementations allowing both write access via SNMP and NETCONF should
> be recommended (required?) to bump the spinlock when NETCONF modifies
> the relevant parts of the SNMP tables.
>
> (this applies of course to all (three) spin locks in these mibs)
>
>> 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.
> These addresses are used in Appendix A.1 where it shows a listening
> endpoint.  0.0.0.0 and :: are the IP any addresses used to listen on
> any interface.
>
> But we can change this to a documention-special address if the example
> becomes more clear this way.
>
>> 5) The security implications of not using the RFC3414 method for cloning and
>> key change are not discussed.
> NETCONF generally over a secure and encrypted transport (this is
> pointed out in the Security Considerations section) hence the SNMP
> cloning mechanism is not needed.  I am not sure what kind of text you
> are looking for.
>
>> 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.
> The keys and the engineID have been copied from RFC 3414.
>
>> 7) I am having some difficulty understanding the purpose of the YANG snmp
>> models.
> The same purpose as any YANG or MIB module - to provide a standardized
> way to manage the underying subsystem if NETCONF/YANG or SNMP/MIBs are
> used.
>
>> 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.
> This might be one scenario.
>
>> 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.
> usmCloneFrom is never intialized - when read it is always
> zeroDotZero.  It is only used when a new user is created over SNMP.
>
> So your statement that keychange cannot be done is not correct.
>
>> 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.
> No.
>
>> 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,
> Well, we don't think the models lack anything...
>
>> 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.
> Another scenario are deployments (operators told the IETF that they
> exist long ago) where SNMP agents run in read-only mode and other
> mechanism (typically proprietary CLIs) are used to configure the SNMP
> agent. This YANG configuration data model clearly targets such
> deployments (that apparently do exist). It still allows to interwork
> with SNMP-managed applications.
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From eggert@cs.ucla.edu  Fri Jan 17 15:39:35 2014
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 326C91ACCF8 for ; Fri, 17 Jan 2014 15:39:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.739
X-Spam-Level: 
X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 j7fTrrhajFj7 for ; Fri, 17 Jan 2014 15:39:34 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 03C511ACCEC for ; Fri, 17 Jan 2014 15:39:34 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 66FBF39E8015; Fri, 17 Jan 2014 15:39:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19aTvZ488tFB; Fri, 17 Jan 2014 15:39:21 -0800 (PST)
Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id D903639E8011; Fri, 17 Jan 2014 15:39:20 -0800 (PST)
Message-ID: <52D9BF28.8070103@cs.ucla.edu>
Date: Fri, 17 Jan 2014 15:39:20 -0800
From: Paul Eggert 
Organization: UCLA Computer Science Department
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Martin Bjorklund 
References: <52D83C94.4070407@cs.ucla.edu>	<52D8C867.30402@cisco.com>	<52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com>
In-Reply-To: <20140117.110413.518038697080561533.mbj@tail-f.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: lear@cisco.com, netmod@ietf.org, sm@resistor.net
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 17 Jan 2014 23:39:35 -0000

Martin Bjorklund wrote:

> We want the YANG module to match what the underlying system is actually using, provided they support the TZ Database available from IANA.

OK, but the typical case is that if the underlying system supports the TZ database, it also supports POSIX TZ strings such as UTC0.  So if we want the YANG module to match what the underlying system is actually using ...

> I think it is ok that the system actually would internally accept e.g. UTC0, even if it is not available in the YANG module.

... then we might want to rethink this.

> It is of course still trivial to write the program that takes as input the current YANG module and the new tzdata.tar.gz file and produces a new YANG module.  If this is what we want to do, I can write that program.  But the question is if this procedure is ok for IANA?

That would require that the TZ coordinator maintain the YANG module.  I think it's better to have YANG-only stuff maintained by the YANG maintainers.  TZ database maintenance is a pain enough already, and its maintenance procedure won't scale to also maintaining YANG timezone data, CLDR timezone data, etc.

From j.schoenwaelder@jacobs-university.de  Sun Jan 19 02:33:51 2014
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 DB4791ADD9D for ; Sun, 19 Jan 2014 02:33:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.088
X-Spam-Level: 
X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 SP3NEpo_2Jj8 for ; Sun, 19 Jan 2014 02:33:49 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C2FF21ADBE5 for ; Sun, 19 Jan 2014 02:33:49 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2411120053; Sun, 19 Jan 2014 11:33:36 +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 fNHZPvOqeyDq; Sun, 19 Jan 2014 11:33:36 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03A0E20057; Sun, 19 Jan 2014 11:33:35 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id F3D7B2ABD298; Sun, 19 Jan 2014 11:33:31 +0100 (CET)
Date: Sun, 19 Jan 2014 11:33:31 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20140119103331.GA41873@elstar.local>
Mail-Followup-To: Andy Bierman , Martin Bjorklund , Paul Eggert , Eliot Lear , "netmod@ietf.org" , SM 
References: <52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com> <52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: SM , "netmod@ietf.org" , Eliot Lear , Paul Eggert 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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: Sun, 19 Jan 2014 10:33:52 -0000

On Thu, Jan 16, 2014 at 11:38:01AM -0800, Andy Bierman wrote:

> Enumeration Cons:
>    - release-specific YANG module must be maintained
>      and kept in sync with the TZ database and the server code
>    - values not yet in the TZ database (or will never be in
>      the TZ database) cannot be supported

I think Andy makes a strong point here. This coupling will be a major
issue for any NETCONF implementation that is not shiped shrink wrapped
with a product. If I run a third party NETCONF server on my say Debian
system, the TZ database changes when the Debian packages are updated,
which happens pretty much independent of the NETCONF server update. So
it is likely that the IANA module shipped with the NETCONF server gets
out of sync with the underlying systems' database.

/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  Sun Jan 19 04:55:46 2014
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 7D95A1ADF26 for ; Sun, 19 Jan 2014 04:55:46 -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 NHNqjR-kUWBr for ; Sun, 19 Jan 2014 04:55:44 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9C12A1ADFD6 for ; Sun, 19 Jan 2014 04:55:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 7F6BD540686; Sun, 19 Jan 2014 13:55:29 +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 6NYix9g3v9jm; Sun, 19 Jan 2014 13:55:26 +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 9D4435401B4; Sun, 19 Jan 2014 13:55:21 +0100 (CET)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Andy Bierman 
In-Reply-To: <20140119103331.GA41873@elstar.local>
References: <52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com> <52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com>  <20140119103331.GA41873@elstar.local>
User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Sun, 19 Jan 2014 13:55:21 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Cc: SM , Paul Eggert , Eliot Lear , "netmod@ietf.org" 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 19 Jan 2014 12:55:46 -0000

Juergen Schoenwaelder  writes:

> On Thu, Jan 16, 2014 at 11:38:01AM -0800, Andy Bierman wrote:
>
>> Enumeration Cons:
>>    - release-specific YANG module must be maintained
>>      and kept in sync with the TZ database and the server code
>>    - values not yet in the TZ database (or will never be in
>>      the TZ database) cannot be supported
>
> I think Andy makes a strong point here. This coupling will be a major
> issue for any NETCONF implementation that is not shiped shrink wrapped
> with a product. If I run a third party NETCONF server on my say Debian
> system, the TZ database changes when the Debian packages are updated,
> which happens pretty much independent of the NETCONF server update. So
> it is likely that the IANA module shipped with the NETCONF server gets
> out of sync with the underlying systems' database.

On the other hand, for a management application configuring a large and heterogeneous network of devices, it would be beneficial to have a uniform interface.

For an operator, the main point of having timezones properly configured is the ability to compare times reported from different sources. I think the POSIX format could serve this purpose quite well, and it would be up to NETCONF server implementations to translate the POSIX specification to the local system's conventions.

Lada 

>
> /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

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

From andy@yumaworks.com  Sun Jan 19 07:35:28 2014
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 F0E541AE005 for ; Sun, 19 Jan 2014 07:35:27 -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 A-iyLjczvzlK for ; Sun, 19 Jan 2014 07:35:25 -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 A2E671ADE7C for ; Sun, 19 Jan 2014 07:35:25 -0800 (PST)
Received: by mail-qe0-f46.google.com with SMTP id 8so5651845qea.33 for ; Sun, 19 Jan 2014 07:35:12 -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=ZtmN8zNgPo9tEESTqK+qwzYW5mmVJ52UB9269fI/ZMw=; b=KYgtH9IkoWWvOdwM+A3mIVzDBxBbxWH6hb6KjypmnnmGrD11qO4Zp7uZGmlZSuVi7Y RakCrujOXszSUgLFNoFW/FDFnovvpJ7BiFqXOSyyEYUs+MONcYYCrb9HaEeyo/44A33U vUaUV0Le9bUio411HIfVrme2IfgofKTArhXFybt4QZFODvGhpL4p/wi4sufMScoj4lQX XEIFAFlENpRFax8TdVk20L+JruhlhY3yDKyEGQZopTwtW/mxPn0f6OW6diJO6Ox2uNad ki2C8GW2Iq3ZBjJcQMtdAmeadHxU5o5ARE32fY2C4Ql3I/5GYBGzvJQpUp4/m5j0drYB uzsQ==
X-Gm-Message-State: ALoCoQndp37HEoB3Rp5XE50Z1mie2W22zjyZ8d48OIzL+OBpRSZQcD/46pCxVHefGNhCE5FGsIHQ
MIME-Version: 1.0
X-Received: by 10.229.56.200 with SMTP id z8mr20757588qcg.1.1390145712308; Sun, 19 Jan 2014 07:35:12 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Sun, 19 Jan 2014 07:35:12 -0800 (PST)
In-Reply-To: 
References: <52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com> <52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com>  <20140119103331.GA41873@elstar.local> 
Date: Sun, 19 Jan 2014 07:35:12 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a113308a45e72cb04f05485cc
Cc: SM , Paul Eggert , Eliot Lear , "netmod@ietf.org" 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 19 Jan 2014 15:35:28 -0000

--001a113308a45e72cb04f05485cc
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jan 19, 2014 at 4:55 AM, Ladislav Lhotka  wrote:

> Juergen Schoenwaelder  writes:
>
> > On Thu, Jan 16, 2014 at 11:38:01AM -0800, Andy Bierman wrote:
> >
> >> Enumeration Cons:
> >>    - release-specific YANG module must be maintained
> >>      and kept in sync with the TZ database and the server code
> >>    - values not yet in the TZ database (or will never be in
> >>      the TZ database) cannot be supported
> >
> > I think Andy makes a strong point here. This coupling will be a major
> > issue for any NETCONF implementation that is not shiped shrink wrapped
> > with a product. If I run a third party NETCONF server on my say Debian
> > system, the TZ database changes when the Debian packages are updated,
> > which happens pretty much independent of the NETCONF server update. So
> > it is likely that the IANA module shipped with the NETCONF server gets
> > out of sync with the underlying systems' database.
>
> On the other hand, for a management application configuring a large and
> heterogeneous network of devices, it would be beneficial to have a uniform
> interface.
>
>

The client needs to be using the module version reported by each server that
it is managing.  The problem with generating a new official YANG module  ~3
times a year
is that there most assuredly will be servers using different versions of
this YANG module.
The client must keep in synch with each server, based on the server
revisions.

The problem that I raised and Juergen commented on is for each individual
server staying
in synch with itself.  On an embedded system, the server vendor must ensure
that the
correct YANG module and TZ database are loaded on the device.  But what
about
a NETCONF server on an open system?  When the OS updates the tzdata package,
the YANG module (or maybe just the module revision date within the server
) will not
magically update to the new version as well.

An enumeration typedef must be updated ASAP. A string typedef never needs
to be updated.
Never mind the burden on IANA, what about the burden this update
requirement places
on server vendors and operators?



For an operator, the main point of having timezones properly configured is
> the ability to compare times reported from different sources. I think the
> POSIX format could serve this purpose quite well, and it would be up to
> NETCONF server implementations to translate the POSIX specification to the
> local system's conventions.
>
> Lada
>
> >
> > /js
>


Andy

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





On Sun, Jan 19, 2014 at 4:55 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:


Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<=
/a>> writes:




> On Thu, Jan 16, 2014 at 11:38:01AM -0800, Andy Bierman wrote:

>

>> Enumeration Cons:

>> =A0 =A0- release-specific YANG module must be maintained

>> =A0 =A0 =A0and kept in sync with the TZ database and the server co=
de

>> =A0 =A0- values not yet in the TZ database (or will never be in
>> =A0 =A0 =A0the TZ database) cannot be supported

>

> I think Andy makes a strong point here. This coupling will be a major<=
br>
> issue for any NETCONF implementation that is not shiped shrink wrapped=


> with a product. If I run a third party NETCONF server on my say Debian=


> system, the TZ database changes when the Debian packages are updated,<=
br>
> which happens pretty much independent of the NETCONF server update. So=


> it is likely that the IANA module shipped with the NETCONF server gets=


> out of sync with the underlying systems' database.



On the other hand, for a management application configuring a large and het=
erogeneous network of devices, it would be beneficial to have a uniform int=
erface.






is that there most assuredly will be servers using different versions =
of this YANG module.
The client must keep in synch with each serv=
er, based on the server revisions.

The problem tha=
t I raised and Juergen commented on is for each individual server staying

in synch with itself. =A0On an embedded system, the server vendor must=
 ensure that the
correct YANG module and TZ database are loaded o=
n the device. =A0But what about
a NETCONF server on an open syste=
m? =A0When the OS updates the tzdata package,


the YANG module (or maybe just the module revision date within the ser=
ver <hello>) will not
magically update to the new version a=
s well. =A0

An enumeration typedef must be updated=
 ASAP. A string typedef never needs to be updated.


Never mind the burden on IANA, what about the burden this update requi=
rement places
on server vendors and operators?





For an operator, the main point of having timezones properly configured is =
the ability to compare times reported from different sources. I think the P=
OSIX format could serve this purpose quite well, and it would be up to NETC=
ONF server implementations to translate the POSIX specification to the loca=
l system's conventions.




Lada



>

> /js


Andy
=



--001a113308a45e72cb04f05485cc--

From lhotka@nic.cz  Sun Jan 19 08:20:13 2014
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 9F99B1ADF4D for ; Sun, 19 Jan 2014 08:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.189
X-Spam-Level: 
X-Spam-Status: No, score=-1.189 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.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 Jq9dpbCbTcSF for ; Sun, 19 Jan 2014 08:20:11 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 621361ADF33 for ; Sun, 19 Jan 2014 08:20:10 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 462CF13F6B3; Sun, 19 Jan 2014 17:19:56 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390148397; bh=cEE1y7qEAtNRhwiZ9Tw4YwzeGpB/N2qvkaXamreCAHc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nOayoIuRVc32ind+ZdTYjaksAjuIL6ACo0AveZyeMNtJ9ti3FMDnLLShwW/vbFhrN QTc3FwzuN3SDmjXvE/EAaeGz58dfNLI/OPxrm0mGaZuEkOUVbZqL65Bkembma2T3Wj d8yY/KM/R7KyefBRBcTPmla41l5Wo04t0MfV1lWk=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Sun, 19 Jan 2014 17:19:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <688CAD4B-D8B0-43DC-8FDA-6334B47B8A53@nic.cz>
References: <52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com> <52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com>  <20140119103331.GA41873@elstar.local>  
To: Andy Bierman 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: SM , Paul Eggert , Eliot Lear , "netmod@ietf.org" 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 19 Jan 2014 16:20:13 -0000

On 19 Jan 2014, at 16:35, Andy Bierman  wrote:

>=20
>=20
>=20
> On Sun, Jan 19, 2014 at 4:55 AM, Ladislav Lhotka  =
wrote:
> Juergen Schoenwaelder  writes:
>=20
> > On Thu, Jan 16, 2014 at 11:38:01AM -0800, Andy Bierman wrote:
> >
> >> Enumeration Cons:
> >>    - release-specific YANG module must be maintained
> >>      and kept in sync with the TZ database and the server code
> >>    - values not yet in the TZ database (or will never be in
> >>      the TZ database) cannot be supported
> >
> > I think Andy makes a strong point here. This coupling will be a =
major
> > issue for any NETCONF implementation that is not shiped shrink =
wrapped
> > with a product. If I run a third party NETCONF server on my say =
Debian
> > system, the TZ database changes when the Debian packages are =
updated,
> > which happens pretty much independent of the NETCONF server update. =
So
> > it is likely that the IANA module shipped with the NETCONF server =
gets
> > out of sync with the underlying systems' database.
>=20
> On the other hand, for a management application configuring a large =
and heterogeneous network of devices, it would be beneficial to have a =
uniform interface.
>=20
>=20
>=20
> The client needs to be using the module version reported by each =
server that
> it is managing.  The problem with generating a new official YANG =
module  ~3 times a year
> is that there most assuredly will be servers using different versions =
of this YANG module.
> The client must keep in synch with each server, based on the server =
revisions.
>=20
> The problem that I raised and Juergen commented on is for each =
individual server staying
> in synch with itself.  On an embedded system, the server vendor must =
ensure that the
> correct YANG module and TZ database are loaded on the device.  But =
what about
> a NETCONF server on an open system?  When the OS updates the tzdata =
package,
> the YANG module (or maybe just the module revision date within the =
server ) will not
> magically update to the new version as well. =20
>=20
> An enumeration typedef must be updated ASAP. A string typedef never =
needs to be updated.
> Never mind the burden on IANA, what about the burden this update =
requirement places
> on server vendors and operators?

=46rom what I have read about the POSIX format, the client would =
essentially specify the offset from UTC and rules for DST shifts. So =
there would be no enumeration and no module updates, and the server will =
just have to apply the received data correctly.

The POSIX format is more cryptic than the Olson names but this can be =
handled on the client=92s side if necessary.=20

Lada
 =20
>=20
>=20
>=20
> For an operator, the main point of having timezones properly =
configured is the ability to compare times reported from different =
sources. I think the POSIX format could serve this purpose quite well, =
and it would be up to NETCONF server implementations to translate the =
POSIX specification to the local system's conventions.
>=20
> Lada
>=20
> >
> > /js
>=20
>=20
> Andy
>=20

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





From andy@yumaworks.com  Sun Jan 19 09:27:28 2014
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 216851ADF70 for ; Sun, 19 Jan 2014 09:27: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 rTj9_qLlVUpp for ; Sun, 19 Jan 2014 09:27:25 -0800 (PST)
Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7451ADF8C for ; Sun, 19 Jan 2014 09:27:25 -0800 (PST)
Received: by mail-qe0-f51.google.com with SMTP id q19so1286370qeb.38 for ; Sun, 19 Jan 2014 09:27:12 -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=ekOeXem5APeBzv6Qw7lVNZ+CMVDbG2H0IvvC3IUIjdY=; b=kfxsY0XBEmqN88MM5prAxZNlPepzBjQFpstaGDP/PjihSf+UNwNO6g0Ii8N1w7Mgo8 RfzoMqDLlvXGUS4y6xwepf0nNO2I1NssxnrObknrNmQToDpk9oTS2FNyys6fdAKpya9M +okcAES3/trhpQkYRBfUK4Yt52fPKOcOIF5m9etODbe3+xD/tnqoUH3U+PoFXya5Q9uq MHS00F85830Vjyhsdxfar4is6DiJTd0FxpioEDJnRjNiBIWkjmxtkOzlFCLogUq9cfnb TUO6jMaOk1Bov4YSmoiREBUUdyqiOHpKD5h9VGlM6Yd+97Ha0Hsi/FQqjK/GZX+Fkb6A rwGQ==
X-Gm-Message-State: ALoCoQlicGnYHvJ/mS1uHGIwt8i5zp9wVR/T8kWK0Dedx55qffWstj+n6uMj2wv7JR3H97GcZsml
MIME-Version: 1.0
X-Received: by 10.224.119.200 with SMTP id a8mr21273420qar.7.1390152431948; Sun, 19 Jan 2014 09:27:11 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Sun, 19 Jan 2014 09:27:11 -0800 (PST)
In-Reply-To: <688CAD4B-D8B0-43DC-8FDA-6334B47B8A53@nic.cz>
References: <52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com> <52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com>  <20140119103331.GA41873@elstar.local>   <688CAD4B-D8B0-43DC-8FDA-6334B47B8A53@nic.cz>
Date: Sun, 19 Jan 2014 09:27:11 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11c2fae6e4188504f056152b
Cc: SM , Paul Eggert , Eliot Lear , "netmod@ietf.org" 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 19 Jan 2014 17:27:28 -0000

--001a11c2fae6e4188504f056152b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 19, 2014 at 8:19 AM, Ladislav Lhotka  wrote:

>
> On 19 Jan 2014, at 16:35, Andy Bierman  wrote:
>
> >
> >
> >
> > On Sun, Jan 19, 2014 at 4:55 AM, Ladislav Lhotka  wrote:
> > Juergen Schoenwaelder  writes:
> >
> > > On Thu, Jan 16, 2014 at 11:38:01AM -0800, Andy Bierman wrote:
> > >
> > >> Enumeration Cons:
> > >>    - release-specific YANG module must be maintained
> > >>      and kept in sync with the TZ database and the server code
> > >>    - values not yet in the TZ database (or will never be in
> > >>      the TZ database) cannot be supported
> > >
> > > I think Andy makes a strong point here. This coupling will be a major
> > > issue for any NETCONF implementation that is not shiped shrink wrappe=
d
> > > with a product. If I run a third party NETCONF server on my say Debia=
n
> > > system, the TZ database changes when the Debian packages are updated,
> > > which happens pretty much independent of the NETCONF server update. S=
o
> > > it is likely that the IANA module shipped with the NETCONF server get=
s
> > > out of sync with the underlying systems' database.
> >
> > On the other hand, for a management application configuring a large and
> heterogeneous network of devices, it would be beneficial to have a unifor=
m
> interface.
> >
> >
> >
> > The client needs to be using the module version reported by each server
> that
> > it is managing.  The problem with generating a new official YANG module
>  ~3 times a year
> > is that there most assuredly will be servers using different versions o=
f
> this YANG module.
> > The client must keep in synch with each server, based on the server
> revisions.
> >
> > The problem that I raised and Juergen commented on is for each
> individual server staying
> > in synch with itself.  On an embedded system, the server vendor must
> ensure that the
> > correct YANG module and TZ database are loaded on the device.  But what
> about
> > a NETCONF server on an open system?  When the OS updates the tzdata
> package,
> > the YANG module (or maybe just the module revision date within the
> server ) will not
> > magically update to the new version as well.
> >
> > An enumeration typedef must be updated ASAP. A string typedef never
> needs to be updated.
> > Never mind the burden on IANA, what about the burden this update
> requirement places
> > on server vendors and operators?
>
> From what I have read about the POSIX format, the client would essentiall=
y
> specify the offset from UTC and rules for DST shifts. So there would be n=
o
> enumeration and no module updates, and the server will just have to apply
> the received data correctly.
>
> The POSIX format is more cryptic than the Olson names but this can be
> handled on the client=92s side if necessary.
>
>
This is a lot of complicated work for no gain.
I strongly oppose changing the format from Olson to POSIX.
POSIX is not user-friendly at all.

This debate is about encoding the Olson format with an enumeration
or with a string typedef, not starting over.

The value of a string timezone type is the same as the xpath1.0 typedef.
It lets tools know how to treat a special string type, without introducing
YANG language extensions to flag the string type as special.



> Lada
>

Andy


>
> >
> >
> >
> > For an operator, the main point of having timezones properly configured
> is the ability to compare times reported from different sources. I think
> the POSIX format could serve this purpose quite well, and it would be up =
to
> NETCONF server implementations to translate the POSIX specification to th=
e
> local system's conventions.
> >
> > Lada
> >
> > >
> > > /js
> >
> >
> > Andy
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--001a11c2fae6e4188504f056152b
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable





On Sun, Jan 19, 2014 at 8:19 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:




On 19 Jan 2014, at 16:35, Andy Bierman <andy@yumaworks.com> wrote:



>

>

>

> On Sun, Jan 19, 2014 at 4:55 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

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

>

> > On Thu, Jan 16, 2014 at 11:38:01AM -0800, Andy Bierman wrote:

> >

> >> Enumeration Cons:

> >> =A0 =A0- release-specific YANG module must be maintained

> >> =A0 =A0 =A0and kept in sync with the TZ database and the serv=
er code

> >> =A0 =A0- values not yet in the TZ database (or will never be =
in

> >> =A0 =A0 =A0the TZ database) cannot be supported

> >

> > I think Andy makes a strong point here. This coupling will be a m=
ajor

> > issue for any NETCONF implementation that is not shiped shrink wr=
apped

> > with a product. If I run a third party NETCONF server on my say D=
ebian

> > system, the TZ database changes when the Debian packages are upda=
ted,

> > which happens pretty much independent of the NETCONF server updat=
e. So

> > it is likely that the IANA module shipped with the NETCONF server=
 gets

> > out of sync with the underlying systems' database.

>

> On the other hand, for a management application configuring a large an=
d heterogeneous network of devices, it would be beneficial to have a unifor=
m interface.

>

>

>

> The client needs to be using the module version reported by each serve=
r that

> it is managing. =A0The problem with generating a new official YANG mod=
ule =A0~3 times a year

> is that there most assuredly will be servers using different versions =
of this YANG module.

> The client must keep in synch with each server, based on the server re=
visions.

>

> The problem that I raised and Juergen commented on is for each individ=
ual server staying

> in synch with itself. =A0On an embedded system, the server vendor must=
 ensure that the

> correct YANG module and TZ database are loaded on the device. =A0But w=
hat about

> a NETCONF server on an open system? =A0When the OS updates the tzdata =
package,

> the YANG module (or maybe just the module revision date within the ser=
ver <hello>) will not

> magically update to the new version as well.

>

> An enumeration typedef must be updated ASAP. A string typedef never ne=
eds to be updated.

> Never mind the burden on IANA, what about the burden this update requi=
rement places

> on server vendors and operators?



>From what I have read about the POSIX format, the client would essentially =
specify the offset from UTC and rules for DST shifts. So there would be no =
enumeration and no module updates, and the server will just have to apply t=
he received data correctly.




The POSIX format is more cryptic than the Olson names but this can be handl=
ed on the client=92s side if necessary.



This is a lot of complicated work for =
no gain.
I strongly oppose changing the format from Olson to POSI=
X.
POSIX is not user-friendly at all.


This debate is about encoding the Olson format with an enumeration
or with a string typedef, not starting over.

The=
 value of a string timezone type is the same as the xpath1.0 typedef.


It lets tools know how to treat a special string type, without introdu=
cing
YANG language extensions to flag the string type as special.=


=A0


Lada

Andy
=A0



>

>

>

> For an operator, the main point of having timezones properly configure=
d is the ability to compare times reported from different sources. I think =
the POSIX format could serve this purpose quite well, and it would be up to=
 NETCONF server implementations to translate the POSIX specification to the=
 local system's conventions.


>

> Lada

>

> >

> > /js

>

>

> Andy

>



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--001a11c2fae6e4188504f056152b--

From mbj@tail-f.com  Sun Jan 19 10:09:36 2014
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 8A6A91ACC80 for ; Sun, 19 Jan 2014 10:09:36 -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 CctPbzm4k7zG for ; Sun, 19 Jan 2014 10:09: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 4B52D1ADF31 for ; Sun, 19 Jan 2014 10:09:34 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 3B0ED240C1F6; Sun, 19 Jan 2014 19:09:20 +0100 (CET)
Date: Sun, 19 Jan 2014 19:09:19 +0100 (CET)
Message-Id: <20140119.190919.515368045.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <688CAD4B-D8B0-43DC-8FDA-6334B47B8A53@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-8859-7
Content-Transfer-Encoding: base64
Cc: netmod@ietf.org, sm@resistor.net, eggert@cs.ucla.edu, lear@cisco.com
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 19 Jan 2014 18:09:36 -0000

QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBTdW4sIEphbiAx
OSwgMjAxNCBhdCA4OjE5IEFNLCBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3Rl
Og0KPiANCj4gPg0KPiA+IE9uIDE5IEphbiAyMDE0LCBhdCAxNjozNSwgQW5keSBCaWVybWFuIDxh
bmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4g
PiBPbiBTdW4sIEphbiAxOSwgMjAxNCBhdCA0OjU1IEFNLCBMYWRpc2xhdiBMaG90a2EgPGxob3Rr
YUBuaWMuY3o+IHdyb3RlOg0KPiA+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndh
ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyaXRlczoNCj4gPiA+DQo+ID4gPiA+IE9uIFRo
dSwgSmFuIDE2LCAyMDE0IGF0IDExOjM4OjAxQU0gLTA4MDAsIEFuZHkgQmllcm1hbiB3cm90ZToN
Cj4gPiA+ID4NCj4gPiA+ID4+IEVudW1lcmF0aW9uIENvbnM6DQo+ID4gPiA+PiAgICAtIHJlbGVh
c2Utc3BlY2lmaWMgWUFORyBtb2R1bGUgbXVzdCBiZSBtYWludGFpbmVkDQo+ID4gPiA+PiAgICAg
IGFuZCBrZXB0IGluIHN5bmMgd2l0aCB0aGUgVFogZGF0YWJhc2UgYW5kIHRoZSBzZXJ2ZXIgY29k
ZQ0KPiA+ID4gPj4gICAgLSB2YWx1ZXMgbm90IHlldCBpbiB0aGUgVFogZGF0YWJhc2UgKG9yIHdp
bGwgbmV2ZXIgYmUgaW4NCj4gPiA+ID4+ICAgICAgdGhlIFRaIGRhdGFiYXNlKSBjYW5ub3QgYmUg
c3VwcG9ydGVkDQo+ID4gPiA+DQo+ID4gPiA+IEkgdGhpbmsgQW5keSBtYWtlcyBhIHN0cm9uZyBw
b2ludCBoZXJlLiBUaGlzIGNvdXBsaW5nIHdpbGwgYmUgYSBtYWpvcg0KPiA+ID4gPiBpc3N1ZSBm
b3IgYW55IE5FVENPTkYgaW1wbGVtZW50YXRpb24gdGhhdCBpcyBub3Qgc2hpcGVkIHNocmluayB3
cmFwcGVkDQo+ID4gPiA+IHdpdGggYSBwcm9kdWN0LiBJZiBJIHJ1biBhIHRoaXJkIHBhcnR5IE5F
VENPTkYgc2VydmVyIG9uIG15IHNheSBEZWJpYW4NCj4gPiA+ID4gc3lzdGVtLCB0aGUgVFogZGF0
YWJhc2UgY2hhbmdlcyB3aGVuIHRoZSBEZWJpYW4gcGFja2FnZXMgYXJlIHVwZGF0ZWQsDQo+ID4g
PiA+IHdoaWNoIGhhcHBlbnMgcHJldHR5IG11Y2ggaW5kZXBlbmRlbnQgb2YgdGhlIE5FVENPTkYg
c2VydmVyIHVwZGF0ZS4gU28NCj4gPiA+ID4gaXQgaXMgbGlrZWx5IHRoYXQgdGhlIElBTkEgbW9k
dWxlIHNoaXBwZWQgd2l0aCB0aGUgTkVUQ09ORiBzZXJ2ZXIgZ2V0cw0KPiA+ID4gPiBvdXQgb2Yg
c3luYyB3aXRoIHRoZSB1bmRlcmx5aW5nIHN5c3RlbXMnIGRhdGFiYXNlLg0KPiA+ID4NCj4gPiA+
IE9uIHRoZSBvdGhlciBoYW5kLCBmb3IgYSBtYW5hZ2VtZW50IGFwcGxpY2F0aW9uIGNvbmZpZ3Vy
aW5nIGEgbGFyZ2UgYW5kDQo+ID4gaGV0ZXJvZ2VuZW91cyBuZXR3b3JrIG9mIGRldmljZXMsIGl0
IHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gaGF2ZSBhIHVuaWZvcm0NCj4gPiBpbnRlcmZhY2UuDQo+
ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBUaGUgY2xpZW50IG5lZWRzIHRvIGJlIHVzaW5nIHRo
ZSBtb2R1bGUgdmVyc2lvbiByZXBvcnRlZCBieSBlYWNoIHNlcnZlcg0KPiA+IHRoYXQNCj4gPiA+
IGl0IGlzIG1hbmFnaW5nLiAgVGhlIHByb2JsZW0gd2l0aCBnZW5lcmF0aW5nIGEgbmV3IG9mZmlj
aWFsIFlBTkcgbW9kdWxlDQo+ID4gIH4zIHRpbWVzIGEgeWVhcg0KPiA+ID4gaXMgdGhhdCB0aGVy
ZSBtb3N0IGFzc3VyZWRseSB3aWxsIGJlIHNlcnZlcnMgdXNpbmcgZGlmZmVyZW50IHZlcnNpb25z
IG9mDQo+ID4gdGhpcyBZQU5HIG1vZHVsZS4NCj4gPiA+IFRoZSBjbGllbnQgbXVzdCBrZWVwIGlu
IHN5bmNoIHdpdGggZWFjaCBzZXJ2ZXIsIGJhc2VkIG9uIHRoZSBzZXJ2ZXINCj4gPiByZXZpc2lv
bnMuDQo+ID4gPg0KPiA+ID4gVGhlIHByb2JsZW0gdGhhdCBJIHJhaXNlZCBhbmQgSnVlcmdlbiBj
b21tZW50ZWQgb24gaXMgZm9yIGVhY2gNCj4gPiBpbmRpdmlkdWFsIHNlcnZlciBzdGF5aW5nDQo+
ID4gPiBpbiBzeW5jaCB3aXRoIGl0c2VsZi4gIE9uIGFuIGVtYmVkZGVkIHN5c3RlbSwgdGhlIHNl
cnZlciB2ZW5kb3IgbXVzdA0KPiA+IGVuc3VyZSB0aGF0IHRoZQ0KPiA+ID4gY29ycmVjdCBZQU5H
IG1vZHVsZSBhbmQgVFogZGF0YWJhc2UgYXJlIGxvYWRlZCBvbiB0aGUgZGV2aWNlLiAgQnV0IHdo
YXQNCj4gPiBhYm91dA0KPiA+ID4gYSBORVRDT05GIHNlcnZlciBvbiBhbiBvcGVuIHN5c3RlbT8g
IFdoZW4gdGhlIE9TIHVwZGF0ZXMgdGhlIHR6ZGF0YQ0KPiA+IHBhY2thZ2UsDQo+ID4gPiB0aGUg
WUFORyBtb2R1bGUgKG9yIG1heWJlIGp1c3QgdGhlIG1vZHVsZSByZXZpc2lvbiBkYXRlIHdpdGhp
biB0aGUNCj4gPiBzZXJ2ZXIgPGhlbGxvPikgd2lsbCBub3QNCj4gPiA+IG1hZ2ljYWxseSB1cGRh
dGUgdG8gdGhlIG5ldyB2ZXJzaW9uIGFzIHdlbGwuDQo+ID4gPg0KPiA+ID4gQW4gZW51bWVyYXRp
b24gdHlwZWRlZiBtdXN0IGJlIHVwZGF0ZWQgQVNBUC4gQSBzdHJpbmcgdHlwZWRlZiBuZXZlcg0K
PiA+IG5lZWRzIHRvIGJlIHVwZGF0ZWQuDQo+ID4gPiBOZXZlciBtaW5kIHRoZSBidXJkZW4gb24g
SUFOQSwgd2hhdCBhYm91dCB0aGUgYnVyZGVuIHRoaXMgdXBkYXRlDQo+ID4gcmVxdWlyZW1lbnQg
cGxhY2VzDQo+ID4gPiBvbiBzZXJ2ZXIgdmVuZG9ycyBhbmQgb3BlcmF0b3JzPw0KPiA+DQo+ID4g
RnJvbSB3aGF0IEkgaGF2ZSByZWFkIGFib3V0IHRoZSBQT1NJWCBmb3JtYXQsIHRoZSBjbGllbnQg
d291bGQgZXNzZW50aWFsbHkNCj4gPiBzcGVjaWZ5IHRoZSBvZmZzZXQgZnJvbSBVVEMgYW5kIHJ1
bGVzIGZvciBEU1Qgc2hpZnRzLiBTbyB0aGVyZSB3b3VsZCBiZSBubw0KPiA+IGVudW1lcmF0aW9u
IGFuZCBubyBtb2R1bGUgdXBkYXRlcywgYW5kIHRoZSBzZXJ2ZXIgd2lsbCBqdXN0IGhhdmUgdG8g
YXBwbHkNCj4gPiB0aGUgcmVjZWl2ZWQgZGF0YSBjb3JyZWN0bHkuDQo+ID4NCj4gPiBUaGUgUE9T
SVggZm9ybWF0IGlzIG1vcmUgY3J5cHRpYyB0aGFuIHRoZSBPbHNvbiBuYW1lcyBidXQgdGhpcyBj
YW4gYmUNCj4gPiBoYW5kbGVkIG9uIHRoZSBjbGllbnSicyBzaWRlIGlmIG5lY2Vzc2FyeS4NCj4g
Pg0KPiA+DQo+IFRoaXMgaXMgYSBsb3Qgb2YgY29tcGxpY2F0ZWQgd29yayBmb3Igbm8gZ2Fpbi4N
Cj4gSSBzdHJvbmdseSBvcHBvc2UgY2hhbmdpbmcgdGhlIGZvcm1hdCBmcm9tIE9sc29uIHRvIFBP
U0lYLg0KPiBQT1NJWCBpcyBub3QgdXNlci1mcmllbmRseSBhdCBhbGwuDQo+IA0KPiBUaGlzIGRl
YmF0ZSBpcyBhYm91dCBlbmNvZGluZyB0aGUgT2xzb24gZm9ybWF0IHdpdGggYW4gZW51bWVyYXRp
b24NCj4gb3Igd2l0aCBhIHN0cmluZyB0eXBlZGVmLCBub3Qgc3RhcnRpbmcgb3Zlci4NCg0KVGhl
IHByb2JsZW0gd2l0aCBhIHN0cmluZyBhcyB0aGUgdGltZXpvbmUgaXMgdGhhdCBpdCBpcw0Kbm9u
LWludGVyb3BlcmFibGUuICBBIGNvbW1vbiB1c2UgY2FzZSBpcyB0aGF0IGEgc2V0IG9mIGRldmlj
ZXMgZnJvbQ0KZGlmZmVyZW50IHZlbmRvcnMgYXJlIGluc3RhbGxlZCBhdCBzb21lIHNpdGUsIGFu
ZCB0aGUgb3BlcmF0b3Igd2FudHMNCnRvIHNldCB0aGUgc2FtZSB0aW1lem9uZSBvbiBhbGwgb2Yg
dGhlbS4gIEhvdyB3aWxsIHRoZSBvcGVyYXRvciBrbm93DQp3aGF0IHRvIHNldCBvbiBlYWNoIGRl
dmljZT8gIEV2ZW4gaWYgdGhlIGR2ZWljZSByZXBvcnRzIGl0cyBzdXBwb3J0ZWQNCnZhbHVlcyBh
cyBvcGVyYXRpb25hbCBzdGF0ZSwgaXQgZG9lc24ndCBoZWxwIG11Y2guDQoNCkJ1dCBmcm9tIHRo
ZSBkaXNjdXNzaW9uIHNvIGZhciBpdCBzZWVtcyB0aGlzIHByb2JsZW0gaXMgdG9vIGRpZmZpY3Vs
dA0KdG8gc29sdmUsIHNpbXBseSBiL2MgdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhIHN0YW5k
YXJkIHNldCBvZg0KdGltZXpvbmUgbG9jYXRpb25zLiAgV2UgdGhvdWdodCB3ZSBjb3VsZCB1c2Ug
dGhlIElBTkEtbWFpbnRhaW5lZCBUWg0KRGF0YWJhc2UgZm9yIHRoaXMsIGJ1dCBzaW5jZSBpdCBj
aGFuZ2VzIHRvbyBvZnRlbiBpdCB3b24ndCB3b3JrLg0KDQpJIHN1c3BlY3QgdGhvdWdoIHRoYXQg
aWYgd2UgY3JlYXRlIHRoaXMgYXMgYSBzdHJpbmcsIGl0IHdpbGwgd29yayBhcw0KaW50ZW5kZWQg
aW4gbW9zdCBwcmFjdGljYWwgc2l0dWF0aW9ucy4gIEkuZS4sIGlmIHRoZSBvcGVyYXRvciBjaG9v
c2VzDQphICJjb21tb24iIGxvY2F0aW9uLCBpdCB3aWxsIHdvcmsgIm1vc3Qgb2YgdGhlIHRpbWUi
LiAgVGhpcyBtaWdodCBiZQ0KZ29vZCBlbm91Z2guDQoNClNvLCBteSBjb25jbHVzaW9uIGFmdGVy
IHRoaXMgZGlzY3Vzc2lvbiwgaXMgdGhhdCB3ZSBzaG91bGQgcmVtb3ZlIHRoZQ0KZW51bSAoYW5k
IHRoYXQgZG9jdW1lbnQpLCBhbmQgdXNlIGEgc3RyaW5nIGluIHRoZSBpZXRmLXN5c3RlbSBtb2R1
bGUuDQoNCg0KL21hcnRpbg0K

From j.schoenwaelder@jacobs-university.de  Sun Jan 19 10:31:48 2014
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 D8C191ADF70 for ; Sun, 19 Jan 2014 10:31:48 -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 raJkhuHAi4mq for ; Sun, 19 Jan 2014 10:31: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 328311ADF38 for ; Sun, 19 Jan 2014 10:31:47 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6BC120042; Sun, 19 Jan 2014 19:31:33 +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 la4jeR6DFrHm; Sun, 19 Jan 2014 19:31:33 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BEA4A20032; Sun, 19 Jan 2014 19:31:32 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C316E2ABDCA2; Sun, 19 Jan 2014 19:31:30 +0100 (CET)
Date: Sun, 19 Jan 2014 19:31:30 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20140119183130.GB42529@elstar.local>
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org, sm@resistor.net, eggert@cs.ucla.edu, lear@cisco.com
References:  <688CAD4B-D8B0-43DC-8FDA-6334B47B8A53@nic.cz>  <20140119.190919.515368045.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140119.190919.515368045.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: sm@resistor.net, lear@cisco.com, eggert@cs.ucla.edu, netmod@ietf.org
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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: Sun, 19 Jan 2014 18:31:49 -0000

On Sun, Jan 19, 2014 at 07:09:19PM +0100, Martin Bjorklund wrote:

[...]
 
> So, my conclusion after this discussion, is that we should remove the
> enum (and that document), and use a string in the ietf-system module.

This is also my conclusion. So, anybody opposing this move forward?
Speak up now. I will read silence as agreement.

/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  Sun Jan 19 10:33:48 2014
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 148721ADF70 for ; Sun, 19 Jan 2014 10:33:48 -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 uDcbNqE4eEjN for ; Sun, 19 Jan 2014 10:33:45 -0800 (PST)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E86291ADF38 for ; Sun, 19 Jan 2014 10:33:44 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id f11so4871690qae.24 for ; Sun, 19 Jan 2014 10:33:31 -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=uS+d02Py/6QQ0fwyG2sWyTLBrEQVc2yKqzc3smEdrwE=; b=SuEODq/+b3FqK/z/zCmgNRUKTAU7CRK7wXcTnt5tCqDb7GAJ+4GLBFL8MgidebZeVq 1iZ40VoGjDdE5VqK42SwIdHVqMQetIAeBtpWTcYnvqhnxDJC+o58bCjwkMtjuIXRjHxc 72/cMmLk+F/1gvL4jGVNcauSPjUx4D1wk0xwZ/PUEv9reZN/Est7nQjB6+1NtRNkyNsj U4HShXEd2yjlxrSTPXluG0Kx5YlEKCtArPsbJTn1JqNC9+yLhQCpTjzLa+5qDx/yyGR8 qqYtBbWD8osgfqNYHD5PQH/hyiRC5yrUC0a7OFSgRSp8ChFj84xYeKfFCMsYN4UxjcCN ptlw==
X-Gm-Message-State: ALoCoQl9HUMjGouVL3GbMG5E66VJOc1GN+mlNeN8s+s5/SyeDw9MpQ3Q3/g9d08UtugktRHjAm2l
MIME-Version: 1.0
X-Received: by 10.140.27.179 with SMTP id 48mr6218812qgx.18.1390156411412; Sun, 19 Jan 2014 10:33:31 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Sun, 19 Jan 2014 10:33:31 -0800 (PST)
In-Reply-To: <20140119.190919.515368045.mbj@tail-f.com>
References:  <688CAD4B-D8B0-43DC-8FDA-6334B47B8A53@nic.cz>  <20140119.190919.515368045.mbj@tail-f.com>
Date: Sun, 19 Jan 2014 10:33:31 -0800
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11c0043416517004f05703fb
Cc: "netmod@ietf.org" , SM , Paul Eggert , Eliot Lear 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 19 Jan 2014 18:33:48 -0000

--001a11c0043416517004f05703fb
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 19, 2014 at 10:09 AM, Martin Bjorklund  wrote:

> Andy Bierman  wrote:
> > On Sun, Jan 19, 2014 at 8:19 AM, Ladislav Lhotka  wrote:
> >
> > >
> > > On 19 Jan 2014, at 16:35, Andy Bierman  wrote:
> > >
> > > >
> > > >
> > > >
> > > > On Sun, Jan 19, 2014 at 4:55 AM, Ladislav Lhotka 
> wrote:
> > > > Juergen Schoenwaelder  writes=
:
> > > >
> > > > > On Thu, Jan 16, 2014 at 11:38:01AM -0800, Andy Bierman wrote:
> > > > >
> > > > >> Enumeration Cons:
> > > > >>    - release-specific YANG module must be maintained
> > > > >>      and kept in sync with the TZ database and the server code
> > > > >>    - values not yet in the TZ database (or will never be in
> > > > >>      the TZ database) cannot be supported
> > > > >
> > > > > I think Andy makes a strong point here. This coupling will be a
> major
> > > > > issue for any NETCONF implementation that is not shiped shrink
> wrapped
> > > > > with a product. If I run a third party NETCONF server on my say
> Debian
> > > > > system, the TZ database changes when the Debian packages are
> updated,
> > > > > which happens pretty much independent of the NETCONF server
> update. So
> > > > > it is likely that the IANA module shipped with the NETCONF server
> gets
> > > > > out of sync with the underlying systems' database.
> > > >
> > > > On the other hand, for a management application configuring a large
> and
> > > heterogeneous network of devices, it would be beneficial to have a
> uniform
> > > interface.
> > > >
> > > >
> > > >
> > > > The client needs to be using the module version reported by each
> server
> > > that
> > > > it is managing.  The problem with generating a new official YANG
> module
> > >  ~3 times a year
> > > > is that there most assuredly will be servers using different
> versions of
> > > this YANG module.
> > > > The client must keep in synch with each server, based on the server
> > > revisions.
> > > >
> > > > The problem that I raised and Juergen commented on is for each
> > > individual server staying
> > > > in synch with itself.  On an embedded system, the server vendor mus=
t
> > > ensure that the
> > > > correct YANG module and TZ database are loaded on the device.  But
> what
> > > about
> > > > a NETCONF server on an open system?  When the OS updates the tzdata
> > > package,
> > > > the YANG module (or maybe just the module revision date within the
> > > server ) will not
> > > > magically update to the new version as well.
> > > >
> > > > An enumeration typedef must be updated ASAP. A string typedef never
> > > needs to be updated.
> > > > Never mind the burden on IANA, what about the burden this update
> > > requirement places
> > > > on server vendors and operators?
> > >
> > > From what I have read about the POSIX format, the client would
> essentially
> > > specify the offset from UTC and rules for DST shifts. So there would
> be no
> > > enumeration and no module updates, and the server will just have to
> apply
> > > the received data correctly.
> > >
> > > The POSIX format is more cryptic than the Olson names but this can be
> > > handled on the client=92s side if necessary.
> > >
> > >
> > This is a lot of complicated work for no gain.
> > I strongly oppose changing the format from Olson to POSIX.
> > POSIX is not user-friendly at all.
> >
> > This debate is about encoding the Olson format with an enumeration
> > or with a string typedef, not starting over.
>
> The problem with a string as the timezone is that it is
> non-interoperable.  A common use case is that a set of devices from
> different vendors are installed at some site, and the operator wants
> to set the same timezone on all of them.  How will the operator know
> what to set on each device?  Even if the dveice reports its supported
> values as operational state, it doesn't help much.
>
> But from the discussion so far it seems this problem is too difficult
> to solve, simply b/c there is no such thing as a standard set of
> timezone locations.  We thought we could use the IANA-maintained TZ
> Database for this, but since it changes too often it won't work.
>
> I suspect though that if we create this as a string, it will work as
> intended in most practical situations.  I.e., if the operator chooses
> a "common" location, it will work "most of the time".  This might be
> good enough.
>
> So, my conclusion after this discussion, is that we should remove the
> enum (and that document), and use a string in the ietf-system module.
>
>
+1

The worst that happens if the client sends an unsupported string,
it gets back an invalid-value error.  Since the CLI or WEBui (if present)
also needs the timezone set, NETCONF does not make the problem
any worse.  Advertising a YANG enumeration that did not exactly match
the server implementation would be worse.


> /martin
>

Andy

--001a11c0043416517004f05703fb
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable





On Sun, Jan 19, 2014 at 10:09 AM, Martin Bjorklund <mbj@tail-f.com> wrote:


Andy Bierman <andy@yumaworks.com> wrote:

> On Sun, Jan 19, 2014 at 8:19 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> >

> > On 19 Jan 2014, at 16:35, Andy Bierman <andy@yumaworks.com> wrote:

> >

> > >

> > >

> > >

> > > On Sun, Jan 19, 2014 at 4:55 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:<=
br>
> > >

> > > > On Thu, Jan 16, 2014 at 11:38:01AM -0800, Andy Bierman =
wrote:

> > > >

> > > >> Enumeration Cons:

> > > >> =A0 =A0- release-specific YANG module must be maint=
ained

> > > >> =A0 =A0 =A0and kept in sync with the TZ database an=
d the server code

> > > >> =A0 =A0- values not yet in the TZ database (or will=
 never be in

> > > >> =A0 =A0 =A0the TZ database) cannot be supported

> > > >

> > > > I think Andy makes a strong point here. This coupling w=
ill be a major

> > > > issue for any NETCONF implementation that is not shiped=
 shrink wrapped

> > > > with a product. If I run a third party NETCONF server o=
n my say Debian

> > > > system, the TZ database changes when the Debian package=
s are updated,

> > > > which happens pretty much independent of the NETCONF se=
rver update. So

> > > > it is likely that the IANA module shipped with the NETC=
ONF server gets

> > > > out of sync with the underlying systems' database.<=
br>
> > >

> > > On the other hand, for a management application configuring =
a large and

> > heterogeneous network of devices, it would be beneficial to have =
a uniform

> > interface.

> > >

> > >

> > >

> > > The client needs to be using the module version reported by =
each server

> > that

> > > it is managing. =A0The problem with generating a new officia=
l YANG module

> > =A0~3 times a year

> > > is that there most assuredly will be servers using different=
 versions of

> > this YANG module.

> > > The client must keep in synch with each server, based on the=
 server

> > revisions.

> > >

> > > The problem that I raised and Juergen commented on is for ea=
ch

> > individual server staying

> > > in synch with itself. =A0On an embedded system, the server v=
endor must

> > ensure that the

> > > correct YANG module and TZ database are loaded on the device=
. =A0But what

> > about

> > > a NETCONF server on an open system? =A0When the OS updates t=
he tzdata

> > package,

> > > the YANG module (or maybe just the module revision date with=
in the

> > server <hello>) will not

> > > magically update to the new version as well.

> > >

> > > An enumeration typedef must be updated ASAP. A string typede=
f never

> > needs to be updated.

> > > Never mind the burden on IANA, what about the burden this up=
date

> > requirement places

> > > on server vendors and operators?

> >

> > From what I have read about the POSIX format, the client would es=
sentially

> > specify the offset from UTC and rules for DST shifts. So there wo=
uld be no

> > enumeration and no module updates, and the server will just have =
to apply

> > the received data correctly.

> >

> > The POSIX format is more cryptic than the Olson names but this ca=
n be

> > handled on the client=92s side if necessary.

> >

> >

> This is a lot of complicated work for no gain.

> I strongly oppose changing the format from Olson to POSIX.

> POSIX is not user-friendly at all.

>

> This debate is about encoding the Olson format with an enumeration

> or with a string typedef, not starting over.



The problem with a string as the timezone is that it is

non-interoperable. =A0A common use case is that a set of devices from

different vendors are installed at some site, and the operator wants

to set the same timezone on all of them. =A0How will the operator know

what to set on each device? =A0Even if the dveice reports its supported

values as operational state, it doesn't help much.



But from the discussion so far it seems this problem is too difficult

to solve, simply b/c there is no such thing as a standard set of

timezone locations. =A0We thought we could use the IANA-maintained TZ

Database for this, but since it changes too often it won't work.



I suspect though that if we create this as a string, it will work as

intended in most practical situations. =A0I.e., if the operator chooses

a "common" location, it will work "most of the time". =
=A0This might be

good enough.



So, my conclusion after this discussion, is that we should remove the

enum (and that document), and use a string in the ietf-system module.



+1

The worst that happens i=
f the client sends an unsupported string,
it gets back an invalid=
-value error. =A0Since the CLI or WEBui (if present)


also needs the timezone set, NETCONF does not make the problem
any worse. =A0Advertising a YANG enumeration that did not exactly match<=
/div>
the server implementation would be worse.





/martin



Andy<=
/div>



--001a11c0043416517004f05703fb--

From sm@resistor.net  Sun Jan 19 10:46:21 2014
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 509871ADF70 for ; Sun, 19 Jan 2014 10:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] 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 cChSvN3U8tH8 for ; Sun, 19 Jan 2014 10:46:20 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6E81ADF38 for ; Sun, 19 Jan 2014 10:46:20 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s0JIjcGM023328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jan 2014 10:45:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1390157148; bh=2FZFKHlBIz0tWAqS+8XOfYNRw1grCZF4RntFLqZgvj8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W6AsIixdMiCphsvZ2PQFCfZpr9Ku/bSE8PZqjpgcr+FNr62AyyuyEnH5SnC0u77uh OQdv6P7JhdCPBvfMgWt5aCUJLm4zpr/9m6dbXayieibLdkUmQzOQt1OWwSsbpvsdL4 uY2q4XWXfz82nvXDWh8r1sLe7V2ySblWgjEofpjU=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1390157148; i=@resistor.net; bh=2FZFKHlBIz0tWAqS+8XOfYNRw1grCZF4RntFLqZgvj8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LlrSWZxMk4xn2iGNXp3/yslLNxzIgNV8PZMgmz76Ngd4O2aIIf0ctJR+4tXXeFKnf tHGQ/Y+ikQv7PdjGWCbnh+SMY41iqmh4D+zyzLLTXEuM0hk9SGTQVOeh/IT1ZBVlkG h/HVyeb3HXXTSpbxJaQ97QUvIkCHUnHiNUQig0C0=
Message-Id: <6.2.5.6.2.20140119104023.0ab164d0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 19 Jan 2014 10:44:12 -0800
To: Juergen Schoenwaelder , Martin Bjorklund 
From: SM 
In-Reply-To: <20140119183130.GB42529@elstar.local>
References:  <688CAD4B-D8B0-43DC-8FDA-6334B47B8A53@nic.cz>  <20140119.190919.515368045.mbj@tail-f.com> <20140119183130.GB42529@elstar.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: lear@cisco.com, eggert@cs.ucla.edu, netmod@ietf.org
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 19 Jan 2014 18:46:21 -0000

Hi Juergen,
At 10:31 19-01-2014, Juergen Schoenwaelder wrote:
>On Sun, Jan 19, 2014 at 07:09:19PM +0100, Martin Bjorklund wrote:
>
>[...]
>
> > So, my conclusion after this discussion, is that we should remove the
> > enum (and that document), and use a string in the ietf-system module.
>
>This is also my conclusion. So, anybody opposing this move forward?
>Speak up now. I will read silence as agreement.

I gather that "document" in the above refers to not moving forward 
with draft-ietf-netmod-iana-timezones-03.

Regards,
-sm



From mbj@tail-f.com  Sun Jan 19 13:02:41 2014
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 8B2EA1ADF78 for ; Sun, 19 Jan 2014 13:02:41 -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 ZkHgaJnOyLr3 for ; Sun, 19 Jan 2014 13:02:40 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E83461AC82A for ; Sun, 19 Jan 2014 13:02:39 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 97046240C1F6; Sun, 19 Jan 2014 22:02:25 +0100 (CET)
Date: Sun, 19 Jan 2014 22:02:25 +0100 (CET)
Message-Id: <20140119.220225.472788075.mbj@tail-f.com>
To: sm@resistor.net
From: Martin Bjorklund 
In-Reply-To: <6.2.5.6.2.20140119104023.0ab164d0@resistor.net>
References: <20140119.190919.515368045.mbj@tail-f.com> <20140119183130.GB42529@elstar.local> <6.2.5.6.2.20140119104023.0ab164d0@resistor.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: lear@cisco.com, eggert@cs.ucla.edu, netmod@ietf.org
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 19 Jan 2014 21:02:41 -0000

SM  wrote:
> Hi Juergen,
> At 10:31 19-01-2014, Juergen Schoenwaelder wrote:
> >On Sun, Jan 19, 2014 at 07:09:19PM +0100, Martin Bjorklund wrote:
> >
> >[...]
> >
> > > So, my conclusion after this discussion, is that we should remove the
> > > enum (and that document), and use a string in the ietf-system module.
> >
> >This is also my conclusion. So, anybody opposing this move forward?
> >Speak up now. I will read silence as agreement.
> 
> I gather that "document" in the above refers to not moving forward with
> draft-ietf-netmod-iana-timezones-03.

Yes.


/martin

From lhotka@nic.cz  Sun Jan 19 22:54:51 2014
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 92F2A1A0058 for ; Sun, 19 Jan 2014 22:54:51 -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 DgA3n7bkqV4Q for ; Sun, 19 Jan 2014 22:54:49 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 542DA1A0057 for ; Sun, 19 Jan 2014 22:54:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 3A8C3540437; Mon, 20 Jan 2014 07:54:47 +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 i68MZxqBIUM8; Mon, 20 Jan 2014 07:54:42 +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 333CC540193; Mon, 20 Jan 2014 07:54:37 +0100 (CET)
From: Ladislav Lhotka 
To: Andy Bierman 
In-Reply-To: 
References: <52D80720.80002@cs.ucla.edu> <20140116.184249.296066285.mbj@tail-f.com> <52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com>  <20140119103331.GA41873@elstar.local>   <688CAD4B-D8B0-43DC-8FDA-6334B47B8A53@nic.cz> 
User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Mon, 20 Jan 2014 07:54:35 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: SM , Paul Eggert , Eliot Lear , "netmod@ietf.org" 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 06:54:51 -0000

Andy Bierman  writes:

> On Sun, Jan 19, 2014 at 8:19 AM, Ladislav Lhotka  wrote:
>
>>
>> On 19 Jan 2014, at 16:35, Andy Bierman  wrote:
>>
>> >
>> >
>> >
>> > On Sun, Jan 19, 2014 at 4:55 AM, Ladislav Lhotka  wrote:
>> > Juergen Schoenwaelder  writes:
>> >
>> > > On Thu, Jan 16, 2014 at 11:38:01AM -0800, Andy Bierman wrote:
>> > >
>> > >> Enumeration Cons:
>> > >>    - release-specific YANG module must be maintained
>> > >>      and kept in sync with the TZ database and the server code
>> > >>    - values not yet in the TZ database (or will never be in
>> > >>      the TZ database) cannot be supported
>> > >
>> > > I think Andy makes a strong point here. This coupling will be a major
>> > > issue for any NETCONF implementation that is not shiped shrink wrapp=
ed
>> > > with a product. If I run a third party NETCONF server on my say Debi=
an
>> > > system, the TZ database changes when the Debian packages are updated,
>> > > which happens pretty much independent of the NETCONF server update. =
So
>> > > it is likely that the IANA module shipped with the NETCONF server ge=
ts
>> > > out of sync with the underlying systems' database.
>> >
>> > On the other hand, for a management application configuring a large and
>> heterogeneous network of devices, it would be beneficial to have a unifo=
rm
>> interface.
>> >
>> >
>> >
>> > The client needs to be using the module version reported by each server
>> that
>> > it is managing.  The problem with generating a new official YANG module
>>  ~3 times a year
>> > is that there most assuredly will be servers using different versions =
of
>> this YANG module.
>> > The client must keep in synch with each server, based on the server
>> revisions.
>> >
>> > The problem that I raised and Juergen commented on is for each
>> individual server staying
>> > in synch with itself.  On an embedded system, the server vendor must
>> ensure that the
>> > correct YANG module and TZ database are loaded on the device.  But what
>> about
>> > a NETCONF server on an open system?  When the OS updates the tzdata
>> package,
>> > the YANG module (or maybe just the module revision date within the
>> server ) will not
>> > magically update to the new version as well.
>> >
>> > An enumeration typedef must be updated ASAP. A string typedef never
>> needs to be updated.
>> > Never mind the burden on IANA, what about the burden this update
>> requirement places
>> > on server vendors and operators?
>>
>> From what I have read about the POSIX format, the client would essential=
ly
>> specify the offset from UTC and rules for DST shifts. So there would be =
no
>> enumeration and no module updates, and the server will just have to apply
>> the received data correctly.
>>
>> The POSIX format is more cryptic than the Olson names but this can be
>> handled on the client=E2=80=99s side if necessary.
>>
>>
> This is a lot of complicated work for no gain.
> I strongly oppose changing the format from Olson to POSIX.
> POSIX is not user-friendly at all.

User-friendliness is nice, but only as long as it allows for setting the ti=
mezone correctly and reliably.

And as I wrote, a friendly interface to human users can be added by a clien=
t application.

>
> This debate is about encoding the Olson format with an enumeration
> or with a string typedef, not starting over.

IMO, the debate is about how to do the right thing wrt timezone setting.

Lada

>
> The value of a string timezone type is the same as the xpath1.0 typedef.
> It lets tools know how to treat a special string type, without introducing
> YANG language extensions to flag the string type as special.
>
>
>
>> Lada
>>
>
> Andy
>
>
>>
>> >
>> >
>> >
>> > For an operator, the main point of having timezones properly configured
>> is the ability to compare times reported from different sources. I think
>> the POSIX format could serve this purpose quite well, and it would be up=
 to
>> NETCONF server implementations to translate the POSIX specification to t=
he
>> local system's conventions.
>> >
>> > Lada
>> >
>> > >
>> > > /js
>> >
>> >
>> > Andy
>> >
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>>

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

From lhotka@nic.cz  Sun Jan 19 23:16:51 2014
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 11D311A005B for ; Sun, 19 Jan 2014 23:16:51 -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 KYQ_A2rx5uhQ for ; Sun, 19 Jan 2014 23:16:49 -0800 (PST)
Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4085F1A0058 for ; Sun, 19 Jan 2014 23:16:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 27F3B540437; Mon, 20 Jan 2014 08:16: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 MpaHTR872tdU; Mon, 20 Jan 2014 08:16:46 +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 9C3B4540193; Mon, 20 Jan 2014 08:16:45 +0100 (CET)
From: Ladislav Lhotka 
To: Martin Bjorklund , andy@yumaworks.com
In-Reply-To: <20140119.190919.515368045.mbj@tail-f.com>
References:  <688CAD4B-D8B0-43DC-8FDA-6334B47B8A53@nic.cz>  <20140119.190919.515368045.mbj@tail-f.com>
User-Agent: Notmuch/0.17~rc2+11~g2de8ce9 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0)
Date: Mon, 20 Jan 2014 08:16:44 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: sm@resistor.net, eggert@cs.ucla.edu, netmod@ietf.org, lear@cisco.com
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 07:16:51 -0000

Martin Bjorklund  writes:

> Andy Bierman  wrote:
>> On Sun, Jan 19, 2014 at 8:19 AM, Ladislav Lhotka  wrote:
>>=20
>> >
>> > On 19 Jan 2014, at 16:35, Andy Bierman  wrote:
>> >
>> > >
>> > >
>> > >
>> > > On Sun, Jan 19, 2014 at 4:55 AM, Ladislav Lhotka  wro=
te:
>> > > Juergen Schoenwaelder  writes:
>> > >
>> > > > On Thu, Jan 16, 2014 at 11:38:01AM -0800, Andy Bierman wrote:
>> > > >
>> > > >> Enumeration Cons:
>> > > >>    - release-specific YANG module must be maintained
>> > > >>      and kept in sync with the TZ database and the server code
>> > > >>    - values not yet in the TZ database (or will never be in
>> > > >>      the TZ database) cannot be supported
>> > > >
>> > > > I think Andy makes a strong point here. This coupling will be a ma=
jor
>> > > > issue for any NETCONF implementation that is not shiped shrink wra=
pped
>> > > > with a product. If I run a third party NETCONF server on my say De=
bian
>> > > > system, the TZ database changes when the Debian packages are updat=
ed,
>> > > > which happens pretty much independent of the NETCONF server update=
. So
>> > > > it is likely that the IANA module shipped with the NETCONF server =
gets
>> > > > out of sync with the underlying systems' database.
>> > >
>> > > On the other hand, for a management application configuring a large =
and
>> > heterogeneous network of devices, it would be beneficial to have a uni=
form
>> > interface.
>> > >
>> > >
>> > >
>> > > The client needs to be using the module version reported by each ser=
ver
>> > that
>> > > it is managing.  The problem with generating a new official YANG mod=
ule
>> >  ~3 times a year
>> > > is that there most assuredly will be servers using different version=
s of
>> > this YANG module.
>> > > The client must keep in synch with each server, based on the server
>> > revisions.
>> > >
>> > > The problem that I raised and Juergen commented on is for each
>> > individual server staying
>> > > in synch with itself.  On an embedded system, the server vendor must
>> > ensure that the
>> > > correct YANG module and TZ database are loaded on the device.  But w=
hat
>> > about
>> > > a NETCONF server on an open system?  When the OS updates the tzdata
>> > package,
>> > > the YANG module (or maybe just the module revision date within the
>> > server ) will not
>> > > magically update to the new version as well.
>> > >
>> > > An enumeration typedef must be updated ASAP. A string typedef never
>> > needs to be updated.
>> > > Never mind the burden on IANA, what about the burden this update
>> > requirement places
>> > > on server vendors and operators?
>> >
>> > From what I have read about the POSIX format, the client would essenti=
ally
>> > specify the offset from UTC and rules for DST shifts. So there would b=
e no
>> > enumeration and no module updates, and the server will just have to ap=
ply
>> > the received data correctly.
>> >
>> > The POSIX format is more cryptic than the Olson names but this can be
>> > handled on the client=E2=80=99s side if necessary.
>> >
>> >
>> This is a lot of complicated work for no gain.
>> I strongly oppose changing the format from Olson to POSIX.
>> POSIX is not user-friendly at all.
>>=20
>> This debate is about encoding the Olson format with an enumeration
>> or with a string typedef, not starting over.
>
> The problem with a string as the timezone is that it is
> non-interoperable.  A common use case is that a set of devices from
> different vendors are installed at some site, and the operator wants
> to set the same timezone on all of them.  How will the operator know
> what to set on each device?  Even if the dveice reports its supported
> values as operational state, it doesn't help much.

Right.

>
> But from the discussion so far it seems this problem is too difficult
> to solve, simply b/c there is no such thing as a standard set of
> timezone locations.  We thought we could use the IANA-maintained TZ
> Database for this, but since it changes too often it won't work.

Moving to the string type does not improve the database in any way, it only=
 shifts the responsibility for resolving possible mismatches from the serve=
r to the client.=20

>
> I suspect though that if we create this as a string, it will work as
> intended in most practical situations.  I.e., if the operator chooses
> a "common" location, it will work "most of the time".  This might be
> good enough.

Probably. I suspect though that the same is true for the current Olson form=
at enumeration, even if it was updated only every five years or so.

>
> So, my conclusion after this discussion, is that we should remove the
> enum (and that document), and use a string in the ietf-system module.

This is fine for a human user configuring a small number of devices but not=
 so much for an automated application and large networks.

Lada

>
>
> /martin

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

From lear@cisco.com  Mon Jan 20 00:46:17 2014
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 A8E111A00A3 for ; Mon, 20 Jan 2014 00:46:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.336
X-Spam-Level: 
X-Spam-Status: No, score=-7.336 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, 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 y5fQTX0gPypW for ; Mon, 20 Jan 2014 00:46:16 -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 292861A009F for ; Mon, 20 Jan 2014 00:46:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1224; q=dns/txt; s=iport; t=1390207577; x=1391417177; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=59Bcyeuo7Ax+X5p74tN82PoN2N7MlC5Xu+e9oXxKO6c=; b=LWfcass/8E10qNr2lLKUsKVIB6anoQof2m2WNSxcqBSEEsvceZM81nhc JGVj/kZyvKHUm8BtapxCpZK4PqrD6YvgEnGdLFvwruak3lyhQ1LGsLnh1 XPtQ8K5sNnp3H1l/KG+Xd4/nU4aDRcBi4BZdzRfAsq1xUehdwfZ08Cior A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFABnh3FKQ/khL/2dsb2JhbABZgwuEC7hAgQkWdIImAQEEI1UBEAsaAgUWCwICCQMCAQIBRQYBDAEHAQGIAadzm14XgSmMc2MHgm+BSQEDmCKSGIMuOw
X-IronPort-AV: E=Sophos;i="4.95,689,1384300800";  d="scan'208";a="3878490"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 20 Jan 2014 08:46:15 +0000
Received: from dhcp-wlsn01-vlan250-10-147-28-71.cisco.com (dhcp-wlsn01-vlan250-10-147-28-71.cisco.com [10.147.28.71]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0K8kFUe007549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jan 2014 08:46:15 GMT
Message-ID: <52DCE256.1040600@cisco.com>
Date: Mon, 20 Jan 2014 09:46:14 +0100
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ladislav Lhotka , Martin Bjorklund , andy@yumaworks.com
References:  <688CAD4B-D8B0-43DC-8FDA-6334B47B8A53@nic.cz>  <20140119.190919.515368045.mbj@tail-f.com> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: sm@resistor.net, eggert@cs.ucla.edu, netmod@ietf.org
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 08:46:17 -0000

Hi everyone,

I'm sorry this is so complex, but there are still a number of options,
none of which are perfect.  Maybe perfection isn't the right target here.

1.  Assume self-consistency from an IETF part.  We can't control what
others do.  We don't write code, and we can expect at least some
localization.  An example of this localization may be adding other
names.  This is my suggested approach, and it means grepping for Link
and Zone lines, or better simply requiring that the name be listed in
the TZ database.  Details of that latter option to be worked out by
yourselves.  The drawback is that localization differs between vendors.

2.  Go with a string and assume absolutely no semantics associated with
it.  I have no idea if this serves your purposes, other than to say,
well if the two systems have a configured TZ then the chances are they
will to some extent agree on what time it is. (N.B., database version
skew means they may disagree).

3.  Go with a POSIX string.  It is possible to some reasonable degree
generate a POSIX string from an Olson database entry, although there are
MANY corner cases, and you have periodically to recompute the string.

Just some thoughts.

Eliot

From bclaise@cisco.com  Mon Jan 20 01:04:48 2014
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 99B3E1A001D for ; Mon, 20 Jan 2014 01:04:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.335
X-Spam-Level: 
X-Spam-Status: No, score=-7.335 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, RP_MATCHES_RCVD=-0.535, 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 dCdTOJKNUEZ3 for ; Mon, 20 Jan 2014 01:04:46 -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 258E61A001C for ; Mon, 20 Jan 2014 01:04:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6360; q=dns/txt; s=iport; t=1390208686; x=1391418286; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=dB8Yah1SXe+7SFmgWi/+5GQowcf3s4maSxdP6YlIHtQ=; b=Z7YQaRKO+X+GestxP91i7EGRKyc+Rteckbiy39PNJ0JmugocekEupasF ir+sUEJpYxAZv1GERzuJFxwQi3hFheLbcPY89SngJrpfV97M8lHL23lOH vTDtPWPXJgYfDnbpz4YliZ83bWwDTaVebqaUWBo0I8qun7dJ0UXUNJ3TE k=;
X-IronPort-AV: E=Sophos;i="4.95,689,1384300800"; d="scan'208,217";a="3209846"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 20 Jan 2014 09:04:45 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0K94i9R012245; Mon, 20 Jan 2014 09:04:44 GMT
Message-ID: <52DCE6AB.8050404@cisco.com>
Date: Mon, 20 Jan 2014 10:04:43 +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: Paul Eggert , Martin Bjorklund 
References: <52D83C94.4070407@cs.ucla.edu>	<52D8C867.30402@cisco.com>	<52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu>
In-Reply-To: <52D9BF28.8070103@cs.ucla.edu>
Content-Type: multipart/alternative; boundary="------------030003010108090003090206"
Cc: lear@cisco.com, netmod@ietf.org, sm@resistor.net, Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 09:04:48 -0000

This is a multi-part message in MIME format.
--------------030003010108090003090206
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

Taking into account
- that there is no canonical list of TZ time zone names (political 
reasons were mentioned)
- that the generate number solutions (from hash or coordinates) don't 
address the removal (and obsoleting) of zones.
- that I'm not too clear if IANA would support a program to generate 
this YANG module
- Lada's feedback: "The value is unused by YANG and the XML encoding, 
but is carried as a convenience to implementors."
I'm wondering if it doesn't make sense to:
- not ask IANA to maintain this YANG module (so removing the IANA 
considerations)
- express: "this document is generated from *Time Zone Data v. 2013i* 
(Released 2013-12-17) tzdata2013i.tar.gz 
 
(213.7kb)"
- see how the situation evolves in the couple of years.
     maybe wait for a canonical list of TZ names
     maybe update this YANG module with a new RFC in a couple of years 
if there are many entry additions/deletions
     ...

Note: without a quick resolution on this issue (max tomorrow morning), I 
will have to remove draft-ietf-netmod-system-mgmt 
 from 
the telechat this Thursday.

Regards, Benoit
> Martin Bjorklund wrote:
>
>> We want the YANG module to match what the underlying system is 
>> actually using, provided they support the TZ Database available from 
>> IANA.
>
> OK, but the typical case is that if the underlying system supports the 
> TZ database, it also supports POSIX TZ strings such as UTC0. So if we 
> want the YANG module to match what the underlying system is actually 
> using ...
>
>> I think it is ok that the system actually would internally accept 
>> e.g. UTC0, even if it is not available in the YANG module.
>
> ... then we might want to rethink this.
>
>> It is of course still trivial to write the program that takes as 
>> input the current YANG module and the new tzdata.tar.gz file and 
>> produces a new YANG module. If this is what we want to do, I can 
>> write that program.  But the question is if this procedure is ok for 
>> IANA?
>
> That would require that the TZ coordinator maintain the YANG module.  
> I think it's better to have YANG-only stuff maintained by the YANG 
> maintainers.  TZ database maintenance is a pain enough already, and 
> its maintenance procedure won't scale to also maintaining YANG 
> timezone data, CLDR timezone data, etc.
> .
>


--------------030003010108090003090206
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Dear all,

      

      Taking into account 

      - that there is no canonical list of TZ time zone names (political
      reasons were mentioned)

      - that the generate number solutions (from hash or coordinates)
      don't address the removal (and obsoleting) of
      zones.

      - that I'm not too clear if IANA would support a program to
      generate this YANG module

      - Lada's feedback: "The value is unused by YANG and the XML
      encoding, but is carried as a convenience to implementors."

      I'm wondering if it doesn't make sense to:

      - not ask IANA to maintain this YANG module (so removing the IANA
      considerations)

      - express: "this document is generated from Time Zone Data v.
        2013i (Released 2013-12-17) tzdata2013i.tar.gz
      (213.7kb)"

      - see how the situation evolves in the couple of years. 

          maybe wait for a canonical list of TZ names

          maybe update this YANG module with a new RFC in a couple of
      years if there are many entry additions/deletions

          ...

      

      Note: without a quick resolution on this issue (max tomorrow
      morning), I will have to remove draft-ietf-netmod-system-mgmt
      from the telechat this Thursday.

      

      Regards, Benoit

    

    
Martin
      Bjorklund wrote:
      

      

      
We want the YANG module to match what the
        underlying system is actually using, provided they support the
        TZ Database available from IANA.
        

      

      

      OK, but the typical case is that if the underlying system supports
      the TZ database, it also supports POSIX TZ strings such as UTC0. 
      So if we want the YANG module to match what the underlying system
      is actually using ...
      

      

      
I think it is ok that the system actually
        would internally accept e.g. UTC0, even if it is not available
        in the YANG module.
        

      

      

      ... then we might want to rethink this.
      

      

      
It is of course still trivial to write the
        program that takes as input the current YANG module and the new
        tzdata<vsn>.tar.gz file and produces a new YANG module. 
        If this is what we want to do, I can write that program.  But
        the question is if this procedure is ok for IANA?
        

      

      

      That would require that the TZ coordinator maintain the YANG
      module.  I think it's better to have YANG-only stuff maintained by
      the YANG maintainers.  TZ database maintenance is a pain enough
      already, and its maintenance procedure won't scale to also
      maintaining YANG timezone data, CLDR timezone data, etc.
      

      .
      

      

    

    

  


--------------030003010108090003090206--

From lhotka@nic.cz  Mon Jan 20 01:19:32 2014
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 6F8A31A0050 for ; Mon, 20 Jan 2014 01:19:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 4n9ZOPFGbkRv for ; Mon, 20 Jan 2014 01:19:29 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 985E41A001D for ; Mon, 20 Jan 2014 01:19:28 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0900414050B; Mon, 20 Jan 2014 10:19:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390209568; bh=xJpNEblYxheqwXRrN5mtJF4yscVOBVgQz10J4y0UcA0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=HIBJsjAY+TkjussyZigygZ5zDKa9CNx5om+x7FY0dZrUxyIE9te7LnHD6FbJIKYtG vee/PrMjBhC3O3VTx8VOXlrSjKIwGx4fPwfSnXxPYJCt90Zs/hlXEw3WXBwmBJBmkA sNDCPSLoCkNrIfbLgFazipSERfUaZHxL1pLd6wJc=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <52DCE6AB.8050404@cisco.com>
Date: Mon, 20 Jan 2014 10:19:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz>
References: <52D83C94.4070407@cs.ucla.edu>	<52D8C867.30402@cisco.com>	<52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: Eliot Lear , netmod@ietf.org, Paul Eggert , SM , Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 09:19:32 -0000

On 20 Jan 2014, at 10:04, Benoit Claise  wrote:

> Dear all,
>=20
> Taking into account=20
> - that there is no canonical list of TZ time zone names (political =
reasons were mentioned)
> - that the generate number solutions (from hash or coordinates) don't =
address the removal (and obsoleting) of zones.
> - that I'm not too clear if IANA would support a program to generate =
this YANG module
> - Lada's feedback: "The value is unused by YANG and the XML encoding, =
but is carried as a convenience to implementors.=94

In other words, I think the =93value=94 substatements can be safely =
removed from the enums, they seem to be more of a nuisance than =
convenience.

> I'm wondering if it doesn't make sense to:
> - not ask IANA to maintain this YANG module (so removing the IANA =
considerations)

+1

> - express: "this document is generated from Time Zone Data v. 2013i =
(Released 2013-12-17) tzdata2013i.tar.gz (213.7kb)=94

+1

> - see how the situation evolves in the couple of years.=20
>     maybe wait for a canonical list of TZ names
>     maybe update this YANG module with a new RFC in a couple of years =
if there are many entry additions/deletions

+1

Lada

>     ...
>=20
> Note: without a quick resolution on this issue (max tomorrow morning), =
I will have to remove draft-ietf-netmod-system-mgmt from the telechat =
this Thursday.
>=20
> Regards, Benoit
>> Martin Bjorklund wrote:=20
>>=20
>>> We want the YANG module to match what the underlying system is =
actually using, provided they support the         TZ Database available =
from IANA.=20
>>=20
>> OK, but the typical case is that if the underlying system supports =
the TZ database, it also supports POSIX TZ strings such as UTC0.  So if =
we want the YANG module to match what the underlying system is actually =
using ...=20
>>=20
>>> I think it is ok that the system actually would internally accept =
e.g. UTC0, even if it is not available         in the YANG module.=20
>>=20
>> ... then we might want to rethink this.=20
>>=20
>>> It is of course still trivial to write the program that takes as =
input the current YANG module and the new tzdata.tar.gz file and =
produces a new YANG module.  If this is what we want to do, I can write =
that program.  But the question is if this procedure is ok for IANA?=20
>>=20
>> That would require that the TZ coordinator maintain the YANG module.  =
I think it's better to have YANG-only stuff maintained by the YANG =
maintainers.  TZ database maintenance is a pain enough already, and its =
maintenance procedure won't scale to also maintaining YANG timezone =
data, CLDR timezone data, etc.=20
>> .=20
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From j.schoenwaelder@jacobs-university.de  Mon Jan 20 01:35:48 2014
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 5CD731A00A8 for ; Mon, 20 Jan 2014 01:35:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.085
X-Spam-Level: 
X-Spam-Status: No, score=-0.085 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 GHYo1AwThXnS for ; Mon, 20 Jan 2014 01:35:46 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EE8281A001D for ; Mon, 20 Jan 2014 01:35:45 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AFAD82006F; Mon, 20 Jan 2014 10:35:45 +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 vaJJsC9hFmzj; Mon, 20 Jan 2014 10:35:45 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D22F2003B; Mon, 20 Jan 2014 10:35:44 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 9BB1C2ABF217; Mon, 20 Jan 2014 10:35:42 +0100 (CET)
Date: Mon, 20 Jan 2014 10:35:42 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140120093542.GB43960@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Benoit Claise , Eliot Lear , netmod@ietf.org, Paul Eggert , SM , Michelle Cotton 
References: <52D83C94.4070407@cs.ucla.edu> <52D8C867.30402@cisco.com> <52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Paul Eggert , Eliot Lear , netmod@ietf.org, SM , Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 09:35:48 -0000

On Mon, Jan 20, 2014 at 10:19:27AM +0100, Ladislav Lhotka wrote:
> 
> On 20 Jan 2014, at 10:04, Benoit Claise  wrote:
> 
> > Dear all,
> > 
> > Taking into account 
> > - that there is no canonical list of TZ time zone names (political reasons were mentioned)
> > - that the generate number solutions (from hash or coordinates) don't address the removal (and obsoleting) of zones.
> > - that I'm not too clear if IANA would support a program to generate this YANG module
> > - Lada's feedback: "The value is unused by YANG and the XML encoding, but is carried as a convenience to implementors.â€
> 
> In other words, I think the “value†substatements can be safely removed from the enums, they seem to be more of a nuisance than convenience.

RFC 6020 section 9.6.4.2:

   If a value is not specified, then one will be automatically assigned.
   If the "enum" substatement is the first one defined, the assigned
   value is zero (0); otherwise, the assigned value is one greater than
   the current highest enum value.

This essentially means any change of order will cause different
numbers to be assigned. Lets not get into a debate whether this
is a feature or but - it is just how Yang 1.0 is defined.

/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 Jan 20 01:39:52 2014
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 064EF1A00A3 for ; Mon, 20 Jan 2014 01:39:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 wDjza2mTDc_x for ; Mon, 20 Jan 2014 01:39:51 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C50DA1A0050 for ; Mon, 20 Jan 2014 01:39:50 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D463020074; Mon, 20 Jan 2014 10:39: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 CwogH-9d4-mD; Mon, 20 Jan 2014 10:39: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 2069E20071; Mon, 20 Jan 2014 10:39:50 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 4377A2ABF32E; Mon, 20 Jan 2014 10:39:47 +0100 (CET)
Date: Mon, 20 Jan 2014 10:39:46 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140120093945.GC43960@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Andy Bierman , SM , "netmod@ietf.org" , Eliot Lear , Paul Eggert 
References: <20140116.184249.296066285.mbj@tail-f.com> <52D8221B.8090001@cs.ucla.edu> <20140116.201519.152036089.mbj@tail-f.com>  <20140119103331.GA41873@elstar.local>   <688CAD4B-D8B0-43DC-8FDA-6334B47B8A53@nic.cz>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: SM , Eliot Lear , Paul Eggert , "netmod@ietf.org" 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 09:39:52 -0000

On Mon, Jan 20, 2014 at 07:54:35AM +0100, Ladislav Lhotka wrote:
> Andy Bierman  writes:
> 
> > This is a lot of complicated work for no gain.
> > I strongly oppose changing the format from Olson to POSIX.
> > POSIX is not user-friendly at all.
> 
> User-friendliness is nice, but only as long as it allows for setting the timezone correctly and reliably.
> 
> And as I wrote, a friendly interface to human users can be added by a client application.
> 

Our goal is to 'fix' the definition of the timezone-location leaf at
this point in time.  Other options can be added to the timezone choice
in the future once we have gained experience that this is needed.

/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 Jan 20 01:40:06 2014
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 514F71A00AB for ; Mon, 20 Jan 2014 01:40:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 QHxaQ4QLu3PT for ; Mon, 20 Jan 2014 01:39: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 A1B241A00AC for ; Mon, 20 Jan 2014 01:39: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 E9E41240C2EA; Mon, 20 Jan 2014 10:39:58 +0100 (CET)
Date: Mon, 20 Jan 2014 10:39:58 +0100 (CET)
Message-Id: <20140120.103958.614685089350678258.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz>
References: <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <3B27B723-2E59-45C6-B679-0CF298D71525@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: eggert@cs.ucla.edu, lear@cisco.com, netmod@ietf.org, sm@resistor.net, michelle.cotton@icann.org
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 09:40:06 -0000

Ladislav Lhotka  wrote:
> 
> On 20 Jan 2014, at 10:04, Benoit Claise  wrote:
> 
> > Dear all,
> > 
> > Taking into account 
> > - that there is no canonical list of TZ time zone names (political
> > - reasons were mentioned)
> > - that the generate number solutions (from hash or coordinates) don't
> > - address the removal (and obsoleting) of zones.
> > - that I'm not too clear if IANA would support a program to generate
> > - this YANG module
> > - Lada's feedback: "The value is unused by YANG and the XML encoding,
> > - but is carried as a convenience to implementors.$B!I(B
> 
> In other words, I think the $B!H(Bvalue$B!I(B substatements can be safely
> removed from the enums, they seem to be more of a nuisance than
> convenience.

Whether the "value" statement is there or nor doesn't matter - if it
is not there explicitly, the enum gets an implict value, and this
value must not change on updates.

But in either case, I don't see the problem with the value.

> > I'm wondering if it doesn't make sense to:
> > - not ask IANA to maintain this YANG module (so removing the IANA
> > - considerations)
> 
> +1
> 
> > - express: "this document is generated from Time Zone Data v. 2013i
> > - (Released 2013-12-17) tzdata2013i.tar.gz (213.7kb)$B!I(B
> 
> +1
> 
> > - see how the situation evolves in the couple of years. 
> >     maybe wait for a canonical list of TZ names
> >     maybe update this YANG module with a new RFC in a couple of years if
> >     there are many entry additions/deletions
> 
> +1

But doesn't this effectively mean that we standardize a snapshot of
the (timezone names from the) TZ Database?  I assume that entries get
added or removed for some good reason, and we are saying that we
ignore that?

This also doesn't solve the issue of mismatch between the YANG module
and the underlying system, for installations on "open" systems.


/martin

From lhotka@nic.cz  Mon Jan 20 01:51:36 2014
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 5DD341A00BA for ; Mon, 20 Jan 2014 01:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level: 
X-Spam-Status: No, score=-0.886 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.535] 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 vU--kyEQlaA3 for ; Mon, 20 Jan 2014 01:51:34 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 998C91A00B3 for ; Mon, 20 Jan 2014 01:51:34 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8044F13F69F; Mon, 20 Jan 2014 10:51:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390211494; bh=r9e0NALDAv7rAbaw/wKvNGQpt+qPIXi22KG+liO+hfw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gn7zYiAY3mxQqR+E5BnPAeLf9TnjLCRKT9irIQAkE21VTlmw5I7mlN8dQL0xDfWLk wrVX/9Hy7w4y45hCkPjRtMPYF4nvX8a8c3tQYTqWpzjeQ9ypJZn5QNoAqs8bkDZufx Ld3/QzCLRgu7n5C1MmLl3XqpjHAMBj55+c3hXqMA=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140120093542.GB43960@elstar.local>
Date: Mon, 20 Jan 2014 10:51:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <25B1956B-37C2-43F2-B2BD-8BEF6D39B9E4@nic.cz>
References: <52D83C94.4070407@cs.ucla.edu> <52D8C867.30402@cisco.com> <52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz> <20140120093542.GB43960@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: Paul Eggert , Eliot Lear , netmod@ietf.org, SM , Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 09:51:36 -0000

On 20 Jan 2014, at 10:35, Juergen Schoenwaelder =
 wrote:

> On Mon, Jan 20, 2014 at 10:19:27AM +0100, Ladislav Lhotka wrote:
>>=20
>> On 20 Jan 2014, at 10:04, Benoit Claise  wrote:
>>=20
>>> Dear all,
>>>=20
>>> Taking into account=20
>>> - that there is no canonical list of TZ time zone names (political =
reasons were mentioned)
>>> - that the generate number solutions (from hash or coordinates) =
don't address the removal (and obsoleting) of zones.
>>> - that I'm not too clear if IANA would support a program to generate =
this YANG module
>>> - Lada's feedback: "The value is unused by YANG and the XML =
encoding, but is carried as a convenience to implementors.=94
>>=20
>> In other words, I think the =93value=94 substatements can be safely =
removed from the enums, they seem to be more of a nuisance than =
convenience.
>=20
> RFC 6020 section 9.6.4.2:
>=20
>   If a value is not specified, then one will be automatically =
assigned.
>   If the "enum" substatement is the first one defined, the assigned
>   value is zero (0); otherwise, the assigned value is one greater than
>   the current highest enum value.
>=20
> This essentially means any change of order will cause different
> numbers to be assigned. Lets not get into a debate whether this
> is a feature or but - it is just how Yang 1.0 is defined.

But it is the name that counts, and that is sent between the client and =
server (or vice versa).

If an implementation decides to map internally the Olson names to =
integers (which is IMO by no means necessary), it should be completely =
transparent to other parties. The numbers are no issue in terms of =
interoperability.

Lada

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

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





From bclaise@cisco.com  Mon Jan 20 01:54:14 2014
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 0B9E41A00B3 for ; Mon, 20 Jan 2014 01:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.036
X-Spam-Level: 
X-Spam-Status: No, score=-10.036 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.535, 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 0I8i54urPXVZ for ; Mon, 20 Jan 2014 01:54:11 -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 9447C1A00BA for ; Mon, 20 Jan 2014 01:54:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3097; q=dns/txt; s=iport; t=1390211652; x=1391421252; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=IvW5H6kI8ekC8ObIBnUGmv+xjYSDQ3t5ul5TNdDMk04=; b=OaCQvdCjWU0q36fO5JnmFeWQtOmQsm/I/H9B07g0JZto5SIKAs8GT444 UxVfOihxIgeA2F3vjbPKt8W6Me1aXBZ+RVrMek90UsiqEzwMdH4J8r2Ab m89HRDuIc4f1ZMhXzBTgXTj6iUrORSF8rtskU7TD4sf9VpNvEOkKv82Ny M=;
X-IronPort-AV: E=Sophos;i="4.95,689,1384300800";  d="scan'208";a="3213002"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 20 Jan 2014 09:54:11 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0K9sAjW025540; Mon, 20 Jan 2014 09:54:10 GMT
Message-ID: <52DCF242.2080201@cisco.com>
Date: Mon, 20 Jan 2014 10:54:10 +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 
References: <52D83C94.4070407@cs.ucla.edu>	<52D8C867.30402@cisco.com>	<52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz>
In-Reply-To: <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Eliot Lear , netmod@ietf.org, Paul Eggert , SM , Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 09:54:14 -0000

On 20/01/2014 10:19, Ladislav Lhotka wrote:
> On 20 Jan 2014, at 10:04, Benoit Claise  wrote:
>
>> Dear all,
>>
>> Taking into account
>> - that there is no canonical list of TZ time zone names (political reasons were mentioned)
>> - that the generate number solutions (from hash or coordinates) don't address the removal (and obsoleting) of zones.
>> - that I'm not too clear if IANA would support a program to generate this YANG module
>> - Lada's feedback: "The value is unused by YANG and the XML encoding, but is carried as a convenience to implementors.”
> In other words, I think the “value” substatements can be safely removed from the enums, they seem to be more of a nuisance than convenience.
I was simply thinking that, if there is a new YANG revision (posted 
after a couple of years) with a different set of values, then it doesn't 
matter to implementation.

Regards, Benoit.
>
>> I'm wondering if it doesn't make sense to:
>> - not ask IANA to maintain this YANG module (so removing the IANA considerations)
> +1
>
>> - express: "this document is generated from Time Zone Data v. 2013i (Released 2013-12-17) tzdata2013i.tar.gz (213.7kb)”
> +1
>
>> - see how the situation evolves in the couple of years.
>>      maybe wait for a canonical list of TZ names
>>      maybe update this YANG module with a new RFC in a couple of years if there are many entry additions/deletions
> +1
>
> Lada
>
>>      ...
>>
>> Note: without a quick resolution on this issue (max tomorrow morning), I will have to remove draft-ietf-netmod-system-mgmt from the telechat this Thursday.
>>
>> Regards, Benoit
>>> Martin Bjorklund wrote:
>>>
>>>> We want the YANG module to match what the underlying system is actually using, provided they support the         TZ Database available from IANA.
>>> OK, but the typical case is that if the underlying system supports the TZ database, it also supports POSIX TZ strings such as UTC0.  So if we want the YANG module to match what the underlying system is actually using ...
>>>
>>>> I think it is ok that the system actually would internally accept e.g. UTC0, even if it is not available         in the YANG module.
>>> ... then we might want to rethink this.
>>>
>>>> It is of course still trivial to write the program that takes as input the current YANG module and the new tzdata.tar.gz file and produces a new YANG module.  If this is what we want to do, I can write that program.  But the question is if this procedure is ok for IANA?
>>> That would require that the TZ coordinator maintain the YANG module.  I think it's better to have YANG-only stuff maintained by the YANG maintainers.  TZ database maintenance is a pain enough already, and its maintenance procedure won't scale to also maintaining YANG timezone data, CLDR timezone data, etc.
>>> .
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> .
>


From j.schoenwaelder@jacobs-university.de  Mon Jan 20 01:55:58 2014
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 6A6891A00BA for ; Mon, 20 Jan 2014 01:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 HPRFj0RTc158 for ; Mon, 20 Jan 2014 01:55: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 0F6B91A00B3 for ; Mon, 20 Jan 2014 01:55:57 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F41B20073; Mon, 20 Jan 2014 10:55:57 +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 7fTFV0y3SjrG; Mon, 20 Jan 2014 10:55:57 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B1DA2006E; Mon, 20 Jan 2014 10:55:56 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C81F92ABF560; Mon, 20 Jan 2014 10:55:53 +0100 (CET)
Date: Mon, 20 Jan 2014 10:55:53 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140120095553.GA44169@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Benoit Claise , Eliot Lear , netmod@ietf.org, Paul Eggert , SM , Michelle Cotton 
References: <52D83C94.4070407@cs.ucla.edu> <52D8C867.30402@cisco.com> <52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz> <20140120093542.GB43960@elstar.local> <25B1956B-37C2-43F2-B2BD-8BEF6D39B9E4@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <25B1956B-37C2-43F2-B2BD-8BEF6D39B9E4@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Paul Eggert , Eliot Lear , netmod@ietf.org, SM , Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 09:55:58 -0000

On Mon, Jan 20, 2014 at 10:51:32AM +0100, Ladislav Lhotka wrote:
> 
> > 
> > This essentially means any change of order will cause different
> > numbers to be assigned. Lets not get into a debate whether this
> > is a feature or but - it is just how Yang 1.0 is defined.
> 
> But it is the name that counts, and that is sent between the client and server (or vice versa).
> 
> If an implementation decides to map internally the Olson names to integers (which is IMO by no means necessary), it should be completely transparent to other parties. The numbers are no issue in terms of interoperability.
> 

As I said, I am quoting how Yang 1.0 is defined. Whether that is
useful or not is not the point of this discussion - we are not going
to change RFC 6020 in order to define the timezone-location leaf.

/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  Mon Jan 20 01:59:29 2014
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 B2BBE1A00C9 for ; Mon, 20 Jan 2014 01:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.036
X-Spam-Level: 
X-Spam-Status: No, score=-10.036 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.535, 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 2MZ7OYervrSk for ; Mon, 20 Jan 2014 01:59:28 -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 224981A00C7 for ; Mon, 20 Jan 2014 01:59:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2287; q=dns/txt; s=iport; t=1390211968; x=1391421568; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KhHgTOVB/00v8ECZrfsGv8x7AKPvlTvppTB6NgO9PEo=; b=kDZePzdQresLPA4/s456NjS/z2xcR3iNPgOLg8isf2FNpByaUf3Rp273 93syw8TWDKPoTpKf1vuhhS+H54fFzUL9Y+t/ait9wKnGfg/ojnGkKwUXe EV4x/aVfmyzo00n1kYPi6we3+AmdcE5koWGOEoxzPAKhTWGUx9Rj+0vTP Y=;
X-IronPort-AV: E=Sophos;i="4.95,689,1384300800";  d="scan'208";a="3882775"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 20 Jan 2014 09:59:27 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0K9xQ6o023578; Mon, 20 Jan 2014 09:59:26 GMT
Message-ID: <52DCF37E.6080500@cisco.com>
Date: Mon, 20 Jan 2014 10:59:26 +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 , lhotka@nic.cz
References: <52D9BF28.8070103@cs.ucla.edu>	<52DCE6AB.8050404@cisco.com>	<3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz> <20140120.103958.614685089350678258.mbj@tail-f.com>
In-Reply-To: <20140120.103958.614685089350678258.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: eggert@cs.ucla.edu, lear@cisco.com, netmod@ietf.org, "iana-questions@iana.org" , sm@resistor.net, michelle.cotton@icann.org
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 09:59:29 -0000

A question for IANA in line.
> Ladislav Lhotka  wrote:
>> On 20 Jan 2014, at 10:04, Benoit Claise  wrote:
>>
>>> Dear all,
>>>
>>> Taking into account 
>>> - that there is no canonical list of TZ time zone names (political
>>> - reasons were mentioned)
>>> - that the generate number solutions (from hash or coordinates) don't
>>> - address the removal (and obsoleting) of zones.
>>> - that I'm not too clear if IANA would support a program to generate
>>> - this YANG module
>>> - Lada's feedback: "The value is unused by YANG and the XML encoding,
>>> - but is carried as a convenience to implementors.$B!I(B
>> In other words, I think the $B!H(Bvalue$B!I(B substatements can be safely
>> removed from the enums, they seem to be more of a nuisance than
>> convenience.
> Whether the "value" statement is there or nor doesn't matter - if it
> is not there explicitly, the enum gets an implict value, and this
> value must not change on updates.
>
> But in either case, I don't see the problem with the value.
>
>>> I'm wondering if it doesn't make sense to:
>>> - not ask IANA to maintain this YANG module (so removing the IANA
>>> - considerations)
>> +1
>>
>>> - express: "this document is generated from Time Zone Data v. 2013i
>>> - (Released 2013-12-17) tzdata2013i.tar.gz (213.7kb)$B!I(B
>> +1
>>
>>> - see how the situation evolves in the couple of years. 
>>>     maybe wait for a canonical list of TZ names
>>>     maybe update this YANG module with a new RFC in a couple of years if
>>>     there are many entry additions/deletions
>> +1
> But doesn't this effectively mean that we standardize a snapshot of
> the (timezone names from the) TZ Database?  I assume that entries get
> added or removed for some good reason, and we are saying that we
> ignore that?

>
> This also doesn't solve the issue of mismatch between the YANG module
> and the underlying system, for installations on "open" systems.
Let me see if I get the situation right.
I understand that we can't do a perfect job (*), so should we do an OK job?

(*) except with a program that IANA would maintain, if I'm not mistaken.
Michelle, is this a viable solution for you?

Regards, Benoit
>
>
> /martin
> .
>


From lhotka@nic.cz  Mon Jan 20 02:18:52 2014
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 EFCA71A00BD for ; Mon, 20 Jan 2014 02:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level: 
X-Spam-Status: No, score=-0.886 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.535] 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 8E-5WXKvoP3z for ; Mon, 20 Jan 2014 02:18: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 801A01A009F for ; Mon, 20 Jan 2014 02:18:49 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 33F1B14014E; Mon, 20 Jan 2014 11:18:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390213129; bh=pC8iSCQnKaSu2R5xttZxBqIscyZTPy5OuEvtCoLf0fs=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FarRJT75YC89sviSaJY3A1CNpZ7Zfldm/rPruVLcZVpe27LtH6qQuqQ6+kLl4kvy4 KdR/7efq5PpRZ0WDGh5yoHh//Jh3IJI4EHnuO2Fgo9MeqVi6nrtqI4xvdwVhwC6dng yfBNUzacHR8hwvpH8nY89D2/TW00qc5oVB3/jxco=
Content-Type: text/plain; charset=iso-2022-jp
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140120.103958.614685089350678258.mbj@tail-f.com>
Date: Mon, 20 Jan 2014 11:18:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A7E8777-70E4-446F-954B-EB18A95882CA@nic.cz>
References: <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz> <20140120.103958.614685089350678258.mbj@tail-f.com>
To: =?iso-8859-1?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: Paul Eggert , Eliot Lear , netmod@ietf.org, SM , Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 10:18:52 -0000

On 20 Jan 2014, at 10:39, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>>=20
>> On 20 Jan 2014, at 10:04, Benoit Claise  wrote:
>>=20
>>> Dear all,
>>>=20
>>> Taking into account=20
>>> - that there is no canonical list of TZ time zone names (political
>>> - reasons were mentioned)
>>> - that the generate number solutions (from hash or coordinates) =
don't
>>> - address the removal (and obsoleting) of zones.
>>> - that I'm not too clear if IANA would support a program to generate
>>> - this YANG module
>>> - Lada's feedback: "The value is unused by YANG and the XML =
encoding,
>>> - but is carried as a convenience to implementors.=1B$B!I=1B(B
>>=20
>> In other words, I think the =1B$B!H=1B(Bvalue=1B$B!I=1B(B =
substatements can be safely
>> removed from the enums, they seem to be more of a nuisance than
>> convenience.
>=20
> Whether the "value" statement is there or nor doesn't matter - if it
> is not there explicitly, the enum gets an implict value, and this
> value must not change on updates.

Must not change - where? As far as I can tell, the value is completely =
local to each client or server. Will anything break if an implementation =
uses a different internal numbering, or no numbering at all?

>=20
> But in either case, I don't see the problem with the value.

I agree.

>=20
>>> I'm wondering if it doesn't make sense to:
>>> - not ask IANA to maintain this YANG module (so removing the IANA
>>> - considerations)
>>=20
>> +1
>>=20
>>> - express: "this document is generated from Time Zone Data v. 2013i
>>> - (Released 2013-12-17) tzdata2013i.tar.gz (213.7kb)=1B$B!I=1B(B
>>=20
>> +1
>>=20
>>> - see how the situation evolves in the couple of years.=20
>>>    maybe wait for a canonical list of TZ names
>>>    maybe update this YANG module with a new RFC in a couple of years =
if
>>>    there are many entry additions/deletions
>>=20
>> +1
>=20
> But doesn't this effectively mean that we standardize a snapshot of
> the (timezone names from the) TZ Database?  I assume that entries get
> added or removed for some good reason, and we are saying that we
> ignore that?

If a server advertizes a timezones module, the client knows exactly the =
available options. Even if it doesn=1B$B!G=1B(Bt reflect the most recent =
version of the database, the client should in most cases be able to =
configure the timezone properly. That is, the client may not be able to =
use =1B$B!H=1B(BEurope/Budweis=1B$B!I=1B(B, which is a shame, but =
=1B$B!H=1B(BEurope/Prague=1B$B!I=1B(B will work as well.=20

>=20
> This also doesn't solve the issue of mismatch between the YANG module
> and the underlying system, for installations on "open" systems.

The NETCONF server should correctly handle the advertised revision. If =
it doesn=1B$B!G=1B(Bt, it=1B$B!G=1B(Bs broken.

It is an illusion to assume that one can freely run =1B$B!H=1B(Bapt-get =
upgrade=1B$B!I=1B(B without checking the impact on the NETCONF =
subsystem. Other things can easily break, too, and the implementation =
must take care of it.

Lada

>=20
>=20
> /martin

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





From lhotka@nic.cz  Mon Jan 20 02:22:53 2014
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 8844E1A00E2 for ; Mon, 20 Jan 2014 02:22:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level: 
X-Spam-Status: No, score=-0.886 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.535] 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 c65HM6zOMJmL for ; Mon, 20 Jan 2014 02:22:52 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 07E741A00E1 for ; Mon, 20 Jan 2014 02:22:51 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 10A0514014E; Mon, 20 Jan 2014 11:22:50 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390213371; bh=6xNOEcjtQy/x5CljqDxvVyE5ggkWRm1UMd84i01qwpY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Z9kDZ/XaJZ2sOvQ+U57Bw2Yzf4hZBj8+8ZBpSoSSAwFgSehbPzZfBqaG5975yznxC P04Ra4N6IIeEFwd1mT3WonJB8yWE3zjcKozgMXn5xKQwAOxygbGW9s1WhoFzDZUMM+ PKFUo4aJt/jjId+5CQVZUap0ng4l/CBPGYKU79Ek=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140120095553.GA44169@elstar.local>
Date: Mon, 20 Jan 2014 11:22:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <52D83C94.4070407@cs.ucla.edu> <52D8C867.30402@cisco.com> <52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz> <20140120093542.GB43960@elstar.local> <25B1956B-37C2-43F2-B2BD-8BEF6D39B9E4@nic.cz> <20140120095553.GA44169@elstar.local>
To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: Paul Eggert , Eliot Lear , netmod@ietf.org, SM , Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 10:22:53 -0000

On 20 Jan 2014, at 10:55, Juergen Schoenwaelder =
 wrote:

> On Mon, Jan 20, 2014 at 10:51:32AM +0100, Ladislav Lhotka wrote:
>>=20
>>>=20
>>> This essentially means any change of order will cause different
>>> numbers to be assigned. Lets not get into a debate whether this
>>> is a feature or but - it is just how Yang 1.0 is defined.
>>=20
>> But it is the name that counts, and that is sent between the client =
and server (or vice versa).
>>=20
>> If an implementation decides to map internally the Olson names to =
integers (which is IMO by no means necessary), it should be completely =
transparent to other parties. The numbers are no issue in terms of =
interoperability.
>>=20
>=20
> As I said, I am quoting how Yang 1.0 is defined. Whether that is
> useful or not is not the point of this discussion - we are not going
> to change RFC 6020 in order to define the timezone-location leaf.

Nothing needs to be changed, the values just seem to be irrelevant from =
the interoperability point of view.
And they are optional in YANG.

Lada

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

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





From j.schoenwaelder@jacobs-university.de  Mon Jan 20 02:29:13 2014
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 796F31A00E2 for ; Mon, 20 Jan 2014 02:29:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 GecNxDLeITL0 for ; Mon, 20 Jan 2014 02:29: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 A67D71A00D6 for ; Mon, 20 Jan 2014 02:29:11 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B92EA20077; Mon, 20 Jan 2014 11:29:11 +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 gqZ94IK3vZEy; Mon, 20 Jan 2014 11:29:11 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B9F520075; Mon, 20 Jan 2014 11:29:11 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 75CDF2ABF777; Mon, 20 Jan 2014 11:29:08 +0100 (CET)
Date: Mon, 20 Jan 2014 11:29:08 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140120102907.GA44247@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Benoit Claise , Eliot Lear , netmod@ietf.org, Paul Eggert , SM , Michelle Cotton 
References: <52D8C867.30402@cisco.com> <52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz> <20140120093542.GB43960@elstar.local> <25B1956B-37C2-43F2-B2BD-8BEF6D39B9E4@nic.cz> <20140120095553.GA44169@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Paul Eggert , Eliot Lear , netmod@ietf.org, SM , Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 10:29:13 -0000

On Mon, Jan 20, 2014 at 11:22:50AM +0100, Ladislav Lhotka wrote:
> 
> On 20 Jan 2014, at 10:55, Juergen Schoenwaelder  wrote:
> 
> > On Mon, Jan 20, 2014 at 10:51:32AM +0100, Ladislav Lhotka wrote:
> >> 
> >>> 
> >>> This essentially means any change of order will cause different
> >>> numbers to be assigned. Lets not get into a debate whether this
> >>> is a feature or but - it is just how Yang 1.0 is defined.
> >> 
> >> But it is the name that counts, and that is sent between the client and server (or vice versa).
> >> 
> >> If an implementation decides to map internally the Olson names to integers (which is IMO by no means necessary), it should be completely transparent to other parties. The numbers are no issue in terms of interoperability.
> >> 
> > 
> > As I said, I am quoting how Yang 1.0 is defined. Whether that is
> > useful or not is not the point of this discussion - we are not going
> > to change RFC 6020 in order to define the timezone-location leaf.
> 
> Nothing needs to be changed, the values just seem to be irrelevant from the interoperability point of view.
> And they are optional in YANG.
> 

Yang 1.0 says (RFC 6020 section 10):

   o  An "enumeration" type may have new enums added, provided the old
      enums's values do not change.

/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 Jan 20 02:33:34 2014
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 298061A00E4 for ; Mon, 20 Jan 2014 02:33:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level: 
X-Spam-Status: No, score=-0.886 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.535] 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 SIBC6Wd9i7Nf for ; Mon, 20 Jan 2014 02:33:33 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D4DC61A00E2 for ; Mon, 20 Jan 2014 02:33:32 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 437A214014E; Mon, 20 Jan 2014 11:33:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390214012; bh=V13zD0CY4+4dFIXO+5hTcZjw+Kcmxwvu8LV+cZNCQa4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XB2pWLQNRFJJbfcTQoqNWhi6UTq6fHXJjr/kLe3ytSCLGO/rnaYuWDf+GlCajH94S XkEcS4EtGQgSaHwHPGMn+keuRNPKUV0KNVlUHS2c2TB+liY6X0GD1D5Baoh5ZhXc7m JaM9M48fJghXzb5J2hlnmbLCVhS50V2tTgesbuqA=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140120102907.GA44247@elstar.local>
Date: Mon, 20 Jan 2014 11:33:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <60AD7C8F-9D71-47FA-99CB-D3DCC9249C03@nic.cz>
References: <52D8C867.30402@cisco.com> <52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz> <20140120093542.GB43960@elstar.local> <25B1956B-37C2-43F2-B2BD-8BEF6D39B9E4@nic.cz> <20140120095553.GA44169@elstar.local>  <20140120102907.GA44247@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: Paul Eggert , Eliot Lear , netmod@ietf.org, SM , Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 10:33:34 -0000

On 20 Jan 2014, at 11:29, Juergen Schoenwaelder =
 wrote:

> On Mon, Jan 20, 2014 at 11:22:50AM +0100, Ladislav Lhotka wrote:
>>=20
>> On 20 Jan 2014, at 10:55, Juergen Schoenwaelder =
 wrote:
>>=20
>>> On Mon, Jan 20, 2014 at 10:51:32AM +0100, Ladislav Lhotka wrote:
>>>>=20
>>>>>=20
>>>>> This essentially means any change of order will cause different
>>>>> numbers to be assigned. Lets not get into a debate whether this
>>>>> is a feature or but - it is just how Yang 1.0 is defined.
>>>>=20
>>>> But it is the name that counts, and that is sent between the client =
and server (or vice versa).
>>>>=20
>>>> If an implementation decides to map internally the Olson names to =
integers (which is IMO by no means necessary), it should be completely =
transparent to other parties. The numbers are no issue in terms of =
interoperability.
>>>>=20
>>>=20
>>> As I said, I am quoting how Yang 1.0 is defined. Whether that is
>>> useful or not is not the point of this discussion - we are not going
>>> to change RFC 6020 in order to define the timezone-location leaf.
>>=20
>> Nothing needs to be changed, the values just seem to be irrelevant =
from the interoperability point of view.
>> And they are optional in YANG.
>>=20
>=20
> Yang 1.0 says (RFC 6020 section 10):
>=20
>   o  An "enumeration" type may have new enums added, provided the old
>      enums's values do not change.

Right, so if no enum=92s values are present, they cannot change.=20

Lada

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

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





From j.schoenwaelder@jacobs-university.de  Mon Jan 20 02:34:49 2014
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 2025E1A00EB; Mon, 20 Jan 2014 02:34:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 uZdPTV8lbCC4; Mon, 20 Jan 2014 02:34: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 87E931A00EA; Mon, 20 Jan 2014 02:34:47 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BBF420071; Mon, 20 Jan 2014 11:34:47 +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 fRxbS4s_fFJM; Mon, 20 Jan 2014 11:34:47 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3207D20026; Mon, 20 Jan 2014 11:34:47 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 44A832ABF8A4; Mon, 20 Jan 2014 11:34:45 +0100 (CET)
Date: Mon, 20 Jan 2014 11:34:45 +0100
From: Juergen Schoenwaelder 
To: SM 
Message-ID: <20140120103445.GA44289@elstar.local>
Mail-Followup-To: SM , Benoit Claise , ietf@ietf.org, netmod@ietf.org
References: <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com> <6.2.5.6.2.20131203182446.06c04fa8@resistor.net> <52A1ACEF.6080307@cisco.com> <52CD7EBD.4090506@cisco.com>  <6.2.5.6.2.20140108233958.0a849e58@resistor.net> <20140109105804.GA44893@elstar.local> <6.2.5.6.2.20140109051548.0a951040@resistor.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6.2.5.6.2.20140109051548.0a951040@resistor.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: ietf@ietf.org, netmod@ietf.org
Subject: Re: [netmod] Fwd: Re: Last Call: 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Jan 2014 10:34:49 -0000

On Thu, Jan 09, 2014 at 07:47:46AM -0800, SM wrote:
 
> >There was concensus in the WG that it is desirable to configure
> >timezones by name (e.g., Europe/Paris) instead of having only hard
> >coded UTC offsets - the benefits should be obvious.
> 
> I agree that there can be benefits to that approach.  I could not
> find the (mailing list) message where that WG decision was taken.

SM,

there are no specific concensus calls for every leaf since this won't
scale. I do not recall having seen any issues raised on using timezone
names during the WG last calls. The timezone configuration using
timezone names has been in this document since its very beginning,
even before WG adoption, see draft-bierman-netmod-system-mgmt-00 (June
2, 2011).

/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 Jan 20 03:11:32 2014
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 954FF1A011B for ; Mon, 20 Jan 2014 03:11:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 5hIR6fTYjEAM for ; Mon, 20 Jan 2014 03:11:30 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDFD1A0118 for ; Mon, 20 Jan 2014 03:11:30 -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 7D804240C30A; Mon, 20 Jan 2014 12:11:29 +0100 (CET)
Date: Mon, 20 Jan 2014 12:11:29 +0100 (CET)
Message-Id: <20140120.121129.2146025393437714538.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <60AD7C8F-9D71-47FA-99CB-D3DCC9249C03@nic.cz>
References:  <20140120102907.GA44247@elstar.local> <60AD7C8F-9D71-47FA-99CB-D3DCC9249C03@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-8859-7
Content-Transfer-Encoding: base64
Cc: eggert@cs.ucla.edu, lear@cisco.com, netmod@ietf.org, sm@resistor.net, michelle.cotton@icann.org
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 11:11:32 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDIwIEphbiAy
MDE0LCBhdCAxMToyOSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFj
b2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiANCj4gPiBPbiBNb24sIEphbiAyMCwgMjAxNCBh
dCAxMToyMjo1MEFNICswMTAwLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4+IA0KPiA+PiBP
biAyMCBKYW4gMjAxNCwgYXQgMTA6NTUsIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53
YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gPj4gDQo+ID4+PiBPbiBNb24s
IEphbiAyMCwgMjAxNCBhdCAxMDo1MTozMkFNICswMTAwLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6
DQo+ID4+Pj4gDQo+ID4+Pj4+IA0KPiA+Pj4+PiBUaGlzIGVzc2VudGlhbGx5IG1lYW5zIGFueSBj
aGFuZ2Ugb2Ygb3JkZXIgd2lsbCBjYXVzZSBkaWZmZXJlbnQNCj4gPj4+Pj4gbnVtYmVycyB0byBi
ZSBhc3NpZ25lZC4gTGV0cyBub3QgZ2V0IGludG8gYSBkZWJhdGUgd2hldGhlciB0aGlzDQo+ID4+
Pj4+IGlzIGEgZmVhdHVyZSBvciBidXQgLSBpdCBpcyBqdXN0IGhvdyBZYW5nIDEuMCBpcyBkZWZp
bmVkLg0KPiA+Pj4+IA0KPiA+Pj4+IEJ1dCBpdCBpcyB0aGUgbmFtZSB0aGF0IGNvdW50cywgYW5k
IHRoYXQgaXMgc2VudCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHNlcnZlciAob3IgdmljZSB2ZXJz
YSkuDQo+ID4+Pj4gDQo+ID4+Pj4gSWYgYW4gaW1wbGVtZW50YXRpb24gZGVjaWRlcyB0byBtYXAg
aW50ZXJuYWxseSB0aGUgT2xzb24gbmFtZXMgdG8gaW50ZWdlcnMgKHdoaWNoIGlzIElNTyBieSBu
byBtZWFucyBuZWNlc3NhcnkpLCBpdCBzaG91bGQgYmUgY29tcGxldGVseSB0cmFuc3BhcmVudCB0
byBvdGhlciBwYXJ0aWVzLiBUaGUgbnVtYmVycyBhcmUgbm8gaXNzdWUgaW4gdGVybXMgb2YgaW50
ZXJvcGVyYWJpbGl0eS4NCj4gPj4+PiANCj4gPj4+IA0KPiA+Pj4gQXMgSSBzYWlkLCBJIGFtIHF1
b3RpbmcgaG93IFlhbmcgMS4wIGlzIGRlZmluZWQuIFdoZXRoZXIgdGhhdCBpcw0KPiA+Pj4gdXNl
ZnVsIG9yIG5vdCBpcyBub3QgdGhlIHBvaW50IG9mIHRoaXMgZGlzY3Vzc2lvbiAtIHdlIGFyZSBu
b3QgZ29pbmcNCj4gPj4+IHRvIGNoYW5nZSBSRkMgNjAyMCBpbiBvcmRlciB0byBkZWZpbmUgdGhl
IHRpbWV6b25lLWxvY2F0aW9uIGxlYWYuDQo+ID4+IA0KPiA+PiBOb3RoaW5nIG5lZWRzIHRvIGJl
IGNoYW5nZWQsIHRoZSB2YWx1ZXMganVzdCBzZWVtIHRvIGJlIGlycmVsZXZhbnQgZnJvbSB0aGUg
aW50ZXJvcGVyYWJpbGl0eSBwb2ludCBvZiB2aWV3Lg0KPiA+PiBBbmQgdGhleSBhcmUgb3B0aW9u
YWwgaW4gWUFORy4NCj4gPj4gDQo+ID4gDQo+ID4gWWFuZyAxLjAgc2F5cyAoUkZDIDYwMjAgc2Vj
dGlvbiAxMCk6DQo+ID4gDQo+ID4gICBvICBBbiAiZW51bWVyYXRpb24iIHR5cGUgbWF5IGhhdmUg
bmV3IGVudW1zIGFkZGVkLCBwcm92aWRlZCB0aGUgb2xkDQo+ID4gICAgICBlbnVtcydzIHZhbHVl
cyBkbyBub3QgY2hhbmdlLg0KPiANCj4gUmlnaHQsIHNvIGlmIG5vIGVudW2icyB2YWx1ZXMgYXJl
IHByZXNlbnQsIHRoZXkgY2Fubm90IGNoYW5nZS4gDQoNCkZyb20gNjAyMDoNCg0KICAgVGhlICJ2
YWx1ZSIgc3RhdGVtZW50LCB3aGljaCBpcyBvcHRpb25hbCwgaXMgdXNlZCB0byBhc3NvY2lhdGUg
YW4NCiAgIGludGVnZXIgdmFsdWUgd2l0aCB0aGUgYXNzaWduZWQgbmFtZSBmb3IgdGhlIGVudW0u
DQoNCiAgIFsuLi5dDQoNCiAgIElmIGEgdmFsdWUgaXMgbm90IHNwZWNpZmllZCwgdGhlbiBvbmUg
d2lsbCBiZSBhdXRvbWF0aWNhbGx5IGFzc2lnbmVkLg0KDQpJLmUuLCBldmVyeSBlbnVtICphbHdh
eXMqIGhhcyBhIHZhbHVlLiAgVGhpcyB2YWx1ZSBtdXN0IG5vdCBjaGFuZ2UNCmR1cmluZyB1cGdy
YWRlLg0KDQoNCi9tYXJ0aW4NCg==

From internet-drafts@ietf.org  Mon Jan 20 04:06:51 2014
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 3F21C1A012E; Mon, 20 Jan 2014 04:06:51 -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 yR2nEK2R6jw8; Mon, 20 Jan 2014 04:06:49 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D381A0113; Mon, 20 Jan 2014 04:06:49 -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.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140120120649.30508.62952.idtracker@ietfa.amsl.com>
Date: Mon, 20 Jan 2014 04:06:49 -0800
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-11.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, 20 Jan 2014 12:06:51 -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-11.txt
	Pages           : 39
	Date            : 2014-01-20

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-11

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


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 lhotka@nic.cz  Mon Jan 20 04:45:15 2014
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 4374A1A0131 for ; Mon, 20 Jan 2014 04:45:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level: 
X-Spam-Status: No, score=-0.886 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.535] 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 4MPO8DAUkSbA for ; Mon, 20 Jan 2014 04:45:13 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CF4EF1A0130 for ; Mon, 20 Jan 2014 04:45:12 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4097614014E; Mon, 20 Jan 2014 13:45:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390221911; bh=UydzBXIWJYAHJj3EIP5Oz3NAhq6fJ9DVfmjHcVNla0s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lXAplX8k+43C2uYLa7GguEKHA2t+woOj7yAcktWaRiI5JaEbtKhXVv7yYs4IGuJmH rKxub2RRDI5waLGNC/wDzHeg3v9CoxXmE+hFQQK2lDrAJ9hHUkl3/evW4sSIYfpPAY C5MX18heHwvk9ItqxYM9WDRbNC4YLizKiAbZWmns=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <60AD7C8F-9D71-47FA-99CB-D3DCC9249C03@nic.cz>
Date: Mon, 20 Jan 2014 13:45:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F6F97CF-A101-494A-BE23-95289CD26D48@nic.cz>
References: <52D8C867.30402@cisco.com> <52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz> <20140120093542.GB43960@elstar.local> <25B1956B-37C2-43F2-B2BD-8BEF6D39B9E4@nic.cz> <20140120095553.GA44169@elstar.local>  <20140120102907.GA44247@elstar.local> <60AD7C8F-9D71-47FA-99CB-D3DCC9249C03@nic.cz>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: SM , Paul Eggert , Michelle Cotton , netmod@ietf.org, Eliot Lear 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 12:45:15 -0000

On 20 Jan 2014, at 11:33, Ladislav Lhotka  wrote:

>=20
> On 20 Jan 2014, at 11:29, Juergen Schoenwaelder =
 wrote:
>=20
>> On Mon, Jan 20, 2014 at 11:22:50AM +0100, Ladislav Lhotka wrote:
>>>=20
>>> On 20 Jan 2014, at 10:55, Juergen Schoenwaelder =
 wrote:
>>>=20
>>>> On Mon, Jan 20, 2014 at 10:51:32AM +0100, Ladislav Lhotka wrote:
>>>>>=20
>>>>>>=20
>>>>>> This essentially means any change of order will cause different
>>>>>> numbers to be assigned. Lets not get into a debate whether this
>>>>>> is a feature or but - it is just how Yang 1.0 is defined.
>>>>>=20
>>>>> But it is the name that counts, and that is sent between the =
client and server (or vice versa).
>>>>>=20
>>>>> If an implementation decides to map internally the Olson names to =
integers (which is IMO by no means necessary), it should be completely =
transparent to other parties. The numbers are no issue in terms of =
interoperability.
>>>>>=20
>>>>=20
>>>> As I said, I am quoting how Yang 1.0 is defined. Whether that is
>>>> useful or not is not the point of this discussion - we are not =
going
>>>> to change RFC 6020 in order to define the timezone-location leaf.
>>>=20
>>> Nothing needs to be changed, the values just seem to be irrelevant =
from the interoperability point of view.
>>> And they are optional in YANG.
>>>=20
>>=20
>> Yang 1.0 says (RFC 6020 section 10):
>>=20
>>  o  An "enumeration" type may have new enums added, provided the old
>>     enums's values do not change.
>=20
> Right, so if no enum=92s values are present, they cannot change.

Oh, I see, the misunderstanding is due to the vague formulation in sec. =
9.6.4.2:

"If a value is not specified, then one will be automatically assigned.=94

My interpretation is, because =93The value is unused by YANG and [only] =
a convenience to implementors=94, that it is an implementor that assigns =
the missing values.

Your and Martin=92s interpretation seems to be =93If a value is not =
specified, the enum entry must be treated as if a value of X was defined =
for it.=94 Then the constraint you cited from sec. 10 of course means =
that the value *is* used by YANG!

Lada

> =20
>=20
> Lada
>=20
>>=20
>> /js
>>=20
>> --=20
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>> Fax:   +49 421 200 3103         
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From eggert@cs.ucla.edu  Mon Jan 20 08:42:14 2014
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 6A6831A01C1 for ; Mon, 20 Jan 2014 08:42:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.736
X-Spam-Level: 
X-Spam-Status: No, score=-4.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 zpAPR7r4lbSi for ; Mon, 20 Jan 2014 08:42:13 -0800 (PST)
Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2921A01BE for ; Mon, 20 Jan 2014 08:42:13 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id EE3E639E8014; Mon, 20 Jan 2014 08:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu
Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqH0Dn-5s6c7; Mon, 20 Jan 2014 08:42:11 -0800 (PST)
Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id BA1DE39E8011; Mon, 20 Jan 2014 08:42:10 -0800 (PST)
Message-ID: <52DD51E2.1090305@cs.ucla.edu>
Date: Mon, 20 Jan 2014 08:42:10 -0800
From: Paul Eggert 
Organization: UCLA Computer Science Department
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Benoit Claise , Martin Bjorklund 
References: <52D83C94.4070407@cs.ucla.edu>	<52D8C867.30402@cisco.com>	<52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com>
In-Reply-To: <52DCE6AB.8050404@cisco.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: lear@cisco.com, netmod@ietf.org, sm@resistor.net, Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 16:42:14 -0000

Benoit Claise wrote:
> - express: "this document is generated from *Time Zone Data v. 2013i*
> (Released 2013-12-17) tzdata2013i.tar.gz
> 
> (213.7kb)"

If this option is taken (and I'm not saying it's a good idea), it should 
state the generation method, and state that this isn't all the names 
supported by the TZ code and data.  Something like this, say:

"The time zone names of this document were taken from the third column 
of the TZ data's zone.tab file, in the same order as the zone.tab file. 
This is a proper subset of the time zone names supported by the TZ code 
and data."

If the generation method is changed to be something along the lines that 
Eliot Lear suggested, then the above text should be changed to match.

Also, it would be helpful to state what should or will happen with 
future releases of the tz data, particularly if the enum values must be 
stable, since the above method does not generate stable enums.

From andy@yumaworks.com  Mon Jan 20 09:17:43 2014
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 AFDA11A01E1 for ; Mon, 20 Jan 2014 09:17:43 -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 m8xofIgwBLRi for ; Mon, 20 Jan 2014 09:17:41 -0800 (PST)
Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0C21A01E0 for ; Mon, 20 Jan 2014 09:17:41 -0800 (PST)
Received: by mail-qc0-f182.google.com with SMTP id c9so6203648qcz.27 for ; Mon, 20 Jan 2014 09:17:41 -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=wTJwT6DGGvAHfS93HVFR7ZAhRXemNJspdvSZxgCkgx0=; b=YnB5vpcE3bDJCM1NaIXATHOe9LwwdLEU5uLEjblwU/JMAJFROP4MrfVG8xsQHBB/RK MgBBEU+1rmie+E2GMvmuSC0GBcq0xdwMRkw2MbFRxwCfHGBxAWdjI+02kb6n5Z/Tcmo1 6+2VQk1vfRpuMnFrjiVKDdH1Ekiz278d7swxmxKLpuoj8hjUJNTV+dmJHUU6lmtNqUfp 55bmiWIB40t1BgBmoc7WU5toTLsENw3DsWsAANywzhgsvJKwjYYmsSL4cnWPdZ8U4FKg s78jND8FxtYef57XO1aSsFqKICIhNo6eO1V/ESmuYC5WZMzR9X7epfdvoNerDgEiKGZQ Jsfw==
X-Gm-Message-State: ALoCoQnST4EpVi2//ZmalTUcJ3qmzlC9lKCIJRO6HKeGxbPkrP9g9rCLfS9N7K/ed16uGfQ4Kcku
MIME-Version: 1.0
X-Received: by 10.140.36.107 with SMTP id o98mr28105604qgo.25.1390238261074; Mon, 20 Jan 2014 09:17:41 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Mon, 20 Jan 2014 09:17:40 -0800 (PST)
In-Reply-To: <52DD51E2.1090305@cs.ucla.edu>
References: <52D83C94.4070407@cs.ucla.edu> <52D8C867.30402@cisco.com> <52D8D9D4.50902@cs.ucla.edu> <20140117.110413.518038697080561533.mbj@tail-f.com> <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <52DD51E2.1090305@cs.ucla.edu>
Date: Mon, 20 Jan 2014 09:17:40 -0800
Message-ID: 
From: Andy Bierman 
To: Paul Eggert 
Content-Type: multipart/alternative; boundary=001a11c154b6b4c4da04f06a1158
Cc: Eliot Lear , "netmod@ietf.org" , SM , Michelle Cotton 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 20 Jan 2014 17:17:43 -0000

--001a11c154b6b4c4da04f06a1158
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 20, 2014 at 8:42 AM, Paul Eggert  wrote:

> Benoit Claise wrote:
>
>> - express: "this document is generated from *Time Zone Data v. 2013i*
>> (Released 2013-12-17) tzdata2013i.tar.gz
>> 
>> (213.7kb)"
>>
>
> If this option is taken (and I'm not saying it's a good idea), it should
> state the generation method, and state that this isn't all the names
> supported by the TZ code and data.  Something like this, say:
>
> "The time zone names of this document were taken from the third column of
> the TZ data's zone.tab file, in the same order as the zone.tab file. This
> is a proper subset of the time zone names supported by the TZ code and
> data."
>
> If the generation method is changed to be something along the lines that
> Eliot Lear suggested, then the above text should be changed to match.
>
> Also, it would be helpful to state what should or will happen with future
> releases of the tz data, particularly if the enum values must be stable,
> since the above method does not generate stable enums.
>


I don't see how a snapshot helps.  That seems to just ignore the problem
of YANG enums out of synch with the operating system. I was surprised that
the TZ database changes as often as 3 times a year.  YANG enumerations
are best suited for static classification.


Andy

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





On Mon, Jan 20, 2014 at 8:42 AM, Paul Eggert <=
eggert@cs.ucla.edu<=
/a>> wrote:


Benoit Claise wrote:



- express: "this document is generated from *Time Zone Data v. 2013i*<=
br>
(Released 2013-12-17) tzdata2013i.tar.gz

<http://www.iana.org/time-zones/reposito=
ry/releases/tzdata2013i.tar.gz>

(213.7kb)"





If this option is taken (and I'm not saying it's a good idea), it s=
hould state the generation method, and state that this isn't all the na=
mes supported by the TZ code and data. =A0Something like this, say:



"The time zone names of this document were taken from the third column=
 of the TZ data's zone.tab file, in the same order as the zone.tab file=
. This is a proper subset of the time zone names supported by the TZ code a=
nd data."




If the generation method is changed to be something along the lines that El=
iot Lear suggested, then the above text should be changed to match.



Also, it would be helpful to state what should or will happen with future r=
eleases of the tz data, particularly if the enum values must be stable, sin=
ce the above method does not generate stable enums.

=A0

I don't see how a s=
napshot helps. =A0That seems to just ignore the problem
of YANG enums out of synch with the operating system. I was su=
rprised that


the TZ database changes as often as 3 times a ye=
ar. =A0YANG enumerations
are best suited fo=
r static classification.



Andy


--001a11c154b6b4c4da04f06a1158--

From lhotka@nic.cz  Tue Jan 21 00:36:36 2014
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 13B221A006B for ; Tue, 21 Jan 2014 00:36:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.713
X-Spam-Level: 
X-Spam-Status: No, score=0.713 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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.535] 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 wqevmjq54Y8o for ; Tue, 21 Jan 2014 00:36:34 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5072B1A0068 for ; Tue, 21 Jan 2014 00:36:34 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C232A13F8B2 for ; Tue, 21 Jan 2014 09:36:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390293393; bh=LdWb+exz21+wzmO2U2UOlp822jLX2ciuy5xkFVPox+o=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Message-Id: Date:To:Mime-Version; b=ct6O7tu26+sp80HGznw+qNP93yP8DQ+D8w+dQ73tPzkKTv4MIX6rJxY419UAmoqBU OB54qSmZqsmsShujr56d8GXyg18hDHj/SPqrEpQM5HxpXTUBz09OcdSMAN76aqtjFi 2uv+k3ITcoDC/gARgXR8X6IsotB3iw9dgiNEi6bM=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz>
Date: Tue, 21 Jan 2014 09:36:32 +0100
To: netmod@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Subject: [netmod] enumeration 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: Tue, 21 Jan 2014 08:36:36 -0000

Hi,

the definition of the enumeration type (sec. 9.6.4.2) contains another =
formulation that confuses me:

   If a value is not specified, then one will be automatically assigned.
   If the "enum" substatement is the first one defined, the assigned
   value is zero (0); otherwise, the assigned value is one greater than
   the current highest enum value.

So, for the example in 9.6.5

     leaf myenum {
         type enumeration {
             enum zero;
             enum one;
             enum seven {
                 value 7;
             }
         }
     }

the assignment should be

zero -> 0
one -> 8
seven -> 7

Is this correct?

Lada

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





From j.schoenwaelder@jacobs-university.de  Tue Jan 21 01:11:06 2014
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 5AD731A0096 for ; Tue, 21 Jan 2014 01:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 pGgA3m84mk6A for ; Tue, 21 Jan 2014 01:10:59 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A22F81A0087 for ; Tue, 21 Jan 2014 01:10:58 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 143262007B; Tue, 21 Jan 2014 10:10:58 +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 YKEerelKHISe; Tue, 21 Jan 2014 10:10:57 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE94420038; Tue, 21 Jan 2014 10:10:56 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 02A892AC24D4; Tue, 21 Jan 2014 10:10:53 +0100 (CET)
Date: Tue, 21 Jan 2014 10:10:52 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140121091052.GA47088@elstar.local>
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration type
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, 21 Jan 2014 09:11:06 -0000

On Tue, Jan 21, 2014 at 09:36:32AM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> the definition of the enumeration type (sec. 9.6.4.2) contains another formulation that confuses me:
> 
>    If a value is not specified, then one will be automatically assigned.
>    If the "enum" substatement is the first one defined, the assigned
>    value is zero (0); otherwise, the assigned value is one greater than
>    the current highest enum value.
> 
> So, for the example in 9.6.5
> 
>      leaf myenum {
>          type enumeration {
>              enum zero;
>              enum one;
>              enum seven {
>                  value 7;
>              }
>          }
>      }
> 
> the assignment should be
> 
> zero -> 0
> one -> 8
> seven -> 7
> 
> Is this correct?

Current in the order of definition, that is:

  zero -> 0
  one -> 1
  seven -> 7

/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  Tue Jan 21 01:18:43 2014
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 0294B1A02C2 for ; Tue, 21 Jan 2014 01:18:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level: 
X-Spam-Status: No, score=-0.886 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.535] 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 9gYoyVwrUbLw for ; Tue, 21 Jan 2014 01:18: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 6A7C31A00A9 for ; Tue, 21 Jan 2014 01:18:40 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 289ED13F8B2; Tue, 21 Jan 2014 10:18:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390295920; bh=/wMC8zJaNFZPlv7vwTkvdotKqtt1Cu4Wz56uJGlKFn4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eoDaaNJhppXuUoICIXFYcY33cQnlC1DCNhN4t+XVlSDalUeGfbA/HzwCAmSgMtNlS fuEULuKJUNWtIrCe7V1qYbuD6qFx/tOO93Imm6WDbtLVriCScHMDMOrEfVC/AhMZ2h rNJwEqT9Ptd8BezHB0mZA9LUQhtxltYDF2q7zbHU=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140121091052.GA47088@elstar.local>
Date: Tue, 21 Jan 2014 10:18:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local>
To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= 
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] enumeration 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: Tue, 21 Jan 2014 09:18:43 -0000

On 21 Jan 2014, at 10:10, Juergen Schoenwaelder =
 wrote:

> On Tue, Jan 21, 2014 at 09:36:32AM +0100, Ladislav Lhotka wrote:
>> Hi,
>>=20
>> the definition of the enumeration type (sec. 9.6.4.2) contains =
another formulation that confuses me:
>>=20
>>   If a value is not specified, then one will be automatically =
assigned.
>>   If the "enum" substatement is the first one defined, the assigned
>>   value is zero (0); otherwise, the assigned value is one greater =
than
>>   the current highest enum value.
>>=20
>> So, for the example in 9.6.5
>>=20
>>     leaf myenum {
>>         type enumeration {
>>             enum zero;
>>             enum one;
>>             enum seven {
>>                 value 7;
>>             }
>>         }
>>     }
>>=20
>> the assignment should be
>>=20
>> zero -> 0
>> one -> 8
>> seven -> 7
>>=20
>> Is this correct?
>=20
> Current in the order of definition, that is:
>=20
>  zero -> 0
>  one -> 1
>  seven -> 7

And what if that value is already taken by a subsequent enum entry? That =
is,

    leaf myenum {
        type enumeration {
            enum zero;
            enum one;
            enum seven {
                value 1;
            }
        }
    }

Lada

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

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





From jernej.tuljak@mg-soft.si  Tue Jan 21 01:23:58 2014
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 6074A1A00A1 for ; Tue, 21 Jan 2014 01:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 pvw5kPH7T6hq for ; Tue, 21 Jan 2014 01:23:55 -0800 (PST)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2971A0090 for ; Tue, 21 Jan 2014 01:23:55 -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 s0L9NsZ3005565; Tue, 21 Jan 2014 10:23:54 +0100
Message-ID: <52DE3CA6.7030308@mg-soft.com>
Date: Tue, 21 Jan 2014 10:23: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: Ladislav Lhotka 
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Tue, 21 Jan 2014 09:23:58 -0000

Dne 21.1.2014 10:18, piše Ladislav Lhotka:
> On 21 Jan 2014, at 10:10, Juergen Schoenwaelder  wrote:
>
>> On Tue, Jan 21, 2014 at 09:36:32AM +0100, Ladislav Lhotka wrote:
>>> Hi,
>>>
>>> the definition of the enumeration type (sec. 9.6.4.2) contains another formulation that confuses me:
>>>
>>>    If a value is not specified, then one will be automatically assigned.
>>>    If the "enum" substatement is the first one defined, the assigned
>>>    value is zero (0); otherwise, the assigned value is one greater than
>>>    the current highest enum value.
>>>
>>> So, for the example in 9.6.5
>>>
>>>      leaf myenum {
>>>          type enumeration {
>>>              enum zero;
>>>              enum one;
>>>              enum seven {
>>>                  value 7;
>>>              }
>>>          }
>>>      }
>>>
>>> the assignment should be
>>>
>>> zero -> 0
>>> one -> 8
>>> seven -> 7
>>>
>>> Is this correct?
>> Current in the order of definition, that is:
>>
>>   zero -> 0
>>   one -> 1
>>   seven -> 7
> And what if that value is already taken by a subsequent enum entry? That is,
>
>      leaf myenum {
>          type enumeration {
>              enum zero;
>              enum one;
>              enum seven {
>                  value 1;
>              }
>          }
>      }

It counts as double assignment of a single value and is an error. That's 
what our implementation does anyways.

Jernej

> Lada
>
>> /js
>>
>> -- 
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>> Fax:   +49 421 200 3103         
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From j.schoenwaelder@jacobs-university.de  Tue Jan 21 01:29:55 2014
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 26B811A00A1 for ; Tue, 21 Jan 2014 01:29:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 AyKiwWmy4fNW for ; Tue, 21 Jan 2014 01:29: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 9C9EE1A0102 for ; Tue, 21 Jan 2014 01:29:52 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DF2620069; Tue, 21 Jan 2014 10:29:52 +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 zy-IN9au-H47; Tue, 21 Jan 2014 10:29:52 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC4E220065; Tue, 21 Jan 2014 10:29:51 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 277A42AC2596; Tue, 21 Jan 2014 10:29:49 +0100 (CET)
Date: Tue, 21 Jan 2014 10:29:48 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140121092948.GA47210@elstar.local>
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration type
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, 21 Jan 2014 09:29:55 -0000

On Tue, Jan 21, 2014 at 10:18:39AM +0100, Ladislav Lhotka wrote:
> 
> On 21 Jan 2014, at 10:10, Juergen Schoenwaelder  wrote:
> 
> > On Tue, Jan 21, 2014 at 09:36:32AM +0100, Ladislav Lhotka wrote:
> >> Hi,
> >> 
> >> the definition of the enumeration type (sec. 9.6.4.2) contains another formulation that confuses me:
> >> 
> >>   If a value is not specified, then one will be automatically assigned.
> >>   If the "enum" substatement is the first one defined, the assigned
> >>   value is zero (0); otherwise, the assigned value is one greater than
> >>   the current highest enum value.
> >> 
> >> So, for the example in 9.6.5
> >> 
> >>     leaf myenum {
> >>         type enumeration {
> >>             enum zero;
> >>             enum one;
> >>             enum seven {
> >>                 value 7;
> >>             }
> >>         }
> >>     }
> >> 
> >> the assignment should be
> >> 
> >> zero -> 0
> >> one -> 8
> >> seven -> 7
> >> 
> >> Is this correct?
> > 
> > Current in the order of definition, that is:
> > 
> >  zero -> 0
> >  one -> 1
> >  seven -> 7
> 
> And what if that value is already taken by a subsequent enum entry? That is,
> 
>     leaf myenum {
>         type enumeration {
>             enum zero;
>             enum one;
>             enum seven {
>                 value 1;
>             }
>         }
>     }
> 

I assume this is the same as this and lead to the same result (namely
that the YANG definition is violating a MUST in section 9.6.4.2).

     leaf myenum {
         type enumeration {
             enum zero { value 0; };
             enum one { value 1; };
             enum seven {
                 value 1;
             }
         }
     }

Yes, one can question this automatic value assignment feature -
perhaps it would have been better to allow enumerations without
assigned numeric values. Perhaps something to consider should we ever
revise the YANG specification.

Martin, do you maintain a list of such issues?

/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 Jan 21 01:38:32 2014
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 0BC511A00AA for ; Tue, 21 Jan 2014 01:38:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 FiPT5k5xSCte for ; Tue, 21 Jan 2014 01:38:30 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7801A02D3 for ; Tue, 21 Jan 2014 01:38:30 -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 78D69240C410; Tue, 21 Jan 2014 10:38:29 +0100 (CET)
Date: Tue, 21 Jan 2014 10:38:29 +0100 (CET)
Message-Id: <20140121.103829.9237619675806241.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20140121092948.GA47210@elstar.local>
References: <20140121091052.GA47088@elstar.local>  <20140121092948.GA47210@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] enumeration 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: Tue, 21 Jan 2014 09:38:32 -0000

Juergen Schoenwaelder  wrote:
> On Tue, Jan 21, 2014 at 10:18:39AM +0100, Ladislav Lhotka wrote:
> > 
> > On 21 Jan 2014, at 10:10, Juergen Schoenwaelder  wrote:
> > 
> > > On Tue, Jan 21, 2014 at 09:36:32AM +0100, Ladislav Lhotka wrote:
> > >> Hi,
> > >> 
> > >> the definition of the enumeration type (sec. 9.6.4.2) contains another formulation that confuses me:
> > >> 
> > >>   If a value is not specified, then one will be automatically assigned.
> > >>   If the "enum" substatement is the first one defined, the assigned
> > >>   value is zero (0); otherwise, the assigned value is one greater than
> > >>   the current highest enum value.
> > >> 
> > >> So, for the example in 9.6.5
> > >> 
> > >>     leaf myenum {
> > >>         type enumeration {
> > >>             enum zero;
> > >>             enum one;
> > >>             enum seven {
> > >>                 value 7;
> > >>             }
> > >>         }
> > >>     }
> > >> 
> > >> the assignment should be
> > >> 
> > >> zero -> 0
> > >> one -> 8
> > >> seven -> 7
> > >> 
> > >> Is this correct?
> > > 
> > > Current in the order of definition, that is:
> > > 
> > >  zero -> 0
> > >  one -> 1
> > >  seven -> 7
> > 
> > And what if that value is already taken by a subsequent enum entry? That is,
> > 
> >     leaf myenum {
> >         type enumeration {
> >             enum zero;
> >             enum one;
> >             enum seven {
> >                 value 1;
> >             }
> >         }
> >     }
> > 
> 
> I assume this is the same as this and lead to the same result (namely
> that the YANG definition is violating a MUST in section 9.6.4.2).
> 
>      leaf myenum {
>          type enumeration {
>              enum zero { value 0; };
>              enum one { value 1; };
>              enum seven {
>                  value 1;
>              }
>          }
>      }
> 
> Yes, one can question this automatic value assignment feature -
> perhaps it would have been better to allow enumerations without
> assigned numeric values. Perhaps something to consider should we ever
> revise the YANG specification.
> 
> Martin, do you maintain a list of such issues?

Yes.  I will add this issue, altough I don't think this is a problem.


/martin


From lhotka@nic.cz  Tue Jan 21 01:44:57 2014
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 8800E1A00A2 for ; Tue, 21 Jan 2014 01:44:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 A6yxvFuLEZFE for ; Tue, 21 Jan 2014 01:44:56 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DF6961A00A0 for ; Tue, 21 Jan 2014 01:44:55 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7580813F876 for ; Tue, 21 Jan 2014 10:44:55 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390297495; bh=RVAejPCBBmlkcvXvMHXHIb0b4g19GRQcoKjEJUgGZ/E=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=s2l0NgFvi6zerjQSppNLWqYNX7bKlnDjkhwwzNqjQoVWsxrxWlr+g0I/E9o6HrW0e o7I0OVVJoXp+jJJFYiBkK0G9ba877N179QZ1Q2PUKgpS4XKPPSGaQ0lyBfJp3iyKXy ICA6W9fiLodeFoT/AHMjySpWKO9waJLA6/IeBPlI=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <52DE3CA6.7030308@mg-soft.com>
Date: Tue, 21 Jan 2014 10:44:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>
To: netmod@ietf.org
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Subject: Re: [netmod] enumeration 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: Tue, 21 Jan 2014 09:44:57 -0000

On 21 Jan 2014, at 10:23, Jernej Tuljak  =
wrote:

> Dne 21.1.2014 10:18, pi=9Ae Ladislav Lhotka:
>> On 21 Jan 2014, at 10:10, Juergen Schoenwaelder =
 wrote:
>>=20
>>> On Tue, Jan 21, 2014 at 09:36:32AM +0100, Ladislav Lhotka wrote:
>>>> Hi,
>>>>=20
>>>> the definition of the enumeration type (sec. 9.6.4.2) contains =
another formulation that confuses me:
>>>>=20
>>>>  If a value is not specified, then one will be automatically =
assigned.
>>>>  If the "enum" substatement is the first one defined, the assigned
>>>>  value is zero (0); otherwise, the assigned value is one greater =
than
>>>>  the current highest enum value.
>>>>=20
>>>> So, for the example in 9.6.5
>>>>=20
>>>>    leaf myenum {
>>>>        type enumeration {
>>>>            enum zero;
>>>>            enum one;
>>>>            enum seven {
>>>>                value 7;
>>>>            }
>>>>        }
>>>>    }
>>>>=20
>>>> the assignment should be
>>>>=20
>>>> zero -> 0
>>>> one -> 8
>>>> seven -> 7
>>>>=20
>>>> Is this correct?
>>> Current in the order of definition, that is:
>>>=20
>>> zero -> 0
>>> one -> 1
>>> seven -> 7
>> And what if that value is already taken by a subsequent enum entry? =
That is,
>>=20
>>    leaf myenum {
>>        type enumeration {
>>            enum zero;
>>            enum one;
>>            enum seven {
>>                value 1;
>>            }
>>        }
>>    }
>=20
> It counts as double assignment of a single value and is an error. =
That's what our implementation does anyways.

Well, I can=92t see how this follows from the text, given that the =
values needn=92t be ordered and can be negative. This value thing really =
seems overengineered but underspecified - given that the only apparent =
purpose is to make module updates harder. I=92d actually propose the =
following erratum:

OLD

  If a value is not specified, then one will be automatically assigned.
  If the "enum" substatement is the first one defined, the assigned
  value is zero (0); otherwise, the assigned value is one greater than
  the current highest enum value.

NEW

  If a value is not specified, an implementation MAY assign any unique =
value.

And then the restriction in sec. 10

  o  An "enumeration" type may have new enums added, provided the old
     enums's values do not change.

should be applied only to explicit enum values.=20

Lada


>=20
> Jernej
>=20
>> Lada
>>=20
>>> /js
>>>=20
>>> --=20
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
>>> Fax:   +49 421 200 3103         
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20

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





From j.schoenwaelder@jacobs-university.de  Tue Jan 21 01:54:13 2014
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 AE7D41A02C1 for ; Tue, 21 Jan 2014 01:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 w7s2aJRYEHJw for ; Tue, 21 Jan 2014 01:54:12 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEED1A0087 for ; Tue, 21 Jan 2014 01:54:12 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4930720070; Tue, 21 Jan 2014 10:54:12 +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 lLi_JqV0dXDS; Tue, 21 Jan 2014 10:54:12 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 870B02005E; Tue, 21 Jan 2014 10:54:11 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id B73A82AC275B; Tue, 21 Jan 2014 10:54:09 +0100 (CET)
Date: Tue, 21 Jan 2014 10:54:09 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20140121095409.GA47316@elstar.local>
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration type
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, 21 Jan 2014 09:54:13 -0000

On Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka wrote:
> 
> Well, I can’t see how this follows from the text, given that the values needn’t be ordered and can be negative. This value thing really seems overengineered but underspecified - given that the only apparent purpose is to make module updates harder. I’d actually propose the following erratum:
> 
> OLD
> 
>   If a value is not specified, then one will be automatically assigned.
>   If the "enum" substatement is the first one defined, the assigned
>   value is zero (0); otherwise, the assigned value is one greater than
>   the current highest enum value.
> 
> NEW
> 
>   If a value is not specified, an implementation MAY assign any unique value.
> 
> And then the restriction in sec. 10
> 
>   o  An "enumeration" type may have new enums added, provided the old
>      enums's values do not change.
> 
> should be applied only to explicit enum values. 

This is not what was intended when RFC 6020 was written and as far as
I can tell this is not what tools implement. Errata are not the way to
change specifications.

/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  Tue Jan 21 02:01:25 2014
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 73DD31A00AE for ; Tue, 21 Jan 2014 02:01:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 856sFA1g57Xl for ; Tue, 21 Jan 2014 02:01:23 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C12EA1A00A6 for ; Tue, 21 Jan 2014 02:01:23 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 805C913F876 for ; Tue, 21 Jan 2014 11:01:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390298482; bh=+mCzm0X+4kAYY6R+if8pOqTX+motfWNtKIjdrkMbqa4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=fM9opMUy52SxrjprNC1JbZbbYGoHJXZOIAqDEShUi70CZuPmj9+6mzDMqzkeJH+n3 f0NARjOTgmG4EV9QZbdgEQqLsz585fiRZBUHHJeLbIWHi1eco3osJgW+fd7hf6NyHE GLMrYXAZFKfdRddSS0ToKDyWS1L5cXqXkpA17oK0=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140121095409.GA47316@elstar.local>
Date: Tue, 21 Jan 2014 11:01:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F5422F7-8524-4E59-AB76-6B80939C8EE8@nic.cz>
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local>
To: netmod@ietf.org
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Subject: Re: [netmod] enumeration 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: Tue, 21 Jan 2014 10:01:25 -0000

On 21 Jan 2014, at 10:54, Juergen Schoenwaelder =
 wrote:

> On Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka wrote:
>>=20
>> Well, I can=92t see how this follows from the text, given that the =
values needn=92t be ordered and can be negative. This value thing really =
seems overengineered but underspecified - given that the only apparent =
purpose is to make module updates harder. I=92d actually propose the =
following erratum:
>>=20
>> OLD
>>=20
>> If a value is not specified, then one will be automatically assigned.
>> If the "enum" substatement is the first one defined, the assigned
>> value is zero (0); otherwise, the assigned value is one greater than
>> the current highest enum value.
>>=20
>> NEW
>>=20
>> If a value is not specified, an implementation MAY assign any unique =
value.
>>=20
>> And then the restriction in sec. 10
>>=20
>> o  An "enumeration" type may have new enums added, provided the old
>>    enums's values do not change.
>>=20
>> should be applied only to explicit enum values.=20
>=20
> This is not what was intended when RFC 6020 was written and as far as
> I can tell this is not what tools implement. Errata are not the way to
> change specifications.

Then another erratum should clarify this. I think the interpretation I =
started with (one->8) is compatible with the text, or at least not =
without reason, because the current highest enum value clearly is 7.

Lada


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

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





From jernej.tuljak@mg-soft.si  Tue Jan 21 02:02:50 2014
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 AF9501A00A6 for ; Tue, 21 Jan 2014 02:02:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 M0xynJHab76q for ; Tue, 21 Jan 2014 02:02:49 -0800 (PST)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 73F3C1A00A4 for ; Tue, 21 Jan 2014 02:02:49 -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 s0LA2lS2005967; Tue, 21 Jan 2014 11:02:47 +0100
Message-ID: <52DE45C3.4040400@mg-soft.com>
Date: Tue, 21 Jan 2014 11:02:43 +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: Ladislav Lhotka , netmod@ietf.org
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local>
In-Reply-To: <20140121095409.GA47316@elstar.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [netmod] enumeration 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: Tue, 21 Jan 2014 10:02:50 -0000

Dne 21.1.2014 10:54, piše Juergen Schoenwaelder:
> On Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka wrote:
>> Well, I can’t see how this follows from the text, given that the values needn’t be ordered and can be negative. This value thing really seems overengineered but underspecified - given that the only apparent purpose is to make module updates harder. I’d actually propose the following erratum:
>>
>> OLD
>>
>>    If a value is not specified, then one will be automatically assigned.
>>    If the "enum" substatement is the first one defined, the assigned
>>    value is zero (0); otherwise, the assigned value is one greater than
>>    the current highest enum value.
>>
>> NEW
>>
>>    If a value is not specified, an implementation MAY assign any unique value.
>>
>> And then the restriction in sec. 10
>>
>>    o  An "enumeration" type may have new enums added, provided the old
>>       enums's values do not change.
>>
>> should be applied only to explicit enum values.
> This is not what was intended when RFC 6020 was written and as far as
> I can tell this is not what tools implement. Errata are not the way to
> change specifications.

I think that the text could use a clearer definition of what "current 
highest enum value" is, however.

Jernej

>
> /js
>


From andy@yumaworks.com  Tue Jan 21 06:46:27 2014
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 A5CAE1A014D for ; Tue, 21 Jan 2014 06:46:27 -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 itXV-eFsM698 for ; Tue, 21 Jan 2014 06:46:25 -0800 (PST)
Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 93C501A015D for ; Tue, 21 Jan 2014 06:46:25 -0800 (PST)
Received: by mail-qe0-f50.google.com with SMTP id q19so162800qeb.9 for ; Tue, 21 Jan 2014 06:46:25 -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=dVVsZkKgo2PPN7j7tvGbc7R/zaN7eyVlFzcppNVveeQ=; b=gBg1NtVd/uuDcbvM0KCSDnnmKY1I+QIc3c1OWXTQmAe3rB2ooAUpwjumJErsDHqROa vjdZ48YX0nrPAGb+PgbdzAh3pu8ie5EFJn/GNt2NPqh9s5wWtWWKX+8cfGnIxRmVDnV6 uFucJ2JhIvJtkAKfXjfvQTyp/t5SItxCl3j74V9Oxl6XwlaeuxHpF3YN6rd4RN3nmhcY IrqhFgZtqNLlwrCLZoA/19h02q9BBg1H1xMzv+WNSHH1I3rG9LJCmDHjmXEoemRD6q3A 0qNbAJBHMqvWLSr1P6KJfGObBMmv+GxZGnk5ELWrKEvO5qF5jCUBYahWiC7AuKGvhbXX IZfg==
X-Gm-Message-State: ALoCoQlaGch410f2yPbIAAOmGOGD7uXtVAtdVGi90Mu60WCp5luB50PoBP07rYARM2zqqVQd2w+X
MIME-Version: 1.0
X-Received: by 10.229.35.194 with SMTP id q2mr11495069qcd.7.1390315585111; Tue, 21 Jan 2014 06:46:25 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 21 Jan 2014 06:46:24 -0800 (PST)
In-Reply-To: <52DE45C3.4040400@mg-soft.com>
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>
Date: Tue, 21 Jan 2014 06:46:24 -0800
Message-ID: 
From: Andy Bierman 
To: Jernej Tuljak 
Content-Type: multipart/alternative; boundary=001a1133c18694e1c904f07c1263
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Tue, 21 Jan 2014 14:46:27 -0000

--001a1133c18694e1c904f07c1263
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I do not understand all this fuss over a field used just
for documentation.  The value field is not used
in the protocol.  It is not referenced in any other
YANG statement.

I thought the auto-assignment procedure was clear
when I implemented it.

Andy



On Tue, Jan 21, 2014 at 2:02 AM, Jernej Tuljak wr=
ote:

> Dne 21.1.2014 10:54, pi=C5=A1e Juergen Schoenwaelder:
>
>> On Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka wrote:
>>
>>> Well, I can=E2=80=99t see how this follows from the text, given that th=
e values
>>> needn=E2=80=99t be ordered and can be negative. This value thing really=
 seems
>>> overengineered but underspecified - given that the only apparent purpos=
e is
>>> to make module updates harder. I=E2=80=99d actually propose the followi=
ng erratum:
>>>
>>> OLD
>>>
>>>    If a value is not specified, then one will be automatically assigned=
.
>>>    If the "enum" substatement is the first one defined, the assigned
>>>    value is zero (0); otherwise, the assigned value is one greater than
>>>    the current highest enum value.
>>>
>>> NEW
>>>
>>>    If a value is not specified, an implementation MAY assign any unique
>>> value.
>>>
>>> And then the restriction in sec. 10
>>>
>>>    o  An "enumeration" type may have new enums added, provided the old
>>>       enums's values do not change.
>>>
>>> should be applied only to explicit enum values.
>>>
>> This is not what was intended when RFC 6020 was written and as far as
>> I can tell this is not what tools implement. Errata are not the way to
>> change specifications.
>>
>
> I think that the text could use a clearer definition of what "current
> highest enum value" is, however.
>
> Jernej
>
>
>> /js
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--001a1133c18694e1c904f07c1263
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I do not understand all this fuss o=
ver a field used just
for documentation. =C2=A0The value field is=
 not used
in the protocol. =C2=A0It is not referenced in any othe=
r

YANG statement.

I thought the auto-assignment proc=
edure was clear
when I implemented it.=C2=A0

=

Andy





On Tue, Jan 21, 2014 at 2:02 AM, Jernej Tuljak <=
span dir=3D"ltr"><jernej.tuljak@mg-soft.si> wrote:

Dne 21.1.2014 10:54, pi=C5=A1e Juergen Schoenwaelder:



On Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka wrote:



Well, I can=E2=80=99t see how this follows from the text, given that the va=
lues needn=E2=80=99t be ordered and can be negative. This value thing reall=
y seems overengineered but underspecified - given that the only apparent pu=
rpose is to make module updates harder. I=E2=80=99d actually propose the fo=
llowing erratum:




OLD



=C2=A0 =C2=A0If a value is not specified, then one will be automatically as=
signed.

=C2=A0 =C2=A0If the "enum" substatement is the first one defined,=
 the assigned

=C2=A0 =C2=A0value is zero (0); otherwise, the assigned value is one greate=
r than

=C2=A0 =C2=A0the current highest enum value.



NEW



=C2=A0 =C2=A0If a value is not specified, an implementation MAY assign any =
unique value.



And then the restriction in sec. 10



=C2=A0 =C2=A0o =C2=A0An "enumeration" type may have new enums add=
ed, provided the old

=C2=A0 =C2=A0 =C2=A0 enums's values do not change.



should be applied only to explicit enum values.



This is not what was intended when RFC 6020 was written and as far as

I can tell this is not what tools implement. Errata are not the way to

change specifications.





I think that the text could use a clearer definition of what "current =
highest enum value" is, however.



Jernej







/js







_______________________________________________

netmod mailing list

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





--001a1133c18694e1c904f07c1263--

From jonathan@hansfords.net  Tue Jan 21 07:23:35 2014
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 672EE1A0167 for ; Tue, 21 Jan 2014 07:23:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Ju9FyRG8c9cG for ; Tue, 21 Jan 2014 07:23:32 -0800 (PST)
Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id 06EA21A0121 for ; Tue, 21 Jan 2014 07:23:31 -0800 (PST)
Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id GfPV1n0044CLSd801fPWxa; Tue, 21 Jan 2014 15:23:31 +0000
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=LqOrlBtc c=1 sm=1 tr=0 a=VrPob/PGR4vzCiwW53VWbQ==:117 a=657E4hAeR8dYZ1rsg01OlA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=ymigdH7LP5EA:10 a=0B8HqoTn75oA:10 a=eDuwVpe5h8AA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=valQ_CuEJh4A:10 a=48vgC7mUAAAA:8 a=TsULZLb35Ops9J5czI4A:9 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=0hOLvd8aYVXGrFWHX1UA:9 a=AVtqeCL_5HFDHIHG:21 a=_W_S_7VecoQA:10
X-AUTH: hansfords+us:2500
Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Tue, 21 Jan 2014 15:23:29 +0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_b1fcbc0c115e1f6a52ff0405f99989ba"
Date: Tue, 21 Jan 2014 15:23:29 +0000
From: Jonathan Hansford 
To: 
In-Reply-To: 
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com> 
Message-ID: <53eb7125803729d92a23665c0f0396ff@imap.plus.net>
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [212.159.131.152]
Subject: Re: [netmod] enumeration 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: Tue, 21 Jan 2014 15:23:35 -0000

--=_b1fcbc0c115e1f6a52ff0405f99989ba
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

 

On 2014-01-21 14:46, Andy Bierman wrote: 

> Hi, 
> I do not
understand all this fuss over a field used just 
> for documentation.
The value field is not used 
> in the protocol. It is not referenced in
any other 
> YANG statement. 
> I thought the auto-assignment procedure
was clear 
> when I implemented it.

It would appear it isn't clear if
this thread is anything to go by, but if the field is never used (other
than for documentation) and therefore has no interoperability issues
between different implementations then I guess it is up to each
implementer to decide what they do with values. 

> Andy 
> 
> On Tue,
Jan 21, 2014 at 2:02 AM, Jernej Tuljak 
wrote:
> 
>> Dne 21.1.2014 10:54, piše Juergen Schoenwaelder:
>> 
>>> On
Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka wrote:
>>> 
>>>>
Well, I can't see how this follows from the text, given that the values
needn't be ordered and can be negative. This value thing really seems
overengineered but underspecified - given that the only apparent purpose
is to make module updates harder. I'd actually propose the following
erratum:
>>>> 
>>>> OLD
>>>> 
>>>> If a value is not specified, then one
will be automatically assigned.
>>>> If the "enum" substatement is the
first one defined, the assigned
>>>> value is zero (0); otherwise, the
assigned value is one greater than
>>>> the current highest enum
value.
>>>> 
>>>> NEW
>>>> 
>>>> If a value is not specified, an
implementation MAY assign any unique value.
>>>> 
>>>> And then the
restriction in sec. 10
>>>> 
>>>> o An "enumeration" type may have new
enums added, provided the old
>>>> enums's values do not change.
>>>>

>>>> should be applied only to explicit enum values.
>>> This is not
what was intended when RFC 6020 was written and as far as
>>> I can tell
this is not what tools implement. Errata are not the way to
>>> change
specifications.
>> 
>> I think that the text could use a clearer
definition of what "current highest enum value" is, however.
>> 
>>
Jernej
>> 
>>> /js
>> 
>>
_______________________________________________
>> netmod mailing
list
>> netmod@ietf.org [1]
>>
https://www.ietf.org/mailman/listinfo/netmod [2]
 

Links:
------
[1]
mailto:netmod@ietf.org
[2]
https://www.ietf.org/mailman/listinfo/netmod
[3]
mailto:jernej.tuljak@mg-soft.si

--=_b1fcbc0c115e1f6a52ff0405f99989ba
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8




On 2014-01-21 14:46, Andy Bierman wrote:




Hi,

I do not understand all this fuss over a field used just


for documentation.  The value field is not used


in the protocol.  It is not referenced in any other


YANG statement.


I thought the auto-assignment procedure was clear


when I implemented it. 








It would appear it isn't clear if this thread is anything to go by, bu=
t if the field is never used (other than for documentation) and therefore h=
as no interoperability issues between different implementations then I gues=
s it is up to each implementer to decide what they do with values. 








Andy







On Tue, Jan 21, 2014 at 2:02 AM, Jernej Tuljak <=
span><jernej.tuljak@mg-soft=
=2Esi> wrote:


Dne 21.1.2014 10:54, piše =
Juergen Schoenwaelder:


On Tue, Jan 21, 2014 at 10:44:55A=
M +0100, Ladislav Lhotka wrote:


Well, I can’t see how this =
follows from the text, given that the values needn’t be ordered and c=
an be negative. This value thing really seems overengineered but underspeci=
fied - given that the only apparent purpose is to make module updates harde=
r. I’d actually propose the following erratum:

 OLD
<=
br />    If a value is not specified, then one will be automatica=
lly assigned.
    If the "enum" substatement is the first on=
e defined, the assigned
    value is zero (0); otherwise, th=
e assigned value is one greater than
    the current highest=
 enum value.

 NEW

    If a value is not spe=
cified, an implementation MAY assign any unique value.

 And then=
 the restriction in sec. 10

    o  An "enumeratio=
n" type may have new enums added, provided the old
     &nbs=
p; enums's values do not change.

 should be applied only to expl=
icit enum values.

This is not what was intended when RFC 6020 was written and as far as
=
 I can tell this is not what tools implement. Errata are not the way to
 change specifications.


 I think that the text could use a clearer definition of what "curren=
t highest enum value" is, however.

 Jernej




 /js



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













--=_b1fcbc0c115e1f6a52ff0405f99989ba--


From andy@yumaworks.com  Tue Jan 21 07:45:50 2014
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 BDF4B1A0344 for ; Tue, 21 Jan 2014 07:45:50 -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 2f6JOAvYegKX for ; Tue, 21 Jan 2014 07:45:48 -0800 (PST)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id 38EE51A02DB for ; Tue, 21 Jan 2014 07:45:48 -0800 (PST)
Received: by mail-qc0-f169.google.com with SMTP id w7so7272305qcr.14 for ; Tue, 21 Jan 2014 07:45:48 -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=XHcT6/yVtyl+UaxsADqXhvgooI7K/UKMOqoYiTE8Hio=; b=gPDhwiyNlCbkBIzI5zcN/4UHHABgBTZsAwextWdGEV/UiDpaKUdvKLK3+2WVu2bmat es7M+MY5ld22ln1gMWYZznOLfg/sZbWlen5WUz9zqZFB1Y8hYO+ZC31j+eQYdHlAsXxJ 1hNQzG7s/wVy8oCYf5WqmyGcHbqdzFzdOOPJpx17MYRVRV37BeEKTfFWW6oofYWDDBpi vela3OVvH18Hk9qj0fMNcf9mvX+dCLeACfwD0q1GEgUM6Uq7BITRZAo6Kv3h4l8iAKb2 39rXVFzFZblngPgldk0icNCRWAhIM5FpYTkG7b3aGIZiPR+ejpbQuiL/P+/Gt1Cn7nUs EsWA==
X-Gm-Message-State: ALoCoQn8YOTyoHEPh16MfSsBwDMSpsm1LhQBPilxaXNAU6zds/e5WzYzddrw0s1QTv8yOAEGjPXf
MIME-Version: 1.0
X-Received: by 10.140.92.65 with SMTP id a59mr35783081qge.34.1390319147867; Tue, 21 Jan 2014 07:45:47 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 21 Jan 2014 07:45:47 -0800 (PST)
In-Reply-To: <53eb7125803729d92a23665c0f0396ff@imap.plus.net>
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>  <53eb7125803729d92a23665c0f0396ff@imap.plus.net>
Date: Tue, 21 Jan 2014 07:45:47 -0800
Message-ID: 
From: Andy Bierman 
To: Jonathan Hansford 
Content-Type: multipart/alternative; boundary=001a113ab29eef1c6604f07ce678
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Tue, 21 Jan 2014 15:45:50 -0000

--001a113ab29eef1c6604f07ce678
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 21, 2014 at 7:23 AM, Jonathan Hansford
wrote:

>  On 2014-01-21 14:46, Andy Bierman wrote:
>
> Hi,
> I do not understand all this fuss over a field used just
> for documentation.  The value field is not used
> in the protocol.  It is not referenced in any other
> YANG statement.
> I thought the auto-assignment procedure was clear
> when I implemented it.
>
>  It would appear it isn't clear if this thread is anything to go by, but
> if the field is never used (other than for documentation) and therefore h=
as
> no interoperability issues between different implementations then I guess
> it is up to each implementer to decide what they do with values.
>

It needs to be clear so a module accepted by one YANG compiler does
not get rejected by another one.   I thought the rules were clear, then I
just tested our compiler and it does not complain about some errors. ;-)

AFAIK, rules are: (process enums in document order)
   1) if first enum has a value-stmt, start with that value, else start
with 0
   2) for each enum (2 - n):
       if enum has value-stmt, use that, otherwise use value( enum[N-1] ) +
1
       * generate an error if enum value is <=3D value( enum[N-1] )

Andy


  Andy
>
> On Tue, Jan 21, 2014 at 2:02 AM, Jernej Tuljak =
wrote:
>
>> Dne 21.1.2014 10:54, pi=C5=A1e Juergen Schoenwaelder:
>>
>>> On Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka wrote:
>>>
>>>> Well, I can=E2=80=99t see how this follows from the text, given that t=
he values
>>>> needn=E2=80=99t be ordered and can be negative. This value thing reall=
y seems
>>>> overengineered but underspecified - given that the only apparent purpo=
se is
>>>> to make module updates harder. I=E2=80=99d actually propose the follow=
ing erratum:
>>>>
>>>> OLD
>>>>
>>>>    If a value is not specified, then one will be automatically assigne=
d.
>>>>    If the "enum" substatement is the first one defined, the assigned
>>>>    value is zero (0); otherwise, the assigned value is one greater tha=
n
>>>>    the current highest enum value.
>>>>
>>>> NEW
>>>>
>>>>    If a value is not specified, an implementation MAY assign any uniqu=
e
>>>> value.
>>>>
>>>> And then the restriction in sec. 10
>>>>
>>>>    o  An "enumeration" type may have new enums added, provided the old
>>>>       enums's values do not change.
>>>>
>>>> should be applied only to explicit enum values.
>>>
>>> This is not what was intended when RFC 6020 was written and as far as
>>> I can tell this is not what tools implement. Errata are not the way to
>>> change specifications.
>>
>>
>> I think that the text could use a clearer definition of what "current
>> highest enum value" is, however.
>>
>> Jernej
>>
>>
>>> /js
>>>
>>>
>> _______________________________________________
>> 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
>
>

--001a113ab29eef1c6604f07ce678
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Tue, Jan 21, 2014 at 7:23 AM, Jonathan Hansford <Jonathan@=
hansfords.net> wrote:






On 2014-01-21 14:46, Andy Bierman wrote:




Hi,

I do not understand all this fuss over a field used just


for documentation. =C2=A0The value field is not used


in the protocol. =C2=A0It is not referenced in any other


YANG statement.


I thought the auto-assignment procedure was clear


when I implemented it.=C2=A0








It would appear it isn't clear if this thread is anything to go by=
, but if the field is never used (other than for documentation) and therefo=
re has no interoperability issues between different implementations then I =
guess it is up to each implementer to decide what they do with values.


It needs to be clear so a modu=
le accepted by one YANG compiler does
not get rejected by another=
 one. =C2=A0 I thought the rules were clear, then I
just tested o=
ur compiler and it does not complain about some errors. ;-)



AFAIK, rules are: (process enums in document order)
=C2=A0 =C2=A01) if first enum has a value-stmt, start with that valu=
e, else start with 0
=C2=A0 =C2=A02) for each enum (2 - n):
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0if enum has value-stmt, use that, otherwise=
 use value( enum[N-1] ) + 1


=C2=A0 =C2=A0 =C2=A0 =C2=A0* generate an error if enum value is <=
=3D value( enum[N-1] )

Andy




 








Andy







On Tue, Jan 21, 2014 at 2:02 AM, Jernej Tuljak <=
span><jern=
ej.tuljak@mg-soft.si> wrote:


Dne 21.1.2014 10:54, pi=C5=A1e Juergen Schoenwaelder:


On Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka =
wrote:



Well, I can=E2=80=99t see how this follows from the text, =
given that the values needn=E2=80=99t be ordered and can be negative. This =
value thing really seems overengineered but underspecified - given that the=
 only apparent purpose is to make module updates harder. I=E2=80=99d actual=
ly propose the following erratum:


 OLD

 =C2=A0 =C2=A0If a value is not specified, then one will be=
 automatically assigned.
 =C2=A0 =C2=A0If the "enum" substatem=
ent is the first one defined, the assigned
 =C2=A0 =C2=A0value is zero (=
0); otherwise, the assigned value is one greater than

 =C2=A0 =C2=A0the current highest enum value.

 NEW

 =C2=A0 =
=C2=A0If a value is not specified, an implementation MAY assign any unique =
value.

 And then the restriction in sec. 10

 =C2=A0 =C2=A0o =
=C2=A0An "enumeration" type may have new enums added, provided th=
e old

 =C2=A0 =C2=A0 =C2=A0 enums's values do not change.

 should be a=
pplied only to explicit enum values.

This is not what was intended when RFC 6020 was written and as far as
 I=
 can tell this is not what tools implement. Errata are not the way to
 c=
hange specifications.


 I think that the text could use a clearer definition of what "cur=
rent highest enum value" is, however.

 Jernej




 /js



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















_______________________________________________

netmod mailing list

netmod@ietf.org

=
https://www.ietf.org/mailman/listinfo/netmod





--001a113ab29eef1c6604f07ce678--

From andy@yumaworks.com  Tue Jan 21 08:18:56 2014
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 39D1F1A039E for ; Tue, 21 Jan 2014 08:18:56 -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 HwOJ4JKmywRA for ; Tue, 21 Jan 2014 08:18:53 -0800 (PST)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 063EF1A03C7 for ; Tue, 21 Jan 2014 08:18:49 -0800 (PST)
Received: by mail-qc0-f171.google.com with SMTP id n7so7177025qcx.2 for ; Tue, 21 Jan 2014 08:18:49 -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=YPIQc8lY03egXFTQq1so4WHe7yl3Poi2EIg3sQVePfs=; b=W0UJS3k3Vf/CGDRxWJYW6Kglh9nMMwUaJlDVV59VLtVHP4kbMVW1NKYuVhUSo5w39A +u5YiV0md+0fs4hKjddp2e+DVxtyIA2o05dLYEJ5Pq7TWDZTxkQPYF71iosu/OjkgHzM AB5WSB/fs1/0ybp5tEttB+bL389cxB+L8CZEaT1BwX6+lh0qWUh54E/dHVS2N1j+rceB bkVD2NUW+iaO3+dUGvhFvIfgQJ2MUDKu3o+jMhRJRLPEZCP/pHHxQjB8gsaKDH/g5fK3 u252qBFdAiwjI2lAMgL7Wm5B3DFUMj54UP5SCM4yEU7Gn/LcwH7Ha2qLAWVehRAqgVi9 t8Lg==
X-Gm-Message-State: ALoCoQl+WHWL+XZUx0eOodXu5DtvRJNWxNUsJuDzVXipq/sYNPEpgtTA4JLh4/V0i36jGHmFACV3
MIME-Version: 1.0
X-Received: by 10.224.119.79 with SMTP id y15mr10413501qaq.16.1390321129363; Tue, 21 Jan 2014 08:18:49 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 21 Jan 2014 08:18:49 -0800 (PST)
In-Reply-To: 
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>  <53eb7125803729d92a23665c0f0396ff@imap.plus.net> 
Date: Tue, 21 Jan 2014 08:18:49 -0800
Message-ID: 
From: Andy Bierman 
To: Jonathan Hansford 
Content-Type: multipart/alternative; boundary=047d7b6d7e0a0ac81804f07d5de3
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Tue, 21 Jan 2014 16:18:56 -0000

--047d7b6d7e0a0ac81804f07d5de3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 21, 2014 at 7:45 AM, Andy Bierman  wrote:

>
>
>
> On Tue, Jan 21, 2014 at 7:23 AM, Jonathan Hansford  > wrote:
>
>>  On 2014-01-21 14:46, Andy Bierman wrote:
>>
>> Hi,
>> I do not understand all this fuss over a field used just
>> for documentation.  The value field is not used
>> in the protocol.  It is not referenced in any other
>> YANG statement.
>> I thought the auto-assignment procedure was clear
>> when I implemented it.
>>
>>  It would appear it isn't clear if this thread is anything to go by, but
>> if the field is never used (other than for documentation) and therefore =
has
>> no interoperability issues between different implementations then I gues=
s
>> it is up to each implementer to decide what they do with values.
>>
>
> It needs to be clear so a module accepted by one YANG compiler does
> not get rejected by another one.   I thought the rules were clear, then I
> just tested our compiler and it does not complain about some errors. ;-)
>
> AFAIK, rules are: (process enums in document order)
>    1) if first enum has a value-stmt, start with that value, else start
> with 0
>    2) for each enum (2 - n):
>        if enum has value-stmt, use that, otherwise use value( enum[N-1] )
> + 1
>

=3D=3D> Use any unassigned value if current value( enum[N-1] ) =3D=3D MAXIN=
T

       * generate an error if enum value is <=3D value( enum[N-1] )
>
>
oops -- there is no requirement that the enum values be in ascending order.
The value just has to be unique with the enumeration type.

 =3D=3D>     * generate an error if enum value  =3D=3D any previously assig=
ned value


> Andy
>

Andy


>
>
>    Andy
>>
>> On Tue, Jan 21, 2014 at 2:02 AM, Jernej Tuljak wrote:
>>
>>> Dne 21.1.2014 10:54, pi=C5=A1e Juergen Schoenwaelder:
>>>
>>>> On Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka wrote:
>>>>
>>>>> Well, I can=E2=80=99t see how this follows from the text, given that =
the
>>>>> values needn=E2=80=99t be ordered and can be negative. This value thi=
ng really
>>>>> seems overengineered but underspecified - given that the only apparen=
t
>>>>> purpose is to make module updates harder. I=E2=80=99d actually propos=
e the
>>>>> following erratum:
>>>>>
>>>>> OLD
>>>>>
>>>>>    If a value is not specified, then one will be automatically
>>>>> assigned.
>>>>>    If the "enum" substatement is the first one defined, the assigned
>>>>>    value is zero (0); otherwise, the assigned value is one greater th=
an
>>>>>    the current highest enum value.
>>>>>
>>>>> NEW
>>>>>
>>>>>    If a value is not specified, an implementation MAY assign any
>>>>> unique value.
>>>>>
>>>>> And then the restriction in sec. 10
>>>>>
>>>>>    o  An "enumeration" type may have new enums added, provided the ol=
d
>>>>>       enums's values do not change.
>>>>>
>>>>> should be applied only to explicit enum values.
>>>>
>>>> This is not what was intended when RFC 6020 was written and as far as
>>>> I can tell this is not what tools implement. Errata are not the way to
>>>> change specifications.
>>>
>>>
>>> I think that the text could use a clearer definition of what "current
>>> highest enum value" is, however.
>>>
>>> Jernej
>>>
>>>
>>>> /js
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>
>>
>

--047d7b6d7e0a0ac81804f07d5de3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Tue, Jan 21, 2014 at 7:45 AM, Andy Bierman <=
;andy@yumaworks.com=
> wrote:






On Tue, Jan 21, 2014 at 7:23 AM, Jonathan Hansford <Jonathan@hansford=
s.net> wrote:






On 2014-01-21 14:46, Andy Bierman wrote:




Hi,

I do not understand all this fuss over a field used just


for documentation. =C2=A0The value field is not used


in the protocol. =C2=A0It is not referenced in any other


YANG statement.


I thought the auto-assignment procedure was clear


when I implemented it.=C2=A0








It would appear it isn't clear if this thread is anything to go by=
, but if the field is never used (other than for documentation) and therefo=
re has no interoperability issues between different implementations then I =
guess it is up to each implementer to decide what they do with values.



It needs to be clear so a modu=
le accepted by one YANG compiler does
not get rejected by another=
 one. =C2=A0 I thought the rules were clear, then I
just tested o=
ur compiler and it does not complain about some errors. ;-)




AFAIK, rules are: (process enums in document order)
=C2=A0 =C2=A01) if first enum has a value-stmt, start with that valu=
e, else start with 0
=C2=A0 =C2=A02) for each enum (2 - n):
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0if enum has value-stmt, use that, otherwise=
 use value( enum[N-1] ) + 1



=3D=3D> Use any unass=
igned value if current value( enum[N-1] ) =3D=3D MAXINT





=C2=A0 =C2=A0 =C2=A0 =C2=A0* generate an error if enum value is <=
=3D value( enum[N-1] )

<=
div>
oops -- there is no requirement that the enum values be =
in ascending order.


The value just has to be unique with the enumeration type.
<=
br>
=C2=A0=3D=3D> =C2=A0 =C2=A0 * generate an error if enum va=
lue =C2=A0=3D=3D any previously assigned value
=C2=A0


Andy

Andy
=C2=A0







 








Andy







On Tue, Jan 21, 2014 at 2:02 AM, Jernej Tuljak <=
span><jern=
ej.tuljak@mg-soft.si> wrote:


Dne 21.1.2014 10:54, pi=C5=A1e Juergen Schoenwaelder:


On Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka =
wrote:




Well, I can=E2=80=99t see how this follows from the text, =
given that the values needn=E2=80=99t be ordered and can be negative. This =
value thing really seems overengineered but underspecified - given that the=
 only apparent purpose is to make module updates harder. I=E2=80=99d actual=
ly propose the following erratum:



 OLD

 =C2=A0 =C2=A0If a value is not specified, then one will be=
 automatically assigned.
 =C2=A0 =C2=A0If the "enum" substatem=
ent is the first one defined, the assigned
 =C2=A0 =C2=A0value is zero (=
0); otherwise, the assigned value is one greater than


 =C2=A0 =C2=A0the current highest enum value.

 NEW

 =C2=A0 =
=C2=A0If a value is not specified, an implementation MAY assign any unique =
value.

 And then the restriction in sec. 10

 =C2=A0 =C2=A0o =
=C2=A0An "enumeration" type may have new enums added, provided th=
e old


 =C2=A0 =C2=A0 =C2=A0 enums's values do not change.

 should be a=
pplied only to explicit enum values.

This is not what was intended when RFC 6020 was written and as far as
 I=
 can tell this is not what tools implement. Errata are not the way to
 c=
hange specifications.


 I think that the text could use a clearer definition of what "cur=
rent highest enum value" is, however.

 Jernej




 /js



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
















_______________________________________________

netmod mailing list

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








--047d7b6d7e0a0ac81804f07d5de3--

From andy@yumaworks.com  Tue Jan 21 08:43:01 2014
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 811D21A0373 for ; Tue, 21 Jan 2014 08:43:01 -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 ZzZrwaFw3rmX for ; Tue, 21 Jan 2014 08:42:58 -0800 (PST)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id DB0841A0191 for ; Tue, 21 Jan 2014 08:42:54 -0800 (PST)
Received: by mail-qa0-f46.google.com with SMTP id ii20so6653346qab.19 for ; Tue, 21 Jan 2014 08: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:cc:content-type; bh=kqcQ24Tso0lMqsSaPjhhQmihrZkm9p7LWvClBnYwfM4=; b=U44panhAtWsggYjLAUSYhCfdGK7JbRhUO4F8DTn30hJkzIKiXMx6qEPgbgUu97Qo1P hm9dgmlpugj42tKUilGhArF9RtUob/7iDAi/lhHH/iZNscfXM1UqM3uJtJY2FomqqvvZ HZX78+/CcAZM1QPDMGdGrS08XMIohdJtN2bSgDKKywnw/Tp3MnSiUL1fvL2P5aHh8MZr Pwqu+1lJsG8zB24F9CDOEOdSF1UCg0qativ3QB0MfdldwvjsF3DI+9i4DlK5JSb4J5r/ fS3HWJxuwYZSDGP+OjAFgCLiQ74loHi1r5FYtdqozswGbsWMumjaXhDD6NYQDBSOavZF 8nEg==
X-Gm-Message-State: ALoCoQkT9zvHzlRxYfo0FD0cxpovB+a27QrQLx1edf2HCtfhc0N4YGfAQqCoLqTtePXYXVPPzgNm
MIME-Version: 1.0
X-Received: by 10.229.194.1 with SMTP id dw1mr38853879qcb.20.1390322574509; Tue, 21 Jan 2014 08:42:54 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 21 Jan 2014 08:42:54 -0800 (PST)
In-Reply-To: 
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>  <53eb7125803729d92a23665c0f0396ff@imap.plus.net> 
Date: Tue, 21 Jan 2014 08:42:54 -0800
Message-ID: 
From: Andy Bierman 
To: Jonathan Hansford 
Content-Type: multipart/alternative; boundary=001a11c2c7362d905a04f07db3f9
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Tue, 21 Jan 2014 16:43:01 -0000

--001a11c2c7362d905a04f07db3f9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

Jonathan, you are right -- the rules are not obvious.
Our code does not implement the rules I specified.
It uses the next highest value assigned:

  leaf enum-test {
    type enumeration {
       enum seven { value 7; }
       enum eight;  // value 8
       enum nine;  // value 9
       enum four { value 4; }
       enum ten;   // value 10, not 5
       enum eleven;   // value 11, not 6
    }
  }


Andy



On Tue, Jan 21, 2014 at 7:45 AM, Andy Bierman  wrote:

>
>
>
> On Tue, Jan 21, 2014 at 7:23 AM, Jonathan Hansford  > wrote:
>
>>  On 2014-01-21 14:46, Andy Bierman wrote:
>>
>> Hi,
>> I do not understand all this fuss over a field used just
>> for documentation.  The value field is not used
>> in the protocol.  It is not referenced in any other
>> YANG statement.
>> I thought the auto-assignment procedure was clear
>> when I implemented it.
>>
>>  It would appear it isn't clear if this thread is anything to go by, but
>> if the field is never used (other than for documentation) and therefore =
has
>> no interoperability issues between different implementations then I gues=
s
>> it is up to each implementer to decide what they do with values.
>>
>
> It needs to be clear so a module accepted by one YANG compiler does
> not get rejected by another one.   I thought the rules were clear, then I
> just tested our compiler and it does not complain about some errors. ;-)
>
> AFAIK, rules are: (process enums in document order)
>    1) if first enum has a value-stmt, start with that value, else start
> with 0
>    2) for each enum (2 - n):
>        if enum has value-stmt, use that, otherwise use value( enum[N-1] )
> + 1
>        * generate an error if enum value is <=3D value( enum[N-1] )
>
> Andy
>
>
>    Andy
>>
>> On Tue, Jan 21, 2014 at 2:02 AM, Jernej Tuljak wrote:
>>
>>> Dne 21.1.2014 10:54, pi=C5=A1e Juergen Schoenwaelder:
>>>
>>>> On Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka wrote:
>>>>
>>>>> Well, I can=E2=80=99t see how this follows from the text, given that =
the
>>>>> values needn=E2=80=99t be ordered and can be negative. This value thi=
ng really
>>>>> seems overengineered but underspecified - given that the only apparen=
t
>>>>> purpose is to make module updates harder. I=E2=80=99d actually propos=
e the
>>>>> following erratum:
>>>>>
>>>>> OLD
>>>>>
>>>>>    If a value is not specified, then one will be automatically
>>>>> assigned.
>>>>>    If the "enum" substatement is the first one defined, the assigned
>>>>>    value is zero (0); otherwise, the assigned value is one greater th=
an
>>>>>    the current highest enum value.
>>>>>
>>>>> NEW
>>>>>
>>>>>    If a value is not specified, an implementation MAY assign any
>>>>> unique value.
>>>>>
>>>>> And then the restriction in sec. 10
>>>>>
>>>>>    o  An "enumeration" type may have new enums added, provided the ol=
d
>>>>>       enums's values do not change.
>>>>>
>>>>> should be applied only to explicit enum values.
>>>>
>>>> This is not what was intended when RFC 6020 was written and as far as
>>>> I can tell this is not what tools implement. Errata are not the way to
>>>> change specifications.
>>>
>>>
>>> I think that the text could use a clearer definition of what "current
>>> highest enum value" is, however.
>>>
>>> Jernej
>>>
>>>
>>>> /js
>>>>
>>>>
>>> _______________________________________________
>>> 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
>>
>>
>

--001a11c2c7362d905a04f07db3f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

Jonathan, you are right -- the rule=
s are not obvious.
Our code does not implement the rules I specif=
ied.
It uses the next highest value assigned:



=C2=A0 leaf enum-test {
=C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 =C2=A0enum seven { value 7; }
=C2=A0 =
=C2=A0 =C2=A0 =C2=A0enum eight; =C2=A0// value 8
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0enum nine; =C2=A0// value 9
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0enum four { value 4; }


=C2=A0 =C2=A0 =C2=A0 =C2=A0enum ten; =C2=A0 // value 10, not 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0enum eleven; =C2=A0 // value 11, not 6
<=
div>=C2=A0 =C2=A0 }
=C2=A0 }


<=
div>Andy




On Tue, Jan 21, 2014 at 7:45 AM, Andy Bierma=
n <andy@yumaworks.com> wrote:





On Tue, Jan 21, 2014 at 7:23 AM, Jonathan Hansford <Jonathan@=
hansfords.net> wrote:







On 2014-01-21 14:46, Andy Bierman wrote:




Hi,

I do not understand all this fuss over a field used just


for documentation. =C2=A0The value field is not used


in the protocol. =C2=A0It is not referenced in any other


YANG statement.


I thought the auto-assignment procedure was clear


when I implemented it.=C2=A0








It would appear it isn't clear if this thread is anything to go by=
, but if the field is never used (other than for documentation) and therefo=
re has no interoperability issues between different implementations then I =
guess it is up to each implementer to decide what they do with values.



It needs to be clear so a modu=
le accepted by one YANG compiler does
not get rejected by another=
 one. =C2=A0 I thought the rules were clear, then I
just tested o=
ur compiler and it does not complain about some errors. ;-)




AFAIK, rules are: (process enums in document order)
=C2=A0 =C2=A01) if first enum has a value-stmt, start with that valu=
e, else start with 0
=C2=A0 =C2=A02) for each enum (2 - n):
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0if enum has value-stmt, use that, otherwise=
 use value( enum[N-1] ) + 1



=C2=A0 =C2=A0 =C2=A0 =C2=A0* generate an error if enum value is <=
=3D value( enum[N-1] )

Andy





 








Andy







On Tue, Jan 21, 2014 at 2:02 AM, Jernej Tuljak <=
span><jern=
ej.tuljak@mg-soft.si> wrote:


Dne 21.1.2014 10:54, pi=C5=A1e Juergen Schoenwaelder:


On Tue, Jan 21, 2014 at 10:44:55AM +0100, Ladislav Lhotka =
wrote:




Well, I can=E2=80=99t see how this follows from the text, =
given that the values needn=E2=80=99t be ordered and can be negative. This =
value thing really seems overengineered but underspecified - given that the=
 only apparent purpose is to make module updates harder. I=E2=80=99d actual=
ly propose the following erratum:



 OLD

 =C2=A0 =C2=A0If a value is not specified, then one will be=
 automatically assigned.
 =C2=A0 =C2=A0If the "enum" substatem=
ent is the first one defined, the assigned
 =C2=A0 =C2=A0value is zero (=
0); otherwise, the assigned value is one greater than


 =C2=A0 =C2=A0the current highest enum value.

 NEW

 =C2=A0 =
=C2=A0If a value is not specified, an implementation MAY assign any unique =
value.

 And then the restriction in sec. 10

 =C2=A0 =C2=A0o =
=C2=A0An "enumeration" type may have new enums added, provided th=
e old


 =C2=A0 =C2=A0 =C2=A0 enums's values do not change.

 should be a=
pplied only to explicit enum values.

This is not what was intended when RFC 6020 was written and as far as
 I=
 can tell this is not what tools implement. Errata are not the way to
 c=
hange specifications.


 I think that the text could use a clearer definition of what "cur=
rent highest enum value" is, however.

 Jernej




 /js



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
















_______________________________________________

netmod mailing list

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








--001a11c2c7362d905a04f07db3f9--

From per@tail-f.com  Tue Jan 21 08:51:54 2014
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 14AC61A02D7 for ; Tue, 21 Jan 2014 08:51:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 4ApHzGUaAJs0 for ; Tue, 21 Jan 2014 08:51: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 8BD9B1A01B8 for ; Tue, 21 Jan 2014 08:51:52 -0800 (PST)
Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 656A1240C36D; Tue, 21 Jan 2014 17:51:51 +0100 (CET)
Message-ID: <52DEA5A7.5010200@tail-f.com>
Date: Tue, 21 Jan 2014 17:51:51 +0100
From: Per Hedeland 
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7
MIME-Version: 1.0
To: Andy Bierman 
References: <67C71E62-16C8-4772-9096-89DDD65BFA3B@nic.cz> <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>  <53eb7125803729d92a23665c0f0396ff@imap.plus.net>  
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Tue, 21 Jan 2014 16:51:54 -0000

On 2014-01-21 17:42, Andy Bierman wrote:
> Hi,
> 
> Jonathan, you are right -- the rules are not obvious.
> Our code does not implement the rules I specified.
> It uses the next highest value assigned:
> 
>   leaf enum-test {
>     type enumeration {
>        enum seven { value 7; }
>        enum eight;  // value 8
>        enum nine;  // value 9
>        enum four { value 4; }
>        enum ten;   // value 10, not 5
>        enum eleven;   // value 11, not 6
>     }
>   }

That's what RFC 6020 says - it's just your rule listing that is
wrong.:-) But yes, the meaning of "current highest [enum] value" could
use clarification.

--Per

From michelle.cotton@icann.org  Tue Jan 21 09:00:37 2014
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 EA7271A01D1 for ; Tue, 21 Jan 2014 09:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.735
X-Spam-Level: 
X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] 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 YOUnfEhKNEAv for ; Tue, 21 Jan 2014 09:00:32 -0800 (PST)
Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 85B331A01AB for ; Tue, 21 Jan 2014 09:00:31 -0800 (PST)
Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 21 Jan 2014 09:00:31 -0800
From: Michelle Cotton 
To: Benoit Claise , Martin Bjorklund , "lhotka@nic.cz" 
Date: Tue, 21 Jan 2014 09:00:27 -0800
Thread-Topic: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
Thread-Index: Ac8WykocZaUA/1uDR8SmpE9Yf6Eq6Q==
Message-ID: 
References: <52D9BF28.8070103@cs.ucla.edu> <52DCE6AB.8050404@cisco.com> <3B27B723-2E59-45C6-B679-0CF298D71525@nic.cz> <20140120.103958.614685089350678258.mbj@tail-f.com> <52DCF37E.6080500@cisco.com>
In-Reply-To: <52DCF37E.6080500@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3473139627_17973714"
MIME-Version: 1.0
Cc: "sm@resistor.net" , "eggert@cs.ucla.edu" , "netmod@ietf.org" , "lear@cisco.com" , "iana-questions@iana.org" 
Subject: Re: [netmod] technical discussion around draft-ietf-netmod-iana-timezones-03
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, 21 Jan 2014 17:00:37 -0000

--B_3473139627_17973714
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I am reviewing the question below to IANA.  Hope to get you an answer
today.

--Michelle

On 1/20/14 1:59 AM, "Benoit Claise"  wrote:

>A question for IANA in line.
>> Ladislav Lhotka  wrote:
>>> On 20 Jan 2014, at 10:04, Benoit Claise  wrote:
>>>
>>>> Dear all,
>>>>
>>>> Taking into account
>>>> - that there is no canonical list of TZ time zone names (political
>>>> - reasons were mentioned)
>>>> - that the generate number solutions (from hash or coordinates) don't
>>>> - address the removal (and obsoleting) of zones.
>>>> - that I'm not too clear if IANA would support a program to generate
>>>> - this YANG module
>>>> - Lada's feedback: "The value is unused by YANG and the XML encoding,
>>>> - but is carried as a convenience to implementors.=B2
>>> In other words, I think the =B3value=B2 substatements can be safely
>>> removed from the enums, they seem to be more of a nuisance than
>>> convenience.
>> Whether the "value" statement is there or nor doesn't matter - if it
>> is not there explicitly, the enum gets an implict value, and this
>> value must not change on updates.
>>
>> But in either case, I don't see the problem with the value.
>>
>>>> I'm wondering if it doesn't make sense to:
>>>> - not ask IANA to maintain this YANG module (so removing the IANA
>>>> - considerations)
>>> +1
>>>
>>>> - express: "this document is generated from Time Zone Data v. 2013i
>>>> - (Released 2013-12-17) tzdata2013i.tar.gz (213.7kb)=B2
>>> +1
>>>
>>>> - see how the situation evolves in the couple of years.
>>>>     maybe wait for a canonical list of TZ names
>>>>     maybe update this YANG module with a new RFC in a couple of years
>>>>if
>>>>     there are many entry additions/deletions
>>> +1
>> But doesn't this effectively mean that we standardize a snapshot of
>> the (timezone names from the) TZ Database?  I assume that entries get
>> added or removed for some good reason, and we are saying that we
>> ignore that?
>
>>
>> This also doesn't solve the issue of mismatch between the YANG module
>> and the underlying system, for installations on "open" systems.
>Let me see if I get the situation right.
>I understand that we can't do a perfect job (*), so should we do an OK
>job?
>
>(*) except with a program that IANA would maintain, if I'm not mistaken.
>Michelle, is this a viable solution for you?
>
>Regards, Benoit
>>
>>
>> /martin
>> .
>>
>

--B_3473139627_17973714
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIITugYJKoZIhvcNAQcCoIITqzCCE6cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
EYYwggb2MIIF3qADAgECAhAFLoNW3qD4JhFZyohPBtNqMA0GCSqGSIb3DQEBBQUAMGIxCzAJ
BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy
dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMzAzMjAwMDAw
MDBaFw0xNjAzMjAxMjAwMDBaMIGfMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p
YTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0aW9u
IGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczENMAsGA1UECxMESUFOQTEYMBYGA1UE
AxMPTWljaGVsbGUgQ290dG9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxWwq
bCL/Xkl+g9mKzyjxA8YKyTJgMKkfuNPm2Pi5iWmUGpAHkSCUX/YKf1rninFM8JkzffVgInmx
juZQRW7lP2796RU0UAUdEsbfDcE5l4dj8h7omA2HkiwvKgxBwegr8VHjzUxOzSetAio5Y2qA
Fs7EY97BX6aulzP+tyKi5+7GSBRq+SguiLYETk4FZo8nmyK8E0210+ozwlUQ0VSfkpWluyc/
wQtRo/vQYoM0DPgVaxkE9r20ReyqaE+mxN2pqKl8qoiNMUAnbJIVUSfZhIxS4yoVKNLsOJzo
CYSrD6JgNOmzbEOfrTMWMAhh1RCqp5bcaZ4Zlq2lbrIGHzPgSwIDAQABo4IDaDCCA2QwHwYD
VR0jBBgwFoAUFQASKxOYspkH7R7for5XDStnAs0wHQYDVR0OBBYEFFcRyKFrxJAiHzozbxx0
fzjeiYmeMCQGA1UdEQQdMBuBGW1pY2hlbGxlLmNvdHRvbkBpY2Fubi5vcmcwDgYDVR0PAQH/
BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjB9BgNVHR8EdjB0MDigNqA0
hjJodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDA4
oDagNIYyaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5j
cmwwggHFBgNVHSAEggG8MIIBuDCCAbQGCmCGSAGG/WwEAQIwggGkMDoGCCsGAQUFBwIBFi5o
dHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYB
BQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQA
aQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEA
bgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAA
YQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUA
bQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAA
YQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A
IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMHcGCCsGAQUFBwEBBGswaTAkBggrBgEFBQcw
AYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMEEGCCsGAQUFBzAChjVodHRwOi8vY2FjZXJ0
cy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNydDAMBgNVHRMBAf8EAjAA
MA0GCSqGSIb3DQEBBQUAA4IBAQAzABp5GDSqoV3ty0YLFXRO8ZlHtgsLOP+5AmAS9P0mDEny
uO6xbrWK/Oi+9/UfcnYKYUGkFvukHBFLowWakQngPhHLjEhNl2QYC4dbQWLd9z4gZWBWYVzs
EreLwUSbRbE3G1r/lkUK3EYO5xAAWtFcv0I4Ixd3//0zxg0ohWW7fm22ypXr8HIBffpptim+
6oO6X55ME5789phHZZDQt6haEHyMnAQNW2SL6e8cgSL30lPcpStRCXriyXBdoSI+oW83+9u3
SvhjG9WXw8sso9oWMBWo8BhSTERNzLYbxQMazYHW5L/BUBUICTR6l3W96+rjpPZDZVpd9wgR
AG54dZ+mMIIGzTCCBbWgAwIBAgIQBv35A5YDreoACus/J7u6GzANBgkqhkiG9w0BAQUFADBl
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln
aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMDYx
MTEwMDAwMDAwWhcNMjExMTEwMDAwMDAwWjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln
aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy
dCBBc3N1cmVkIElEIENBLTEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDogi2Z
+crCQpWlgHNAcNKeVlRcqcTSQQaPyTP8TUWRXIGf7Syc+BZZ3561JBXCmLm0d0ncicQK2q/L
XmvtrbBxMevPOkAMRk2T7It6NggDqww0/hhJgv7HxzFIgHweog+SDlDJxofrNj/YMMP/pvf7
os1vcyP+rFYFkPAyIRaJxnCI+QWXfaPHQ90C6Ds97bFBo+0/vtuVSMTuHrPyvAwrmdDGXRJC
geGDboJzPyZLFJCuWWYKxI2+0s4Grq2Eb0iEm09AufFM8q+Y+/bOQF1c9qjxL6/siSLyaxhl
scFzrdfx2M8eCnRcQrhofrfVdwonVnwPYqQ/MhRglf0HBKIJAgMBAAGjggN6MIIDdjAOBgNV
HQ8BAf8EBAMCAYYwOwYDVR0lBDQwMgYIKwYBBQUHAwEGCCsGAQUFBwMCBggrBgEFBQcDAwYI
KwYBBQUHAwQGCCsGAQUFBwMIMIIB0gYDVR0gBIIByTCCAcUwggG0BgpghkgBhv1sAAEEMIIB
pDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0
b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQA
aABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMA
IABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQA
IABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIA
dAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA
YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUA
ZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjALBglghkgBhv1s
AxUwEgYDVR0TAQH/BAgwBgEB/wIBADB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0
dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGln
aWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNydDCBgQYDVR0fBHoweDA6oDig
NoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNy
bDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9v
dENBLmNybDAdBgNVHQ4EFgQUFQASKxOYspkH7R7for5XDStnAs0wHwYDVR0jBBgwFoAUReui
r/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAEZQPsm3KCSnOB22WymvUs9S
6TFHq1Zce9UNC0Gz7+x1H3Q48rJcYaKclcNQ5IK5I9G6OoZyrTh4rHVdFxc0ckeFlFbR67s2
hHfMJKXzBBlVqefj56tizfuLLZDCwNK1lL1eT7EF0g49GqkUW6aGMWKoqDPkmzmnxPXOHXh2
lCVz5Cqrz5x2S+1fwksW5EtwTACJHvzFebxMElf+X+EevAJdqP77BzhPDcZdkbkPZ0XN1oPt
55INjbFpjE/7WeAjD9KqrgB87pxCDs+R1ye3Fu4Pw718CqDuLAhVhSK46xgaTfwqIa1JMYNH
lXdx3LEbS0scEJx3FMGdTy9alQgpECYwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5
MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx
GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg
SUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYT
AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x
JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWV
MmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ
/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X
8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk
2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y
d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYE
FEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgP
MA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/M
zhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLi
l4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6
ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR
34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6
CkUvovDyMYIB/DCCAfgCAQEwdjBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQg
SW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2VydCBBc3N1
cmVkIElEIENBLTECEAUug1beoPgmEVnKiE8G02owCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJ
BDEWBBQ7KXu4rC/YAIGSi412Jque4zlygTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG
CSqGSIb3DQEJBTEPFw0xNDAxMjExNzAwMjdaMA0GCSqGSIb3DQEBAQUABIIBACRd7nVz8MW7
S2ZXccA10uOAc+RwKc+ykA4I3pSSGV6c9tY27uUh+kljrnlea1FM1RNxhKeII6RjCXdT+Pd0
DHAuPF52W9QzKIh7apzbF9vPV9IYSLUvy3HvmE3EFbMuULymFv4yeESjDEuzT9AvY5bpBerB
C4hREU0T4wjWV6S8UHxBuWciUqsRV75UV2/r0mjarqsDuKL03OxBVqfOpzRDQXVpacmugAVS
p5I279HtV5SjvxOpinfoeayKaKdU1Jz7Yu4NEpqp0RF4Gt6tMCq90kdSPYvOKeNiaMMUsyjl
XRjdxUxcCTUO3HTbtsvcz99fimWUHeEA0hYHEGIqqog=

--B_3473139627_17973714--

From randy_presuhn@mindspring.com  Tue Jan 21 09:35:54 2014
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 D25CC1A0426 for ; Tue, 21 Jan 2014 09:35:54 -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_40=-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 isbaRY_1AKvc for ; Tue, 21 Jan 2014 09:35:52 -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 AE0271A03E5 for ; Tue, 21 Jan 2014 09:35:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=t0JnPILIK1HSZ66q8I7Y2fwy6+ec0WUZGPm5SZQmja7pQGJvUOr/5eH7B6jL3xaI; 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-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W5fEu-0004DO-6r for netmod@ietf.org; Tue, 21 Jan 2014 12:35:52 -0500
Received: from 99.23.160.218 by webmail.earthlink.net with HTTP; Tue, 21 Jan 2014 12:35:51 -0500
Message-ID: <7139720.1390325752026.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
Date: Tue, 21 Jan 2014 09:35:51 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbc94f1bdce0bc0d5fe8494cd5d7f944bfd350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.36
Subject: Re: [netmod] enumeration type
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, 21 Jan 2014 17:35:55 -0000

Hi -

>From: Andy Bierman 
>Sent: Jan 21, 2014 6:46 AM
>To: Jernej Tuljak 
>Cc: "netmod@ietf.org" 
>Subject: Re: [netmod] enumeration type
...
>I do not understand all this fuss over a field used just
>for documentation.  The value field is not used
>in the protocol.  It is not referenced in any other
>YANG statement.

Which leads to the question: why does the value
field even exist?

>I thought the auto-assignment procedure was clear
>when I implemented it.

The problem is that there are two reasonable interpretations
of the text, and, depending on which interpretation was used
in constructing an implementation, the same module may or may
not produce an error.  That's not interoperable.

Randy

From j.schoenwaelder@jacobs-university.de  Tue Jan 21 09:56:15 2014
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 3CECD1A01D7 for ; Tue, 21 Jan 2014 09:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 conf9pUjk9tE for ; Tue, 21 Jan 2014 09:56:13 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 242181A018E for ; Tue, 21 Jan 2014 09:56:12 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 445D12007C; Tue, 21 Jan 2014 18:56:12 +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 fZ1GXV85_SrC; Tue, 21 Jan 2014 18:56:12 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1B5220070; Tue, 21 Jan 2014 18:56:11 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id D71E72AC3CB9; Tue, 21 Jan 2014 18:56:08 +0100 (CET)
Date: Tue, 21 Jan 2014 18:56:08 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20140121175608.GB48434@elstar.local>
Mail-Followup-To: Andy Bierman , Jonathan Hansford , "netmod@ietf.org" 
References: <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>  <53eb7125803729d92a23665c0f0396ff@imap.plus.net>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration type
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, 21 Jan 2014 17:56:15 -0000

On Tue, Jan 21, 2014 at 08:42:54AM -0800, Andy Bierman wrote:
> Hi,
> 
> Jonathan, you are right -- the rules are not obvious.
> Our code does not implement the rules I specified.
> It uses the next highest value assigned:
> 
>   leaf enum-test {
>     type enumeration {
>        enum seven { value 7; }
>        enum eight;  // value 8
>        enum nine;  // value 9
>        enum four { value 4; }
>        enum ten;   // value 10, not 5
>        enum eleven;   // value 11, not 6
>     }
>   }
> 

In C, ten would be 5 and eleven would be 6. I believe we reduce the
number of surprises if we follow C semantics (and as far as I recall
that was the original idea as well). I think "current highest value"
really was meant to be "the last value (in the order of enum
definition)".

Note that we have similar text in section 9.7.4.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 tnadeau@lucidvision.com  Tue Jan 21 11:53:50 2014
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 4417C1A0213 for ; Tue, 21 Jan 2014 11:53:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 K-AaU5pNwHs3 for ; Tue, 21 Jan 2014 11:53:48 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB111A014D for ; Tue, 21 Jan 2014 11:53:48 -0800 (PST)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 0406A26C1392; Tue, 21 Jan 2014 14:53:47 -0500 (EST)
From: Thomas Nadeau 
Content-Type: multipart/signed; boundary="Apple-Mail=_2FB7D559-5F4D-40A6-99A6-2CAFDF286CB9"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Tue, 21 Jan 2014 14:53:47 -0500
Message-Id: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>
To: netmod@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Cc: netmod-chairs@tools.ietf.org
Subject: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 21 Jan 2014 19:53:50 -0000

--Apple-Mail=_2FB7D559-5F4D-40A6-99A6-2CAFDF286CB9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	Netmod WG:

	The working group chairs have considered the discussion =
concerning=20
the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
draft-ietf-netmod-iana-timezones-03. In particular, we would like
like to call consensus on the matter regarding that surfaced during
the IETF last call with regard to the the practicability of maintaining =
a=20
YANG module with an enumeration of timezone names. We believe there is
consensus in the working group to move forward with the following=20
resolution:

- The YANG module in draft-ietf-netmod-system-mgmt-11 gets
extended to introduce a new typedef for timezone names, e.g.
something that looks like:

  typedef timezone-name {
    type string;
    description
     "A timezone name as used by the Time Zone Database, sometimes
      referred to as the 'Olson Database'.";
    reference
     "RFC 6557: Procedures for Maintaining the Time Zone Database";
  }

The timezone-location leaf will be changed to use this type,
the import of iana-timezones will be removed and the references
to I-D.ietf-netmod-iana-timezones will be removed.

- The draft-ietf-netmod-iana-timezones-00 document will be pulled
back and work on this draft will stop.  The I-D is declared dead.

- Since there is nothing to do for IANA, there will be no IANA request=20=

needed in this regard for draft-ietf-netmod-system-mgmt-11.=20

	We note that further alternatives can be added to the timezone
choice in the future should the two mechanisms currently in place
turn out to be insufficient in practice.

	We would like to give the WG sufficient time to raise any =
additional concerns or=20
issues with regard to this issue and our path for resolving the issue at =
hand, and so we=20
will accept comments/discussion on this matter until 8AM EDT on Tuesday, =
January 28, 2014.
As Juergen has been closely involved with the matter, I will adjudicate =
any issues
arising from this comment period.

	Thanks,

	Tom





--Apple-Mail=_2FB7D559-5F4D-40A6-99A6-2CAFDF286CB9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS3tBLAAoJEPcO+I7eiUJZ8AEQAIs9VwjZIDrVcfv59/z8mkaJ
urtdVBr/4ywsWJzCPI6gwMW6SngqErtDpdcGbq0gIpuCggivNqL0jpV9mAzmj5LU
ooORLN/Fq1d+azqU1beV+Tz+Vw2uwTbJ9TDIYJcH64y3jz5tYmwqYTyfT2/SNgSG
rY3mOjBTWzZWMoDVvLnHotjgvIdQ/3bi4C9gxEM2B8S16US3cM2EqDBfLRHCWzW0
GBFu08LCrC8alNXsJdsN6TD83+AOI5waz16Ys/H6YTmAqfyqF01b52Pxs+sofxmy
iE3dkGgNU8hcAut3ds3OclvlGNRDCLPhpUE3lxdcDzUyFiTZT4yrRrwwzzOnabaR
TOvFGbDPYQeSgt1QPokINqEdnyDeGtoy0C7I6E7p8/hu/kdg4Pl8YOdQSoA9PEyx
53zqJXLUmHDYS2P/gXd69JCONamNf+rVchcD6sFgGw+zMttVedHF6NLCEWqDX8Vf
YhgcIuGVImoBw/LuMwzcyrKylEePZxGXTdPsMBPcVAKqDI4B4ZSflOx8w6JrqYcf
OkG4yUemLTUhaQI5wIIAHsh3tCdwYR66sryoBoF5buU+Hngv/rgCdMw26NKmKPuV
hfzhEygvGAOvzP72TYtQAw+iyzT1l6S8lAmkhS+3i/dPyNKUmT+acNQ2QeExWknW
jNDr5MMPh5cRFY2DHmIS
=+xWE
-----END PGP SIGNATURE-----

--Apple-Mail=_2FB7D559-5F4D-40A6-99A6-2CAFDF286CB9--

From jeffrey.K.lange@ge.com  Tue Jan 21 12:25:42 2014
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 E944A1A01B4 for ; Tue, 21 Jan 2014 12:25:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 mxcCym7Khit7 for ; Tue, 21 Jan 2014 12:25:40 -0800 (PST)
Received: from exprod5og112.obsmtp.com (exprod5og112.obsmtp.com [64.18.0.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB0C1A0166 for ; Tue, 21 Jan 2014 12:25:40 -0800 (PST)
Received: from cinmlip10.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob112.postini.com ([64.18.4.12]) with SMTP ID DSNKUt7XxIvVlaPJwrVUrXiYEErUTRV+u5Zr@postini.com; Tue, 21 Jan 2014 12:25:40 PST
Received: from unknown (HELO CINMBHT02.e2k.ad.ge.com) ([3.159.212.195]) by cinmlip10.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 21 Jan 2014 15:30:54 -0500
Received: from ALPURTP02.e2k.ad.ge.com (3.159.16.201) by CINMBHT02.e2k.ad.ge.com (3.159.212.195) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 21 Jan 2014 15:25:38 -0500
Received: from CINURAPD02.e2k.ad.ge.com (3.159.212.110) by ALPURTP02.e2k.ad.ge.com (3.159.16.201) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 21 Jan 2014 15:25:38 -0500
Received: from CINURCNA15.e2k.ad.ge.com ([169.254.3.132]) by CINURAPD02.e2k.ad.ge.com ([169.254.8.5]) with mapi id 14.03.0174.001; Tue, 21 Jan 2014 15:25:37 -0500
From: "Lange, Jeffrey K (GE Energy Management)" 
To: Thomas Nadeau , "netmod@ietf.org" 
Thread-Topic: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
Thread-Index: AQHPFubxOdhtTr8sSUit2/4oQBk1SQ==
Date: Tue, 21 Jan 2014 20:25:37 +0000
Message-ID: 
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>
In-Reply-To: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [3.159.212.181]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netmod-chairs@tools.ietf.org" 
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 21 Jan 2014 20:25:43 -0000

On 1/21/14, 2:53 PM, "Thomas Nadeau"  wrote:

>
>	Netmod WG:
>
>	The working group chairs have considered the discussion concerning
>the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
>draft-ietf-netmod-iana-timezones-03. In particular, we would like
>like to call consensus on the matter regarding that surfaced during
>the IETF last call with regard to the the practicability of maintaining a
>YANG module with an enumeration of timezone names. We believe there is
>consensus in the working group to move forward with the following
>resolution:
>
>- The YANG module in draft-ietf-netmod-system-mgmt-11 gets
>extended to introduce a new typedef for timezone names, e.g.
>something that looks like:
>
>  typedef timezone-name {
>    type string;
>    description
>     "A timezone name as used by the Time Zone Database, sometimes
>      referred to as the 'Olson Database'.";
>    reference
>     "RFC 6557: Procedures for Maintaining the Time Zone Database";
>  }
>
>The timezone-location leaf will be changed to use this type,
>the import of iana-timezones will be removed and the references
>to I-D.ietf-netmod-iana-timezones will be removed.
>
>- The draft-ietf-netmod-iana-timezones-00 document will be pulled
>back and work on this draft will stop.  The I-D is declared dead.

I support this proposal.

 At some point in the conversation there was also the possibility of
having a config false list of the valid strings that a particular server
supports.  I think this is useful from a usability point of view. This
would be wrapped in a "if-feature timezone-location=B2 clause like the
config true leaf. Was there general interest in this? Or was it more of a
passing comment?

-Jeff


>
>- Since there is nothing to do for IANA, there will be no IANA request
>needed in this regard for draft-ietf-netmod-system-mgmt-11.
>
>	We note that further alternatives can be added to the timezone
>choice in the future should the two mechanisms currently in place
>turn out to be insufficient in practice.
>
>	We would like to give the WG sufficient time to raise any additional
>concerns or=20
>issues with regard to this issue and our path for resolving the issue at
>hand, and so we=20
>will accept comments/discussion on this matter until 8AM EDT on Tuesday,
>January 28, 2014.
>As Juergen has been closely involved with the matter, I will adjudicate
>any issues
>arising from this comment period.
>
>	Thanks,
>
>	Tom
>
>
>
>


From per@tail-f.com  Tue Jan 21 15:03:29 2014
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 1E9C91A01D7 for ; Tue, 21 Jan 2014 15:03:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 al8ozXL8mXDb for ; Tue, 21 Jan 2014 15:03:26 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 511CC1A0232 for ; Tue, 21 Jan 2014 15:03:26 -0800 (PST)
Received: from pluto.hedeland.org (h71n2-hy-d5.ias.bredband.telia.com [213.65.153.71]) by mail.tail-f.com (Postfix) with ESMTPSA id 3F48B37C127; Wed, 22 Jan 2014 00:03:25 +0100 (CET)
Message-ID: <52DEFCBC.3050202@tail-f.com>
Date: Wed, 22 Jan 2014 00:03:24 +0100
From: Per Hedeland 
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5
MIME-Version: 1.0
To: Andy Bierman ,  Jonathan Hansford , "netmod@ietf.org" 
References: <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>  <53eb7125803729d92a23665c0f0396ff@imap.plus.net>   <20140121175608.GB48434@elstar.local>
In-Reply-To: <20140121175608.GB48434@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] enumeration 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: Tue, 21 Jan 2014 23:03:29 -0000

On 2014-01-21 18:56, Juergen Schoenwaelder wrote:
> On Tue, Jan 21, 2014 at 08:42:54AM -0800, Andy Bierman wrote:
>> Hi,
>>
>> Jonathan, you are right -- the rules are not obvious.
>> Our code does not implement the rules I specified.
>> It uses the next highest value assigned:
>>
>>   leaf enum-test {
>>     type enumeration {
>>        enum seven { value 7; }
>>        enum eight;  // value 8
>>        enum nine;  // value 9
>>        enum four { value 4; }
>>        enum ten;   // value 10, not 5
>>        enum eleven;   // value 11, not 6
>>     }
>>   }
>>
> 
> In C, ten would be 5 and eleven would be 6.

And if you added twelve at the end, it would be 7 just like seven - C
doesn't care, but in YANG it would be an error, and you would either be
required to give a value statement for such cases too (and not just for
the MAXINT case explicitly spelled out in 6020), or the compiler would
have to find an unused value instead of just always using highest + 1
for auto-assignment (quite doable of course, but it's definitely not
what 6020 says).

> I believe we reduce the
> number of surprises if we follow C semantics (and as far as I recall
> that was the original idea as well). I think "current highest value"
> really was meant to be "the last value (in the order of enum
> definition)".

I seriously doubt that, given the above - the other parts of the text
don't match. And so far I don't think we've heard of any implementation
doing that (pyang also does the assignment that Andy listed), so I think
it really would have to be considered a changed specification.

> Note that we have similar text in section 9.7.4.2.

Yes, it could also use clarification of "current highest".

--Per

From andy@yumaworks.com  Tue Jan 21 17:41:59 2014
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 3A1F51A01B8 for ; Tue, 21 Jan 2014 17:41:59 -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 kEdyO1WuYo8W for ; Tue, 21 Jan 2014 17:41:57 -0800 (PST)
Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id AC9EB1A027D for ; Tue, 21 Jan 2014 17:41:56 -0800 (PST)
Received: by mail-qc0-f178.google.com with SMTP id m20so8172111qcx.9 for ; Tue, 21 Jan 2014 17:41:56 -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=Ef5WPhS7CR3bHNnDiL0uQv8HZbfp2KbcQ+6JZ9IPMO8=; b=ZanE4Odk+44dOaz6S7cBpFCmJDNfZTRbNxIW+ixjBWgV689kWYnJ7elCGTF+FnMokm 6zBdKx7Gtfl3odQLw4X3UZPo9ali283c12uggTWdTKmyME5LLkh+Au9rPZ9OgISRBQzx wiZY6gvQ4Jiqyc902DGDC1UKATUnqJ+85EI4zGUWBTimhCHBvRy+kNygKMm0Fc0ZFKva GuRMr2Z+e00HxsoM29VpXBpCwnhTdkMT6PZ8J/bJmjSO4Qqj1EwvqaUH5UoO1eyatPS4 vK327gQf+WYMOG26QmvciU2MLcptGZhbUjztjIt/4wKWr/5XeTueWFEfl3nWUVhlb7f5 jgyg==
X-Gm-Message-State: ALoCoQkBhvXrSCLhfAjy7ghxqcwAqMM7wntX29sMZ1tKCoOe22lrwXSmKffazHBrXPEibGWIgSRS
MIME-Version: 1.0
X-Received: by 10.229.194.1 with SMTP id dw1mr42451918qcb.20.1390354916183; Tue, 21 Jan 2014 17:41:56 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 21 Jan 2014 17:41:56 -0800 (PST)
In-Reply-To: <52DEFCBC.3050202@tail-f.com>
References: <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>  <53eb7125803729d92a23665c0f0396ff@imap.plus.net>   <20140121175608.GB48434@elstar.local> <52DEFCBC.3050202@tail-f.com>
Date: Tue, 21 Jan 2014 17:41:56 -0800
Message-ID: 
From: Andy Bierman 
To: Per Hedeland 
Content-Type: multipart/alternative; boundary=001a11c2c736e42b9004f0853a74
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 01:41:59 -0000

--001a11c2c736e42b9004f0853a74
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 21, 2014 at 3:03 PM, Per Hedeland  wrote:

> On 2014-01-21 18:56, Juergen Schoenwaelder wrote:
> > On Tue, Jan 21, 2014 at 08:42:54AM -0800, Andy Bierman wrote:
> >> Hi,
> >>
> >> Jonathan, you are right -- the rules are not obvious.
> >> Our code does not implement the rules I specified.
> >> It uses the next highest value assigned:
> >>
> >>   leaf enum-test {
> >>     type enumeration {
> >>        enum seven { value 7; }
> >>        enum eight;  // value 8
> >>        enum nine;  // value 9
> >>        enum four { value 4; }
> >>        enum ten;   // value 10, not 5
> >>        enum eleven;   // value 11, not 6
> >>     }
> >>   }
> >>
> >
> > In C, ten would be 5 and eleven would be 6.
>
> And if you added twelve at the end, it would be 7 just like seven - C
> doesn't care, but in YANG it would be an error, and you would either be
> required to give a value statement for such cases too (and not just for
> the MAXINT case explicitly spelled out in 6020), or the compiler would
> have to find an unused value instead of just always using highest + 1
> for auto-assignment (quite doable of course, but it's definitely not
> what 6020 says).
>
> > I believe we reduce the
> > number of surprises if we follow C semantics (and as far as I recall
> > that was the original idea as well). I think "current highest value"
> > really was meant to be "the last value (in the order of enum
> > definition)".
>
> I seriously doubt that, given the above - the other parts of the text
> don't match. And so far I don't think we've heard of any implementation
> doing that (pyang also does the assignment that Andy listed), so I think
> it really would have to be considered a changed specification.
>
> > Note that we have similar text in section 9.7.4.2.
>
> Yes, it could also use clarification of "current highest".
>
>
I agree we should not change the behavior now.

The "max value" corner case is not really clear either.

   leaf max-enum-test {
      type enumeration {
         enum max { value 2147483647; }
         enum pick1;
         enum pick2;
         enum minus1 { value -1; }
       }
     }

The compiler is supposed to assign unused values for pick1 and pick2.
Is the compiler supposed to avoid assigning -1 or is the minus1 enum
an error (if -1 happened to be selected for pick1 or pick2).




> --Per
>

Andy

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





On Tue, Jan 21, 2014 at 3:03 PM, Per Hedeland <=
;per@tail-f.com>=
 wrote:


On 2014-01-21 18:56, Juergen Schoenwaelder wrote:

> On Tue, Jan 21, 2014 at 08:42:54AM -0800, Andy Bierman wrote:

>> Hi,

>>

>> Jonathan, you are right -- the rules are not obvious.

>> Our code does not implement the rules I specified.

>> It uses the next highest value assigned:

>>

>> =A0 leaf enum-test {

>> =A0 =A0 type enumeration {

>> =A0 =A0 =A0 =A0enum seven { value 7; }

>> =A0 =A0 =A0 =A0enum eight; =A0// value 8

>> =A0 =A0 =A0 =A0enum nine; =A0// value 9

>> =A0 =A0 =A0 =A0enum four { value 4; }

>> =A0 =A0 =A0 =A0enum ten; =A0 // value 10, not 5

>> =A0 =A0 =A0 =A0enum eleven; =A0 // value 11, not 6

>> =A0 =A0 }

>> =A0 }

>>

>

> In C, ten would be 5 and eleven would be 6.



And if you added twelve at the end, it would be 7 just like seven - C

doesn't care, but in YANG it would be an error, and you would either be=


required to give a value statement for such cases too (and not just for

the MAXINT case explicitly spelled out in 6020), or the compiler would

have to find an unused value instead of just always using highest + 1

for auto-assignment (quite doable of course, but it's definitely not
what 6020 says).



> I believe we reduce the

> number of surprises if we follow C semantics (and as far as I recall
> that was the original idea as well). I think "current highest val=
ue"

> really was meant to be "the last value (in the order of enum

> definition)".



I seriously doubt that, given the above - the other parts of the text

don't match. And so far I don't think we've heard of any implem=
entation

doing that (pyang also does the assignment that Andy listed), so I think
it really would have to be considered a changed specification.



> Note that we have similar text in section 9.7.4.2.



Yes, it could also use clarification of "current highest".



I agree we should not change the behavior now.
<=
br>
The "max value" corner case is not really clear eit=
her.



=A0 =A0leaf max-enum-test {
=A0 =A0 =A0 =
type enumeration {
=A0 =A0 =A0 =A0 =A0enum max { value 2147483647=
; }
=A0 =A0 =A0 =A0 =A0enum pick1;
=A0 =A0 =A0 =A0 =A0e=
num pick2;
=A0 =A0 =A0 =A0 =A0enum minus1 { value -1; }


=A0 =A0 =A0 =A0}
=A0 =A0 =A0}

The compiler is supposed to assign unused values for pick1 and pick2.
Is the compiler supposed to avoid assigning -1 or is the minus1 enum<=
/div>

an error (if -1 happened to be selected for pick1 or pick2).

=


=A0


--Per



Andy<=
/div>



--001a11c2c736e42b9004f0853a74--

From per@tail-f.com  Tue Jan 21 23:15:34 2014
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 780841A02B5 for ; Tue, 21 Jan 2014 23:15:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 BR-jHUOqxAZz for ; Tue, 21 Jan 2014 23:15:29 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 26CF31A02A1 for ; Tue, 21 Jan 2014 23:15:29 -0800 (PST)
Received: from pluto.hedeland.org (h71n2-hy-d5.ias.bredband.telia.com [213.65.153.71]) by mail.tail-f.com (Postfix) with ESMTPSA id 607CA240C1B4; Wed, 22 Jan 2014 08:15:27 +0100 (CET)
Message-ID: <52DF700F.1090304@tail-f.com>
Date: Wed, 22 Jan 2014 08:15:27 +0100
From: Per Hedeland 
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5
MIME-Version: 1.0
To: Andy Bierman 
References: <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>  <53eb7125803729d92a23665c0f0396ff@imap.plus.net>   <20140121175608.GB48434@elstar.local> <52DEFCBC.3050202@tail-f.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 07:15:34 -0000

On 2014-01-22 02:41, Andy Bierman wrote:
> On Tue, Jan 21, 2014 at 3:03 PM, Per Hedeland  wrote:
> 
>> On 2014-01-21 18:56, Juergen Schoenwaelder wrote:
>>> On Tue, Jan 21, 2014 at 08:42:54AM -0800, Andy Bierman wrote:
>>>> Hi,
>>>>
>>>> Jonathan, you are right -- the rules are not obvious.
>>>> Our code does not implement the rules I specified.
>>>> It uses the next highest value assigned:
>>>>
>>>>   leaf enum-test {
>>>>     type enumeration {
>>>>        enum seven { value 7; }
>>>>        enum eight;  // value 8
>>>>        enum nine;  // value 9
>>>>        enum four { value 4; }
>>>>        enum ten;   // value 10, not 5
>>>>        enum eleven;   // value 11, not 6
>>>>     }
>>>>   }
>>>>
>>>
>>> In C, ten would be 5 and eleven would be 6.
>>
>> And if you added twelve at the end, it would be 7 just like seven - C
>> doesn't care, but in YANG it would be an error, and you would either be
>> required to give a value statement for such cases too (and not just for
>> the MAXINT case explicitly spelled out in 6020), or the compiler would
>> have to find an unused value instead of just always using highest + 1
>> for auto-assignment (quite doable of course, but it's definitely not
>> what 6020 says).
>>
>>> I believe we reduce the
>>> number of surprises if we follow C semantics (and as far as I recall
>>> that was the original idea as well). I think "current highest value"
>>> really was meant to be "the last value (in the order of enum
>>> definition)".
>>
>> I seriously doubt that, given the above - the other parts of the text
>> don't match. And so far I don't think we've heard of any implementation
>> doing that (pyang also does the assignment that Andy listed), so I think
>> it really would have to be considered a changed specification.
>>
>>> Note that we have similar text in section 9.7.4.2.
>>
>> Yes, it could also use clarification of "current highest".
>>
>>
> I agree we should not change the behavior now.
> 
> The "max value" corner case is not really clear either.

If we use the common interpretation of "current highest value", I can't
see that it is unclear.

>    leaf max-enum-test {
>       type enumeration {
>          enum max { value 2147483647; }
>          enum pick1;
>          enum pick2;
>          enum minus1 { value -1; }
>        }
>      }
> 
> The compiler is supposed to assign unused values for pick1 and pick2.

No, why do you think so? 6020 says:

   If the current highest value is equal to 2147483647, then an enum
   value MUST be specified for "enum" substatements following the one
   with the current highest value.

I.e. in this corner-case, you are required to *specify* values for pick1
and pick2 - the auto-assignment isn't expected to handle it. pyang just
folds this requirement into the <= MAXINT check:

enum.yang:8: error: the enumeration value "2147483648" is not an 32 bit integer
enum.yang:9: error: the enumeration value "2147483649" is not an 32 bit integer

- which is OK I guess.

> Is the compiler supposed to avoid assigning -1 or is the minus1 enum
> an error (if -1 happened to be selected for pick1 or pick2).

So this doesn't apply - but something similar will happen with

    type enumeration {
      enum zero; // value 0
      enum two { value 2; }
      enum one { value 1; }
      enum three; // value 3
      enum four { value 3; }
    }

pyang says:

enum.yang:11: error: the integer value "3" has already been used for the enumeration at enum.yang:10

Again, with the common interpretation of "current highest value", there
is nothing unclear - the compiler never needs to look-ahead for
specified values, auto-assignment always uses highest + 1 - and the
module writer needs to take that into account when mixing enums with and
without specified values (e.g. by reordering the enum statements in the
probably unlikely case that there is a clash and the specified value is
important - putting all those with specified values before those without
will always work, as long as the (even less likely-to-be-a-problem)
MAXINT rule is also observed).

--Per

From jernej.tuljak@mg-soft.si  Tue Jan 21 23:16:11 2014
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 4DF221A02BC for ; Tue, 21 Jan 2014 23:16:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.834
X-Spam-Level: 
X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535] 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 INaJ7SuN5F55 for ; Tue, 21 Jan 2014 23:16:03 -0800 (PST)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 28E7B1A02A1 for ; Tue, 21 Jan 2014 23:16:02 -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 s0M7G1c5018006; Wed, 22 Jan 2014 08:16:01 +0100
Message-ID: <52DF702D.2070007@mg-soft.com>
Date: Wed, 22 Jan 2014 08:15:57 +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: Andy Bierman 
References: <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>  <53eb7125803729d92a23665c0f0396ff@imap.plus.net>   <20140121175608.GB48434@elstar.local> <52DEFCBC.3050202@tail-f.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030201070100010909070204"
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 07:16:11 -0000

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

Dne 22.1.2014 2:41, pis(e Andy Bierman:
>
>
>
> On Tue, Jan 21, 2014 at 3:03 PM, Per Hedeland  > wrote:
>
>     On 2014-01-21 18:56, Juergen Schoenwaelder wrote:
>     > On Tue, Jan 21, 2014 at 08:42:54AM -0800, Andy Bierman wrote:
>     >> Hi,
>     >>
>     >> Jonathan, you are right -- the rules are not obvious.
>     >> Our code does not implement the rules I specified.
>     >> It uses the next highest value assigned:
>     >>
>     >>   leaf enum-test {
>     >>     type enumeration {
>     >>        enum seven { value 7; }
>     >>        enum eight;  // value 8
>     >>        enum nine;  // value 9
>     >>        enum four { value 4; }
>     >>        enum ten;   // value 10, not 5
>     >>        enum eleven;   // value 11, not 6
>     >>     }
>     >>   }
>     >>
>     >
>     > In C, ten would be 5 and eleven would be 6.
>
>     And if you added twelve at the end, it would be 7 just like seven - C
>     doesn't care, but in YANG it would be an error, and you would
>     either be
>     required to give a value statement for such cases too (and not
>     just for
>     the MAXINT case explicitly spelled out in 6020), or the compiler would
>     have to find an unused value instead of just always using highest + 1
>     for auto-assignment (quite doable of course, but it's definitely not
>     what 6020 says).
>
>     > I believe we reduce the
>     > number of surprises if we follow C semantics (and as far as I recall
>     > that was the original idea as well). I think "current highest value"
>     > really was meant to be "the last value (in the order of enum
>     > definition)".
>
>     I seriously doubt that, given the above - the other parts of the text
>     don't match. And so far I don't think we've heard of any
>     implementation
>     doing that (pyang also does the assignment that Andy listed), so I
>     think
>     it really would have to be considered a changed specification.
>
>     > Note that we have similar text in section 9.7.4.2.
>
>     Yes, it could also use clarification of "current highest".
>
>
> I agree we should not change the behavior now.
>
> The "max value" corner case is not really clear either.
>
>    leaf max-enum-test {
>       type enumeration {
>          enum max { value 2147483647; }
>          enum pick1;
>          enum pick2;
>          enum minus1 { value -1; }
>        }
>      }
>
> The compiler is supposed to assign unused values for pick1 and pick2.
> Is the compiler supposed to avoid assigning -1 or is the minus1 enum
> an error (if -1 happened to be selected for pick1 or pick2).
>
>

    If the current highest value is equal to 2147483647, then an enum
    value MUST be specified for "enum" substatements following the one
    with the current highest value.

Your example violates this MUST before you even get to "minus1". After 
max is reached, all enums must have explicit value substatements. So 
it's an error, but not the one you were wondering about.

I'd also like to point out, that this auto assignment issue also applies 
to bit's position substatement.

Jernej

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


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


  
    
  
  
    
Dne 22.1.2014 2:41, piše Andy Bierman:

    

    

      


        


          

          
On Tue, Jan 21, 2014 at 3:03 PM, Per
            Hedeland <per@tail-f.com>
            wrote:

            
On
              2014-01-21 18:56, Juergen Schoenwaelder wrote:

              > On Tue, Jan 21, 2014 at 08:42:54AM -0800, Andy
              Bierman wrote:

              >> Hi,

              >>

              >> Jonathan, you are right -- the rules are not
              obvious.

              >> Our code does not implement the rules I
              specified.

              >> It uses the next highest value assigned:

              >>

              >>   leaf enum-test {

              >>     type enumeration {

              >>        enum seven { value 7; }

              >>        enum eight;  // value 8

              >>        enum nine;  // value 9

              >>        enum four { value 4; }

              >>        enum ten;   // value 10, not 5

              >>        enum eleven;   // value 11, not 6

              >>     }

              >>   }

              >>

              >

              > In C, ten would be 5 and eleven would be 6.

              

              And if you added twelve at the end, it would be 7 just
              like seven - C

              doesn't care, but in YANG it would be an error, and you
              would either be

              required to give a value statement for such cases too (and
              not just for

              the MAXINT case explicitly spelled out in 6020), or the
              compiler would

              have to find an unused value instead of just always using
              highest + 1

              for auto-assignment (quite doable of course, but it's
              definitely not

              what 6020 says).

              

              > I believe we reduce the

              > number of surprises if we follow C semantics (and as
              far as I recall

              > that was the original idea as well). I think "current
              highest value"

              > really was meant to be "the last value (in the order
              of enum

              > definition)".

              

              I seriously doubt that, given the above - the other parts
              of the text

              don't match. And so far I don't think we've heard of any
              implementation

              doing that (pyang also does the assignment that Andy
              listed), so I think

              it really would have to be considered a changed
              specification.

              

              > Note that we have similar text in section 9.7.4.2.

              

              Yes, it could also use clarification of "current highest".

              

                

            


            

            
I agree we should not change the behavior now.

            


            

            
The "max value" corner case is not really clear either.

            


            

            

              
   leaf max-enum-test {

              
      type enumeration {

              
         enum max { value 2147483647; }

              
         enum pick1;

              
         enum pick2;

              
         enum minus1 { value -1; }

              
       }

              
     }

            

            


            

            
The compiler is supposed to assign unused values for
              pick1 and pick2.

            
Is the compiler supposed to avoid assigning -1 or is
              the minus1 enum

            

              an error (if -1 happened to be selected for pick1 or
              pick2).

            


            

            


            

          

        

      

    

    

    
   If the current highest value is equal to 2147483647, then an enum
   value MUST be specified for "enum" substatements following the one
   with the current highest value.

    Your example violates this MUST before you even get to "minus1".
    After max is reached, all enums must have explicit value
    substatements. So it's an error, but not the one you were wondering
    about.

    

    I'd also like to point out, that this auto assignment issue also
    applies to bit's position substatement.

    

    Jernej

    

    

      

        

          

            
 

            

                  --Per

                

          

          

        

        
Andy

        


        

      

      

      

      

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


    

    

  


--------------030201070100010909070204--

From bclaise@cisco.com  Wed Jan 22 00:50:44 2014
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 E2B8A1A0379 for ; Wed, 22 Jan 2014 00:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.035
X-Spam-Level: 
X-Spam-Status: No, score=-10.035 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.535, 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 kQ4rsSbKLF8H for ; Wed, 22 Jan 2014 00:50:42 -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 4BD081A02BB for ; Wed, 22 Jan 2014 00:50:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6228; q=dns/txt; s=iport; t=1390380641; x=1391590241; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=bdek0q+kUOc7kVmmIfSEy9PgjeGhoz8Lw10pmL22XRE=; b=CQoKU4arhFMux1+WCnPixRjuh9+6AGJZ4EYAmB6nrWfoPGjRTgklHHEr RJmVFUvanKYLdKbmWvEfaA22lVDvnvmBfUIn0uKhekxa2AoJEQ7A9bjvE 1JZLwNd5PfxVzbyh0eEFWrRnflpdkVnIN7gtfb5gqbygTRzQBRajFKxFK k=;
X-IronPort-AV: E=Sophos;i="4.95,698,1384300800"; d="scan'208,217";a="3327377"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 22 Jan 2014 08:50:40 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0M8odiZ015147; Wed, 22 Jan 2014 08:50:39 GMT
Message-ID: <52DF865F.3020006@cisco.com>
Date: Wed, 22 Jan 2014 09:50:39 +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: Thomas Nadeau , netmod@ietf.org
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>
In-Reply-To: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>
Content-Type: multipart/alternative; boundary="------------080602030505070605060507"
Cc: netmod-chairs@tools.ietf.org, Eliot Lear , Paul Eggert 
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 22 Jan 2014 08:50:45 -0000

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

Tom,
> 	Netmod WG:
>
> 	The working group chairs have considered the discussion concerning
> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
> draft-ietf-netmod-iana-timezones-03. In particular, we would like
> like to call consensus on the matter regarding that surfaced during
> the IETF last call with regard to the the practicability of maintaining a
> YANG module with an enumeration of timezone names. We believe there is
> consensus in the working group to move forward with the following
> resolution:
>
> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets
> extended to introduce a new typedef for timezone names, e.g.
> something that looks like:
>
>    typedef timezone-name {
>      type string;
>      description
>       "A timezone name as used by the Time Zone Database, sometimes
>        referred to as the 'Olson Database'.";
>      reference
>       "RFC 6557: Procedures for Maintaining the Time Zone Database";
>    }
>
> The timezone-location leaf will be changed to use this type,
> the import of iana-timezones will be removed and the references
> to I-D.ietf-netmod-iana-timezones will be removed.
>
> - The draft-ietf-netmod-iana-timezones-00 document will be pulled
> back and work on this draft will stop.  The I-D is declared dead.
>
> - Since there is nothing to do for IANA, there will be no IANA request
> needed in this regard for draft-ietf-netmod-system-mgmt-11.
I'm unclear on what's happening when a timezone name is added, removed, 
modified in the Time Zone Database.
Or maybe the assumption is that the typedef is always up to date with 
the latest version of the Time Zone Database, on the NETCONF client and 
server?
I believe It needs a little bit of explanation.

Regards, Benoit
>
> 	We note that further alternatives can be added to the timezone
> choice in the future should the two mechanisms currently in place
> turn out to be insufficient in practice.
>
> 	We would like to give the WG sufficient time to raise any additional concerns or
> issues with regard to this issue and our path for resolving the issue at hand, and so we
> will accept comments/discussion on this matter until 8AM EDT on Tuesday, January 28, 2014.
> As Juergen has been closely involved with the matter, I will adjudicate any issues
> arising from this comment period.
>
> 	Thanks,
>
> 	Tom
>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    
Tom,

    

    

      
	Netmod WG:

	The working group chairs have considered the discussion concerning 
the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
draft-ietf-netmod-iana-timezones-03. In particular, we would like
like to call consensus on the matter regarding that surfaced during
the IETF last call with regard to the the practicability of maintaining a 
YANG module with an enumeration of timezone names. We believe there is
consensus in the working group to move forward with the following 
resolution:

- The YANG module in draft-ietf-netmod-system-mgmt-11 gets
extended to introduce a new typedef for timezone names, e.g.
something that looks like:

  typedef timezone-name {
    type string;
    description
     "A timezone name as used by the Time Zone Database, sometimes
      referred to as the 'Olson Database'.";
    reference
     "RFC 6557: Procedures for Maintaining the Time Zone Database";
  }

The timezone-location leaf will be changed to use this type,
the import of iana-timezones will be removed and the references
to I-D.ietf-netmod-iana-timezones will be removed.

- The draft-ietf-netmod-iana-timezones-00 document will be pulled
back and work on this draft will stop.  The I-D is declared dead.

- Since there is nothing to do for IANA, there will be no IANA request 
needed in this regard for draft-ietf-netmod-system-mgmt-11. 

    

    I'm unclear on what's happening when a timezone name is added,
    removed, modified in the Time Zone Database.

    Or maybe the assumption is that the typedef is always up to date
    with the latest version of the Time Zone Database, on the NETCONF
    client and server?

    I believe It needs a little bit of explanation.

    

    Regards, Benoit

    

      

	We note that further alternatives can be added to the timezone
choice in the future should the two mechanisms currently in place
turn out to be insufficient in practice.

	We would like to give the WG sufficient time to raise any additional concerns or 
issues with regard to this issue and our path for resolving the issue at hand, and so we 
will accept comments/discussion on this matter until 8AM EDT on Tuesday, January 28, 2014.
As Juergen has been closely involved with the matter, I will adjudicate any issues
arising from this comment period.

	Thanks,

	Tom






      

      

      

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


    

    

  


--------------080602030505070605060507--

From lhotka@nic.cz  Wed Jan 22 01:18:34 2014
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 910FE1A03E5 for ; Wed, 22 Jan 2014 01:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 HonwLiUbdsUs for ; Wed, 22 Jan 2014 01:18:33 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C40C71A03DE for ; Wed, 22 Jan 2014 01:18:32 -0800 (PST)
Received: from [192.168.41.135] (outwfguestc.fbk.eu [217.77.82.140]) by mail.nic.cz (Postfix) with ESMTPSA id E67A913F9D6; Wed, 22 Jan 2014 10:18:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390382311; bh=Y5kePcaSmh1av0mWcC8zAUphdM8+4GbcwIuVqEGix40=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dt891aQk4YfDisXYJZdYraFweNFrVN2cbbNsEfPbCy+rr8wGGt6YnUBmZVYK+9+pI tBsp+d8IxVM5njnjEKD4Jpn4WPAdd99X13oxfJiDxNBuhe7SEj6cVKvt74hGJ9S0Tb NZSBV9YGfOAJIutSF5xZShDAYLAqJ8V9cDjt1FZI=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <7139720.1390325752026.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
Date: Wed, 22 Jan 2014 10:18:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2702BAE9-B494-4FFF-AB34-86879582FF8B@nic.cz>
References: <7139720.1390325752026.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
To: Randy Presuhn 
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] enumeration 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: Wed, 22 Jan 2014 09:18:35 -0000

On 21 Jan 2014, at 18:35, Randy Presuhn  =
wrote:

> Hi -
>=20
>> From: Andy Bierman 
>> Sent: Jan 21, 2014 6:46 AM
>> To: Jernej Tuljak 
>> Cc: "netmod@ietf.org" 
>> Subject: Re: [netmod] enumeration type
> ...
>> I do not understand all this fuss over a field used just
>> for documentation.  The value field is not used
>> in the protocol.  It is not referenced in any other
>> YANG statement.
>=20
> Which leads to the question: why does the value
> field even exist?

I can imagine use cases where the numeric value has some intrinsic =
meaning, e. g.

enum January {
    value 1;
}
=85

If it is not the case, as in the timezones enumeration, the values are =
pretty much useless.

The only place in YANG where the values become relevant is the first =
bullet in sec. 10:

   o  An "enumeration" type may have new enums added, provided the old
      enums's values do not change.

Lada


>=20
>> I thought the auto-assignment procedure was clear
>> when I implemented it.
>=20
> The problem is that there are two reasonable interpretations
> of the text, and, depending on which interpretation was used
> in constructing an implementation, the same module may or may
> not produce an error.  That's not interoperable.
>=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 jonathan@hansfords.net  Wed Jan 22 01:42:01 2014
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 E5BE51A03ED for ; Wed, 22 Jan 2014 01:42:01 -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 ZTsmEOA62V5O for ; Wed, 22 Jan 2014 01:41:59 -0800 (PST)
Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id 11FEE1A02DE for ; Wed, 22 Jan 2014 01:41:58 -0800 (PST)
Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id Gxhw1n00B4CLSd801xhxvE; Wed, 22 Jan 2014 09:41:58 +0000
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=LqOrlBtc c=1 sm=1 tr=0 a=VrPob/PGR4vzCiwW53VWbQ==:117 a=657E4hAeR8dYZ1rsg01OlA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=ymigdH7LP5EA:10 a=0B8HqoTn75oA:10 a=eDuwVpe5h8AA:10 a=IkcTkHD0fZMA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=valQ_CuEJh4A:10 a=u07AKapRAAAA:8 a=yZdqkil9Jd-QLio0u_sA:9 a=QEXdDO2ut3YA:10 a=XqebBV1NYWwA:10
X-AUTH: hansfords+us:2500
Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Wed, 22 Jan 2014 09:41:56 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 22 Jan 2014 09:41:56 +0000
From: Jonathan Hansford 
To: Per Hedeland 
In-Reply-To: <52DF700F.1090304@tail-f.com>
References: <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>  <53eb7125803729d92a23665c0f0396ff@imap.plus.net>   <20140121175608.GB48434@elstar.local> <52DEFCBC.3050202@tail-f.com>  <52DF700F.1090304@tail-f.com>
Message-ID: <0c9fc47bfad970d8e0aef6f382e61827@imap.plus.net>
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [212.159.131.152]
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 09:42:02 -0000

On 2014-01-22 07:15, Per Hedeland wrote:

> On 2014-01-22 02:41, Andy Bierman wrote:
>
>> On Tue, Jan 21, 2014 at 3:03 PM, Per Hedeland 
>> wrote:
>>
>>> On 2014-01-21 18:56, Juergen Schoenwaelder wrote:
>>>
>>>> On Tue, Jan 21, 2014 at 08:42:54AM -0800, Andy Bierman wrote:
>>>>
>>>>> Hi, Jonathan, you are right -- the rules are not obvious. Our
>>>>> code does not implement the rules I specified. It uses the next
>>>>> highest value assigned: leaf enum-test { type enumeration { enum
>>>>> seven { value 7; } enum eight; // value 8 enum nine; // value 9
>>>>> enum four { value 4; } enum ten; // value 10, not 5 enum eleven;
>>>>> // value 11, not 6 } }
>>>> In C, ten would be 5 and eleven would be 6.
>>> And if you added twelve at the end, it would be 7 just like seven -
>>> C doesn't care, but in YANG it would be an error, and you would
>>> either be required to give a value statement for such cases too 
>>> (and
>>> not just for the MAXINT case explicitly spelled out in 6020), or 
>>> the
>>> compiler would have to find an unused value instead of just always
>>> using highest + 1 for auto-assignment (quite doable of course, but
>>> it's definitely not what 6020 says).
>>>
>>>> I believe we reduce the number of surprises if we follow C
>>>> semantics (and as far as I recall that was the original idea as
>>>> well). I think "current highest value" really was meant to be "the
>>>> last value (in the order of enum definition)".
>>> I seriously doubt that, given the above - the other parts of the
>>> text don't match. And so far I don't think we've heard of any
>>> implementation doing that (pyang also does the assignment that Andy
>>> listed), so I think it really would have to
>>>
>>>> d a changed specification. Note that w
>>> r text in section 9.7.4.2. Yes, it could also use clarification of
>>> "current highest".
>> I agree we should not change the behavior now. The "max value" 
>> corner
>> case is not really clear either.
>
> If we use the common interpretation of "current highest value", I 
> can't
> see that it is unclear.
>

I don't believe there is a common interpretation. For a parser the
interpretation would be the highest value currently encountered (i.e. 
the
highest value that has already been parsed). For someone who doesn't 
think
that way, all the values in the enumeration are current.

>
>> leaf max-enum-test { type enumeration { enum max { value 2147483647; 
>> }
>> enum pick1; enum pick2; enum minus1 { value -1; } } } The compiler 
>> is
>> supposed to assign unused values for pick1 and pick2.
>
> No, why do you think so? 6020 says:
>
> If the current highest value is equal to 2147483647, then an enum
> value MUST be specified for "enum" substatements following the one
> with the current highest value.
>
> I.e. in this corner-case, you are required to *specify* values for 
> pick1
> and pick2 - the auto-assignment isn't expect> it. pyang just folds 
> this
> requirement into the <= MAXINT check:
>> enum.yang:8: error: the enumeration value "2147483648" is no
> nteger enum.yang:9: error: the enumeration value "2147483649" is not 
> an
> 32 bit integer - which is OK I guess. Is the compiler supposed to 
> avoid
> assigning -1 or is the minus1 enum an error (if -1 happened to be
> selected for pick1 or pick2).
>
> So this doesn't apply - but something similar will happen with
>
> type enumeration {
> enum zero; // value 0
> enum two { value 2; }
> enum one { value 1; }
> enum three; // value 3
> enum four { value 3; }
> }
>
> pyang says:
>
> enum.yang:11: error: the integer value "3" has already been used for 
> the
> enumeration at enum.yang:10
>
> Again, with the common interpretation of "current highest value", 
> there
> is nothing unclear - the compiler never needs to look-ahead for
> specified values, auto-assignment always uses highest + 1 - and the
> module writer needs to take that into account when mixing enums with 
> and
> without specified values (e.g. by reordering the enum statements in 
> the
> probably unlikely case that there is a clash and the specified value 
> is
> important - putting all those with specified values before those 
> without
> will always work, as long as the (even less likely-to-be-a-problem)
> MAXINT rule is also observed).
>
> --Per

Links:
------
[1] mailto:per@tail-f.com

From per@tail-f.com  Wed Jan 22 02:03:38 2014
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 513241A02C2 for ; Wed, 22 Jan 2014 02:03:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 MKuzj51p21rS for ; Wed, 22 Jan 2014 02:03:36 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 448931A0099 for ; Wed, 22 Jan 2014 02:03:36 -0800 (PST)
Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 713DB240C1B4; Wed, 22 Jan 2014 11:03:34 +0100 (CET)
Message-ID: <52DF9776.7090903@tail-f.com>
Date: Wed, 22 Jan 2014 11:03:34 +0100
From: Per Hedeland 
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7
MIME-Version: 1.0
To: Jonathan Hansford 
References: <20140121091052.GA47088@elstar.local>  <52DE3CA6.7030308@mg-soft.com>  <20140121095409.GA47316@elstar.local> <52DE45C3.4040400@mg-soft.com>  <53eb7125803729d92a23665c0f0396ff@imap.plus.net>   <20140121175608.GB48434@elstar.local> <52DEFCBC.3050202@tail-f.com>  <52DF700F.1090304@tail-f.com> <0c9fc47bfad970d8e0aef6f382e61827@imap.plus.net>
In-Reply-To: <0c9fc47bfad970d8e0aef6f382e61827@imap.plus.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 10:03:38 -0000

On 2014-01-22 10:41, Jonathan Hansford wrote:
> On 2014-01-22 07:15, Per Hedeland wrote:
> 
>> On 2014-01-22 02:41, Andy Bierman wrote:
>>
>>> On Tue, Jan 21, 2014 at 3:03 PM, Per Hedeland 
>>> wrote:
>>>
>>>> On 2014-01-21 18:56, Juergen Schoenwaelder wrote:
>>>>
>>>>> On Tue, Jan 21, 2014 at 08:42:54AM -0800, Andy Bierman wrote:
>>>>>
>>>>>> Hi, Jonathan, you are right -- the rules are not obvious. Our
>>>>>> code does not implement the rules I specified. It uses the next
>>>>>> highest value assigned: leaf enum-test { type enumeration { enum
>>>>>> seven { value 7; } enum eight; // value 8 enum nine; // value 9
>>>>>> enum four { value 4; } enum ten; // value 10, not 5 enum eleven;
>>>>>> // value 11, not 6 } }
>>>>> In C, ten would be 5 and eleven would be 6.
>>>> And if you added twelve at the end, it would be 7 just like seven -
>>>> C doesn't care, but in YANG it would be an error, and you would
>>>> either be required to give a value statement for such cases too (and
>>>> not just for the MAXINT case explicitly spelled out in 6020), or the
>>>> compiler would have to find an unused value instead of just always
>>>> using highest + 1 for auto-assignment (quite doable of course, but
>>>> it's definitely not what 6020 says).
>>>>
>>>>> I believe we reduce the number of surprises if we follow C
>>>>> semantics (and as far as I recall that was the original idea as
>>>>> well). I think "current highest value" really was meant to be "the
>>>>> last value (in the order of enum definition)".
>>>> I seriously doubt that, given the above - the other parts of the
>>>> text don't match. And so far I don't think we've heard of any
>>>> implementation doing that (pyang also does the assignment that Andy
>>>> listed), so I think it really would have to
>>>>
>>>>> d a changed specification. Note that w
>>>> r text in section 9.7.4.2. Yes, it could also use clarification of
>>>> "current highest".
>>> I agree we should not change the behavior now. The "max value" corner
>>> case is not really clear either.
>>
>> If we use the common interpretation of "current highest value", I can't
>> see that it is unclear.
>>
> 
> I don't believe there is a common interpretation. For a parser the
> interpretation would be the highest value currently encountered (i.e. the
> highest value that has already been parsed). For someone who doesn't think
> that way, all the values in the enumeration are current.

Yes, I (too) earlier agreed that it could use clarification, sorry for
being terse here. With "common interpretation", I really meant "the
apparently common interpretation across the YANG implementors that have
spoken up in this thread". The wording was just meant to indicate that
using this interpretation was a condition for considering the remainder
of the spec to be clear...

--Per

From randy_presuhn@mindspring.com  Wed Jan 22 02:17:26 2014
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 5C7811A01EB for ; Wed, 22 Jan 2014 02:17:26 -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 mQBzgbuAyvBF for ; Wed, 22 Jan 2014 02:17:24 -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 1D8B91A0099 for ; Wed, 22 Jan 2014 02:17:24 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=BB2JiKY3Ry6Z8w3S6n5CG9QNZWwAZnbwR9HaUGfcFCMClHCZ4hNizDfnicX51Hz0; 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 1W5us7-0000Bg-KY for netmod@ietf.org; Wed, 22 Jan 2014 05:17:23 -0500
Received: from 99.101.140.68 by webmail.earthlink.net with HTTP; Wed, 22 Jan 2014 05:17:23 -0500
Message-ID: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
Date: Wed, 22 Jan 2014 02:17:23 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbc748899ec3a987810f5345b5139cf6964350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.36
Subject: Re: [netmod] enumeration type
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, 22 Jan 2014 10:17:26 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Jan 22, 2014 1:18 AM
>To: Randy Presuhn 
>Cc: netmod@ietf.org
>Subject: Re: [netmod] enumeration type
... 
>> Which leads to the question: why does the value
>> field even exist?
>
>I can imagine use cases where the numeric value has some intrinsic meaning, e. g.
>
>enum January {
>    value 1;
>}

I don't really see any "intrinsic meaning" to the value 1
in this case, particularly since that value doesn't show up
"on the wire", nor is it used to, for example, govern sorting.

It sounds like the value is there only to potentially trigger
error messages from compilers, and not to in any way foster
interoperability or affect the operation of gear.

Randy

From jonathan@hansfords.net  Wed Jan 22 02:30:48 2014
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 3A69D1A02C2 for ; Wed, 22 Jan 2014 02:30:48 -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 WOlaHjjDX1Pz for ; Wed, 22 Jan 2014 02:30:43 -0800 (PST)
Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8D90E1A01EB for ; Wed, 22 Jan 2014 02:30:43 -0800 (PST)
Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id GyWh1n00C4CLSd801yWiil; Wed, 22 Jan 2014 10:30:42 +0000
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=LqOrlBtc c=1 sm=1 tr=0 a=VrPob/PGR4vzCiwW53VWbQ==:117 a=657E4hAeR8dYZ1rsg01OlA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=ymigdH7LP5EA:10 a=0B8HqoTn75oA:10 a=eDuwVpe5h8AA:10 a=IkcTkHD0fZMA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=valQ_CuEJh4A:10 a=84BadPHTAAAA:8 a=48vgC7mUAAAA:8 a=Qh68hDqhDpjbM4vz1rMA:9 a=QEXdDO2ut3YA:10 a=OS7PZEPQ3MUA:10 a=lZB815dzVvQA:10
X-AUTH: hansfords+us:2500
Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Wed, 22 Jan 2014 10:30:41 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 22 Jan 2014 10:30:41 +0000
From: Jonathan Hansford 
To: 
In-Reply-To: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
Message-ID: 
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [212.159.131.152]
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 10:30:48 -0000

On 2014-01-22 10:17, Randy Presuhn wrote:

> Hi -
>
>> From: Ladislav Lhotka  Sent: Jan 22, 2014 1:18 AM
>> To: Randy Presuhn  Cc:
>> netmod@ietf.org [3] Subject: Re: [netmod] enumeration type
>
> ...
>
>>> Which leads to the question: why does the value field even exist?
>> I can imagine use cases where the numeric value has some intrinsic
>> meaning, e. g. enum January { value 1; }
>
> I don't really see any "intrinsic meaning" to the value 1
> in this case, particularly since that value doesn't show up
> "on the wire", nor is it used to, for example, govern sorting.
>
> It sounds like the value is there only to potentially trigger
> error messages from compilers, and not to in any way foster
> interoperability or affect the operation of gear.
>

And if the value has no "intrinsic meaning" then there is no reason 
why, if a value is not specified, the assigned value should be one 
greater than the current highest enum value (other than to make parsing 
the enumeration statement easier). A two-pass parse would allow the 
parser to assign any previously unassigned value (whether explicit or 
implicit) and a parser error would only occur if the full value space 
were used up (perish the thought).

Can anyone explain why enumerations were originally given values, if 
they have no intrinsic meaning (other than the fact that calling them 
enumerations implies that numbers are involved)?

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


Links:
------
[1] mailto:lhotka@nic.cz
[2] mailto:randy_presuhn@mindspring.com
[3] mailto:netmod@ietf.org

From per@tail-f.com  Wed Jan 22 03:03:04 2014
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 B225F1A03DF for ; Wed, 22 Jan 2014 03:03:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 34YTReC_cAMg for ; Wed, 22 Jan 2014 03:03:03 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id D60591A02DE for ; Wed, 22 Jan 2014 03:03:02 -0800 (PST)
Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id CF159240C425; Wed, 22 Jan 2014 12:03:01 +0100 (CET)
Message-ID: <52DFA565.6080204@tail-f.com>
Date: Wed, 22 Jan 2014 12:03:01 +0100
From: Per Hedeland 
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20110120 Thunderbird/3.1.7
MIME-Version: 1.0
To: Jonathan Hansford 
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 11:03:04 -0000

On 2014-01-22 11:30, Jonathan Hansford wrote:
> On 2014-01-22 10:17, Randy Presuhn wrote:
> 
>> Hi -
>>
>>> From: Ladislav Lhotka  Sent: Jan 22, 2014 1:18 AM
>>> To: Randy Presuhn  Cc:
>>> netmod@ietf.org [3] Subject: Re: [netmod] enumeration type
>>
>> ...
>>
>>>> Which leads to the question: why does the value field even exist?
>>> I can imagine use cases where the numeric value has some intrinsic
>>> meaning, e. g. enum January { value 1; }
>>
>> I don't really see any "intrinsic meaning" to the value 1
>> in this case, particularly since that value doesn't show up
>> "on the wire", nor is it used to, for example, govern sorting.
>>
>> It sounds like the value is there only to potentially trigger
>> error messages from compilers, and not to in any way foster
>> interoperability or affect the operation of gear.
>>
> 
> And if the value has no "intrinsic meaning" then there is no reason why, if a value is not specified, the assigned value should be one greater than the current highest enum value (other than to make
> parsing the enumeration statement easier). A two-pass parse would allow the parser to assign any previously unassigned value (whether explicit or implicit) and a parser error would only occur if the
> full value space were used up (perish the thought).
> 
> Can anyone explain why enumerations were originally given values, if they have no intrinsic meaning (other than the fact that calling them enumerations implies that numbers are involved)?

Well, 6020 somewhat vaguely says "carried as a convenience to
implementors", which I take to mean implementors of data stores and
instrumentation. It can be a considerable space saving to store (stable)
32-bit integers instead of arbitrary strings, and in (e.g.) C
instrumentation, it is "nice" to be able to switch() on (stable) values
instead of doing a bunch of strcmp()s. Neither of these "conveniences"
apply in the specific case of the timezone enumeration, though.

--Per

From lhotka@nic.cz  Wed Jan 22 03:21:30 2014
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 8CB551A041B for ; Wed, 22 Jan 2014 03:21:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 fiQFWzhySRtu for ; Wed, 22 Jan 2014 03:21:29 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id F17EC1A00A4 for ; Wed, 22 Jan 2014 03:21:28 -0800 (PST)
Received: from [192.168.41.135] (outwfguestc.fbk.eu [217.77.82.140]) by mail.nic.cz (Postfix) with ESMTPSA id 0A8BF13FD97; Wed, 22 Jan 2014 12:21:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390389688; bh=SyAYrHfx+wVz1sWlgsnksDitub4P/WBkWARs6IuxSYc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OhBKKzXUyy9H/lw0QbQSyxbjdrmqCKzKsdvjDUKk5cRRKmiPtGgyyAySzlYPcWXOH dclrC5e+w/oQe7rxfXYbydpiHcp502l65zQb6XxQjeLCbnqXYI0DeZVj9wtFfb2deY 7fxXcSEcVU0lx1ABeVLUPyvdHfvbyzLbI2uXw2ZU=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
Date: Wed, 22 Jan 2014 12:21:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
To: Randy Presuhn 
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] enumeration 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: Wed, 22 Jan 2014 11:21:30 -0000

On 22 Jan 2014, at 11:17, Randy Presuhn  =
wrote:

> Hi -
>=20
>> From: Ladislav Lhotka 
>> Sent: Jan 22, 2014 1:18 AM
>> To: Randy Presuhn 
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] enumeration type
> ...=20
>>> Which leads to the question: why does the value
>>> field even exist?
>>=20
>> I can imagine use cases where the numeric value has some intrinsic =
meaning, e. g.
>>=20
>> enum January {
>>   value 1;
>> }
>=20
> I don't really see any "intrinsic meaning" to the value 1
> in this case, particularly since that value doesn't show up
> "on the wire", nor is it used to, for example, govern sorting.

I mean the numbers might sometimes be used instead of names in some =
contexts, though not in NETCONF. I do admit it is a rather weak use =
case.
=20
>=20
> It sounds like the value is there only to potentially trigger
> error messages from compilers, and not to in any way foster
> interoperability or affect the operation of gear.

Yes, they can only trigger error messages and complicate updates of =
modules with such enumerations.

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 lhotka@nic.cz  Wed Jan 22 03:49:43 2014
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 7680A1A043A for ; Wed, 22 Jan 2014 03:49:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 ELHSnBbd3TKX for ; Wed, 22 Jan 2014 03:49:42 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0B79B1A0439 for ; Wed, 22 Jan 2014 03:49:41 -0800 (PST)
Received: from [192.168.41.135] (outwfguestc.fbk.eu [217.77.82.140]) by mail.nic.cz (Postfix) with ESMTPSA id 219C613FD97; Wed, 22 Jan 2014 12:49:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390391380; bh=I+jGldSNYfVl66Px1sElf5fmNQl89j8eYaT0hRjZejw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=t8LWd7wmgtcBSCF8KD6hrY8P/9mFy7DHly+7N2+yh6Rjgv1/+gPAMfsUwP4d57sIz li0GN44AK5E6/t1KvxOluRekEbN4YFzsNemvQO4+rouj9EMTQIvLgygevaUWy1Aoux 1AyWRHz4CJ8hJpQhqPLWl+uyl8DSHpGEpMUmZpFs=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <52DFA565.6080204@tail-f.com>
Date: Wed, 22 Jan 2014 12:49:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <98EF395F-B344-444C-AE84-D1E91BD9FECC@nic.cz>
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <52DFA565.6080204@tail-f.com>
To: Per Hedeland 
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] enumeration 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: Wed, 22 Jan 2014 11:49:43 -0000

On 22 Jan 2014, at 12:03, Per Hedeland  wrote:

> On 2014-01-22 11:30, Jonathan Hansford wrote:
>> On 2014-01-22 10:17, Randy Presuhn wrote:
>>=20
>>> Hi -
>>>=20
>>>> From: Ladislav Lhotka  Sent: Jan 22, 2014 1:18 =
AM
>>>> To: Randy Presuhn  Cc:
>>>> netmod@ietf.org [3] Subject: Re: [netmod] enumeration type
>>>=20
>>> ...
>>>=20
>>>>> Which leads to the question: why does the value field even exist?
>>>> I can imagine use cases where the numeric value has some intrinsic
>>>> meaning, e. g. enum January { value 1; }
>>>=20
>>> I don't really see any "intrinsic meaning" to the value 1
>>> in this case, particularly since that value doesn't show up
>>> "on the wire", nor is it used to, for example, govern sorting.
>>>=20
>>> It sounds like the value is there only to potentially trigger
>>> error messages from compilers, and not to in any way foster
>>> interoperability or affect the operation of gear.
>>>=20
>>=20
>> And if the value has no "intrinsic meaning" then there is no reason =
why, if a value is not specified, the assigned value should be one =
greater than the current highest enum value (other than to make
>> parsing the enumeration statement easier). A two-pass parse would =
allow the parser to assign any previously unassigned value (whether =
explicit or implicit) and a parser error would only occur if the
>> full value space were used up (perish the thought).
>>=20
>> Can anyone explain why enumerations were originally given values, if =
they have no intrinsic meaning (other than the fact that calling them =
enumerations implies that numbers are involved)?
>=20
> Well, 6020 somewhat vaguely says "carried as a convenience to
> implementors", which I take to mean implementors of data stores and
> instrumentation. It can be a considerable space saving to store =
(stable)
> 32-bit integers instead of arbitrary strings, and in (e.g.) C
> instrumentation, it is "nice" to be able to switch() on (stable) =
values
> instead of doing a bunch of strcmp()s. Neither of these "conveniences"
> apply in the specific case of the timezone enumeration, though.

Fair enough, but there is no need that everybody uses the same internal =
name-value mapping.

Lada

>=20
> --Per
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From j.schoenwaelder@jacobs-university.de  Wed Jan 22 04:34:02 2014
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 E031C1A009E for ; Wed, 22 Jan 2014 04:34:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 2Nn27qWsTZmH for ; Wed, 22 Jan 2014 04:34:00 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 439EA1A00B1 for ; Wed, 22 Jan 2014 04:34:00 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03E8820064; Wed, 22 Jan 2014 13:33:59 +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 ynFx3yKJKcUx; Wed, 22 Jan 2014 13:33: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 8912220055; Wed, 22 Jan 2014 13:33:58 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id CF9922AC5BC6; Wed, 22 Jan 2014 13:33:54 +0100 (CET)
Date: Wed, 22 Jan 2014 13:33:53 +0100
From: Juergen Schoenwaelder 
To: Jonathan Hansford 
Message-ID: <20140122123353.GA50544@elstar.local>
Mail-Followup-To: Jonathan Hansford , netmod@ietf.org
References: <30210296.1390385843355.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: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration type
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, 22 Jan 2014 12:34:03 -0000

On Wed, Jan 22, 2014 at 10:30:41AM +0000, Jonathan Hansford wrote:
> 
> Can anyone explain why enumerations were originally given values, if
> they have no intrinsic meaning (other than the fact that calling
> them enumerations implies that numbers are involved)?
> 

As far as I recall, they were originally designed this way at the
Stockholm meeting (that is months before the YANG work came to the
IETF) in order to support some coexistance with other protocols that
happen to use numbers instead of strings on the wire for enumerations.

Looking at it from today's perspective, I tend to believe the
automatic assignment of values was not a very smart choice (since
using it is very dangerous when it comes to updates) and in hindsight
it might have been better to allow values as an optional feature of an
enum that YANG data model designers can use but are not required to
use.

/js

PS: I do feel somewhat guilty for this design but I am not sure who
    actually had this automated numbering idea and it probably does
    not matter. Back in London, I started coding what several years
    later became RFC 6643, but for that I did not need automated
    numbering.

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

From xiang.li3000@gmail.com  Wed Jan 22 05:57:53 2014
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 83AE51A00D6 for ; Wed, 22 Jan 2014 05:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 LcRORQY8PaXE for ; Wed, 22 Jan 2014 05:57:52 -0800 (PST)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id BA2131A00B2 for ; Wed, 22 Jan 2014 05:57:51 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id x55so334345wes.22 for ; Wed, 22 Jan 2014 05:57:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=HbAlg+Q7Xg3yWNqKXdCVVqHj93B4AFohQ+2iPaPh5vw=; b=lrgsVya8Z1yFevFyrSes0Vdqpc0N2aVOFGLSNAlZIFjkoBgikO0iNMGuHdsrVY9Obo HWdbJJhVM6c8te/Kf/P+rNcwa0kNyxOwutfx5ND2F7ar3zc0Wa67gEXbV2Bn4Bk8GZVH uof13FCbNqnT+RxgT2hoX1DrQVX4UjovZiE9aPnDXnHkg5m2BoPK5r755Qt9dveHK3iS q63708K7TSm4fodkX+VWnHKfrp/sLJ6b8v2zSaqOiiATqM3O09zty55FWqLBXwCkt+++ obEpqLnLmXrZq5oz6JPg70advRbIdbyLTZfRjhWrYaVNf6KGM7Z8gUYSuvLWBp9ynwAG hgnw==
MIME-Version: 1.0
X-Received: by 10.180.76.103 with SMTP id j7mr3334103wiw.58.1390399069223; Wed, 22 Jan 2014 05:57:49 -0800 (PST)
Received: by 10.227.175.197 with HTTP; Wed, 22 Jan 2014 05:57:49 -0800 (PST)
In-Reply-To: <20140122123353.GA50544@elstar.local>
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>
Date: Wed, 22 Jan 2014 07:57:49 -0600
Message-ID: 
From: Xiang Li 
To: Juergen Schoenwaelder ,  Jonathan Hansford , netmod@ietf.org
Content-Type: multipart/alternative; boundary=f46d043c7cc69e006604f08f8220
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 13:57:53 -0000

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

While I tend to agree that the automatic numbering is not very useful, but
since it already managed to be there so I prefer to consider it as a
'feature'. When I read the texts in RFC6020 again and again, I actually
think the meaning of "the highest enum value" is arguably clear (that
it is different
from c interpretation), but it may be only me thinks this way...


 -- Xiang Li


On Wed, Jan 22, 2014 at 6:33 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Jan 22, 2014 at 10:30:41AM +0000, Jonathan Hansford wrote:
> >
> > Can anyone explain why enumerations were originally given values, if
> > they have no intrinsic meaning (other than the fact that calling
> > them enumerations implies that numbers are involved)?
> >
>
> As far as I recall, they were originally designed this way at the
> Stockholm meeting (that is months before the YANG work came to the
> IETF) in order to support some coexistance with other protocols that
> happen to use numbers instead of strings on the wire for enumerations.
>
> Looking at it from today's perspective, I tend to believe the
> automatic assignment of values was not a very smart choice (since
> using it is very dangerous when it comes to updates) and in hindsight
> it might have been better to allow values as an optional feature of an
> enum that YANG data model designers can use but are not required to
> use.
>
> /js
>
> PS: I do feel somewhat guilty for this design but I am not sure who
>     actually had this automated numbering idea and it probably does
>     not matter. Back in London, I started coding what several years
>     later became RFC 6643, but for that I did not need automated
>     numbering.
>
> --
> 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
>

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


While I tend to agree that the automatic numbering is not =
very useful, but since it already managed to be there so I prefer to consid=
er it as a 'feature'. When I read the texts in RFC6020 again and ag=
ain, I actually think the meaning of "the=A0highest enum value" is=A0arguably clear (t=
hat it is=A0different from c=
 interpretation), but it may be only me thinks this way...



=A0-- Xiang Li



On Wed, Jan 22, 2014 at 6:33 AM, Juergen=
 Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Wed, Jan 22, 2014 at 10:30:41AM +0000, Jo=
nathan Hansford wrote:

>

> Can anyone explain why enumerations were originally given values, if
> they have no intrinsic meaning (other than the fact that calling

> them enumerations implies that numbers are involved)?

>



As far as I recall, they were originally designed this way at the

Stockholm meeting (that is months before the YANG work came to the

IETF) in order to support some coexistance with other protocols that

happen to use numbers instead of strings on the wire for enumerations.



Looking at it from today's perspective, I tend to believe the

automatic assignment of values was not a very smart choice (since

using it is very dangerous when it comes to updates) and in hindsight

it might have been better to allow values as an optional feature of an

enum that YANG data model designers can use but are not required to

use.



/js



PS: I do feel somewhat guilty for this design but I am not sure who

=A0 =A0 actually had this automated numbering idea and it probably does

=A0 =A0 not matter. Back in London, I started coding what several years

=A0 =A0 later became RFC 6643, but for that I did not need automated

=A0 =A0 numbering.



--

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, Germany

Fax: =A0 +=
49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/>

_______________________________________________

netmod mailing list

netmod@ietf.org

=
https://www.ietf.org/mailman/listinfo/netmod





--f46d043c7cc69e006604f08f8220--

From jonathan@hansfords.net  Wed Jan 22 07:16:00 2014
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 B25BC1A0102 for ; Wed, 22 Jan 2014 07:16:00 -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 atJLUM0I9uoE for ; Wed, 22 Jan 2014 07:15:58 -0800 (PST)
Received: from avasout08.plus.net (avasout08.plus.net [212.159.14.20]) by ietfa.amsl.com (Postfix) with ESMTP id 054A31A00CF for ; Wed, 22 Jan 2014 07:15:57 -0800 (PST)
Received: from webmail.plus.net ([84.93.237.194]) by avasout08 with smtp id H3Fv1n0044CLSd8013FwSA; Wed, 22 Jan 2014 15:15:56 +0000
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=LqOrlBtc c=1 sm=1 tr=0 a=VrPob/PGR4vzCiwW53VWbQ==:117 a=657E4hAeR8dYZ1rsg01OlA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=ymigdH7LP5EA:10 a=0B8HqoTn75oA:10 a=eDuwVpe5h8AA:10 a=IkcTkHD0fZMA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=valQ_CuEJh4A:10 a=kj9Kw6FvMZAKwy35cuoA:9 a=QEXdDO2ut3YA:10
X-AUTH: hansfords+us:2500
Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Wed, 22 Jan 2014 15:15:55 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 22 Jan 2014 15:15:55 +0000
From: Jonathan Hansford 
To: 
In-Reply-To: <20140122123353.GA50544@elstar.local>
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>
Message-ID: 
X-Sender: Jonathan@hansfords.net
User-Agent: Roundcube Webmail/0.7.4
X-Originating-IP: [212.159.131.152]
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 15:16:00 -0000

On 2014-01-22 12:33, Juergen Schoenwaelder wrote:

> On Wed, Jan 22, 2014 at 10:30:41AM +0000, Jonathan Hansford wrote:
>
>> Can anyone explain why enumerations were originally given values, if
>> they have no intrinsic meaning (other than the fact that calling 
>> them
>> enumerations implies that numbers are involved)?
>
> As far as I recall, they were originally designed this way at the
> Stockholm meeting (that is months before the YANG work came to the
> IETF) in order to support some coexistance with other protocols that
> happen to use numbers instead of strings on the wire for 
> enumerations.

Having looked through some historical documents, it may also have 
arisen from the draft-bjorklund-yang-requirements-00 response ("SMIv2 
style enumerations are fully supported in YANG.") to RFC 3216 "SMIng 
Objectives", section 4.1.17 "Enumerations":

    Type: basic

    From: SMI, SPPI

    Description: SMIng must provide support for enumerations.  
Enumerated
       values must be a part of the enumeration definition.

    Motivation: SMIv2 already has enumerated numbers.

    Notes: Enumerations have the implicit constraint that the attribute
       is constrained to the values for the enumeration.

>
> Looking at it from today's perspective, I tend to believe the
> automatic assignment of values was not a very smart choice (since
> using it is very dangerous when it comes to updates) and in hindsight
> it might have been better to allow values as an optional feature of 
> an
> enum that YANG data model designers can use but are not required to
> use.
>
> /js
>
> PS: I do feel somewhat guilty for this design but I am not sure who
> actually had this automated numbering idea and it probably does
> not matter. Back in London, I started coding what several years
> later became RFC 6643, but for that I did not need automated
> numbering.

From spakes@snmp.com  Wed Jan 22 08:05:56 2014
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 121311A035D for ; Wed, 22 Jan 2014 08:05:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 G1jx5P3TUxjy for ; Wed, 22 Jan 2014 08:05:54 -0800 (PST)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id C5C2B1A044C for ; Wed, 22 Jan 2014 08:05:49 -0800 (PST)
Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA27675; Wed, 22 Jan 2014 11:04:23 -0500 (EST)
Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA20765; Wed, 22 Jan 2014 11:03:07 -0500 (EST)
X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs
Date: Wed, 22 Jan 2014 11:03:07 -0500 (EST)
From: David Spakes 
X-X-Sender: spakes@adminfs
To: netmod@ietf.org
In-Reply-To: 
Message-ID: 
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local> 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 16:05:56 -0000

On Wed, 22 Jan 2014, Ladislav Lhotka wrote:

> I mean the numbers might sometimes be used instead of names in some
> contexts, though not in NETCONF. I do admit it is a rather weak use
> case.


On 2014-01-22 12:33, Juergen Schoenwaelder wrote:

> As far as I recall, they were originally designed this way at the
> Stockholm meeting (that is months before the YANG work came to the
> IETF) in order to support some coexistance with other protocols that
> happen to use numbers instead of strings on the wire for
> enumerations.


On Wed, 22 Jan 2014, Jonathan Hansford wrote:

> Having looked through some historical documents, it may also have
> arisen from the draft-bjorklund-yang-requirements-00 response ("SMIv2
> style enumerations are fully supported in YANG.") to RFC 3216 "SMIng
> Objectives", section 4.1.17 "Enumerations":


One of the most important lessons for management architecture design
that resulted from SNMP experience over the past 25 years is that you
should keep the specifications of protocol, data definition language,
and managed objects independent of one another.

If someone were to argue that numeric values for enumerations are not
important because NETCONF doesn't need them, I would reply that their
argument is short-sighted.  YANG modules that are created in the
present may be used with other protocols that emerge in the future or
existing protocols designed in the past.  Design decisions that hinder
multiple uses of a technology can serve to slow or stop enterprises
from adopting that technology.

In my opinion, it would have been better to require that a numeric
value be explicitly defined for every enumeration.  However, the
automatic assignment of numeric values is acceptable as long as the
values are not changed by a subsequent revision of the document.
Also, the procedure to arrive at the automatically assigned values
must be absolutely clear to every reader.

-dss


-------------------------------------------------------------
 David Spakes                       email:   spakes@snmp.com
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------


From andy@yumaworks.com  Wed Jan 22 08:21:11 2014
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 394A31A01A9 for ; Wed, 22 Jan 2014 08:21:11 -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 WHsayIiZ-GzB for ; Wed, 22 Jan 2014 08:21:09 -0800 (PST)
Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3B17F1A035C for ; Wed, 22 Jan 2014 08:21:08 -0800 (PST)
Received: by mail-qc0-f179.google.com with SMTP id e16so760178qcx.38 for ; Wed, 22 Jan 2014 08:21:08 -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=nqaSJE1UH8gShN4rUIluLYig/130A2JJfqaViR0XJAA=; b=H2xbDUamHous86tEDH6aDSs94Z7tDMwNYBIFgDsLmdlEuiVdhZcTRyqBVPtkKzIIsY yEEkvDGMABHzOKaZCYhV1HYdRTpQKd1uBPV5FH0+e9AHNZtYhCFlmQjXbgDhAQZSlHA3 FSwkXAHOtZQxLKuUNN3NOFfYXhaBZ0PUfX4ZJfvTOeqM9aFTOQjO1U/K3VaezYa8Yuhy YRlyQSEtYe9CgJV646gtU8U9AC8L6o6lMDL3ExuEfLbdZ1UfWzgTJ5f0DJkg6U/qkh43 JhWnVM+1bA1PyiXlnksQ1B1uhEKt+Kb/0/WPfXoUI7GQD+U2piPtN+xLC3+BdNrKfybL phlQ==
X-Gm-Message-State: ALoCoQlcCYG/traunYDJljHXgngem2Kg3czb6mOV1sLAMN/Dkx7S6xyl5dO9IsZIzoqV5OPhXBNa
MIME-Version: 1.0
X-Received: by 10.140.36.107 with SMTP id o98mr3560377qgo.25.1390407668295; Wed, 22 Jan 2014 08:21:08 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Wed, 22 Jan 2014 08:21:08 -0800 (PST)
In-Reply-To: 
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>  
Date: Wed, 22 Jan 2014 08:21:08 -0800
Message-ID: 
From: Andy Bierman 
To: David Spakes 
Content-Type: multipart/alternative; boundary=001a11c154b629c26304f09183f7
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 16:21:11 -0000

--001a11c154b629c26304f09183f7
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 22, 2014 at 8:03 AM, David Spakes  wrote:

> On Wed, 22 Jan 2014, Ladislav Lhotka wrote:
>
> > I mean the numbers might sometimes be used instead of names in some
> > contexts, though not in NETCONF. I do admit it is a rather weak use
> > case.
>
>
> On 2014-01-22 12:33, Juergen Schoenwaelder wrote:
>
> > As far as I recall, they were originally designed this way at the
> > Stockholm meeting (that is months before the YANG work came to the
> > IETF) in order to support some coexistance with other protocols that
> > happen to use numbers instead of strings on the wire for
> > enumerations.
>
>
> On Wed, 22 Jan 2014, Jonathan Hansford wrote:
>
> > Having looked through some historical documents, it may also have
> > arisen from the draft-bjorklund-yang-requirements-00 response ("SMIv2
> > style enumerations are fully supported in YANG.") to RFC 3216 "SMIng
> > Objectives", section 4.1.17 "Enumerations":
>
>
> One of the most important lessons for management architecture design
> that resulted from SNMP experience over the past 25 years is that you
> should keep the specifications of protocol, data definition language,
> and managed objects independent of one another.
>
> If someone were to argue that numeric values for enumerations are not
> important because NETCONF doesn't need them, I would reply that their
> argument is short-sighted.  YANG modules that are created in the
> present may be used with other protocols that emerge in the future or
> existing protocols designed in the past.  Design decisions that hinder
> multiple uses of a technology can serve to slow or stop enterprises
> from adopting that technology.
>
> In my opinion, it would have been better to require that a numeric
> value be explicitly defined for every enumeration.  However, the
> automatic assignment of numeric values is acceptable as long as the
> values are not changed by a subsequent revision of the document.
> Also, the procedure to arrive at the automatically assigned values
> must be absolutely clear to every reader.
>
>

If the numeric values have some semantics (e.g., matching port numbers)
then the value-stmt might help an application.  Otherwise
the value-stmt is just clutter.  Auto-assignment will comply
with sec. 10 (updates) if new enums and bits are always added
at the end of the list.



> -dss
>

Andy

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





On Wed, Jan 22, 2014 at 8:03 AM, David Spakes <=
;spakes@snmp.com&g=
t; wrote:


On Wed, 22 Jan 2014, Ladislav Lhotka wrote:<=
br>


> I mean the numbers might sometimes be used instead of names in some
> contexts, though not in NETCONF. I do admit it is a rather weak use
> case.





On 2014-01-22 12:33, Juergen Schoenwaelder wrote:



> As far as I recall, they were originally designed this way at the

> Stockholm meeting (that is months before the YANG work came to the

> IETF) in order to support some coexistance with other protocols that
> happen to use numbers instead of strings on the wire for

> enumerations.





On Wed, 22 Jan 2014, Jonathan Hansford wrote:



> Having looked through some historical documents, it may also have

> arisen from the draft-bjorklund-yang-requirements-00 response ("S=
MIv2

> style enumerations are fully supported in YANG.") to RFC 3216 &qu=
ot;SMIng

> Objectives", section 4.1.17 "Enumerations":





One of the most important lessons for management architecture design

that resulted from SNMP experience over the past 25 years is that you

should keep the specifications of protocol, data definition language,

and managed objects independent of one another.



If someone were to argue that numeric values for enumerations are not

important because NETCONF doesn't need them, I would reply that their
argument is short-sighted. =A0YANG modules that are created in the

present may be used with other protocols that emerge in the future or

existing protocols designed in the past. =A0Design decisions that hinder
multiple uses of a technology can serve to slow or stop enterprises

from adopting that technology.



In my opinion, it would have been better to require that a numeric

value be explicitly defined for every enumeration. =A0However, the

automatic assignment of numeric values is acceptable as long as the

values are not changed by a subsequent revision of the document.

Also, the procedure to arrive at the automatically assigned values

must be absolutely clear to every reader.




If the numeric values h=
ave some semantics (e.g., matching port numbers)
then the value-s=
tmt might help an application. =A0Otherwise
the value-stmt is jus=
t clutter. =A0Auto-assignment will comply


with sec. 10 (updates) if new enums and bits are always added
at the end of the list.

=A0


-dss

Andy



--001a11c154b629c26304f09183f7--

From j.schoenwaelder@jacobs-university.de  Wed Jan 22 08:58:46 2014
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 12F481A0179 for ; Wed, 22 Jan 2014 08:58:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 oaaQJ6pZFjYZ for ; Wed, 22 Jan 2014 08:58:44 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E1A961A0153 for ; Wed, 22 Jan 2014 08:58:43 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 319A32007E; Wed, 22 Jan 2014 17:58:43 +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 MXxHlhqy4v7X; Wed, 22 Jan 2014 17:58:43 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3DDC620085; Wed, 22 Jan 2014 17:58:41 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 691442AC6DF6; Wed, 22 Jan 2014 17:58:39 +0100 (CET)
Date: Wed, 22 Jan 2014 17:58:39 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20140122165839.GB51297@elstar.local>
Mail-Followup-To: Andy Bierman , David Spakes , "netmod@ietf.org" 
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>   
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration type
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, 22 Jan 2014 16:58:46 -0000

On Wed, Jan 22, 2014 at 08:21:08AM -0800, Andy Bierman wrote:

> If the numeric values have some semantics (e.g., matching port numbers)
> then the value-stmt might help an application.  Otherwise
> the value-stmt is just clutter.  Auto-assignment will comply
> with sec. 10 (updates) if new enums and bits are always added
> at the end of the list.

The problem is that not many people will understand that changing the
order causes interoperability problems. So I would strongly recommend
against the usage of automatic assignments. It is not robust enough.

/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  Wed Jan 22 09:19:44 2014
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 B6AD81A011B for ; Wed, 22 Jan 2014 09:19:44 -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 8JmNvyl1jfH2 for ; Wed, 22 Jan 2014 09:19:43 -0800 (PST)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 292831A013A for ; Wed, 22 Jan 2014 09:19:43 -0800 (PST)
Received: by mail-qa0-f46.google.com with SMTP id ii20so787719qab.33 for ; Wed, 22 Jan 2014 09:19:42 -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=Mc1TZ9fenaYUZCixLb9FEolQ44VVkXxf2EoWoSWLaWA=; b=FND3vj8OD7xoyaxG4U6JfXfqd9/nlJU0CLtSHFsQ0L2MEHYvVpp6Rg/8jeQm3vOGp3 n5rfKLqsgRElPYD0HJsN1MkPYAqcUxDgFQSwFRCGraSt5PmfbBMglU/9PGRIu7P7Xeeu A764WaFzlzuVDsaVbJC1OAcT37FxySPDJF35DmxtD8dqr8V92wmMpfOgLVGfwgbMP3ej peat0f9IU3MCutSDBCWKN7pIY+E9Z4nAYu5KN7dzdSBku1vWvsFopClPVJwzmxkBivzz 7Cn7DGlEGdZ0RFbDbNfEueOmF4AUVJBgu13PbaCoejRqio+lrNKIRBRkACEqeHZnY5yZ fzZw==
X-Gm-Message-State: ALoCoQlaQe+g9hzRe8KxEeGnKTMA1IJMWUyN4r8+YMnuVkjZdMwuLl3CoTm5tw+cSmbXBVWaC9k+
MIME-Version: 1.0
X-Received: by 10.224.123.14 with SMTP id n14mr4316271qar.78.1390411182411; Wed, 22 Jan 2014 09:19:42 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Wed, 22 Jan 2014 09:19:42 -0800 (PST)
In-Reply-To: <20140122165839.GB51297@elstar.local>
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>    <20140122165839.GB51297@elstar.local>
Date: Wed, 22 Jan 2014 09:19:42 -0800
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Andy Bierman ,  David Spakes , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0149c2b49ec81e04f09254c9
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 17:19:44 -0000

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

On Wed, Jan 22, 2014 at 8:58 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Jan 22, 2014 at 08:21:08AM -0800, Andy Bierman wrote:
>
> > If the numeric values have some semantics (e.g., matching port numbers)
> > then the value-stmt might help an application.  Otherwise
> > the value-stmt is just clutter.  Auto-assignment will comply
> > with sec. 10 (updates) if new enums and bits are always added
> > at the end of the list.
>
> The problem is that not many people will understand that changing the
> order causes interoperability problems. So I would strongly recommend
> against the usage of automatic assignments. It is not robust enough.
>
>
Either way I have to remember a clever little rule -- always add an
explicit value-stmt, or always add new enums at the end of the list.
I never bother to use the value-stmt if the enum is just an arbitrary
integer.  The auto-assign can do that for me.


/js
>

Andy

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





On Wed, Jan 22, 2014 at 8:58 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:


On Wed, Jan 22, 2014 at 08:21:08AM -0800, An=
dy Bierman wrote:



> If the numeric values have some semantics (e.g., matching port numbers=
)

> then the value-stmt might help an application. =A0Otherwise

> the value-stmt is just clutter. =A0Auto-assignment will comply

> with sec. 10 (updates) if new enums and bits are always added

> at the end of the list.



The problem is that not many people will understand that changing the

order causes interoperability problems. So I would strongly recommend

against the usage of automatic assignments. It is not robust enough.



Either way I have to remember a clever little rule -=
- always add an
explicit value-stmt, or always add new enums at t=
he end of the list.


I never bother to use the value-stmt if the enum is just an arbitrary<=
/div>
integer. =A0The auto-assign can do that for me.




/js

Andy
=A0


--089e0149c2b49ec81e04f09254c9--

From blukovic@ndt-inc.com  Wed Jan 22 14:24:12 2014
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 5EBD71A04DA for ; Wed, 22 Jan 2014 14:24:12 -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 sGMwq6RselTY for ; Wed, 22 Jan 2014 14:24:11 -0800 (PST)
Received: from mail19k.g19.rapidsite.net (mail19k.g19.rapidsite.net [204.202.242.122]) by ietfa.amsl.com (Postfix) with ESMTP id 077761A04CB for ; Wed, 22 Jan 2014 14:24:10 -0800 (PST)
Received: from mxmtaout02.va1.mxservers.net (208.55.215.49) by mail19k.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 4-0265029449 for ; Wed, 22 Jan 2014 17:24:10 -0500 (EST)
Received: from unknown [161.58.75.15] (EHLO mmm1913.dulles19-verio.com) by mxmtaout02.va1.mxservers.net(mxl_mta-6.15.0-3) with ESMTP id 90540e25.0.641874.00-492.1016083.mxmtaout02.va1.mxservers.net (envelope-from );  Wed, 22 Jan 2014 17:24:10 -0500 (EST)
X-MXL-Hash: 52e0450a2c3bdf35-71af0b542af0fca516cde77b4ce6eb40a75a86e9
Received: (qmail 14237 invoked from network); 22 Jan 2014 22:24:09 -0000
Received: from unknown (HELO ?192.168.0.21?) (blukovic@135.23.154.141) by  with ESMTPA; 22 Jan 2014 22:24:09 -0000
Message-ID: <52E04509.6010006@ndt-inc.com>
Date: Wed, 22 Jan 2014 17:24:09 -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: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>    <20140122165839.GB51297@elstar.local>
In-Reply-To: <20140122165839.GB51297@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam: [F=0.2000000000; CM=0.500; MH=0.500(2014012220); S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [161.58.75.15]
X-AnalysisOut: [v=2.0 cv=QqnpKyOd c=1 sm=1 a=IcBn81/O6j4k4bHiM4CBQw==:17 a]
X-AnalysisOut: [=jl2ymW9NZSsA:10 a=ymigdH7LP5EA:10 a=63bDUHjCYPkA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=A1sffi52AAAA:8 a=valQ_CuE]
X-AnalysisOut: [Jh4A:10 a=vHqUM8IwwqGZDi5KdJIA:9 a=wPNLvfGTeEIA:10]
X-SF-Loop: 1
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 22:24:12 -0000

Could you clarify interoperability problem with changing order of enums?
My understanding is that Netconf mgrs/agents do not use enum value in 
communication.

Borislav

On 1/22/2014 11:58 AM, Juergen Schoenwaelder wrote:
> On Wed, Jan 22, 2014 at 08:21:08AM -0800, Andy Bierman wrote:
>
>> If the numeric values have some semantics (e.g., matching port numbers)
>> then the value-stmt might help an application.  Otherwise
>> the value-stmt is just clutter.  Auto-assignment will comply
>> with sec. 10 (updates) if new enums and bits are always added
>> at the end of the list.
> The problem is that not many people will understand that changing the
> order causes interoperability problems. So I would strongly recommend
> against the usage of automatic assignments. It is not robust enough.
>
> /js
>


From j.schoenwaelder@jacobs-university.de  Wed Jan 22 14:56:00 2014
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 F111C1A0146 for ; Wed, 22 Jan 2014 14:55:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 ftaO1DRXaOwe for ; Wed, 22 Jan 2014 14:55: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 3C13F1A0364 for ; Wed, 22 Jan 2014 14:55:56 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12F0520082; Wed, 22 Jan 2014 23:55:55 +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 Yp3T9TniXRLb; Wed, 22 Jan 2014 23:55:54 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48B762007E; Wed, 22 Jan 2014 23:55:54 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 95EC92AC76D5; Wed, 22 Jan 2014 23:55:52 +0100 (CET)
Date: Wed, 22 Jan 2014 23:55:52 +0100
From: Juergen Schoenwaelder 
To: B Lukovic 
Message-ID: <20140122225552.GC51800@elstar.local>
Mail-Followup-To: B Lukovic , netmod@ietf.org
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>    <20140122165839.GB51297@elstar.local> <52E04509.6010006@ndt-inc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52E04509.6010006@ndt-inc.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration type
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, 22 Jan 2014 22:56:00 -0000

On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:

> Could you clarify interoperability problem with changing order of enums?
> My understanding is that Netconf mgrs/agents do not use enum value
> in communication.

Correct, it does not impact NETCONF exchanges. But whatever uses the
assigned numerical values may get confused if they change. If nothing
ever uses them, fine. But since YANG 1.0 provides them, there is an
unknown risk. YANG 1.0 makes this promise:

   o  An "enumeration" type may have new enums added, provided the old
      enums's values do not change.

Once YANG is widely used, I am sure we will find something somewhere
relying on this and then we may see rather obscure and hard to debug
problems. It is not a concrete and urgent issue but I personally am
happy to have this on a list of things to consider should be ever
create YANG > 1.0.

/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  Wed Jan 22 15:24:38 2014
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 C35B91A04D3 for ; Wed, 22 Jan 2014 15:24:38 -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 ZmOUbdfsU_9L for ; Wed, 22 Jan 2014 15:24:36 -0800 (PST)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id AB8581A039D for ; Wed, 22 Jan 2014 15:24:36 -0800 (PST)
Received: by mail-qa0-f50.google.com with SMTP id cm18so1346995qab.9 for ; Wed, 22 Jan 2014 15:24:35 -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=66o/W7Fl+gaYrkBwYB04Vr3GOeJCvO8hCtURhJBVoKM=; b=mtj/t+hubrBbU2P+3smHOTW1D0Aa8Sdu1sHTvLsiQQl6oyCN919TutHrE+bbfhf2sf sA7/9Ds3Pr1X3/pkig2NJogoLnd7OpYnHf61jTH/ACw4yDqBYiVE+ptK1Wj+r8lQrvwm mfbIczwOhPX6HDhdc7hUpxoQgSyws1zngvowTidlA5QmNA5lM4qtWMl2/td53lujDLud ZV8Ab09MUBnUtuU5AnCppqPYTFRidTqvX8kCdpPXzopyWFoEjop39BuvyroVCEwYbeXK dzaxhv13cU9uz2fSbYBK0TW5NEZAtxVC2BTidGjqRmpHu96jeI3cudBt0u7STxlViaON Ioig==
X-Gm-Message-State: ALoCoQkgm2cQJwDPp7Em9dQL/j915Nv59dvB1U2U8gYCXz39alQSqwL854uSbjYI0ymVmlOnBptL
MIME-Version: 1.0
X-Received: by 10.140.92.65 with SMTP id a59mr6499899qge.34.1390433075800; Wed, 22 Jan 2014 15:24:35 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Wed, 22 Jan 2014 15:24:35 -0800 (PST)
In-Reply-To: <20140122225552.GC51800@elstar.local>
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>    <20140122165839.GB51297@elstar.local> <52E04509.6010006@ndt-inc.com> <20140122225552.GC51800@elstar.local>
Date: Wed, 22 Jan 2014 15:24:35 -0800
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , B Lukovic , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113ab29e91ecd504f0976d8f
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 23:24:38 -0000

--001a113ab29e91ecd504f0976d8f
Content-Type: text/plain; charset=ISO-8859-1

Hi,

It is possible tools are already using the value-stmt.
Many tools use YANG modules. They are not just
for the client/server message exchanges.

But I could imagine a mapping to CoAP in which various strings
were automatically converted to numbers somehow.
Most enum values could be expressed in 1 byte in CoAP using the
value integer.


Andy



On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:
>
> > Could you clarify interoperability problem with changing order of enums?
> > My understanding is that Netconf mgrs/agents do not use enum value
> > in communication.
>
> Correct, it does not impact NETCONF exchanges. But whatever uses the
> assigned numerical values may get confused if they change. If nothing
> ever uses them, fine. But since YANG 1.0 provides them, there is an
> unknown risk. YANG 1.0 makes this promise:
>
>    o  An "enumeration" type may have new enums added, provided the old
>       enums's values do not change.
>
> Once YANG is widely used, I am sure we will find something somewhere
> relying on this and then we may see rather obscure and hard to debug
> problems. It is not a concrete and urgent issue but I personally am
> happy to have this on a list of things to consider should be ever
> create YANG > 1.0.
>
> /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
>

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


Hi,

It is possible tools are already us=
ing the value-stmt.
Many tools use YANG modules. They are not jus=
t
for the client/server message exchanges.


But I could imagine a mapping to CoAP in which various strings
we=
re automatically converted to numbers somehow.
Most enum values c=
ould be expressed in 1 byte in CoAP using the
value integer.



Andy



On Wed, Jan 22, 2014 at=
 2:55 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs=
-university.de> wrote:


On Wed, Jan 22, 2014 at 05:24:09PM -0500, B =
Lukovic wrote:



> Could you clarify interoperability problem with changing order of enum=
s?

> My understanding is that Netconf mgrs/agents do not use enum value

> in communication.



Correct, it does not impact NETCONF exchanges. But whatever uses the

assigned numerical values may get confused if they change. If nothing

ever uses them, fine. But since YANG 1.0 provides them, there is an

unknown risk. YANG 1.0 makes this promise:



=A0 =A0o =A0An "enumeration" type may have new enums added, provi=
ded the old

=A0 =A0 =A0 enums's values do not change.



Once YANG is widely used, I am sure we will find something somewhere

relying on this and then we may see rather obscure and hard to debug

problems. It is not a concrete and urgent issue but I personally am

happy to have this on a list of things to consider should be ever

create YANG > 1.0.



/js



--

Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German=
y

Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><=
br>
_______________________________________________

netmod mailing list

netmod@ietf.org

=
https://www.ietf.org/mailman/listinfo/netmod





--001a113ab29e91ecd504f0976d8f--

From akatlas@gmail.com  Wed Jan 22 15:29:30 2014
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 A03D71A00C8; Wed, 22 Jan 2014 15:29:30 -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 bFC9yr8s7AZ1; Wed, 22 Jan 2014 15:29:27 -0800 (PST)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id D6DFC1A0256; Wed, 22 Jan 2014 15:29:26 -0800 (PST)
Received: by mail-ig0-f181.google.com with SMTP id j1so3162319iga.2 for ; Wed, 22 Jan 2014 15:29:26 -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:cc:content-type; bh=mwFHlnKWrYuxKhSdhHUbM14rXhZ7hKPmXWECbTfcD7o=; b=te1xCuRh826rCnDJ9rvFEqN6kSrOHWFMxEzxuIZPWffRD5eicgnC7uen++oXlVKRIg V0hs4NcvLX6ykokG/uYXFETr3xLel6h8Ua2fe/5k96PbxCB+c6vwGXeNphB1Lp15FC6Y ox5vYQLJIxNkODBNCR+sRsSRQNH3ksA+BNWYoItN0NlcUghxtlBJL+umvVwf/XKyJ2Rw 0p902uBpdCAcOQXMtXLU7J42x/QQ30OSr838H0nCgQB+IHmS/pQuaesW0kYjfQ7jP1bD VuAt5letWMT9F8QHDpJokXyqx5hVtYeVn9BeNCV/kyh4/JM3sZO+xvXLD6teTSmpoNQc 9LTA==
MIME-Version: 1.0
X-Received: by 10.43.56.4 with SMTP id wa4mr3522148icb.18.1390433366151; Wed, 22 Jan 2014 15:29:26 -0800 (PST)
Received: by 10.64.72.132 with HTTP; Wed, 22 Jan 2014 15:29:26 -0800 (PST)
Date: Wed, 22 Jan 2014 18:29:26 -0500
Message-ID: 
From: Alia Atlas 
To: "rtg-ads@tools.ietf.org" 
Content-Type: multipart/alternative; boundary=bcaec517aa5adf9bce04f0977e48
Cc: "rtg-dir@ietf.org" , "netmod@ietf.org" , draft-ietf-netmod-ip-cfg@tools.ietf.org
Subject: [netmod] RtgDir review: draft-ietf-netmod-ip-cfg-12
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, 22 Jan 2014 23:29:30 -0000

--bcaec517aa5adf9bce04f0977e48
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review. The purpose of
the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-netmod-ip-cfg-12.txt
Reviewer: Alia Atlas
Review Date: 22 January 2014
IETF LC End Date: 23 January 2014
Intended Status: Proposed Standard

*Summary:*
I have a few minor concerns about this document (clarifying a few aspects)
that I think should be resolved before publication.

*Comments:*
This document is very clearly written, but I did find a few details that
could use a bit more clarity.  I was able to figure out what was intended
by wandering through the referenced RFCs.

*Major Issues:*
No major issues found.

*Minor Issues:*


   1. ipv4/forwarding and ipv6/forwarding:  First, I wasn't sure what this
   meant or how it was different from ipv4/enable or ipv6/enable.   I went
   back to look at RFC 4293 to learn that ipv4/forwarding means =93acting a=
s a
   router and forwarding traffic not destined to the device=94.  Could you
   clarify the text to add those key details into the description for
   ipv4/forwarding and ipv6/forwarding?  Second, I was surprised that the
   default is false; I think about this from the router perspective, of
   course, but a bit of explanation as to why that decision was made would =
be
   useful.
   2. ipv4/enabled and ipv6/enabled:  Similarly, what is enabled by
   ipv4/enabled isn=92t clear (unless I look at RFC 4293).   Could you clar=
ify
   that it means connected to an IPv4 stack for sending out IPv4 packets an=
d
   for receiving to-me packets and do the same clarification for ipv6/enabl=
ed?
   3. ipv4/mtu and ipv6/mtu:  This is discussing sending and receiving
   packets =96 a mention of the MRU would be useful and even quoting  RFC24=
60 in
   Sec 5 which says =93From each link to which a node is directly attached,
   the node must be  able to accept packets as large as that link's MTU. =
=93
   so it=92s clear.
   4.  For the ARP cache (ipv4/neighbor) and ND cache (ipv6/neighbor), is
   there a reason that lastUpdated isn=92t included?  This doesn=92t seem t=
o
   provide quite enough information to see whenr mappings were last updated=
?
   Is the assumption that there will be a ARP specific and ND specific YANG
   model for getting the details?

*Nits:*

I've put these as nits because I think that they are probably textual
errors rather than intentional...


   1.  ipv6/forwarding:   why is the reference RFC 4861 =96 neighbor
   discovery???  That seems like it applies to the neighbor info, unless I=
=92ve
   misunderstood what ipv6/forwarding is doing=85
   2. In the second table in Sec 3, ipv4/neighbor/interface and
   ipv6/neighbor/interface are listed, but I don=92t see them in state tree=
 in
   Sec 2.  I think that=92s because they aren=92t necessary??

Regards,
Alia

--bcaec517aa5adf9bce04f0977e48
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Hello,
I have been se=
lected as the Routing Directorate reviewer for this draft. The Routing Dire=
ctorate seeks to review all routing or routing-related drafts as they pass =
through IETF last call and IESG review. The purpose of the review is to pro=
vide assistance to the Routing ADs. For more information about the Routing =
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html


Although these comments are primarily for the use of the R=
outing ADs, it would be helpful if you could consider them along with any o=
ther IETF Last Call comments that you receive, and strive to resolve them t=
hrough discussion or by updating the draft.


Document: draft-ietf-netmod-ip-cfg-12.txt=A0
Reviewer: =
Alia Atlas
Review Date: 22 January 2014=A0
IETF LC End Date: 23 Janua=
ry 2014

Intended Status: Proposed Standard
Summary:=A0
I have a few minor concerns about this document (clarifying a f=
ew aspects) that I think should be resolved before publication.


Comments:=A0
This document is very cle=
arly written, but I did find a few details that could use a bit more clarit=
y. =A0I was able to figure out what was intended by wandering through the r=
eferenced RFCs.


Major Issues:=A0
No major issues found=
.

Minor Issues:=A0
  1. ipv4/forwarding and ipv6/fo=
rwarding: =A0First, I wasn't sure what this meant or how it was differe=
nt from ipv4/enable or ipv6/enable. =A0=A0I went back to=
 look at RFC 4293 to learn that ipv4/forwarding means =93acting as a router=
 and forwarding traffic not destined to the device=94.=A0 Could you clarify=
 the text to add those key details into the description for ipv4/forwarding=
 and ipv6/forwarding? =A0Second, I was surprised that the default is false;=
 I think about this from the router perspective, of course, but a bit of ex=
planation as to why that decision was made would be useful. =A0
    2. 

  2. ipv4/enabled and ipv6/enabled: =A0Similarly, what is enable=
d by ipv4/enabled isn=92t
clear (unless I look at RFC 4293).=A0=A0
Could you clarify that it means connected to an IPv4 stack for sending out
IPv4 packets and for receiving to-me packets and do the same clarification =
for
ipv6/enabled?
  3. ipv4/mtu and ipv6/mtu:=A0 This is discussing sending and re=
ceiving packets =96 a mention of the MRU would be useful and even quoting=
=A0 RFC2460 in Sec 5 which says =93From each li=
nk to which a node is directly attached, the node must be=A0 able to accept=
 packets as large as that link's MTU. =93 so it=92s clear.=A0
    4. 

  4. =A0=
For the ARP cache (ipv4/neighbor) and ND cache
(ipv6/neighbor), is there a reason that lastUpdated isn=92t included?=A0 Th=
is doesn=92t seem to provide quite enough
information to see whenr mappings were last updated?=A0 Is the assumption t=
hat there will be a ARP
specific and ND specific YANG model for getting the details?
    5. Nits:=A0=

    

    I've put these as nits because I think that they a=
re probably textual errors rather than intentional...
    

    1. =A0ipv6/forwarding:=A0=A0 why is the reference R=
FC 4861 =96 neighbor discovery???=A0 That seems like it applies to the neig=
hbor info, unless I=92ve misunderstood what ipv6/forwarding is doing=85
      2. 

    2. I=
n the second table in Sec 3, ipv4/neighbor/interface
and ipv6/neighbor/interface are listed, but I don=92t see them in state tre=
e in
Sec 2.=A0 I think that=92s because they aren=92t
necessary??
    Regards,
    Alia


--bcaec517aa5adf9bce04f0977e48--

From blukovic@ndt-inc.com  Wed Jan 22 15:36:26 2014
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 654B61A051F for ; Wed, 22 Jan 2014 15:36:26 -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, HTML_MESSAGE=0.001, 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 PpRr44QcXnhx for ; Wed, 22 Jan 2014 15:36:24 -0800 (PST)
Received: from mail19a.g19.rapidsite.net (mail19a.g19.rapidsite.net [204.202.242.24]) by ietfa.amsl.com (Postfix) with SMTP id E99B41A0511 for ; Wed, 22 Jan 2014 15:36:23 -0800 (PST)
Received: from mxmtaout03.va1.mxservers.net (208.55.215.50) by mail19a.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 3-0738243783 for ; Wed, 22 Jan 2014 18:36:23 -0500 (EST)
Received: from unknown [161.58.75.15] (EHLO mmm1913.dulles19-verio.com) by mxmtaout03.va1.mxservers.net(mxl_mta-6.15.0-3) with ESMTP id 6f550e25.0.693020.00-492.1066967.mxmtaout03.va1.mxservers.net (envelope-from );  Wed, 22 Jan 2014 18:36:23 -0500 (EST)
X-MXL-Hash: 52e055f75e7bbc06-beb0139da3d48b911535301641c61020f554b4c7
Received: (qmail 25481 invoked from network); 22 Jan 2014 23:36:22 -0000
Received: from unknown (HELO ?192.168.0.21?) (blukovic@135.23.154.141) by  with ESMTPA; 22 Jan 2014 23:36:22 -0000
Message-ID: <52E055F6.80004@ndt-inc.com>
Date: Wed, 22 Jan 2014 18:36:22 -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: andy@yumaworks.com
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>    <20140122165839.GB51297@elstar.local> <52E04509.6010006@ndt-inc.com> <20140122225552.GC51800@elstar.local> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020605040403020504080100"
X-Spam: [F=0.2000000000; CM=0.500; MH=0.500(2014012221); S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [161.58.75.15]
X-AnalysisOut: [v=2.0 cv=frFrkiEf c=1 sm=1 a=IcBn81/O6j4k4bHiM4CBQw==:17 a]
X-AnalysisOut: [=jl2ymW9NZSsA:10 a=ymigdH7LP5EA:10 a=63bDUHjCYPkA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=A1sffi52AAAA:8 a=valQ_CuEJh4A:10 a=j3Z76cjp]
X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=srY38zT5NPC837bN110A:9 a=wPNLvfG]
X-AnalysisOut: [TeEIA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=zeshHG33Dl4]
X-AnalysisOut: [A:10 a=lZB815dzVvQA:10 a=pGLkceISAAAA:8 a=XNLNM5ip1Oi4lnMp]
X-AnalysisOut: [K5cA:9 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=2okZx391wyVqg]
X-AnalysisOut: [WVG:21]
X-SF-Loop: 1
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Wed, 22 Jan 2014 23:36:26 -0000

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

Then the argument expressed by David applies even more.
If Yang is going to be used as data modelling language for various 
protocols
then "value" for "enum" must be mandatory.
This would take away any ambiguity, not to mention simplified enum value 
validation by compiler.

Borislav

On 1/22/2014 6:24 PM, Andy Bierman wrote:
> Hi,
>
> It is possible tools are already using the value-stmt.
> Many tools use YANG modules. They are not just
> for the client/server message exchanges.
>
> But I could imagine a mapping to CoAP in which various strings
> were automatically converted to numbers somehow.
> Most enum values could be expressed in 1 byte in CoAP using the
> value integer.
>
>
> Andy
>
>
>
> On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder 
>  > wrote:
>
>     On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:
>
>     > Could you clarify interoperability problem with changing order
>     of enums?
>     > My understanding is that Netconf mgrs/agents do not use enum value
>     > in communication.
>
>     Correct, it does not impact NETCONF exchanges. But whatever uses the
>     assigned numerical values may get confused if they change. If nothing
>     ever uses them, fine. But since YANG 1.0 provides them, there is an
>     unknown risk. YANG 1.0 makes this promise:
>
>        o  An "enumeration" type may have new enums added, provided the old
>           enums's values do not change.
>
>     Once YANG is widely used, I am sure we will find something somewhere
>     relying on this and then we may see rather obscure and hard to debug
>     problems. It is not a concrete and urgent issue but I personally am
>     happy to have this on a list of things to consider should be ever
>     create YANG > 1.0.
>
>     /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
>
>


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


  
    
  
  
    Then the argument expressed by David applies even more.

    If Yang is going to be used as data modelling language for various
    protocols 

    then "value" for "enum" must be mandatory.

    This would take away any ambiguity, not to mention simplified enum
    value validation by compiler.

    

    Borislav

    

    
On 1/22/2014 6:24 PM, Andy Bierman
      wrote:

    

    

      
Hi,
        


        

        
It is possible tools are already using the value-stmt.

        
Many tools use YANG modules. They are not just

        
for the client/server message exchanges.

        


        

        

          But I could imagine a mapping to CoAP in which various strings

        
were automatically converted to numbers somehow.

        
Most enum values could be expressed in 1 byte in CoAP using
          the

        
value integer.

        


        

        


        

        
Andy

        


        

        

          


            

            
On Wed, Jan 22, 2014 at 2:55 PM,
              Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
              wrote:

              
On
                Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:

                

                > Could you clarify interoperability problem with
                changing order of enums?

                > My understanding is that Netconf mgrs/agents do not
                use enum value

                > in communication.

                

                Correct, it does not impact NETCONF exchanges. But
                whatever uses the

                assigned numerical values may get confused if they
                change. If nothing

                ever uses them, fine. But since YANG 1.0 provides them,
                there is an

                unknown risk. YANG 1.0 makes this promise:

                

                   o  An "enumeration" type may have new enums added,
                provided the old

                      enums's values do not change.

                

                Once YANG is widely used, I am sure we will find
                something somewhere

                relying on this and then we may see rather obscure and
                hard to debug

                problems. It is not a concrete and urgent issue but I
                personally am

                happy to have this on a list of things to consider
                should be ever

                create YANG > 1.0.

                

                    /js

                    

                    --

                    Juergen Schoenwaelder           Jacobs University
                    Bremen gGmbH

                    Phone: +49 421 200 3587         Campus Ring 1, 28759
                    Bremen, Germany

                    Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

                    _______________________________________________

                    netmod mailing list

                    netmod@ietf.org

                    https://www.ietf.org/mailman/listinfo/netmod

                  

            

            

          

        

      

    

    

  


--------------020605040403020504080100--

From andy@yumaworks.com  Wed Jan 22 16:03:03 2014
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 495DD1A01D1 for ; Wed, 22 Jan 2014 16:03:03 -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 WVB9lv1sf3yU for ; Wed, 22 Jan 2014 16:03:01 -0800 (PST)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3461A0171 for ; Wed, 22 Jan 2014 16:03:01 -0800 (PST)
Received: by mail-qa0-f52.google.com with SMTP id j15so1399473qaq.11 for ; Wed, 22 Jan 2014 16:03:00 -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=KuBygOyiYDVL2CRYlr4iAO5ObfZms8APHkjq/wU2a2c=; b=dcVx8ZKhIderJBAxNsXnDq0VD1QDxaL6anhyKUCtgbxf6PYEFVR19qNyGtdz2cy2g0 IVMUHRk6MSnVNhrVnsTLAWtHTimHpx3kXpqLbLjXWc1mYfpiJJMJlQOM/I3QHejMZcwU /P59N0jJSAs4ctO60TVvfYZeZxZAm+b3GZXTXGkVfArnQbdb6WWGRRhX8nUdh8zT1NTO IUkO/XkhRf/daUw4lMuiqNS5gA7gq7EJylQt1ZGJHVYyWDZv5xh9YMISa2xhDHRV3aB9 c7VKSNlf5X7zTZIRss8iwOdDF3KSPU3S4FRFNPPpvc23AR4NyOfP+14h6Y1LowiXKnSR 4fSQ==
X-Gm-Message-State: ALoCoQn6nzZ3rpv3KtoOo1mBqI+M+BpsS4G1jwr7nnHXzHZoEyQWE4ZzZkD39Hj8L7qHCwCXxhLI
MIME-Version: 1.0
X-Received: by 10.140.27.179 with SMTP id 48mr6666570qgx.18.1390435380464; Wed, 22 Jan 2014 16:03:00 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Wed, 22 Jan 2014 16:03:00 -0800 (PST)
In-Reply-To: <52E055F6.80004@ndt-inc.com>
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>    <20140122165839.GB51297@elstar.local> <52E04509.6010006@ndt-inc.com> <20140122225552.GC51800@elstar.local>  <52E055F6.80004@ndt-inc.com>
Date: Wed, 22 Jan 2014 16:03:00 -0800
Message-ID: 
From: Andy Bierman 
To: B Lukovic 
Content-Type: multipart/alternative; boundary=001a11c00434efb9d604f097f620
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Thu, 23 Jan 2014 00:03:03 -0000

--001a11c00434efb9d604f097f620
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 22, 2014 at 3:36 PM, B Lukovic  wrote:

>  Then the argument expressed by David applies even more.
> If Yang is going to be used as data modelling language for various
> protocols
> then "value" for "enum" must be mandatory.
> This would take away any ambiguity, not to mention simplified enum value
> validation by compiler.
>
>
I do not agree.  The meaning of "current highest value" seems to be clear
enough to produce consistent implementations.

The RFC says the value/position values are not allowed to change
in a new revision.  I get it that somebody might violate the rules
specified in the RFC, but that is out of scope.  There are lots of
ways bad things happen if sec. 10 is violated.

There is a mandatory algorithm to follow when the value-stmt is missing,
so there is no problem in the RFC that needs fixing here.



Borislav
>
>

Andy



> On 1/22/2014 6:24 PM, Andy Bierman wrote:
>
> Hi,
>
>  It is possible tools are already using the value-stmt.
> Many tools use YANG modules. They are not just
> for the client/server message exchanges.
>
>  But I could imagine a mapping to CoAP in which various strings
> were automatically converted to numbers somehow.
> Most enum values could be expressed in 1 byte in CoAP using the
> value integer.
>
>
>  Andy
>
>
>
> On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:
>>
>> > Could you clarify interoperability problem with changing order of enums?
>> > My understanding is that Netconf mgrs/agents do not use enum value
>> > in communication.
>>
>> Correct, it does not impact NETCONF exchanges. But whatever uses the
>> assigned numerical values may get confused if they change. If nothing
>> ever uses them, fine. But since YANG 1.0 provides them, there is an
>> unknown risk. YANG 1.0 makes this promise:
>>
>>    o  An "enumeration" type may have new enums added, provided the old
>>       enums's values do not change.
>>
>> Once YANG is widely used, I am sure we will find something somewhere
>> relying on this and then we may see rather obscure and hard to debug
>> problems. It is not a concrete and urgent issue but I personally am
>> happy to have this on a list of things to consider should be ever
>> create YANG > 1.0.
>>
>> /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
>>
>
>
>

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





On Wed, Jan 22, 2014 at 3:36 PM, B Lukovic <blukovic@ndt-inc.co=
m> wrote:



 =20
   =20
 =20
  

    Then the argument expressed by David applies even more.

    If Yang is going to be used as data modelling language for various
    protocols 

    then "value" for "enum" must be mandatory.

    This would take away any ambiguity, not to mention simplified enum
    value validation by compiler.

    

I do not agree. =A0The meani=
ng of "current highest value" seems to be clear
enough =
to produce consistent implementations.

The RFC say=
s the value/position values are not allowed to change


in a new revision. =A0I get it that somebody might violate the rules
specified in the RFC, but that is out of scope. =A0There are lots =
of
ways bad things happen if sec. 10 is violated.

<=
/div>

There is a mandatory algorithm to follow when the value-stmt is missin=
g,
so there is no problem in the RFC that needs fixing here.




    Borislav

    


Andy

=A0


    
On 1/22/2014 6:24 PM, Andy Bierman
      wrote:

    

    

      
Hi,
        


        

        
It is possible tools are already using the value-stmt.

        
Many tools use YANG modules. They are not just

        
for the client/server message exchanges.

        


        

        

          But I could imagine a mapping to CoAP in which various strings
        
were automatically converted to numbers somehow.

        
Most enum values could be expressed in 1 byte in CoAP using
          the

        
value integer.

        


        

        


        

        
Andy

        


        

        

          


            

            
On Wed, Jan 22, 2014 at 2:55 PM,
              Juergen Schoenwaelder <j.schoenwaelder@ja=
cobs-university.de>
              wrote:

              
On
                Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:

                

                > Could you clarify interoperability problem with
                changing order of enums?

                > My understanding is that Netconf mgrs/agents do not
                use enum value

                > in communication.

                

                Correct, it does not impact NETCONF exchanges. But
                whatever uses the

                assigned numerical values may get confused if they
                change. If nothing

                ever uses them, fine. But since YANG 1.0 provides them,
                there is an

                unknown risk. YANG 1.0 makes this promise:

                

                =A0 =A0o =A0An "enumeration" type may have new en=
ums added,
                provided the old

                =A0 =A0 =A0 enums's values do not change.

                

                Once YANG is widely used, I am sure we will find
                something somewhere

                relying on this and then we may see rather obscure and
                hard to debug

                problems. It is not a concrete and urgent issue but I
                personally am

                happy to have this on a list of things to consider
                should be ever

                create YANG > 1.0.

                

                    /js

                    

                    --

                    Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs Univer=
sity
                    Bremen gGmbH

                    Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, =
28759
                    Bremen, Germany

                    Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-u=
niversity.de/>

                    _______________________________________________

                    netmod mailing list

                    ne=
tmod@ietf.org

                    https://www.ietf.org/mailman/listinfo/netmod

                  

            

            

          

        

      

    

    

  






--001a11c00434efb9d604f097f620--

From andy@yumaworks.com  Wed Jan 22 16:14:19 2014
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 BA9491A038D for ; Wed, 22 Jan 2014 16:14:19 -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 qNchDgmRPy9p for ; Wed, 22 Jan 2014 16:14:17 -0800 (PST)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 10E001A01D6 for ; Wed, 22 Jan 2014 16:14:16 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id f11so1372624qae.24 for ; Wed, 22 Jan 2014 16:14:16 -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=CFwa33m0gJ9AQeAp/XHbvYglP1NwMEf020oX8ZpSDbc=; b=I0faNV46ew84pekl6Zc0ySmxNi9hOgd/Z2DApcNy+Jm5WNVQJB6Vgf1jPIt7C/c2UM f+MmxQGOzrh+8PIC7jQWHwT82QBclhLpRPqQBIIiRFj/7834ThF0pQ9GNUtusBT8u4hS Q4VtSuOO2b4+8rTKYk1QWgb2qQ6Vtb5OKBtj8uaZU/+qMze1Z/Ndh8xZohqYb3wCZD5t nhxOTbDj9BwJdeq0POQaGa0YxW7c5msvfbDNEDdjQC5XK0hDsWJaeckZiqNLj7ZIzOto mDafBFWS6M49tHJWEsiRv/Vk/J5/D05FUqDdzuNCNxLDbHXzyV3NhMkHHX9YE9e1P5/W wwug==
X-Gm-Message-State: ALoCoQklFc/GqlJJyO4uY8vcFezttYxMQM/7MMuC6P4tgXiGateSX5/jXv3KqQYkhZ56PEZU+Bfc
MIME-Version: 1.0
X-Received: by 10.224.123.14 with SMTP id n14mr7086605qar.78.1390436056345; Wed, 22 Jan 2014 16:14:16 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Wed, 22 Jan 2014 16:14:16 -0800 (PST)
In-Reply-To: <1926055575-1390435944-cardhu_decombobulator_blackberry.rim.net-1347915928-@b12.c4.bise7.blackberry>
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>    <20140122165839.GB51297@elstar.local> <52E04509.6010006@ndt-inc.com> <20140122225552.GC51800@elstar.local>  <52E055F6.80004@ndt-inc.com>  <1926055575-1390435944-cardhu_decombobulator_blackberry.rim.net-1347915928-@b12.c4.bise7.blackberry>
Date: Wed, 22 Jan 2014 16:14:16 -0800
Message-ID: 
From: Andy Bierman 
To: Jonathan Hansford 
Content-Type: multipart/alternative; boundary=089e0149c2b438c65104f0981fb2
Cc: B Lukovic , netmod , "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Thu, 23 Jan 2014 00:14:20 -0000

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

On Wed, Jan 22, 2014 at 4:12 PM, Jonathan Hansford
wrote:

> Just, possibly, an editorial comment confirming that "current" relates to
> those values, implicit or explicit, prior to the current position in the
> enumeration statement.
>

Agreed -- an RFC Errata should be OK for this one.



> Sent from my BlackBerry
>
> -----Original Message-----
> From: Andy Bierman 
> Sender: "netmod" 
> Date: Wed, 22 Jan 2014 16:03:00
> To: B Lukovic
> Cc: netmod@ietf.org
> Subject: Re: [netmod] enumeration type
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>

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





On Wed, Jan 22, 2014 at 4:12 PM, Jonathan Hansford <jonathan@=
hansfords.net> wrote:


Just, possibly, an editorial comment confirm=
ing that "current" relates to those values, implicit or explicit,=
 prior to the current position in the enumeration statement.



Agreed -- an RFC Errata should be OK for t=
his one.

=A0

Sent from my BlackBerry



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

From: Andy Bierman <andy@yumaworks=
.com>

Sender: "netmod" <n=
etmod-bounces@ietf.org>

Date: Wed, 22 Jan 2014 16:03:00

To: B Lukovic<blukovic@ndt-inc.c=
om>

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

Subject: Re: [netmod] enumeration type

_______________________________________________

netmod mailing list

netmod@ietf.org

=
https://www.ietf.org/mailman/listinfo/netmod









--089e0149c2b438c65104f0981fb2--

From blukovic@ndt-inc.com  Wed Jan 22 17:04:33 2014
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 9C5321A0147 for ; Wed, 22 Jan 2014 17:04:33 -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, HTML_MESSAGE=0.001, 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 U2fSjTJkuMwl for ; Wed, 22 Jan 2014 17:04:31 -0800 (PST)
Received: from mail19e.g19.rapidsite.net (mail19e.g19.rapidsite.net [204.202.242.20]) by ietfa.amsl.com (Postfix) with SMTP id 4765C1A0111 for ; Wed, 22 Jan 2014 17:04:31 -0800 (PST)
Received: from mxmtaout08.va1.mxservers.net (208.55.215.84) by mail19e.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 0-0369989070 for ; Wed, 22 Jan 2014 20:04:30 -0500 (EST)
Received: from unknown [161.58.75.15] (EHLO mmm1913.dulles19-verio.com) by mxmtaout08.va1.mxservers.net(mxl_mta-6.15.0-3) with ESMTP id e9a60e25.0.654919.00-484.995128.mxmtaout08.va1.mxservers.net (envelope-from );  Wed, 22 Jan 2014 20:04:30 -0500 (EST)
X-MXL-Hash: 52e06a9e17c9cba8-4b571be6a344c0ad86b07cf2b17e4ce8c616613f
Received: (qmail 38960 invoked from network); 23 Jan 2014 01:04:30 -0000
Received: from unknown (HELO ?192.168.0.21?) (blukovic@135.23.154.141) by  with ESMTPA; 23 Jan 2014 01:04:30 -0000
Message-ID: <52E06A9D.4090606@ndt-inc.com>
Date: Wed, 22 Jan 2014 20:04:29 -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: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>    <20140122165839.GB51297@elstar.local> <52E04509.6010006@ndt-inc.com> <20140122225552.GC51800@elstar.local>  <52E055F6.80004@ndt-inc.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080103070406080705000106"
X-Spam: [F=0.2000000000; CM=0.500; MH=0.500(2014012222); S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [161.58.75.15]
X-AnalysisOut: [v=2.0 cv=PpkkmXw3 c=1 sm=1 a=IcBn81/O6j4k4bHiM4CBQw==:17 a]
X-AnalysisOut: [=jl2ymW9NZSsA:10 a=ymigdH7LP5EA:10 a=63bDUHjCYPkA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=A1sffi52AAAA:8 a=valQ_CuEJh4A:10 a=j3Z76cjp]
X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=BOq5SBC65mjwLqGAxlgA:9 a=wPNLvfG]
X-AnalysisOut: [TeEIA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=pbPsBPsJn90]
X-AnalysisOut: [A:10 a=zeshHG33Dl4A:10 a=lZB815dzVvQA:10 a=C6u9hcr2fBSWNb-]
X-AnalysisOut: [A:21 a=TmCAQhYA2cfO2Gsk:21 a=pGLkceISAAAA:8 a=uAn4sLilYXIT]
X-AnalysisOut: [cdAugwcA:9 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 a=QdLQI9_f1]
X-AnalysisOut: [_WQwzH9:21 a=ZtF26YETPRtCVbQO:21 a=C-0XLVvmnfIfA-DR:21]
X-SF-Loop: 1
Subject: Re: [netmod] enumeration 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: Thu, 23 Jan 2014 01:04:33 -0000

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

I don't disagree with auto-numbering.
But, there is no guarantee that all C/C++/Java/... compilers would 
produce the enum sequence that correspond to Yang rules,
so in the end implementation would have explicitly assigned values 
(according to Yang rules) to avoid possible bug.
If this is the case, why not specify those values in Yang module itself.

Also,  when Yang module is created from existing "other" data models, in 
particular SNMP MIB,
enumerations should have values specified exactly as in the 
corresponding MIB.
This is not the case in the current release of ietf-snmp Yang modules.

Borislav


On 1/22/2014 7:03 PM, Andy Bierman wrote:
>
>
>
> On Wed, Jan 22, 2014 at 3:36 PM, B Lukovic  > wrote:
>
>     Then the argument expressed by David applies even more.
>     If Yang is going to be used as data modelling language for various
>     protocols
>     then "value" for "enum" must be mandatory.
>     This would take away any ambiguity, not to mention simplified enum
>     value validation by compiler.
>
>
> I do not agree.  The meaning of "current highest value" seems to be clear
> enough to produce consistent implementations.
>
> The RFC says the value/position values are not allowed to change
> in a new revision.  I get it that somebody might violate the rules
> specified in the RFC, but that is out of scope.  There are lots of
> ways bad things happen if sec. 10 is violated.
>
> There is a mandatory algorithm to follow when the value-stmt is missing,
> so there is no problem in the RFC that needs fixing here.
>
>
>
>     Borislav
>
>
>
> Andy
>
>     On 1/22/2014 6:24 PM, Andy Bierman wrote:
>>     Hi,
>>
>>     It is possible tools are already using the value-stmt.
>>     Many tools use YANG modules. They are not just
>>     for the client/server message exchanges.
>>
>>     But I could imagine a mapping to CoAP in which various strings
>>     were automatically converted to numbers somehow.
>>     Most enum values could be expressed in 1 byte in CoAP using the
>>     value integer.
>>
>>
>>     Andy
>>
>>
>>
>>     On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder
>>     >     > wrote:
>>
>>         On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:
>>
>>         > Could you clarify interoperability problem with changing
>>         order of enums?
>>         > My understanding is that Netconf mgrs/agents do not use
>>         enum value
>>         > in communication.
>>
>>         Correct, it does not impact NETCONF exchanges. But whatever
>>         uses the
>>         assigned numerical values may get confused if they change. If
>>         nothing
>>         ever uses them, fine. But since YANG 1.0 provides them, there
>>         is an
>>         unknown risk. YANG 1.0 makes this promise:
>>
>>            o  An "enumeration" type may have new enums added,
>>         provided the old
>>               enums's values do not change.
>>
>>         Once YANG is widely used, I am sure we will find something
>>         somewhere
>>         relying on this and then we may see rather obscure and hard
>>         to debug
>>         problems. It is not a concrete and urgent issue but I
>>         personally am
>>         happy to have this on a list of things to consider should be ever
>>         create YANG > 1.0.
>>
>>         /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


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


  
    
  
  
    I don't disagree with auto-numbering. 

    But, there is no guarantee that all C/C++/Java/... compilers would
    produce the enum sequence that correspond to Yang rules, 

    so in the end implementation would have explicitly assigned values
    (according to Yang rules) to avoid possible bug.

    If this is the case, why not specify those values in Yang module
    itself.

    

    Also,  when Yang module is created from existing "other" data
    models, in particular SNMP MIB, 

    enumerations should have values specified exactly as in the
    corresponding MIB.

    This is not the case in the current release of ietf-snmp Yang
    modules.

    

    Borislav

    

    

    
On 1/22/2014 7:03 PM, Andy Bierman
      wrote:

    

    

      


        


          

          
On Wed, Jan 22, 2014 at 3:36 PM, B
            Lukovic <blukovic@ndt-inc.com>
            wrote:

            

              
 Then the argument
                expressed by David applies even more.

                If Yang is going to be used as data modelling language
                for various protocols 

                then "value" for "enum" must be mandatory.

                This would take away any ambiguity, not to mention
                simplified enum value validation by compiler.

                

              

            

            


            

            
I do not agree.  The meaning of "current highest value"
              seems to be clear

            
enough to produce consistent implementations.

            


            

            
The RFC says the value/position values are not allowed
              to change

            
in a new revision.  I get it that somebody might
              violate the rules

            
specified in the RFC, but that is out of scope.  There
              are lots of

            
ways bad things happen if sec. 10 is violated.

            


            

            
There is a mandatory algorithm to follow when the
              value-stmt is missing,

            
so there is no problem in the RFC that needs fixing
              here.

            


            

            


            

            


            

            

              
 Borislav

                

              

            

            


            

            


            

            
Andy

            


            

            
 

            

              

                
On 1/22/2014 6:24 PM, Andy Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
It is possible tools are already using the
                      value-stmt.

                    
Many tools use YANG modules. They are not just

                    
for the client/server message exchanges.

                    


                    

                    
 But I could imagine a mapping to CoAP in which
                      various strings

                    
were automatically converted to numbers
                      somehow.

                    
Most enum values could be expressed in 1 byte
                      in CoAP using the

                    
value integer.

                    


                    

                    


                    

                    
Andy

                    


                    

                    

                      


                        

                        
On Wed, Jan 22, 2014 at
                          2:55 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
                          wrote:

                          
On Wed, Jan 22,
                            2014 at 05:24:09PM -0500, B Lukovic wrote:

                            

                            > Could you clarify interoperability
                            problem with changing order of enums?

                            > My understanding is that Netconf
                            mgrs/agents do not use enum value

                            > in communication.

                            

                            Correct, it does not impact NETCONF
                            exchanges. But whatever uses the

                            assigned numerical values may get confused
                            if they change. If nothing

                            ever uses them, fine. But since YANG 1.0
                            provides them, there is an

                            unknown risk. YANG 1.0 makes this promise:

                            

                               o  An "enumeration" type may have new
                            enums added, provided the old

                                  enums's values do not change.

                            

                            Once YANG is widely used, I am sure we will
                            find something somewhere

                            relying on this and then we may see rather
                            obscure and hard to debug

                            problems. It is not a concrete and urgent
                            issue but I personally am

                            happy to have this on a list of things to
                            consider should be ever

                            create YANG > 1.0.

                            

                                /js

                                    

                                    --

                                    Juergen Schoenwaelder          
                                    Jacobs University Bremen gGmbH

                                    Phone: +49 421 200 3587        
                                    Campus Ring 1, 28759 Bremen, Germany

                                    Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________

                                    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


    

    

  


--------------080103070406080705000106--

From andy@yumaworks.com  Wed Jan 22 17:25:14 2014
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 4FB3D1A02C8 for ; Wed, 22 Jan 2014 17:25:14 -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 zylT2ZJ_49Ov for ; Wed, 22 Jan 2014 17:25:09 -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 E79311A02B4 for ; Wed, 22 Jan 2014 17:25:08 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id j5so1438160qaq.20 for ; Wed, 22 Jan 2014 17:25:08 -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=D9YcWqvcuLMEjYp8vdEzL4GvIMUU1J5ehnJ6+E4SJGQ=; b=bU8cQwjFGT3lCfddVplLqQDf4b3Qxc/PXMQkzYKddeaTbqBhRfyCDHIAtwMGpygXiO Gh03kaIGJlDR/Ubo8ZisDGYZTMqsmWwt1tX53MbBsJzBozf4mucyZp28kh6qmoCTuMpa Ta9Z9U+cBjdFjgJBSwT+vFd3Q6I2g+9LuZWMvojjm9vFO+zyPmpTBpUHHrByPRzyg9SG wHyJaoYedyZsZRrqdnaOpH7URUccbFda6rt2yFG3ocCjUmZxPhPicdvhyQKDEJ0EXkl3 sWvGyB0A8+xX3yu4V4NYNie4Gl2MdUuumOcLqe3OX1SquKNe2aYhKbGksn0vRNNHZdLb /mwQ==
X-Gm-Message-State: ALoCoQnh5iQxUo6zP5lK+pzQ4SBdsT5SC0wdHCJgq0fZ2J93EmIA5vV9CTKXmQ7QArgeDVtQSxPt
MIME-Version: 1.0
X-Received: by 10.140.23.209 with SMTP id 75mr6955762qgp.94.1390440308104; Wed, 22 Jan 2014 17:25:08 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Wed, 22 Jan 2014 17:25:07 -0800 (PST)
In-Reply-To: <52E06A9D.4090606@ndt-inc.com>
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>    <20140122165839.GB51297@elstar.local> <52E04509.6010006@ndt-inc.com> <20140122225552.GC51800@elstar.local>  <52E055F6.80004@ndt-inc.com>  <52E06A9D.4090606@ndt-inc.com>
Date: Wed, 22 Jan 2014 17:25:07 -0800
Message-ID: 
From: Andy Bierman 
To: B Lukovic 
Content-Type: multipart/alternative; boundary=001a11c13422a6981704f0991cee
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Thu, 23 Jan 2014 01:25:14 -0000

--001a11c13422a6981704f0991cee
Content-Type: text/plain; charset=ISO-8859-1

Hi,

If JAVA or other compilers implement the RFC correctly, then they will
have the correct value numbers for all enums.  This cannot be changed
with an RFC Errata -- the auto-correct can be clarified but the text is
very clear that the value-stmt is optional, so changing it to mandatory
would break existing compliant implementations.


Andy



On Wed, Jan 22, 2014 at 5:04 PM, B Lukovic  wrote:

>  I don't disagree with auto-numbering.
> But, there is no guarantee that all C/C++/Java/... compilers would produce
> the enum sequence that correspond to Yang rules,
> so in the end implementation would have explicitly assigned values
> (according to Yang rules) to avoid possible bug.
> If this is the case, why not specify those values in Yang module itself.
>
> Also,  when Yang module is created from existing "other" data models, in
> particular SNMP MIB,
> enumerations should have values specified exactly as in the corresponding
> MIB.
> This is not the case in the current release of ietf-snmp Yang modules.
>
> Borislav
>
>
> On 1/22/2014 7:03 PM, Andy Bierman wrote:
>
>
>
>
> On Wed, Jan 22, 2014 at 3:36 PM, B Lukovic  wrote:
>
>>  Then the argument expressed by David applies even more.
>> If Yang is going to be used as data modelling language for various
>> protocols
>> then "value" for "enum" must be mandatory.
>> This would take away any ambiguity, not to mention simplified enum value
>> validation by compiler.
>>
>>
>  I do not agree.  The meaning of "current highest value" seems to be clear
> enough to produce consistent implementations.
>
>  The RFC says the value/position values are not allowed to change
> in a new revision.  I get it that somebody might violate the rules
> specified in the RFC, but that is out of scope.  There are lots of
> ways bad things happen if sec. 10 is violated.
>
>  There is a mandatory algorithm to follow when the value-stmt is missing,
> so there is no problem in the RFC that needs fixing here.
>
>
>
>   Borislav
>>
>>
>
>  Andy
>
>
>
>>  On 1/22/2014 6:24 PM, Andy Bierman wrote:
>>
>> Hi,
>>
>>  It is possible tools are already using the value-stmt.
>> Many tools use YANG modules. They are not just
>> for the client/server message exchanges.
>>
>>  But I could imagine a mapping to CoAP in which various strings
>> were automatically converted to numbers somehow.
>> Most enum values could be expressed in 1 byte in CoAP using the
>> value integer.
>>
>>
>>  Andy
>>
>>
>>
>> On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder <
>> j.schoenwaelder@jacobs-university.de> wrote:
>>
>>> On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:
>>>
>>> > Could you clarify interoperability problem with changing order of
>>> enums?
>>> > My understanding is that Netconf mgrs/agents do not use enum value
>>> > in communication.
>>>
>>> Correct, it does not impact NETCONF exchanges. But whatever uses the
>>> assigned numerical values may get confused if they change. If nothing
>>> ever uses them, fine. But since YANG 1.0 provides them, there is an
>>> unknown risk. YANG 1.0 makes this promise:
>>>
>>>    o  An "enumeration" type may have new enums added, provided the old
>>>       enums's values do not change.
>>>
>>> Once YANG is widely used, I am sure we will find something somewhere
>>> relying on this and then we may see rather obscure and hard to debug
>>> problems. It is not a concrete and urgent issue but I personally am
>>> happy to have this on a list of things to consider should be ever
>>> create YANG > 1.0.
>>>
>>> /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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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


Hi,

If JAVA or other compilers im=
plement the RFC correctly, then they will
have the correct value number=
s for all enums. =A0This cannot be changed
with an RFC Errata -- =
the auto-correct can be clarified but the text is


very clear that the value-stmt is optional, so changing it to mandator=
y
would break existing compliant implementations.

<=
/div>

Andy




On Wed, Jan 22, 2014 at 5:04 PM, B Lukovic <=
span dir=3D"ltr"><blukovic@ndt-inc.com> wrote:


 =20
   =20
 =20
  

    I don't disagree with auto-numbering. 

    But, there is no guarantee that all C/C++/Java/... compilers would
    produce the enum sequence that correspond to Yang rules, 

    so in the end implementation would have explicitly assigned values
    (according to Yang rules) to avoid possible bug.

    If this is the case, why not specify those values in Yang module
    itself.

    

    Also,=A0 when Yang module is created from existing "other" da=
ta
    models, in particular SNMP MIB, 

    enumerations should have values specified exactly as in the
    corresponding MIB.

    This is not the case in the current release of ietf-snmp Yang
    modules.

    

    Borislav

    

    

    
On 1/22/2014 7:03 PM, Andy Bierman
      wrote:

    

    

      


        


          

          
On Wed, Jan 22, 2014 at 3:36 PM, B
            Lukovic <blukovic@ndt-inc.com>
            wrote:

            

              
 Then the argument
                expressed by David applies even more.

                If Yang is going to be used as data modelling language
                for various protocols 

                then "value" for "enum" must be mandato=
ry.

                This would take away any ambiguity, not to mention
                simplified enum value validation by compiler.

                

              

            

            


            

            
I do not agree. =A0The meaning of "current highest va=
lue"
              seems to be clear

            
enough to produce consistent implementations.

            


            

            
The RFC says the value/position values are not allowed
              to change

            
in a new revision. =A0I get it that somebody might
              violate the rules

            
specified in the RFC, but that is out of scope. =A0There
              are lots of

            
ways bad things happen if sec. 10 is violated.

            


            

            
There is a mandatory algorithm to follow when the
              value-stmt is missing,

            
so there is no problem in the RFC that needs fixing
              here.

            


            

            


            

            


            

            

              
 Borislav

                

              

            

            


            

            


            

            
Andy

            


            

            
=A0

            

              

                
On 1/22/2014 6:24 PM, Andy Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
It is possible tools are already using the
                      value-stmt.

                    
Many tools use YANG modules. They are not just
                    
for the client/server message exchanges.

                    


                    

                    
 But I could imagine a mapping to CoAP in which
                      various strings

                    
were automatically converted to numbers
                      somehow.

                    
Most enum values could be expressed in 1 byte
                      in CoAP using the

                    
value integer.

                    


                    

                    


                    

                    
Andy

                    


                    

                    

                      


                        

                        
On Wed, Jan 22, 2014 at
                          2:55 PM, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de>
                          wrote:

                          
On Wed, Jan 22,
                            2014 at 05:24:09PM -0500, B Lukovic wrote:

                            

                            > Could you clarify interoperability
                            problem with changing order of enums?

                            > My understanding is that Netconf
                            mgrs/agents do not use enum value

                            > in communication.

                            

                            Correct, it does not impact NETCONF
                            exchanges. But whatever uses the

                            assigned numerical values may get confused
                            if they change. If nothing

                            ever uses them, fine. But since YANG 1.0
                            provides them, there is an

                            unknown risk. YANG 1.0 makes this promise:

                            

                            =A0 =A0o =A0An "enumeration" type may=
 have new
                            enums added, provided the old

                            =A0 =A0 =A0 enums's values do not change.
                            

                            Once YANG is widely used, I am sure we will
                            find something somewhere

                            relying on this and then we may see rather
                            obscure and hard to debug

                            problems. It is not a concrete and urgent
                            issue but I personally am

                            happy to have this on a list of things to
                            consider should be ever

                            create YANG > 1.0.

                            

                                /js

                                    

                                    --

                                    Juergen Schoenwaelder =A0 =A0 =A0 =A0 =
=A0
                                    Jacobs University Bremen gGmbH

                                    Phone: +49 421 200 3587 =A0 =A0 =A0 =A0
                                    Campus Ring 1, 28759 Bremen, Germany
                                    Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =
=A0 <http=
://www.jacobs-university.de/>

_______________________________________________

                                    netmod mailing list

                                    netmod@ietf.org

                                    https://www.ietf.org/mailman/listinfo/n=
etmod

                                  

                           
                         

                          

                    

                  

                

                

              

            

          

          

        

      

      

      

      

      
_______________________________________________
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





--001a11c13422a6981704f0991cee--

From j.schoenwaelder@jacobs-university.de  Wed Jan 22 23:41:41 2014
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 66EBA1A023E for ; Wed, 22 Jan 2014 23:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 jCji203OekEQ for ; Wed, 22 Jan 2014 23:41:39 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1321A005A for ; Wed, 22 Jan 2014 23:41:38 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 871F120076; Thu, 23 Jan 2014 08:41: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 DfI4M01mDj8K; Thu, 23 Jan 2014 08:41: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 A30582006A; Thu, 23 Jan 2014 08:41:36 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C03E12AC843B; Thu, 23 Jan 2014 08:41:33 +0100 (CET)
Date: Thu, 23 Jan 2014 08:41:32 +0100
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20140123074131.GA52688@elstar.local>
Mail-Followup-To: Benoit Claise , Thomas Nadeau , netmod@ietf.org, netmod-chairs@tools.ietf.org, Eliot Lear , Paul Eggert 
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <52DF865F.3020006@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52DF865F.3020006@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod-chairs@tools.ietf.org, Eliot Lear , netmod@ietf.org, Paul Eggert 
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 23 Jan 2014 07:41:41 -0000

On Wed, Jan 22, 2014 at 09:50:39AM +0100, Benoit Claise wrote:
> Tom,
> >	Netmod WG:
> >
> >	The working group chairs have considered the discussion concerning
> >the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
> >draft-ietf-netmod-iana-timezones-03. In particular, we would like
> >like to call consensus on the matter regarding that surfaced during
> >the IETF last call with regard to the the practicability of maintaining a
> >YANG module with an enumeration of timezone names. We believe there is
> >consensus in the working group to move forward with the following
> >resolution:
> >
> >- The YANG module in draft-ietf-netmod-system-mgmt-11 gets
> >extended to introduce a new typedef for timezone names, e.g.
> >something that looks like:
> >
> >   typedef timezone-name {
> >     type string;
> >     description
> >      "A timezone name as used by the Time Zone Database, sometimes
> >       referred to as the 'Olson Database'.";
> >     reference
> >      "RFC 6557: Procedures for Maintaining the Time Zone Database";
> >   }
> >
> >The timezone-location leaf will be changed to use this type,
> >the import of iana-timezones will be removed and the references
> >to I-D.ietf-netmod-iana-timezones will be removed.
> >
> >- The draft-ietf-netmod-iana-timezones-00 document will be pulled
> >back and work on this draft will stop.  The I-D is declared dead.
> >
> >- Since there is nothing to do for IANA, there will be no IANA request
> >needed in this regard for draft-ietf-netmod-system-mgmt-11.
> I'm unclear on what's happening when a timezone name is added,
> removed, modified in the Time Zone Database.
> Or maybe the assumption is that the typedef is always up to date
> with the latest version of the Time Zone Database, on the NETCONF
> client and server?
> I believe It needs a little bit of explanation.

Since the typedef does not attempt to define the set of valid timezone
names, the typedef definition is always up-to-date. We are moving from
compile-time validation to run-time validation.

(Implementations that have been coded to 'understand' this typedef may
 still do some validatation based on whatever information source they
 have access to - its up to implementors to figure this out.)

/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  Thu Jan 23 00:10:47 2014
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 D3B651A02DA for ; Thu, 23 Jan 2014 00:10:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level: 
X-Spam-Status: No, score=-0.886 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.535] 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 E-bOQZJIKQjo for ; Thu, 23 Jan 2014 00:10: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 285961A0075 for ; Thu, 23 Jan 2014 00:10:46 -0800 (PST)
Received: from [192.168.41.135] (outwfguestc.fbk.eu [217.77.82.140]) by mail.nic.cz (Postfix) with ESMTPSA id B76C114050B; Thu, 23 Jan 2014 09:10:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390464645; bh=F2lTxFT2iE2dHTZSuORhNnBg2/0wi2OpThpMN8fgsQA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=eMu86iud9mnLFL9Zz1fEik+YBAl7bOcwgkOn06wDOVe/MCCb0ycjtRMHxWv5Fk07J N85fDm1DDXdgcZ1dmu4ZIW2FDTVfdreALtbdHdtCcv+HXDveWIe9XTe5khrwR4KV2D 1KmTepqNUJya5enZ2XgYOikbF4cyEBbKRXsb9III=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140122225552.GC51800@elstar.local>
Date: Thu, 23 Jan 2014 09:10:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <30210296.1390385843355.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>  <20140122123353.GA50544@elstar.local>    <20140122165839.GB51297@elstar.local> <52E04509.6010006@ndt-inc.com> <20140122225552.GC51800@elstar.local>
To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: B Lukovic , netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Thu, 23 Jan 2014 08:10:48 -0000

On 22 Jan 2014, at 23:55, Juergen Schoenwaelder =
 wrote:

> On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:
>=20
>> Could you clarify interoperability problem with changing order of =
enums?
>> My understanding is that Netconf mgrs/agents do not use enum value
>> in communication.
>=20
> Correct, it does not impact NETCONF exchanges. But whatever uses the
> assigned numerical values may get confused if they change. If nothing
> ever uses them, fine. But since YANG 1.0 provides them, there is an
> unknown risk. YANG 1.0 makes this promise:
>=20
>   o  An "enumeration" type may have new enums added, provided the old
>      enums's values do not change.
>=20
> Once YANG is widely used, I am sure we will find something somewhere

But I think it is important to clarify and rectify things where possible =
*before* this happens. In my view, it is possible to interpret the above =
sec. 10 rule so that it only pertains to old enum values that are =
explicitly present in previous module revisions. This also makes sense: =
If a modeller wants to have the values fixed and standardised, he can =
use the =93value=94 statement. Otherwise, the values may be assigned at =
each implementor=92s discretion, or not assigned at all.

> relying on this and then we may see rather obscure and hard to debug
> problems. It is not a concrete and urgent issue but I personally am
> happy to have this on a list of things to consider should be ever
> create YANG > 1.0.

+1

Lada

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From mbj@tail-f.com  Thu Jan 23 00:59:10 2014
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 3E4291A033F for ; Thu, 23 Jan 2014 00:59:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 uc6mOpCILZDg for ; Thu, 23 Jan 2014 00:59: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 4894A1A033E for ; Thu, 23 Jan 2014 00:59:08 -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 73499240C17B; Thu, 23 Jan 2014 09:59:06 +0100 (CET)
Date: Thu, 23 Jan 2014 09:59:06 +0100 (CET)
Message-Id: <20140123.095906.604677946907611433.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <52E055F6.80004@ndt-inc.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: blukovic@ndt-inc.com, netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Thu, 23 Jan 2014 08:59:10 -0000

I fully agree with Andy.


/martin



Andy Bierman  wrote:
> On Wed, Jan 22, 2014 at 3:36 PM, B Lukovic  wrote:
> 
> >  Then the argument expressed by David applies even more.
> > If Yang is going to be used as data modelling language for various
> > protocols
> > then "value" for "enum" must be mandatory.
> > This would take away any ambiguity, not to mention simplified enum value
> > validation by compiler.
> >
> >
> I do not agree.  The meaning of "current highest value" seems to be clear
> enough to produce consistent implementations.
> 
> The RFC says the value/position values are not allowed to change
> in a new revision.  I get it that somebody might violate the rules
> specified in the RFC, but that is out of scope.  There are lots of
> ways bad things happen if sec. 10 is violated.
> 
> There is a mandatory algorithm to follow when the value-stmt is missing,
> so there is no problem in the RFC that needs fixing here.
> 
> 
> 
> Borislav
> >
> >
> 
> Andy
> 
> 
> 
> > On 1/22/2014 6:24 PM, Andy Bierman wrote:
> >
> > Hi,
> >
> >  It is possible tools are already using the value-stmt.
> > Many tools use YANG modules. They are not just
> > for the client/server message exchanges.
> >
> >  But I could imagine a mapping to CoAP in which various strings
> > were automatically converted to numbers somehow.
> > Most enum values could be expressed in 1 byte in CoAP using the
> > value integer.
> >
> >
> >  Andy
> >
> >
> >
> > On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder <
> > j.schoenwaelder@jacobs-university.de> wrote:
> >
> >> On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:
> >>
> >> > Could you clarify interoperability problem with changing order of enums?
> >> > My understanding is that Netconf mgrs/agents do not use enum value
> >> > in communication.
> >>
> >> Correct, it does not impact NETCONF exchanges. But whatever uses the
> >> assigned numerical values may get confused if they change. If nothing
> >> ever uses them, fine. But since YANG 1.0 provides them, there is an
> >> unknown risk. YANG 1.0 makes this promise:
> >>
> >>    o  An "enumeration" type may have new enums added, provided the old
> >>       enums's values do not change.
> >>
> >> Once YANG is widely used, I am sure we will find something somewhere
> >> relying on this and then we may see rather obscure and hard to debug
> >> problems. It is not a concrete and urgent issue but I personally am
> >> happy to have this on a list of things to consider should be ever
> >> create YANG > 1.0.
> >>
> >> /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 j.schoenwaelder@jacobs-university.de  Thu Jan 23 02:29:55 2014
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 6B6061A03CF for ; Thu, 23 Jan 2014 02:29:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 T9fYPNoBL2su for ; Thu, 23 Jan 2014 02:29: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 14AD81A03CA for ; Thu, 23 Jan 2014 02:29:54 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B9FD20086; Thu, 23 Jan 2014 11:29: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 8KXepFqRGz3r; Thu, 23 Jan 2014 11:29: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 A9B482006A; Thu, 23 Jan 2014 11:29:52 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 456412AC8CFA; Thu, 23 Jan 2014 11:29:50 +0100 (CET)
Date: Thu, 23 Jan 2014 11:29:49 +0100
From: Juergen Schoenwaelder 
To: B Lukovic 
Message-ID: <20140123102949.GB53155@elstar.local>
Mail-Followup-To: B Lukovic , netmod@ietf.org
References:    <20140122165839.GB51297@elstar.local> <52E04509.6010006@ndt-inc.com> <20140122225552.GC51800@elstar.local>  <52E055F6.80004@ndt-inc.com>  <52E06A9D.4090606@ndt-inc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52E06A9D.4090606@ndt-inc.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration type
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, 23 Jan 2014 10:29:55 -0000

On Wed, Jan 22, 2014 at 08:04:29PM -0500, B Lukovic wrote:
 
> Also, when Yang module is created from existing "other" data models,
> in particular SNMP MIB, enumerations should have values specified
> exactly as in the corresponding MIB.  This is not the case in the
> current release of ietf-snmp Yang modules.

Good catch.

I just went through all enumerations in the ietf-snmp-* modules making
sure they have explicit value assignments and that the values match
the values assigned in the MIB modules.

/js

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

From blukovic@ndt-inc.com  Thu Jan 23 06:23:55 2014
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 1B6B11A00BE for ; Thu, 23 Jan 2014 06:23:55 -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 qMq-dmfVu9vi for ; Thu, 23 Jan 2014 06:23:52 -0800 (PST)
Received: from mail19b.g19.rapidsite.net (mail19b.g19.rapidsite.net [204.202.242.88]) by ietfa.amsl.com (Postfix) with SMTP id 5E5181A00FC for ; Thu, 23 Jan 2014 06:23:52 -0800 (PST)
Received: from mxmtaout02.va1.mxservers.net (208.55.215.49) by mail19b.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 0-0551447030 for ; Thu, 23 Jan 2014 09:23:51 -0500 (EST)
Received: from unknown [161.58.75.15] (EHLO mmm1913.dulles19-verio.com) by mxmtaout02.va1.mxservers.net(mxl_mta-6.15.0-3) with ESMTP id 6f521e25.0.718396.00-486.1135147.mxmtaout02.va1.mxservers.net (envelope-from );  Thu, 23 Jan 2014 09:23:51 -0500 (EST)
X-MXL-Hash: 52e125f77c20c626-4fb27795a5d83f03f676d65f003f901bff26a0d0
Received: (qmail 72080 invoked from network); 23 Jan 2014 14:23:50 -0000
Received: from unknown (HELO ?192.168.0.21?) (blukovic@135.23.154.141) by  with ESMTPA; 23 Jan 2014 14:23:50 -0000
Message-ID: <52E125F6.8010507@ndt-inc.com>
Date: Thu, 23 Jan 2014 09:23:50 -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: mbj@tail-f.com
References:  <52E055F6.80004@ndt-inc.com>  <20140123.095906.604677946907611433.mbj@tail-f.com>
In-Reply-To: <20140123.095906.604677946907611433.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam: [F=0.2000000000; CM=0.500; MH=0.500(2014012312); S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [161.58.75.15]
X-AnalysisOut: [v=2.0 cv=QqnpKyOd c=1 sm=1 a=IcBn81/O6j4k4bHiM4CBQw==:17 a]
X-AnalysisOut: [=jl2ymW9NZSsA:10 a=ymigdH7LP5EA:10 a=63bDUHjCYPkA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=A1sffi52AAAA:8 a=valQ_CuE]
X-AnalysisOut: [Jh4A:10 a=xskcdSivAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8]
X-AnalysisOut: [ a=Q5U_EyMDvP1gpXu1SB4A:9 a=wPNLvfGTeEIA:10 a=FvgKqOQ44qUA]
X-AnalysisOut: [:10 a=JrSEOxZJtCQA:10 a=ChEcuLpljosA:10 a=pbPsBPsJn90A:10 ]
X-AnalysisOut: [a=zeshHG33Dl4A:10 a=lZB815dzVvQA:10]
X-SF-Loop: 1
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Thu, 23 Jan 2014 14:23:55 -0000

It seems to me that the whole thread is related to use of Yang data 
model with protocols other than NetConf.
Yet, rfc 6020 states :

YANG is a data modeling language used to model configuration and
state data manipulated by the Network Configuration Protocol
(NETCONF), NETCONF remote procedure calls, and NETCONF notifications.

I am not proposing changing rfc 6020, but since there is an interest in 
using Yang for other protocols,
next revision of it should take into account this discussion.

     Borislav

On 1/23/2014 3:59 AM, Martin Bjorklund wrote:
> I fully agree with Andy.
>
>
> /martin
>
>
>
> Andy Bierman  wrote:
>> On Wed, Jan 22, 2014 at 3:36 PM, B Lukovic  wrote:
>>
>>>   Then the argument expressed by David applies even more.
>>> If Yang is going to be used as data modelling language for various
>>> protocols
>>> then "value" for "enum" must be mandatory.
>>> This would take away any ambiguity, not to mention simplified enum value
>>> validation by compiler.
>>>
>>>
>> I do not agree.  The meaning of "current highest value" seems to be clear
>> enough to produce consistent implementations.
>>
>> The RFC says the value/position values are not allowed to change
>> in a new revision.  I get it that somebody might violate the rules
>> specified in the RFC, but that is out of scope.  There are lots of
>> ways bad things happen if sec. 10 is violated.
>>
>> There is a mandatory algorithm to follow when the value-stmt is missing,
>> so there is no problem in the RFC that needs fixing here.
>>
>>
>>
>> Borislav
>>>
>> Andy
>>
>>
>>
>>> On 1/22/2014 6:24 PM, Andy Bierman wrote:
>>>
>>> Hi,
>>>
>>>   It is possible tools are already using the value-stmt.
>>> Many tools use YANG modules. They are not just
>>> for the client/server message exchanges.
>>>
>>>   But I could imagine a mapping to CoAP in which various strings
>>> were automatically converted to numbers somehow.
>>> Most enum values could be expressed in 1 byte in CoAP using the
>>> value integer.
>>>
>>>
>>>   Andy
>>>
>>>
>>>
>>> On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder <
>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>
>>>> On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:
>>>>
>>>>> Could you clarify interoperability problem with changing order of enums?
>>>>> My understanding is that Netconf mgrs/agents do not use enum value
>>>>> in communication.
>>>> Correct, it does not impact NETCONF exchanges. But whatever uses the
>>>> assigned numerical values may get confused if they change. If nothing
>>>> ever uses them, fine. But since YANG 1.0 provides them, there is an
>>>> unknown risk. YANG 1.0 makes this promise:
>>>>
>>>>     o  An "enumeration" type may have new enums added, provided the old
>>>>        enums's values do not change.
>>>>
>>>> Once YANG is widely used, I am sure we will find something somewhere
>>>> relying on this and then we may see rather obscure and hard to debug
>>>> problems. It is not a concrete and urgent issue but I personally am
>>>> happy to have this on a list of things to consider should be ever
>>>> create YANG > 1.0.
>>>>
>>>> /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 j.schoenwaelder@jacobs-university.de  Thu Jan 23 07:37:10 2014
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 23E641A0038 for ; Thu, 23 Jan 2014 07:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 8xp2kbUXsFwp for ; Thu, 23 Jan 2014 07:37: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 6FE6F1A002A for ; Thu, 23 Jan 2014 07:37:07 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E07A20082; Thu, 23 Jan 2014 16:37:06 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 05_SqdiACwAp; Thu, 23 Jan 2014 16:37:06 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0121820076; Thu, 23 Jan 2014 16:37:04 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 786032AC9576; Thu, 23 Jan 2014 16:37:01 +0100 (CET)
Date: Thu, 23 Jan 2014 16:37:01 +0100
From: Juergen Schoenwaelder 
To: B Lukovic 
Message-ID: <20140123153701.GA53881@elstar.local>
Mail-Followup-To: B Lukovic , mbj@tail-f.com, netmod@ietf.org
References:  <52E055F6.80004@ndt-inc.com>  <20140123.095906.604677946907611433.mbj@tail-f.com> <52E125F6.8010507@ndt-inc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52E125F6.8010507@ndt-inc.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration type
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, 23 Jan 2014 15:37:10 -0000

On Thu, Jan 23, 2014 at 09:23:50AM -0500, B Lukovic wrote:
> 
> It seems to me that the whole thread is related to use of Yang data
> model with protocols other than NetConf.

No, this thread is (was) about whether the text in RFC 6020 is clear
enough or not. And we should wrap that discussion up with either the
conclusion that the text is good enough or with a concrete proposal to
improve clarity that we can agree on and post it at an appropriate
place.

/js

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

From internet-drafts@ietf.org  Thu Jan 23 08:09:26 2014
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 E4CA41A0036; Thu, 23 Jan 2014 08:09:26 -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 wYxLYZdUFjaF; Thu, 23 Jan 2014 08:09:24 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7111A0030; Thu, 23 Jan 2014 08:09:24 -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.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140123160923.14952.12497.idtracker@ietfa.amsl.com>
Date: Thu, 23 Jan 2014 08:09:23 -0800
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-16.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: Thu, 23 Jan 2014 16:09:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the NETCONF Data Modeling Language Working Gr=
oup of the IETF.

        Title           : A YANG Data Model for Interface Management
        Author          : Martin Bjorklund
	Filename        : draft-ietf-netmod-interfaces-cfg-16.txt
	Pages           : 46
	Date            : 2014-01-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-16

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


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 spakes@snmp.com  Thu Jan 23 08:25:56 2014
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 1C8661A0014 for ; Thu, 23 Jan 2014 08:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 JPBHbOWJIgqR for ; Thu, 23 Jan 2014 08:25:54 -0800 (PST)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id EE9E41A0006 for ; Thu, 23 Jan 2014 08:25:53 -0800 (PST)
Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA18086; Thu, 23 Jan 2014 11:25:50 -0500 (EST)
Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA08975; Thu, 23 Jan 2014 11:24:35 -0500 (EST)
X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs
Date: Thu, 23 Jan 2014 11:24:35 -0500 (EST)
From: David Spakes 
X-X-Sender: spakes@adminfs
To: Juergen Schoenwaelder 
In-Reply-To: <20140123153701.GA53881@elstar.local>
Message-ID: 
References:  <52E055F6.80004@ndt-inc.com>  <20140123.095906.604677946907611433.mbj@tail-f.com> <52E125F6.8010507@ndt-inc.com> <20140123153701.GA53881@elstar.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Thu, 23 Jan 2014 16:25:56 -0000

On Tue, Jan 21, 2014 at 3:03 PM, Per Hedeland  wrote:

> On 2014-01-21 18:56, Juergen Schoenwaelder wrote:
>
> > ... I think "current highest value"
> > really was meant to be "the last value (in the order of enum
> > definition)".
>
> Yes, it could also use clarification of "current highest".
>
> --Per


On Thu, 23 Jan 2014, Juergen Schoenwaelder wrote:

> No, this thread is (was) about whether the text in RFC 6020 is clear
> enough or not. And we should wrap that discussion up with either the
> conclusion that the text is good enough or with a concrete proposal to
> improve clarity that we can agree on and post it at an appropriate
> place.


I also agree with Per Hedeland that the text needs to be clarified.
Here is a proposal for sec. 9.6.4.2:

   If a value is not specified, then one will be automatically assigned.
   If the "enum" substatement is the first one defined, the assigned
   value is zero (0); otherwise, the assigned value is one greater than
   the current highest enum value; i.e., the previously encountered or
   previously assigned highest value in order of enum definition.


-dss


-------------------------------------------------------------
 David Spakes                       email:   spakes@snmp.com
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------


From wwwrun@rfc-editor.org  Thu Jan 23 08:57:12 2014
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 690391A0028 for ; Thu, 23 Jan 2014 08:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.953
X-Spam-Level: 
X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-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 LBtqs7M_GD2H for ; Thu, 23 Jan 2014 08:57:11 -0800 (PST)
Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABA41A007B for ; Thu, 23 Jan 2014 08:57:09 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 677B27FC39F; Thu, 23 Jan 2014 08:57:06 -0800 (PST)
To: mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, tnadeau@lucidvision.com
From: RFC Errata System 
Message-Id: <20140123165706.677B27FC39F@rfc-editor.org>
Date: Thu, 23 Jan 2014 08:57:06 -0800 (PST)
Cc: netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Editorial Errata Reported] RFC6020 (3871)
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, 23 Jan 2014 16:57:12 -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=3871

--------------------------------------
Type: Editorial
Reported by: Jonathan Hansford 

Section: 9.6.4.2

Original Text
-------------
If a value is not specified, then one will be automatically assigned.
If the "enum" substatement is the first one defined, the assigned
value is zero (0); otherwise, the assigned value is one greater than
the current highest enum value.

Corrected Text
--------------
If a value is not specified, then one will be automatically assigned.
If the "enum" substatement is the first one defined, the assigned
value is zero (0); otherwise, the assigned value is one greater than
the current highest enum value (that is, the highest enum value,
implicit or explicit, prior to the current "enum" substatement in
the parent "type" statement).

Notes
-----
Clarification that 'current highest' does not refer to all enum values, implicit or explicit, in the parent "type" statement but only to those that precede the current "enum" substatement.

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 Jan 23 08:57:37 2014
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 D9FFB1A00A4 for ; Thu, 23 Jan 2014 08:57:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.953
X-Spam-Level: 
X-Spam-Status: No, score=0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ykJF4JDYVPGu for ; Thu, 23 Jan 2014 08:57:36 -0800 (PST)
Received: from rfc-editor.org (unknown [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 803A11A009D for ; Thu, 23 Jan 2014 08:57:36 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id A8B187FC39F; Thu, 23 Jan 2014 08:57:29 -0800 (PST)
To: mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, j.schoenwaelder@jacobs-university.de, tnadeau@lucidvision.com
From: RFC Errata System 
Message-Id: <20140123165732.A8B187FC39F@rfc-editor.org>
Date: Thu, 23 Jan 2014 08:57:29 -0800 (PST)
Cc: netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Editorial Errata Reported] RFC6020 (3872)
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, 23 Jan 2014 16:57:38 -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=3872

--------------------------------------
Type: Editorial
Reported by: Jonathan Hansford 

Section: 9.7.4.2

Original Text
-------------
If a bit position is not specified, then one will be automatically
assigned. If the "bit" substatement is the first one defined, the
assigned value is zero (0); otherwise, the assigned value is one
greater than the current highest bit position.

Corrected Text
--------------
If a bit position is not specified, then one will be automatically
assigned. If the "bit" substatement is the first one defined, the
assigned value is zero (0); otherwise, the assigned value is one
greater than the current highest bit position (that is, the
highest bit position, implicit or explicit, prior to the current
"bit" substatement in the parent "type" statement).

Notes
-----
Clarification that 'current highest' does not refer to all bit positions, implicit or explicit, in the parent "type" statement but only to those that precede the current "bit" substatement.

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 ietfdbh@comcast.net  Thu Jan 23 09:17:22 2014
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 3AC891A001A for ; Thu, 23 Jan 2014 09:17:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 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.535, 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 VS0w1wSfg9K7 for ; Thu, 23 Jan 2014 09:17:17 -0800 (PST)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 30C6E1A00E0 for ; Thu, 23 Jan 2014 09:17:17 -0800 (PST)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta08.westchester.pa.mail.comcast.net with comcast id HRyo1n00116LCl058VHGLR; Thu, 23 Jan 2014 17:17:16 +0000
Received: from [192.168.0.11] ([72.187.162.59]) by omta06.westchester.pa.mail.comcast.net with comcast id HVGa1n0091HC2N03SVGfpi; Thu, 23 Jan 2014 17:17:11 +0000
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=us-ascii
From: David Harrington 
In-Reply-To: <20140123.095906.604677946907611433.mbj@tail-f.com>
Date: Thu, 23 Jan 2014 12:16:33 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <9E4ADC55-6A9B-4EED-8B93-1ED78A01086A@comcast.net>
References:  <52E055F6.80004@ndt-inc.com>  <20140123.095906.604677946907611433.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1510)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390497436; bh=35g0JaxDvcwLuVy/6m6Mv8qbVYGw2UubLK9Np1Nf2sk=; h=Received:Received:Subject:Mime-Version:Content-Type:From:Date: Message-Id:To; b=OkesA87FK9oxrQu1/cRwh1DZ0/6bmCAiA4+tE+A7vprJ8IbmvR7pC9rjVSnPhpIT6 Mr4XudecKRMUKTLgNqcUzC6fa7+HJ0eyHKDJ89TZMVpsh1856Z/ctoqDifO+IyditX a+tYSIQVBx9+ERNMErb2xanNNDlqwQOcMI/bcr4xcgrDglPj77IEGFAQQ0DYABDFW5 AkyRsh/QZoiRAvMKUwrLI+D3n+KNlkZagZeUJKzO5hWKXCpk1JMzFrg6KBOG2x5V89 rs/7fXVmhJ1kSOGj2wKoH0MFXkZW8z7CVrBCqStNdB7rydbgSaoHIzn8fsaxdolLZj 0c6Lsy6jux/Mw==
Cc: blukovic@ndt-inc.com, netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Thu, 23 Jan 2014 17:17:22 -0000

Hi,

I have a concern with changing value of enums and the impact on =
interoperability between NMS applications and YANG modules.

Drawing on SNMP experience, we have one case that has been especially =
problematic - the dynamic assignment of ifIndex values. NMS applications =
that cache information (or build database records of information) =
provided by the IF-MIB, or any MIB that uses ifIndex as a way to create =
a relation between sets of data, have had problems with the =
discontinuity and subsequent changes to remotely-assigned ifIndex =
values.=20

Interoperability for both SNMP and NETCONF (and other NMS protocols) is =
often related to being able to store and reference data on the NMS side =
by enumerated values contained in the data assigned by the agent =
(server).
I recommend that the interoperability issues associated with dynamically =
changing enums be discussed, possibly in an "operations and management =
considerations" section.

dbh


On Jan 23, 2014, at 3:59 AM, Martin Bjorklund  wrote:

> I fully agree with Andy.
>=20
>=20
> /martin
>=20
>=20
>=20
> Andy Bierman  wrote:
>> On Wed, Jan 22, 2014 at 3:36 PM, B Lukovic  =
wrote:
>>=20
>>> Then the argument expressed by David applies even more.
>>> If Yang is going to be used as data modelling language for various
>>> protocols
>>> then "value" for "enum" must be mandatory.
>>> This would take away any ambiguity, not to mention simplified enum =
value
>>> validation by compiler.
>>>=20
>>>=20
>> I do not agree.  The meaning of "current highest value" seems to be =
clear
>> enough to produce consistent implementations.
>>=20
>> The RFC says the value/position values are not allowed to change
>> in a new revision.  I get it that somebody might violate the rules
>> specified in the RFC, but that is out of scope.  There are lots of
>> ways bad things happen if sec. 10 is violated.
>>=20
>> There is a mandatory algorithm to follow when the value-stmt is =
missing,
>> so there is no problem in the RFC that needs fixing here.
>>=20
>>=20
>>=20
>> Borislav
>>>=20
>>>=20
>>=20
>> Andy
>>=20
>>=20
>>=20
>>> On 1/22/2014 6:24 PM, Andy Bierman wrote:
>>>=20
>>> Hi,
>>>=20
>>> It is possible tools are already using the value-stmt.
>>> Many tools use YANG modules. They are not just
>>> for the client/server message exchanges.
>>>=20
>>> But I could imagine a mapping to CoAP in which various strings
>>> were automatically converted to numbers somehow.
>>> Most enum values could be expressed in 1 byte in CoAP using the
>>> value integer.
>>>=20
>>>=20
>>> Andy
>>>=20
>>>=20
>>>=20
>>> On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder <
>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>=20
>>>> On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:
>>>>=20
>>>>> Could you clarify interoperability problem with changing order of =
enums?
>>>>> My understanding is that Netconf mgrs/agents do not use enum value
>>>>> in communication.
>>>>=20
>>>> Correct, it does not impact NETCONF exchanges. But whatever uses =
the
>>>> assigned numerical values may get confused if they change. If =
nothing
>>>> ever uses them, fine. But since YANG 1.0 provides them, there is an
>>>> unknown risk. YANG 1.0 makes this promise:
>>>>=20
>>>>   o  An "enumeration" type may have new enums added, provided the =
old
>>>>      enums's values do not change.
>>>>=20
>>>> Once YANG is widely used, I am sure we will find something =
somewhere
>>>> relying on this and then we may see rather obscure and hard to =
debug
>>>> problems. It is not a concrete and urgent issue but I personally am
>>>> happy to have this on a list of things to consider should be ever
>>>> create YANG > 1.0.
>>>>=20
>>>> /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
>>>>=20
>>>=20
>>>=20
>>>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From andy@yumaworks.com  Thu Jan 23 10:02:00 2014
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 9B0621A000A for ; Thu, 23 Jan 2014 10:02: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 zBBFBYB1qCQF for ; Thu, 23 Jan 2014 10:01:55 -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 40B6C1A0052 for ; Thu, 23 Jan 2014 10:01:55 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id j5so2572471qaq.6 for ; Thu, 23 Jan 2014 10:01: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:cc:content-type; bh=KxeKVRZ1zF2LNpVew5YB04ITw9xn2S5zV5rjFYHswx8=; b=gx4IOneoCzv8Bw3cLL1pOqCI31rnb0E0ALVOeVqW0c+dAh1rYyCS/pkKvTFjh9K1k3 hrkM5n3Xk8ezaUgSpJjLtPjwkB2W0iN0V31rLrgqRQm22OpS/oowjYjNmYqdeq9RSCr4 BdbRESy24QQ0WVdAIpHUr/4V2mYHFxLjWM2M74A1VmXunk75ArO1GGn3JluzVqXcMvm4 qx5NE8Dzbbia4gtciL1CioHG8EAtq4cL+YNqmV4P3Ijjoe8tzTKC9+uyeKEk21aNybzB 6EDrASXwoSiIRy/lejsQUPo/Bsn89zwS64mTz8MqJr9MZz8FuteHpMMKoeT9b23D4EVU 15bQ==
X-Gm-Message-State: ALoCoQmXpWj22qQBkulQg3fKwq5yo/kw8CSWT+uFvOHiq5llQt0X35HVlZY9JXvNZtUyTZQKns7W
MIME-Version: 1.0
X-Received: by 10.140.92.65 with SMTP id a59mr12900682qge.34.1390500114016; Thu, 23 Jan 2014 10:01:54 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 23 Jan 2014 10:01:53 -0800 (PST)
In-Reply-To: <9E4ADC55-6A9B-4EED-8B93-1ED78A01086A@comcast.net>
References:  <52E055F6.80004@ndt-inc.com>  <20140123.095906.604677946907611433.mbj@tail-f.com> <9E4ADC55-6A9B-4EED-8B93-1ED78A01086A@comcast.net>
Date: Thu, 23 Jan 2014 10:01:53 -0800
Message-ID: 
From: Andy Bierman 
To: David Harrington 
Content-Type: multipart/alternative; boundary=001a113ab29e5b401404f0a70978
Cc: B Lukovic , "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Thu, 23 Jan 2014 18:02:00 -0000

--001a113ab29e5b401404f0a70978
Content-Type: text/plain; charset=ISO-8859-1

Hi,


You seem to be referring to server-assigned ifIndex values.
I agree that persistence of such values should be addressed
in our standards. IMO, NETCONF does not deal with server-assigned
values very well. (is it config, is it state? We do not agree even on that).

This thread is about the schema definitions of enumeration values
that are auto-assigned by the YANG compiler.


Andy



On Thu, Jan 23, 2014 at 9:16 AM, David Harrington wrote:

> Hi,
>
> I have a concern with changing value of enums and the impact on
> interoperability between NMS applications and YANG modules.
>
> Drawing on SNMP experience, we have one case that has been especially
> problematic - the dynamic assignment of ifIndex values. NMS applications
> that cache information (or build database records of information) provided
> by the IF-MIB, or any MIB that uses ifIndex as a way to create a relation
> between sets of data, have had problems with the discontinuity and
> subsequent changes to remotely-assigned ifIndex values.
>
> Interoperability for both SNMP and NETCONF (and other NMS protocols) is
> often related to being able to store and reference data on the NMS side by
> enumerated values contained in the data assigned by the agent (server).
> I recommend that the interoperability issues associated with dynamically
> changing enums be discussed, possibly in an "operations and management
> considerations" section.
>
> dbh
>
>
> On Jan 23, 2014, at 3:59 AM, Martin Bjorklund  wrote:
>
> > I fully agree with Andy.
> >
> >
> > /martin
> >
> >
> >
> > Andy Bierman  wrote:
> >> On Wed, Jan 22, 2014 at 3:36 PM, B Lukovic 
> wrote:
> >>
> >>> Then the argument expressed by David applies even more.
> >>> If Yang is going to be used as data modelling language for various
> >>> protocols
> >>> then "value" for "enum" must be mandatory.
> >>> This would take away any ambiguity, not to mention simplified enum
> value
> >>> validation by compiler.
> >>>
> >>>
> >> I do not agree.  The meaning of "current highest value" seems to be
> clear
> >> enough to produce consistent implementations.
> >>
> >> The RFC says the value/position values are not allowed to change
> >> in a new revision.  I get it that somebody might violate the rules
> >> specified in the RFC, but that is out of scope.  There are lots of
> >> ways bad things happen if sec. 10 is violated.
> >>
> >> There is a mandatory algorithm to follow when the value-stmt is missing,
> >> so there is no problem in the RFC that needs fixing here.
> >>
> >>
> >>
> >> Borislav
> >>>
> >>>
> >>
> >> Andy
> >>
> >>
> >>
> >>> On 1/22/2014 6:24 PM, Andy Bierman wrote:
> >>>
> >>> Hi,
> >>>
> >>> It is possible tools are already using the value-stmt.
> >>> Many tools use YANG modules. They are not just
> >>> for the client/server message exchanges.
> >>>
> >>> But I could imagine a mapping to CoAP in which various strings
> >>> were automatically converted to numbers somehow.
> >>> Most enum values could be expressed in 1 byte in CoAP using the
> >>> value integer.
> >>>
> >>>
> >>> Andy
> >>>
> >>>
> >>>
> >>> On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder <
> >>> j.schoenwaelder@jacobs-university.de> wrote:
> >>>
> >>>> On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:
> >>>>
> >>>>> Could you clarify interoperability problem with changing order of
> enums?
> >>>>> My understanding is that Netconf mgrs/agents do not use enum value
> >>>>> in communication.
> >>>>
> >>>> Correct, it does not impact NETCONF exchanges. But whatever uses the
> >>>> assigned numerical values may get confused if they change. If nothing
> >>>> ever uses them, fine. But since YANG 1.0 provides them, there is an
> >>>> unknown risk. YANG 1.0 makes this promise:
> >>>>
> >>>>   o  An "enumeration" type may have new enums added, provided the old
> >>>>      enums's values do not change.
> >>>>
> >>>> Once YANG is widely used, I am sure we will find something somewhere
> >>>> relying on this and then we may see rather obscure and hard to debug
> >>>> problems. It is not a concrete and urgent issue but I personally am
> >>>> happy to have this on a list of things to consider should be ever
> >>>> create YANG > 1.0.
> >>>>
> >>>> /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
>
>

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


Hi,


You seem to be refer=
ring to server-assigned ifIndex values.
I agree that persistence =
of such values should be addressed
in our standards. IMO, NETCONF=
 does not deal with server-assigned


values very well. (is it config, is it state? We do not agree even on =
that).

This thread is about the schema definitions=
 of enumeration values
that are auto-assigned by the YANG com=
piler.




Andy



On Thu, Jan 23, 2014 a=
t 9:16 AM, David Harrington <ietfdbh@comcast.net> wrote:

Hi,



I have a concern with changing value of enums and the impact on interoperab=
ility between NMS applications and YANG modules.



Drawing on SNMP experience, we have one case that has been especially probl=
ematic - the dynamic assignment of ifIndex values. NMS applications that ca=
che information (or build database records of information) provided by the =
IF-MIB, or any MIB that uses ifIndex as a way to create a relation between =
sets of data, have had problems with the discontinuity and subsequent chang=
es to remotely-assigned ifIndex values.




Interoperability for both SNMP and NETCONF (and other NMS protocols) is oft=
en related to being able to store and reference data on the NMS side by enu=
merated values contained in the data assigned by the agent (server).


I recommend that the interoperability issues associated with dynamically ch=
anging enums be discussed, possibly in an "operations and management c=
onsiderations" section.



dbh





On Jan 23, 2014, at 3:59 AM, Martin Bjorklund <mbj@tail-f.com> wrote:



> I fully agree with Andy.

>

>

> /martin

>

>

>

> Andy Bierman <andy@yumaworks.=
com> wrote:

>> On Wed, Jan 22, 2014 at 3:36 PM, B Lukovic <blukovic@ndt-inc.com> wrote:

>>

>>> Then the argument expressed by David applies even more.

>>> If Yang is going to be used as data modelling language for var=
ious

>>> protocols

>>> then "value" for "enum" must be mandatory.=


>>> This would take away any ambiguity, not to mention simplified =
enum value

>>> validation by compiler.

>>>

>>>

>> I do not agree. =A0The meaning of "current highest value"=
; seems to be clear

>> enough to produce consistent implementations.

>>

>> The RFC says the value/position values are not allowed to change
>> in a new revision. =A0I get it that somebody might violate the rul=
es

>> specified in the RFC, but that is out of scope. =A0There are lots =
of

>> ways bad things happen if sec. 10 is violated.

>>

>> There is a mandatory algorithm to follow when the value-stmt is mi=
ssing,

>> so there is no problem in the RFC that needs fixing here.

>>

>>

>>

>> Borislav

>>>

>>>

>>

>> Andy

>>

>>

>>

>>> On 1/22/2014 6:24 PM, Andy Bierman wrote:

>>>

>>> Hi,

>>>

>>> It is possible tools are already using the value-stmt.

>>> Many tools use YANG modules. They are not just

>>> for the client/server message exchanges.

>>>

>>> But I could imagine a mapping to CoAP in which various strings=


>>> were automatically converted to numbers somehow.

>>> Most enum values could be expressed in 1 byte in CoAP using th=
e

>>> value integer.

>>>

>>>

>>> Andy

>>>

>>>

>>>

>>> On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder <
>>> j.scho=
enwaelder@jacobs-university.de> wrote:

>>>

>>>> On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:=


>>>>

>>>>> Could you clarify interoperability problem with changi=
ng order of enums?

>>>>> My understanding is that Netconf mgrs/agents do not us=
e enum value

>>>>> in communication.

>>>>

>>>> Correct, it does not impact NETCONF exchanges. But whateve=
r uses the

>>>> assigned numerical values may get confused if they change.=
 If nothing

>>>> ever uses them, fine. But since YANG 1.0 provides them, th=
ere is an

>>>> unknown risk. YANG 1.0 makes this promise:

>>>>

>>>> =A0 o =A0An "enumeration" type may have new enum=
s added, provided the old

>>>> =A0 =A0 =A0enums's values do not change.

>>>>

>>>> Once YANG is widely used, I am sure we will find something=
 somewhere

>>>> relying on this and then we may see rather obscure and har=
d to debug

>>>> problems. It is not a concrete and urgent issue but I pers=
onally am

>>>> happy to have this on a list of things to consider should =
be ever

>>>> create YANG > 1.0.

>>>>

>>>> /js

>>>>

>>>> --

>>>> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs Universit=
y Bremen gGmbH

>>>> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 287=
59 Bremen, Germany

>>>> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-univer=
sity.de/>

>>>> _______________________________________________

>>>> 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







--001a113ab29e5b401404f0a70978--

From bclaise@cisco.com  Fri Jan 24 02:19:31 2014
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 2A66E1A0218 for ; Fri, 24 Jan 2014 02:19:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.036
X-Spam-Level: 
X-Spam-Status: No, score=-10.036 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.535, 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 rJPGvCJuLyDK for ; Fri, 24 Jan 2014 02:19: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 50D0C1A018D for ; Fri, 24 Jan 2014 02:19:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2483; q=dns/txt; s=iport; t=1390558768; x=1391768368; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=r5ySDMO3hvzPQQCUJDKzJO7aJsMo3cliE1Dm07vQhPM=; b=f+9O3e+SeQR6FK+2WUxBJPElKUPB6Fp6LvUHqSgLcLeFZ4rHTV1fMxlq xZZjNWk4rzAQZ02B7AucX4T6YNoRDya/pReFhts5T0FxGSE9gU+7aTVDS 29oM+gf4RNTIMW6TAn9Y10A7cfg1iYRUfuZBu8DeWQWlAMDgyCLsfH05u I=;
X-IronPort-AV: E=Sophos;i="4.95,712,1384300800";  d="scan'208";a="3451830"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 24 Jan 2014 10:19:26 +0000
Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0OAJQLC029137; Fri, 24 Jan 2014 10:19:26 GMT
Message-ID: <52E23E2E.3060806@cisco.com>
Date: Fri, 24 Jan 2014 11:19:26 +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: Thomas Nadeau , netmod@ietf.org, netmod-chairs@tools.ietf.org, Eliot Lear , Paul Eggert 
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <52DF865F.3020006@cisco.com> <20140123074131.GA52688@elstar.local>
In-Reply-To: <20140123074131.GA52688@elstar.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 24 Jan 2014 10:19:31 -0000

On 23/01/2014 08:41, Juergen Schoenwaelder wrote:
> On Wed, Jan 22, 2014 at 09:50:39AM +0100, Benoit Claise wrote:
>> Tom,
>>> 	Netmod WG:
>>>
>>> 	The working group chairs have considered the discussion concerning
>>> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
>>> draft-ietf-netmod-iana-timezones-03. In particular, we would like
>>> like to call consensus on the matter regarding that surfaced during
>>> the IETF last call with regard to the the practicability of maintaining a
>>> YANG module with an enumeration of timezone names. We believe there is
>>> consensus in the working group to move forward with the following
>>> resolution:
>>>
>>> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets
>>> extended to introduce a new typedef for timezone names, e.g.
>>> something that looks like:
>>>
>>>    typedef timezone-name {
>>>      type string;
>>>      description
>>>       "A timezone name as used by the Time Zone Database, sometimes
>>>        referred to as the 'Olson Database'.";
>>>      reference
>>>       "RFC 6557: Procedures for Maintaining the Time Zone Database";
>>>    }
>>>
>>> The timezone-location leaf will be changed to use this type,
>>> the import of iana-timezones will be removed and the references
>>> to I-D.ietf-netmod-iana-timezones will be removed.
>>>
>>> - The draft-ietf-netmod-iana-timezones-00 document will be pulled
>>> back and work on this draft will stop.  The I-D is declared dead.
>>>
>>> - Since there is nothing to do for IANA, there will be no IANA request
>>> needed in this regard for draft-ietf-netmod-system-mgmt-11.
>> I'm unclear on what's happening when a timezone name is added,
>> removed, modified in the Time Zone Database.
>> Or maybe the assumption is that the typedef is always up to date
>> with the latest version of the Time Zone Database, on the NETCONF
>> client and server?
>> I believe It needs a little bit of explanation.
> Since the typedef does not attempt to define the set of valid timezone
> names, the typedef definition is always up-to-date. We are moving from
> compile-time validation to run-time validation.
Thanks.
>
> (Implementations that have been coded to 'understand' this typedef may
>   still do some validatation based on whatever information source they
>   have access to - its up to implementors to figure this out.)
This is what needs to be explained in the draft.

Regards, Benoit
>
> /js
>


From j.schoenwaelder@jacobs-university.de  Fri Jan 24 15:04:59 2014
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 71D9F1A01F9 for ; Fri, 24 Jan 2014 15:04:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 Z1DFSzukyDw3 for ; Fri, 24 Jan 2014 15:04:58 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id F0DF11A01F5 for ; Fri, 24 Jan 2014 15:04:57 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6436320053; Sat, 25 Jan 2014 00:04:56 +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 DCpHk4Og-X1W; Sat, 25 Jan 2014 00:04:56 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C90A420051; Sat, 25 Jan 2014 00:04:55 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 190022ACE431; Sat, 25 Jan 2014 00:04:53 +0100 (CET)
Date: Sat, 25 Jan 2014 00:04:53 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20140124230453.GA65851@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] consensus on errata (was enumeration type)
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, 24 Jan 2014 23:04:59 -0000

Hi,

do we have concensus on errata 3871 and 3872?

  http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3871
  http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3872

Should it be marked as 'Verified'?

/js

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

From spakes@snmp.com  Fri Jan 24 15:21:57 2014
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 3EC4B1A0202 for ; Fri, 24 Jan 2014 15:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 QymYKHUL-J6h for ; Fri, 24 Jan 2014 15:21:55 -0800 (PST)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 505C81A01F0 for ; Fri, 24 Jan 2014 15:21:55 -0800 (PST)
Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id SAA03899; Fri, 24 Jan 2014 18:21:52 -0500 (EST)
Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id SAA22138; Fri, 24 Jan 2014 18:21:50 -0500 (EST)
X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs
Date: Fri, 24 Jan 2014 18:21:50 -0500 (EST)
From: David Spakes 
X-X-Sender: spakes@adminfs
To: Juergen Schoenwaelder 
In-Reply-To: <20140124230453.GA65851@elstar.local>
Message-ID: 
References: <20140124230453.GA65851@elstar.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: netmod@ietf.org
Subject: Re: [netmod] consensus on errata (was enumeration 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, 24 Jan 2014 23:21:57 -0000

On Sat, 25 Jan 2014, Juergen Schoenwaelder wrote:

> Hi,
>
> do we have concensus on errata 3871 and 3872?
>
>   http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3871
>   http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3872
>
> Should it be marked as 'Verified'?
>
> /js


I made a proposal based on the posts of three contributors, including
myself.  The text of my proposal is essentially the same as Jonathan's
errata text.  If there are no objections, then as far as I am concerned,
it is verified, and there is concensus.

-dss



-------------------------------------------------------------
 David Spakes                       email:   spakes@snmp.com
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------


From lhotka@nic.cz  Fri Jan 24 23:53:31 2014
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 525851A016D for ; Fri, 24 Jan 2014 23:53:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 b5W-dfE4V1W2 for ; Fri, 24 Jan 2014 23:53:29 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id F3E561A015D for ; Fri, 24 Jan 2014 23:53:28 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6D62A13F6B3; Sat, 25 Jan 2014 08:53:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390636406; bh=Eh6GCvx9ky28CBDDzodx6XWBgeb30y56QVDXVPdscyk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rrBFa0DF8+SZ//LucrK4g4OQDiz4MzSEREczhwNAa5+CdIVUC70KyqWY5jgnN63+g KXU6uQCJ6BZQ2Ah+ZK3j990dbbHq9zC733+uu+yLp1BJmlTcRW2iHyv8bAXmRL7h4I NdicoDLS5T4Nk/PDSDWZRwupVqg25zkalqRzDrhs=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <52E125F6.8010507@ndt-inc.com>
Date: Sat, 25 Jan 2014 08:53:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <52E055F6.80004@ndt-inc.com>  <20140123.095906.604677946907611433.mbj@tail-f.com> <52E125F6.8010507@ndt-inc.com>
To: B Lukovic 
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] enumeration 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: Sat, 25 Jan 2014 07:53:31 -0000

On 23 Jan 2014, at 15:23, B Lukovic  wrote:

>=20
> It seems to me that the whole thread is related to use of Yang data =
model with protocols other than NetConf.
> Yet, rfc 6020 states :
>=20
> YANG is a data modeling language used to model configuration and
> state data manipulated by the Network Configuration Protocol
> (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.

It is not only this verbal definition, other fundamental YANG concepts =
are defined using NETCONF-specific terms. For example, second bullet in =
sec. 8.1:

   o  If the constraint is defined on state data, it MUST be true in a
      reply to a  operation without a filter.

>=20
> I am not proposing changing rfc 6020, but since there is an interest =
in using Yang for other protocols,
> next revision of it should take into account this discussion.

In Berlin (IETF 87), I proposed to start work on a new YANG spec that =
would, among other things, remove such NETCONF dependences.

Lada

>=20
>    Borislav
>=20
> On 1/23/2014 3:59 AM, Martin Bjorklund wrote:
>> I fully agree with Andy.
>>=20
>>=20
>> /martin
>>=20
>>=20
>>=20
>> Andy Bierman  wrote:
>>> On Wed, Jan 22, 2014 at 3:36 PM, B Lukovic  =
wrote:
>>>=20
>>>>  Then the argument expressed by David applies even more.
>>>> If Yang is going to be used as data modelling language for various
>>>> protocols
>>>> then "value" for "enum" must be mandatory.
>>>> This would take away any ambiguity, not to mention simplified enum =
value
>>>> validation by compiler.
>>>>=20
>>>>=20
>>> I do not agree.  The meaning of "current highest value" seems to be =
clear
>>> enough to produce consistent implementations.
>>>=20
>>> The RFC says the value/position values are not allowed to change
>>> in a new revision.  I get it that somebody might violate the rules
>>> specified in the RFC, but that is out of scope.  There are lots of
>>> ways bad things happen if sec. 10 is violated.
>>>=20
>>> There is a mandatory algorithm to follow when the value-stmt is =
missing,
>>> so there is no problem in the RFC that needs fixing here.
>>>=20
>>>=20
>>>=20
>>> Borislav
>>>>=20
>>> Andy
>>>=20
>>>=20
>>>=20
>>>> On 1/22/2014 6:24 PM, Andy Bierman wrote:
>>>>=20
>>>> Hi,
>>>>=20
>>>>  It is possible tools are already using the value-stmt.
>>>> Many tools use YANG modules. They are not just
>>>> for the client/server message exchanges.
>>>>=20
>>>>  But I could imagine a mapping to CoAP in which various strings
>>>> were automatically converted to numbers somehow.
>>>> Most enum values could be expressed in 1 byte in CoAP using the
>>>> value integer.
>>>>=20
>>>>=20
>>>>  Andy
>>>>=20
>>>>=20
>>>>=20
>>>> On Wed, Jan 22, 2014 at 2:55 PM, Juergen Schoenwaelder <
>>>> j.schoenwaelder@jacobs-university.de> wrote:
>>>>=20
>>>>> On Wed, Jan 22, 2014 at 05:24:09PM -0500, B Lukovic wrote:
>>>>>=20
>>>>>> Could you clarify interoperability problem with changing order of =
enums?
>>>>>> My understanding is that Netconf mgrs/agents do not use enum =
value
>>>>>> in communication.
>>>>> Correct, it does not impact NETCONF exchanges. But whatever uses =
the
>>>>> assigned numerical values may get confused if they change. If =
nothing
>>>>> ever uses them, fine. But since YANG 1.0 provides them, there is =
an
>>>>> unknown risk. YANG 1.0 makes this promise:
>>>>>=20
>>>>>    o  An "enumeration" type may have new enums added, provided the =
old
>>>>>       enums's values do not change.
>>>>>=20
>>>>> Once YANG is widely used, I am sure we will find something =
somewhere
>>>>> relying on this and then we may see rather obscure and hard to =
debug
>>>>> problems. It is not a concrete and urgent issue but I personally =
am
>>>>> happy to have this on a list of things to consider should be ever
>>>>> create YANG > 1.0.
>>>>>=20
>>>>> /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
>>>>>=20
>>>>=20
>>>>=20
>=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  Sat Jan 25 01:17:27 2014
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 E7FED1A0158 for ; Sat, 25 Jan 2014 01:17:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 jtMyZ-TQ3Noa for ; Sat, 25 Jan 2014 01:17:25 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 540E61A014B for ; Sat, 25 Jan 2014 01:17:23 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6A54513F6B3 for ; Sat, 25 Jan 2014 10:17:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390641441; bh=qnUVHmsOobnqE8ExWZRgaGPz9mRvCdZIGEY/qpUbJcQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=jwXChufPCNxAe+tlFBfZQZdEpNfdKIPe8ihgjwimZH+4OJpmAEFqMdyzmb0JvgNdD WIi5UDpF24EJ9kLctNosd20lMQdHU7jXLVYLUevuYJ+SbA/Rw0LkfqxXuo1/kIhLgW 8CXuAg4aXzKxVMlLXZnB/eUdHBVILhjYEtTdTdoY=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140124230453.GA65851@elstar.local>
Date: Sat, 25 Jan 2014 10:17:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2024EB45-CBA8-42E3-8977-599B52545606@nic.cz>
References: <20140124230453.GA65851@elstar.local>
To: netmod@ietf.org
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Subject: Re: [netmod] consensus on errata (was enumeration 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: Sat, 25 Jan 2014 09:17:27 -0000

On 25 Jan 2014, at 00:04, Juergen Schoenwaelder =
 wrote:

> Hi,
>=20
> do we have concensus on errata 3871 and 3872?
>=20
>  http://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D3871
>  http://www.rfc-editor.org/errata_search.php?rfc=3D6020&eid=3D3872
>=20
> Should it be marked as 'Verified=92?

+1

Lada

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From mbj@tail-f.com  Sat Jan 25 06:18:53 2014
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 F2F761A02D3; Sat, 25 Jan 2014 06:18:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 90PtJhoquivI; Sat, 25 Jan 2014 06:18: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 2E1421A02C2; Sat, 25 Jan 2014 06:18:50 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id BD3A9240C1AF; Sat, 25 Jan 2014 15:18:47 +0100 (CET)
Date: Sat, 25 Jan 2014 15:18:47 +0100 (CET)
Message-Id: <20140125.151847.09968453.mbj@tail-f.com>
To: akatlas@gmail.com
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=utf-8
Content-Transfer-Encoding: base64
Cc: rtg-dir@ietf.org, draft-ietf-netmod-ip-cfg@tools.ietf.org, netmod@ietf.org, rtg-ads@tools.ietf.org
Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-ip-cfg-12
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, 25 Jan 2014 14:18:53 -0000

SGksDQoNCkFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPiB3cm90ZToNCj4gSGVsbG8sDQo+
IA0KPiBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZp
ZXdlciBmb3IgdGhpcyBkcmFmdC4NCj4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8g
cmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZA0KPiBkcmFmdHMgYXMgdGhleSBw
YXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LiBUaGUgcHVycG9zZSBv
Zg0KPiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBB
RHMuIEZvciBtb3JlDQo+IGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl
LCBwbGVhc2Ugc2VlDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS9yb3V0
aW5nLmh0bWwNCj4gDQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9y
IHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdA0KPiB3b3VsZCBiZSBoZWxwZnVsIGlmIHlv
dSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdA0KPiBD
YWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVt
IHRocm91Z2gNCj4gZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+IA0KPiBE
b2N1bWVudDogZHJhZnQtaWV0Zi1uZXRtb2QtaXAtY2ZnLTEyLnR4dA0KPiBSZXZpZXdlcjogQWxp
YSBBdGxhcw0KPiBSZXZpZXcgRGF0ZTogMjIgSmFudWFyeSAyMDE0DQo+IElFVEYgTEMgRW5kIERh
dGU6IDIzIEphbnVhcnkgMjAxNA0KPiBJbnRlbmRlZCBTdGF0dXM6IFByb3Bvc2VkIFN0YW5kYXJk
DQo+IA0KPiAqU3VtbWFyeToqDQo+IEkgaGF2ZSBhIGZldyBtaW5vciBjb25jZXJucyBhYm91dCB0
aGlzIGRvY3VtZW50IChjbGFyaWZ5aW5nIGEgZmV3IGFzcGVjdHMpDQo+IHRoYXQgSSB0aGluayBz
aG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KPiANCj4gKkNvbW1lbnRzOioN
Cj4gVGhpcyBkb2N1bWVudCBpcyB2ZXJ5IGNsZWFybHkgd3JpdHRlbiwgYnV0IEkgZGlkIGZpbmQg
YSBmZXcgZGV0YWlscyB0aGF0DQo+IGNvdWxkIHVzZSBhIGJpdCBtb3JlIGNsYXJpdHkuICBJIHdh
cyBhYmxlIHRvIGZpZ3VyZSBvdXQgd2hhdCB3YXMgaW50ZW5kZWQNCj4gYnkgd2FuZGVyaW5nIHRo
cm91Z2ggdGhlIHJlZmVyZW5jZWQgUkZDcy4NCj4gDQo+ICpNYWpvciBJc3N1ZXM6Kg0KPiBObyBt
YWpvciBpc3N1ZXMgZm91bmQuDQo+IA0KPiAqTWlub3IgSXNzdWVzOioNCj4gDQo+IA0KPiAgICAx
LiBpcHY0L2ZvcndhcmRpbmcgYW5kIGlwdjYvZm9yd2FyZGluZzogIEZpcnN0LCBJIHdhc24ndCBz
dXJlIHdoYXQgdGhpcw0KPiAgICBtZWFudCBvciBob3cgaXQgd2FzIGRpZmZlcmVudCBmcm9tIGlw
djQvZW5hYmxlIG9yIGlwdjYvZW5hYmxlLiAgIEkgd2VudA0KPiAgICBiYWNrIHRvIGxvb2sgYXQg
UkZDIDQyOTMgdG8gbGVhcm4gdGhhdCBpcHY0L2ZvcndhcmRpbmcgbWVhbnMg4oCcYWN0aW5nIGFz
IGENCj4gICAgcm91dGVyIGFuZCBmb3J3YXJkaW5nIHRyYWZmaWMgbm90IGRlc3RpbmVkIHRvIHRo
ZSBkZXZpY2XigJ0uICBDb3VsZCB5b3UNCj4gICAgY2xhcmlmeSB0aGUgdGV4dCB0byBhZGQgdGhv
c2Uga2V5IGRldGFpbHMgaW50byB0aGUgZGVzY3JpcHRpb24gZm9yDQo+ICAgIGlwdjQvZm9yd2Fy
ZGluZyBhbmQgaXB2Ni9mb3J3YXJkaW5nPw0KDQpJIHRoaW5rIHRoaXMgcHJvYmFibHkgYmVjb21l
cyBtb3JlIGNsZWFyIGlmIHdlIGNsYXJpZnkgdGhlICJlbmFibGVkIg0KbGVhZiBhcyB5b3Ugc3Vn
Z2VzdCBiZWxvdyBpbiAoMikuICBXaXRoIHRoZSBzdWdnZXN0ZWQgbmV3IHRleHQgYmVsb3cNCm1h
eWJlIHRoaXMgImZvcndhcmRpbmciIGxlYWYgaXMgb2s/ICBPdGhlcndpc2UsIHdlIGNvdWxkIHdy
aXRlIGluIHRoZQ0Kc3R5bGUgb2YgNDI5MzoNCg0KT0xEOg0KDQogICAgICAgICAgIkNvbnRyb2xz
IGlmIElQdjQgcGFja2V0IGZvcndhcmRpbmcgaXMgZW5hYmxlZCBvciBkaXNhYmxlZA0KICAgICAg
ICAgICBvbiB0aGlzIGludGVyZmFjZS4iOw0KDQpORVc6DQoNCiAgICAgICAgICAiQ29udHJvbHMg
SVB2NCBwYWNrZXQgZm9yd2FyZGluZyBvZiBkYXRhZ3JhbXMgcmVjZWl2ZWQgYnksDQogICAgICAg
ICAgIGJ1dCBub3QgYWRkcmVzc2VkIHRvLCB0aGlzIGludGVyZmFjZS4gIElQdjQgcm91dGVycyBm
b3J3YXJkDQogICAgICAgICAgIGRhdGFncmFtcy4gIElQdjQgaG9zdHMgZG8gbm90IChleGNlcHQg
dGhvc2Ugc291cmNlLXJvdXRlZA0KICAgICAgICAgICB2aWEgdGhlIGhvc3QpIjsNCg0KPiAgICBT
ZWNvbmQsIEkgd2FzIHN1cnByaXNlZCB0aGF0IHRoZQ0KPiAgICBkZWZhdWx0IGlzIGZhbHNlOyBJ
IHRoaW5rIGFib3V0IHRoaXMgZnJvbSB0aGUgcm91dGVyIHBlcnNwZWN0aXZlLCBvZg0KPiAgICBj
b3Vyc2UsIGJ1dCBhIGJpdCBvZiBleHBsYW5hdGlvbiBhcyB0byB3aHkgdGhhdCBkZWNpc2lvbiB3
YXMgbWFkZSB3b3VsZCBiZQ0KPiAgICB1c2VmdWwuDQoNClRoZSBjb25jZXB0dWFsIHZhcmlhYmxl
IElzUm91dGVyLCBkZWZpbmVkIGluIFJGQyA0ODYxLCBoYXMgRkFMU0UgYXMNCml0cyBkZWZhdWx0
IHZhbHVlLiAgKHNlZSBtb3JlIGJlbG93KS4NCg0KPiAgICAyLiBpcHY0L2VuYWJsZWQgYW5kIGlw
djYvZW5hYmxlZDogIFNpbWlsYXJseSwgd2hhdCBpcyBlbmFibGVkIGJ5DQo+ICAgIGlwdjQvZW5h
YmxlZCBpc27igJl0IGNsZWFyICh1bmxlc3MgSSBsb29rIGF0IFJGQyA0MjkzKS4gICBDb3VsZCB5
b3UgY2xhcmlmeQ0KPiAgICB0aGF0IGl0IG1lYW5zIGNvbm5lY3RlZCB0byBhbiBJUHY0IHN0YWNr
IGZvciBzZW5kaW5nIG91dCBJUHY0IHBhY2tldHMgYW5kDQo+ICAgIGZvciByZWNlaXZpbmcgdG8t
bWUgcGFja2V0cyBhbmQgZG8gdGhlIHNhbWUgY2xhcmlmaWNhdGlvbiBmb3IgaXB2Ni9lbmFibGVk
Pw0KDQpXb3VsZCB0aGlzIHdvcms/DQoNCk9MRDoNCg0KICAgICAgICAgICJDb250cm9scyBpZiBJ
UHY2IGlzIGVuYWJsZWQgb3IgZGlzYWJsZWQgb24gdGhpcw0KICAgICAgICAgICBpbnRlcmZhY2Uu
IjsNCg0KTkVXOg0KDQogICAgICAgICAgIkNvbnRyb2xzIGlmIElQdjYgaXMgZW5hYmxlZCBvciBk
aXNhYmxlZCBvbiB0aGlzDQogICAgICAgICAgIGludGVyZmFjZS4gIFdoZW4gSVB2NiBpcyBlbmFi
bGVkLCB0aGlzIGludGVyZmFjZSBpcw0KICAgICAgICAgICBjb25uZWN0ZWQgdG8gYW4gSVB2NiBz
dGFjaywgYW5kIHRoZSBpbnRlcmZhY2UgY2FuIHNlbmQNCiAgICAgICAgICAgYW5kIHJlY2VpdmUg
SVB2NiBwYWNrZXRzLiI7DQoNCg0KPiAgICAzLiBpcHY0L210dSBhbmQgaXB2Ni9tdHU6ICBUaGlz
IGlzIGRpc2N1c3Npbmcgc2VuZGluZyBhbmQgcmVjZWl2aW5nDQo+ICAgIHBhY2tldHMg4oCTIGEg
bWVudGlvbiBvZiB0aGUgTVJVIHdvdWxkIGJlIHVzZWZ1bCBhbmQgZXZlbiBxdW90aW5nICBSRkMy
NDYwIGluDQo+ICAgIFNlYyA1IHdoaWNoIHNheXMg4oCcRnJvbSBlYWNoIGxpbmsgdG8gd2hpY2gg
YSBub2RlIGlzIGRpcmVjdGx5IGF0dGFjaGVkLA0KPiAgICB0aGUgbm9kZSBtdXN0IGJlICBhYmxl
IHRvIGFjY2VwdCBwYWNrZXRzIGFzIGxhcmdlIGFzIHRoYXQgbGluaydzIE1UVS4g4oCcDQo+ICAg
IHNvIGl04oCZcyBjbGVhci4NCg0KSG1tLCB0aGUgY3VycmVudCB0ZXh0IHNheXM6DQoNCiAgICAg
ICAgIlRoZSBzaXplLCBpbiBvY3RldHMsIG9mIHRoZSBsYXJnZXN0IElQdjYgcGFja2V0IHRoYXQg
dGhlDQogICAgICAgICBpbnRlcmZhY2Ugd2lsbCBzZW5kIGFuZCByZWNlaXZlLg0KDQpJc24ndCBp
dCBjbGVhciB0aGF0IGl0IGFwcGxpZXMgYWxzbyB0byB0aGUgc2l6ZSBvZiByZWNlaXZlZCBwYWNr
ZXRzPw0KT3IgbWF5YmUgSSBtaXN1bmRlcnN0b29kIHlvdXIgY29uY2Vybj8NCg0KDQo+ICAgIDQu
ICBGb3IgdGhlIEFSUCBjYWNoZSAoaXB2NC9uZWlnaGJvcikgYW5kIE5EIGNhY2hlIChpcHY2L25l
aWdoYm9yKSwgaXMNCj4gICAgdGhlcmUgYSByZWFzb24gdGhhdCBsYXN0VXBkYXRlZCBpc27igJl0
IGluY2x1ZGVkPyAgVGhpcyBkb2VzbuKAmXQgc2VlbSB0bw0KPiAgICBwcm92aWRlIHF1aXRlIGVu
b3VnaCBpbmZvcm1hdGlvbiB0byBzZWUgd2hlbnIgbWFwcGluZ3Mgd2VyZSBsYXN0IHVwZGF0ZWQ/
DQo+ICAgIElzIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlcmUgd2lsbCBiZSBhIEFSUCBzcGVjaWZp
YyBhbmQgTkQgc3BlY2lmaWMgWUFORw0KPiAgICBtb2RlbCBmb3IgZ2V0dGluZyB0aGUgZGV0YWls
cz8NCg0KTm8sIHRoZSBpbnRlbnRpb24gaXMgdGhhdCB0aGlzIG1vZGVsIHNob3VsZCBiZSBzdWZm
aWNpZW50Lg0KDQpUaGVyZSBpcyBub3Qgc3VjaCAibGFzdCB1cGRhdGVkIiBvYmplY3QgZGVmaW5l
ZCBpbiBSRkMgNDg2MS4gIEFsc28sIGl0DQpzZWVtcyB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBh
dmFpbGFibGUgaW4gc29tZSBpbXBsZW1lbnRhdGlvbnMgKG5vdA0KaW4gbGludXgpLiAgIERvIG90
aGVyIGltcGxlbWVudGF0aW9uIHR5cGNpYWxseSBzdG9yZSB0aGlzIGluZm8/ICBJZg0Kc28sIGlu
IHdoYXQgZm9ybT8NCg0KDQo+ICpOaXRzOioNCj4gDQo+IEkndmUgcHV0IHRoZXNlIGFzIG5pdHMg
YmVjYXVzZSBJIHRoaW5rIHRoYXQgdGhleSBhcmUgcHJvYmFibHkgdGV4dHVhbA0KPiBlcnJvcnMg
cmF0aGVyIHRoYW4gaW50ZW50aW9uYWwuLi4NCj4gDQo+IA0KPiAgICAxLiAgaXB2Ni9mb3J3YXJk
aW5nOiAgIHdoeSBpcyB0aGUgcmVmZXJlbmNlIFJGQyA0ODYxIOKAkyBuZWlnaGJvcg0KPiAgICBk
aXNjb3Zlcnk/Pz8gIFRoYXQgc2VlbXMgbGlrZSBpdCBhcHBsaWVzIHRvIHRoZSBuZWlnaGJvciBp
bmZvLCB1bmxlc3MgSeKAmXZlDQo+ICAgIG1pc3VuZGVyc3Rvb2Qgd2hhdCBpcHY2L2ZvcndhcmRp
bmcgaXMgZG9pbmfigKYNCg0KQWN0dWFsbHksIHRoZSBvYmplY3QgSXNSb3V0ZXIgaW4gNi4yLjEg
aW4gUkZDIDQ4NjEgYXBwbGllcyB0byB0aGUNCmludGVyZmFjZSwgbm90IHRvIHRoZSBuZWlnaGJv
ci4gIFRoaXMgb2JqZWN0IGlzIGRlZmluZWQgYXM6DQoNCiAgICAgICAgICAgICAgICAgICAgIEEg
ZmxhZyBpbmRpY2F0aW5nIHdoZXRoZXIgcm91dGluZyBpcyBlbmFibGVkIG9uDQogICAgICAgICAg
ICAgICAgICAgICB0aGlzIGludGVyZmFjZS4gIEVuYWJsaW5nIHJvdXRpbmcgb24gdGhlIGludGVy
ZmFjZQ0KICAgICAgICAgICAgICAgICAgICAgd291bGQgaW1wbHkgdGhhdCBhIHJvdXRlciBjYW4g
Zm9yd2FyZCBwYWNrZXRzIHRvIG9yDQogICAgICAgICAgICAgICAgICAgICBmcm9tIHRoZSBpbnRl
cmZhY2UuDQoNCihUaGUgbmVpZ2hib3IgY2FjaGUgYWxzbyB0YWdzIGVhY2ggbmVpZ2hib3IgYXMg
YmVpbmcgYSByb3V0ZXIgb3Igbm90KS4NCg0KDQo+ICAgIDIuIEluIHRoZSBzZWNvbmQgdGFibGUg
aW4gU2VjIDMsIGlwdjQvbmVpZ2hib3IvaW50ZXJmYWNlIGFuZA0KPiAgICBpcHY2L25laWdoYm9y
L2ludGVyZmFjZSBhcmUgbGlzdGVkLCBidXQgSSBkb27igJl0IHNlZSB0aGVtIGluIHN0YXRlIHRy
ZWUgaW4NCj4gICAgU2VjIDIuICBJIHRoaW5rIHRoYXTigJlzIGJlY2F1c2UgdGhleSBhcmVu4oCZ
dCBuZWNlc3Nhcnk/Pw0KDQpObyB0aGlzIGlzIGEgYnVnIC0gSSBmb3Jnb3QgdG8gcmVtb3ZlIHRo
ZXNlIHdoZW4gd2UgY2hhbmdlZCB0aGUgZGF0YQ0KbW9kZWwgYXQgc29tZSB0aW1lLiAgVGhhbmtz
IGZvciBzcG90dGluZyBpdCENCg0KDQovbWFydGluDQo=

From mbj@tail-f.com  Sat Jan 25 06:26:57 2014
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 79BF31A037A for ; Sat, 25 Jan 2014 06:26:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 FrQEbwIXhvc3 for ; Sat, 25 Jan 2014 06:26:56 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 1873E1A02C2 for ; Sat, 25 Jan 2014 06:26:56 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 399AA240C1AF; Sat, 25 Jan 2014 15:26:54 +0100 (CET)
Date: Sat, 25 Jan 2014 15:26:53 +0100 (CET)
Message-Id: <20140125.152653.476476846.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20140124230453.GA65851@elstar.local>
References: <20140124230453.GA65851@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] consensus on errata
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, 25 Jan 2014 14:26:57 -0000

Juergen Schoenwaelder  wrote:
> Hi,
> 
> do we have concensus on errata 3871 and 3872?
> 
>   http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3871
>   http://www.rfc-editor.org/errata_search.php?rfc=6020&eid=3872
> 
> Should it be marked as 'Verified'?

Yes.


/martin

From andy@yumaworks.com  Sat Jan 25 09:35:07 2014
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 2D9AB1A0087 for ; Sat, 25 Jan 2014 09:35:07 -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 5jRr739K7JBl for ; Sat, 25 Jan 2014 09:35:04 -0800 (PST)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id BC1DD1A002A for ; Sat, 25 Jan 2014 09:35:04 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id f11so5356963qae.24 for ; Sat, 25 Jan 2014 09:35:02 -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:date:message-id:subject:from:to :content-type; bh=ClUwKUmhimngCIUAqWUXyjCpkof8nVsXPE2ijCAtMWQ=; b=U6jseD2U0ydoPrHqNdQaTnCSmmBdD1UneYQ0xxQ1GMOiJMa9CUKS7lnEKURhbY2RPo CSBbARWHejRgKCSbvXBTKUjDGu5cwZ0vgvuWLOJ/cXDVsHjBKnyvvcVo+f8gRMzdcvCU DY4GYaKh51aM+ymIy4qkcH1yCj3bB0YMAxSLsWLNi/QRo+1LMu1WP8xWG6VHYnsIjXdU Murx4OjTORoe/VK7fexkXXafObpNN0Q0ueMflm/KBraXWHIiV61Ml++Mg7udUfhgsYb+ OE1VwAxMxIMJI70codDAWsFJyG206yt/wm4vu1OkExsZymu5tGyoy73qfaVeQwo1ytF6 ratQ==
X-Gm-Message-State: ALoCoQnpmMpYE9LcBT30889dSkXJEtVd5HwkrPtX9+s1hbx2dP7LYLIn5Kpab5Uco421QWprvCaR
MIME-Version: 1.0
X-Received: by 10.224.119.200 with SMTP id a8mr29720471qar.7.1390671302593; Sat, 25 Jan 2014 09:35:02 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Sat, 25 Jan 2014 09:35:02 -0800 (PST)
Date: Sat, 25 Jan 2014 09:35:02 -0800
Message-ID: 
From: Andy Bierman 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c2fae6fda04804f0cee428
Subject: [netmod] leafref type in a typedef
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, 25 Jan 2014 17:35:07 -0000

--001a11c2fae6fda04804f0cee428
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I have been discussing a leafref issue with Martin offline.
I think the RFC needs more clarification wrt/ a typedef
for a leafref.

Consider 2 modules (leafref-typ and leafref):

module leafref-typ {
    namespace "http://example.com/ns/leafref-typ";
    prefix "lrt";
    revision 2014-01-25;

    typedef abs-typ {
      type leafref {
        path "/mylist/X";
      }
    }

    typedef rel-typ {
      type leafref {
        path "../mylist/X";
      }
    }

    list mylist {
       key A;
       leaf A { type string; }
       leaf X { type int32; }
    }
}


module leafref {
    namespace "http://example.com/ns/leafref";
    prefix "lr";
    import leafref-typ { prefix lrt; }
    revision 2014-01-25;

    leaf abs-ref {
      type lrt:abs-typ;
    }

    leaf rel-ref {
      type lrt:rel-typ;
    }
}


The path statement section does not account for typedef,
in which no context node exists yet.


RFC 6020, sec. 9.9.2, para 5:

   The "path" XPath expression is conceptually evaluated in the
   following context, in addition to the definition in Section 6.4.1:

   o  The context node is the node in the data tree for which the "path"
      statement is defined.

   The accessible tree depends on the context node:

   o  If the context node represents configuration data, the tree is the
      data in the NETCONF datastore where the context node exists.  The
      XPath root node has all top-level configuration data nodes in all
      modules as children.

   o  Otherwise, the tree is all state data on the device, and the
       datastore.  The XPath root node has all top-level data
      nodes in all modules as children.


This text seems to say the path-stmt is evaluated in the context of the
leaf statements in the leafref module,

Sec 6.4.1:

   All YANG XPath expressions share the following XPath context
   definition:

   o  The set of namespace declarations is the set of all "import"
      statements' prefix and namespace pairs in the module where the
      XPath expression is specified, and the "prefix" statement's prefix
      for the "namespace" statement's URI.

   o  Names without a namespace prefix belong to the same namespace as
      the identifier of the current node.  Inside a grouping, that
      namespace is affected by where the grouping is used (see
      Section 7.12).

Q: Which namespace is the default for the path-stmts in module leafref-typ?

Q: what is the context node for the path-expr in the rel-typ typedef?

IMO, some bullets above are incomplete and need to be fixed somehow.
Hoping the WG can agree how to do that.


Andy

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


Hi,

I have been discussing a leafref is=
sue with Martin offline.
I think the RFC needs more clarification=
 wrt/ a typedef
for a leafref.

Consider =
2 modules (leafref-typ and leafref):



module leafref-typ {
=A0 =A0 namespace &=
quot;http://example.com/ns/le=
afref-typ";
=A0 =A0 prefix "lrt";
=
=A0 =A0 revision 2014-01-25;



=A0 =A0 typedef abs-typ {
=A0 =A0 =A0 type le=
afref {
=A0 =A0 =A0 =A0 path "/mylist/X";
=A0=
 =A0 =A0 }
=A0 =A0 }

=A0 =A0 typedef rel=
-typ {
=A0 =A0 =A0 type leafref {


=A0 =A0 =A0 =A0 path "../mylist/X";
=A0 =A0 =A0 }<=
/div>
=A0 =A0 }

=A0 =A0 list mylist {
=A0 =A0 =A0 =A0key A;
=A0 =A0 =A0 =A0leaf A { type string; }
=A0 =A0 =A0 =A0leaf X { type int32; }


=A0 =A0 }
}


mod=
ule leafref {
=A0 =A0 namespace "http://example.com/ns/leafref";
=A0 =A0 p=
refix "lr";


=A0 =A0 import leafref-typ { prefix lrt; }
=A0 =A0 revision =
2014-01-25;

=A0 =A0 leaf abs-ref {
=A0 =
=A0 =A0 type lrt:abs-typ;
=A0 =A0 }

=A0 =
=A0 leaf rel-ref {


=A0 =A0 =A0 type lrt:rel-typ;
=A0 =A0 }
}


The path statement section does not a=
ccount for typedef,
in which no context node exists yet.




RFC 6020, sec. 9.9.2, para 5:

   The "path" XPath expression is conceptually evaluated in =
the
   following context, in addition to the definition in Section 6.4.1:

   o  The context node is the node in the data tree for which the "pat=
h"
      statement is defined.

   The accessible tree depends on the context node:

   o  If the context node represents configuration data, the tree is the
      data in the NETCONF datastore where the context node exists.  The
      XPath root node has all top-level configuration data nodes in all
      modules as children.

   o  Otherwise, the tree is all state data on the device, and the
      <running/> datastore.  The XPath root node has all top-level da=
ta
      nodes in all modules as children.


This text seems to say the path-stmt =
is evaluated in the context of the
leaf statements in the leafref=
 module,

Sec 6.4.1:
   All YANG XPath expressions share the following XPath context
   definition:

   o  The set of namespace declarations is the set of all "import"=
;
      statements' prefix and namespace pairs in the module where the
      XPath expression is specified, and the "prefix" statement&#=
39;s prefix
      for the "namespace" statement's URI.

   o  Names without a namespace prefix belong to the same namespace as
      the identifier of the current node.  Inside a grouping, that
      namespace is affected by where the grouping is used (see
      Section 7.12).
Q: Which namespace is the default for =
the path-stmts in module leafref-typ?
=A0
Q: what is th=
e context node for the path-expr in the rel-typ typedef?=A0



IMO, some bullets above are incomplete and need to be fixed some=
how.
Hoping the WG can agree how to do that.

=


Andy



--001a11c2fae6fda04804f0cee428--

From randy_presuhn@mindspring.com  Sat Jan 25 10:38:24 2014
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 D77B21A001B for ; Sat, 25 Jan 2014 10:38:24 -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 6IoBogqTutc1 for ; Sat, 25 Jan 2014 10:38:23 -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 2911F1A0017 for ; Sat, 25 Jan 2014 10:38:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TGjshYmySn8jGVWX3eBOGAARiNe0hisBv7goxuxFINxd3RxuZxWZ4FFmMproE359; 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.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W787Y-0005eT-1D; Sat, 25 Jan 2014 13:38:20 -0500
Received: from 99.23.161.33 by webmail.earthlink.net with HTTP; Sat, 25 Jan 2014 13:38:19 -0500
Message-ID: <19773188.1390675099961.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net>
Date: Sat, 25 Jan 2014 10:38:19 -0800 (GMT-08:00)
From: Randy Presuhn 
To: Ladislav Lhotka , B Lukovic 
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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbc5825f9820f5c344c981235da6de00b81350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.32
Cc: netmod@ietf.org
Subject: Re: [netmod] enumeration type
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: Sat, 25 Jan 2014 18:38:25 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Jan 24, 2014 11:53 PM
>To: B Lukovic 
>Cc: netmod@ietf.org
>Subject: Re: [netmod] enumeration type
...
>In Berlin (IETF 87), I proposed to start work on a new YANG
>spec that would, among other things, remove such NETCONF dependences.

How quickly we forget lessons learned in the 1980's.

There's a seductive appeal to the idea of making the
data modeling language protocol independent, but the
reality is that both protocols and data modeling languages,
at least as a matter of usability, generally end up embodying
assumptions about metamodel.  If you're careful and lucky,
you *might* get a spec appropriate for use with a set of
Netconf-ish protocols, and perhaps a set of specs for how
this new Yang maps to the service definitions of each of
those protocols.  Doing this "right" requires thinking
about both what the metamodel really is, and what the core
supporting protocol services need to be.

Randy

From andy@yumaworks.com  Sat Jan 25 11:03:01 2014
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 F3FC91A003C for ; Sat, 25 Jan 2014 11:03: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 zO_w7idl6vlk for ; Sat, 25 Jan 2014 11:02:59 -0800 (PST)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 01F201A0039 for ; Sat, 25 Jan 2014 11:02:58 -0800 (PST)
Received: by mail-qa0-f53.google.com with SMTP id cm18so5371376qab.40 for ; Sat, 25 Jan 2014 11:02:57 -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=Has8OHsNLirn7uPMfHzAxYIDL1WsxaAZ2pWQ/tCkdWw=; b=YQ5IhilnWCm+MB/UBRhYC8JSTZbgTQGUYMirYV3NB/Yi9zrqxxIkVU0og5UNpO0GtD s4Q7Z2wmlo9nmNdo9LaJIlyNXObP0NtJZMlSIZVlDPI5E54JlKAB2WR/F/52oxFRefoa TjaaABkvQ2EMov/NTUQxjCVduxVLCVWdKQzNhuI8c+q6KJ182wbQmZROO75JcJ1XUkyu KQABvoQLEpxVChXvM4/eTnKb6RL2oTHQYQK7Uhy3qAYdEzcO5wmf0M5g5iI1PJc1nmI8 F+9n4lNiHeLPCsyVfxAdV0DjK6KGA+p4tfR4zhQMHGYsVnmb84Jn1dqDj0BwvX+KqlFu elcA==
X-Gm-Message-State: ALoCoQkb5LBxMUHull1DT0wd2D+jJ3kxlIeyTB3QFaygFJRZZRLSL9UTyC+e2PIzVyIei0JDH2M1
MIME-Version: 1.0
X-Received: by 10.140.85.179 with SMTP id n48mr28379899qgd.91.1390676577273; Sat, 25 Jan 2014 11:02:57 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Sat, 25 Jan 2014 11:02:57 -0800 (PST)
In-Reply-To: <19773188.1390675099961.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net>
References: <19773188.1390675099961.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net>
Date: Sat, 25 Jan 2014 11:02:57 -0800
Message-ID: 
From: Andy Bierman 
To: Randy Presuhn 
Content-Type: multipart/alternative; boundary=001a11c133de62df6704f0d01fac
Cc: B Lukovic , "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Sat, 25 Jan 2014 19:03:01 -0000

--001a11c133de62df6704f0d01fac
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jan 25, 2014 at 10:38 AM, Randy Presuhn <
randy_presuhn@mindspring.com> wrote:

> Hi -
>
> >From: Ladislav Lhotka 
> >Sent: Jan 24, 2014 11:53 PM
> >To: B Lukovic 
> >Cc: netmod@ietf.org
> >Subject: Re: [netmod] enumeration type
> ...
> >In Berlin (IETF 87), I proposed to start work on a new YANG
> >spec that would, among other things, remove such NETCONF dependences.
>
> How quickly we forget lessons learned in the 1980's.
>
> There's a seductive appeal to the idea of making the
> data modeling language protocol independent, but the
> reality is that both protocols and data modeling languages,
> at least as a matter of usability, generally end up embodying
> assumptions about metamodel.  If you're careful and lucky,
> you *might* get a spec appropriate for use with a set of
> Netconf-ish protocols, and perhaps a set of specs for how
> this new Yang maps to the service definitions of each of
> those protocols.  Doing this "right" requires thinking
> about both what the metamodel really is, and what the core
> supporting protocol services need to be.
>
>
Good point -- not just because I do not want to work a new
YANG version :-) -- the only reason RESTCONF works with YANG
is because it borrows the NETCONF context roots (datastore,
rpc input/output, notification), so all the validation rules are the same.



> Randy
>

Andy

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





On Sat, Jan 25, 2014 at 10:38 AM, Randy Presuhn &=
lt;randy_=
presuhn@mindspring.com> wrote:


Hi -



>From: Ladislav Lhotka <lhotka@nic.c=
z>

>Sent: Jan 24, 2014 11:53 PM

>To: B Lukovic <blukovic@ndt-=
inc.com>

>Cc: netmod@ietf.org

>Subject: Re: [netmod] enumeration type

...

>In Berlin (IETF 87), I proposed to start work on a new YANG

>spec that would, among other things, remove such NETCONF dependences.


How quickly we forget lessons learned in the 1980's.



There's a seductive appeal to the idea of making the

data modeling language protocol independent, but the

reality is that both protocols and data modeling languages,

at least as a matter of usability, generally end up embodying

assumptions about metamodel. =A0If you're careful and lucky,

you *might* get a spec appropriate for use with a set of

Netconf-ish protocols, and perhaps a set of specs for how

this new Yang maps to the service definitions of each of

those protocols. =A0Doing this "right" requires thinking

about both what the metamodel really is, and what the core

supporting protocol services need to be.



Good point -- not just because I do no=
t want to work a new
YANG version :-) -- the only reason RESTCONF=
 works with YANG
is because it borrows the NETCONF context roots =
(datastore,


rpc input/output, notification), so all the validation rules are the s=
ame.

=A0

Randy

Andy



--001a11c133de62df6704f0d01fac--

From lhotka@nic.cz  Sat Jan 25 11:04:28 2014
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 6C1791A003C for ; Sat, 25 Jan 2014 11:04:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 KvnoKUlEKV2R for ; Sat, 25 Jan 2014 11:04:26 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A23A41A0039 for ; Sat, 25 Jan 2014 11:04:26 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 92BFE13F6B3; Sat, 25 Jan 2014 20:04:23 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390676663; bh=wqVmY0tNmkv4LAceb4/HPFcxyMqy9Y6BsLmEAiXXS80=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hwri6xupnswjTcNvsko/J2k+RzowzgPdgKbrKBHbi1/6OZVzRPgiQQ1i13Ra2BXVB OMCs6+FC5wGw5UkjRCkatRKuOZxwQ0tDS5gAyjbl8cxzI+xT46Lo18jswS/J6DfQNf cRaGOOjDr08DkNnlJobC3cGgL5pa7WujrI2bQJnw=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <19773188.1390675099961.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net>
Date: Sat, 25 Jan 2014 20:04:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E4C2011-8946-4396-9D08-C2EC090CE2AA@nic.cz>
References: <19773188.1390675099961.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net>
To: Randy Presuhn 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: B Lukovic , netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Sat, 25 Jan 2014 19:04:28 -0000

On 25 Jan 2014, at 19:38, Randy Presuhn  =
wrote:

> Hi -
>=20
>> From: Ladislav Lhotka 
>> Sent: Jan 24, 2014 11:53 PM
>> To: B Lukovic 
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] enumeration type
> ...
>> In Berlin (IETF 87), I proposed to start work on a new YANG
>> spec that would, among other things, remove such NETCONF dependences.
>=20
> How quickly we forget lessons learned in the 1980's.
>=20
> There's a seductive appeal to the idea of making the
> data modeling language protocol independent, but the
> reality is that both protocols and data modeling languages,
> at least as a matter of usability, generally end up embodying
> assumptions about metamodel.  If you're careful and lucky,
> you *might* get a spec appropriate for use with a set of
> Netconf-ish protocols, and perhaps a set of specs for how
> this new Yang maps to the service definitions of each of
> those protocols.  Doing this "right" requires thinking
> about both what the metamodel really is, and what the core
> supporting protocol services need to be.

Well, the fact of the matter is that YANG is already being used for =
non-NETCONF protocols (and a non-XML encoding). Those who do so have to =
pretend they know what each constraint means, and this is of course a =
slippery slope.

I do believe the potential of YANG goes beyond NETCONF. IMO, a =
meta-model should no be too difficult to derive: one or more =
hierarchical data trees, R/O and R/W data, RPCs and notifications.

Lada=20

>=20
> Randy

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





From lhotka@nic.cz  Sat Jan 25 11:09:36 2014
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 2293C1A0028 for ; Sat, 25 Jan 2014 11:09:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 16cHJItb0sXn for ; Sat, 25 Jan 2014 11:09:35 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3471A0015 for ; Sat, 25 Jan 2014 11:09:35 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id E08A113F6B3; Sat, 25 Jan 2014 20:09:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390676973; bh=AFaRze3C6m7dZiiUXuLLLtxUK/l8QfxAanr5z73lHgY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=D3W+orfy9VBo6yPXIVu+2H6KKfxc93DuxSwYQKpaXBMqJV9uN9YrM9Zn/lH0ff0fF utuidgXdouy/8OrB/DEuDY2PW6IhWdA/KHaJoP8y8QRwOv+JGB4kLsnvoxf8gLbNaE KNX5B1OE8oWFgYCDu51IDCIMmrX7sdghfYccUjeY=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Sat, 25 Jan 2014 20:09:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <19773188.1390675099961.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: Randy Presuhn , B Lukovic , "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Sat, 25 Jan 2014 19:09:36 -0000

On 25 Jan 2014, at 20:02, Andy Bierman  wrote:

>=20
>=20
>=20
> On Sat, Jan 25, 2014 at 10:38 AM, Randy Presuhn =
 wrote:
> Hi -
>=20
> >From: Ladislav Lhotka 
> >Sent: Jan 24, 2014 11:53 PM
> >To: B Lukovic 
> >Cc: netmod@ietf.org
> >Subject: Re: [netmod] enumeration type
> ...
> >In Berlin (IETF 87), I proposed to start work on a new YANG
> >spec that would, among other things, remove such NETCONF dependences.
>=20
> How quickly we forget lessons learned in the 1980's.
>=20
> There's a seductive appeal to the idea of making the
> data modeling language protocol independent, but the
> reality is that both protocols and data modeling languages,
> at least as a matter of usability, generally end up embodying
> assumptions about metamodel.  If you're careful and lucky,
> you *might* get a spec appropriate for use with a set of
> Netconf-ish protocols, and perhaps a set of specs for how
> this new Yang maps to the service definitions of each of
> those protocols.  Doing this "right" requires thinking
> about both what the metamodel really is, and what the core
> supporting protocol services need to be.
>=20
>=20
> Good point -- not just because I do not want to work a new
> YANG version :-) -- the only reason RESTCONF works with YANG
> is because it borrows the NETCONF context roots (datastore,
> rpc input/output, notification), so all the validation rules are the =
same.

This is not true:

   o  If the constraint is defined on state data, it MUST be true in a
      reply to a  operation without a filter.

Where in RESTCONF can I find a reply to a  operation without a =
filter?

Lada
=20
>=20
> =20
> Randy
>=20
> Andy
>=20

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





From andy@yumaworks.com  Sat Jan 25 11:15:14 2014
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 E70F51A002F for ; Sat, 25 Jan 2014 11:15:13 -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 o2BPWyAjJgMy for ; Sat, 25 Jan 2014 11:15:11 -0800 (PST)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7891A0028 for ; Sat, 25 Jan 2014 11:15:10 -0800 (PST)
Received: by mail-qa0-f44.google.com with SMTP id w5so5548120qac.31 for ; Sat, 25 Jan 2014 11:15:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LLJMvxyM4s4vQdROuYlriigNe4B5+82jbHxuO3jj4NU=; b=S56tOva3s0Y5jM6qcs+17+oBMFjkz4bBB7JvIZem3RrDVwCq9MXCMmijMbuMMPFslk d697gDdrXUZZr4MwIfaFms8GAZOg/0IsXiINOpu76+QkzVNd4UDGJaWZKt2XOsw2izqY mY/NmMqju5ovBXb42KxgtekE/iraOHvMG4+1gPeeWpB1WRH0MbLyJTgfNKF6IR6sKZNH 726vzLHI8DbG5oj1S6PHF74t/IEQmaxZWEUtR/PaMmVXHWz5HBXdu3CPUedFt74L80ie +HnK3NVSPwrcTGIqbn7WfrNh1pdqjw6f97T1OnEaYCpEWmJ0jGYeGK5iLjuDaLmpDPQY 7pvA==
MIME-Version: 1.0
X-Received: by 10.224.26.71 with SMTP id d7mr7416021qac.99.1390677309356; Sat, 25 Jan 2014 11:15:09 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Sat, 25 Jan 2014 11:15:09 -0800 (PST)
In-Reply-To: 
References: <19773188.1390675099961.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net>  
Date: Sat, 25 Jan 2014 11:15:09 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=089e0149c510058eb704f0d04b8b
Cc: Randy Presuhn , B Lukovic , "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Sat, 25 Jan 2014 19:15:14 -0000

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

On Sat, Jan 25, 2014 at 11:09 AM, Ladislav Lhotka  wrote:

>
> On 25 Jan 2014, at 20:02, Andy Bierman  wrote:
>
> >
> >
> >
> > On Sat, Jan 25, 2014 at 10:38 AM, Randy Presuhn <
> randy_presuhn@mindspring.com> wrote:
> > Hi -
> >
> > >From: Ladislav Lhotka 
> > >Sent: Jan 24, 2014 11:53 PM
> > >To: B Lukovic 
> > >Cc: netmod@ietf.org
> > >Subject: Re: [netmod] enumeration type
> > ...
> > >In Berlin (IETF 87), I proposed to start work on a new YANG
> > >spec that would, among other things, remove such NETCONF dependences.
> >
> > How quickly we forget lessons learned in the 1980's.
> >
> > There's a seductive appeal to the idea of making the
> > data modeling language protocol independent, but the
> > reality is that both protocols and data modeling languages,
> > at least as a matter of usability, generally end up embodying
> > assumptions about metamodel.  If you're careful and lucky,
> > you *might* get a spec appropriate for use with a set of
> > Netconf-ish protocols, and perhaps a set of specs for how
> > this new Yang maps to the service definitions of each of
> > those protocols.  Doing this "right" requires thinking
> > about both what the metamodel really is, and what the core
> > supporting protocol services need to be.
> >
> >
> > Good point -- not just because I do not want to work a new
> > YANG version :-) -- the only reason RESTCONF works with YANG
> > is because it borrows the NETCONF context roots (datastore,
> > rpc input/output, notification), so all the validation rules are the
> same.
>
> This is not true:
>
>    o  If the constraint is defined on state data, it MUST be true in a
>       reply to a  operation without a filter.
>
> Where in RESTCONF can I find a reply to a  operation without a filter?
>
>
You are being kind of literal.
A developer might guess GET.
As for "using an encoding other than XML", we are using the
YANG to JSON mapping you wrote.

How can we make sure that the NETMOD charter is updated
(if RESTCONF is approved for NETCONF) so that the YANG to JSON
mapping RFC must also be chartered? RESTCONF has a normative
reference to this draft.


Lada
>

Andy


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

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





On Sat, Jan 25, 2014 at 11:09 AM, Ladislav Lhotka <lhotka@nic.cz&g=
t; wrote:




On 25 Jan 2014, at 20:02, Andy Bierman <andy@yumaworks.com> wrote:



>

>

>

> On Sat, Jan 25, 2014 at 10:38 AM, Randy Presuhn <randy_presuhn@mindspring.com> wrote:
> Hi -

>

> >From: Ladislav Lhotka <lhotka@=
nic.cz>

> >Sent: Jan 24, 2014 11:53 PM

> >To: B Lukovic <blukovic=
@ndt-inc.com>

> >Cc: netmod@ietf.org

> >Subject: Re: [netmod] enumeration type

> ...

> >In Berlin (IETF 87), I proposed to start work on a new YANG

> >spec that would, among other things, remove such NETCONF dependenc=
es.

>

> How quickly we forget lessons learned in the 1980's.

>

> There's a seductive appeal to the idea of making the

> data modeling language protocol independent, but the

> reality is that both protocols and data modeling languages,

> at least as a matter of usability, generally end up embodying

> assumptions about metamodel. =A0If you're careful and lucky,

> you *might* get a spec appropriate for use with a set of

> Netconf-ish protocols, and perhaps a set of specs for how

> this new Yang maps to the service definitions of each of

> those protocols. =A0Doing this "right" requires thinking

> about both what the metamodel really is, and what the core

> supporting protocol services need to be.

>

>

> Good point -- not just because I do not want to work a new

> YANG version :-) -- the only reason RESTCONF works with YANG

> is because it borrows the NETCONF context roots (datastore,

> rpc input/output, notification), so all the validation rules are the s=
ame.



This is not true:



=A0 =A0o =A0If the constraint is defined on state data, it MUST be true in =
a

=A0 =A0 =A0 reply to a <get> operation without a filter.



Where in RESTCONF can I find a reply to a <get> operation without a f=
ilter?



You are being kind of literal.
A developer might guess GET.
As for "using an encoding ot=
her than XML", we are using the
YANG to JSON mapping you wro=
te.



How can we make sure that the NETMOD charter is updated=

(if RESTCONF is approved for NETCONF) so that the YANG to JSON
mapping RFC must also be chartered? RESTCONF has a normative


reference to this draft.



Lada

Andy
=A0



>

>

> Randy

>

> Andy

>



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--089e0149c510058eb704f0d04b8b--

From lhotka@nic.cz  Sat Jan 25 11:39:48 2014
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 A99321A0056 for ; Sat, 25 Jan 2014 11:39:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 IdSWxryMHi_3 for ; Sat, 25 Jan 2014 11:39: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 607F81A002F for ; Sat, 25 Jan 2014 11:39: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 0545013F6B3; Sat, 25 Jan 2014 20:39:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390678784; bh=LfMmSXcduTKCScnrm+ZTM8KOl1y3OkByT+vz3s2lrmw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=W1qy1QIzlG5HGYy5MHsAYLfOXT8NthgGKJBuRCwfIpdHMZnCYE/b5l8aetYT4FP2U pQuOHVRp+d8PAwf0EA8ICefQm9QLknAF5+F9vNohqiCZ6QnHmKf+dr2YYYgZ/DCbuE Xi0beIm7OZVtKVO3nVmvkhSmdhPdQwAP9ezuh7Sw=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Sat, 25 Jan 2014 20:39:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <19773188.1390675099961.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net>   
To: Andy Bierman 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: Randy Presuhn , B Lukovic , "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Sat, 25 Jan 2014 19:39:48 -0000

On 25 Jan 2014, at 20:15, Andy Bierman  wrote:

>=20
>=20
>=20
> On Sat, Jan 25, 2014 at 11:09 AM, Ladislav Lhotka  =
wrote:
>=20
> On 25 Jan 2014, at 20:02, Andy Bierman  wrote:
>=20
> >
> >
> >
> > On Sat, Jan 25, 2014 at 10:38 AM, Randy Presuhn =
 wrote:
> > Hi -
> >
> > >From: Ladislav Lhotka 
> > >Sent: Jan 24, 2014 11:53 PM
> > >To: B Lukovic 
> > >Cc: netmod@ietf.org
> > >Subject: Re: [netmod] enumeration type
> > ...
> > >In Berlin (IETF 87), I proposed to start work on a new YANG
> > >spec that would, among other things, remove such NETCONF =
dependences.
> >
> > How quickly we forget lessons learned in the 1980's.
> >
> > There's a seductive appeal to the idea of making the
> > data modeling language protocol independent, but the
> > reality is that both protocols and data modeling languages,
> > at least as a matter of usability, generally end up embodying
> > assumptions about metamodel.  If you're careful and lucky,
> > you *might* get a spec appropriate for use with a set of
> > Netconf-ish protocols, and perhaps a set of specs for how
> > this new Yang maps to the service definitions of each of
> > those protocols.  Doing this "right" requires thinking
> > about both what the metamodel really is, and what the core
> > supporting protocol services need to be.
> >
> >
> > Good point -- not just because I do not want to work a new
> > YANG version :-) -- the only reason RESTCONF works with YANG
> > is because it borrows the NETCONF context roots (datastore,
> > rpc input/output, notification), so all the validation rules are the =
same.
>=20
> This is not true:
>=20
>    o  If the constraint is defined on state data, it MUST be true in a
>       reply to a  operation without a filter.
>=20
> Where in RESTCONF can I find a reply to a  operation without a =
filter?
>=20
>=20
> You are being kind of literal.
> A developer might guess GET.

Yes, and I2RS folks might guess something else. Validity has to do with =
certain data trees rather than particular methods for retrieving the =
data. We should be able to define it in a generic way, I don=92t think =
there is any rocket science involved.

> As for "using an encoding other than XML", we are using the
> YANG to JSON mapping you wrote.

Right, but it is not very straightforward and easy to grasp for =
newcomers. I think the JSON encoding should eventually be integrated =
into the YANG spec as an alternative to XML.

>=20
> How can we make sure that the NETMOD charter is updated
> (if RESTCONF is approved for NETCONF) so that the YANG to JSON
> mapping RFC must also be chartered? RESTCONF has a normative
> reference to this draft.

I hope it will be chartered.

Lada

>=20
>=20
> Lada
>=20
> Andy
> =20
>=20
> >
> >
> > Randy
> >
> > Andy
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20

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





From mbj@tail-f.com  Sat Jan 25 13:58:01 2014
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 E0AD81A00A0 for ; Sat, 25 Jan 2014 13:58:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 3jc40E2GHyaG for ; Sat, 25 Jan 2014 13:58:00 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id A149F1A009D for ; Sat, 25 Jan 2014 13:58:00 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F85B240C4CC; Sat, 25 Jan 2014 22:57:57 +0100 (CET)
Date: Sat, 25 Jan 2014 22:57:57 +0100 (CET)
Message-Id: <20140125.225757.373181551.mbj@tail-f.com>
To: randy_presuhn@mindspring.com
From: Martin Bjorklund 
In-Reply-To: <19773188.1390675099961.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net>
References: <19773188.1390675099961.JavaMail.root@elwamui-cypress.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: blukovic@ndt-inc.com, netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Sat, 25 Jan 2014 21:58:02 -0000

Randy Presuhn  wrote:
> Hi -
> 
> >From: Ladislav Lhotka 
> >Sent: Jan 24, 2014 11:53 PM
> >To: B Lukovic 
> >Cc: netmod@ietf.org
> >Subject: Re: [netmod] enumeration type
> ...
> >In Berlin (IETF 87), I proposed to start work on a new YANG
> >spec that would, among other things, remove such NETCONF dependences.
> 
> How quickly we forget lessons learned in the 1980's.
> 
> There's a seductive appeal to the idea of making the
> data modeling language protocol independent, but the
> reality is that both protocols and data modeling languages,
> at least as a matter of usability, generally end up embodying
> assumptions about metamodel.

I fully agree.

But the idea is not to try to make YANG a protocol-independent
modelling languge.  The idea is "just" to separate the
protocol-specific parts from the language.

The idea with RESTCONF (separate thread...) is to do this - design a
new protocol that is compatible with the (implict) meta-model of
NETCONF and YANG.

But I also agree that it is not obvious that it can be done, and still
be useful.

> If you're careful and lucky,
> you *might* get a spec appropriate for use with a set of
> Netconf-ish protocols, and perhaps a set of specs for how
> this new Yang maps to the service definitions of each of
> those protocols.  Doing this "right" requires thinking
> about both what the metamodel really is, and what the core
> supporting protocol services need to be.

Again I fully agree.


/martin

From andy@yumaworks.com  Sat Jan 25 14:00:26 2014
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 084AB1A009D for ; Sat, 25 Jan 2014 14:00:26 -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 Z86pg0OZWPzX for ; Sat, 25 Jan 2014 14:00:24 -0800 (PST)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 107A01A00A0 for ; Sat, 25 Jan 2014 14:00:23 -0800 (PST)
Received: by mail-qa0-f52.google.com with SMTP id j15so5653316qaq.11 for ; Sat, 25 Jan 2014 14:00:22 -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=ZabKCXB7axZxinBRPL51rq3JPL6ZG9dB670E+CXi82k=; b=Iyavl9/pwLPDQUBr8XVYztsEgEngXM7zXLyNpt3/O/TtZXO1deXfp2G6ImXgiiP+kw XMACG5rB6PbFC+kMcPPN0X+yCve/R8S2iV2vmlJO6CLvZo8tE5ujb9jdC5PDWkOAo0HC oIE0gFE0XraZ1D7fH6XZfNoNne631e6QskIkmRx59aByt7JpGNp6Tr139rIS3LHl7z86 l6CjTeLwp1SdrfMuQuR47gRjDwddRnKzEvjxI8aDQvWyajzrmBD7kmfQ8CXFFxV7F8XE OCD2FHlgvIJYyPVADaO60W8bfLyPWAfZ+44HndG7yD2Ri9TmLhW/ku0zX7IUBkIs1ls5 wB8g==
X-Gm-Message-State: ALoCoQlZkozjpCc2T9PUgDQm0VdOvTROR7fZRKhezSwHteIK12KGFZ0xFMbfCyA/KJ0jLe5nUgIZ
MIME-Version: 1.0
X-Received: by 10.140.84.19 with SMTP id k19mr29613652qgd.98.1390687222241; Sat, 25 Jan 2014 14:00:22 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Sat, 25 Jan 2014 14:00:22 -0800 (PST)
In-Reply-To: 
References: <19773188.1390675099961.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net>    
Date: Sat, 25 Jan 2014 14:00:22 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11c12e4ce02ebd04f0d29913
Cc: Randy Presuhn , B Lukovic , "netmod@ietf.org" 
Subject: Re: [netmod] enumeration 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: Sat, 25 Jan 2014 22:00:26 -0000

--001a11c12e4ce02ebd04f0d29913
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

...
> > You are being kind of literal.
> > A developer might guess GET.
>
> Yes, and I2RS folks might guess something else. Validity has to do with
> certain data trees rather than particular methods for retrieving the data=
.
> We should be able to define it in a generic way, I don=92t think there is=
 any
> rocket science involved.
>
>
The term  could easily be replaced by "retrieval".
I think I2RS can figure that out, but we can worry
about that if the issue ever comes up for real.



> > As for "using an encoding other than XML", we are using the
> > YANG to JSON mapping you wrote.
>
> Right, but it is not very straightforward and easy to grasp for newcomers=
.
> I think the JSON encoding should eventually be integrated into the YANG
> spec as an alternative to XML.
>
>
Republishing RFCs just to move stuff around is expensive and the
IETF can't really afford the resources to do that.  A newcomer
reading RESTCONF will see where to find the JSON encoding rules.



> >
> > How can we make sure that the NETMOD charter is updated
> > (if RESTCONF is approved for NETCONF) so that the YANG to JSON
> > mapping RFC must also be chartered? RESTCONF has a normative
> > reference to this draft.
>
> I hope it will be chartered.
>
> Lada
>
>
Andy

--001a11c12e4ce02ebd04f0d29913
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable




...

> You are being kind of literal.

> A developer might guess GET.



Yes, and I2RS folks might guess something else. Validity has to do with cer=
tain data trees rather than particular methods for retrieving the data. We =
should be able to define it in a generic way, I don=92t think there is any =
rocket science involved.




The term <get> could easily be r=
eplaced by "retrieval".
I think I2RS can figure that ou=
t, but we can worry
about that if the issue ever comes up for rea=
l.



=A0

> As for "using an encoding other than XML", we are using the<=
br>
> YANG to JSON mapping you wrote.



Right, but it is not very straightforward and easy to grasp for newcomers. =
I think the JSON encoding should eventually be integrated into the YANG spe=
c as an alternative to XML.



Republishing RFCs just to move stuff a=
round is expensive and the
IETF can't really afford the resou=
rces to do that. =A0A newcomer
reading RESTCONF will see where to=
 find the JSON encoding rules.



=A0

>

> How can we make sure that the NETMOD charter is updated

> (if RESTCONF is approved for NETCONF) so that the YANG to JSON

> mapping RFC must also be chartered? RESTCONF has a normative

> reference to this draft.



I hope it will be chartered.



Lada



Andy
=A0


--001a11c12e4ce02ebd04f0d29913--

From blukovic@ndt-inc.com  Sat Jan 25 14:13:38 2014
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 DBEBA1A009D for ; Sat, 25 Jan 2014 14:13:38 -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, HTML_MESSAGE=0.001, 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 M0_VfhZuF2fa for ; Sat, 25 Jan 2014 14:13:36 -0800 (PST)
Received: from mail19g.g19.rapidsite.net (mail19g.g19.rapidsite.net [204.202.242.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8A35E1A00A4 for ; Sat, 25 Jan 2014 14:13:36 -0800 (PST)
Received: from mxmtaout02.va1.mxservers.net (208.55.215.49) by mail19g.g19.rapidsite.net (RS ver 1.0.95vs) with SMTP id 4-074808014 for ; Sat, 25 Jan 2014 17:13:34 -0500 (EST)
Received: from unknown [161.58.75.15] (EHLO mmm1913.dulles19-verio.com) by mxmtaout02.va1.mxservers.net(mxl_mta-6.15.0-3) with ESMTP id e0734e25.0.1055256.00-491.1689436.mxmtaout02.va1.mxservers.net (envelope-from );  Sat, 25 Jan 2014 17:13:34 -0500 (EST)
X-MXL-Hash: 52e4370e256424b5-9e67149fa5a4490916e79e2c4a39f5d320a46d1c
Received: (qmail 40289 invoked from network); 25 Jan 2014 22:13:34 -0000
Received: from unknown (HELO ?192.168.0.21?) (blukovic@135.23.154.141) by  with ESMTPA; 25 Jan 2014 22:13:34 -0000
Message-ID: <52E4370F.2030305@ndt-inc.com>
Date: Sat, 25 Jan 2014 17:13:35 -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: andy@yumaworks.com
References: <19773188.1390675099961.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net>     
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000903020305030003010204"
X-Spam: [F=0.2000000000; CM=0.500; MH=0.500(2014012516); S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [161.58.75.15]
X-AnalysisOut: [v=2.0 cv=QqnpKyOd c=1 sm=1 a=IcBn81/O6j4k4bHiM4CBQw==:17 a]
X-AnalysisOut: [=jl2ymW9NZSsA:10 a=ymigdH7LP5EA:10 a=63bDUHjCYPkA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=A1sffi52AAAA:8 a=valQ_CuEJh4A:10 a=BOKZgaiD]
X-AnalysisOut: [gig6pj5s_aMA:9 a=pILNOxqGKmIA:10 a=pGLkceISAAAA:8 a=cA1rjA]
X-AnalysisOut: [d99aVUo-5eIncA:9 a=_W_S_7VecoQA:10]
X-SF-Loop: 1
Cc: randy_presuhn@mindspring.com, netmod@ietf.org
Subject: Re: [netmod] enumeration 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: Sat, 25 Jan 2014 22:13:39 -0000

This is a multi-part message in MIME format.
--------------000903020305030003010204
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit


This is interesting discussion but subject line is misleading.

      Borislav


On 1/25/2014 5:00 PM, Andy Bierman wrote:
>
>
>     ...
>     > You are being kind of literal.
>     > A developer might guess GET.
>
>     Yes, and I2RS folks might guess something else. Validity has to do
>     with certain data trees rather than particular methods for
>     retrieving the data. We should be able to define it in a generic
>     way, I don’t think there is any rocket science involved.
>
>
> The term  could easily be replaced by "retrieval".
> I think I2RS can figure that out, but we can worry
> about that if the issue ever comes up for real.
>
>     > As for "using an encoding other than XML", we are using the
>     > YANG to JSON mapping you wrote.
>
>     Right, but it is not very straightforward and easy to grasp for
>     newcomers. I think the JSON encoding should eventually be
>     integrated into the YANG spec as an alternative to XML.
>
>
> Republishing RFCs just to move stuff around is expensive and the
> IETF can't really afford the resources to do that.  A newcomer
> reading RESTCONF will see where to find the JSON encoding rules.
>
>     >
>     > How can we make sure that the NETMOD charter is updated
>     > (if RESTCONF is approved for NETCONF) so that the YANG to JSON
>     > mapping RFC must also be chartered? RESTCONF has a normative
>     > reference to this draft.
>
>     I hope it will be chartered.
>
>     Lada
>
>
> Andy


--------------000903020305030003010204
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    This is interesting discussion but subject line is misleading.

    

         Borislav

    

    

    
On 1/25/2014 5:00 PM, Andy Bierman
      wrote:

    

    

      


        


          

            
...

              > You are being kind of literal.

              > A developer might guess GET.

              

              Yes, and I2RS folks might guess something else. Validity
              has to do with certain data trees rather than particular
              methods for retrieving the data. We should be able to
              define it in a generic way, I don’t think there is any
              rocket science involved.

              

            

            


            

            
The term <get> could easily be replaced by
              "retrieval".

            
I think I2RS can figure that out, but we can worry

            
about that if the issue ever comes up for real.

            


            

            
 

            

              > As for "using an encoding other than XML", we are
              using the

              > YANG to JSON mapping you wrote.

              

              Right, but it is not very straightforward and easy to
              grasp for newcomers. I think the JSON encoding should
              eventually be integrated into the YANG spec as an
              alternative to XML.

              

            

            


            

            
Republishing RFCs just to move stuff around is
              expensive and the

            
IETF can't really afford the resources to do that.  A
              newcomer

            
reading RESTCONF will see where to find the JSON
              encoding rules.

            


            

            
 

            

              >

              > How can we make sure that the NETMOD charter is
              updated

              > (if RESTCONF is approved for NETCONF) so that the
              YANG to JSON

              > mapping RFC must also be chartered? RESTCONF has a
              normative

              > reference to this draft.

              

              I hope it will be chartered.

              

              Lada

              

            

            


            

            
Andy

            
 

          

        

      

    

    

  


--------------000903020305030003010204--

From iesg-secretary@ietf.org  Mon Jan 27 13:51:51 2014
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 B21331A008F; Mon, 27 Jan 2014 13:51:51 -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 AO2gUkB8_CBq; Mon, 27 Jan 2014 13:51:45 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EEB1A03D6; Mon, 27 Jan 2014 13:51:42 -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.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140127215142.11552.44608.idtracker@ietfa.amsl.com>
Date: Mon, 27 Jan 2014 13:51:42 -0800
Cc: netmod chair , netmod mailing list , RFC Editor 
Subject: [netmod] Protocol Action: 'A YANG Data Model for Interface Management' to Proposed Standard (draft-ietf-netmod-interfaces-cfg-16.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, 27 Jan 2014 21:51:51 -0000

The IESG has approved the following document:
- 'A YANG Data Model for Interface Management'
  (draft-ietf-netmod-interfaces-cfg-16.txt) as Proposed Standard

This document is the product of the NETCONF Data Modeling Language
Working Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/




Technical Summary

   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.

Working Group Summary

   The normal WG process was followed and the document reflect WG
   consensus with nothing special worth mentioning except for the following.

   While the working group felt that the set of documents was complete in
   April 2013, there was a sense of unease about disparities between
   operational state and configuration. Additional reviews during the last
   call made it clear that it was desirable to deal with this by separating
   operational state from configuration management and that this should have
   been done from the beginning. The working group pulled the document back
   from IESG review and worked to add this to the model.

Document Quality

  This set of documents (draft-ietf-netmod-interfaces-cfg, draft-ietf-netmod-iana-if-type,
  draft-ietf-netmod-ip-cf) received extensive review within the working group
  and ample time was spent to review and reconsider all design choices.
  The working group also reached out to the IP directorate and received
 additional review from Dave Thaler.

Personnel

  David Kessens is the document shepherd (and Thomas Nadeau lately)
  Benoit Claise is the responsible Area Director. 


From sm@resistor.net  Mon Jan 27 13:54:38 2014
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 E1ABD1A03E2 for ; Mon, 27 Jan 2014 13:54:37 -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] 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 KA1vW0s4wWiC for ; Mon, 27 Jan 2014 13:54:36 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8661A02DC for ; Mon, 27 Jan 2014 13:54:34 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s0RLsOlj002017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jan 2014 13:54:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1390859671; bh=bsD1LX9yriCFhBWT1CeD9L7ttoNyEXYgRhRPwPNdF2o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IyadiKL+/0gV9V74JkRRcL6/V+jsFth39oL6IWHI5Y35uwaZV2WY+ECKrfLve0a2t fYpoJO5SXgwtNzMjdJBE96h2//n6mvHCBJS+8pjhiOn1cmfPgSKQ5K+HSkEwLzfTH1 f8U4xDPYoFJmjGkpCkSbf8k3ATDf0JX261NZ4eLg=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1390859671; i=@resistor.net; bh=bsD1LX9yriCFhBWT1CeD9L7ttoNyEXYgRhRPwPNdF2o=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=mwNIIsp403OGsRnKUQKOrunCdT4eKrXXRMLbktbzXJu+vDkuseueiG6laLIRRXF+m ZOUjjOZWq5Ep5GG5w3ro5LPi21LS/xVd05wgMva34W8Uw5THE4HbbHCSl5BPhwUpSq oEiog5n2kgTneda0k0my/nQ7t0q6MCYwuxzI3310=
Message-Id: <6.2.5.6.2.20140127135221.0b185b98@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 27 Jan 2014 13:53:56 -0800
To: netmod@ietf.org
From: SM 
In-Reply-To: <52E2EE46.5030804@cisco.com>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <52E23EBC.1040708@cisco.com> <6.2.5.6.2.20140124114546.0b2d57c0@resistor.net> <52E2EE46.5030804@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: netmod-chairs@tools.ietf.org
Subject: Re: [netmod] Fwd: consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 27 Jan 2014 21:54:38 -0000

Hello,

>         The working group chairs have considered the discussion concerning
>the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
>draft-ietf-netmod-iana-timezones-03. In particular, we would like
>like to call consensus on the matter regarding that surfaced during
>the IETF last call with regard to the the practicability of maintaining a
>YANG module with an enumeration of timezone names. We believe there is
>consensus in the working group to move forward with the following
>resolution:
>
>- The YANG module in draft-ietf-netmod-system-mgmt-11 gets
>extended to introduce a new typedef for timezone names, e.g.
>something that looks like:
>
>   typedef timezone-name {
>     type string;
>     description
>      "A timezone name as used by the Time Zone Database, sometimes
>       referred to as the 'Olson Database'.";
>     reference
>      "RFC 6557: Procedures for Maintaining the Time Zone Database";
>   }
>
>The timezone-location leaf will be changed to use this type,
>the import of iana-timezones will be removed and the references
>to I-D.ietf-netmod-iana-timezones will be removed.

I don't have a strong opinion about the above.  There were some good 
comments (ignoring mine) which might be helpful to the working group 
as it reviews the above.

>- The draft-ietf-netmod-iana-timezones-00 document will be pulled
>back and work on this draft will stop.  The I-D is declared dead.
>
>- Since there is nothing to do for IANA, there will be no IANA request
>needed in this regard for draft-ietf-netmod-system-mgmt-11.

I am okay with the above resolution of the issue.

Regards,
-sm 


From jernej.tuljak@mg-soft.si  Tue Jan 28 01:59:32 2014
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 6D0031A011B for ; Tue, 28 Jan 2014 01:59:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.065
X-Spam-Level: 
X-Spam-Status: No, score=0.065 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.535] 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 fRxxUI7wzKLK for ; Tue, 28 Jan 2014 01:59:24 -0800 (PST)
Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF421A0258 for ; Tue, 28 Jan 2014 01:59:23 -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 s0S9xI5F018961; Tue, 28 Jan 2014 10:59:19 +0100
Message-ID: <52E77F72.7000900@mg-soft.com>
Date: Tue, 28 Jan 2014 10:59:14 +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: Andy Bierman 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050409060603040101040507"
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] leafref type in a typedef
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, 28 Jan 2014 09:59:33 -0000

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

Dne 25.1.2014 18:35, pis(e Andy Bierman:
> Hi,
>
> I have been discussing a leafref issue with Martin offline.
> I think the RFC needs more clarification wrt/ a typedef
> for a leafref.
>
> Consider 2 modules (leafref-typ and leafref):
>
> module leafref-typ {
>     namespace "http://example.com/ns/leafref-typ";
>     prefix "lrt";
>     revision 2014-01-25;
>
>     typedef abs-typ {
>       type leafref {
>         path "/mylist/X";
>       }
>     }
>
>     typedef rel-typ {
>       type leafref {
>         path "../mylist/X";
>       }
>     }
>
>     list mylist {
>        key A;
>        leaf A { type string; }
>        leaf X { type int32; }
>     }
> }
>
>
> module leafref {
>     namespace "http://example.com/ns/leafref";
>     prefix "lr";
>     import leafref-typ { prefix lrt; }
>     revision 2014-01-25;
>
>     leaf abs-ref {
>       type lrt:abs-typ;
>     }
>
>     leaf rel-ref {
>       type lrt:rel-typ;
>     }
> }
>
>
> The path statement section does not account for typedef,
> in which no context node exists yet.
>
>
> RFC 6020, sec. 9.9.2, para 5:
>
>     The "path" XPath expression is conceptually evaluated in the
>     following context, in addition to the definition in Section 6.4.1:
>
>     o  The context node is the node in the data tree for which the "path"
>        statement is defined.
>
>     The accessible tree depends on the context node:
>
>     o  If the context node represents configuration data, the tree is the
>        data in the NETCONF datastore where the context node exists.  The
>        XPath root node has all top-level configuration data nodes in all
>        modules as children.
>
>     o  Otherwise, the tree is all state data on the device, and the
>         datastore.  The XPath root node has all top-level data
>        nodes in all modules as children.
>
> This text seems to say the path-stmt is evaluated in the context of the
> leaf statements in the leafref module,
>
> Sec 6.4.1:
>     All YANG XPath expressions share the following XPath context
>     definition:
>
>     o  The set of namespace declarations is the set of all "import"
>        statements' prefix and namespace pairs in the module where the
>        XPath expression is specified, and the "prefix" statement's prefix
>        for the "namespace" statement's URI.
>
>     o  Names without a namespace prefix belong to the same namespace as
>        the identifier of the current node.  Inside a grouping, that
>        namespace is affected by where the grouping is used (see
>        Section 7.12).
> Q: Which namespace is the default for the path-stmts in module 
> leafref-typ?

The namespace should be that of the typedef defining module. From module 
leafref perspective, paths are in this form: "/lrt:mylist/lrt:X" and 
"../lrt:mylist/lrt:X". Similar to the value/position statement issue, 
again "the identifier of the current node" seems ambiguous (6.4.1.).

"Inside a typedef, that namespace is the same as that of the identifier 
of the typedef (applies only to path statement, see Section 9.9.2.)." or 
something similar could be added after the grouping exception.

> Q: what is the context node for the path-expr in the rel-typ typedef?

The context node should be the lr:rel-ref leaf. One could argue that it 
already represents "the data node in the data tree for which the path 
statement is defined" even with current text. Would be better to be more 
specific though.

"If the path statement is defined within a used typedef, the context 
node is the leaf or leaf-list data node ancestor of the type statement 
which references the used typedef." or something similar could be added.

>
> IMO, some bullets above are incomplete and need to be fixed somehow.
> Hoping the WG can agree how to do that.
>

I agree.

P.S.: However, IMO, any grouping or typedef should be reusable anywhere 
in their respective usage scope (whether top-level or local). A typedef 
or a grouping that can only be used in a specific way (like lrt:rel-typ) 
should be made illegal in favor of promoting reuse - the main purpose of 
both statements. Any XPath expression in YANG, not just path 
expressions, should respect this inherent property of typedefs and 
groupings. It's a shame this was not considered in the original text. 
Probably requires YANG 2.0 to fix.

Jernej


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


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


  
    
  
  
    
Dne 25.1.2014 18:35, piše Andy Bierman:

    

    

      
Hi,
        


        

        
I have been discussing a leafref issue with Martin offline.

        
I think the RFC needs more clarification wrt/ a typedef

        
for a leafref.

        


        

        
Consider 2 modules (leafref-typ and leafref):

        


        

        

          
module leafref-typ {

          
          
    prefix "lrt";

          
    revision 2014-01-25;

          


          

          
    typedef abs-typ {

          
      type leafref {

          
        path "/mylist/X";

          
      }

          
    }

          


          

          
    typedef rel-typ {

          
      type leafref {

          
        path "../mylist/X";

          
      }

          
    }

          


          

          
    list mylist {

          
       key A;

          
       leaf A { type string; }

          
       leaf X { type int32; }

          
    }

          
}

          


          

          


          

          

            
module leafref {

            
            
    prefix "lr";

            
    import leafref-typ { prefix lrt; }

            
    revision 2014-01-25;

            


            

            
    leaf abs-ref {

            
      type lrt:abs-typ;

            
    }

            


            

            
    leaf rel-ref {

            
      type lrt:rel-typ;

            
    }

            
}

          

          


          

          


          

          
The path statement section does not account for typedef,

          
in which no context node exists yet.

          


          

          


          

          
RFC 6020, sec. 9.9.2, para 5:

          


          

          

            
   The "path" XPath expression is conceptually evaluated in the
   following context, in addition to the definition in Section 6.4.1:

   o  The context node is the node in the data tree for which the "path"
      statement is defined.

   The accessible tree depends on the context node:

   o  If the context node represents configuration data, the tree is the
      data in the NETCONF datastore where the context node exists.  The
      XPath root node has all top-level configuration data nodes in all
      modules as children.

   o  Otherwise, the tree is all state data on the device, and the
      <running/> datastore.  The XPath root node has all top-level data
      nodes in all modules as children.


          

          


          

        

        
This text seems to say the path-stmt is evaluated in the
          context of the

        
leaf statements in the leafref module,

        


        

        
Sec 6.4.1:

        

          
   All YANG XPath expressions share the following XPath context
   definition:

   o  The set of namespace declarations is the set of all "import"
      statements' prefix and namespace pairs in the module where the
      XPath expression is specified, and the "prefix" statement's prefix
      for the "namespace" statement's URI.

   o  Names without a namespace prefix belong to the same namespace as
      the identifier of the current node.  Inside a grouping, that
      namespace is affected by where the grouping is used (see
      Section 7.12).

        

        
Q: Which namespace is the default for the path-stmts in
          module leafref-typ?

      

    

    

    The namespace should be that of the typedef defining module. From
    module leafref perspective, paths are in this form:
    "/lrt:mylist/lrt:X" and "../lrt:mylist/lrt:X". Similar to the
    value/position statement issue, again "the identifier of the current
    node" seems ambiguous (6.4.1.).

    

    "Inside a typedef, that namespace is the same as that of the
    identifier of the typedef (applies only to path statement, see
    Section 9.9.2.)." or something similar could be added after the
    grouping exception.

    

    

      

        
 

        
Q: what is the context node for the path-expr in the
          rel-typ typedef? 

        

      

    

    

    The context node should be the lr:rel-ref leaf. One could argue that
    it already represents "the data node in the data tree for which the
    path statement is defined" even with current text. Would be better
    to be more specific though.

    

    "If the path statement is defined within a used typedef, the context
    node is the leaf or leaf-list data node ancestor of the type
    statement which references the used typedef." or something similar
    could be added.

    

    

      

        


        

        
IMO, some bullets above are incomplete and need to be fixed
          somehow.

        
Hoping the WG can agree how to do that.

        


        

      

    

    

    I agree.

    

    P.S.: However, IMO, any grouping or typedef should be reusable
    anywhere in their respective usage scope (whether top-level or
    local). A typedef or a grouping that can only be used in a specific
    way (like lrt:rel-typ) should be made illegal in favor of promoting
    reuse - the main purpose of both statements. Any XPath expression in
    YANG, not just path expressions, should respect this inherent
    property of typedefs and groupings. It's a shame this was not
    considered in the original text. Probably requires YANG 2.0 to fix.

    

    Jernej 

    

    

    

      

        


        

        
Andy

        


        

      

      

      

      

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


    

    

  


--------------050409060603040101040507--

From mbj@tail-f.com  Tue Jan 28 02:44:32 2014
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 09C951A01EC for ; Tue, 28 Jan 2014 02:44:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 g7i2CQ9dc5yA for ; Tue, 28 Jan 2014 02:44:30 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6F81A01DA for ; Tue, 28 Jan 2014 02:44:30 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 32FB6240C443; Tue, 28 Jan 2014 11:44:26 +0100 (CET)
Date: Tue, 28 Jan 2014 11:44:25 +0100 (CET)
Message-Id: <20140128.114425.486388648.mbj@tail-f.com>
To: tnadeau@lucidvision.com
From: Martin Bjorklund 
In-Reply-To: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.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-chairs@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 28 Jan 2014 10:44:32 -0000

Hi,


Thomas Nadeau  wrote:
> 
> 	Netmod WG:
> 
> 	The working group chairs have considered the discussion concerning 
> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
> draft-ietf-netmod-iana-timezones-03. In particular, we would like
> like to call consensus on the matter regarding that surfaced during
> the IETF last call with regard to the the practicability of maintaining a 
> YANG module with an enumeration of timezone names. We believe there is
> consensus in the working group to move forward with the following 
> resolution:
> 
> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets
> extended to introduce a new typedef for timezone names, e.g.
> something that looks like:
> 
>   typedef timezone-name {
>     type string;
>     description
>      "A timezone name as used by the Time Zone Database, sometimes
>       referred to as the 'Olson Database'.";
>     reference
>      "RFC 6557: Procedures for Maintaining the Time Zone Database";
>   }
> 
> The timezone-location leaf will be changed to use this type,
> the import of iana-timezones will be removed and the references
> to I-D.ietf-netmod-iana-timezones will be removed.

I support this solution.

However, I think we need to explain in the description text of the
timezone-name typedef that servers will restrict the valid values for
this type to whatever they support, and that how clients can learn
which values are valid is out of scope for this document.


/martin

From lhotka@nic.cz  Tue Jan 28 04:07:04 2014
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 C83551A0360 for ; Tue, 28 Jan 2014 04:07:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level: 
X-Spam-Status: No, score=-0.886 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.535] 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 CLh5WJHTC_b8 for ; Tue, 28 Jan 2014 04:07:03 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DFD7B1A008A for ; Tue, 28 Jan 2014 04:07:02 -0800 (PST)
Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id C4F9413F766; Tue, 28 Jan 2014 13:06:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390910819; bh=SbmmpW4DfJCAS3PGMHGNwGhQCra7/7Fwo3CvrDcd0f0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lTQuT0/gB7Pk6beYuYBLbEuYOGSWAd1uzD8O6OZTiqcrhN6O1fW4B608MfHsCrqyq GkGXrqBEct7Un135Jr86l3ARd39vFDpZKhkdifR6yk8bASbLVARXqNbUvXeXZJvy4i QqZS5DwmqzEXVZmWXDBbyorKrE3lEJivJE8jbL5o=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140128.114425.486388648.mbj@tail-f.com>
Date: Tue, 28 Jan 2014 13:06:57 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D0EEFB1-AD82-4EDB-9DB4-797EAA758D4D@nic.cz>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <20140128.114425.486388648.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-chairs@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 28 Jan 2014 12:07:05 -0000

On 28 Jan 2014, at 11:44, Martin Bjorklund  wrote:

> Hi,
>=20
>=20
> Thomas Nadeau  wrote:
>>=20
>> 	Netmod WG:
>>=20
>> 	The working group chairs have considered the discussion =
concerning=20
>> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
>> draft-ietf-netmod-iana-timezones-03. In particular, we would like
>> like to call consensus on the matter regarding that surfaced during
>> the IETF last call with regard to the the practicability of =
maintaining a=20
>> YANG module with an enumeration of timezone names. We believe there =
is
>> consensus in the working group to move forward with the following=20
>> resolution:
>>=20
>> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets
>> extended to introduce a new typedef for timezone names, e.g.
>> something that looks like:
>>=20
>>  typedef timezone-name {
>>    type string;
>>    description
>>     "A timezone name as used by the Time Zone Database, sometimes
>>      referred to as the 'Olson Database'.";
>>    reference
>>     "RFC 6557: Procedures for Maintaining the Time Zone Database";
>>  }
>>=20
>> The timezone-location leaf will be changed to use this type,
>> the import of iana-timezones will be removed and the references
>> to I-D.ietf-netmod-iana-timezones will be removed.
>=20
> I support this solution.
>=20
> However, I think we need to explain in the description text of the
> timezone-name typedef that servers will restrict the valid values for
> this type to whatever they support, and that how clients can learn
> which values are valid is out of scope for this document.

A client also needs to be able to learn the corresponding UTC offsets =
and DST rules.

I don=92t have a strong opinion here but I wonder whether the benefits =
of the string type outweigh the damage to interoperability. My concern =
is that a string might be vulnerable not only to political, but also =
marketing pressures.

Lada

>=20
>=20
> /martin
> _______________________________________________
> 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  Tue Jan 28 07:58:15 2014
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 D0C911A034D for ; Tue, 28 Jan 2014 07:58:15 -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 Lo7AzAXHMwiQ for ; Tue, 28 Jan 2014 07:58:12 -0800 (PST)
Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC8C1A02EA for ; Tue, 28 Jan 2014 07:58:12 -0800 (PST)
Received: by mail-qc0-f181.google.com with SMTP id e9so810638qcy.12 for ; Tue, 28 Jan 2014 07:58:09 -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=bJlb+ugbOmqjTPiQvl2Pkzo8mMGJFU/QN9H8+5TiGm4=; b=XhFPduGoiX9y01XgonpGN46PMjuQfAQa/4BSho7Q7KBdX+l/1Lt3Qe3jVattbqfyH0 4HHbwhH12izuHPKxI3pHHno+kuFm/WAHNOzhr24s0TixvzC6xBOJujFOJC3UQG5Th/uz 98Bdf7Nzn7m9SEPrUDPLDnvX+++rh+qj9pMSD7L1SsmExy1Lx+/feyt2Ot6pcwW2EyiU j0RUx2s4R+txgLjSEEVZHUL1EBsGDlRONutsBWuLgQgn7nTAyS/wW7l74qj7vsdLPwnO dUYniiGVLoF3y+0645HRLvAz3Mn6xvik1vr1eO2KMMiVKiwBOT/Ze9HeKMzBRlL/q+OP kDFw==
X-Gm-Message-State: ALoCoQmOMRIGeQYBRs/xzhbq6euRUXACyPb9TCDach/LJGapcqvWh633aYgWixLOj1Rz11b4JNHZ
MIME-Version: 1.0
X-Received: by 10.140.27.179 with SMTP id 48mr3450941qgx.18.1390924689511; Tue, 28 Jan 2014 07:58:09 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 28 Jan 2014 07:58:09 -0800 (PST)
In-Reply-To: <52E77F72.7000900@mg-soft.com>
References:  <52E77F72.7000900@mg-soft.com>
Date: Tue, 28 Jan 2014 07:58:09 -0800
Message-ID: 
From: Andy Bierman 
To: Jernej Tuljak 
Content-Type: multipart/alternative; boundary=001a11c0043407255704f109e499
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] leafref type in a typedef
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, 28 Jan 2014 15:58:16 -0000

--001a11c0043407255704f109e499
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 28, 2014 at 1:59 AM, Jernej Tuljak wr=
ote:

>  Dne 25.1.2014 18:35, pi=C5=A1e Andy Bierman:
>
> Hi,
>
>  I have been discussing a leafref issue with Martin offline.
> I think the RFC needs more clarification wrt/ a typedef
> for a leafref.
>
>  Consider 2 modules (leafref-typ and leafref):
>
>  module leafref-typ {
>     namespace "http://example.com/ns/leafref-typ";
>     prefix "lrt";
>     revision 2014-01-25;
>
>      typedef abs-typ {
>       type leafref {
>         path "/mylist/X";
>       }
>     }
>
>      typedef rel-typ {
>       type leafref {
>         path "../mylist/X";
>       }
>     }
>
>      list mylist {
>        key A;
>        leaf A { type string; }
>        leaf X { type int32; }
>     }
> }
>
>
>  module leafref {
>     namespace "http://example.com/ns/leafref";
>     prefix "lr";
>     import leafref-typ { prefix lrt; }
>     revision 2014-01-25;
>
>      leaf abs-ref {
>       type lrt:abs-typ;
>     }
>
>      leaf rel-ref {
>       type lrt:rel-typ;
>     }
> }
>
>
>  The path statement section does not account for typedef,
> in which no context node exists yet.
>
>
>  RFC 6020, sec. 9.9.2, para 5:
>
>     The "path" XPath expression is conceptually evaluated in the
>    following context, in addition to the definition in Section 6.4.1:
>
>    o  The context node is the node in the data tree for which the "path"
>       statement is defined.
>
>    The accessible tree depends on the context node:
>
>    o  If the context node represents configuration data, the tree is the
>       data in the NETCONF datastore where the context node exists.  The
>       XPath root node has all top-level configuration data nodes in all
>       modules as children.
>
>    o  Otherwise, the tree is all state data on the device, and the
>        datastore.  The XPath root node has all top-level data
>       nodes in all modules as children.
>
>
>  This text seems to say the path-stmt is evaluated in the context of the
> leaf statements in the leafref module,
>
>  Sec 6.4.1:
>
>    All YANG XPath expressions share the following XPath context
>    definition:
>
>    o  The set of namespace declarations is the set of all "import"
>       statements' prefix and namespace pairs in the module where the
>       XPath expression is specified, and the "prefix" statement's prefix
>       for the "namespace" statement's URI.
>
>    o  Names without a namespace prefix belong to the same namespace as
>       the identifier of the current node.  Inside a grouping, that
>       namespace is affected by where the grouping is used (see
>       Section 7.12).
>
>  Q: Which namespace is the default for the path-stmts in module
> leafref-typ?
>
>
> The namespace should be that of the typedef defining module. From module
> leafref perspective, paths are in this form: "/lrt:mylist/lrt:X" and
> "../lrt:mylist/lrt:X". Similar to the value/position statement issue, aga=
in
> "the identifier of the current node" seems ambiguous (6.4.1.).
>
> "Inside a typedef, that namespace is the same as that of the identifier o=
f
> the typedef (applies only to path statement, see Section 9.9.2.)." or
> something similar could be added after the grouping exception.
>
>
I agree the compiler always has to bind modules to QNames inside the module
containing
the path-stmt.  That seems to be clear from 6.4.1. (Current node is really
current statement,
not a data node).



> Q: what is the context node for the path-expr in the rel-typ typedef?
>
>
> The context node should be the lr:rel-ref leaf. One could argue that it
> already represents "the data node in the data tree for which the path
> statement is defined" even with current text. Would be better to be more
> specific though.
>
> "If the path statement is defined within a used typedef, the context node
> is the leaf or leaf-list data node ancestor of the type statement which
> references the used typedef." or something similar could be added.
>
>

Our compiler tries to validate the path-stmt in the typedef, using the
document
root as the context node.  Then it is evaluated again in the leaf, using th=
e
real context node.  Relative path expressions should be avoided in typedefs
but they are allowed.




>
>  IMO, some bullets above are incomplete and need to be fixed somehow.
> Hoping the WG can agree how to do that.
>
>
> I agree.
>
> P.S.: However, IMO, any grouping or typedef should be reusable anywhere i=
n
> their respective usage scope (whether top-level or local). A typedef or a
> grouping that can only be used in a specific way (like lrt:rel-typ) shoul=
d
> be made illegal in favor of promoting reuse - the main purpose of both
> statements. Any XPath expression in YANG, not just path expressions, shou=
ld
> respect this inherent property of typedefs and groupings. It's a shame th=
is
> was not considered in the original text. Probably requires YANG 2.0 to fi=
x.
>
>
I agree the relative path-expr is dangerous to use.
It could be covered with a YANG guideline.
We have guidelines like mandatory top-level nodes are legal,
but not allowed in IETF modules. We can force IETF modules
to use absolute path-expr in typedefs.  A relative path-expr
in a grouping that refers to something in the grouping is OK.


Jernej
>
>

Andy

--001a11c0043407255704f109e499
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable





On Tue, Jan 28, 2014 at 1:59 AM, Jernej Tuljak &l=
t;jernej.tulj=
ak@mg-soft.si> wrote:



 =20
   =20
 =20
  

    
Dne 25.1.2014 18:35, pi=C5=A1e Andy Bierman:

    

    

      
Hi,
        


        

        
I have been discussing a leafref issue with Martin offline.
        
I think the RFC needs more clarification wrt/ a typedef

        
for a leafref.

        


        

        
Consider 2 modules (leafref-typ and leafref):

        


        

        

          
module leafref-typ {

          
=C2=A0 =C2=A0 namespace "http://example.com/ns/leafref-typ&quo=
t;;

          
=C2=A0 =C2=A0 prefix "lrt";

          
=C2=A0 =C2=A0 revision 2014-01-25;

          


          

          
=C2=A0 =C2=A0 typedef abs-typ {

          
=C2=A0 =C2=A0 =C2=A0 type leafref {

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0 path "/mylist/X";
          
=C2=A0 =C2=A0 =C2=A0 }

          
=C2=A0 =C2=A0 }

          


          

          
=C2=A0 =C2=A0 typedef rel-typ {

          
=C2=A0 =C2=A0 =C2=A0 type leafref {

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0 path "../mylist/X";
          
=C2=A0 =C2=A0 =C2=A0 }

          
=C2=A0 =C2=A0 }

          


          

          
=C2=A0 =C2=A0 list mylist {

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0key A;

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf A { type string; }

          
=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf X { type int32; }

          
=C2=A0 =C2=A0 }

          
}

          


          

          


          

          

            
module leafref {

            
=C2=A0 =C2=A0 namespace "http://example.com/ns/leafref";
            
=C2=A0 =C2=A0 prefix "lr";

            
=C2=A0 =C2=A0 import leafref-typ { prefix lrt; }

            
=C2=A0 =C2=A0 revision 2014-01-25;

            


            

            
=C2=A0 =C2=A0 leaf abs-ref {

            
=C2=A0 =C2=A0 =C2=A0 type lrt:abs-typ;

            
=C2=A0 =C2=A0 }

            


            

            
=C2=A0 =C2=A0 leaf rel-ref {

            
=C2=A0 =C2=A0 =C2=A0 type lrt:rel-typ;

            
=C2=A0 =C2=A0 }

            
}

          

          


          

          


          

          
The path statement section does not account for typedef,
          
in which no context node exists yet.

          


          

          


          

          
RFC 6020, sec. 9.9.2, para 5:

          


          

          

            
   The=
 "path" XPath expression is conceptually evaluated in the
   following context, in addition to the definition in Section 6.4.1:

   o  The context node is the node in the data tree for which the "pat=
h"
      statement is defined.

   The accessible tree depends on the context node:

   o  If the context node represents configuration data, the tree is the
      data in the NETCONF datastore where the context node exists.  The
      XPath root node has all top-level configuration data nodes in all
      modules as children.

   o  Otherwise, the tree is all state data on the device, and the
      <running/> datastore.  The XPath root node has all top-level da=
ta
      nodes in all modules as children.


          

          


          

        

        
This text seems to say the path-stmt is evaluated in the
          context of the

        
leaf statements in the leafref module,

        


        

        
Sec 6.4.1:

        

          
   All Y=
ANG XPath expressions share the following XPath context
   definition:

   o  The set of namespace declarations is the set of all "import"=
;
      statements' prefix and namespace pairs in the module where the
      XPath expression is specified, and the "prefix" statement&#=
39;s prefix
      for the "namespace" statement's URI.

   o  Names without a namespace prefix belong to the same namespace as
      the identifier of the current node.  Inside a grouping, that
      namespace is affected by where the grouping is used (see
      Section 7.12).

        

        
Q: Which namespace is the default for the path-stmts in
          module leafref-typ?

      

    

    

    The namespace should be that of the typedef defining module. From
    module leafref perspective, paths are in this form:
    "/lrt:mylist/lrt:X" and "../lrt:mylist/lrt:X". Simi=
lar to the
    value/position statement issue, again "the identifier of the curre=
nt
    node" seems ambiguous (6.4.1.).

    

    "Inside a typedef, that namespace is the same as that of the
    identifier of the typedef (applies only to path statement, see
    Section 9.9.2.)." or something similar could be added after the
    grouping exception.

    

I agree the compiler always =
has to bind modules to QNames inside the module containing
the pa=
th-stmt. =C2=A0That seems to be clear from 6.4.1. (Current node is really c=
urrent statement,


not a data node).



    

      

        
=C2=A0

        
Q: what is the context node for the path-expr in the
          rel-typ typedef? 

        

      

    

    

    The context node should be the lr:rel-ref leaf. One could argue that
    it already represents "the data node in the data tree for which th=
e
    path statement is defined" even with current text. Would be better
    to be more specific though.

    

    "If the path statement is defined within a used typedef, the conte=
xt
    node is the leaf or leaf-list data node ancestor of the type
    statement which references the used typedef." or something similar
    could be added.

    


Our compiler =
tries to validate the path-stmt in the typedef, using the document
root as the context node. =C2=A0Then it is evaluated again in the leaf, u=
sing the


real context node. =C2=A0Relative path expressions should be avoided i=
n typedefs
but they are allowed.


=C2=A0



    

      

        


        

        
IMO, some bullets above are incomplete and need to be fixed
          somehow.

        
Hoping the WG can agree how to do that.

        


        

      

    

    

    I agree.

    

    P.S.: However, IMO, any grouping or typedef should be reusable
    anywhere in their respective usage scope (whether top-level or
    local). A typedef or a grouping that can only be used in a specific
    way (like lrt:rel-typ) should be made illegal in favor of promoting
    reuse - the main purpose of both statements. Any XPath expression in
    YANG, not just path expressions, should respect this inherent
    property of typedefs and groupings. It's a shame this was not
    considered in the original text. Probably requires YANG 2.0 to fix.

    

I agree the relative path-ex=
pr is dangerous to use.
It could be covered with a YANG guideline=
.
We have guidelines like mandatory top-level nodes are legal,

but not allowed in IETF modules. We can force IETF modules
t=
o use absolute path-expr in typedefs. =C2=A0A relative path-expr
=
in a grouping that refers to something in the grouping is OK.




    Jernej 

    


Andy
=C2=A0


--001a11c0043407255704f109e499--

From spakes@snmp.com  Tue Jan 28 08:08:23 2014
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 4D3DE1A0440 for ; Tue, 28 Jan 2014 08:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 tks3aKphNmTo for ; Tue, 28 Jan 2014 08:08:21 -0800 (PST)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 28EE51A0441 for ; Tue, 28 Jan 2014 08:08:21 -0800 (PST)
Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA03770; Tue, 28 Jan 2014 11:08:17 -0500 (EST)
Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA22244; Tue, 28 Jan 2014 11:08:16 -0500 (EST)
X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs
Date: Tue, 28 Jan 2014 11:08:15 -0500 (EST)
From: David Spakes 
X-X-Sender: spakes@adminfs
To: netmod@ietf.org
In-Reply-To: <4D0EEFB1-AD82-4EDB-9DB4-797EAA758D4D@nic.cz>
Message-ID: 
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <20140128.114425.486388648.mbj@tail-f.com> <4D0EEFB1-AD82-4EDB-9DB4-797EAA758D4D@nic.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 28 Jan 2014 16:08:23 -0000

On Tue, 28 Jan 2014, Ladislav Lhotka wrote:

> >>  typedef timezone-name {
> >>    type string;
> >>    description
> >>     "A timezone name as used by the Time Zone Database, sometimes
> >>      referred to as the 'Olson Database'.";
> >>    reference
> >>     "RFC 6557: Procedures for Maintaining the Time Zone Database";
> >>  }
> >
> > I support this solution.
> >
> > However, I think we need to explain in the description text of the
> > timezone-name typedef that servers will restrict the valid values for
> > this type to whatever they support, and that how clients can learn
> > which values are valid is out of scope for this document.
>
> A client also needs to be able to learn the corresponding UTC offsets
> and DST rules.
>
> I don't have a strong opinion here but I wonder whether the benefits
> of the string type outweigh the damage to interoperability. My concern
> is that a string might be vulnerable not only to political, but also
> marketing pressures.


If the client has a way to view the list of strings recognized by the
server together with their corresponding UTC offsets and DST changes,
then we should be able to lay to rest any and all concerns about how
political and marketing pressures affect the implementation of
individual devices.

I made a proposal a little over a week ago that is relevant.  No one
commented on it at that time, but maybe it should be discussed now.
Here it is again.


On Fri, 17 Jan 2014, David Spakes wrote:

> If the client needs to be able to see the list of strings that the
> server is actually using, then the client should not reach out to the
> TZ Database; it should consult the server.  In addition to the typedef,
> the document should define a config false list of strings that the
> server actually supports.


Here is basically what I had in mind:

  list known-timezones {
    config false;

    leaf name {
      type timezone-name;
    }
    leaf utc-offset {
      // whatever type is appropriate
    }
    leaf valid-time {
      type uint32 {
        range "0 .. 365";
      }
      description
        "The number of days this advice is expected to remain valid.";
    }
  }


To prepare to configure a device, a client would retrieve the list.
A graphical-based client could use this information to populate a
choice widget from which a human operator could select the desired
value.  A non-interactive client could validate a predetermined
selection or automatically make a choice based on the utc-offset.

The valid-time would be used to set a timer in the client.  When the
timer fires, it's time to review the choice and potentially reconfigure
the device.  The client should retrieve the list again from the device
in order to update the choice.  For countries with a predetermined date
to switch between standard and daylight savings time, the valid-time
would indicate the number of days until the next switch.  If a country
(or state, or other municipality) chooses to modify the DST scheduled
(as the United States did a couple of years ago), the valid-time would
indicate the date when such a schedule change is expected.  If a date
is unknown to the device, it could set the value to zero, which means
"check back often".  In a region where there is no change for DST, the
value would remain 365 every time the information is retrieved.

-dss


-------------------------------------------------------------
 David Spakes                       email:   spakes@snmp.com
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------


From andy@yumaworks.com  Tue Jan 28 08:21:40 2014
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 EDED01A02D5 for ; Tue, 28 Jan 2014 08:21: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 zzOcc-RzPi0Z for ; Tue, 28 Jan 2014 08:21:37 -0800 (PST)
Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id C8E0E1A02C0 for ; Tue, 28 Jan 2014 08:21:36 -0800 (PST)
Received: by mail-qc0-f178.google.com with SMTP id m20so852378qcx.23 for ; Tue, 28 Jan 2014 08:21:34 -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=RHfLdGjDg3XYePhV1qHHyOrNLvV2WhE2jxQsAdYuFwo=; b=eBBX4AZxWIAmiZD281XPkcTA+1wbN9uWWR/rk2Xrb7GiZ0CnK72MF1EsUAO5UR8UGD sOTpkC7i7fpFf0bBpItHwAjjynSux7sdOZ1qrczGfWvYunuB0DSqxRffEfe+bspMldo/ 6Vs/+xwd1tRz3YJMxc6ekvk/DJnf83c1p2j3gLru3x9mFbfFncKL23KRVNQ00tjMqiBA UPKTGNpO+wffRF6k4KKvlluXxCsqDgUn9kzjJafJrR9cKmmzZUpKhoKbp4S9KlzTucdn qhUx1UfbbCU0PThIYQP2cfqMxMRni2Tkj9mojK6pP4r47x/BjtOyAaY9JsdyUoXs4f8W 8OdA==
X-Gm-Message-State: ALoCoQlIa0xXcwJA1Z3Tn3g7PJHEbCzaLF+05cNzi2Xm5u1PjFHeqQrW0xIZAjHSNRhlxVGwSbqX
MIME-Version: 1.0
X-Received: by 10.229.194.1 with SMTP id dw1mr3891121qcb.20.1390926094050; Tue, 28 Jan 2014 08:21:34 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 28 Jan 2014 08:21:33 -0800 (PST)
In-Reply-To: 
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <20140128.114425.486388648.mbj@tail-f.com> <4D0EEFB1-AD82-4EDB-9DB4-797EAA758D4D@nic.cz> 
Date: Tue, 28 Jan 2014 08:21:33 -0800
Message-ID: 
From: Andy Bierman 
To: David Spakes 
Content-Type: multipart/alternative; boundary=001a11c2c736bed16704f10a37fc
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 28 Jan 2014 16:21:40 -0000

--001a11c2c736bed16704f10a37fc
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 28, 2014 at 8:08 AM, David Spakes  wrote:

> On Tue, 28 Jan 2014, Ladislav Lhotka wrote:
>
> > >>  typedef timezone-name {
> > >>    type string;
> > >>    description
> > >>     "A timezone name as used by the Time Zone Database, sometimes
> > >>      referred to as the 'Olson Database'.";
> > >>    reference
> > >>     "RFC 6557: Procedures for Maintaining the Time Zone Database";
> > >>  }
> > >
> > > I support this solution.
> > >
> > > However, I think we need to explain in the description text of the
> > > timezone-name typedef that servers will restrict the valid values for
> > > this type to whatever they support, and that how clients can learn
> > > which values are valid is out of scope for this document.
> >
> > A client also needs to be able to learn the corresponding UTC offsets
> > and DST rules.
> >
> > I don't have a strong opinion here but I wonder whether the benefits
> > of the string type outweigh the damage to interoperability. My concern
> > is that a string might be vulnerable not only to political, but also
> > marketing pressures.
>
>
> If the client has a way to view the list of strings recognized by the
> server together with their corresponding UTC offsets and DST changes,
> then we should be able to lay to rest any and all concerns about how
> political and marketing pressures affect the implementation of
> individual devices.
>
> I made a proposal a little over a week ago that is relevant.  No one
> commented on it at that time, but maybe it should be discussed now.
> Here it is again.
>
>
> On Fri, 17 Jan 2014, David Spakes wrote:
>
> > If the client needs to be able to see the list of strings that the
> > server is actually using, then the client should not reach out to the
> > TZ Database; it should consult the server.  In addition to the typedef,
> > the document should define a config false list of strings that the
> > server actually supports.
>
>
> Here is basically what I had in mind:
>
>   list known-timezones {
>     config false;
>
>     leaf name {
>       type timezone-name;
>     }
>     leaf utc-offset {
>       // whatever type is appropriate
>     }
>     leaf valid-time {
>       type uint32 {
>         range "0 .. 365";
>       }
>       description
>         "The number of days this advice is expected to remain valid.";
>     }
>   }
>
>
> To prepare to configure a device, a client would retrieve the list.
> A graphical-based client could use this information to populate a
> choice widget from which a human operator could select the desired
> value.  A non-interactive client could validate a predetermined
> selection or automatically make a choice based on the utc-offset.
>
> The valid-time would be used to set a timer in the client.  When the
> timer fires, it's time to review the choice and potentially reconfigure
> the device.  The client should retrieve the list again from the device
> in order to update the choice.  For countries with a predetermined date
> to switch between standard and daylight savings time, the valid-time
> would indicate the number of days until the next switch.  If a country
> (or state, or other municipality) chooses to modify the DST scheduled
> (as the United States did a couple of years ago), the valid-time would
> indicate the date when such a schedule change is expected.  If a date
> is unknown to the device, it could set the value to zero, which means
> "check back often".  In a region where there is no change for DST, the
> value would remain 365 every time the information is retrieved.
>
>

In order to justify all this extra work on the client and server, it would
help to understand the impact that timezone interoperability problems
are having on real deployments.

IMO the real TZ database is going to match the server values for
over 99.5% of the string values.  A few corner-cases are not worth
worrying about.




> -dss
>
>
Andy

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





On Tue, Jan 28, 2014 at 8:08 AM, David Spakes <=
;spakes@snmp.com&g=
t; wrote:


On Tue, 28 Jan 2014, Ladislav Lhotka wrote:<=
br>


> >> =A0typedef timezone-name {

> >> =A0 =A0type string;

> >> =A0 =A0description

> >> =A0 =A0 "A timezone name as used by the Time Zone Databa=
se, sometimes

> >> =A0 =A0 =A0referred to as the 'Olson Database'."=
;

> >> =A0 =A0reference

> >> =A0 =A0 "RFC 6557: Procedures for Maintaining the Time Z=
one Database";

> >> =A0}

> >

> > I support this solution.

> >

> > However, I think we need to explain in the description text of th=
e

> > timezone-name typedef that servers will restrict the valid values=
 for

> > this type to whatever they support, and that how clients can lear=
n

> > which values are valid is out of scope for this document.

>

> A client also needs to be able to learn the corresponding UTC offsets<=
br>
> and DST rules.

>

> I don't have a strong opinion here but I wonder whether the benefi=
ts

> of the string type outweigh the damage to interoperability. My concern=


> is that a string might be vulnerable not only to political, but also
> marketing pressures.





If the client has a way to view the list of strings recognized by the

server together with their corresponding UTC offsets and DST changes,

then we should be able to lay to rest any and all concerns about how

political and marketing pressures affect the implementation of

individual devices.



I made a proposal a little over a week ago that is relevant. =A0No one

commented on it at that time, but maybe it should be discussed now.

Here it is again.





On Fri, 17 Jan 2014, David Spakes wrote:



> If the client needs to be able to see the list of strings that the

> server is actually using, then the client should not reach out to the<=
br>
> TZ Database; it should consult the server. =A0In addition to the typed=
ef,

> the document should define a config false list of strings that the

> server actually supports.





Here is basically what I had in mind:



=A0 list known-timezones {

=A0 =A0 config false;



=A0 =A0 leaf name {

=A0 =A0 =A0 type timezone-name;

=A0 =A0 }

=A0 =A0 leaf utc-offset {

=A0 =A0 =A0 // whatever type is appropriate

=A0 =A0 }

=A0 =A0 leaf valid-time {

=A0 =A0 =A0 type uint32 {

=A0 =A0 =A0 =A0 range "0 .. 365";

=A0 =A0 =A0 }

=A0 =A0 =A0 description

=A0 =A0 =A0 =A0 "The number of days this advice is expected to remain =
valid.";

=A0 =A0 }

=A0 }





To prepare to configure a device, a client would retrieve the list.

A graphical-based client could use this information to populate a

choice widget from which a human operator could select the desired

value. =A0A non-interactive client could validate a predetermined

selection or automatically make a choice based on the utc-offset.



The valid-time would be used to set a timer in the client. =A0When the

timer fires, it's time to review the choice and potentially reconfigure=


the device. =A0The client should retrieve the list again from the device
in order to update the choice. =A0For countries with a predetermined date
to switch between standard and daylight savings time, the valid-time

would indicate the number of days until the next switch. =A0If a country
(or state, or other municipality) chooses to modify the DST scheduled

(as the United States did a couple of years ago), the valid-time would

indicate the date when such a schedule change is expected. =A0If a date

is unknown to the device, it could set the value to zero, which means

"check back often". =A0In a region where there is no change for D=
ST, the

value would remain 365 every time the information is retrieved.




In order to justify all=
 this extra work on the client and server, it would
help to under=
stand the impact that timezone interoperability problems
are havi=
ng on real deployments.



IMO the real TZ database is going to match the server v=
alues for
over 99.5% of the string values. =A0A few corner-cases =
are not worth
worrying about.




=A0

-dss



Andy




--001a11c2c736bed16704f10a37fc--

From lhotka@nic.cz  Tue Jan 28 09:43:34 2014
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 18D3A1A0355 for ; Tue, 28 Jan 2014 09:43:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 KeNTtSBHGzR2 for ; Tue, 28 Jan 2014 09:43:32 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BA2E01A0351 for ; Tue, 28 Jan 2014 09:43:31 -0800 (PST)
Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id E4F6A13F766; Tue, 28 Jan 2014 18:43:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390931008; bh=/63AzUuSBYhJNCBep7ExKWtxV+JJQt6zrXmLrFBbEFk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NGa2AJ7bGTzooCCapuILm58B6HVprjXMfo/8jSAnSIQTfHtw9WH3BGXN8yTZGO55K DC7e2mySpUS/LeWg03FlhETLO52xscvw9Qq4WehAPd7i9Vz8Y0EY1v0yIvI2NnZKOQ Z/QGY6deDt8UEJ7mffkvwDTfbK9QvZYL8MV2+ya4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 28 Jan 2014 18:43:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <579DD59F-B668-4AB8-B08E-CF4F68B903CE@nic.cz>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <20140128.114425.486388648.mbj@tail-f.com> <4D0EEFB1-AD82-4EDB-9DB4-797EAA758D4D@nic.cz> 
To: David Spakes 
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] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 28 Jan 2014 17:43:34 -0000

On 28 Jan 2014, at 17:08, David Spakes  wrote:

> On Tue, 28 Jan 2014, Ladislav Lhotka wrote:
>=20
>>>> typedef timezone-name {
>>>>   type string;
>>>>   description
>>>>    "A timezone name as used by the Time Zone Database, sometimes
>>>>     referred to as the 'Olson Database'.";
>>>>   reference
>>>>    "RFC 6557: Procedures for Maintaining the Time Zone Database";
>>>> }
>>>=20
>>> I support this solution.
>>>=20
>>> However, I think we need to explain in the description text of the
>>> timezone-name typedef that servers will restrict the valid values =
for
>>> this type to whatever they support, and that how clients can learn
>>> which values are valid is out of scope for this document.
>>=20
>> A client also needs to be able to learn the corresponding UTC offsets
>> and DST rules.
>>=20
>> I don't have a strong opinion here but I wonder whether the benefits
>> of the string type outweigh the damage to interoperability. My =
concern
>> is that a string might be vulnerable not only to political, but also
>> marketing pressures.
>=20
>=20
> If the client has a way to view the list of strings recognized by the
> server together with their corresponding UTC offsets and DST changes,
> then we should be able to lay to rest any and all concerns about how
> political and marketing pressures affect the implementation of
> individual devices.
>=20
> I made a proposal a little over a week ago that is relevant.  No one
> commented on it at that time, but maybe it should be discussed now.
> Here it is again.

I don=92t get why it is preferable to have the poor server send all this =
info (which can be quite bulky) instead of letting the client to simply =
*configure* the timezone, perhaps using the POSIX format or any other =
means involving UTC offset and DST rules, provided the client knows the =
geographical location of the device.

>=20
>=20
> On Fri, 17 Jan 2014, David Spakes wrote:
>=20
>> If the client needs to be able to see the list of strings that the
>> server is actually using, then the client should not reach out to the
>> TZ Database; it should consult the server.  In addition to the =
typedef,
>> the document should define a config false list of strings that the
>> server actually supports.
>=20
>=20
> Here is basically what I had in mind:
>=20
>  list known-timezones {
>    config false;
>=20
>    leaf name {
>      type timezone-name;
>    }
>    leaf utc-offset {
>      // whatever type is appropriate
>    }
>    leaf valid-time {
>      type uint32 {
>        range "0 .. 365";
>      }
>      description
>        "The number of days this advice is expected to remain valid.";
>    }
>  }
>=20
>=20
> To prepare to configure a device, a client would retrieve the list.
> A graphical-based client could use this information to populate a
> choice widget from which a human operator could select the desired
> value.  A non-interactive client could validate a predetermined
> selection or automatically make a choice based on the utc-offset.
>=20
> The valid-time would be used to set a timer in the client.  When the
> timer fires, it's time to review the choice and potentially =
reconfigure
> the device.  The client should retrieve the list again from the device
> in order to update the choice.  For countries with a predetermined =
date
> to switch between standard and daylight savings time, the valid-time
> would indicate the number of days until the next switch.  If a country
> (or state, or other municipality) chooses to modify the DST scheduled
> (as the United States did a couple of years ago), the valid-time would
> indicate the date when such a schedule change is expected.  If a date
> is unknown to the device, it could set the value to zero, which means
> "check back often".  In a region where there is no change for DST, the
> value would remain 365 every time the information is retrieved.

I think the DST rules have to be specified exactly, pretty much as in =
the POSIX format, so that both local time and UTC offset never get out =
of sync.

Lada

>=20
> -dss
>=20
>=20
> -------------------------------------------------------------
> David Spakes                       email:   spakes@snmp.com
> SNMP Research                      voice:   +1 865 573 1434
> 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
> Knoxville, TN  37920-9716  USA      http://www.snmp.com
> -------------------------------------------------------------
>=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  Tue Jan 28 09:57:06 2014
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 05B631A0187 for ; Tue, 28 Jan 2014 09:57:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 Z7UYBEyeUM6h for ; Tue, 28 Jan 2014 09:57:04 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5C81A021A for ; Tue, 28 Jan 2014 09:57:04 -0800 (PST)
Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id EFF0213F766; Tue, 28 Jan 2014 18:57:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390931821; bh=FebsiEmsoE1hKFf6UxSJFxTs34WAvR3mSRVq01OpBX0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nQmGTa2Oxmm8ngEPuwrdkNIVO7HGd+JpIB+FJkbE7XYQPMo0oUzTRIysegQtYKHPY WVsocOiBdq5wFW/13gO7AqobgFK4rztU0pT4NnnXqjGXhwD7i/6MFjYETI4Spn5Wxo eIOfPnMDbj/EUscT/0NjaOfPBICqd7+CT/8KAOig=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 28 Jan 2014 18:57:00 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <611825BE-FD17-4427-8263-28F74F4E33E1@nic.cz>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <20140128.114425.486388648.mbj@tail-f.com> <4D0EEFB1-AD82-4EDB-9DB4-797EAA758D4D@nic.cz>  
To: Andy Bierman 
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] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 28 Jan 2014 17:57:06 -0000

On 28 Jan 2014, at 17:21, Andy Bierman  wrote:

>=20
>=20
>=20
> On Tue, Jan 28, 2014 at 8:08 AM, David Spakes  wrote:
> On Tue, 28 Jan 2014, Ladislav Lhotka wrote:
>=20
> > >>  typedef timezone-name {
> > >>    type string;
> > >>    description
> > >>     "A timezone name as used by the Time Zone Database, sometimes
> > >>      referred to as the 'Olson Database'.";
> > >>    reference
> > >>     "RFC 6557: Procedures for Maintaining the Time Zone =
Database";
> > >>  }
> > >
> > > I support this solution.
> > >
> > > However, I think we need to explain in the description text of the
> > > timezone-name typedef that servers will restrict the valid values =
for
> > > this type to whatever they support, and that how clients can learn
> > > which values are valid is out of scope for this document.
> >
> > A client also needs to be able to learn the corresponding UTC =
offsets
> > and DST rules.
> >
> > I don't have a strong opinion here but I wonder whether the benefits
> > of the string type outweigh the damage to interoperability. My =
concern
> > is that a string might be vulnerable not only to political, but also
> > marketing pressures.
>=20
>=20
> If the client has a way to view the list of strings recognized by the
> server together with their corresponding UTC offsets and DST changes,
> then we should be able to lay to rest any and all concerns about how
> political and marketing pressures affect the implementation of
> individual devices.
>=20
> I made a proposal a little over a week ago that is relevant.  No one
> commented on it at that time, but maybe it should be discussed now.
> Here it is again.
>=20
>=20
> On Fri, 17 Jan 2014, David Spakes wrote:
>=20
> > If the client needs to be able to see the list of strings that the
> > server is actually using, then the client should not reach out to =
the
> > TZ Database; it should consult the server.  In addition to the =
typedef,
> > the document should define a config false list of strings that the
> > server actually supports.
>=20
>=20
> Here is basically what I had in mind:
>=20
>   list known-timezones {
>     config false;
>=20
>     leaf name {
>       type timezone-name;
>     }
>     leaf utc-offset {
>       // whatever type is appropriate
>     }
>     leaf valid-time {
>       type uint32 {
>         range "0 .. 365";
>       }
>       description
>         "The number of days this advice is expected to remain valid.";
>     }
>   }
>=20
>=20
> To prepare to configure a device, a client would retrieve the list.
> A graphical-based client could use this information to populate a
> choice widget from which a human operator could select the desired
> value.  A non-interactive client could validate a predetermined
> selection or automatically make a choice based on the utc-offset.
>=20
> The valid-time would be used to set a timer in the client.  When the
> timer fires, it's time to review the choice and potentially =
reconfigure
> the device.  The client should retrieve the list again from the device
> in order to update the choice.  For countries with a predetermined =
date
> to switch between standard and daylight savings time, the valid-time
> would indicate the number of days until the next switch.  If a country
> (or state, or other municipality) chooses to modify the DST scheduled
> (as the United States did a couple of years ago), the valid-time would
> indicate the date when such a schedule change is expected.  If a date
> is unknown to the device, it could set the value to zero, which means
> "check back often".  In a region where there is no change for DST, the
> value would remain 365 every time the information is retrieved.
>=20
>=20
>=20
> In order to justify all this extra work on the client and server, it =
would
> help to understand the impact that timezone interoperability problems
> are having on real deployments.
>=20
> IMO the real TZ database is going to match the server values for
> over 99.5% of the string values.  A few corner-cases are not worth
> worrying about.

I agree. To this end, it would IMO be sufficient to publish the existing =
timezones module (the enumeration), and just get IANA out of the loop.

Lada

>=20
>=20
> =20
> -dss
>=20
>=20
> Andy
>=20
>=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  Tue Jan 28 10:26:04 2014
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 E73D61A02B2 for ; Tue, 28 Jan 2014 10:26:04 -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 xV0lBYpPFupK for ; Tue, 28 Jan 2014 10:26:02 -0800 (PST)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id D1B031A0240 for ; Tue, 28 Jan 2014 10:26:01 -0800 (PST)
Received: by mail-qa0-f52.google.com with SMTP id j15so976283qaq.25 for ; Tue, 28 Jan 2014 10:25:59 -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=komfa2kJ2Sn+md+cd8OP6SbF1EnJ/sKw8W6jXh7jdR0=; b=GTgPamVMC7V3yE4yQxTEAaxPU+BISoSb76k3Q6QuQHPzFoA9c+eJPNBK2LGGULQ7OL hW4ZESxyj82A5R675Fh9B3H2pK+i5cE5MqL/NTORMJ42p0fuIQo1MwRUhrAgTEmeilQ7 juA1vK+Bim+z7yKZT2yK/WNQ3791w5w4rArv8mffGU+PJpE6rtF8BTVHEziXDserBU8n G5hISJbzX/XmXq3VbYznNf7BXWU6onmOtt57rPT12NNgq1Yd661a5Wt1+mW349TePAKt KdRxyXCX6cX0EPQoA4RE4ruc1CRxMrLwoIclpR9zLc744Bg5hpa4fMZPn9hWQC+/PFin aZnw==
X-Gm-Message-State: ALoCoQkoIVbiQ2YlZa2tvQDDWCeRgdJUYMXT0Z/eZ6SfAvYWNzmCrMvHCFn1ZxF3TMsriynAnJAN
MIME-Version: 1.0
X-Received: by 10.140.85.179 with SMTP id n48mr4473990qgd.91.1390933559011; Tue, 28 Jan 2014 10:25:59 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 28 Jan 2014 10:25:58 -0800 (PST)
In-Reply-To: <611825BE-FD17-4427-8263-28F74F4E33E1@nic.cz>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <20140128.114425.486388648.mbj@tail-f.com> <4D0EEFB1-AD82-4EDB-9DB4-797EAA758D4D@nic.cz>   <611825BE-FD17-4427-8263-28F74F4E33E1@nic.cz>
Date: Tue, 28 Jan 2014 10:25:58 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11c133deb1007304f10bf468
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 28 Jan 2014 18:26:05 -0000

--001a11c133deb1007304f10bf468
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 28, 2014 at 9:57 AM, Ladislav Lhotka  wrote:

>
> On 28 Jan 2014, at 17:21, Andy Bierman  wrote:
>
> >
> >
> >
> > On Tue, Jan 28, 2014 at 8:08 AM, David Spakes  wrote:
> > On Tue, 28 Jan 2014, Ladislav Lhotka wrote:
> >
> > > >>  typedef timezone-name {
> > > >>    type string;
> > > >>    description
> > > >>     "A timezone name as used by the Time Zone Database, sometimes
> > > >>      referred to as the 'Olson Database'.";
> > > >>    reference
> > > >>     "RFC 6557: Procedures for Maintaining the Time Zone Database";
> > > >>  }
> > > >
> > > > I support this solution.
> > > >
> > > > However, I think we need to explain in the description text of the
> > > > timezone-name typedef that servers will restrict the valid values for
> > > > this type to whatever they support, and that how clients can learn
> > > > which values are valid is out of scope for this document.
> > >
> > > A client also needs to be able to learn the corresponding UTC offsets
> > > and DST rules.
> > >
> > > I don't have a strong opinion here but I wonder whether the benefits
> > > of the string type outweigh the damage to interoperability. My concern
> > > is that a string might be vulnerable not only to political, but also
> > > marketing pressures.
> >
> >
> > If the client has a way to view the list of strings recognized by the
> > server together with their corresponding UTC offsets and DST changes,
> > then we should be able to lay to rest any and all concerns about how
> > political and marketing pressures affect the implementation of
> > individual devices.
> >
> > I made a proposal a little over a week ago that is relevant.  No one
> > commented on it at that time, but maybe it should be discussed now.
> > Here it is again.
> >
> >
> > On Fri, 17 Jan 2014, David Spakes wrote:
> >
> > > If the client needs to be able to see the list of strings that the
> > > server is actually using, then the client should not reach out to the
> > > TZ Database; it should consult the server.  In addition to the typedef,
> > > the document should define a config false list of strings that the
> > > server actually supports.
> >
> >
> > Here is basically what I had in mind:
> >
> >   list known-timezones {
> >     config false;
> >
> >     leaf name {
> >       type timezone-name;
> >     }
> >     leaf utc-offset {
> >       // whatever type is appropriate
> >     }
> >     leaf valid-time {
> >       type uint32 {
> >         range "0 .. 365";
> >       }
> >       description
> >         "The number of days this advice is expected to remain valid.";
> >     }
> >   }
> >
> >
> > To prepare to configure a device, a client would retrieve the list.
> > A graphical-based client could use this information to populate a
> > choice widget from which a human operator could select the desired
> > value.  A non-interactive client could validate a predetermined
> > selection or automatically make a choice based on the utc-offset.
> >
> > The valid-time would be used to set a timer in the client.  When the
> > timer fires, it's time to review the choice and potentially reconfigure
> > the device.  The client should retrieve the list again from the device
> > in order to update the choice.  For countries with a predetermined date
> > to switch between standard and daylight savings time, the valid-time
> > would indicate the number of days until the next switch.  If a country
> > (or state, or other municipality) chooses to modify the DST scheduled
> > (as the United States did a couple of years ago), the valid-time would
> > indicate the date when such a schedule change is expected.  If a date
> > is unknown to the device, it could set the value to zero, which means
> > "check back often".  In a region where there is no change for DST, the
> > value would remain 365 every time the information is retrieved.
> >
> >
> >
> > In order to justify all this extra work on the client and server, it
> would
> > help to understand the impact that timezone interoperability problems
> > are having on real deployments.
> >
> > IMO the real TZ database is going to match the server values for
> > over 99.5% of the string values.  A few corner-cases are not worth
> > worrying about.
>
> I agree. To this end, it would IMO be sufficient to publish the existing
> timezones module (the enumeration), and just get IANA out of the loop.
>
>
I don't agree with using a snapshot as an enumeration.
New values added over time will get incorrectly rejected by the server.
Since the YANG module needs to be generated from the TZ database,
the client (and server) can just use that directly for validation.

If the double-validation that the YANG module provides is not correct
for any reason, then it just gets in the way.



> Lada
>
>
Andy

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





On Tue, Jan 28, 2014 at 9:57 AM, Ladislav Lhotka =
<lhotka@nic.cz>=
; wrote:




On 28 Jan 2014, at 17:21, Andy Bierman <andy@yumaworks.com> wrote:



>

>

>

> On Tue, Jan 28, 2014 at 8:08 AM, David Spakes <spakes@snmp.com> wrote:

> On Tue, 28 Jan 2014, Ladislav Lhotka wrote:

>

> > >> =A0typedef timezone-name {

> > >> =A0 =A0type string;

> > >> =A0 =A0description

> > >> =A0 =A0 "A timezone name as used by the Time Zone D=
atabase, sometimes

> > >> =A0 =A0 =A0referred to as the 'Olson Database'.&=
quot;;

> > >> =A0 =A0reference

> > >> =A0 =A0 "RFC 6557: Procedures for Maintaining the T=
ime Zone Database";

> > >> =A0}

> > >

> > > I support this solution.

> > >

> > > However, I think we need to explain in the description text =
of the

> > > timezone-name typedef that servers will restrict the valid v=
alues for

> > > this type to whatever they support, and that how clients can=
 learn

> > > which values are valid is out of scope for this document.
> >

> > A client also needs to be able to learn the corresponding UTC off=
sets

> > and DST rules.

> >

> > I don't have a strong opinion here but I wonder whether the b=
enefits

> > of the string type outweigh the damage to interoperability. My co=
ncern

> > is that a string might be vulnerable not only to political, but a=
lso

> > marketing pressures.

>

>

> If the client has a way to view the list of strings recognized by the<=
br>
> server together with their corresponding UTC offsets and DST changes,<=
br>
> then we should be able to lay to rest any and all concerns about how
> political and marketing pressures affect the implementation of

> individual devices.

>

> I made a proposal a little over a week ago that is relevant. =A0No one=


> commented on it at that time, but maybe it should be discussed now.
> Here it is again.

>

>

> On Fri, 17 Jan 2014, David Spakes wrote:

>

> > If the client needs to be able to see the list of strings that th=
e

> > server is actually using, then the client should not reach out to=
 the

> > TZ Database; it should consult the server. =A0In addition to the =
typedef,

> > the document should define a config false list of strings that th=
e

> > server actually supports.

>

>

> Here is basically what I had in mind:

>

> =A0 list known-timezones {

> =A0 =A0 config false;

>

> =A0 =A0 leaf name {

> =A0 =A0 =A0 type timezone-name;

> =A0 =A0 }

> =A0 =A0 leaf utc-offset {

> =A0 =A0 =A0 // whatever type is appropriate

> =A0 =A0 }

> =A0 =A0 leaf valid-time {

> =A0 =A0 =A0 type uint32 {

> =A0 =A0 =A0 =A0 range "0 .. 365";

> =A0 =A0 =A0 }

> =A0 =A0 =A0 description

> =A0 =A0 =A0 =A0 "The number of days this advice is expected to re=
main valid.";

> =A0 =A0 }

> =A0 }

>

>

> To prepare to configure a device, a client would retrieve the list.
> A graphical-based client could use this information to populate a

> choice widget from which a human operator could select the desired

> value. =A0A non-interactive client could validate a predetermined

> selection or automatically make a choice based on the utc-offset.

>

> The valid-time would be used to set a timer in the client. =A0When the=


> timer fires, it's time to review the choice and potentially reconf=
igure

> the device. =A0The client should retrieve the list again from the devi=
ce

> in order to update the choice. =A0For countries with a predetermined d=
ate

> to switch between standard and daylight savings time, the valid-time
> would indicate the number of days until the next switch. =A0If a count=
ry

> (or state, or other municipality) chooses to modify the DST scheduled<=
br>
> (as the United States did a couple of years ago), the valid-time would=


> indicate the date when such a schedule change is expected. =A0If a dat=
e

> is unknown to the device, it could set the value to zero, which means<=
br>
> "check back often". =A0In a region where there is no change =
for DST, the

> value would remain 365 every time the information is retrieved.

>

>

>

> In order to justify all this extra work on the client and server, it w=
ould

> help to understand the impact that timezone interoperability problems<=
br>
> are having on real deployments.

>

> IMO the real TZ database is going to match the server values for

> over 99.5% of the string values. =A0A few corner-cases are not worth
> worrying about.



I agree. To this end, it would IMO be sufficient to publish the existing ti=
mezones module (the enumeration), and just get IANA out of the loop.



I don't agree with using a snapsho=
t as an enumeration.
New values added over time will get incorrec=
tly rejected by the server.
Since the YANG module needs to be gen=
erated from the TZ database,


the client (and server) can just use that directly for validation.

If the double-validation that the YANG module provide=
s is not correct
for any reason, then it just gets in the way.


=A0

Lada



Andy
=A0


--001a11c133deb1007304f10bf468--

From randy_presuhn@mindspring.com  Tue Jan 28 10:34:56 2014
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 41B041A037C for ; Tue, 28 Jan 2014 10:34:56 -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 2svFOnvXKRWY for ; Tue, 28 Jan 2014 10:34:53 -0800 (PST)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6C21A0350 for ; Tue, 28 Jan 2014 10:34:53 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qLsLUMnTbfl+jGMNjs1xx/le6BPcKsL1KLZrq8e1UhlFL4aH4TL4YSZRJ+kaRhjG; 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.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1W8DUo-0006jB-AU for netmod@ietf.org; Tue, 28 Jan 2014 13:34:50 -0500
Received: from 99.23.160.213 by webmail.earthlink.net with HTTP; Tue, 28 Jan 2014 13:34:50 -0500
Message-ID: <32585597.1390934090319.JavaMail.root@mswamui-andean.atl.sa.earthlink.net>
Date: Tue, 28 Jan 2014 10:34:50 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbcae62292ae346d1ce65ce0fed91fd984b350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.24
Subject: Re: [netmod] consensus all: timezone-location and	draft-ietf-netmod-iana-timezones-03
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, 28 Jan 2014 18:34:56 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Jan 28, 2014 9:43 AM
>To: David Spakes 
>Cc: netmod@ietf.org
>Subject: Re: [netmod] consensus all: timezone-location and=09draft-ietf-ne=
tmod-iana-timezones-03
...
>I don=E2=80=99t get why it is preferable to have the poor server
>send all this info (which can be quite bulky) instead of
>letting the client to simply *configure* the timezone,
>perhaps using the POSIX format or any other means
>involving UTC offset and DST rules, provided the client
>knows the geographical location of the device.

(1) That location information might need to be quite detailed
in order to cope with the situation in, e.g., Arizona.
http://www.timeanddate.com/time/us/arizona-no-dst.html

(2) What are the implications for systems that move around,
e.g. on ships and planes and trains and people's pockets?

Randy

From lhotka@nic.cz  Tue Jan 28 10:41:28 2014
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 520B81A0368 for ; Tue, 28 Jan 2014 10:41:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 tidUIh8DnKZv for ; Tue, 28 Jan 2014 10:41:26 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DA33B1A0353 for ; Tue, 28 Jan 2014 10:41:25 -0800 (PST)
Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id AF24813F766; Tue, 28 Jan 2014 19:41:22 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390934482; bh=IR4kAWrXWh7J1iihuy0QqrRHpkPxvPoPFMhLtGaq7ns=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FvABcBuNKe0th3aHrSIs5IDRS47cGgiavmFAYvoBl260ymiOobq3wHBrVvqBUmvGs J6H4kQlWP+mroIfzqcJQXFULMJDOFAsLms50q2vvf42CvXDUPAkW+hG62BfD9wDK2q m5+D0smNDxW+MrIn7iCW87lv1Vo9v8zdEDEGAaC0=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 28 Jan 2014 19:41:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <052B00E1-34E5-4E57-BC33-E205CD28E36F@nic.cz>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <20140128.114425.486388648.mbj@tail-f.com> <4D0EEFB1-AD82-4EDB-9DB4-797EAA758D4D@nic.cz>   <611825BE-FD17-4427-8263-28F74F4E33E1@nic.cz> 
To: Andy Bierman 
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] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 28 Jan 2014 18:41:28 -0000

On 28 Jan 2014, at 19:25, Andy Bierman  wrote:

>=20
>=20
>=20
> On Tue, Jan 28, 2014 at 9:57 AM, Ladislav Lhotka  =
wrote:
>=20
> On 28 Jan 2014, at 17:21, Andy Bierman  wrote:
>=20
> >
> >
> >
> > On Tue, Jan 28, 2014 at 8:08 AM, David Spakes  =
wrote:
> > On Tue, 28 Jan 2014, Ladislav Lhotka wrote:
> >
> > > >>  typedef timezone-name {
> > > >>    type string;
> > > >>    description
> > > >>     "A timezone name as used by the Time Zone Database, =
sometimes
> > > >>      referred to as the 'Olson Database'.";
> > > >>    reference
> > > >>     "RFC 6557: Procedures for Maintaining the Time Zone =
Database";
> > > >>  }
> > > >
> > > > I support this solution.
> > > >
> > > > However, I think we need to explain in the description text of =
the
> > > > timezone-name typedef that servers will restrict the valid =
values for
> > > > this type to whatever they support, and that how clients can =
learn
> > > > which values are valid is out of scope for this document.
> > >
> > > A client also needs to be able to learn the corresponding UTC =
offsets
> > > and DST rules.
> > >
> > > I don't have a strong opinion here but I wonder whether the =
benefits
> > > of the string type outweigh the damage to interoperability. My =
concern
> > > is that a string might be vulnerable not only to political, but =
also
> > > marketing pressures.
> >
> >
> > If the client has a way to view the list of strings recognized by =
the
> > server together with their corresponding UTC offsets and DST =
changes,
> > then we should be able to lay to rest any and all concerns about how
> > political and marketing pressures affect the implementation of
> > individual devices.
> >
> > I made a proposal a little over a week ago that is relevant.  No one
> > commented on it at that time, but maybe it should be discussed now.
> > Here it is again.
> >
> >
> > On Fri, 17 Jan 2014, David Spakes wrote:
> >
> > > If the client needs to be able to see the list of strings that the
> > > server is actually using, then the client should not reach out to =
the
> > > TZ Database; it should consult the server.  In addition to the =
typedef,
> > > the document should define a config false list of strings that the
> > > server actually supports.
> >
> >
> > Here is basically what I had in mind:
> >
> >   list known-timezones {
> >     config false;
> >
> >     leaf name {
> >       type timezone-name;
> >     }
> >     leaf utc-offset {
> >       // whatever type is appropriate
> >     }
> >     leaf valid-time {
> >       type uint32 {
> >         range "0 .. 365";
> >       }
> >       description
> >         "The number of days this advice is expected to remain =
valid.";
> >     }
> >   }
> >
> >
> > To prepare to configure a device, a client would retrieve the list.
> > A graphical-based client could use this information to populate a
> > choice widget from which a human operator could select the desired
> > value.  A non-interactive client could validate a predetermined
> > selection or automatically make a choice based on the utc-offset.
> >
> > The valid-time would be used to set a timer in the client.  When the
> > timer fires, it's time to review the choice and potentially =
reconfigure
> > the device.  The client should retrieve the list again from the =
device
> > in order to update the choice.  For countries with a predetermined =
date
> > to switch between standard and daylight savings time, the valid-time
> > would indicate the number of days until the next switch.  If a =
country
> > (or state, or other municipality) chooses to modify the DST =
scheduled
> > (as the United States did a couple of years ago), the valid-time =
would
> > indicate the date when such a schedule change is expected.  If a =
date
> > is unknown to the device, it could set the value to zero, which =
means
> > "check back often".  In a region where there is no change for DST, =
the
> > value would remain 365 every time the information is retrieved.
> >
> >
> >
> > In order to justify all this extra work on the client and server, it =
would
> > help to understand the impact that timezone interoperability =
problems
> > are having on real deployments.
> >
> > IMO the real TZ database is going to match the server values for
> > over 99.5% of the string values.  A few corner-cases are not worth
> > worrying about.
>=20
> I agree. To this end, it would IMO be sufficient to publish the =
existing timezones module (the enumeration), and just get IANA out of =
the loop.
>=20
>=20
> I don't agree with using a snapshot as an enumeration.
> New values added over time will get incorrectly rejected by the =
server.

Unless and until the module changes, there is nothing new between the =
server and client that can be rejected. A problem might be with deleted =
timezones but I wonder whether this falls among the 0.05% you mentioned.

Lada

> Since the YANG module needs to be generated from the TZ database,
> the client (and server) can just use that directly for validation.
>=20
> If the double-validation that the YANG module provides is not correct
> for any reason, then it just gets in the way.
>=20
> =20
> Lada
>=20
>=20
> Andy
> =20

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





From andy@yumaworks.com  Tue Jan 28 10:59:31 2014
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 E91091A0355 for ; Tue, 28 Jan 2014 10:59:30 -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 jHk9yOj5R4gy for ; Tue, 28 Jan 2014 10:59:29 -0800 (PST)
Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id 927731A03B7 for ; Tue, 28 Jan 2014 10:59:29 -0800 (PST)
Received: by mail-qa0-f43.google.com with SMTP id o15so1051930qap.16 for ; Tue, 28 Jan 2014 10:59:26 -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=0H0PMHE83elV+a95y6bG3toIOVq5PRTtMOGM7bpQsdY=; b=LTm2QBjB7hYxDtRv2aODnXi0DQdcGKzHyMxr0J9Y4dvrzAzGYtAzsGPu8ZTeV4Ix/U Ufy7W5FSUbRJE6NwCHVcCIL+nnbiXiKGMvvwnKAupdrw5HXa2Qu2XfS2S+pTPgs16Zzq dR5S1zOA0vZfpiR0d6eqGxqZewW6mJsNvtTCnM4Lykbmj89ZXE4yXtT96ADRzVvzdmnj 5I5TjtoCJ8iO1VyC/GXWCLU7llG7BEquXxji5ENDwbsQbMSYOEtkFFxeKwYbrfHgvHTI GdMhtHb9h6vgTuT29kdZ3dufCfGGzdReC1HQL1kaYII2nfFPttEE8DdtwE3A9+w2ITLR afJw==
X-Gm-Message-State: ALoCoQkd5XGDnTau3YOfTF+WjlAimfM/UEJ6ejDLW7zYxdvlV9g4Hht/ELqZjmKSb3d8TqC/uJYm
MIME-Version: 1.0
X-Received: by 10.224.136.10 with SMTP id p10mr5244964qat.16.1390935566792; Tue, 28 Jan 2014 10:59:26 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Tue, 28 Jan 2014 10:59:26 -0800 (PST)
In-Reply-To: <052B00E1-34E5-4E57-BC33-E205CD28E36F@nic.cz>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <20140128.114425.486388648.mbj@tail-f.com> <4D0EEFB1-AD82-4EDB-9DB4-797EAA758D4D@nic.cz>   <611825BE-FD17-4427-8263-28F74F4E33E1@nic.cz>  <052B00E1-34E5-4E57-BC33-E205CD28E36F@nic.cz>
Date: Tue, 28 Jan 2014 10:59:26 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11c2a8b05d8a1404f10c6c00
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 28 Jan 2014 18:59:31 -0000

--001a11c2a8b05d8a1404f10c6c00
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 28, 2014 at 10:41 AM, Ladislav Lhotka  wrote:

> ....
> > I don't agree with using a snapshot as an enumeration.
> > New values added over time will get incorrectly rejected by the server.
>
> Unless and until the module changes, there is nothing new between the
> server and client that can be rejected. A problem might be with deleted
> timezones but I wonder whether this falls among the 0.05% you mentioned.
>
>

Martin posted an email showing there were 3 additions/year over
the last 2 years. I did not count the enums.
I guessed this rate was 0.5%


Lada
>

Andy

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





On Tue, Jan 28, 2014 at 10:41 AM, Ladislav Lhotka <lhotka@nic.cz&g=
t; wrote:



....

> I don't agree with using a snapshot as an enumeration.

> New values added over time will get incorrectly rejected by the server=
.



Unless and until the module changes, there is nothing new between the serve=
r and client that can be rejected. A problem might be with deleted timezone=
s but I wonder whether this falls among the 0.05% you mentioned.




Martin posted an email =
showing there were 3 additions/year over
the last 2 years. I did =
not count the enums.
I guessed this rate was 0.5%=A0





Lada

Andy
=A0


--001a11c2a8b05d8a1404f10c6c00--

From lhotka@nic.cz  Tue Jan 28 12:17:05 2014
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 7995E1A028B for ; Tue, 28 Jan 2014 12:17:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 W4a9NJrsNxKZ for ; Tue, 28 Jan 2014 12:17:04 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 038551A0378 for ; Tue, 28 Jan 2014 12:17:03 -0800 (PST)
Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id CF18613F963; Tue, 28 Jan 2014 21:16:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1390940220; bh=wRRrWW7HEuMwCew0AfBfHIHro0FCDFz6o8LA5AoHtIE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sBsDCjFoo96vXoaCuHGMbtpPLjjkmEuw02aAZbsqS9HyrF5T1GQYhZVuQ+OKA9gvT qZjNFEqTkjhw5B9kxEbJSoxJL/oS/Cj2LHjG0uIcwWRA0nz4dI7pdxHdSlehZONMvp G0dRrYR1QgdlUMnoc7W5gL21KeiWNaQMgJ5ssB3s=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 28 Jan 2014 21:16:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <13CCF916-75B5-4562-A724-B6E8BC06A69C@nic.cz>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> <20140128.114425.486388648.mbj@tail-f.com> <4D0EEFB1-AD82-4EDB-9DB4-797EAA758D4D@nic.cz>   <611825BE-FD17-4427-8263-28F74F4E33E1@nic.cz>  <052B00E1-34E5-4E57-BC33-E205CD28E36F@nic.cz> 
To: Andy Bierman 
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] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 28 Jan 2014 20:17:05 -0000

On 28 Jan 2014, at 19:59, Andy Bierman  wrote:

>=20
>=20
>=20
> On Tue, Jan 28, 2014 at 10:41 AM, Ladislav Lhotka  =
wrote:
> ....
> > I don't agree with using a snapshot as an enumeration.
> > New values added over time will get incorrectly rejected by the =
server.
>=20
> Unless and until the module changes, there is nothing new between the =
server and client that can be rejected. A problem might be with deleted =
timezones but I wonder whether this falls among the 0.05% you mentioned.
>=20
>=20
>=20
> Martin posted an email showing there were 3 additions/year over
> the last 2 years. I did not count the enums.
> I guessed this rate was 0.5%=20

New additions won=92t be available to NETCONF clients until the module =
gets updated, but this IMO presents very few practical problems, so the =
module needn=92t be changed with every tzdata database update.

Lada

>=20
>=20
> Lada
>=20
> Andy
> =20

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





From bclaise@cisco.com  Fri Jan 31 06:29:27 2014
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 3F41A1A0233; Fri, 31 Jan 2014 06:29:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.036
X-Spam-Level: 
X-Spam-Status: No, score=-10.036 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.535, 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 J6Ht3X_-4MQn; Fri, 31 Jan 2014 06:29:25 -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 6BBAD1A0064; Fri, 31 Jan 2014 06:29:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6257; q=dns/txt; s=iport; t=1391178561; x=1392388161; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qXagcwgxKR19tUYYRjkzmob2I/jOO8dg5dsh/jcNcYY=; b=Mp5F22hjXniNaIDAbN5x53Xl5btII4glu8XJ0Ds1L93a2vvmpW8D7Lmc olsvUwFLnwjoH/82VXMm5z58DtdYEsZSof0+leqMACWDTNqrBHHe87fBv s7z8bsyKyMTO0rsm3pMWFzMTVLFT4hY2F/bABJKlKbq9UOcP4fm+Ui44S Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgYFAOqy61KQ/khR/2dsb2JhbABZgww4g1i5aE+BBxZ0giUBAQEDAQEBASAPAQU2CgEQCxQEAgIFFgsCAgkDAgECAQ8GMBMBBQIBAQWHaAMJCA2rHJduDYktF4Epi0OCFgeCb4FJAQOWPoFshkiGFoVDgy47
X-IronPort-AV: E=Sophos;i="4.95,758,1384300800";  d="scan'208";a="4477120"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 31 Jan 2014 14:29:19 +0000
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0VETJDM009350; Fri, 31 Jan 2014 14:29:19 GMT
Message-ID: <52EBB33F.2090304@cisco.com>
Date: Fri, 31 Jan 2014 15:29:19 +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: akatlas@gmail.com
References:  <20140125.151847.09968453.mbj@tail-f.com>
In-Reply-To: <20140125.151847.09968453.mbj@tail-f.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: rtg-dir@ietf.org, rtg-ads@tools.ietf.org, netmod@ietf.org, draft-ietf-netmod-ip-cfg@tools.ietf.org
Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-ip-cfg-12
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, 31 Jan 2014 14:29:27 -0000

Alia,

Please let us know if your concerns are addressed.
We would like to progress the draft.

Regards, Benoit
> Hi,
>
> Alia Atlas  wrote:
>> Hello,
>>
>> I have been selected as the Routing Directorate reviewer for this draft.
>> The Routing Directorate seeks to review all routing or routing-related
>> drafts as they pass through IETF last call and IESG review. The purpose of
>> the review is to provide assistance to the Routing ADs. For more
>> information about the Routing Directorate, please see
>> http://www.ietf.org/iesg/directorate/routing.html
>>
>> Although these comments are primarily for the use of the Routing ADs, it
>> would be helpful if you could consider them along with any other IETF Last
>> Call comments that you receive, and strive to resolve them through
>> discussion or by updating the draft.
>>
>> Document: draft-ietf-netmod-ip-cfg-12.txt
>> Reviewer: Alia Atlas
>> Review Date: 22 January 2014
>> IETF LC End Date: 23 January 2014
>> Intended Status: Proposed Standard
>>
>> *Summary:*
>> I have a few minor concerns about this document (clarifying a few aspects)
>> that I think should be resolved before publication.
>>
>> *Comments:*
>> This document is very clearly written, but I did find a few details that
>> could use a bit more clarity.  I was able to figure out what was intended
>> by wandering through the referenced RFCs.
>>
>> *Major Issues:*
>> No major issues found.
>>
>> *Minor Issues:*
>>
>>
>>     1. ipv4/forwarding and ipv6/forwarding:  First, I wasn't sure what this
>>     meant or how it was different from ipv4/enable or ipv6/enable.   I went
>>     back to look at RFC 4293 to learn that ipv4/forwarding means “acting as a
>>     router and forwarding traffic not destined to the deviceâ€.  Could you
>>     clarify the text to add those key details into the description for
>>     ipv4/forwarding and ipv6/forwarding?
> I think this probably becomes more clear if we clarify the "enabled"
> leaf as you suggest below in (2).  With the suggested new text below
> maybe this "forwarding" leaf is ok?  Otherwise, we could write in the
> style of 4293:
>
> OLD:
>
>            "Controls if IPv4 packet forwarding is enabled or disabled
>             on this interface.";
>
> NEW:
>
>            "Controls IPv4 packet forwarding of datagrams received by,
>             but not addressed to, this interface.  IPv4 routers forward
>             datagrams.  IPv4 hosts do not (except those source-routed
>             via the host)";
>
>>     Second, I was surprised that the
>>     default is false; I think about this from the router perspective, of
>>     course, but a bit of explanation as to why that decision was made would be
>>     useful.
> The conceptual variable IsRouter, defined in RFC 4861, has FALSE as
> its default value.  (see more below).
>
>>     2. ipv4/enabled and ipv6/enabled:  Similarly, what is enabled by
>>     ipv4/enabled isn’t clear (unless I look at RFC 4293).   Could you clarify
>>     that it means connected to an IPv4 stack for sending out IPv4 packets and
>>     for receiving to-me packets and do the same clarification for ipv6/enabled?
> Would this work?
>
> OLD:
>
>            "Controls if IPv6 is enabled or disabled on this
>             interface.";
>
> NEW:
>
>            "Controls if IPv6 is enabled or disabled on this
>             interface.  When IPv6 is enabled, this interface is
>             connected to an IPv6 stack, and the interface can send
>             and receive IPv6 packets.";
>
>
>>     3. ipv4/mtu and ipv6/mtu:  This is discussing sending and receiving
>>     packets – a mention of the MRU would be useful and even quoting  RFC2460 in
>>     Sec 5 which says “From each link to which a node is directly attached,
>>     the node must be  able to accept packets as large as that link's MTU. “
>>     so it’s clear.
> Hmm, the current text says:
>
>          "The size, in octets, of the largest IPv6 packet that the
>           interface will send and receive.
>
> Isn't it clear that it applies also to the size of received packets?
> Or maybe I misunderstood your concern?
>
>
>>     4.  For the ARP cache (ipv4/neighbor) and ND cache (ipv6/neighbor), is
>>     there a reason that lastUpdated isn’t included?  This doesn’t seem to
>>     provide quite enough information to see whenr mappings were last updated?
>>     Is the assumption that there will be a ARP specific and ND specific YANG
>>     model for getting the details?
> No, the intention is that this model should be sufficient.
>
> There is not such "last updated" object defined in RFC 4861.  Also, it
> seems this information is not available in some implementations (not
> in linux).   Do other implementation typcially store this info?  If
> so, in what form?
>
>
>> *Nits:*
>>
>> I've put these as nits because I think that they are probably textual
>> errors rather than intentional...
>>
>>
>>     1.  ipv6/forwarding:   why is the reference RFC 4861 – neighbor
>>     discovery???  That seems like it applies to the neighbor info, unless I’ve
>>     misunderstood what ipv6/forwarding is doing…
> Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the
> interface, not to the neighbor.  This object is defined as:
>
>                       A flag indicating whether routing is enabled on
>                       this interface.  Enabling routing on the interface
>                       would imply that a router can forward packets to or
>                       from the interface.
>
> (The neighbor cache also tags each neighbor as being a router or not).
>
>
>>     2. In the second table in Sec 3, ipv4/neighbor/interface and
>>     ipv6/neighbor/interface are listed, but I don’t see them in state tree in
>>     Sec 2.  I think that’s because they aren’t necessary??
> No this is a bug - I forgot to remove these when we changed the data
> model at some time.  Thanks for spotting it!
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From tnadeau@lucidvision.com  Fri Jan 31 07:02:44 2014
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 DA31B1A1F1A for ; Fri, 31 Jan 2014 07:02:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 W-xUlyqnE2OK for ; Fri, 31 Jan 2014 07:02:39 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 185481A03F5 for ; Fri, 31 Jan 2014 07:02:39 -0800 (PST)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 3547326D3C1C; Fri, 31 Jan 2014 10:02:35 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_32BA0F67-CDF0-4281-A581-07CE3B8D783B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Nadeau 
In-Reply-To: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>
Date: Fri, 31 Jan 2014 10:02:34 -0500
Message-Id: 
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>
To: netmod@ietf.org
X-Mailer: Apple Mail (2.1827)
Cc: netmod-chairs@tools.ietf.org
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 31 Jan 2014 15:02:45 -0000

--Apple-Mail=_32BA0F67-CDF0-4281-A581-07CE3B8D783B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	I would like to call consensus on this matter. I've received =
%100 supporting comments for the proposal from the WG with no one not =
liking the proposal. The only comments received were from Martin and =
Benoit with regard to enhancing the description around the timezone-name =
typedef.  Document editors, please take those two comments into account =
and make the changes necessary. You might want to propose the text on =
the list before publishing as it should be a fairly minor change, but =
just to make sure it covers the comments received.

	--Tom


>=20
> 	Netmod WG:
>=20
> 	The working group chairs have considered the discussion =
concerning=20
> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
> draft-ietf-netmod-iana-timezones-03. In particular, we would like
> like to call consensus on the matter regarding that surfaced during
> the IETF last call with regard to the the practicability of =
maintaining a=20
> YANG module with an enumeration of timezone names. We believe there is
> consensus in the working group to move forward with the following=20
> resolution:
>=20
> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets
> extended to introduce a new typedef for timezone names, e.g.
> something that looks like:
>=20
>  typedef timezone-name {
>    type string;
>    description
>     "A timezone name as used by the Time Zone Database, sometimes
>      referred to as the 'Olson Database'.";
>    reference
>     "RFC 6557: Procedures for Maintaining the Time Zone Database";
>  }
>=20
> The timezone-location leaf will be changed to use this type,
> the import of iana-timezones will be removed and the references
> to I-D.ietf-netmod-iana-timezones will be removed.
>=20
> - The draft-ietf-netmod-iana-timezones-00 document will be pulled
> back and work on this draft will stop.  The I-D is declared dead.
>=20
> - Since there is nothing to do for IANA, there will be no IANA request=20=

> needed in this regard for draft-ietf-netmod-system-mgmt-11.=20
>=20
> 	We note that further alternatives can be added to the timezone
> choice in the future should the two mechanisms currently in place
> turn out to be insufficient in practice.
>=20
> 	We would like to give the WG sufficient time to raise any =
additional concerns or=20
> issues with regard to this issue and our path for resolving the issue =
at hand, and so we=20
> will accept comments/discussion on this matter until 8AM EDT on =
Tuesday, January 28, 2014.
> As Juergen has been closely involved with the matter, I will =
adjudicate any issues
> arising from this comment period.
>=20
> 	Thanks,
>=20
> 	Tom
>=20
>=20
>=20
>=20


--Apple-Mail=_32BA0F67-CDF0-4281-A581-07CE3B8D783B
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS67sKAAoJEPcO+I7eiUJZvUsP/RjMHSvw2yOdac4FU0+R8ATQ
RjAUxZa6gUUcTMkUZLApJveMnZG2JGNZ3IHK2vQYWxTObDRP9OoovXDo6srv2oXX
M7b5/CniURY5gKYP+Glsu+cjwMR+5lnOa+aji52whGp8FDF4HupJh3gnw3AfBVnx
hOfXWq8In14C737ugGHFr7lylsKMWL6wJgovfCArcklGf+rhNwBVA9tBLi4WE+y4
KyhZKFhJ/YKmUfhgcmK+GDJWf/7iYEbc4SALCSRBCNt9d+fG3nodwzgdNyzsMxc4
noR5LnjJwZpEe2ftXvyqaFcwECpB7ka65tEg3cUELvAZdAkC9EHN18gQ5c7CPA7O
37b6adAMiHbuwRdkeafX3k+eLV1a7lXa3q/GGynIMFl29uhG+ZHOalbsATGnhRgG
QT7GrHcC13BuQPCPKb49SGQOtRYY6RBI9VHLEBz5J5hcWayC/a92KvnDoDhmizgv
R2JuvAL4rJTDtq2lpxotbvWspClk4ka7E4lYvFMwu3SfWNFfyGO7aYC3pDzijUzN
tR5G9J4E/wRsmR4nMbe3epZWsjmTfxhIxI3UeHMcXeF7vxeoGqm7BznkaYbwRjWi
K+rMyHIi6oZ/2hy4o9tEFzd57C0y64SAlLJgnhCOCmkhy16V+E4Ca9j31EeGZ+DU
F/ZWeJJTyK3QH+LDETaP
=SDZM
-----END PGP SIGNATURE-----

--Apple-Mail=_32BA0F67-CDF0-4281-A581-07CE3B8D783B--

From akatlas@gmail.com  Fri Jan 31 07:13:29 2014
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 25C411A020C; Fri, 31 Jan 2014 07:13:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, 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 2BmsgxvK0Oo1; Fri, 31 Jan 2014 07:13:24 -0800 (PST)
Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) by ietfa.amsl.com (Postfix) with ESMTP id 14E931A0193; Fri, 31 Jan 2014 07:13:24 -0800 (PST)
Received: by mail-yk0-f176.google.com with SMTP id 131so24173439ykp.7 for ; Fri, 31 Jan 2014 07:12:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PklrJQLbqZatmpHyUZXE2nn/3ytnqghYnAyE+Sc6eUg=; b=Y1rqVc4NfINF60d/uKqgFspKkF03wKZsFgv9N51J91TXCdTlPvGu+uD8D3G4CUMmrP cZMoBQSNnpWWvC6zVSSyMO+kh/nKYRrYF3CQ/MZ7O2W4mrk0yr19t1YZt/AdRrHXCQmK wpIpW93XEB/6+4Ofu8RhTr/v1h10dyJ00tj92wa2Gryr+r43ANDqi+vHO+Qifc4uPO1G ZbQrMj2vJDj2FfbFsvTskgU17Xs0ncLOoN3Mj5MRWi7EFkjDc+4ucaILvBNnvnFm3c0u EUBLRVZgj7sOsqBQCeXcwA3gz4IyFCQq90gscCSGRaKdecIbDp/ScW674tUZiA+R8aNr GV5g==
MIME-Version: 1.0
X-Received: by 10.236.200.35 with SMTP id y23mr18870884yhn.38.1391181163075; Fri, 31 Jan 2014 07:12:43 -0800 (PST)
Received: by 10.170.186.88 with HTTP; Fri, 31 Jan 2014 07:12:43 -0800 (PST)
In-Reply-To: <20140125.151847.09968453.mbj@tail-f.com>
References:  <20140125.151847.09968453.mbj@tail-f.com>
Date: Fri, 31 Jan 2014 10:12:43 -0500
Message-ID: 
From: Alia Atlas 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=bcaec50b4bde0b2bf404f1459bb4
Cc: "rtg-dir@ietf.org" , draft-ietf-netmod-ip-cfg@tools.ietf.org, "netmod@ietf.org" , "rtg-ads@tools.ietf.org" 
Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-ip-cfg-12
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, 31 Jan 2014 15:13:29 -0000

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

Responses in-line.


On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund  wrote:

> Hi,
>
> Alia Atlas  wrote:
> > Hello,
> >
> > I have been selected as the Routing Directorate reviewer for this draft.
> > The Routing Directorate seeks to review all routing or routing-related
> > drafts as they pass through IETF last call and IESG review. The purpose
> of
> > the review is to provide assistance to the Routing ADs. For more
> > information about the Routing Directorate, please see
> > http://www.ietf.org/iesg/directorate/routing.html
> >
> > Although these comments are primarily for the use of the Routing ADs, it
> > would be helpful if you could consider them along with any other IETF
> Last
> > Call comments that you receive, and strive to resolve them through
> > discussion or by updating the draft.
> >
> > Document: draft-ietf-netmod-ip-cfg-12.txt
> > Reviewer: Alia Atlas
> > Review Date: 22 January 2014
> > IETF LC End Date: 23 January 2014
> > Intended Status: Proposed Standard
> >
> > *Summary:*
> > I have a few minor concerns about this document (clarifying a few
> aspects)
> > that I think should be resolved before publication.
> >
> > *Comments:*
> > This document is very clearly written, but I did find a few details that
> > could use a bit more clarity.  I was able to figure out what was intended
> > by wandering through the referenced RFCs.
> >
> > *Major Issues:*
> > No major issues found.
> >
> > *Minor Issues:*
> >
> >
> >    1. ipv4/forwarding and ipv6/forwarding:  First, I wasn't sure what
> this
> >    meant or how it was different from ipv4/enable or ipv6/enable.   I
> went
> >    back to look at RFC 4293 to learn that ipv4/forwarding means "acting
> as a
> >    router and forwarding traffic not destined to the device".  Could you
> >    clarify the text to add those key details into the description for
> >    ipv4/forwarding and ipv6/forwarding?
>
> I think this probably becomes more clear if we clarify the "enabled"
> leaf as you suggest below in (2).  With the suggested new text below
> maybe this "forwarding" leaf is ok?  Otherwise, we could write in the
> style of 4293:
>
> OLD:
>
>           "Controls if IPv4 packet forwarding is enabled or disabled
>            on this interface.";
>
> NEW:
>
>           "Controls IPv4 packet forwarding of datagrams received by,
>            but not addressed to, this interface.  IPv4 routers forward
>            datagrams.  IPv4 hosts do not (except those source-routed
>            via the host)";
>
[Alia] Perfect

>
> >    Second, I was surprised that the
> >    default is false; I think about this from the router perspective, of
> >    course, but a bit of explanation as to why that decision was made
> would be
> >    useful.
>
> The conceptual variable IsRouter, defined in RFC 4861, has FALSE as
> its default value.  (see more below).
>
> [Alia] That's fine.


> >    2. ipv4/enabled and ipv6/enabled:  Similarly, what is enabled by
> >    ipv4/enabled isn't clear (unless I look at RFC 4293).   Could you
> clarify
> >    that it means connected to an IPv4 stack for sending out IPv4 packets
> and
> >    for receiving to-me packets and do the same clarification for
> ipv6/enabled?
>
> Would this work?
>
> OLD:
>
>           "Controls if IPv6 is enabled or disabled on this
>            interface.";
>
> NEW:
>
>           "Controls if IPv6 is enabled or disabled on this
>            interface.  When IPv6 is enabled, this interface is
>            connected to an IPv6 stack, and the interface can send
>            and receive IPv6 packets.";
>
[Alia] Sounds great - same for IPv4?

>
>
> >    3. ipv4/mtu and ipv6/mtu:  This is discussing sending and receiving
> >    packets - a mention of the MRU would be useful and even quoting
>  RFC2460 in
> >    Sec 5 which says "From each link to which a node is directly attached,
> >    the node must be  able to accept packets as large as that link's MTU.
> "
> >    so it's clear.
>
> Hmm, the current text says:
>
>         "The size, in octets, of the largest IPv6 packet that the
>          interface will send and receive.
>
> Isn't it clear that it applies also to the size of received packets?
> Or maybe I misunderstood your concern?
>

[Alia] MRU and MTU do not need to be the same thing.  The current text
assumes that it is - and I agree that is a common way of configuring both
in a single move.  I was just looking for a bit more clarity that you
really do mean MRU as well.  It's not something that I feel strongly about.

>
> >    4.  For the ARP cache (ipv4/neighbor) and ND cache (ipv6/neighbor), is
> >    there a reason that lastUpdated isn't included?  This doesn't seem to
> >    provide quite enough information to see whenr mappings were last
> updated?
> >    Is the assumption that there will be a ARP specific and ND specific
> YANG
> >    model for getting the details?
>
> No, the intention is that this model should be sufficient.
>
> There is not such "last updated" object defined in RFC 4861.  Also, it
> seems this information is not available in some implementations (not
> in linux).   Do other implementation typcially store this info?  If
> so, in what form?
>

[Alia] I was looking at RFC 4293 and your table of comparison of objects
between this YANG model and that MIB.  If you look at the MIB, it has the
following:

IpNetToPhysicalEntry ::= SEQUENCE {
        ipNetToPhysicalIfIndex         InterfaceIndex,
        ipNetToPhysicalNetAddressType  InetAddressType,
        ipNetToPhysicalNetAddress      InetAddress,
        ipNetToPhysicalPhysAddress     PhysAddress,
        ipNetToPhysicalLastUpdated     TimeStamp,
        ipNetToPhysicalType            INTEGER,
        ipNetToPhysicalState           INTEGER,
        ipNetToPhysicalRowStatus       RowStatus
    }


ipNetToPhysicalLastUpdated OBJECT-TYPE
    SYNTAX     TimeStamp
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
           "The value of sysUpTime at the time this entry was last
            updated.  If this entry was updated prior to the last re-
            initialization of the local network management subsystem,
            then this object contains a zero value."
    ::= { ipNetToPhysicalEntry 5 }



The only piece of information not captured in the YANG model that I noticed
is the ipNetToPhysicalLastUpdated.

That is why I asked about it being intentionally left out versus
accidentally.


> > *Nits:*
> >
> > I've put these as nits because I think that they are probably textual
> > errors rather than intentional...
> >
> >
> >    1.  ipv6/forwarding:   why is the reference RFC 4861 - neighbor
> >    discovery???  That seems like it applies to the neighbor info, unless
> I've
> >    misunderstood what ipv6/forwarding is doing...
>
> Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the
> interface, not to the neighbor.  This object is defined as:
>
>                      A flag indicating whether routing is enabled on
>                      this interface.  Enabling routing on the interface
>                      would imply that a router can forward packets to or
>                      from the interface.
>
> (The neighbor cache also tags each neighbor as being a router or not).
>
[Alia] Ok - but a reference to the RFC for neighbor discovery is really not
clear when all you are talking about is whether the interface routes
packets or not.  PLEASE either add a more specific reference to the section
or otherwise clarify.  I do think that the text changes we discussed above
will help also.


>
> >    2. In the second table in Sec 3, ipv4/neighbor/interface and
> >    ipv6/neighbor/interface are listed, but I don't see them in state
> tree in
> >    Sec 2.  I think that's because they aren't necessary??
>
> No this is a bug - I forgot to remove these when we changed the data
> model at some time.  Thanks for spotting it!


[Alia] Another pair of eyes :-)  Glad to help.

Sorry for the delayed response,
Alia

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


Responses in-line.


<=
div class=3D"gmail_quote">On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund=
 <=
mbj@tail-f.com> wrote:


Hi,




Alia Atlas <akatlas@gmail.com&g=
t; wrote:

> Hello,

>

> I have been selected as the Routing Directorate reviewer for this draf=
t.

> The Routing Directorate seeks to review all routing or routing-related=


> drafts as they pass through IETF last call and IESG review. The purpos=
e of

> the review is to provide assistance to the Routing ADs. For more

> information about the Routing Directorate, please see

> http://www.ietf.org/iesg/directorate/routing.html

>

> Although these comments are primarily for the use of the Routing ADs, =
it

> would be helpful if you could consider them along with any other IETF =
Last

> Call comments that you receive, and strive to resolve them through

> discussion or by updating the draft.

>

> Document: draft-ietf-netmod-ip-cfg-12.txt

> Reviewer: Alia Atlas

> Review Date: 22 January 2014

> IETF LC End Date: 23 January 2014

> Intended Status: Proposed Standard

>


> *Summary:*


> I have a few minor concerns about this document (cla=
rifying a few aspects)

> that I think should be resolved before publication.

>


> *Comments:*


> This document is very clearly written, but I did fin=
d a few details that

> could use a bit more clarity.  I was able to figure out what was =
intended

> by wandering through the referenced RFCs.

>


> *Major Issues:*

> No major issues found.

>

> *Minor Issues:*

>

>

>    1. ipv4/forwarding and ipv6/forwarding:  First, I wa=
sn't sure what this


>    meant or how it was different from ipv4=
/enable or ipv6/enable.   I went

>    back to look at RFC 4293 to learn that ipv4/forwarding me=
ans “acting as a

>    router and forwarding traffic not destined to the device&=
rdquo;.  Could you

>    clarify the text to add those key details into the descri=
ption for

>    ipv4/forwarding and ipv6/forwarding?




I think this probably becomes more clear if we clarify the "enab=
led"

leaf as you suggest below in (2).  With the suggested new text below
maybe this "forwarding" leaf is ok?  Otherwise, we could wri=
te in the

style of 4293:



OLD:



          "Controls if IPv4 packet forwarding=
 is enabled or disabled

           on this interface.";



NEW:



          "Controls IPv4 packet forwarding of=
 datagrams received by,

           but not addressed to, this interfa=
ce.  IPv4 routers forward

           datagrams.  IPv4 hosts do not=
 (except those source-routed

           via the host)";
[Alia] Perfect 





>    Second, I was surprised that the

>    default is false; I think about this from the router pers=
pective, of

>    course, but a bit of explanation as to why that decision =
was made would be

>    useful.




The conceptual variable IsRouter, defined in RFC 4861, has FALSE as
its default value.  (see more below).



[Alia] That's fine.
=

 



>    2. ipv4/enabled and ipv6/enabled:  Similarly, what i=
s enabled by

>    ipv4/enabled isn’t clear (unless I look at RFC 4293=
).   Could you clarify

>    that it means connected to an IPv4 stack for sending out =
IPv4 packets and

>    for receiving to-me packets and do the same clarification=
 for ipv6/enabled?




Would this work?



OLD:



          "Controls if IPv6 is enabled or dis=
abled on this

           interface.";



NEW:



          "Controls if IPv6 is enabled or dis=
abled on this

           interface.  When IPv6 is enab=
led, this interface is

           connected to an IPv6 stack, and th=
e interface can send

           and receive IPv6 packets.";
[Alia] Sounds great - same for IPv4? 






>    3. ipv4/mtu and ipv6/mtu:  This is discussing sendin=
g and receiving


>    packets – a mention of the MRU wo=
uld be useful and even quoting  RFC2460 in

>    Sec 5 which says “From each link to which a node is=
 directly attached,

>    the node must be  able to accept packets as large as=
 that link's MTU. “

>    so it’s clear.




Hmm, the current text says:



        "The size, in octets, of the largest IPv6 =
packet that the

         interface will send and receive.



Isn't it clear that it applies also to the size of received packets?
Or maybe I misunderstood your concern?

=
[Alia] MRU and MTU do not need to be the same thing.  The current text=
 assumes that it is - and I agree that is a common way of configuring both =
in a single move.  I was just looking for a bit more clarity that you =
really do mean MRU as well.  It's not something that I feel strong=
ly about. 





>    4.  For the ARP cache (ipv4/neighbor) and ND cache (=
ipv6/neighbor), is


>    there a reason that lastUpdated isn&rsq=
uo;t included?  This doesn’t seem to

>    provide quite enough information to see whenr mappings we=
re last updated?

>    Is the assumption that there will be a ARP specific and N=
D specific YANG

>    model for getting the details?




No, the intention is that this model should be sufficient.



There is not such "last updated" object defined in RFC 4861. &nbs=
p;Also, it

seems this information is not available in some implementations (not

in linux).   Do other implementation typcially store this info?  =
If

so, in what form?

[Alia] I was looking =
at RFC 4293 and your table of comparison of objects between this YANG model=
 and that MIB.  If you look at the MIB, it has the following:


IpNetToPhysicalEntry ::=3D SEQUENCE {
        ipNetToPhysicalIfIndex         InterfaceIndex,
        ipNetToPhysicalNetAddressType  InetAddressType,
        ipNetToPhysicalNetAddress      InetAddress,
        ipNetToPhysicalPhysAddress     PhysAddress,
        ipNetToPhysicalLastUpdated     TimeStamp,
        ipNetToPhysicalType            INTEGER,
        ipNetToPhysicalState           INTEGER,
        ipNetToPhysicalRowStatus       RowStatus
    }


ipNetToPhysicalLastUpdated OBJECT-TYPE
    SYNTAX     TimeStamp
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
           "The value of sysUpTime at the time this entry was last
            updated.  If this entry was updated prior to the last re-
            initialization of the local network management subsystem,
            then this object contains a zero value."
    ::=3D { ipNetToPhysicalEntry 5 }



The only pie=
ce of information not captured in the YANG model that I noticed is the ipNe=
tToPhysicalLastUpdated.



That is why I asked about it being intentionally left o=
ut versus accidentally.
 

> *Nits:*


>

> I've put these as nits because I think that they are probably text=
ual

> errors rather than intentional...

>

>


>    1.  ipv6/forwarding:   why is the referen=
ce RFC 4861 – neighbor


>    discovery???  That seems like it a=
pplies to the neighbor info, unless I’ve

>    misunderstood what ipv6/forwarding is doing…




Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the

interface, not to the neighbor.  This object is defined as:



                     =
;A flag indicating whether routing is enabled on

                     =
;this interface.  Enabling routing on the interface

                     =
;would imply that a router can forward packets to or

                     =
;from the interface.



(The neighbor cache also tags each neighbor as being a router or not).
<=
/blockquote>
[Alia] Ok - but a reference to the RFC for neighbor discov=
ery is really not clear when all you are talking about is whether the inter=
face routes packets or not.  PLEASE either add a more specific referen=
ce to the section or otherwise clarify.  I do think that the text chan=
ges we discussed above will help also. 


 



>    2. In the second table in Sec 3, ipv4/neighbor/interface =
and


>    ipv6/neighbor/interface are listed, but=
 I don’t see them in state tree in

>    Sec 2.  I think that’s because they aren&rsquo=
;t necessary??




No this is a bug - I forgot to remove these when we changed the data<=
br>
model at some time.  Thanks for spotting it!

[Alia] Another pair of eyes :-)  Glad to help.

Sorry for the delayed response,
Alia 


--bcaec50b4bde0b2bf404f1459bb4--

From lhotka@nic.cz  Fri Jan 31 07:20:46 2014
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 1316E1A0589 for ; Fri, 31 Jan 2014 07:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 YyvJ-yRFxjNK for ; Fri, 31 Jan 2014 07:20:44 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EA33E1A028B for ; Fri, 31 Jan 2014 07:20:43 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C4E20140119; Fri, 31 Jan 2014 16:20:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391181640; bh=mliCE+WZKNViL8SgnOjJx50sr0DER/FFq2WWbBWXmYE=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=G9+PH99k0Xw0HJjgUTFzMCeieaRaDDBl0iy8q7nDY2RaJGonANpXwL+9ZHQZvJ+qJ +8WVDYPVvAQUvRgT0+IUmtl2J9dMNXcxbcSMUtLYtVYLMiL6Ve4udP+CMM9+pQLO/y TzCk/M6HrqtZnxXyUGroFJKCZ5h/k/XPs0Q/dZYg=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 31 Jan 2014 16:20:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com> 
To: Thomas Nadeau 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 31 Jan 2014 15:20:46 -0000

On 31 Jan 2014, at 16:02, Thomas Nadeau  wrote:

>=20
> 	I would like to call consensus on this matter. I've received =
%100 supporting comments for the proposal from the WG with no one not =
liking the proposal. The only comments received were from Martin and

You must have missed my comments, so let me say I don=92t like the =
proposal. I think we are throwing out the baby with the bath water.

Lada

>  Benoit with regard to enhancing the description around the =
timezone-name typedef.  Document editors, please take those two comments =
into account and make the changes necessary. You might want to propose =
the text on the list before publishing as it should be a fairly minor =
change, but just to make sure it covers the comments received.
>=20
> 	--Tom
>=20
>=20
>>=20
>> 	Netmod WG:
>>=20
>> 	The working group chairs have considered the discussion =
concerning=20
>> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
>> draft-ietf-netmod-iana-timezones-03. In particular, we would like
>> like to call consensus on the matter regarding that surfaced during
>> the IETF last call with regard to the the practicability of =
maintaining a=20
>> YANG module with an enumeration of timezone names. We believe there =
is
>> consensus in the working group to move forward with the following=20
>> resolution:
>>=20
>> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets
>> extended to introduce a new typedef for timezone names, e.g.
>> something that looks like:
>>=20
>> typedef timezone-name {
>>   type string;
>>   description
>>    "A timezone name as used by the Time Zone Database, sometimes
>>     referred to as the 'Olson Database'.";
>>   reference
>>    "RFC 6557: Procedures for Maintaining the Time Zone Database";
>> }
>>=20
>> The timezone-location leaf will be changed to use this type,
>> the import of iana-timezones will be removed and the references
>> to I-D.ietf-netmod-iana-timezones will be removed.
>>=20
>> - The draft-ietf-netmod-iana-timezones-00 document will be pulled
>> back and work on this draft will stop.  The I-D is declared dead.
>>=20
>> - Since there is nothing to do for IANA, there will be no IANA =
request=20
>> needed in this regard for draft-ietf-netmod-system-mgmt-11.=20
>>=20
>> 	We note that further alternatives can be added to the timezone
>> choice in the future should the two mechanisms currently in place
>> turn out to be insufficient in practice.
>>=20
>> 	We would like to give the WG sufficient time to raise any =
additional concerns or=20
>> issues with regard to this issue and our path for resolving the issue =
at hand, and so we=20
>> will accept comments/discussion on this matter until 8AM EDT on =
Tuesday, January 28, 2014.
>> As Juergen has been closely involved with the matter, I will =
adjudicate any issues
>> arising from this comment period.
>>=20
>> 	Thanks,
>>=20
>> 	Tom
>>=20
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From tnadeau@lucidvision.com  Fri Jan 31 07:28:30 2014
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 AD5761A020C for ; Fri, 31 Jan 2014 07:28:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 xQwewsphJkmy for ; Fri, 31 Jan 2014 07:28:28 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4841A02DA for ; Fri, 31 Jan 2014 07:28:28 -0800 (PST)
Received: from [192.168.1.110] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id E43D726D3D13; Fri, 31 Jan 2014 10:28:24 -0500 (EST)
Content-Type: multipart/signed; boundary="Apple-Mail=_8C6D02E1-14D3-49A7-B702-56B585AE027C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Thomas Nadeau 
In-Reply-To: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz>
Date: Fri, 31 Jan 2014 10:28:23 -0500
Message-Id: <46B81EE3-7E8E-4818-97FA-1ED40583B1AC@lucidvision.com>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>  <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz>
To: Ladislav Lhotka 
X-Mailer: Apple Mail (2.1827)
Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 31 Jan 2014 15:28:30 -0000

--Apple-Mail=_8C6D02E1-14D3-49A7-B702-56B585AE027C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


	Fair enough.  Point taken.=20

	--Tom



On Jan 31, 2014:10:20 AM, at 10:20 AM, Ladislav Lhotka  =
wrote:

>=20
> On 31 Jan 2014, at 16:02, Thomas Nadeau  =
wrote:
>=20
>>=20
>> 	I would like to call consensus on this matter. I've received =
%100 supporting comments for the proposal from the WG with no one not =
liking the proposal. The only comments received were from Martin and
>=20
> You must have missed my comments, so let me say I don=92t like the =
proposal. I think we are throwing out the baby with the bath water.
>=20
> Lada
>=20
>> Benoit with regard to enhancing the description around the =
timezone-name typedef.  Document editors, please take those two comments =
into account and make the changes necessary. You might want to propose =
the text on the list before publishing as it should be a fairly minor =
change, but just to make sure it covers the comments received.
>>=20
>> 	--Tom
>>=20
>>=20
>>>=20
>>> 	Netmod WG:
>>>=20
>>> 	The working group chairs have considered the discussion =
concerning=20
>>> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
>>> draft-ietf-netmod-iana-timezones-03. In particular, we would like
>>> like to call consensus on the matter regarding that surfaced during
>>> the IETF last call with regard to the the practicability of =
maintaining a=20
>>> YANG module with an enumeration of timezone names. We believe there =
is
>>> consensus in the working group to move forward with the following=20
>>> resolution:
>>>=20
>>> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets
>>> extended to introduce a new typedef for timezone names, e.g.
>>> something that looks like:
>>>=20
>>> typedef timezone-name {
>>>  type string;
>>>  description
>>>   "A timezone name as used by the Time Zone Database, sometimes
>>>    referred to as the 'Olson Database'.";
>>>  reference
>>>   "RFC 6557: Procedures for Maintaining the Time Zone Database";
>>> }
>>>=20
>>> The timezone-location leaf will be changed to use this type,
>>> the import of iana-timezones will be removed and the references
>>> to I-D.ietf-netmod-iana-timezones will be removed.
>>>=20
>>> - The draft-ietf-netmod-iana-timezones-00 document will be pulled
>>> back and work on this draft will stop.  The I-D is declared dead.
>>>=20
>>> - Since there is nothing to do for IANA, there will be no IANA =
request=20
>>> needed in this regard for draft-ietf-netmod-system-mgmt-11.=20
>>>=20
>>> 	We note that further alternatives can be added to the timezone
>>> choice in the future should the two mechanisms currently in place
>>> turn out to be insufficient in practice.
>>>=20
>>> 	We would like to give the WG sufficient time to raise any =
additional concerns or=20
>>> issues with regard to this issue and our path for resolving the =
issue at hand, and so we=20
>>> will accept comments/discussion on this matter until 8AM EDT on =
Tuesday, January 28, 2014.
>>> As Juergen has been closely involved with the matter, I will =
adjudicate any issues
>>> arising from this comment period.
>>>=20
>>> 	Thanks,
>>>=20
>>> 	Tom
>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
>=20


--Apple-Mail=_8C6D02E1-14D3-49A7-B702-56B585AE027C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJS68EXAAoJEPcO+I7eiUJZQh8P/1iuJB6ILSEOHPWhJXVa05KU
XmsTy8y8NcSMDnOksQGK9VXsRMawvmygu3zZS+bg6/fVI1iJN2LjSakkwsmisrAj
taZcg6ZYPic1oYt/tSPX+d5MJaPzF48SfeAvPRZq4y2rWV2f6dVHsCkCjmiaWifY
Vs1fMF2WZXQGp0XAWnMMhAkdc3muijNy+7w9kdTB+SqJBEpfMEU54/wPjwRwGou8
TgSUBKFNqV6CrkPVidlJnqdjPP7Zq0SFbY5jXMxAIhVCiMh8bpcpbuhMJYHsZpTB
de7UYyuBz3F7sK6kjlLGPg60feczUj2bmsXQK7B5KjUIQRjfALs6EbCbmA1kSNdq
8r40yq16FN200LjAg85/UqmEh3nlPaaDNtggljDFYeWQU7MpY7PGu+CbemFwWBt9
MgoNV05oUjsIGRiNeyKmBBi2N1Yrfo1+/XF2AEbruWrU4UhmMQEH57Rw2dzJ8kii
tURzkXsv0zaxvYIPKpvUJAxC1h9lOxm/Uh7KfVGIjqXJxWmCIja5zWTqVtFC+AHc
NefrH8HytjI4N2dLx7bPMm3GOTQ22cUs2L1UFCZjYZzt2VxRnOTtjMWkGvpevurB
TTesP+uV8BEHj+JbcPe1kI97f5h7n7is3rAtPZr90wfeTITB3RHVFiicCbfpNGuD
dAxB+RR2mrsgy4MffV9/
=3NJq
-----END PGP SIGNATURE-----

--Apple-Mail=_8C6D02E1-14D3-49A7-B702-56B585AE027C--

From lhotka@nic.cz  Fri Jan 31 07:41:11 2014
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 9E42C1A0522; Fri, 31 Jan 2014 07:41:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.186
X-Spam-Level: 
X-Spam-Status: No, score=-1.186 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.535] 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 gS85gG5gbUZf; Fri, 31 Jan 2014 07:41:10 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BED2A1A03F5; Fri, 31 Jan 2014 07:41:10 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 56DCA14014E; Fri, 31 Jan 2014 16:41:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391182866; bh=IwtHjqDdKC755ht30afYFTbyGAG18gR7UJh/D2IfRkU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qDeP6sDhM330IAmTKWVFMMM/299uZP4cSkdoJk+yHm9thMDnXtz1nCUIexc8vatLg pnxqVB4fWiOMcpZxbyeUkx7gyk8ZRU5AQlxz+6hSsLhELWO3nFkMh26x5p61JLYwOj o9FdTIGGKp6ln7P/z1XOWpzmetqujOHtbHII1TJM=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 31 Jan 2014 16:41:07 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E60D80A-7F2C-491E-9F5D-BC892E719E92@nic.cz>
References:  <20140125.151847.09968453.mbj@tail-f.com> 
To: Alia Atlas 
X-Mailer: Apple Mail (2.1827)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: "rtg-dir@ietf.org" , "rtg-ads@tools.ietf.org" , "netmod@ietf.org" , draft-ietf-netmod-ip-cfg@tools.ietf.org
Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-ip-cfg-12
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, 31 Jan 2014 15:41:11 -0000

On 31 Jan 2014, at 16:12, Alia Atlas  wrote:

> >    1. ipv4/forwarding and ipv6/forwarding:  First, I wasn't sure =
what this
> >    meant or how it was different from ipv4/enable or ipv6/enable.   =
I went
> >    back to look at RFC 4293 to learn that ipv4/forwarding means =
=93acting as a
> >    router and forwarding traffic not destined to the device=94.  =
Could you
> >    clarify the text to add those key details into the description =
for
> >    ipv4/forwarding and ipv6/forwarding?
>=20
> I think this probably becomes more clear if we clarify the "enabled"
> leaf as you suggest below in (2).  With the suggested new text below
> maybe this "forwarding" leaf is ok?  Otherwise, we could write in the
> style of 4293:
>=20
> OLD:
>=20
>           "Controls if IPv4 packet forwarding is enabled or disabled
>            on this interface.";
>=20
> NEW:
>=20
>           "Controls IPv4 packet forwarding of datagrams received by,
>            but not addressed to, this interface.  IPv4 routers forward
>            datagrams.  IPv4 hosts do not (except those source-routed
>            via the host)";
> [Alia] Perfect=20
>=20

This description then might also mention that this leaf has specific =
implications for the =93ietf-routing=94 module, see sec. 6.2 in =
draft-ietf-netmod-routing-cfg-13.

Lada

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





From mbj@tail-f.com  Fri Jan 31 08:40:47 2014
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 848911A0367; Fri, 31 Jan 2014 08:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 TayvOFvDebmU; Fri, 31 Jan 2014 08:40:46 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 06E401A035D; Fri, 31 Jan 2014 08:40:46 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E3CD240C58A; Fri, 31 Jan 2014 17:40:41 +0100 (CET)
Date: Fri, 31 Jan 2014 17:40:41 +0100 (CET)
Message-Id: <20140131.174041.236982788.mbj@tail-f.com>
To: akatlas@gmail.com
From: Martin Bjorklund 
In-Reply-To: 
References:  <20140125.151847.09968453.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: rtg-dir@ietf.org, draft-ietf-netmod-ip-cfg@tools.ietf.org, netmod@ietf.org, rtg-ads@tools.ietf.org
Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-ip-cfg-12
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, 31 Jan 2014 16:40:47 -0000

Alia Atlas  wrote:
> Responses in-line.
> 
> 
> On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > Alia Atlas  wrote:

[...]

> > >    2. ipv4/enabled and ipv6/enabled:  Similarly, what is enabled by
> > >    ipv4/enabled isn't clear (unless I look at RFC 4293).   Could you
> > clarify
> > >    that it means connected to an IPv4 stack for sending out IPv4 packets
> > and
> > >    for receiving to-me packets and do the same clarification for
> > ipv6/enabled?
> >
> > Would this work?
> >
> > OLD:
> >
> >           "Controls if IPv6 is enabled or disabled on this
> >            interface.";
> >
> > NEW:
> >
> >           "Controls if IPv6 is enabled or disabled on this
> >            interface.  When IPv6 is enabled, this interface is
> >            connected to an IPv6 stack, and the interface can send
> >            and receive IPv6 packets.";
> >
> [Alia] Sounds great - same for IPv4?

Yes.

> > >    1.  ipv6/forwarding:   why is the reference RFC 4861 - neighbor
> > >    discovery???  That seems like it applies to the neighbor info, unless
> > I've
> > >    misunderstood what ipv6/forwarding is doing...
> >
> > Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the
> > interface, not to the neighbor.  This object is defined as:
> >
> >                      A flag indicating whether routing is enabled on
> >                      this interface.  Enabling routing on the interface
> >                      would imply that a router can forward packets to or
> >                      from the interface.
> >
> > (The neighbor cache also tags each neighbor as being a router or not).
> >
> [Alia] Ok - but a reference to the RFC for neighbor discovery is really not
> clear when all you are talking about is whether the interface routes
> packets or not.  PLEASE either add a more specific reference to the section
> or otherwise clarify.  I do think that the text changes we discussed above
> will help also.

The current reference is:

    container ipv6 {
      ...
      leaf forwarding {
        ...
        reference
          "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
                     Section 6.2.1, IsRouter";
      }
    }

I hope this is specific enough?



/martin

From mbj@tail-f.com  Fri Jan 31 08:45:42 2014
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 237011A0442 for ; Fri, 31 Jan 2014 08:45:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 Orw5WYJ9pTDP for ; Fri, 31 Jan 2014 08:45:39 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E2ACA1A035D for ; Fri, 31 Jan 2014 08:45:38 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 627E3240C5A5; Fri, 31 Jan 2014 17:45:33 +0100 (CET)
Date: Fri, 31 Jan 2014 17:45:32 +0100 (CET)
Message-Id: <20140131.174532.535193369.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>  <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@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=utf-8
Content-Transfer-Encoding: base64
Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 31 Jan 2014 16:45:42 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDMxIEphbiAy
MDE0LCBhdCAxNjowMiwgVGhvbWFzIE5hZGVhdSA8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+IHdy
b3RlOg0KPiANCj4gPiANCj4gPiAJSSB3b3VsZCBsaWtlIHRvIGNhbGwgY29uc2Vuc3VzIG9uIHRo
aXMgbWF0dGVyLiBJJ3ZlIHJlY2VpdmVkICUxMDANCj4gPiAJc3VwcG9ydGluZyBjb21tZW50cyBm
b3IgdGhlIHByb3Bvc2FsIGZyb20gdGhlIFdHIHdpdGggbm8gb25lIG5vdCBsaWtpbmcNCj4gPiAJ
dGhlIHByb3Bvc2FsLiBUaGUgb25seSBjb21tZW50cyByZWNlaXZlZCB3ZXJlIGZyb20gTWFydGlu
IGFuZA0KPiANCj4gWW91IG11c3QgaGF2ZSBtaXNzZWQgbXkgY29tbWVudHMsIHNvIGxldCBtZSBz
YXkgSSBkb27igJl0IGxpa2UgdGhlIHByb3Bvc2FsLiBJDQo+IHRoaW5rIHdlIGFyZSB0aHJvd2lu
ZyBvdXQgdGhlIGJhYnkgd2l0aCB0aGUgYmF0aCB3YXRlci4NCg0KSSB0aGluayB5b3UgZG8gaGF2
ZSBhIHZhbGlkIHBvaW50LiAgSXQgaXMgcHJvYmFibHkgYmUgYmV0dGVyIHRvIGhhdmUNCm9uZSBm
aXhlZCB2ZXJzaW9uIG9mIHRoZSBlbnVtZXJhdGlvbiBzdGFuZGFyZGl6ZWQuICBCdXQgdGhlIHBy
b2JsZW0gaXMNCmhvdyB0aGlzIG1vZHVsZSB3b3VsZCBiZSBtYWludGFpbmVkLiAgQXBwYXJlbnRs
eSB0aGUgZGF0YWJhc2UgY2hhbmdlcw0KdG9vIG9mdGVuIGZvciBiZWluZyBtYWludGFpbmVkIGlu
IFJGQ3MuICBBbmQgdGhlcmUgYWxzbyBzZWVtcyB0byBiZQ0KYSBwb2xpdGljYWwgZGltZW5zaW9u
IHRvIGl0IHRoYXQgSSBkb24ndCB0aGluayB3ZSBhcmUgcHJlcGFyZWQgdG8NCmhhbmRsZS4gIEFu
ZCBpZiB3ZSBzaW1wbHkgcHVibGlzaCBhbiBSRkMgd2l0aCB0aGUgY3VycmVudCB2ZXJzaW9uIG9m
DQp0aGUgbmFtZXMgZnJvbSB0aGUgZGF0YWJhc2UsIHdoYXQgZG9lcyBpdCBtZWFuIHRoYXQgdGhl
DQpJQU5BLW1haW50YWluZWQgZGIgZGlmZmVycz8NCg0KDQovbWFydGluDQoNCg0KDQo+IA0KPiBM
YWRhDQo+IA0KPiA+ICBCZW5vaXQgd2l0aCByZWdhcmQgdG8gZW5oYW5jaW5nIHRoZSBkZXNjcmlw
dGlvbiBhcm91bmQgdGhlIHRpbWV6b25lLW5hbWUNCj4gPiAgdHlwZWRlZi4gIERvY3VtZW50IGVk
aXRvcnMsIHBsZWFzZSB0YWtlIHRob3NlIHR3byBjb21tZW50cyBpbnRvIGFjY291bnQgYW5kDQo+
ID4gIG1ha2UgdGhlIGNoYW5nZXMgbmVjZXNzYXJ5LiBZb3UgbWlnaHQgd2FudCB0byBwcm9wb3Nl
IHRoZSB0ZXh0IG9uIHRoZSBsaXN0DQo+ID4gIGJlZm9yZSBwdWJsaXNoaW5nIGFzIGl0IHNob3Vs
ZCBiZSBhIGZhaXJseSBtaW5vciBjaGFuZ2UsIGJ1dCBqdXN0IHRvIG1ha2UNCj4gPiAgc3VyZSBp
dCBjb3ZlcnMgdGhlIGNvbW1lbnRzIHJlY2VpdmVkLg0KPiA+IA0KPiA+IAktLVRvbQ0KPiA+IA0K
PiA+IA0KPiA+PiANCj4gPj4gCU5ldG1vZCBXRzoNCj4gPj4gDQo+ID4+IAlUaGUgd29ya2luZyBn
cm91cCBjaGFpcnMgaGF2ZSBjb25zaWRlcmVkIHRoZSBkaXNjdXNzaW9uIGNvbmNlcm5pbmcgDQo+
ID4+IHRoZSB0aW1lem9uZS1sb2NhdGlvbiBsZWFmIGluIGRyYWZ0LWlldGYtbmV0bW9kLXN5c3Rl
bS1tZ210LTEwIGFuZA0KPiA+PiBkcmFmdC1pZXRmLW5ldG1vZC1pYW5hLXRpbWV6b25lcy0wMy4g
SW4gcGFydGljdWxhciwgd2Ugd291bGQgbGlrZQ0KPiA+PiBsaWtlIHRvIGNhbGwgY29uc2Vuc3Vz
IG9uIHRoZSBtYXR0ZXIgcmVnYXJkaW5nIHRoYXQgc3VyZmFjZWQgZHVyaW5nDQo+ID4+IHRoZSBJ
RVRGIGxhc3QgY2FsbCB3aXRoIHJlZ2FyZCB0byB0aGUgdGhlIHByYWN0aWNhYmlsaXR5IG9mIG1h
aW50YWluaW5nIGEgDQo+ID4+IFlBTkcgbW9kdWxlIHdpdGggYW4gZW51bWVyYXRpb24gb2YgdGlt
ZXpvbmUgbmFtZXMuIFdlIGJlbGlldmUgdGhlcmUgaXMNCj4gPj4gY29uc2Vuc3VzIGluIHRoZSB3
b3JraW5nIGdyb3VwIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHRoZSBmb2xsb3dpbmcgDQo+ID4+IHJl
c29sdXRpb246DQo+ID4+IA0KPiA+PiAtIFRoZSBZQU5HIG1vZHVsZSBpbiBkcmFmdC1pZXRmLW5l
dG1vZC1zeXN0ZW0tbWdtdC0xMSBnZXRzDQo+ID4+IGV4dGVuZGVkIHRvIGludHJvZHVjZSBhIG5l
dyB0eXBlZGVmIGZvciB0aW1lem9uZSBuYW1lcywgZS5nLg0KPiA+PiBzb21ldGhpbmcgdGhhdCBs
b29rcyBsaWtlOg0KPiA+PiANCj4gPj4gdHlwZWRlZiB0aW1lem9uZS1uYW1lIHsNCj4gPj4gICB0
eXBlIHN0cmluZzsNCj4gPj4gICBkZXNjcmlwdGlvbg0KPiA+PiAgICAiQSB0aW1lem9uZSBuYW1l
IGFzIHVzZWQgYnkgdGhlIFRpbWUgWm9uZSBEYXRhYmFzZSwgc29tZXRpbWVzDQo+ID4+ICAgICBy
ZWZlcnJlZCB0byBhcyB0aGUgJ09sc29uIERhdGFiYXNlJy4iOw0KPiA+PiAgIHJlZmVyZW5jZQ0K
PiA+PiAgICAiUkZDIDY1NTc6IFByb2NlZHVyZXMgZm9yIE1haW50YWluaW5nIHRoZSBUaW1lIFpv
bmUgRGF0YWJhc2UiOw0KPiA+PiB9DQo+ID4+IA0KPiA+PiBUaGUgdGltZXpvbmUtbG9jYXRpb24g
bGVhZiB3aWxsIGJlIGNoYW5nZWQgdG8gdXNlIHRoaXMgdHlwZSwNCj4gPj4gdGhlIGltcG9ydCBv
ZiBpYW5hLXRpbWV6b25lcyB3aWxsIGJlIHJlbW92ZWQgYW5kIHRoZSByZWZlcmVuY2VzDQo+ID4+
IHRvIEktRC5pZXRmLW5ldG1vZC1pYW5hLXRpbWV6b25lcyB3aWxsIGJlIHJlbW92ZWQuDQo+ID4+
IA0KPiA+PiAtIFRoZSBkcmFmdC1pZXRmLW5ldG1vZC1pYW5hLXRpbWV6b25lcy0wMCBkb2N1bWVu
dCB3aWxsIGJlIHB1bGxlZA0KPiA+PiBiYWNrIGFuZCB3b3JrIG9uIHRoaXMgZHJhZnQgd2lsbCBz
dG9wLiAgVGhlIEktRCBpcyBkZWNsYXJlZCBkZWFkLg0KPiA+PiANCj4gPj4gLSBTaW5jZSB0aGVy
ZSBpcyBub3RoaW5nIHRvIGRvIGZvciBJQU5BLCB0aGVyZSB3aWxsIGJlIG5vIElBTkEgcmVxdWVz
dCANCj4gPj4gbmVlZGVkIGluIHRoaXMgcmVnYXJkIGZvciBkcmFmdC1pZXRmLW5ldG1vZC1zeXN0
ZW0tbWdtdC0xMS4gDQo+ID4+IA0KPiA+PiAJV2Ugbm90ZSB0aGF0IGZ1cnRoZXIgYWx0ZXJuYXRp
dmVzIGNhbiBiZSBhZGRlZCB0byB0aGUgdGltZXpvbmUNCj4gPj4gY2hvaWNlIGluIHRoZSBmdXR1
cmUgc2hvdWxkIHRoZSB0d28gbWVjaGFuaXNtcyBjdXJyZW50bHkgaW4gcGxhY2UNCj4gPj4gdHVy
biBvdXQgdG8gYmUgaW5zdWZmaWNpZW50IGluIHByYWN0aWNlLg0KPiA+PiANCj4gPj4gCVdlIHdv
dWxkIGxpa2UgdG8gZ2l2ZSB0aGUgV0cgc3VmZmljaWVudCB0aW1lIHRvIHJhaXNlIGFueSBhZGRp
dGlvbmFsDQo+ID4+IAljb25jZXJucyBvcg0KPiA+PiBpc3N1ZXMgd2l0aCByZWdhcmQgdG8gdGhp
cyBpc3N1ZSBhbmQgb3VyIHBhdGggZm9yIHJlc29sdmluZyB0aGUgaXNzdWUgYXQNCj4gPj4gaGFu
ZCwgYW5kIHNvIHdlDQo+ID4+IHdpbGwgYWNjZXB0IGNvbW1lbnRzL2Rpc2N1c3Npb24gb24gdGhp
cyBtYXR0ZXIgdW50aWwgOEFNIEVEVCBvbiBUdWVzZGF5LA0KPiA+PiBKYW51YXJ5IDI4LCAyMDE0
Lg0KPiA+PiBBcyBKdWVyZ2VuIGhhcyBiZWVuIGNsb3NlbHkgaW52b2x2ZWQgd2l0aCB0aGUgbWF0
dGVyLCBJIHdpbGwgYWRqdWRpY2F0ZSBhbnkNCj4gPj4gaXNzdWVzDQo+ID4+IGFyaXNpbmcgZnJv
bSB0aGlzIGNvbW1lbnQgcGVyaW9kLg0KPiA+PiANCj4gPj4gCVRoYW5rcywNCj4gPj4gDQo+ID4+
IAlUb20NCj4gPj4gDQo+ID4+IA0KPiA+PiANCj4gPj4gDQo+ID4gDQo+ID4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBs
aXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9uZXRtb2QNCj4gDQo+IC0tDQo+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExh
YnMNCj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxp
c3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbmV0bW9kDQo+IA0K

From akatlas@gmail.com  Fri Jan 31 08:50:13 2014
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 E93F01A0420; Fri, 31 Jan 2014 08:50:13 -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 RrwsvhLSte1c; Fri, 31 Jan 2014 08:50:12 -0800 (PST)
Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF1C1A03F5; Fri, 31 Jan 2014 08:50:12 -0800 (PST)
Received: by mail-yk0-f171.google.com with SMTP id 142so24737086ykq.2 for ; Fri, 31 Jan 2014 08:50:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QAJzVOuwbqOGHYll+roXr48EBka2EY9kztnxTXyAreE=; b=SWqsbUiApm5vUi9zoQ4HgDXwjts5Wx+vF/bSA+Qjllg2O0gZ8tSOyho7Owr0VspeJJ lKXo/lm18e7D04Kq6+64gjk5HMB2C30Yr8SB/BhzS3aAHCwpc4JkXzNL8YMeAeH+yMTk z9MhYHWH8R4yDPrVDYC9kTCQKz0nOI7rmgMT0ezX95Sra+dC5ghtnZhpVwnl/RbESHTU LW+OPKbabitWk+P/YfSASNExuE+9Ljt3IxL5I5BBFboc/LGfI7YCzcexKV29qZFOAJPH gKBiDvMV6iBxRQrMNMBr7WFEusEzlj9XgjxfosZTQ4szKsrMx+hyvq9sUZ8/mDcMZG0R MBCQ==
MIME-Version: 1.0
X-Received: by 10.236.88.75 with SMTP id z51mr1842163yhe.109.1391187008276; Fri, 31 Jan 2014 08:50:08 -0800 (PST)
Received: by 10.170.186.88 with HTTP; Fri, 31 Jan 2014 08:50:08 -0800 (PST)
In-Reply-To: <20140131.174041.236982788.mbj@tail-f.com>
References:  <20140125.151847.09968453.mbj@tail-f.com>  <20140131.174041.236982788.mbj@tail-f.com>
Date: Fri, 31 Jan 2014 11:50:08 -0500
Message-ID: 
From: Alia Atlas 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=bcaec544ed6871ce6104f146f7c7
Cc: "rtg-dir@ietf.org" , draft-ietf-netmod-ip-cfg@tools.ietf.org, "netmod@ietf.org" , "rtg-ads@tools.ietf.org" 
Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-ip-cfg-12
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, 31 Jan 2014 16:50:14 -0000

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

On Fri, Jan 31, 2014 at 11:40 AM, Martin Bjorklund  wrote:

> Alia Atlas  wrote:
> > Responses in-line.
> >
> >
> > On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund 
> wrote:
> >
> > > Hi,
> > >
> > > Alia Atlas  wrote:
>
> [...]
>
> > > >    2. ipv4/enabled and ipv6/enabled:  Similarly, what is enabled by
> > > >    ipv4/enabled isn't clear (unless I look at RFC 4293).   Could you
> > > clarify
> > > >    that it means connected to an IPv4 stack for sending out IPv4
> packets
> > > and
> > > >    for receiving to-me packets and do the same clarification for
> > > ipv6/enabled?
> > >
> > > Would this work?
> > >
> > > OLD:
> > >
> > >           "Controls if IPv6 is enabled or disabled on this
> > >            interface.";
> > >
> > > NEW:
> > >
> > >           "Controls if IPv6 is enabled or disabled on this
> > >            interface.  When IPv6 is enabled, this interface is
> > >            connected to an IPv6 stack, and the interface can send
> > >            and receive IPv6 packets.";
> > >
> > [Alia] Sounds great - same for IPv4?
>
> Yes.
>
> > > >    1.  ipv6/forwarding:   why is the reference RFC 4861 - neighbor
> > > >    discovery???  That seems like it applies to the neighbor info,
> unless
> > > I've
> > > >    misunderstood what ipv6/forwarding is doing...
> > >
> > > Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the
> > > interface, not to the neighbor.  This object is defined as:
> > >
> > >                      A flag indicating whether routing is enabled on
> > >                      this interface.  Enabling routing on the interface
> > >                      would imply that a router can forward packets to
> or
> > >                      from the interface.
> > >
> > > (The neighbor cache also tags each neighbor as being a router or not).
> > >
> > [Alia] Ok - but a reference to the RFC for neighbor discovery is really
> not
> > clear when all you are talking about is whether the interface routes
> > packets or not.  PLEASE either add a more specific reference to the
> section
> > or otherwise clarify.  I do think that the text changes we discussed
> above
> > will help also.
>
> The current reference is:
>
>     container ipv6 {
>       ...
>       leaf forwarding {
>         ...
>         reference
>           "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
>                      Section 6.2.1, IsRouter";
>       }
>     }
>
> I hope this is specific enough?
>
[Alia] Yes - sorry - should have double-checked the draft again..

Alia


>
>
>
> /martin
>

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


On F=
ri, Jan 31, 2014 at 11:40 AM, Martin Bjorklund <mbj@tail-f.com>=
 wrote:


Alia Atlas <akatlas@gmail.com> wrote:

> Responses in-line.

>

>

> On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

>

> > Hi,

> >

> > Alia Atlas <akatlas@gmail=
.com> wrote:




[...]




> > > =A0 =A02. ipv4/enabled and ipv6/enabled: =A0Similarly, what =
is enabled by

> > > =A0 =A0ipv4/enabled isn't clear (unless I look at RFC 42=
93). =A0 Could you

> > clarify

> > > =A0 =A0that it means connected to an IPv4 stack for sending =
out IPv4 packets

> > and

> > > =A0 =A0for receiving to-me packets and do the same clarifica=
tion for

> > ipv6/enabled?

> >

> > Would this work?

> >

> > OLD:

> >

> > =A0 =A0 =A0 =A0 =A0 "Controls if IPv6 is enabled or disabled=
 on this

> > =A0 =A0 =A0 =A0 =A0 =A0interface.";

> >

> > NEW:

> >

> > =A0 =A0 =A0 =A0 =A0 "Controls if IPv6 is enabled or disabled=
 on this

> > =A0 =A0 =A0 =A0 =A0 =A0interface. =A0When IPv6 is enabled, this i=
nterface is

> > =A0 =A0 =A0 =A0 =A0 =A0connected to an IPv6 stack, and the interf=
ace can send

> > =A0 =A0 =A0 =A0 =A0 =A0and receive IPv6 packets.";

> >

> [Alia] Sounds great - same for IPv4?




Yes.




> > > =A0 =A01. =A0ipv6/forwarding: =A0 why is the reference RFC 4=
861 - neighbor

> > > =A0 =A0discovery??? =A0That seems like it applies to the nei=
ghbor info, unless

> > I've


> > > =A0 =A0misunderstood what ipv6/forwarding is doing...<=
br>

> >

> > Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the=


> > interface, not to the neighbor. =A0This object is defined as:

> >

> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A flag indicating whet=
her routing is enabled on

> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this interface. =A0Ena=
bling routing on the interface

> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0would imply that a rou=
ter can forward packets to or

> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0from the interface.
> >

> > (The neighbor cache also tags each neighbor as being a router or =
not).

> >

> [Alia] Ok - but a reference to the RFC for neighbor discovery is reall=
y not

> clear when all you are talking about is whether the interface routes
> packets or not. =A0PLEASE either add a more specific reference to the =
section

> or otherwise clarify. =A0I do think that the text changes we discussed=
 above

> will help also.




The current reference is:



=A0 =A0 container ipv6 {

=A0 =A0 =A0 ...

=A0 =A0 =A0 leaf forwarding {

=A0 =A0 =A0 =A0 ...

=A0 =A0 =A0 =A0 reference

=A0 =A0 =A0 =A0 =A0 "RFC 4861: Neighbor Discovery for IP version 6 (IP=
v6)

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Section 6.2.1, IsRouter";
=A0 =A0 =A0 }

=A0 =A0 }



I hope this is specific enough?
[Alia] Yes - sorry - s=
hould have double-checked the draft again..

Alia
=A0








/martin





--bcaec544ed6871ce6104f146f7c7--

From lhotka@nic.cz  Fri Jan 31 08:54:46 2014
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 6086D1A0522; Fri, 31 Jan 2014 08:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level: 
X-Spam-Status: No, score=-0.886 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.535] 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 H8qRbUvjt7cF; Fri, 31 Jan 2014 08:54:44 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 36CE71A0448; Fri, 31 Jan 2014 08:54:44 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C6E8013FACA; Fri, 31 Jan 2014 17:54:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391187280; bh=6KxLND7Q2TCqn9+EInPNTz9h0rK9B4EQw0u2qdKTtUI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=s6xTylYW8eMHUfYQAc4hmXA3/4r+FEXY2KhJwdcqf9S7Gcjy67TEAmF6QQrDQcO6i z0uRoDuwGaqtoPro/IRxARoThS6c/tJ6hMoyrfsv7TZZfYkezkptNMjiq41LL944hU z650BOopTFEnVj2ZU5NWbMGchS/wb33sTTJsZ/3M=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140131.174041.236982788.mbj@tail-f.com>
Date: Fri, 31 Jan 2014 17:54:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BD3F9E8-2BB5-42F4-8F64-41EDDB7FFC32@nic.cz>
References:  <20140125.151847.09968453.mbj@tail-f.com>  <20140131.174041.236982788.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: rtg-dir@ietf.org, draft-ietf-netmod-ip-cfg@tools.ietf.org, rtg-ads@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] RtgDir review: draft-ietf-netmod-ip-cfg-12
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, 31 Jan 2014 16:54:46 -0000

On 31 Jan 2014, at 17:40, Martin Bjorklund  wrote:

> Alia Atlas  wrote:
>> Responses in-line.
>>=20
>>=20
>> On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund  =
wrote:
>>=20
>>> Hi,
>>>=20
>>> Alia Atlas  wrote:
>=20
> [...]
>=20
>>>>   2. ipv4/enabled and ipv6/enabled:  Similarly, what is enabled by
>>>>   ipv4/enabled isn't clear (unless I look at RFC 4293).   Could you
>>> clarify
>>>>   that it means connected to an IPv4 stack for sending out IPv4 =
packets
>>> and
>>>>   for receiving to-me packets and do the same clarification for
>>> ipv6/enabled?
>>>=20
>>> Would this work?
>>>=20
>>> OLD:
>>>=20
>>>          "Controls if IPv6 is enabled or disabled on this
>>>           interface.";
>>>=20
>>> NEW:
>>>=20
>>>          "Controls if IPv6 is enabled or disabled on this
>>>           interface.  When IPv6 is enabled, this interface is
>>>           connected to an IPv6 stack, and the interface can send
>>>           and receive IPv6 packets.";
>>>=20
>> [Alia] Sounds great - same for IPv4?
>=20
> Yes.
>=20
>>>>   1.  ipv6/forwarding:   why is the reference RFC 4861 - neighbor
>>>>   discovery???  That seems like it applies to the neighbor info, =
unless
>>> I've
>>>>   misunderstood what ipv6/forwarding is doing...
>>>=20
>>> Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the
>>> interface, not to the neighbor.  This object is defined as:
>>>=20
>>>                     A flag indicating whether routing is enabled on
>>>                     this interface.  Enabling routing on the =
interface
>>>                     would imply that a router can forward packets to =
or
>>>                     from the interface.
>>>=20
>>> (The neighbor cache also tags each neighbor as being a router or =
not).
>>>=20
>> [Alia] Ok - but a reference to the RFC for neighbor discovery is =
really not
>> clear when all you are talking about is whether the interface routes
>> packets or not.  PLEASE either add a more specific reference to the =
section
>> or otherwise clarify.  I do think that the text changes we discussed =
above
>> will help also.
>=20
> The current reference is:
>=20
>    container ipv6 {
>      ...
>      leaf forwarding {
>        ...
>        reference
>          "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)
>                     Section 6.2.1, IsRouter";
>      }
>    }
>=20
> I hope this is specific enough?

I think it is. The other router configuration parameters that are =
specified in that 4861 section are dealt with in the =
=93ietf-ipv6-unicast-routing=94 module - perhaps it would be useful to =
mention this in the description, too.

Lada

>=20
>=20
>=20
> /martin
> _______________________________________________
> 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  Fri Jan 31 08:55:21 2014
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 2A3551A0448 for ; Fri, 31 Jan 2014 08:55:21 -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 DvVnd9rNu233 for ; Fri, 31 Jan 2014 08:55:16 -0800 (PST)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id A3CE71A0416 for ; Fri, 31 Jan 2014 08:55:16 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id f11so6537462qae.38 for ; Fri, 31 Jan 2014 08:55:12 -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=fbB6kI+ok9FRmbu1sQw7edyC2JmV7PUnqWVD5KSdmNY=; b=OUZO9LnL5efKJEEYZnynsk6fkvq7cDSGx+9RjI2g69T0LNYysCfxcfavO+kKRpTCP9 Nk11ESgwjiR9H5aW67aq0r4katWJ8SN+VP30z0uea0CkJ5GoG+RtA0IRjCA+p1pQ/zhb MoZ4yeNzFB4m3jTloRM8g9MM0yoGzhlYowILXq+EqXu057ds6OBUTJNhaOY4vhZTHYAL M/6Dmvu32PCXB593nskJVJWqUjzxCX07dl2cqSTsOp0VATXvEXarB2yebTnw3SZ0aakJ onnXPzN3h00gjyQJxK2Bl22E7QKBgj299GlkGuUxW95UhKPxUii/XG5cD4LHHPLzvPYI OVyg==
X-Gm-Message-State: ALoCoQnvJoVg3TAHP4TcdnmYJfO0BnB66/WRGl3PKJdqTSrCM7OAnWnZ2g5P11pTbauyPnIMYHPE
MIME-Version: 1.0
X-Received: by 10.224.46.130 with SMTP id j2mr33228433qaf.7.1391187311798; Fri, 31 Jan 2014 08:55:11 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Fri, 31 Jan 2014 08:55:11 -0800 (PST)
In-Reply-To: <20140131.174532.535193369.mbj@tail-f.com>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>  <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.mbj@tail-f.com>
Date: Fri, 31 Jan 2014 08:55:11 -0800
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a11c2a9ca893f2104f1470988
Cc: netmod-chairs@tools.ietf.org, "netmod@ietf.org" 
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 31 Jan 2014 16:55:21 -0000

--001a11c2a9ca893f2104f1470988
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 31, 2014 at 8:45 AM, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
> >
> > On 31 Jan 2014, at 16:02, Thomas Nadeau  wrote:
> >
> > >
> > >     I would like to call consensus on this matter. I've received %100
> > >     supporting comments for the proposal from the WG with no one not
> liking
> > >     the proposal. The only comments received were from Martin and
> >
> > You must have missed my comments, so let me say I don't like the
> proposal. I
> > think we are throwing out the baby with the bath water.
>
> I think you do have a valid point.  It is probably be better to have
> one fixed version of the enumeration standardized.  But the problem is
> how this module would be maintained.  Apparently the database changes
> too often for being maintained in RFCs.  And there also seems to be
> a political dimension to it that I don't think we are prepared to
> handle.  And if we simply publish an RFC with the current version of
> the names from the database, what does it mean that the
> IANA-maintained db differs?
>
>
The YANG enumeration is supposed to reflect the TZ database
and IANA is the naming authority for that database.  This YANG
module cannot be the authoritative source of TZ names.
A "snapshot" removes IANA as the naming authority,
and that was never the intent.



> /martin
>


Andy


>
>
>
> >
> > Lada
> >
> > >  Benoit with regard to enhancing the description around the
> timezone-name
> > >  typedef.  Document editors, please take those two comments into
> account and
> > >  make the changes necessary. You might want to propose the text on the
> list
> > >  before publishing as it should be a fairly minor change, but just to
> make
> > >  sure it covers the comments received.
> > >
> > >     --Tom
> > >
> > >
> > >>
> > >>    Netmod WG:
> > >>
> > >>    The working group chairs have considered the discussion concerning
> > >> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
> > >> draft-ietf-netmod-iana-timezones-03. In particular, we would like
> > >> like to call consensus on the matter regarding that surfaced during
> > >> the IETF last call with regard to the the practicability of
> maintaining a
> > >> YANG module with an enumeration of timezone names. We believe there is
> > >> consensus in the working group to move forward with the following
> > >> resolution:
> > >>
> > >> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets
> > >> extended to introduce a new typedef for timezone names, e.g.
> > >> something that looks like:
> > >>
> > >> typedef timezone-name {
> > >>   type string;
> > >>   description
> > >>    "A timezone name as used by the Time Zone Database, sometimes
> > >>     referred to as the 'Olson Database'.";
> > >>   reference
> > >>    "RFC 6557: Procedures for Maintaining the Time Zone Database";
> > >> }
> > >>
> > >> The timezone-location leaf will be changed to use this type,
> > >> the import of iana-timezones will be removed and the references
> > >> to I-D.ietf-netmod-iana-timezones will be removed.
> > >>
> > >> - The draft-ietf-netmod-iana-timezones-00 document will be pulled
> > >> back and work on this draft will stop.  The I-D is declared dead.
> > >>
> > >> - Since there is nothing to do for IANA, there will be no IANA request
> > >> needed in this regard for draft-ietf-netmod-system-mgmt-11.
> > >>
> > >>    We note that further alternatives can be added to the timezone
> > >> choice in the future should the two mechanisms currently in place
> > >> turn out to be insufficient in practice.
> > >>
> > >>    We would like to give the WG sufficient time to raise any
> additional
> > >>    concerns or
> > >> issues with regard to this issue and our path for resolving the issue
> at
> > >> hand, and so we
> > >> will accept comments/discussion on this matter until 8AM EDT on
> Tuesday,
> > >> January 28, 2014.
> > >> As Juergen has been closely involved with the matter, I will
> adjudicate any
> > >> issues
> > >> arising from this comment period.
> > >>
> > >>    Thanks,
> > >>
> > >>    Tom
> > >>
> > >>
> > >>
> > >>
> > >
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--001a11c2a9ca893f2104f1470988
Content-Type: text/html; charset=ISO-8859-1





On Fri, Jan 31, 2014 at 8:45 AM, Martin Bjorklund <mbj@tail-f.com> wrote:


Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> On 31 Jan 2014, at 16:02, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

>

> >

> >     I would like to call consensus on this matter. I've received %100

> >     supporting comments for the proposal from the WG with no one not liking

> >     the proposal. The only comments received were from Martin and

>

> You must have missed my comments, so let me say I don’t like the proposal. I

> think we are throwing out the baby with the bath water.



I think you do have a valid point.  It is probably be better to have

one fixed version of the enumeration standardized.  But the problem is

how this module would be maintained.  Apparently the database changes

too often for being maintained in RFCs.  And there also seems to be

a political dimension to it that I don't think we are prepared to

handle.  And if we simply publish an RFC with the current version of

the names from the database, what does it mean that the

IANA-maintained db differs?



The YANG enumeration is supposed to reflect the TZ database
and IANA is the naming authority for that database.  This YANG
module cannot be the authoritative source of TZ names.


A "snapshot" removes IANA as the naming authority,
and that was never the intent.






/martin


Andy
 







>

> Lada

>

> >  Benoit with regard to enhancing the description around the timezone-name

> >  typedef.  Document editors, please take those two comments into account and

> >  make the changes necessary. You might want to propose the text on the list

> >  before publishing as it should be a fairly minor change, but just to make

> >  sure it covers the comments received.

> >

> >     --Tom

> >

> >

> >>

> >>    Netmod WG:

> >>

> >>    The working group chairs have considered the discussion concerning

> >> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and

> >> draft-ietf-netmod-iana-timezones-03. In particular, we would like

> >> like to call consensus on the matter regarding that surfaced during

> >> the IETF last call with regard to the the practicability of maintaining a

> >> YANG module with an enumeration of timezone names. We believe there is

> >> consensus in the working group to move forward with the following

> >> resolution:

> >>

> >> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets

> >> extended to introduce a new typedef for timezone names, e.g.

> >> something that looks like:

> >>

> >> typedef timezone-name {

> >>   type string;

> >>   description

> >>    "A timezone name as used by the Time Zone Database, sometimes

> >>     referred to as the 'Olson Database'.";

> >>   reference

> >>    "RFC 6557: Procedures for Maintaining the Time Zone Database";

> >> }

> >>

> >> The timezone-location leaf will be changed to use this type,

> >> the import of iana-timezones will be removed and the references

> >> to I-D.ietf-netmod-iana-timezones will be removed.

> >>

> >> - The draft-ietf-netmod-iana-timezones-00 document will be pulled

> >> back and work on this draft will stop.  The I-D is declared dead.

> >>

> >> - Since there is nothing to do for IANA, there will be no IANA request

> >> needed in this regard for draft-ietf-netmod-system-mgmt-11.

> >>

> >>    We note that further alternatives can be added to the timezone

> >> choice in the future should the two mechanisms currently in place

> >> turn out to be insufficient in practice.

> >>

> >>    We would like to give the WG sufficient time to raise any additional

> >>    concerns or

> >> issues with regard to this issue and our path for resolving the issue at

> >> hand, and so we

> >> will accept comments/discussion on this matter until 8AM EDT on Tuesday,

> >> January 28, 2014.

> >> As Juergen has been closely involved with the matter, I will adjudicate any

> >> issues

> >> arising from this comment period.

> >>

> >>    Thanks,

> >>

> >>    Tom

> >>

> >>

> >>

> >>

> >

> > _______________________________________________

> > 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

>

_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod





--001a11c2a9ca893f2104f1470988--

From lhotka@nic.cz  Fri Jan 31 09:18:52 2014
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 7A88C1A0420 for ; Fri, 31 Jan 2014 09:18:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level: 
X-Spam-Status: No, score=-0.886 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.535] 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 6trHDQCSWn2i for ; Fri, 31 Jan 2014 09:18: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 EFA6E1A0416 for ; Fri, 31 Jan 2014 09:18:46 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 742B4140AB2; Fri, 31 Jan 2014 18:18:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391188722; bh=/n1kMTdXlmNcOzJk3TIHRRbDPa9uc8veshRYaZlSrhU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Z7UZVTSB+re8To/CCzygZKJsGOOJBdzIRF7Uvy/bxxTBtcYgLENDHQspyxd0nBwJJ vBFW2D+yx2mG3SDkNwQaNWa/B+PHuAPw/VaOWEYhX9Org6HzK+XH2dPiGl9IpaEccX SFoOgme/77tCKoh4fazmi9w/sXHiSKcsK9nFqItA=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ladislav Lhotka 
In-Reply-To: <20140131.174532.535193369.mbj@tail-f.com>
Date: Fri, 31 Jan 2014 18:18:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C75D1D5-249F-4E8A-BC45-F1152CFE2BF3@nic.cz>
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>  <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.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-chairs@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 31 Jan 2014 17:18:52 -0000

On 31 Jan 2014, at 17:45, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>>=20
>> On 31 Jan 2014, at 16:02, Thomas Nadeau  =
wrote:
>>=20
>>>=20
>>> 	I would like to call consensus on this matter. I've received =
%100
>>> 	supporting comments for the proposal from the WG with no one not =
liking
>>> 	the proposal. The only comments received were from Martin and
>>=20
>> You must have missed my comments, so let me say I don=92t like the =
proposal. I
>> think we are throwing out the baby with the bath water.
>=20
> I think you do have a valid point.  It is probably be better to have
> one fixed version of the enumeration standardized.  But the problem is
> how this module would be maintained.  Apparently the database changes
> too often for being maintained in RFCs.  And there also seems to be
> a political dimension to it that I don't think we are prepared to
> handle.  And if we simply publish an RFC with the current version of
> the names from the database, what does it mean that the
> IANA-maintained db differs?

Paul Eggert suggested in his messages from 16 January that the political =
issues can be avoided by not claiming that the YANG enumeration is =
authoritative/canonical or that it always mirrors the current Olson =
database names.

I was trying to figure out what typical changes have been applied to the =
database recently but I don=92t know how to get this information. I =
reckon a typical scenario might be that a new timezone is added, say =
"Pacific/Bora-Bora=94. Until the YANG module gets updated, all NETCONF =
servers on Bora Bora will not allow this setting but the clients can =
continue to use =93Pacific/Tahiti=94 as before - mostly not a big deal =
IMO.

I am convinced that Benoit=92s proposal from

http://www.ietf.org/mail-archive/web/netmod/current/msg08983.html

is perfectly viable.

Lada

>=20
>=20
> /martin
>=20
>=20
>=20
>>=20
>> Lada
>>=20
>>> Benoit with regard to enhancing the description around the =
timezone-name
>>> typedef.  Document editors, please take those two comments into =
account and
>>> make the changes necessary. You might want to propose the text on =
the list
>>> before publishing as it should be a fairly minor change, but just to =
make
>>> sure it covers the comments received.
>>>=20
>>> 	--Tom
>>>=20
>>>=20
>>>>=20
>>>> 	Netmod WG:
>>>>=20
>>>> 	The working group chairs have considered the discussion =
concerning=20
>>>> the timezone-location leaf in draft-ietf-netmod-system-mgmt-10 and
>>>> draft-ietf-netmod-iana-timezones-03. In particular, we would like
>>>> like to call consensus on the matter regarding that surfaced during
>>>> the IETF last call with regard to the the practicability of =
maintaining a=20
>>>> YANG module with an enumeration of timezone names. We believe there =
is
>>>> consensus in the working group to move forward with the following=20=

>>>> resolution:
>>>>=20
>>>> - The YANG module in draft-ietf-netmod-system-mgmt-11 gets
>>>> extended to introduce a new typedef for timezone names, e.g.
>>>> something that looks like:
>>>>=20
>>>> typedef timezone-name {
>>>>  type string;
>>>>  description
>>>>   "A timezone name as used by the Time Zone Database, sometimes
>>>>    referred to as the 'Olson Database'.";
>>>>  reference
>>>>   "RFC 6557: Procedures for Maintaining the Time Zone Database";
>>>> }
>>>>=20
>>>> The timezone-location leaf will be changed to use this type,
>>>> the import of iana-timezones will be removed and the references
>>>> to I-D.ietf-netmod-iana-timezones will be removed.
>>>>=20
>>>> - The draft-ietf-netmod-iana-timezones-00 document will be pulled
>>>> back and work on this draft will stop.  The I-D is declared dead.
>>>>=20
>>>> - Since there is nothing to do for IANA, there will be no IANA =
request=20
>>>> needed in this regard for draft-ietf-netmod-system-mgmt-11.=20
>>>>=20
>>>> 	We note that further alternatives can be added to the timezone
>>>> choice in the future should the two mechanisms currently in place
>>>> turn out to be insufficient in practice.
>>>>=20
>>>> 	We would like to give the WG sufficient time to raise any =
additional
>>>> 	concerns or
>>>> issues with regard to this issue and our path for resolving the =
issue at
>>>> hand, and so we
>>>> will accept comments/discussion on this matter until 8AM EDT on =
Tuesday,
>>>> January 28, 2014.
>>>> As Juergen has been closely involved with the matter, I will =
adjudicate any
>>>> issues
>>>> arising from this comment period.
>>>>=20
>>>> 	Thanks,
>>>>=20
>>>> 	Tom
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20

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





From j.schoenwaelder@jacobs-university.de  Fri Jan 31 12:26:29 2014
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 2814D1A0456 for ; Fri, 31 Jan 2014 12:26:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 gaEbpmTS1WMF for ; Fri, 31 Jan 2014 12:26: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 9407F1A03CC for ; Fri, 31 Jan 2014 12:26:26 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7669920076; Fri, 31 Jan 2014 21:26:22 +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 BUkTdSdZ8M9Z; Fri, 31 Jan 2014 21:26: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 E75E420061; Fri, 31 Jan 2014 21:26:21 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id AD9C62B0383F; Fri, 31 Jan 2014 21:26:20 +0100 (CET)
Date: Fri, 31 Jan 2014 21:26:20 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20140131202620.GB31150@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, tnadeau@lucidvision.com, netmod-chairs@tools.ietf.org, netmod@ietf.org
References: <2A72C094-7CBC-474B-8413-8F60842142C8@lucidvision.com>  <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140131.174532.535193369.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 31 Jan 2014 20:26:29 -0000

On Fri, Jan 31, 2014 at 05:45:32PM +0100, Martin Bjorklund wrote:
> 
> I think you do have a valid point.  It is probably be better to have
> one fixed version of the enumeration standardized.  But the problem is
> how this module would be maintained.  Apparently the database changes
> too often for being maintained in RFCs.  And there also seems to be
> a political dimension to it that I don't think we are prepared to
> handle.  And if we simply publish an RFC with the current version of
> the names from the database, what does it mean that the
> IANA-maintained db differs?
> 

I completely fail to understand which value an RFC with an almost
immediately outdated list of TZ names has. I would then rather prefer
to code my manager to use my local list and be prepared that names can
be rejected.

/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  Fri Jan 31 12:40:48 2014
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 BC0CB1A03CC for ; Fri, 31 Jan 2014 12:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 NFiFtH330iIv for ; Fri, 31 Jan 2014 12:40:47 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 736A71A0292 for ; Fri, 31 Jan 2014 12:40:47 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 087F7240C58A; Fri, 31 Jan 2014 21:40:43 +0100 (CET)
Date: Fri, 31 Jan 2014 21:40:42 +0100 (CET)
Message-Id: <20140131.214042.353989959.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20140131202620.GB31150@elstar.local>
References: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.mbj@tail-f.com> <20140131202620.GB31150@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-chairs@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 31 Jan 2014 20:40:48 -0000

Juergen Schoenwaelder  wrote:
> On Fri, Jan 31, 2014 at 05:45:32PM +0100, Martin Bjorklund wrote:
> > 
> > I think you do have a valid point.  It is probably be better to have
> > one fixed version of the enumeration standardized.  But the problem is
> > how this module would be maintained.  Apparently the database changes
> > too often for being maintained in RFCs.  And there also seems to be
> > a political dimension to it that I don't think we are prepared to
> > handle.  And if we simply publish an RFC with the current version of
> > the names from the database, what does it mean that the
> > IANA-maintained db differs?
> > 
> 
> I completely fail to understand which value an RFC with an almost
> immediately outdated list of TZ names has.

I don't think it is "immediately outdated".  Locations are rarely added and
removed.

> I would then rather prefer
> to code my manager to use my local list and be prepared that names can
> be rejected.

I expect this to work reasonably well in practice.  But the point is
that you don't know if a value will be accepted or not.


/martin


From j.schoenwaelder@jacobs-university.de  Fri Jan 31 12:51:09 2014
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 5A10D1A0456 for ; Fri, 31 Jan 2014 12:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.785
X-Spam-Level: 
X-Spam-Status: No, score=-2.785 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.535] 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 iuJqu8lrEu-H for ; Fri, 31 Jan 2014 12:51: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 799B31A0451 for ; Fri, 31 Jan 2014 12:51:07 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6292E20061; Fri, 31 Jan 2014 21:51:03 +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 ETUQgCfhlddt; Fri, 31 Jan 2014 21:51: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 C323620033; Fri, 31 Jan 2014 21:51:02 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 94AFD2B03AC5; Fri, 31 Jan 2014 21:51:00 +0100 (CET)
Date: Fri, 31 Jan 2014 21:50:59 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20140131205059.GA31573@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, tnadeau@lucidvision.com, netmod-chairs@tools.ietf.org, netmod@ietf.org
References: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.mbj@tail-f.com> <20140131202620.GB31150@elstar.local> <20140131.214042.353989959.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140131.214042.353989959.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod-chairs@tools.ietf.org, netmod@ietf.org
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 31 Jan 2014 20:51:09 -0000

On Fri, Jan 31, 2014 at 09:40:42PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Jan 31, 2014 at 05:45:32PM +0100, Martin Bjorklund wrote:
> > > 
> > > I think you do have a valid point.  It is probably be better to have
> > > one fixed version of the enumeration standardized.  But the problem is
> > > how this module would be maintained.  Apparently the database changes
> > > too often for being maintained in RFCs.  And there also seems to be
> > > a political dimension to it that I don't think we are prepared to
> > > handle.  And if we simply publish an RFC with the current version of
> > > the names from the database, what does it mean that the
> > > IANA-maintained db differs?
> > > 
> > 
> > I completely fail to understand which value an RFC with an almost
> > immediately outdated list of TZ names has.
> 
> I don't think it is "immediately outdated".  Locations are rarely added and
> removed.

The numbers I recall indicate a certain chance it comes out of the
whole process already outdated. But even if it takes a year, the value
is rather questionable.
 
> > I would then rather prefer
> > to code my manager to use my local list and be prepared that names can
> > be rejected.
> 
> I expect this to work reasonably well in practice.  But the point is
> that you don't know if a value will be accepted or not.

So what? I believe we will see other leaf where you can't predict for
100% that the value will be accepted. If we continue to strive for a
perfect world, we will never ever achieve anything. I really doubt
setting the timezone name is the biggest interoperability problem to
solve.

/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  Fri Jan 31 12:53:27 2014
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 C5BC01A0456 for ; Fri, 31 Jan 2014 12:53:27 -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 QbadlP6e84Cw for ; Fri, 31 Jan 2014 12:53:25 -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 A17151A0451 for ; Fri, 31 Jan 2014 12:53:25 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id j5so7037056qaq.34 for ; Fri, 31 Jan 2014 12:53:21 -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=cphHA0qyOYxTV9O5MFIQovEivCIAob4QRCpEGXRyRIk=; b=cIjiJQctCqjy1EJJx/+c6VNwA4aGhw876bzESrzeLAyq8XmCcp6nJQyBJo28s1HK9g JGTeJU18+o25AIxd13yBjYk5q2fS8sXibawjXaTsJrdWr7DMTyB/VMzWyQx9hlwa0iMs Ql4oNiOBH4DoNGsMF9IJ4v6+hGwaNfPuvxVyxrt3u/+hEx1IEFYdlXJWx878U/kzXLQo Xb/DwivvCF4/m9BH0oVi00/DlXXuy9IB5fan/qo3NlXuV65A4N7mswnbmMSGPP3oqfwE ILfX3wABW4f6zBYCgt2+67msNlPf3CO650PxTiKQcJxVMBU8MKpL6A3npgC3BlHWhKYW T/2A==
X-Gm-Message-State: ALoCoQmCLXbuCDdEcE1Pjw3Qjwodwje7pKF0n2gJWxDme907o2J+aO4QmRpEc9Hth8YocN0FuDvn
MIME-Version: 1.0
X-Received: by 10.140.92.65 with SMTP id a59mr32955144qge.34.1391201601853; Fri, 31 Jan 2014 12:53:21 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Fri, 31 Jan 2014 12:53:21 -0800 (PST)
In-Reply-To: <20140131.214042.353989959.mbj@tail-f.com>
References: <0B4780F9-FC24-4D8E-8F9E-BE5D2E55B2FB@nic.cz> <20140131.174532.535193369.mbj@tail-f.com> <20140131202620.GB31150@elstar.local> <20140131.214042.353989959.mbj@tail-f.com>
Date: Fri, 31 Jan 2014 12:53:21 -0800
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a113ab29e4a47e604f14a5db8
Cc: netmod-chairs@tools.ietf.org, "netmod@ietf.org" 
Subject: Re: [netmod] consensus all: timezone-location and draft-ietf-netmod-iana-timezones-03
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, 31 Jan 2014 20:53:28 -0000

--001a113ab29e4a47e604f14a5db8
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 31, 2014 at 12:40 PM, Martin Bjorklund  wrote:

> Juergen Schoenwaelder  wrote:
> > On Fri, Jan 31, 2014 at 05:45:32PM +0100, Martin Bjorklund wrote:
> > >
> > > I think you do have a valid point.  It is probably be better to have
> > > one fixed version of the enumeration standardized.  But the problem is
> > > how this module would be maintained.  Apparently the database changes
> > > too often for being maintained in RFCs.  And there also seems to be
> > > a political dimension to it that I don't think we are prepared to
> > > handle.  And if we simply publish an RFC with the current version of
> > > the names from the database, what does it mean that the
> > > IANA-maintained db differs?
> > >
> >
> > I completely fail to understand which value an RFC with an almost
> > immediately outdated list of TZ names has.
>
> I don't think it is "immediately outdated".  Locations are rarely added and
> removed.
>

3 a year may be rare but IMO that is too often for a standard YANG module.


>
> > I would then rather prefer
> > to code my manager to use my local list and be prepared that names can
> > be rejected.
>
> I expect this to work reasonably well in practice.  But the point is
> that you don't know if a value will be accepted or not.
>

You mean you don't know from analyzing the YANG module.
Code today must already use some other validation mechanism.
IMO they will still use some other validation mechanism.

Eventually (4 months or so) the YANG module will start rejecting
requests that are valid in the TZ database.  I agree with Juergen
about not seeing the value in this sort of YANG module.
I am not buying that this a feature instead of a bug (i.e., declare that
the YANG module is a new standard, not related to the TZ database)




>
>
> /martin
>


Andy


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

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





On Fri, Jan 31, 2014 at 12:40 PM, Martin Bjorklund <mbj@tail-f.com> wrote:


Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<=
/a>> wrote:


> On Fri, Jan 31, 2014 at 05:45:32PM +0100, Martin Bjorklund wrote:

> >

> > I think you do have a valid point. =A0It is probably be better to=
 have

> > one fixed version of the enumeration standardized. =A0But the pro=
blem is

> > how this module would be maintained. =A0Apparently the database c=
hanges

> > too often for being maintained in RFCs. =A0And there also seems t=
o be

> > a political dimension to it that I don't think we are prepare=
d to

> > handle. =A0And if we simply publish an RFC with the current versi=
on of

> > the names from the database, what does it mean that the

> > IANA-maintained db differs?

> >

>

> I completely fail to understand which value an RFC with an almost

> immediately outdated list of TZ names has.



I don't think it is "immediately outdated". =A0Locations are =
rarely added and

removed.





> I would then rather prefer

> to code my manager to use my local list and be prepared that names can=


> be rejected.



I expect this to work reasonably well in practice. =A0But the point is

that you don't know if a value will be accepted or not.

You mean you don't know from analyzing the YANG mo=
dule.
Code today must already use some other validation mechanism=
.


IMO they will still use some other validation mechanism.
Eventually (4 months or so) the YANG module will start rejectin=
g
requests that are valid in the TZ database. =A0I agree with Jue=
rgen


about not seeing the value in this sort of YANG module.
I am=
 not buying that this a feature instead of a bug (i.e., declare that
<=
div>the YANG module is a new standard, not related to the TZ database)



=A0





/martin


Andy
=
=A0



_______________________________________________

netmod mailing list

netmod@ietf.org

=
https://www.ietf.org/mailman/listinfo/netmod





--001a113ab29e4a47e604f14a5db8--