From calle@tail-f.com Fri Jun 1 04:01:57 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC6921F864C for ; Fri, 1 Jun 2012 04:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLpXYxqqweWD for ; Fri, 1 Jun 2012 04:01:57 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C376521F8642 for ; Fri, 1 Jun 2012 04:01:56 -0700 (PDT) Received: from calle-macbook.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C34B1200AEC; Fri, 1 Jun 2012 13:01:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Carl Moberg In-Reply-To: <20120531.230040.65100516.mbj@tail-f.com> Date: Fri, 1 Jun 2012 12:51:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B6CB54B-45D8-44E6-9EA4-AB17F5873DD9@tail-f.com> References: <4FC7C42D.9070106@netconfcentral.org> <20120531.230040.65100516.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1257) Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 11:01:58 -0000 We use import by revision in the CableLabs CCAP project. On May 31, 2012, at 23:00 PM, Martin Bjorklund wrote: > Hi, >=20 > I think I agree with you. I have never seen import by revision being > used. include by revision, however, is used, and useful. >=20 > Note that RFC 6087 says: >=20 > The revision-date substatement within the imports statement SHOULD = be > present if any groupings are used from the external module. >=20 >=20 >=20 > /martin >=20 >=20 >=20 > Andy Bierman wrote: >> Hi, >>=20 >> I think the use-case for import-by-revision in sec. 5.1.1 is >> really vague and the example is not clear. >>=20 >> When the author of "a" publishes a new revision, the changes may = not >> be acceptable to the author of "b". If the new revision is >> acceptable, the author of "b" can republish with an updated = revision >> in the "import" statement. >>=20 >>=20 >> This is wrong. Why wouldn't the changes to module "a" be acceptable >> if the author follows the update rules in section 10? >>=20 >> The import exact revision rule is too fragile and does not match >> any real use cases: >>=20 >> 7.1.5.1. The import's revision-date Statement >>=20 >> The import's "revision-date" statement is used to specify the = exact >> version of the module to import. The "revision-date" statement = MUST >> match the most recent "revision" statement in the imported = module. >>=20 >> The most common and important use case is to require "version>=3D X", = not "version =3D=3D X". >> I know this can cause optional nodes to suddenly appear in expanded = uses-stmts, >> but this is actually a feature (reusing multiple versions of a = complex type in >> the same data model is a bad idea). >>=20 >> The relevant revision date is the one that the client or other data = model starts >> relying on the presence of a particular definition. After that = point, since >> only legal changes are being made, the client or other data model can = upgrade >> to a new version without breaking anything. >>=20 >>=20 >> Andy >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From andy@netconfcentral.org Fri Jun 1 05:53:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C327D11E81A2 for ; Fri, 1 Jun 2012 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+x6oKj-sarN for ; Fri, 1 Jun 2012 05:53:17 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA4811E8140 for ; Fri, 1 Jun 2012 05:53:13 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q51CrC1W012445 for ; Fri, 1 Jun 2012 08:53:12 -0400 Authentication-Results: cm-omr1 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:42252] helo=[192.168.0.168]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id 08/B3-06474-83BB8CF4; Fri, 01 Jun 2012 08:53:12 -0400 Message-ID: <4FC8BB36.6060704@netconfcentral.org> Date: Fri, 01 Jun 2012 05:53:10 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Carl Moberg References: <4FC7C42D.9070106@netconfcentral.org> <20120531.230040.65100516.mbj@tail-f.com> <3B6CB54B-45D8-44E6-9EA4-AB17F5873DD9@tail-f.com> In-Reply-To: <3B6CB54B-45D8-44E6-9EA4-AB17F5873DD9@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 12:53:19 -0000 On 06/01/2012 03:51 AM, Carl Moberg wrote: > We use import by revision in the CableLabs CCAP project. Do you have a use-case or you just wanted to make the module as fragile as possible? Do you really expect that when you update the imported module, following the change rules in RFC 6020, that the importing module will break? Do you anticipate the need to change the imported module in such a way that it would break the other module? My point is that import exact version X is fragile because the server has to advertise multiple versions of the same module in order to upgrade module X for new objects, and still have the exact version some import-by-revision module expects. This is completely broken from a conformance POV. 2 versions of the same module implies 2 separate conformances for the module -- which 1 does the client trust? Which conformance applies to which objects? What if the new version obsoletes an object? Is the object implemented or not? Import yb revision is broken because YANG conformance is broken. Andy > > On May 31, 2012, at 23:00 PM, Martin Bjorklund wrote: > >> Hi, >> >> I think I agree with you. I have never seen import by revision being >> used. include by revision, however, is used, and useful. >> >> Note that RFC 6087 says: >> >> The revision-date substatement within the imports statement SHOULD be >> present if any groupings are used from the external module. >> >> >> >> /martin >> >> >> >> Andy Bierman wrote: >>> Hi, >>> >>> I think the use-case for import-by-revision in sec. 5.1.1 is >>> really vague and the example is not clear. >>> >>> When the author of "a" publishes a new revision, the changes may not >>> be acceptable to the author of "b". If the new revision is >>> acceptable, the author of "b" can republish with an updated revision >>> in the "import" statement. >>> >>> >>> This is wrong. Why wouldn't the changes to module "a" be acceptable >>> if the author follows the update rules in section 10? >>> >>> The import exact revision rule is too fragile and does not match >>> any real use cases: >>> >>> 7.1.5.1. The import's revision-date Statement >>> >>> The import's "revision-date" statement is used to specify the exact >>> version of the module to import. The "revision-date" statement MUST >>> match the most recent "revision" statement in the imported module. >>> >>> The most common and important use case is to require "version>= X", not "version == X". >>> I know this can cause optional nodes to suddenly appear in expanded uses-stmts, >>> but this is actually a feature (reusing multiple versions of a complex type in >>> the same data model is a bad idea). >>> >>> The relevant revision date is the one that the client or other data model starts >>> relying on the presence of a particular definition. After that point, since >>> only legal changes are being made, the client or other data model can upgrade >>> to a new version without breaking anything. >>> >>> >>> Andy >>> >>> >>> _______________________________________________ >>> 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 > -- > Carl Moberg, Tail-f Systems > mailto:calle@tail-f.com > twitter: @cmoberg > http://www.tail-f.com/ > > > From calle@tail-f.com Fri Jun 1 06:03:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389E211E86F8 for ; Fri, 1 Jun 2012 06:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAo1dponli69 for ; Fri, 1 Jun 2012 06:03:37 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 284EB11E86F0 for ; Fri, 1 Jun 2012 06:03:37 -0700 (PDT) Received: from calle-macbook.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 116CE1200AEC; Fri, 1 Jun 2012 15:03:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carl Moberg In-Reply-To: <4FC8BB36.6060704@netconfcentral.org> Date: Fri, 1 Jun 2012 15:03:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <42528CDD-1C04-4AFE-ACF0-E8973A829127@tail-f.com> References: <4FC7C42D.9070106@netconfcentral.org> <20120531.230040.65100516.mbj@tail-f.com> <3B6CB54B-45D8-44E6-9EA4-AB17F5873DD9@tail-f.com> <4FC8BB36.6060704@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 13:03:38 -0000 On Jun 1, 2012, at 14:53 PM, Andy Bierman wrote: > On 06/01/2012 03:51 AM, Carl Moberg wrote: >> We use import by revision in the CableLabs CCAP project. >=20 > Do you have a use-case or you just wanted to make the > module as fragile as possible? Well, the expectation is that a specific (as published by CableLabs) = version CCAP module imports well known revisions of modules from other = sources so that the combination YANG modules as a whole is strictly = defined. When the CCAP version is updated it's up to the editor(s) to = update the import revisions if needed. > Do you really expect that when you update the imported module, > following the change rules in RFC 6020, that the importing module > will break? Do you anticipate the need to change the imported > module in such a way that it would break the other module? I (with CCAP module editor hat on) don't expect to update any imported = module. > My point is that import exact version X is fragile because the > server has to advertise multiple versions of the same module > in order to upgrade module X for new objects, and still have > the exact version some import-by-revision module expects. I (with CCAP module editor hat on) think that the "model = stability/precision" provided by import by revision is beneficial for = the consumers of the service (CCAP-specific client library developers, = etc). > This is completely broken from a conformance POV. > 2 versions of the same module implies 2 separate conformances > for the module -- which 1 does the client trust? Which conformance > applies to which objects? What if the new version obsoletes > an object? Is the object implemented or not? I (still same hat) wouldn't expect several versions of the modules = directly related to (as imported by revision) the CCAP module. > Import yb revision is broken because YANG conformance is broken. >=20 >=20 > Andy >=20 >>=20 >> On May 31, 2012, at 23:00 PM, Martin Bjorklund wrote: >>=20 >>> Hi, >>>=20 >>> I think I agree with you. I have never seen import by revision = being >>> used. include by revision, however, is used, and useful. >>>=20 >>> Note that RFC 6087 says: >>>=20 >>> The revision-date substatement within the imports statement SHOULD = be >>> present if any groupings are used from the external module. >>>=20 >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>=20 >>> Andy Bierman wrote: >>>> Hi, >>>>=20 >>>> I think the use-case for import-by-revision in sec. 5.1.1 is >>>> really vague and the example is not clear. >>>>=20 >>>> When the author of "a" publishes a new revision, the changes may = not >>>> be acceptable to the author of "b". If the new revision is >>>> acceptable, the author of "b" can republish with an updated = revision >>>> in the "import" statement. >>>>=20 >>>>=20 >>>> This is wrong. Why wouldn't the changes to module "a" be = acceptable >>>> if the author follows the update rules in section 10? >>>>=20 >>>> The import exact revision rule is too fragile and does not match >>>> any real use cases: >>>>=20 >>>> 7.1.5.1. The import's revision-date Statement >>>>=20 >>>> The import's "revision-date" statement is used to specify the = exact >>>> version of the module to import. The "revision-date" = statement MUST >>>> match the most recent "revision" statement in the imported = module. >>>>=20 >>>> The most common and important use case is to require "version>=3D = X", not "version =3D=3D X". >>>> I know this can cause optional nodes to suddenly appear in expanded = uses-stmts, >>>> but this is actually a feature (reusing multiple versions of a = complex type in >>>> the same data model is a bad idea). >>>>=20 >>>> The relevant revision date is the one that the client or other data = model starts >>>> relying on the presence of a particular definition. After that = point, since >>>> only legal changes are being made, the client or other data model = can upgrade >>>> to a new version without breaking anything. >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Carl Moberg, Tail-f Systems >> mailto:calle@tail-f.com >> twitter: @cmoberg >> http://www.tail-f.com/ >>=20 >>=20 >>=20 >=20 -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From andy@netconfcentral.org Fri Jun 1 06:29:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6E011E80E1 for ; Fri, 1 Jun 2012 06:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+RICGuV0Bof for ; Fri, 1 Jun 2012 06:29:31 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id DE55D11E8089 for ; Fri, 1 Jun 2012 06:29:30 -0700 (PDT) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q51DTTdJ030063 for ; Fri, 1 Jun 2012 09:29:29 -0400 Authentication-Results: cm-omr2 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:42941] helo=[192.168.0.168]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id FA/7E-11572-8B3C8CF4; Fri, 01 Jun 2012 09:29:29 -0400 Message-ID: <4FC8C3B3.7000008@netconfcentral.org> Date: Fri, 01 Jun 2012 06:29:23 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Carl Moberg References: <4FC7C42D.9070106@netconfcentral.org> <20120531.230040.65100516.mbj@tail-f.com> <3B6CB54B-45D8-44E6-9EA4-AB17F5873DD9@tail-f.com> <4FC8BB36.6060704@netconfcentral.org> <42528CDD-1C04-4AFE-ACF0-E8973A829127@tail-f.com> In-Reply-To: <42528CDD-1C04-4AFE-ACF0-E8973A829127@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 13:29:32 -0000 On 06/01/2012 06:03 AM, Carl Moberg wrote: > On Jun 1, 2012, at 14:53 PM, Andy Bierman wrote: You seem to be saying that you will republish both the importing and imported modules at the same time if that is needed. You control what goes into a new version, and you can make sure every import of module X in your system is an import-by-revision identifying the same revision. The problems show up when you don't have publication control over the imported module or every module in the system that also happens to import module X. Then the server can advertise multiple versions of the same module in its . The module capabilities are not a deterministic snapshot of the data model a server is expected to support. There are lots of corner-cases, but 1 of the most obvious: - module A contains top-level typedefs intended for module A and some mandatory objects - module B is written later and needs the typedefs, so it imports A to reuse the data types. - platform acme-1000 needs to implement module B, but its says it also implements module A Andy >> On 06/01/2012 03:51 AM, Carl Moberg wrote: >>> We use import by revision in the CableLabs CCAP project. >> Do you have a use-case or you just wanted to make the >> module as fragile as possible? > Well, the expectation is that a specific (as published by CableLabs) version CCAP module imports well known revisions of modules from other sources so that the combination YANG modules as a whole is strictly defined. When the CCAP version is updated it's up to the editor(s) to update the import revisions if needed. > >> Do you really expect that when you update the imported module, >> following the change rules in RFC 6020, that the importing module >> will break? Do you anticipate the need to change the imported >> module in such a way that it would break the other module? > I (with CCAP module editor hat on) don't expect to update any imported module. > >> My point is that import exact version X is fragile because the >> server has to advertise multiple versions of the same module >> in order to upgrade module X for new objects, and still have >> the exact version some import-by-revision module expects. > I (with CCAP module editor hat on) think that the "model stability/precision" provided by import by revision is beneficial for the consumers of the service (CCAP-specific client library developers, etc). > >> This is completely broken from a conformance POV. >> 2 versions of the same module implies 2 separate conformances >> for the module -- which 1 does the client trust? Which conformance >> applies to which objects? What if the new version obsoletes >> an object? Is the object implemented or not? > I (still same hat) wouldn't expect several versions of the modules directly related to (as imported by revision) the CCAP module. > >> Import yb revision is broken because YANG conformance is broken. >> >> >> Andy >> >>> On May 31, 2012, at 23:00 PM, Martin Bjorklund wrote: >>> >>>> Hi, >>>> >>>> I think I agree with you. I have never seen import by revision being >>>> used. include by revision, however, is used, and useful. >>>> >>>> Note that RFC 6087 says: >>>> >>>> The revision-date substatement within the imports statement SHOULD be >>>> present if any groupings are used from the external module. >>>> >>>> >>>> >>>> /martin >>>> >>>> >>>> >>>> Andy Bierman wrote: >>>>> Hi, >>>>> >>>>> I think the use-case for import-by-revision in sec. 5.1.1 is >>>>> really vague and the example is not clear. >>>>> >>>>> When the author of "a" publishes a new revision, the changes may not >>>>> be acceptable to the author of "b". If the new revision is >>>>> acceptable, the author of "b" can republish with an updated revision >>>>> in the "import" statement. >>>>> >>>>> >>>>> This is wrong. Why wouldn't the changes to module "a" be acceptable >>>>> if the author follows the update rules in section 10? >>>>> >>>>> The import exact revision rule is too fragile and does not match >>>>> any real use cases: >>>>> >>>>> 7.1.5.1. The import's revision-date Statement >>>>> >>>>> The import's "revision-date" statement is used to specify the exact >>>>> version of the module to import. The "revision-date" statement MUST >>>>> match the most recent "revision" statement in the imported module. >>>>> >>>>> The most common and important use case is to require "version>= X", not "version == X". >>>>> I know this can cause optional nodes to suddenly appear in expanded uses-stmts, >>>>> but this is actually a feature (reusing multiple versions of a complex type in >>>>> the same data model is a bad idea). >>>>> >>>>> The relevant revision date is the one that the client or other data model starts >>>>> relying on the presence of a particular definition. After that point, since >>>>> only legal changes are being made, the client or other data model can upgrade >>>>> to a new version without breaking anything. >>>>> >>>>> >>>>> Andy >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> -- >>> Carl Moberg, Tail-f Systems >>> mailto:calle@tail-f.com >>> twitter: @cmoberg >>> http://www.tail-f.com/ >>> >>> >>> > -- > Carl Moberg, Tail-f Systems > mailto:calle@tail-f.com > twitter: @cmoberg > http://www.tail-f.com/ > > > From calle@tail-f.com Fri Jun 1 06:41:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1960811E8179 for ; Fri, 1 Jun 2012 06:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayRzMqUOlisa for ; Fri, 1 Jun 2012 06:41:40 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E88A311E8174 for ; Fri, 1 Jun 2012 06:41:39 -0700 (PDT) Received: from calle-macbook.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 0239B1200050; Fri, 1 Jun 2012 15:41:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carl Moberg In-Reply-To: <4FC8C3B3.7000008@netconfcentral.org> Date: Fri, 1 Jun 2012 15:41:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <610429DC-2BF0-4BB8-8651-46C1B51B1DED@tail-f.com> References: <4FC7C42D.9070106@netconfcentral.org> <20120531.230040.65100516.mbj@tail-f.com> <3B6CB54B-45D8-44E6-9EA4-AB17F5873DD9@tail-f.com> <4FC8BB36.6060704@netconfcentral.org> <42528CDD-1C04-4AFE-ACF0-E8973A829127@tail-f.com> <4FC8C3B3.7000008@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1257) Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 13:41:41 -0000 On Jun 1, 2012, at 15:29 PM, Andy Bierman wrote: > On 06/01/2012 06:03 AM, Carl Moberg wrote: >> On Jun 1, 2012, at 14:53 PM, Andy Bierman wrote: >=20 >=20 > You seem to be saying that you will republish both the > importing and imported modules at the same time > if that is needed. You control what goes into > a new version, and you can make sure every import of module X > in your system is an import-by-revision identifying the same revision. CableLabs will update the YANG module lock-step with their standard = editorial cycle. At the point of publication the editors of the CCAP = YANG module will decide if they want to import newer revisions of e.g. = ietf-yang-types or if they want to stay with the existing revision. > The problems show up when you don't have publication control > over the imported module or every module in the system that > also happens to import module X. Then the server can advertise > multiple versions of the same module in its . Agreed. It will be a design decision for the person responsible for the = complete set of YANG modules exposed by the device. > The module capabilities are not a deterministic snapshot of > the data model a server is expected to support. There are > lots of corner-cases, but 1 of the most obvious: >=20 > - module A contains top-level typedefs intended for module A and = some mandatory objects > - module B is written later and needs the typedefs, so it imports A = to reuse the data types. > - platform acme-1000 needs to implement module B, but its = says it also implements > module A All good observations of that it is indeed possible to make things very = complicated with yang imports. >=20 >=20 > Andy >=20 >=20 >=20 >=20 >=20 >=20 >=20 >>> On 06/01/2012 03:51 AM, Carl Moberg wrote: >>>> We use import by revision in the CableLabs CCAP project. >>> Do you have a use-case or you just wanted to make the >>> module as fragile as possible? >> Well, the expectation is that a specific (as published by CableLabs) = version CCAP module imports well known revisions of modules from other = sources so that the combination YANG modules as a whole is strictly = defined. When the CCAP version is updated it's up to the editor(s) to = update the import revisions if needed. >>=20 >>> Do you really expect that when you update the imported module, >>> following the change rules in RFC 6020, that the importing module >>> will break? Do you anticipate the need to change the imported >>> module in such a way that it would break the other module? >> I (with CCAP module editor hat on) don't expect to update any = imported module. >>=20 >>> My point is that import exact version X is fragile because the >>> server has to advertise multiple versions of the same module >>> in order to upgrade module X for new objects, and still have >>> the exact version some import-by-revision module expects. >> I (with CCAP module editor hat on) think that the "model = stability/precision" provided by import by revision is beneficial for = the consumers of the service (CCAP-specific client library developers, = etc). >>=20 >>> This is completely broken from a conformance POV. >>> 2 versions of the same module implies 2 separate conformances >>> for the module -- which 1 does the client trust? Which conformance >>> applies to which objects? What if the new version obsoletes >>> an object? Is the object implemented or not? >> I (still same hat) wouldn't expect several versions of the modules = directly related to (as imported by revision) the CCAP module. >>=20 >>> Import yb revision is broken because YANG conformance is broken. >>>=20 >>>=20 >>> Andy >>>=20 >>>> On May 31, 2012, at 23:00 PM, Martin Bjorklund wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I think I agree with you. I have never seen import by revision = being >>>>> used. include by revision, however, is used, and useful. >>>>>=20 >>>>> Note that RFC 6087 says: >>>>>=20 >>>>> The revision-date substatement within the imports statement = SHOULD be >>>>> present if any groupings are used from the external module. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> /martin >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Andy Bierman wrote: >>>>>> Hi, >>>>>>=20 >>>>>> I think the use-case for import-by-revision in sec. 5.1.1 is >>>>>> really vague and the example is not clear. >>>>>>=20 >>>>>> When the author of "a" publishes a new revision, the changes = may not >>>>>> be acceptable to the author of "b". If the new revision is >>>>>> acceptable, the author of "b" can republish with an updated = revision >>>>>> in the "import" statement. >>>>>>=20 >>>>>>=20 >>>>>> This is wrong. Why wouldn't the changes to module "a" be = acceptable >>>>>> if the author follows the update rules in section 10? >>>>>>=20 >>>>>> The import exact revision rule is too fragile and does not match >>>>>> any real use cases: >>>>>>=20 >>>>>> 7.1.5.1. The import's revision-date Statement >>>>>>=20 >>>>>> The import's "revision-date" statement is used to specify = the exact >>>>>> version of the module to import. The "revision-date" = statement MUST >>>>>> match the most recent "revision" statement in the imported = module. >>>>>>=20 >>>>>> The most common and important use case is to require "version>=3D = X", not "version =3D=3D X". >>>>>> I know this can cause optional nodes to suddenly appear in = expanded uses-stmts, >>>>>> but this is actually a feature (reusing multiple versions of a = complex type in >>>>>> the same data model is a bad idea). >>>>>>=20 >>>>>> The relevant revision date is the one that the client or other = data model starts >>>>>> relying on the presence of a particular definition. After that = point, since >>>>>> only legal changes are being made, the client or other data model = can upgrade >>>>>> to a new version without breaking anything. >>>>>>=20 >>>>>>=20 >>>>>> Andy >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> -- >>>> Carl Moberg, Tail-f Systems >>>> mailto:calle@tail-f.com >>>> twitter: @cmoberg >>>> http://www.tail-f.com/ >>>>=20 >>>>=20 >>>>=20 >> -- >> Carl Moberg, Tail-f Systems >> mailto:calle@tail-f.com >> twitter: @cmoberg >> http://www.tail-f.com/ >>=20 >>=20 >>=20 >=20 -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From jmh@joelhalpern.com Fri Jun 1 08:31:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA30711E8088 for ; Fri, 1 Jun 2012 08:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.253 X-Spam-Level: X-Spam-Status: No, score=-102.253 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22welPZ--UYL for ; Fri, 1 Jun 2012 08:31:14 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 874B011E80F3 for ; Fri, 1 Jun 2012 08:31:14 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 5049155805B for ; Fri, 1 Jun 2012 08:31:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id F15D11C08D3; Fri, 1 Jun 2012 08:31:12 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.110] (pool-71-161-51-104.clppva.btas.verizon.net [71.161.51.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 3660F1C08CF; Fri, 1 Jun 2012 08:31:12 -0700 (PDT) Message-ID: <4FC8E029.8040204@joelhalpern.com> Date: Fri, 01 Jun 2012 11:30:49 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andy Bierman References: <4FC7C42D.9070106@netconfcentral.org> <20120531.230040.65100516.mbj@tail-f.com> <3B6CB54B-45D8-44E6-9EA4-AB17F5873DD9@tail-f.com> <4FC8BB36.6060704@netconfcentral.org> In-Reply-To: <4FC8BB36.6060704@netconfcentral.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 15:31:15 -0000 Andy, you seem to have mixed what is probably an accurate conclusion with some very misleading questions. I would hope that the in designing a module (either one that imports others or one that is to be imported) that one does not ahve to figure out the answer to the question "what changes are likely in the future". the answer has to be "any changes that are permitted by the standards are likely", as any other answer is just asking for trouble. Yours, Joel On 6/1/2012 8:53 AM, Andy Bierman wrote: > On 06/01/2012 03:51 AM, Carl Moberg wrote: >> We use import by revision in the CableLabs CCAP project. > > Do you have a use-case or you just wanted to make the > module as fragile as possible? > > Do you really expect that when you update the imported module, > following the change rules in RFC 6020, that the importing module > will break? Do you anticipate the need to change the imported > module in such a way that it would break the other module? > > My point is that import exact version X is fragile because the > server has to advertise multiple versions of the same module > in order to upgrade module X for new objects, and still have > the exact version some import-by-revision module expects. > > This is completely broken from a conformance POV. > 2 versions of the same module implies 2 separate conformances > for the module -- which 1 does the client trust? Which conformance > applies to which objects? What if the new version obsoletes > an object? Is the object implemented or not? > > Import yb revision is broken because YANG conformance is broken. > > > Andy From jernej.tuljak@mg-soft.si Mon Jun 4 02:23:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3351321F8629 for ; Mon, 4 Jun 2012 02:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ijGWcPFE1Re for ; Mon, 4 Jun 2012 02:23:23 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3B321F8610 for ; Mon, 4 Jun 2012 02:23:22 -0700 (PDT) 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 q549NJC0006246 for ; Mon, 4 Jun 2012 11:23:19 +0200 Message-ID: <4FCC7E86.1050509@mg-soft.com> Date: Mon, 04 Jun 2012 11:23:18 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/alternative; boundary="------------000203030003040704070106" Subject: [netmod] YANG module compatibility X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 09:23:25 -0000 This is a multi-part message in MIME format. --------------000203030003040704070106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In a recent discussion Andy Bierman implied that a server should never advertise two revisions of the same module and I agree. This also means that a server cannot implement certain combinations of modules since they are incompatible -- or can implement them but must then choose a specific subset of the implementation to work with. I now wonder if there are any other ways for two modules to become incompatible. There's only one other case I can currently think of. I heard some developers create modules which share namespaces. If two such modules were to define at least one top-level data definition statement which appears in both of them and is named exactly the same in both of them then these two modules are bound to be incompatible, right? I'm assuming this since there would be no way to properly validate content modeled based on such modules -- and because YANG grammar prevents this within a single module and same rules apply to modules which share a namespace URI. Are there any other cases which one should be wary of? I'm asking this since I'm not sure that letting our generic client application to load just any set of modules was a good idea - especially now with a working implementation of RFC6110 in the picture -- and am trying to determine whether this should be prevented and in what way. Are there rules that apply to "module pools"? Jernej Tuljak --------------000203030003040704070106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In a recent discussion Andy Bierman implied that a server should never advertise two revisions of the same module and I agree. This also means that a server cannot implement certain combinations of modules since they are incompatible – or can implement them but must then choose a specific subset of the implementation to work with.

I now wonder if there are any other ways for two modules to become incompatible. There's only one other case I can currently think of. I heard some developers create modules which share namespaces. If two such modules were to define at least one top-level data definition statement which appears in both of them and is named exactly the same in both of them then these two modules are bound to be incompatible, right? I'm assuming this since there would be no way to properly validate content modeled based on such modules – and because YANG grammar prevents this within a single module and same rules apply to modules which share a namespace URI.

Are there any other cases which one should be wary of? I'm asking this since I'm not sure that letting our generic client application to load just any set of modules was a good idea - especially now with a working implementation of RFC6110 in the picture – and am trying to determine whether this should be prevented and in what way. Are there rules that apply to "module pools"?

Jernej Tuljak
--------------000203030003040704070106-- From Jonathan.Hansford@generaldynamics.uk.com Mon Jun 4 03:44:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069FA21F87C4 for ; Mon, 4 Jun 2012 03:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.198 X-Spam-Level: X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3kNAaYY68bR for ; Mon, 4 Jun 2012 03:44:38 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5297721F87A7 for ; Mon, 4 Jun 2012 03:44:38 -0700 (PDT) Received: from [85.158.137.83:14391] by server-10.bemta-3.messagelabs.com id 90/FE-12071-5919CCF4; Mon, 04 Jun 2012 10:44:37 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-9.tower-140.messagelabs.com!1338806676!24324400!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22142 invoked from network); 4 Jun 2012 10:44:36 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-9.tower-140.messagelabs.com with SMTP; 4 Jun 2012 10:44:36 -0000 Received: from mail.compd.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 04 Jun 2012 11:44:32 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jun 2012 11:44:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jun 2012 11:44:35 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E650546206BFABB5@GDUKADH850.uk1.r-org.net> In-Reply-To: <610429DC-2BF0-4BB8-8651-46C1B51B1DED@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] import by revision Thread-Index: Ac1CPwijFBp3RutIT0SYdSu2AcRrFg== References: <4FC7C42D.9070106@netconfcentral.org><20120531.230040.65100516.mbj@tail-f.com><3B6CB54B-45D8-44E6-9EA4-AB17F5873DD9@tail-f.com><4FC8BB36.6060704@netconfcentral.org><42528CDD-1C04-4AFE-ACF0-E8973A829127@tail-f.com><4FC8C3B3.7000008@netconfcentral.org> <610429DC-2BF0-4BB8-8651-46C1B51B1DED@tail-f.com> From: To: , X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 04 Jun 2012 10:44:28.0613 (UTC) FILETIME=[044CD750:01CD423F] Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 10:44:40 -0000 Carl, Your approach may be OK if the products are to be managed by a bespoke client. But what is a system comprising many products needs to be managed by a single management system? It would be far better not to have to worry about specific revisions of imported modules to support different products, but to know that, because of the rules relating to updating modules, the latest will work fine with all. Jonathan > -----Original Message----- > From: Carl Moberg [mailto:calle@tail-f.com] > Sent: 01 June 2012 14:42 > To: Andy Bierman > Cc: netmod@ietf.org > Subject: Re: [netmod] import by revision >=20 >=20 > On Jun 1, 2012, at 15:29 PM, Andy Bierman wrote: >=20 > > On 06/01/2012 06:03 AM, Carl Moberg wrote: > >> On Jun 1, 2012, at 14:53 PM, Andy Bierman wrote: > > > > > > You seem to be saying that you will republish both the > > importing and imported modules at the same time > > if that is needed. You control what goes into > > a new version, and you can make sure every import of module X > > in your system is an import-by-revision identifying the same revision. >=20 > CableLabs will update the YANG module lock-step with their standard > editorial cycle. At the point of publication the editors of the CCAP YANG > module will decide if they want to import newer revisions of e.g. ietf- > yang-types or if they want to stay with the existing revision. >=20 > > The problems show up when you don't have publication control > > over the imported module or every module in the system that > > also happens to import module X. Then the server can advertise > > multiple versions of the same module in its . >=20 > Agreed. It will be a design decision for the person responsible for the > complete set of YANG modules exposed by the device. >=20 > > The module capabilities are not a deterministic snapshot of > > the data model a server is expected to support. There are > > lots of corner-cases, but 1 of the most obvious: > > > > - module A contains top-level typedefs intended for module A and some > mandatory objects > > - module B is written later and needs the typedefs, so it imports A to > reuse the data types. > > - platform acme-1000 needs to implement module B, but its says > it also implements > > module A >=20 > All good observations of that it is indeed possible to make things very > complicated with yang imports. >=20 > > > > > > Andy > > > > > > > > > > > > > > > >>> On 06/01/2012 03:51 AM, Carl Moberg wrote: > >>>> We use import by revision in the CableLabs CCAP project. > >>> Do you have a use-case or you just wanted to make the > >>> module as fragile as possible? > >> Well, the expectation is that a specific (as published by CableLabs) > version CCAP module imports well known revisions of modules from other > sources so that the combination YANG modules as a whole is strictly > defined. When the CCAP version is updated it's up to the editor(s) to > update the import revisions if needed. > >> > >>> Do you really expect that when you update the imported module, > >>> following the change rules in RFC 6020, that the importing module > >>> will break? Do you anticipate the need to change the imported > >>> module in such a way that it would break the other module? > >> I (with CCAP module editor hat on) don't expect to update any imported > module. > >> > >>> My point is that import exact version X is fragile because the > >>> server has to advertise multiple versions of the same module > >>> in order to upgrade module X for new objects, and still have > >>> the exact version some import-by-revision module expects. > >> I (with CCAP module editor hat on) think that the "model > stability/precision" provided by import by revision is beneficial for the > consumers of the service (CCAP-specific client library developers, etc). > >> > >>> This is completely broken from a conformance POV. > >>> 2 versions of the same module implies 2 separate conformances > >>> for the module -- which 1 does the client trust? Which conformance > >>> applies to which objects? What if the new version obsoletes > >>> an object? Is the object implemented or not? > >> I (still same hat) wouldn't expect several versions of the modules > directly related to (as imported by revision) the CCAP module. > >> > >>> Import yb revision is broken because YANG conformance is broken. > >>> > >>> > >>> Andy > >>> > >>>> On May 31, 2012, at 23:00 PM, Martin Bjorklund wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> I think I agree with you. I have never seen import by revision > being > >>>>> used. include by revision, however, is used, and useful. > >>>>> > >>>>> Note that RFC 6087 says: > >>>>> > >>>>> The revision-date substatement within the imports statement SHOULD > be > >>>>> present if any groupings are used from the external module. > >>>>> > >>>>> > >>>>> > >>>>> /martin > >>>>> > >>>>> > >>>>> > >>>>> Andy Bierman wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I think the use-case for import-by-revision in sec. 5.1.1 is > >>>>>> really vague and the example is not clear. > >>>>>> > >>>>>> When the author of "a" publishes a new revision, the changes may > not > >>>>>> be acceptable to the author of "b". If the new revision is > >>>>>> acceptable, the author of "b" can republish with an updated > revision > >>>>>> in the "import" statement. > >>>>>> > >>>>>> > >>>>>> This is wrong. Why wouldn't the changes to module "a" be > acceptable > >>>>>> if the author follows the update rules in section 10? > >>>>>> > >>>>>> The import exact revision rule is too fragile and does not match > >>>>>> any real use cases: > >>>>>> > >>>>>> 7.1.5.1. The import's revision-date Statement > >>>>>> > >>>>>> The import's "revision-date" statement is used to specify the > exact > >>>>>> version of the module to import. The "revision-date" > statement MUST > >>>>>> match the most recent "revision" statement in the imported > module. > >>>>>> > >>>>>> The most common and important use case is to require "version>=3D X", > not "version =3D=3D X". > >>>>>> I know this can cause optional nodes to suddenly appear in expanded > uses-stmts, > >>>>>> but this is actually a feature (reusing multiple versions of a > complex type in > >>>>>> the same data model is a bad idea). > >>>>>> > >>>>>> The relevant revision date is the one that the client or other data > model starts > >>>>>> relying on the presence of a particular definition. After that > point, since > >>>>>> only legal changes are being made, the client or other data model > can upgrade > >>>>>> to a new version without breaking anything. > >>>>>> > >>>>>> > >>>>>> Andy > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>>> -- > >>>> Carl Moberg, Tail-f Systems > >>>> mailto:calle@tail-f.com > >>>> twitter: @cmoberg > >>>> http://www.tail-f.com/ > >>>> > >>>> > >>>> > >> -- > >> Carl Moberg, Tail-f Systems > >> mailto:calle@tail-f.com > >> twitter: @cmoberg > >> http://www.tail-f.com/ > >> > >> > >> > > >=20 > -- > Carl Moberg, Tail-f Systems > mailto:calle@tail-f.com > twitter: @cmoberg > http://www.tail-f.com/ >=20 This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From internet-drafts@ietf.org Mon Jun 4 04:02:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE30821F8758; Mon, 4 Jun 2012 04:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEEsghw7IvX7; Mon, 4 Jun 2012 04:02:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137DE21F85AF; Mon, 4 Jun 2012 04:02:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120604110234.18039.8036.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2012 04:02:34 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 11:02:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : IANA Interface Type and Address Family YANG Modules Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-iana-if-type-03.txt Pages : 49 Date : 2012-06-04 This document defines the initial versions of the iana-if-type and iana-afn-safi YANG modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/ From calle@tail-f.com Mon Jun 4 04:21:15 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DADD21F8740 for ; Mon, 4 Jun 2012 04:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-8jd6kPj8W6 for ; Mon, 4 Jun 2012 04:21:14 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 258E621F873E for ; Mon, 4 Jun 2012 04:21:14 -0700 (PDT) Received: from calle-macbook.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 2ABDA1200043; Mon, 4 Jun 2012 13:21:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Carl Moberg In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206BFABB5@GDUKADH850.uk1.r-org.net> Date: Mon, 4 Jun 2012 13:21:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28F7DD6E-C91C-40A2-AC84-C47AFA795473@tail-f.com> References: <4FC7C42D.9070106@netconfcentral.org><20120531.230040.65100516.mbj@tail-f.com><3B6CB54B-45D8-44E6-9EA4-AB17F5873DD9@tail-f.com><4FC8BB36.6060704@netconfcentral.org><42528CDD-1C04-4AFE-ACF0-E8973A829127@tail-f.com><4FC8C3B3.7000008@netconfcentral.org> <610429DC-2BF0-4BB8-8651-46C1B51B1DED@tail-f.com> <83C941F7F59F3F42AC017AD1E650546206BFABB5@GDUKADH850.uk1.r-org.net> To: X-Mailer: Apple Mail (2.1257) Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 11:21:15 -0000 Jonathan, Right, and in my experience, the requirements driving the design of the = models will vary a lot across application areas and standards writing = organizations. In the case of CableLabs and the CCAP specification there = are well defined use cases, step by step, that describes the expected = behavior of the system. This comes "before" the data model and obviously = puts various requirements on it's design. This reflects the assumption = that the clients will be "bespoke" if you wish, for the MSOs to manage = cable modem terminating systems and not much else. There's even good = reasons for the MSOs tool people/client developers to try and influence = the module design to be as specific as possible since it will make their = life easier. The decision to use import by revision was taken with all = this in mind. I'm sure there are other environments where other = requirements would have the module authors not import by revision. On Jun 4, 2012, at 12:44 PM, = wrote: > Carl, >=20 > Your approach may be OK if the products are to be managed by a bespoke > client. But what is a system comprising many products needs to be > managed by a single management system? It would be far better not to > have to worry about specific revisions of imported modules to support > different products, but to know that, because of the rules relating to > updating modules, the latest will work fine with all. >=20 > Jonathan >=20 >> -----Original Message----- >> From: Carl Moberg [mailto:calle@tail-f.com] >> Sent: 01 June 2012 14:42 >> To: Andy Bierman >> Cc: netmod@ietf.org >> Subject: Re: [netmod] import by revision >>=20 >>=20 >> On Jun 1, 2012, at 15:29 PM, Andy Bierman wrote: >>=20 >>> On 06/01/2012 06:03 AM, Carl Moberg wrote: >>>> On Jun 1, 2012, at 14:53 PM, Andy Bierman wrote: >>>=20 >>>=20 >>> You seem to be saying that you will republish both the >>> importing and imported modules at the same time >>> if that is needed. You control what goes into >>> a new version, and you can make sure every import of module X >>> in your system is an import-by-revision identifying the same > revision. >>=20 >> CableLabs will update the YANG module lock-step with their standard >> editorial cycle. At the point of publication the editors of the CCAP > YANG >> module will decide if they want to import newer revisions of e.g. > ietf- >> yang-types or if they want to stay with the existing revision. >>=20 >>> The problems show up when you don't have publication control >>> over the imported module or every module in the system that >>> also happens to import module X. Then the server can advertise >>> multiple versions of the same module in its . >>=20 >> Agreed. It will be a design decision for the person responsible for > the >> complete set of YANG modules exposed by the device. >>=20 >>> The module capabilities are not a deterministic snapshot of >>> the data model a server is expected to support. There are >>> lots of corner-cases, but 1 of the most obvious: >>>=20 >>> - module A contains top-level typedefs intended for module A and > some >> mandatory objects >>> - module B is written later and needs the typedefs, so it imports > A to >> reuse the data types. >>> - platform acme-1000 needs to implement module B, but its > says >> it also implements >>> module A >>=20 >> All good observations of that it is indeed possible to make things > very >> complicated with yang imports. >>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>>> On 06/01/2012 03:51 AM, Carl Moberg wrote: >>>>>> We use import by revision in the CableLabs CCAP project. >>>>> Do you have a use-case or you just wanted to make the >>>>> module as fragile as possible? >>>> Well, the expectation is that a specific (as published by > CableLabs) >> version CCAP module imports well known revisions of modules from = other >> sources so that the combination YANG modules as a whole is strictly >> defined. When the CCAP version is updated it's up to the editor(s) to >> update the import revisions if needed. >>>>=20 >>>>> Do you really expect that when you update the imported module, >>>>> following the change rules in RFC 6020, that the importing module >>>>> will break? Do you anticipate the need to change the imported >>>>> module in such a way that it would break the other module? >>>> I (with CCAP module editor hat on) don't expect to update any > imported >> module. >>>>=20 >>>>> My point is that import exact version X is fragile because the >>>>> server has to advertise multiple versions of the same module >>>>> in order to upgrade module X for new objects, and still have >>>>> the exact version some import-by-revision module expects. >>>> I (with CCAP module editor hat on) think that the "model >> stability/precision" provided by import by revision is beneficial for > the >> consumers of the service (CCAP-specific client library developers, > etc). >>>>=20 >>>>> This is completely broken from a conformance POV. >>>>> 2 versions of the same module implies 2 separate conformances >>>>> for the module -- which 1 does the client trust? Which > conformance >>>>> applies to which objects? What if the new version obsoletes >>>>> an object? Is the object implemented or not? >>>> I (still same hat) wouldn't expect several versions of the modules >> directly related to (as imported by revision) the CCAP module. >>>>=20 >>>>> Import yb revision is broken because YANG conformance is broken. >>>>>=20 >>>>>=20 >>>>> Andy >>>>>=20 >>>>>> On May 31, 2012, at 23:00 PM, Martin Bjorklund wrote: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> I think I agree with you. I have never seen import by revision >> being >>>>>>> used. include by revision, however, is used, and useful. >>>>>>>=20 >>>>>>> Note that RFC 6087 says: >>>>>>>=20 >>>>>>> The revision-date substatement within the imports statement > SHOULD >> be >>>>>>> present if any groupings are used from the external module. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> /martin >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Andy Bierman wrote: >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> I think the use-case for import-by-revision in sec. 5.1.1 is >>>>>>>> really vague and the example is not clear. >>>>>>>>=20 >>>>>>>> When the author of "a" publishes a new revision, the changes > may >> not >>>>>>>> be acceptable to the author of "b". If the new revision is >>>>>>>> acceptable, the author of "b" can republish with an updated >> revision >>>>>>>> in the "import" statement. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> This is wrong. Why wouldn't the changes to module "a" be >> acceptable >>>>>>>> if the author follows the update rules in section 10? >>>>>>>>=20 >>>>>>>> The import exact revision rule is too fragile and does not > match >>>>>>>> any real use cases: >>>>>>>>=20 >>>>>>>> 7.1.5.1. The import's revision-date Statement >>>>>>>>=20 >>>>>>>> The import's "revision-date" statement is used to specify > the >> exact >>>>>>>> version of the module to import. The "revision-date" >> statement MUST >>>>>>>> match the most recent "revision" statement in the > imported >> module. >>>>>>>>=20 >>>>>>>> The most common and important use case is to require "version>=3D= > X", >> not "version =3D=3D X". >>>>>>>> I know this can cause optional nodes to suddenly appear in > expanded >> uses-stmts, >>>>>>>> but this is actually a feature (reusing multiple versions of a >> complex type in >>>>>>>> the same data model is a bad idea). >>>>>>>>=20 >>>>>>>> The relevant revision date is the one that the client or other > data >> model starts >>>>>>>> relying on the presence of a particular definition. After that >> point, since >>>>>>>> only legal changes are being made, the client or other data > model >> can upgrade >>>>>>>> to a new version without breaking anything. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Andy >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> netmod mailing list >>>>>>>> netmod@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> netmod@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>> -- >>>>>> Carl Moberg, Tail-f Systems >>>>>> mailto:calle@tail-f.com >>>>>> twitter: @cmoberg >>>>>> http://www.tail-f.com/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>> -- >>>> Carl Moberg, Tail-f Systems >>>> mailto:calle@tail-f.com >>>> twitter: @cmoberg >>>> http://www.tail-f.com/ >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >> -- >> Carl Moberg, Tail-f Systems >> mailto:calle@tail-f.com >> twitter: @cmoberg >> http://www.tail-f.com/ >>=20 >=20 >=20 >=20 > This email and any files attached are intended for the addressee and = may contain information of a confidential nature. If you are not the = intended recipient, be aware that this email was sent to you in error = and you should not disclose, distribute, print, copy or make other use = of this email or its attachments. Such actions, in fact, may be = unlawful. In compliance with the various Regulations and Acts, General = Dynamics United Kingdom Limited reserves the right to monitor (and = examine for viruses) all emails and email attachments, both inbound and = outbound. Email communications and their attachments may not be secure = or error- or virus-free and the company does not accept liability or = responsibility for such matters or the consequences thereof. General = Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, = London EC1A 2DY. Registered in England and Wales No: 1911653.=20 -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From andy@netconfcentral.org Mon Jun 4 08:15:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5628521F86A8 for ; Mon, 4 Jun 2012 08:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8fZ16g0A16P for ; Mon, 4 Jun 2012 08:15:27 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8C41121F863F for ; Mon, 4 Jun 2012 08:15:27 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q54FFQYS002670 for ; Mon, 4 Jun 2012 11:15:26 -0400 Authentication-Results: cm-omr3 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:49755] helo=[192.168.0.168]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id 5B/38-14279-D01DCCF4; Mon, 04 Jun 2012 11:15:26 -0400 Message-ID: <4FCCD10B.9040600@netconfcentral.org> Date: Mon, 04 Jun 2012 08:15:23 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jonathan.Hansford@generaldynamics.uk.com References: <4FC7C42D.9070106@netconfcentral.org><20120531.230040.65100516.mbj@tail-f.com><3B6CB54B-45D8-44E6-9EA4-AB17F5873DD9@tail-f.com><4FC8BB36.6060704@netconfcentral.org><42528CDD-1C04-4AFE-ACF0-E8973A829127@tail-f.com><4FC8C3B3.7000008@netconfcentral.org> <610429DC-2BF0-4BB8-8651-46C1B51B1DED@tail-f.com> <83C941F7F59F3F42AC017AD1E650546206BFABB5@GDUKADH850.uk1.r-org.net> In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206BFABB5@GDUKADH850.uk1.r-org.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 15:15:28 -0000 On 06/04/2012 03:44 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: > Carl, > > Your approach may be OK if the products are to be managed by a bespoke > client. But what is a system comprising many products needs to be > managed by a single management system? It would be far better not to > have to worry about specific revisions of imported modules to support > different products, but to know that, because of the rules relating to > updating modules, the latest will work fine with all. Obviously a single-purpose embedded device is much more likely to have a single naming authority than a large embedded system or an open system. I didn't say a server must not advertise 2 revisions of a module. Actually the server should advertise all the modules it uses directly or indirectly through imports. The YANG module capabilities sent in the NETCONF attempt to serve 2 functions, neither of which is does all that well: 1) schema tree - each main module name, XML namespace, and revision date allows the client to identify the module to find (from the local modules it already knows about). - If is supported the client can guess .yang, and then .yin, and get the main module from the server. - if submodules are used, the client will either have them locally or use as needed (by parsing all the main modules to find include-stmts). Submodules are not advertised in the NETCONF . 2) conformance - the features and deviations are patched into the exact modules/revisions the server advertised to determine all the supported data objects Both are incomplete, and conflict with each other. Doing (1) correctly is likely to claim conformance to modules just imported for meta-data, not objects. Doing (2) correctly is likely to leave out modules needed to build the schema tree. > Jonathan Andy > From jernej.tuljak@mg-soft.si Tue Jun 5 01:11:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6E621F86DC for ; Tue, 5 Jun 2012 01:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxr3z-W0ASb3 for ; Tue, 5 Jun 2012 01:11:57 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 21B0C21F86D7 for ; Tue, 5 Jun 2012 01:11:54 -0700 (PDT) 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 q558Bpff020647; Tue, 5 Jun 2012 10:11:52 +0200 Message-ID: <4FCDBF46.2080500@mg-soft.com> Date: Tue, 05 Jun 2012 10:11:50 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <4FC7C42D.9070106@netconfcentral.org><20120531.230040.65100516.mbj@tail-f.com><3B6CB54B-45D8-44E6-9EA4-AB17F5873DD9@tail-f.com><4FC8BB36.6060704@netconfcentral.org><42528CDD-1C04-4AFE-ACF0-E8973A829127@tail-f.com><4FC8C3B3.7000008@netconfcentral.org> <610429DC-2BF0-4BB8-8651-46C1B51B1DED@tail-f.com> <83C941F7F59F3F42AC017AD1E650546206BFABB5@GDUKADH850.uk1.r-org.net> <4FCCD10B.9040600@netconfcentral.org> In-Reply-To: <4FCCD10B.9040600@netconfcentral.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 08:11:58 -0000 Dne 4.6.2012 17:15, piše Andy Bierman: > On 06/04/2012 03:44 AM, Jonathan.Hansford@generaldynamics.uk.com wrote: >> Carl, >> >> Your approach may be OK if the products are to be managed by a bespoke >> client. But what is a system comprising many products needs to be >> managed by a single management system? It would be far better not to >> have to worry about specific revisions of imported modules to support >> different products, but to know that, because of the rules relating to >> updating modules, the latest will work fine with all. > > Obviously a single-purpose embedded device is much more > likely to have a single naming authority than a large embedded > system or an open system. > > I didn't say a server must not advertise 2 revisions of a module. > Actually the server should advertise all the modules it uses > directly or indirectly through imports. But why would a server advertise both revisions if, in your words, only legal changes to the module were made. It makes no sense to do this and it's only confusing for the client. I think is unacceptable for a server to send such a hello message as it may lead to a world of pain. > > The YANG module capabilities sent in the NETCONF > attempt to serve 2 functions, neither of which is does all that well: > > 1) schema tree > - each main module name, XML namespace, and revision date > allows the client to identify the module to find (from the local > modules it already knows about). > - If is supported the client can guess .yang, and then .yin, > and get the main module from the server. > - if submodules are used, the client will either have them locally or use > as needed (by parsing all the main modules to find > include-stmts). > Submodules are not advertised in the NETCONF . > > 2) conformance > - the features and deviations are patched into the exact > modules/revisions > the server advertised to determine all the supported data objects > > Both are incomplete, and conflict with each other. Doing (1) correctly > is likely to claim conformance to modules just imported for meta-data, > not objects. > Doing (2) correctly is likely to leave out modules needed to build the > schema tree. > If a hello message is a nondeterministic snapshot of the data model which a server supports then it is useless to a generic client. And if we add not using import by revision to the whole thing.... Consider this: 1. some modules on server use ietf-yang-types 2. a new typedef is added to ietf-yang-types and a new revision is published 3. a new module on server uses the new type 4. server advertises both revisions of ietf-yang-types and all the other modules 5. client decides to load the older revision of the two since import without revision is nondeterministic 6. new module fails client-side validation because a type is undefined And what if the imported module defines a schema tree and both revisions of it are advertised? RCF6020 clearly states in 5.1.2. that top-level nodes of YANG modules are to be encoded as child XML elements in any order within NETCONF payloads. Thus a schema cannot be defined which could be used to validate XML content based on two modules which define the same top-level statements within the same namespace because it cannot be determined which element is to be matched against which YANG module top-level statement. If this is what one might expect then hello messages don't just serve their purpose poorly, they too are broken. What good is a contract between two parties if they can both interpret it the way they please? I think all of this would be fixed if revision-date in import statements would be used as the minimal required version and if servers would only be allowed to advertise a single revision of a module at a time plus some kind of a promise that no two modules are advertised by the server within the same namespace which also define top-level statements named the same way. > >> Jonathan > > Andy > >> > Jernej From mbj@tail-f.com Tue Jun 5 01:31:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD25F21F8701 for ; Tue, 5 Jun 2012 01:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eXpVXjlj3rh for ; Tue, 5 Jun 2012 01:31:47 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4E01221F86FD for ; Tue, 5 Jun 2012 01:31:47 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 5FEDA1200B84; Tue, 5 Jun 2012 10:31:45 +0200 (CEST) Date: Tue, 05 Jun 2012 10:31:44 +0200 (CEST) Message-Id: <20120605.103144.471517364.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si From: Martin Bjorklund In-Reply-To: <4FCDBF46.2080500@mg-soft.com> References: <83C941F7F59F3F42AC017AD1E650546206BFABB5@GDUKADH850.uk1.r-org.net> <4FCCD10B.9040600@netconfcentral.org> <4FCDBF46.2080500@mg-soft.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 08:31:48 -0000 Hi, A server should not advertise a module unless it implements the module's schema tree, rpcs, and notifications (*). There is no reason for advertising a module for its typedefs, groupings etc. Now, suppose module A imports module T, which only contains typedefs. T is imported w/o import-by-revision. The server advertises A. How does the client know which version of T is used by the server? (Note that this is the situation with MIBs). The client can check the /netconf-state/schemas list for the complete list of modules used by the server, including submodules etc and find T. If A imports T by revision, the client knows exactly which version of T A used. (*) Modulo features. You might think that this is a too coarse conformance mechanism. Maybe we need something more fine-grained. But this is really an orthogonal problem. /martin From jernej.tuljak@mg-soft.si Tue Jun 5 02:26:05 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E4C21F86A0 for ; Tue, 5 Jun 2012 02:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KauhkoBWLDLA for ; Tue, 5 Jun 2012 02:26:05 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id F1A1121F869C for ; Tue, 5 Jun 2012 02:26:04 -0700 (PDT) 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 q559Q2AX021826; Tue, 5 Jun 2012 11:26:03 +0200 Message-ID: <4FCDD0A9.1020106@mg-soft.com> Date: Tue, 05 Jun 2012 11:26:01 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <83C941F7F59F3F42AC017AD1E650546206BFABB5@GDUKADH850.uk1.r-org.net> <4FCCD10B.9040600@netconfcentral.org> <4FCDBF46.2080500@mg-soft.com> <20120605.103144.471517364.mbj@tail-f.com> In-Reply-To: <20120605.103144.471517364.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 09:26:06 -0000 Dne 5.6.2012 10:31, piše Martin Bjorklund: > Hi, > > A server should not advertise a module unless it implements the > module's schema tree, rpcs, and notifications (*). There is no reason > for advertising a module for its typedefs, groupings etc. > > Now, suppose module A imports module T, which only contains typedefs. > T is imported w/o import-by-revision. The server advertises A. How > does the client know which version of T is used by the server? (Note > that this is the situation with MIBs). The client can check the > /netconf-state/schemas list for the complete list of modules used by > the server, including submodules etc and find T. > > If A imports T by revision, the client knows exactly which version of > T A used. > > > (*) Modulo features. You might think that this is a too coarse > conformance mechanism. Maybe we need something more fine-grained. > But this is really an orthogonal problem. > > > /martin I think a client should always know exactly what is implemented on a server regardless of whether ietf-netconf-monitoring is implemented on either side. Especially if this has bearing on XML payloads that may be sent between it and the server (and typedefs sure do). One should never assume that clients are to be implemented by the same people who implemented the server nor that the client has a static implementation which was known before hand. For generic clients which must resolve such problems dynamically on the fly - form payloads based on loaded modules - it is vital to know everything AND to be informed properly without confusing information. The current mechanism does not provide this unless certain conditions are met as observed by our examples. As I said before, I wouldn't mind import by minimal revision in a combination with not allowing servers to advertise incompatible schema trees. Why do both confd and netconfd advertise non-schema tree modules such as ietf-inet-types out of the box if there is no reason to do this? :) Jernej From internet-drafts@ietf.org Tue Jun 5 02:49:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAEB21F8711; Tue, 5 Jun 2012 02:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjpMkGX1pajd; Tue, 5 Jun 2012 02:49:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E1E21F86EB; Tue, 5 Jun 2012 02:49:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120605094927.4753.44427.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2012 02:49:27 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 09:49:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : A YANG Data Model for SNMP Configuration Author(s) : Martin Bjorklund Juergen Schoenwaelder Filename : draft-ietf-netmod-snmp-cfg-00.txt Pages : 72 Date : 2012-06-04 This document defines a collection of YANG definitions for configuring SNMP engines. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-snmp-cfg-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-snmp-cfg-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/ From lhotka@nic.cz Tue Jun 5 04:12:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6614121F86C6 for ; Tue, 5 Jun 2012 04:12:17 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6NXFZpkOtew for ; Tue, 5 Jun 2012 04:12:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D804721F86E1 for ; Tue, 5 Jun 2012 04:12:14 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id DEF5D141065 for ; Tue, 5 Jun 2012 13:12:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1338894733; bh=w+Il0GBqT9N5i7sWim3s2g7KERD/jYR2BPK9I3+u6Fo=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=q/D10/WcvFedDZ8ZT7sYcfW0lD0FZY1V40QsdACRAHV/UYsnX8bIkgcizfu7xgaqE y2zSZ/DOZCg7TpawAjQGd2rlaUgfP3N54SBNlaVMZvaX/KTALIOkOQc1cI6T0QZ2IP jbudU7SJ3C8Cf096OMUWMc8iJ9uL8Vnhw+7Ldn0A= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jun 2012 13:12:08 +0200 References: <20120605110606.19150.76771.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: <7E1CAB62-9E7F-48BC-907F-DB6E0A787008@nic.cz> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [netmod] Fwd: New Version Notification for draft-lhotka-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 11:12:17 -0000 Hi, this is a new revision of the JSON mapping draft. The main change is a = more liberal approach to namespaces - an explicit namespace identifier = must be used in JSON only where the local name is ambiguous, which = should hopefully be almost nowhere. Comments are welcome. Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-lhotka-yang-json-01.txt > Date: June 5, 2012 1:06:06 PM GMT+02:00 > To: lhotka@nic.cz >=20 > A new version of I-D, draft-lhotka-yang-json-01.txt has been = successfully submitted by Ladislav Lhotka and posted to the IETF = repository. >=20 > Filename: draft-lhotka-yang-json > Revision: 01 > Title: Modeling JSON Text with YANG > Creation date: 2012-06-05 > WG ID: Individual Submission > Number of pages: 12 >=20 > Abstract: > This document defines rules for mapping data models expressed in = YANG > to configuration and operational state data encoded as JSON text. = It > does so by specifying a procedure for translating the subset of = YANG- > compatible XML documents to JSON text, and vice versa. >=20 >=20 >=20 >=20 > The IETF Secretariat -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jun 5 04:25:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A2221F866A for ; Tue, 5 Jun 2012 04:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p44fNUBPYDXJ for ; Tue, 5 Jun 2012 04:25:34 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B4D1621F866C for ; Tue, 5 Jun 2012 04:25:34 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id B59AF1200AD8; Tue, 5 Jun 2012 13:25:33 +0200 (CEST) Date: Tue, 05 Jun 2012 13:25:33 +0200 (CEST) Message-Id: <20120605.132533.493115426.mbj@tail-f.com> To: jernej.tuljak@mg-soft.si From: Martin Bjorklund In-Reply-To: <4FCDD0A9.1020106@mg-soft.com> References: <4FCDBF46.2080500@mg-soft.com> <20120605.103144.471517364.mbj@tail-f.com> <4FCDD0A9.1020106@mg-soft.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 11:25:35 -0000 Jernej Tuljak wrote: > Dne 5.6.2012 10:31, pi=A8e Martin Bjorklund: > > Hi, > > > > A server should not advertise a module unless it implements the > > module's schema tree, rpcs, and notifications (*). There is no rea= son > > for advertising a module for its typedefs, groupings etc. > > > > Now, suppose module A imports module T, which only contains typedef= s. > > T is imported w/o import-by-revision. The server advertises A. Ho= w > > does the client know which version of T is used by the server? (No= te > > that this is the situation with MIBs). The client can check the > > /netconf-state/schemas list for the complete list of modules used b= y > > the server, including submodules etc and find T. > > > > If A imports T by revision, the client knows exactly which version = of > > T A used. > > > > > > (*) Modulo features. You might think that this is a too coarse > > conformance mechanism. Maybe we need something more fine-grained. > > But this is really an orthogonal problem. > > > > > > /martin > I think a client should always know exactly what is implemented on a = server > regardless of whether ietf-netconf-monitoring is implemented on eithe= r > side. Especially if this has bearing on XML payloads that may be sent= between > it and the server (and typedefs sure do). One should never assume tha= t clients > are to be implemented by the same people who implemented the server n= or that > the client has a static implementation which was known before hand. F= or generic > clients which must resolve such problems dynamically on the fly - for= m payloads > based on loaded modules - it is vital to know everything AND to be in= formed > properly without confusing information. The current mechanism does no= t provide > this unless certain conditions are met as observed by our examples. > = > As I said before, I wouldn't mind import by minimal revision in a com= bination > with not allowing servers to advertise incompatible schema trees. I don't think this solves the problem. If A imports T >=3D rev1 and B imports T >=3D rev2, and A is compiled with T of rev1, and B with T of rev2, which version of T would the server advertise? (ietf-netconf-monitoring doesn't solve this either). In order to handle this, you would either have to advertise the revision of each imported module in each capability: ...?module=3DA&imports=3DT@rev1,U@rev2,... or you would say that the server must "use" exactly one version of each module, so A and B MUST be compiled with the same version of T. But this doesn't work today. > Why do both confd and netconfd advertise non-schema tree modules such= as > ietf-inet-types out of the box if there is no reason to do this? :) Good question! They probably shouldn't. /martin From andy@netconfcentral.org Tue Jun 5 06:00:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C232721F8638 for ; Tue, 5 Jun 2012 06:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VK4pqn0TqjQi for ; Tue, 5 Jun 2012 06:00:29 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 28FA121F8628 for ; Tue, 5 Jun 2012 06:00:28 -0700 (PDT) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q55D0RBx026615 for ; Tue, 5 Jun 2012 09:00:27 -0400 Authentication-Results: cm-omr14 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:47020] helo=[192.168.0.168]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id F5/44-31525-AE20ECF4; Tue, 05 Jun 2012 09:00:27 -0400 Message-ID: <4FCE02E9.3090705@netconfcentral.org> Date: Tue, 05 Jun 2012 06:00:25 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <83C941F7F59F3F42AC017AD1E650546206BFABB5@GDUKADH850.uk1.r-org.net> <4FCCD10B.9040600@netconfcentral.org> <4FCDBF46.2080500@mg-soft.com> <20120605.103144.471517364.mbj@tail-f.com> In-Reply-To: <20120605.103144.471517364.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 13:00:29 -0000 On 06/05/2012 01:31 AM, Martin Bjorklund wrote: > Hi, > > A server should not advertise a module unless it implements the > module's schema tree, rpcs, and notifications (*). There is no reason > for advertising a module for its typedefs, groupings etc. This means the client will not have a complete set of modules used and will not build an accurate schema tree for the server. The reason the advertise the types modules is so the client uses the correct one. Using the wrong grouping, typedef, identity, etc. can have an impact on the user and the network. Andy > Now, suppose module A imports module T, which only contains typedefs. > T is imported w/o import-by-revision. The server advertises A. How > does the client know which version of T is used by the server? (Note > that this is the situation with MIBs). The client can check the > /netconf-state/schemas list for the complete list of modules used by > the server, including submodules etc and find T. > > If A imports T by revision, the client knows exactly which version of > T A used. > > > (*) Modulo features. You might think that this is a too coarse > conformance mechanism. Maybe we need something more fine-grained. > But this is really an orthogonal problem. > > > /martin > > From andy@netconfcentral.org Tue Jun 5 06:18:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7190C21F86AA for ; Tue, 5 Jun 2012 06:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vlcAXoP4E44 for ; Tue, 5 Jun 2012 06:18:35 -0700 (PDT) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC4C21F86A8 for ; Tue, 5 Jun 2012 06:18:35 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q55DIYvY024098 for ; Tue, 5 Jun 2012 09:18:34 -0400 Authentication-Results: cm-omr3 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:47367] helo=[192.168.0.168]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id 4A/A2-14279-A270ECF4; Tue, 05 Jun 2012 09:18:34 -0400 Message-ID: <4FCE0728.6000804@netconfcentral.org> Date: Tue, 05 Jun 2012 06:18:32 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <4FCDBF46.2080500@mg-soft.com> <20120605.103144.471517364.mbj@tail-f.com> <4FCDD0A9.1020106@mg-soft.com> <20120605.132533.493115426.mbj@tail-f.com> In-Reply-To: <20120605.132533.493115426.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 13:18:36 -0000 On 06/05/2012 04:25 AM, Martin Bjorklund wrote: > Jernej Tuljak wrote: >> Dne 5.6.2012 10:31, pi¨e Martin Bjorklund: >>> Hi, >>> >>> A server should not advertise a module unless it implements the >>> module's schema tree, rpcs, and notifications (*). There is no reason >>> for advertising a module for its typedefs, groupings etc. >>> >>> Now, suppose module A imports module T, which only contains typedefs. >>> T is imported w/o import-by-revision. The server advertises A. How >>> does the client know which version of T is used by the server? (Note >>> that this is the situation with MIBs). The client can check the >>> /netconf-state/schemas list for the complete list of modules used by >>> the server, including submodules etc and find T. >>> >>> If A imports T by revision, the client knows exactly which version of >>> T A used. >>> >>> >>> (*) Modulo features. You might think that this is a too coarse >>> conformance mechanism. Maybe we need something more fine-grained. >>> But this is really an orthogonal problem. >>> >>> >>> /martin >> I think a client should always know exactly what is implemented on a server >> regardless of whether ietf-netconf-monitoring is implemented on either >> side. Especially if this has bearing on XML payloads that may be sent between >> it and the server (and typedefs sure do). One should never assume that clients >> are to be implemented by the same people who implemented the server nor that >> the client has a static implementation which was known before hand. For generic >> clients which must resolve such problems dynamically on the fly - form payloads >> based on loaded modules - it is vital to know everything AND to be informed >> properly without confusing information. The current mechanism does not provide >> this unless certain conditions are met as observed by our examples. >> >> As I said before, I wouldn't mind import by minimal revision in a combination >> with not allowing servers to advertise incompatible schema trees. > I don't think this solves the problem. If A imports T>= rev1 and B > imports T>= rev2, and A is compiled with T of rev1, and B with T of > rev2, which version of T would the server advertise? > > (ietf-netconf-monitoring doesn't solve this either). > > In order to handle this, you would either have to advertise the > revision of each imported module in each capability: > > ...?module=A&imports=T@rev1,U@rev2,... > > or you would say that the server must "use" exactly one version of > each module, so A and B MUST be compiled with the same version of T. > > But this doesn't work today. > >> Why do both confd and netconfd advertise non-schema tree modules such as >> ietf-inet-types out of the box if there is no reason to do this? :) What if the foo-types modules changes? What if foo-type is range "1..100" in 1 version and "1..1000" in version 2? Which range is actually used? What if there is another foo-types module that has a different XML namespace? Remember in YANG the module name only needs to be unique within a given server, but XML namespaces are supposed to be globally unique. The server needs to advertise the complete module set so the client doesn't just guess the versions or the namespaces. Note that YANG conformance is completely broken unless import/include by revision is used everywhere OR unless all the revisions of all the modules used is advertised in the . If module A requires the foo-type with range 1..100, and the foo-types module is upgraded for any reason, the conformance will change for module A because now the server is expected to accept 1..1000 (unless import-by-revision is used to force version 1. If module B does not use import-by-revision for foo-types, it will use version 2. This is 1 way the server can advertise both foo-types.1 and foo-types.2. Andy > Good question! They probably shouldn't. > > /martin > > Andy From jernej.tuljak@mg-soft.si Tue Jun 5 07:15:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CB321F8497 for ; Tue, 5 Jun 2012 07:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D070RRpvLfqU for ; Tue, 5 Jun 2012 07:15:05 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF1E21F8450 for ; Tue, 5 Jun 2012 07:15:04 -0700 (PDT) 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 q55EF21U025270; Tue, 5 Jun 2012 16:15:02 +0200 Message-ID: <4FCE1464.1050502@mg-soft.com> Date: Tue, 05 Jun 2012 16:15:00 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <4FCDBF46.2080500@mg-soft.com> <20120605.103144.471517364.mbj@tail-f.com> <4FCDD0A9.1020106@mg-soft.com> <20120605.132533.493115426.mbj@tail-f.com> <4FCE0728.6000804@netconfcentral.org> In-Reply-To: <4FCE0728.6000804@netconfcentral.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 14:15:07 -0000 Dne 5.6.2012 15:18, pi¨e Andy Bierman: > On 06/05/2012 04:25 AM, Martin Bjorklund wrote: >> Jernej Tuljak wrote: >>> Dne 5.6.2012 10:31, pi¨e Martin Bjorklund: >>>> Hi, >>>> >>>> A server should not advertise a module unless it implements the >>>> module's schema tree, rpcs, and notifications (*). There is no reason >>>> for advertising a module for its typedefs, groupings etc. >>>> >>>> Now, suppose module A imports module T, which only contains typedefs. >>>> T is imported w/o import-by-revision. The server advertises A. How >>>> does the client know which version of T is used by the server? (Note >>>> that this is the situation with MIBs). The client can check the >>>> /netconf-state/schemas list for the complete list of modules used by >>>> the server, including submodules etc and find T. >>>> >>>> If A imports T by revision, the client knows exactly which version of >>>> T A used. >>>> >>>> >>>> (*) Modulo features. You might think that this is a too coarse >>>> conformance mechanism. Maybe we need something more fine-grained. >>>> But this is really an orthogonal problem. >>>> >>>> >>>> /martin >>> I think a client should always know exactly what is implemented on a >>> server >>> regardless of whether ietf-netconf-monitoring is implemented on either >>> side. Especially if this has bearing on XML payloads that may be >>> sent between >>> it and the server (and typedefs sure do). One should never assume >>> that clients >>> are to be implemented by the same people who implemented the server >>> nor that >>> the client has a static implementation which was known before hand. >>> For generic >>> clients which must resolve such problems dynamically on the fly - >>> form payloads >>> based on loaded modules - it is vital to know everything AND to be >>> informed >>> properly without confusing information. The current mechanism does >>> not provide >>> this unless certain conditions are met as observed by our examples. >>> >>> As I said before, I wouldn't mind import by minimal revision in a >>> combination >>> with not allowing servers to advertise incompatible schema trees. >> I don't think this solves the problem. If A imports T>= rev1 and B >> imports T>= rev2, and A is compiled with T of rev1, and B with T of >> rev2, which version of T would the server advertise? >> >> (ietf-netconf-monitoring doesn't solve this either). >> >> In order to handle this, you would either have to advertise the >> revision of each imported module in each capability: >> >> ...?module=A&imports=T@rev1,U@rev2,... >> >> or you would say that the server must "use" exactly one version of >> each module, so A and B MUST be compiled with the same version of T. >> >> But this doesn't work today. >> >>> Why do both confd and netconfd advertise non-schema tree modules >>> such as >>> ietf-inet-types out of the box if there is no reason to do this? :) > > > What if the foo-types modules changes? > What if foo-type is range "1..100" in 1 version and "1..1000" > in version 2? Which range is actually used? > > What if there is another foo-types module that has a different XML > namespace? > Remember in YANG the module name only needs to be unique within > a given server, but XML namespaces are supposed to be globally unique. > The server needs to advertise the complete module set so the client > doesn't > just guess the versions or the namespaces. > > Note that YANG conformance is completely broken unless import/include > by revision is used everywhere OR unless all the revisions of all the > modules > used is advertised in the . > > If module A requires the foo-type with range 1..100, and the foo-types > module is upgraded > for any reason, the conformance will change for module A because now > the server is expected to accept 1..1000 (unless import-by-revision is > used > to force version 1. If module B does not use import-by-revision for > foo-types, it will use > version 2. This is 1 way the server can advertise both foo-types.1 > and foo-types.2. > > > Andy > > I agree with Andy that the entire set of modules should be advertised because of the namespace uri. It is however irrelevant to the client if a range of a type changes during a proper module evolution (RFC6020 10.). This is because no matter which foo-types revision is used the client cannot generate an invalid payload based on it. If it believes that a leaf has a a range of 1..100 but the server actually supports a range of 1..1000 then nothing is wrong with that. However if A were to change and require a newly defined typedef which only appears in newer revisions of foo-types it would be a different story. I'm not a server-side guy, but why would anyone bother to maintain code for two different revisions of the same module on a server? Why can't the entire server be re-compiled with newest versions of modules? No change could have been made that would break any of the modules. When I said "prevent server from advertising different revisions of the same module" I actually meant this. Of course combined with import by min revision. I still think a server should never advertise two revisions of the same module. It should not even list such modules in ietf-netconf-monitoring. Perhaps it doesn't matter for non-schema tree modules, but if a module defines a schema tree (top-level schema nodes), bad things are bound to happen when this is done. Jernej > > >> Good question! They probably shouldn't. >> >> /martin >> >> > > Andy From jeffrey.K.lange@ge.com Tue Jun 5 07:41:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41CE21F8680 for ; Tue, 5 Jun 2012 07:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+GqDPU16u0w for ; Tue, 5 Jun 2012 07:41:01 -0700 (PDT) Received: from exprod5og111.obsmtp.com (exprod5og111.obsmtp.com [64.18.0.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED2A21F866C for ; Tue, 5 Jun 2012 07:40:59 -0700 (PDT) Received: from alpmlip14.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob111.postini.com ([64.18.4.12]) with SMTP ID DSNKT84ae8zFg4IbRuXjVAffVbbtSktSmg1/@postini.com; Tue, 05 Jun 2012 07:40:59 PDT Received: from unknown (HELO cinmlef12.e2k.ad.ge.com) ([3.159.213.59]) by alpmlip14.e2k.ad.ge.com with ESMTP; 05 Jun 2012 10:40:57 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef12.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jun 2012 10:40:57 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jun 2012 10:40:57 -0400 Received: from CINMBCNA04.e2k.ad.ge.com (3.159.212.58) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 5 Jun 2012 10:40:56 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA04.e2k.ad.ge.com ([169.254.4.136]) with mapi id 14.02.0283.003; Tue, 5 Jun 2012 10:40:56 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-03.txt Thread-Index: Ac1DJwzMs7rV+LuLTcO2jbf71bFFtg== Date: Tue, 5 Jun 2012 14:40:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2012 14:40:57.0408 (UTC) FILETIME=[37E4E400:01CD4329] Subject: Re: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 14:41:02 -0000 I tried extracting out the iana-if-type.yang from this draft, and I found a= n issue, The newly added vmwareNicTeam enum is missing it's closing curly = brace. Thanks -Jeff Lange -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org Sent: Monday, June 04, 2012 7:03 AM To: i-d-announce@ietf.org Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : IANA Interface Type and Address Family YANG Modules Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-iana-if-type-03.txt Pages : 49 Date : 2012-06-04 This document defines the initial versions of the iana-if-type and iana-afn-safi YANG modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/ _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From andy@netconfcentral.org Tue Jun 5 07:41:10 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C4321F86F7 for ; Tue, 5 Jun 2012 07:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peVgCET896nA for ; Tue, 5 Jun 2012 07:41:09 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8196221F86F3 for ; Tue, 5 Jun 2012 07:41:09 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q55Ef8FI014204 for ; Tue, 5 Jun 2012 10:41:08 -0400 Authentication-Results: cm-omr1 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:49018] helo=[192.168.0.168]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id 5A/0A-06474-38A1ECF4; Tue, 05 Jun 2012 10:41:08 -0400 Message-ID: <4FCE1A82.3000006@netconfcentral.org> Date: Tue, 05 Jun 2012 07:41:06 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jernej Tuljak References: <4FCDBF46.2080500@mg-soft.com> <20120605.103144.471517364.mbj@tail-f.com> <4FCDD0A9.1020106@mg-soft.com> <20120605.132533.493115426.mbj@tail-f.com> <4FCE0728.6000804@netconfcentral.org> <4FCE1464.1050502@mg-soft.com> In-Reply-To: <4FCE1464.1050502@mg-soft.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 14:41:10 -0000 .... > I agree with Andy that the entire set of modules should be advertised because of the namespace uri. It is however irrelevant to the client if a range of a type changes during a proper module > evolution (RFC6020 10.). This is because no matter which foo-types revision is used the client cannot generate an invalid payload based on it. If it believes that a leaf has a a range of 1..100 but > the server actually supports a range of 1..1000 then nothing is wrong with that. > However if A were to change and require a newly defined typedef which only appears in newer revisions of foo-types it would be a different story. > It is not irrelevant in the new-client/old-server scenario. It is not irrelevant to the YANG module designer who wants to specify precise server conformance requirements for interoperability. If a new client (who knows about range 1..1000) receives no advertisement, or incorrect advertisement of the foo-types module version in use, it will send values 101..1000 to the server but this is wrong. 1) the conformance for module "A" (when it was written) was for range 1..100 2) the server will correctly reject the requests for 101..1000 because the range it implements is 1..100 > I'm not a server-side guy, but why would anyone bother to maintain code for two different revisions of the same module on a server? Why can't the entire server be re-compiled with newest versions > of modules? No change could have been made that would break any of the modules. When I said "prevent server from advertising different revisions of the same module" I actually meant this. Of course > combined with import by min revision. What makes you think the constants in the server instrumentation code for module "A" are dynamically derived from YANG modules? > > I still think a server should never advertise two revisions of the same module. It should not even list such modules in ietf-netconf-monitoring. Perhaps it doesn't matter for non-schema tree > modules, but if a module defines a schema tree (top-level schema nodes), bad things are bound to happen when this is done. This scenario can't happen in YANG. Once the module defines node /foo, further attempts to define it will fail. Even top-level uses-stmt for an external grouping is restricted to 1 expansion (or else duplicate node name error). > > Jernej > Andy From internet-drafts@ietf.org Tue Jun 5 09:51:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B4221F8778; Tue, 5 Jun 2012 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfEkcOLwQ96U; Tue, 5 Jun 2012 09:51:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA2421F873E; Tue, 5 Jun 2012 09:51:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120605165129.2101.42628.idtracker@ietfa.amsl.com> Date: Tue, 05 Jun 2012 09:51:29 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 16:51:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : IANA Interface Type and Address Family YANG Modules Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-iana-if-type-04.txt Pages : 49 Date : 2012-06-05 This document defines the initial versions of the iana-if-type and iana-afn-safi YANG modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-iana-if-type-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type/ From mbj@tail-f.com Tue Jun 5 09:52:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F5721F876D for ; Tue, 5 Jun 2012 09:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBMcbm+o+hlh for ; Tue, 5 Jun 2012 09:52:16 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 04CCD21F875A for ; Tue, 5 Jun 2012 09:52:16 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E3181200AD8; Tue, 5 Jun 2012 18:52:14 +0200 (CEST) Date: Tue, 05 Jun 2012 18:52:13 +0200 (CEST) Message-Id: <20120605.185213.317375761.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 16:52:17 -0000 Hi, "Lange, Jeffrey K (GE Energy)" wrote: > I tried extracting out the iana-if-type.yang from this draft, and I found an > issue, The newly added vmwareNicTeam enum is missing it's closing curly brace. Thanks for catching this! I should learn to use the tools properly... I have posted an update. /martin From randy_presuhn@mindspring.com Tue Jun 5 10:44:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F9021F87B8 for ; Tue, 5 Jun 2012 10:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMs-MigmiZZL for ; Tue, 5 Jun 2012 10:44:31 -0700 (PDT) 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 C9C6521F87B1 for ; Tue, 5 Jun 2012 10:44:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=rK39LOtLwdN3WdJpYiaQQJmgra2JqdsIWWUf6EMj+tECF34S2XibTMEiDfWAgvIM; 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.251] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Sbxny-0005KC-BL for netmod@ietf.org; Tue, 05 Jun 2012 13:44:30 -0400 Message-ID: <004001cd4343$47e3e580$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <4FCDBF46.2080500@mg-soft.com><20120605.103144.471517364.mbj@tail-f.com><4FCDD0A9.1020106@mg-soft.com><20120605.132533.493115426.mbj@tail-f.com> <4FCE0728.6000804@netconfcentral.org> Date: Tue, 5 Jun 2012 10:47:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8882951211ce6890f88db687ec92ea8370db923ba10466c4b68350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.101.142.251 Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 17:44:32 -0000 Hi - > From: "Andy Bierman" > To: "Martin Bjorklund" > Cc: > Sent: Tuesday, June 05, 2012 6:18 AM > Subject: Re: [netmod] import by revision ... > The server needs to advertise the complete module set so the client doesn't > just guess the versions or the namespaces. > > Note that YANG conformance is completely broken unless import/include > by revision is used everywhere OR unless all the revisions of all the modules > used is advertised in the . Refer back to Martin's earlier point: the syntax of the advertisement doesn't provide sufficient information. There isn't enough information there to know which versions imported which versions - what is needed is a tree, rather than a list, particularly for typedefs or aspect-oriented designs. In open, multi-vendor, or extensible systems this lack of information might be more of an issue than in single-vendor non-extensible products. Randy From andy@netconfcentral.org Tue Jun 5 19:51:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09AF11E80C9 for ; Tue, 5 Jun 2012 19:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFw-an6v02hr for ; Tue, 5 Jun 2012 19:51:02 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by ietfa.amsl.com (Postfix) with ESMTP id B7CD211E8097 for ; Tue, 5 Jun 2012 19:50:50 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q562onDT030867 for ; Tue, 5 Jun 2012 22:50:49 -0400 Authentication-Results: cm-omr7 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:34759] helo=[192.168.0.168]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id ED/E0-20637-985CECF4; Tue, 05 Jun 2012 22:50:49 -0400 Message-ID: <4FCEC587.5070704@netconfcentral.org> Date: Tue, 05 Jun 2012 19:50:47 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Randy Presuhn References: <4FCDBF46.2080500@mg-soft.com><20120605.103144.471517364.mbj@tail-f.com><4FCDD0A9.1020106@mg-soft.com><20120605.132533.493115426.mbj@tail-f.com> <4FCE0728.6000804@netconfcentral.org> <004001cd4343$47e3e580$6b01a8c0@oemcomputer> In-Reply-To: <004001cd4343$47e3e580$6b01a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 02:51:02 -0000 On 06/05/2012 10:47 AM, Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Martin Bjorklund" >> Cc: >> Sent: Tuesday, June 05, 2012 6:18 AM >> Subject: Re: [netmod] import by revision > ... >> The server needs to advertise the complete module set so the client doesn't >> just guess the versions or the namespaces. >> >> Note that YANG conformance is completely broken unless import/include >> by revision is used everywhere OR unless all the revisions of all the modules >> used is advertised in the. > Refer back to Martin's earlier point: the syntax of the advertisement > doesn't provide sufficient information. There isn't enough information there > to know which versions imported which versions - what is needed is a tree, > rather than a list, particularly for typedefs or aspect-oriented designs. In > open, multi-vendor, or extensible systems this lack of information might > be more of an issue than in single-vendor non-extensible products. You're right. IMO, a real conformance-statement is needed which captures the conformance for a specific version so it cannot be misinterpreted over time, under any circumstances. I guess that would be a dependency tree, i.e., something that can be parsed recursively. Just because module X-1 augments a node in module X, the server may not intend to conform to module X, just X-1. The import is only needed to make augment work. The client needs to import X in order to parse X-1, so the server needs to advertise it. The module designer may need multiple conformance statements, not 1 per module. Anybody who has read the ietf-ipfix-psamp.yang module can appreciate how hard it is to read a module with 3 separate use-cases and 17 optional features. Use cases change over time. Changing/adding more if-feature-stmts is not a good solution. Some dartboard material: module X-1: import X { prefix X; } conformance X-1-sample { revision-date 2012-04-03; use-module X { module-conformance X:X-1-rev1; } // syntax for conformance TBD.... required "/foo-list"; } module X: conformance X-rev1 { revision-date 2012-02-02; // for this version of module X use-module foo-types { // no module-conformance means this conformance to module X // does not require any objects from foo-types. use-revision 2011-04-22; // version must be >= this date } } > Randy Andy From jernej.tuljak@mg-soft.si Wed Jun 6 00:57:35 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4E621F8568 for ; Wed, 6 Jun 2012 00:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1PwscIZp6+UI for ; Wed, 6 Jun 2012 00:57:34 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 516CD21F854A for ; Wed, 6 Jun 2012 00:57:33 -0700 (PDT) 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 q567vVfi002618; Wed, 6 Jun 2012 09:57:31 +0200 Message-ID: <4FCF0D69.5020504@mg-soft.com> Date: Wed, 06 Jun 2012 09:57:29 +0200 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andy Bierman References: <4FCDBF46.2080500@mg-soft.com><20120605.103144.471517364.mbj@tail-f.com><4FCDD0A9.1020106@mg-soft.com><20120605.132533.493115426.mbj@tail-f.com> <4FCE0728.6000804@netconfcentral.org> <004001cd4343$47e3e580$6b01a8c0@oemcomputer> <4FCEC587.5070704@netconfcentral.org> In-Reply-To: <4FCEC587.5070704@netconfcentral.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 07:57:35 -0000 Dne 6.6.2012 4:50, piše Andy Bierman: > On 06/05/2012 10:47 AM, Randy Presuhn wrote: >> Hi - >> >>> From: "Andy Bierman" >>> To: "Martin Bjorklund" >>> Cc: >>> Sent: Tuesday, June 05, 2012 6:18 AM >>> Subject: Re: [netmod] import by revision >> ... >>> The server needs to advertise the complete module set so the client >>> doesn't >>> just guess the versions or the namespaces. >>> >>> Note that YANG conformance is completely broken unless import/include >>> by revision is used everywhere OR unless all the revisions of all >>> the modules >>> used is advertised in the. >> Refer back to Martin's earlier point: the syntax of the advertisement >> doesn't provide sufficient information. There isn't enough >> information there >> to know which versions imported which versions - what is needed is a >> tree, >> rather than a list, particularly for typedefs or aspect-oriented >> designs. In >> open, multi-vendor, or extensible systems this lack of information might >> be more of an issue than in single-vendor non-extensible products. > > You're right. > IMO, a real conformance-statement is needed which captures > the conformance for a specific version so it cannot be misinterpreted > over time, under any circumstances. I guess that would be a dependency > tree, > i.e., something that can be parsed recursively. > > Just because module X-1 augments a node in module X, > the server may not intend to conform to module X, just X-1. > The import is only needed to make augment work. > The client needs to import X in order to parse X-1, so the > server needs to advertise it. > How does a client know when a module was advertised in order for another module to be parsed and not conform to it? I think augmentation is not a good example for this. When a module augments another module the intention of a YANG developer is always to conform to the augmented module (X-1 must conform to X but with some additional nodes). Augmentation represents composition not aggregation (X-1 cannot exist without X). What if X-1 contains a leafref to an augmented node which resides somewhere in the subtree of X for example? If someone wishes to import X-1 just for it's top-level typedefs, groupings, etc. AND at the same time not conform to X however, then this is bad module design. Definitions intended for reuse should always reside inside non-schema tree modules. IMO, forcing this somehow would not be a bad idea. Perhaps by differentiating between "header modules" and "implementation modules" (presence of schema nodes). > The module designer may need multiple conformance statements, > not 1 per module. Anybody who has read the ietf-ipfix-psamp.yang > module can appreciate how hard it is to read a module with 3 separate > use-cases > and 17 optional features. Use cases change over time. Changing/adding > more > if-feature-stmts is not a good solution. > > Some dartboard material: > > module X-1: > > import X { prefix X; } > > conformance X-1-sample { > revision-date 2012-04-03; > use-module X { > module-conformance X:X-1-rev1; > } > > // syntax for conformance TBD.... > required "/foo-list"; > > } > > module X: > > conformance X-rev1 { > revision-date 2012-02-02; // for this version of module X > use-module foo-types { > // no module-conformance means this conformance to module X > // does not require any objects from foo-types. > use-revision 2011-04-22; // version must be >= this date > } > } > The hello message would still need to be adjusted in order for this to work. Modules alone would not contain enough information to determine a list of modules that are actually used by the server (I think). >> Randy > > Andy > Jernej From andy@netconfcentral.org Wed Jun 6 07:25:39 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D43C21F879F for ; Wed, 6 Jun 2012 07:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeUq2NOi-jG9 for ; Wed, 6 Jun 2012 07:25:38 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8E821F8755 for ; Wed, 6 Jun 2012 07:25:38 -0700 (PDT) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q56EPbEM029889 for ; Wed, 6 Jun 2012 10:25:37 -0400 Authentication-Results: cm-omr8 smtp.user=andy@netconfcentral.org; auth=pass (CRAM-MD5) X-Authenticated-UID: andy@netconfcentral.org Received: from [75.84.168.164] ([75.84.168.164:47509] helo=[192.168.0.168]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES256-SHA) id FF/E8-09498-0686FCF4; Wed, 06 Jun 2012 10:25:36 -0400 Message-ID: <4FCF685E.4080204@netconfcentral.org> Date: Wed, 06 Jun 2012 07:25:34 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jernej Tuljak References: <4FCDBF46.2080500@mg-soft.com><20120605.103144.471517364.mbj@tail-f.com><4FCDD0A9.1020106@mg-soft.com><20120605.132533.493115426.mbj@tail-f.com> <4FCE0728.6000804@netconfcentral.org> <004001cd4343$47e3e580$6b01a8c0@oemcomputer> <4FCEC587.5070704@netconfcentral.org> <4FCF0D69.5020504@mg-soft.com> In-Reply-To: <4FCF0D69.5020504@mg-soft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: netmod@ietf.org Subject: Re: [netmod] import by revision X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 14:25:39 -0000 On 06/06/2012 12:57 AM, Jernej Tuljak wrote: > Dne 6.6.2012 4:50, piše Andy Bierman: >> On 06/05/2012 10:47 AM, Randy Presuhn wrote: >>> Hi - >>> >>>> From: "Andy Bierman" >>>> To: "Martin Bjorklund" >>>> Cc: >>>> Sent: Tuesday, June 05, 2012 6:18 AM >>>> Subject: Re: [netmod] import by revision >>> ... >>>> The server needs to advertise the complete module set so the client doesn't >>>> just guess the versions or the namespaces. >>>> >>>> Note that YANG conformance is completely broken unless import/include >>>> by revision is used everywhere OR unless all the revisions of all the modules >>>> used is advertised in the. >>> Refer back to Martin's earlier point: the syntax of the advertisement >>> doesn't provide sufficient information. There isn't enough information there >>> to know which versions imported which versions - what is needed is a tree, >>> rather than a list, particularly for typedefs or aspect-oriented designs. In >>> open, multi-vendor, or extensible systems this lack of information might >>> be more of an issue than in single-vendor non-extensible products. >> >> You're right. >> IMO, a real conformance-statement is needed which captures >> the conformance for a specific version so it cannot be misinterpreted >> over time, under any circumstances. I guess that would be a dependency tree, >> i.e., something that can be parsed recursively. >> >> Just because module X-1 augments a node in module X, >> the server may not intend to conform to module X, just X-1. >> The import is only needed to make augment work. >> The client needs to import X in order to parse X-1, so the >> server needs to advertise it. >> > > How does a client know when a module was advertised in order for another module to be parsed and not conform to it? It doesn't know with the current RFCs. > > I think augmentation is not a good example for this. When a module augments another module the intention of a YANG developer is always to conform to the augmented module (X-1 must conform to X but > with some additional nodes). Augmentation represents composition not aggregation (X-1 cannot exist without X). What if X-1 contains a leafref to an augmented node which resides somewhere in the > subtree of X for example? If someone wishes to import X-1 just for it's top-level typedefs, groupings, etc. AND at the same time not conform to X however, then this is bad module design. > Definitions intended for reuse should always reside inside non-schema tree modules. IMO, forcing this somehow would not be a bad idea. Perhaps by differentiating between "header modules" and > "implementation modules" (presence of schema nodes). The issue is how much of the augmented module must be implemented in order to claim conformance to the augmenting module. The answer "all of it" is too course-grained, like the rest of YANG conformance specification. > >> The module designer may need multiple conformance statements, >> not 1 per module. Anybody who has read the ietf-ipfix-psamp.yang >> module can appreciate how hard it is to read a module with 3 separate use-cases >> and 17 optional features. Use cases change over time. Changing/adding more >> if-feature-stmts is not a good solution. >> >> Some dartboard material: >> >> module X-1: >> >> import X { prefix X; } >> >> conformance X-1-sample { >> revision-date 2012-04-03; >> use-module X { >> module-conformance X:X-1-rev1; >> } >> >> // syntax for conformance TBD.... >> required "/foo-list"; >> >> } >> >> module X: >> >> conformance X-rev1 { >> revision-date 2012-02-02; // for this version of module X >> use-module foo-types { >> // no module-conformance means this conformance to module X >> // does not require any objects from foo-types. >> use-revision 2011-04-22; // version must be >= this date >> } >> } >> > > The hello message would still need to be adjusted in order for this to work. Modules alone would not contain enough information to determine a list of modules that are actually used by the server > (I think). > correct -- advertisement of the module set used by the server and advertisement of the module conformances could be done together: http://example.com/ns/foo?module=foo&revision=2012-06-06&conformance=foo-basic BTW, there is conformance to data types like ietf-yang-types.yang. The typedefs have syntax and some semantics that need to be implemented correctly, just like a list or a leaf. >>> Randy >> >> Andy >> > Jernej > > > Andy From j.schoenwaelder@jacobs-university.de Sun Jun 10 06:48:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4921F85AA for ; Sun, 10 Jun 2012 06:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvFEUIYSt2xg for ; Sun, 10 Jun 2012 06:48:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 993B721F85A3 for ; Sun, 10 Jun 2012 06:48:26 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15A2820BC1; Sun, 10 Jun 2012 15:48:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mr-hKhrrbim9; Sun, 10 Jun 2012 15:48:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A81CF20AFA; Sun, 10 Jun 2012 15:48:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 68A851FBC2DA; Sun, 10 Jun 2012 15:48:25 +0200 (CEST) Date: Sun, 10 Jun 2012 15:48:25 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120610134825.GB60379@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] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 13:48:28 -0000 I have reviewed draft-ietf-netmod-interfaces-cfg-04 and here are my comments/questions. a) p9: s/2011/2012/ b) p15: s/destined to it/it should receive and process/ (twice) interfaces/interface also allows to modify the MTU - so perhaps this needs to be reflected as well, i.e., setting the MTU to a very small value can be used to slow down interfaces. c) p17: Are the references RFC2579, RFC6241, RFC6242 really normative? The routing document I think has RFC6241 and RFC 6242 as informative. Perhaps we should also explicitely refer to RFC6536 or even encourage its implementation. /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 Sun Jun 10 06:49:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE95221F85B7 for ; Sun, 10 Jun 2012 06:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.816 X-Spam-Level: X-Spam-Status: No, score=-102.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4XV1i9cA7xY for ; Sun, 10 Jun 2012 06:49:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEAA21F85A3 for ; Sun, 10 Jun 2012 06:48:54 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01ABD20BC1; Sun, 10 Jun 2012 15:48:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5Paj4-yi3fIj; Sun, 10 Jun 2012 15:48:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92E9820AFA; Sun, 10 Jun 2012 15:48:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8C6681FBC2F8; Sun, 10 Jun 2012 15:48:53 +0200 (CEST) Date: Sun, 10 Jun 2012 15:48:53 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120610134853.GC60379@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] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 13:49:01 -0000 I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my comments/questions. a) p1: I am wondering whether the title is correct. The document really is concerned with the configuration of IP interfaces as far as I understand it. It does not do routing and it also leaves out configuration things such as reassembly timers, default TTLs, etc. So would a more accurate title be "A Yang Data Model for IP Interface Configuration"? And if so, should the module name become ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? b) Should there be an Acknowledgements section? We have quite some decent reviews... c) s/create-temporary-addressed/create-temporary-addresses/ d) p5: The objects ipNetToPhysicalTable and ipAddressStatus are writable in the IP-MIB but do not represent configuration, and are thus not mapped to the YANG module. This seems odd. Static address mappings can typically be configured and some people do this (either for security or performance reasons). As far as I understand things in the Linux world, address mappings seem to be interface specific. e) p6: s/2011/2012/ f) p10: If I do not what autoconf address at all, I have to set all create-* leaves to false? Should there be a global switch? Not sure, just asking... g) p13: Should there be text discussing ipv4/forwarding and ipv6/forwarding? Or the impact of the autoconf knobs? h) p14: Are the references RFC6241, RFC6242 really normative? The routing document I think has RFC6241 and RFC 6242 as informative. Perhaps we should also explicitely refer to RFC6536 or even encourage its implementation. i) Add IPv6 config to the example? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Jun 10 06:49:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE70121F85AA for ; Sun, 10 Jun 2012 06:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIeJwBVH51D3 for ; Sun, 10 Jun 2012 06:49:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1D75A21F85A3 for ; Sun, 10 Jun 2012 06:49:42 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 740D120BC1; Sun, 10 Jun 2012 15:49:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1VaAJyCVCKTS; Sun, 10 Jun 2012 15:49:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15B5D20AFA; Sun, 10 Jun 2012 15:49:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0155E1FBC32D; Sun, 10 Jun 2012 15:49:39 +0200 (CEST) Date: Sun, 10 Jun 2012 15:49:39 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120610134939.GD60379@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] review of draft-ietf-netmod-routing-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 13:49:43 -0000 I have reviewed draft-ietf-netmod-routing-cfg-03 and here are my comments/questions. a) p1: The abstract reads: This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring a routing subsystem. It is therefore expected that this module will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. [...] It is unclear that "this module" in the fourth line refers to. Do you mean "these modules"? Or are you referring only to the core module? In this case, be explicit. b) p3: s/ etc// c) p8: According to the figure, both the outgoing-interface and the next-hop are optional. Is this by intention? d) p10: s/.[YANG-IF]./ [YANG-IF]./ e) p10: Should we not also cover RFC 6106 (DNS Configuration RAs)? f) p14: s/and fit it into/and it has to fit into/ g) p18: s/real route filtering/more flexible route filtering/ h) p19: Is "missing-element" the right error-tag? If a router with the requested name does not exist, then it is not a missing element in the XML sense. Is this perhaps "data-missing"? i) p20: s/also depends on several/also depend on several/ j) p24: I think the note below should be removed. Such a note may make sense where the identity is used but not as part of the identity definition itself. (And I noted that the text where this is used actually says something slightly different.) identity allow-all-route-filter { base route-filter; description "Route filter that permits all routes. Note that use of this filter is equivalent to no filter at all. "; } k) p27: Is it useful to hardwire the router-id to be an IPv4 address? l) p36/p45: The route list is indexed by seqno, which is a "sequential number of the route". What does this mean? Do I have to do a major renumbering just to insert a route? Why not using "dest-prefix next-hop" as a key and eliminating seqno or something like that? m) p40: s/name] "/name]"/ ? n) p41: s/from the interface/to the interface/ ? o) There are these dynamic defaults in the RA config and I am wondering what this really means. Do the defaults change dynamically when I change max-rtr-adv-interval? Or are they calculated only onces? How does this interact with the many ways of dealing with defaults in NETCONF? p) p44: I do not understand how valid-lifetime and preferred-lifetime would work given that implementations may use the value to refer to absolute point in time or a fixed interval. In fact, to configure a fixed point in time, I would prefer to configure a date-and-time value. I think this needs to be broken into separate objects. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Jun 11 04:13:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8CF21F856C for ; Mon, 11 Jun 2012 04:13:19 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYaPdBV366m5 for ; Mon, 11 Jun 2012 04:13:18 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5082221F8569 for ; Mon, 11 Jun 2012 04:13:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 3A13A5402C8; Mon, 11 Jun 2012 13:13:16 +0200 (CEST) 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 iVTzPMgtKHuE; Mon, 11 Jun 2012 13:13:12 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9BA1D540025; Mon, 11 Jun 2012 13:13:11 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20120610134939.GD60379@elstar.local> References: <20120610134939.GD60379@elstar.local> User-Agent: Notmuch/0.12+113~gde05574 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: Juergen Schoenwaelder , netmod@ietf.org Date: Mon, 11 Jun 2012 13:13:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 11:13:19 -0000 Hi Juergen, thanks for the review. My replies are inline. Juergen Schoenwaelder writes: > I have reviewed draft-ietf-netmod-routing-cfg-03 and here are my > comments/questions. > > a) p1: The abstract reads: > > This document contains a specification of three YANG modules. > Together they form the core routing data model which serves as a > framework for configuring a routing subsystem. It is therefore > expected that this module will be augmented by additional YANG > modules defining data models for individual routing protocols and > other related functions. [...] > > It is unclear that "this module" in the fourth line refers to. Do > you mean "these modules"? Or are you referring only to the core > module? In this case, be explicit. It should read "these modules". > > b) p3: s/ etc// Removed. > > c) p8: According to the figure, both the outgoing-interface and the > next-hop are optional. Is this by intention? One of them must be present, or both. So none of them is mandatory, nor is it a choice. Damn, I now realized I had not properly updated the tree in Fig. 1. The "route" subtree should be: +--ro route +--ro outgoing-interface? +--ro source-protocol +--ro age +--ro v4ur:dest-prefix? +--ro v4ur:next-hop? +--ro v6ur:dest-prefix? +--ro v6ur:next-hop? > > d) p10: s/.[YANG-IF]./ [YANG-IF]./ Fixed. > > e) p10: Should we not also cover RFC 6106 (DNS Configuration RAs)? RA-based DNS configuration is optional so I think it needn't be done here. This is different from the basic RAs - RFC 4861 states in sec. 6.2.1: "A router MUST allow for the following conceptual variables to be configured by system management." > > f) p14: s/and fit it into/and it has to fit into/ OK. > > g) p18: s/real route filtering/more flexible route filtering/ Or perhaps "more comprehensive"? > > h) p19: Is "missing-element" the right error-tag? If a router with the > requested name does not exist, then it is not a missing > element in the XML sense. Is this perhaps "data-missing"? I wasn't sure here. So "missing-element" would be used only if an element is missing that is mandatory according to the schema? > > i) p20: s/also depends on several/also depend on several/ Fixed. > > j) p24: I think the note below should be removed. Such a note may make > sense where the identity is used but not as part of the identity > definition itself. (And I noted that the text where this is used > actually says something slightly different.) > > identity allow-all-route-filter { > base route-filter; > description > "Route filter that permits all routes. > > Note that use of this filter is equivalent to no filter at > all. > "; > } I removed the note from the identity description and placed it to the I-D text (sec. 4.5). > > k) p27: Is it useful to hardwire the router-id to be an IPv4 address? I think this is how it currently works - even IPv6 routers use an IPv4 dotted quad notation. Routing protocols that do not want to use this global-id can define a specific id which can be anything. > > l) p36/p45: The route list is indexed by seqno, which is a "sequential > number of the route". What does this mean? Do I have to do > a major renumbering just to insert a route? Why not using > "dest-prefix next-hop" as a key and eliminating seqno or > something like that? It would be too limiting to require that "dest-prefix next-hop" be unique. Thing is, there is no natural key to be used here and the list can be very long. So it could be a royal pain for the client to always have to select a unique key for each entry. A good solution to this problem might be to leave the assignment of the key to the server - and then the sequential numbers can really be sorted in the datastore. It is how it is done in Mikrotik routers and I find it quite handy. Maybe it could become another item in the NETCONF 2.0 wishlist. But for the time being I don't really know how to deal with this issue. Should I change the key type to an opaque string? > > m) p40: s/name] "/name]"/ ? OK. > > n) p41: s/from the interface/to the interface/ ? I took the description verbatim from RFC 4861 so I assume it's correct. It is about RAs sent out of the interface. > > o) There are these dynamic defaults in the RA config and I am > wondering what this really means. Do the defaults change > dynamically when I change max-rtr-adv-interval? Or are they > calculated only onces? How does this interact with the many ways of > dealing with defaults in NETCONF? Again, it's more a question for the authors of RFC 4861, but I assume it means that the default is calculated dynamically each time the particular (missing) value is used. > > p) p44: I do not understand how valid-lifetime and preferred-lifetime > would work given that implementations may use the value to > refer to absolute point in time or a fixed interval. In fact, As I understand it, the meaning for the receiving node is always the same (number of seconds), the two variants differ only in the behaviour of the sending router - in the first case it sends always the same value while in the second case the value in the next RA will be decremented by the amount time elapsed after the preceding RA. > to configure a fixed point in time, I would prefer to > configure a date-and-time value. I think this needs to be > broken into separate objects. No, I think it has to remain in seconds. 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 j.schoenwaelder@jacobs-university.de Mon Jun 11 05:47:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0513921F84AF for ; Mon, 11 Jun 2012 05:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.989 X-Spam-Level: X-Spam-Status: No, score=-102.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us3QjsbIb98d for ; Mon, 11 Jun 2012 05:47:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D13A821F848B for ; Mon, 11 Jun 2012 05:47:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF25320C3C; Mon, 11 Jun 2012 14:47:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u76HK9PJ_XUJ; Mon, 11 Jun 2012 14:47:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B9D220C2B; Mon, 11 Jun 2012 14:47:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 98C681FBE39A; Mon, 11 Jun 2012 14:47:44 +0200 (CEST) Date: Mon, 11 Jun 2012 14:47:43 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120611124743.GA64394@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20120610134939.GD60379@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) Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 12:47:48 -0000 On Mon, Jun 11, 2012 at 01:13:10PM +0200, Ladislav Lhotka wrote: > > e) p10: Should we not also cover RFC 6106 (DNS Configuration RAs)? > > RA-based DNS configuration is optional so I think it needn't be done here. This is different from the basic RAs - RFC 4861 states in sec. 6.2.1: "A router MUST allow for the following conceptual variables to be configured by system management." > OK, this is reasoning. But is it a reasonable thing to do? > > h) p19: Is "missing-element" the right error-tag? If a router with the > > requested name does not exist, then it is not a missing > > element in the XML sense. Is this perhaps "data-missing"? > > I wasn't sure here. So "missing-element" would be used only if an element is missing that is mandatory according to the schema? RFC 6241 error descriptions are not super precise. My reading of error-tag: missing-element error-type: protocol, application error-severity: error error-info: : name of the missing element Description: An expected element is missing. is that we are talking about missing XML element - but then the text just says element. I guess NETCONF implementors should clarify what their use of the error-tags really is. > > l) p36/p45: The route list is indexed by seqno, which is a "sequential > > number of the route". What does this mean? Do I have to do > > a major renumbering just to insert a route? Why not using > > "dest-prefix next-hop" as a key and eliminating seqno or > > something like that? > > It would be too limiting to require that "dest-prefix next-hop" be unique. Thing is, > there is no natural key to be used here and the list can be very long. So it could be a royal pain for the client to always have to select a unique key for each entry. > > A good solution to this problem might be to leave the assignment of the key to the server - and then the sequential numbers can really be sorted in the datastore. It is how it is done in Mikrotik routers and I find it quite handy. Maybe it could become another item in the NETCONF 2.0 wishlist. > > But for the time being I don't really know how to deal with this issue. Should I change the key type to an opaque string? I do not know what the correct answer is. I just found it unclear what the text implies. And I surely do not want to renumber to insert a route. > > o) There are these dynamic defaults in the RA config and I am > > wondering what this really means. Do the defaults change > > dynamically when I change max-rtr-adv-interval? Or are they > > calculated only onces? How does this interact with the many ways of > > dealing with defaults in NETCONF? > > Again, it's more a question for the authors of RFC 4861, but I assume it means that the default is calculated dynamically each time the particular (missing) value is used. > Is used? Anybody here who can clarify the intention of RFC 4861? > > p) p44: I do not understand how valid-lifetime and preferred-lifetime > > would work given that implementations may use the value to > > refer to absolute point in time or a fixed interval. In fact, > > As I understand it, the meaning for the receiving node is always the same (number of seconds), the two variants differ only in the behaviour of the sending router - in the first case it sends always the same value while in the second case the value in the next RA will be decremented by the amount time elapsed after the preceding RA. I understand that but the point is that a single number is not telling you whether its behaviour A or B. > > to configure a fixed point in time, I would prefer to > > configure a date-and-time value. I think this needs to be > > broken into separate objects. > > No, I think it has to remain in seconds. If the intention is that the RA is valid until say 6pm today, does it really make sense to calculate the seconds until 6pm at the time the edit-config is sent to the box? I doubt it. I would prefer to configure the date, that is 2012-06-11T18:00+0100 and let the box calculate the number of seconds. This is much more robust. /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 Jun 11 06:48:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C918F21F85A1 for ; Mon, 11 Jun 2012 06:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r25AA9oCLLiV for ; Mon, 11 Jun 2012 06:48:47 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4622021F859E for ; Mon, 11 Jun 2012 06:48:47 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8D2371200CF2; Mon, 11 Jun 2012 15:48:46 +0200 (CEST) Date: Mon, 11 Jun 2012 15:48:46 +0200 (CEST) Message-Id: <20120611.154846.863925517358651472.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120610134825.GB60379@elstar.local> References: <20120610134825.GB60379@elstar.local> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 13:48:47 -0000 Juergen Schoenwaelder wrote: > I have reviewed draft-ietf-netmod-interfaces-cfg-04 and here are my > comments/questions. > > a) p9: s/2011/2012/ Ok. > b) p15: s/destined to it/it should receive and process/ (twice) > > interfaces/interface also allows to modify the MTU - so perhaps > this needs to be reflected as well, i.e., setting the MTU to a very > small value can be used to slow down interfaces. Ok. > c) p17: Are the references RFC2579, RFC6241, RFC6242 really normative? > The routing document I think has RFC6241 and RFC 6242 as > informative. No, fixed. > Perhaps we should also explicitely refer to > RFC6536 or even encourage its implementation. This seems like a good idea. But we should probably update the Security Sections Template with this reference. RFC 6087 has a link to the template, but apparently this link is now broken :( http://www.ops.ietf.org/netconf/yang-security-considerations.txt /martin From lhotka@nic.cz Mon Jun 11 07:07:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1578221F8460 for ; Mon, 11 Jun 2012 07:07:37 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95pKvRL5ykIs for ; Mon, 11 Jun 2012 07:07:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC4421F845E for ; Mon, 11 Jun 2012 07:07:35 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id C52DD141281; Mon, 11 Jun 2012 16:07:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339423654; bh=slAroDDqjZriq1RznRxIOv59Wiv9k8ZMQEqXWGSn3aw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=wSG1Qc2ENF9engaQckRSZ2LtLwPl+c/tYQdSMreilSvjvhcATaIEoyqmU8+0ZnjEH o9oRcRVf/A4cjVVlqSY3rVBEft0uY8Uk++25v9KAutJHgwInJEXLONTMXBj3S31lqY mwplsj4zWC5lUt/3QuXeAHIT/02lUOCeP5v5D0As= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120611124743.GA64394@elstar.local> Date: Mon, 11 Jun 2012 16:07:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120610134939.GD60379@elstar.local> <20120611124743.GA64394@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 14:07:37 -0000 On Jun 11, 2012, at 2:47 PM, Juergen Schoenwaelder wrote: > On Mon, Jun 11, 2012 at 01:13:10PM +0200, Ladislav Lhotka wrote: >=20 >>> e) p10: Should we not also cover RFC 6106 (DNS Configuration RAs)? >>=20 >> RA-based DNS configuration is optional so I think it needn't be done = here. This is different from the basic RAs - RFC 4861 states in sec. = 6.2.1: "A router MUST allow for the following conceptual variables to be = configured by system management." >>=20 >=20 > OK, this is reasoning. But is it a reasonable thing to do? Yes, I think it is reasonable to set the boundary for the core routing = model between MUST and SHOULD because otherwise there would be other = candidates for inclusion, e.g. IPSec. >=20 >>> h) p19: Is "missing-element" the right error-tag? If a router with = the >>> requested name does not exist, then it is not a missing >>> element in the XML sense. Is this perhaps "data-missing"? >>=20 >> I wasn't sure here. So "missing-element" would be used only if an = element is missing that is mandatory according to the schema? >=20 > RFC 6241 error descriptions are not super precise. My reading of >=20 > error-tag: missing-element > error-type: protocol, application > error-severity: error > error-info: : name of the missing element > Description: An expected element is missing. >=20 > is that we are talking about missing XML element - but then the text > just says element. I guess NETCONF implementors should clarify what > their use of the error-tags really is. Agreed. Is the general feeling that "data-missing" is better for this = case than "missing-element"? >=20 >>> l) p36/p45: The route list is indexed by seqno, which is a = "sequential >>> number of the route". What does this mean? Do I have to = do >>> a major renumbering just to insert a route? Why not using >>> "dest-prefix next-hop" as a key and eliminating seqno or >>> something like that? >>=20 >> It would be too limiting to require that "dest-prefix next-hop" be = unique. Thing is,=20 >> there is no natural key to be used here and the list can be very = long. So it could be a royal pain for the client to always have to = select a unique key for each entry. >>=20 >> A good solution to this problem might be to leave the assignment of = the key to the server - and then the sequential numbers can really be = sorted in the datastore. It is how it is done in Mikrotik routers and I = find it quite handy. Maybe it could become another item in the NETCONF = 2.0 wishlist. >>=20 >> But for the time being I don't really know how to deal with this = issue. Should I change the key type to an opaque string? >=20 > I do not know what the correct answer is. I just found it unclear what > the text implies. And I surely do not want to renumber to insert a > route. Sure, this was not intended although the description ("sequential") = seems to indicate so. Would "number of the route" be any better? >=20 >>> o) There are these dynamic defaults in the RA config and I am >>> wondering what this really means. Do the defaults change >>> dynamically when I change max-rtr-adv-interval? Or are they >>> calculated only onces? How does this interact with the many ways = of >>> dealing with defaults in NETCONF? >>=20 >> Again, it's more a question for the authors of RFC 4861, but I assume = it means that the default is calculated dynamically each time the = particular (missing) value is used. >>=20 >=20 > Is used? Anybody here who can clarify the intention of RFC 4861? The text describing these parameters in 4861 is IMO quite sloppy, and I = have already submitted an erratum. >=20 >>> p) p44: I do not understand how valid-lifetime and = preferred-lifetime >>> would work given that implementations may use the value to >>> refer to absolute point in time or a fixed interval. In fact, >>=20 >> As I understand it, the meaning for the receiving node is always the = same (number of seconds), the two variants differ only in the behaviour = of the sending router - in the first case it sends always the same value = while in the second case the value in the next RA will be decremented by = the amount time elapsed after the preceding RA. >=20 > I understand that but the point is that a single number is not telling > you whether its behaviour A or B. >=20 >>> to configure a fixed point in time, I would prefer to >>> configure a date-and-time value. I think this needs to be >>> broken into separate objects. >>=20 >> No, I think it has to remain in seconds. >=20 > If the intention is that the RA is valid until say 6pm today, does it > really make sense to calculate the seconds until 6pm at the time the > edit-config is sent to the box? I doubt it. I would prefer to > configure the date, that is 2012-06-11T18:00+0100 and let the box > calculate the number of seconds. This is much more robust. The option of a constant lifetime (in seconds) must remain available, so = it would require either a "union" type for these leafs (which I don't = like at all) or a choice between two alternative leafs. At any rate, all three implementations I am using as a reference (IOS, = JUNOS and BIRD) have the lifetimes expressed as a number of seconds in = their configurations, and implement (I think) only the constant values. 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 j.schoenwaelder@jacobs-university.de Mon Jun 11 08:17:36 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C8121F84A0 for ; Mon, 11 Jun 2012 08:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.032 X-Spam-Level: X-Spam-Status: No, score=-103.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dw-nhJ0bfOw for ; Mon, 11 Jun 2012 08:17:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 10A7921F849A for ; Mon, 11 Jun 2012 08:17:36 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 643E220C19; Mon, 11 Jun 2012 17:17:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Y6GzT-KiiLQq; Mon, 11 Jun 2012 17:17:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02BA320C15; Mon, 11 Jun 2012 17:17:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2A8001FBEBF4; Mon, 11 Jun 2012 17:17:33 +0200 (CEST) Date: Mon, 11 Jun 2012 17:17:33 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120611151733.GA65070@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20120610134939.GD60379@elstar.local> <20120611124743.GA64394@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] review of draft-ietf-netmod-routing-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:17:37 -0000 On Mon, Jun 11, 2012 at 04:07:34PM +0200, Ladislav Lhotka wrote: > > If the intention is that the RA is valid until say 6pm today, does it > > really make sense to calculate the seconds until 6pm at the time the > > edit-config is sent to the box? I doubt it. I would prefer to > > configure the date, that is 2012-06-11T18:00+0100 and let the box > > calculate the number of seconds. This is much more robust. > > The option of a constant lifetime (in seconds) must remain available, so it would require either a "union" type for these leafs (which I don't like at all) or a choice between two alternative leafs. > > At any rate, all three implementations I am using as a reference (IOS, JUNOS and BIRD) have the lifetimes expressed as a number of seconds in their configurations, and implement (I think) only the constant values. > I personally do not mind to support only the relative time interval. But in any case, it simply needs to be clear what the configured number means. /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 Jun 11 08:27:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB91921F8501 for ; Mon, 11 Jun 2012 08:27:34 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DomxwqE3Vagv for ; Mon, 11 Jun 2012 08:27:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 15B5821F84FB for ; Mon, 11 Jun 2012 08:27:34 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 49C3E141281; Mon, 11 Jun 2012 17:27:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339428453; bh=sv+gqITO12hd1BGw5naJqJGAoWjqBzJpykPwwr5uMw4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oCF2Zn3Lowet6IU1/d2y8i37dwCzGt4pvmzyXrK7MGCziArwQqNRcOirusUWxhGoq ymbKPwyGjfFgkD3CY3WwFGk3KbkOnzkISvRlSCGriNXI3pF5Iih5AHXuC4D3pdd94T sdcRo5fjRDulCFj8PsUY96PvuzGucKSTIyxY+tq0= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120611151733.GA65070@elstar.local> Date: Mon, 11 Jun 2012 17:27:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09DFE953-64E7-42C8-A64F-BCE2ED378EED@nic.cz> References: <20120610134939.GD60379@elstar.local> <20120611124743.GA64394@elstar.local> <20120611151733.GA65070@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:27:35 -0000 On Jun 11, 2012, at 5:17 PM, Juergen Schoenwaelder wrote: > On Mon, Jun 11, 2012 at 04:07:34PM +0200, Ladislav Lhotka wrote: >=20 >>> If the intention is that the RA is valid until say 6pm today, does = it >>> really make sense to calculate the seconds until 6pm at the time the >>> edit-config is sent to the box? I doubt it. I would prefer to >>> configure the date, that is 2012-06-11T18:00+0100 and let the box >>> calculate the number of seconds. This is much more robust. >>=20 >> The option of a constant lifetime (in seconds) must remain available, = so it would require either a "union" type for these leafs (which I don't = like at all) or a choice between two alternative leafs. >>=20 >> At any rate, all three implementations I am using as a reference = (IOS, JUNOS and BIRD) have the lifetimes expressed as a number of = seconds in their configurations, and implement (I think) only the = constant values. >>=20 >=20 > I personally do not mind to support only the relative time > interval. But in any case, it simply needs to be clear what the > configured number means. An option could be to add a boolean switch for configuring the = behaviour, with a default meaning the fixed lifetime. 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 Jun 11 08:30:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4017121F8658 for ; Mon, 11 Jun 2012 08:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXvmx1DUyp4M for ; Mon, 11 Jun 2012 08:30:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6517121F8657 for ; Mon, 11 Jun 2012 08:30:20 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B902C20C00; Mon, 11 Jun 2012 17:30:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NywkxD7yuHfU; Mon, 11 Jun 2012 17:30:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54EDE20BFE; Mon, 11 Jun 2012 17:30:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8A3EB1FBECFF; Mon, 11 Jun 2012 17:30:18 +0200 (CEST) Date: Mon, 11 Jun 2012 17:30:18 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120611153017.GA65184@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20120610134939.GD60379@elstar.local> <20120611124743.GA64394@elstar.local> <20120611151733.GA65070@elstar.local> <09DFE953-64E7-42C8-A64F-BCE2ED378EED@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09DFE953-64E7-42C8-A64F-BCE2ED378EED@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:30:21 -0000 On Mon, Jun 11, 2012 at 05:27:32PM +0200, Ladislav Lhotka wrote: > > On Jun 11, 2012, at 5:17 PM, Juergen Schoenwaelder wrote: > > > On Mon, Jun 11, 2012 at 04:07:34PM +0200, Ladislav Lhotka wrote: > > > >>> If the intention is that the RA is valid until say 6pm today, does it > >>> really make sense to calculate the seconds until 6pm at the time the > >>> edit-config is sent to the box? I doubt it. I would prefer to > >>> configure the date, that is 2012-06-11T18:00+0100 and let the box > >>> calculate the number of seconds. This is much more robust. > >> > >> The option of a constant lifetime (in seconds) must remain available, so it would require either a "union" type for these leafs (which I don't like at all) or a choice between two alternative leafs. > >> > >> At any rate, all three implementations I am using as a reference (IOS, JUNOS and BIRD) have the lifetimes expressed as a number of seconds in their configurations, and implement (I think) only the constant values. > >> > > > > I personally do not mind to support only the relative time > > interval. But in any case, it simply needs to be clear what the > > configured number means. > > An option could be to add a boolean switch for configuring the behaviour, with a default meaning the fixed lifetime. > But having the seconds in config is IMHO broken if we talk about an absolute time stamp. Is this number constantly changing? What happens if I reload a configuration? If we do this, I think we need to do it properly. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Jun 11 08:43:20 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7605B21F85AF for ; Mon, 11 Jun 2012 08:43:20 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4m0ns63Jm01 for ; Mon, 11 Jun 2012 08:43:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC9B21F847F for ; Mon, 11 Jun 2012 08:43:19 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id D2E89141281; Mon, 11 Jun 2012 17:43:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339429398; bh=7e06oi05xgs7dgoIBmpQCrAfi0jJQui1I5NcCqCi2Y0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kG44WTGlf6ZG2JdVKgnoqAFhz4uA2HEYmQzxwoLMVzT3VikwS2c53LIMdCkSfuHPz VkAF5wDxEyYFoHSMLhqg0xVOZpxc6nSbsKy8LBmKz3F/31ep2je8nMgQ/CZVm2OjQ9 +/7C6pINchvsrmfiIIB6W0ckJy0T/VAtm7WJE0DI= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120611153017.GA65184@elstar.local> Date: Mon, 11 Jun 2012 17:43:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120610134939.GD60379@elstar.local> <20120611124743.GA64394@elstar.local> <20120611151733.GA65070@elstar.local> <09DFE953-64E7-42C8-A64F-BCE2ED378EED@nic.cz> <20120611153017.GA65184@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:43:20 -0000 On Jun 11, 2012, at 5:30 PM, Juergen Schoenwaelder wrote: > On Mon, Jun 11, 2012 at 05:27:32PM +0200, Ladislav Lhotka wrote: >>=20 >> On Jun 11, 2012, at 5:17 PM, Juergen Schoenwaelder wrote: >>=20 >>> On Mon, Jun 11, 2012 at 04:07:34PM +0200, Ladislav Lhotka wrote: >>>=20 >>>>> If the intention is that the RA is valid until say 6pm today, does = it >>>>> really make sense to calculate the seconds until 6pm at the time = the >>>>> edit-config is sent to the box? I doubt it. I would prefer to >>>>> configure the date, that is 2012-06-11T18:00+0100 and let the box >>>>> calculate the number of seconds. This is much more robust. >>>>=20 >>>> The option of a constant lifetime (in seconds) must remain = available, so it would require either a "union" type for these leafs = (which I don't like at all) or a choice between two alternative leafs. >>>>=20 >>>> At any rate, all three implementations I am using as a reference = (IOS, JUNOS and BIRD) have the lifetimes expressed as a number of = seconds in their configurations, and implement (I think) only the = constant values. >>>>=20 >>>=20 >>> I personally do not mind to support only the relative time >>> interval. But in any case, it simply needs to be clear what the >>> configured number means. >>=20 >> An option could be to add a boolean switch for configuring the = behaviour, with a default meaning the fixed lifetime. >>=20 >=20 > But having the seconds in config is IMHO broken if we talk about an > absolute time stamp. Is this number constantly changing? What happens > if I reload a configuration? If we do this, I think we need to do it > properly. 1. The router reads the configured value in seconds at startup or when = the configuration changes, and then decrements it in real time in the = consecutive RAs. 2. The router used the same (configured) value in consecutive RAs. If a configuration is reloaded, scenario 1 will start from the original = (higher) value. I guess it is just another manifestation of the = difference between configuration and operational parameters. 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 Jun 11 08:51:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638C121F8555 for ; Mon, 11 Jun 2012 08:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.087 X-Spam-Level: X-Spam-Status: No, score=-103.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VfcbweJdokG for ; Mon, 11 Jun 2012 08:51:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EA03A21F847F for ; Mon, 11 Jun 2012 08:51:41 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4BEBC206D7; Mon, 11 Jun 2012 17:51:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TcpGNCF11Wli; Mon, 11 Jun 2012 17:51:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9AA820BFE; Mon, 11 Jun 2012 17:51:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E632A1FBEE29; Mon, 11 Jun 2012 17:51:39 +0200 (CEST) Date: Mon, 11 Jun 2012 17:51:39 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120611155139.GA65256@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20120610134939.GD60379@elstar.local> <20120611124743.GA64394@elstar.local> <20120611151733.GA65070@elstar.local> <09DFE953-64E7-42C8-A64F-BCE2ED378EED@nic.cz> <20120611153017.GA65184@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] review of draft-ietf-netmod-routing-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:51:43 -0000 On Mon, Jun 11, 2012 at 05:43:18PM +0200, Ladislav Lhotka wrote: > > On Jun 11, 2012, at 5:30 PM, Juergen Schoenwaelder wrote: > > > On Mon, Jun 11, 2012 at 05:27:32PM +0200, Ladislav Lhotka wrote: > >> > >> On Jun 11, 2012, at 5:17 PM, Juergen Schoenwaelder wrote: > >> > >>> On Mon, Jun 11, 2012 at 04:07:34PM +0200, Ladislav Lhotka wrote: > >>> > >>>>> If the intention is that the RA is valid until say 6pm today, does it > >>>>> really make sense to calculate the seconds until 6pm at the time the > >>>>> edit-config is sent to the box? I doubt it. I would prefer to > >>>>> configure the date, that is 2012-06-11T18:00+0100 and let the box > >>>>> calculate the number of seconds. This is much more robust. > >>>> > >>>> The option of a constant lifetime (in seconds) must remain available, so it would require either a "union" type for these leafs (which I don't like at all) or a choice between two alternative leafs. > >>>> > >>>> At any rate, all three implementations I am using as a reference (IOS, JUNOS and BIRD) have the lifetimes expressed as a number of seconds in their configurations, and implement (I think) only the constant values. > >>>> > >>> > >>> I personally do not mind to support only the relative time > >>> interval. But in any case, it simply needs to be clear what the > >>> configured number means. > >> > >> An option could be to add a boolean switch for configuring the behaviour, with a default meaning the fixed lifetime. > >> > > > > But having the seconds in config is IMHO broken if we talk about an > > absolute time stamp. Is this number constantly changing? What happens > > if I reload a configuration? If we do this, I think we need to do it > > properly. > > 1. The router reads the configured value in seconds at startup or when the configuration changes, and then decrements it in real time in the consecutive RAs. > > 2. The router used the same (configured) value in consecutive RAs. > > If a configuration is reloaded, scenario 1 will start from the original (higher) value. I guess it is just another manifestation of the difference between configuration and operational parameters. > If option 1. is as you describe, then I tend to conclude that option 1. does operationally not make much sense (and perhaps this is why it is not commonly implemented). /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 Jun 11 14:07:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B5921F8595 for ; Mon, 11 Jun 2012 14:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXdZk4B9QF4k for ; Mon, 11 Jun 2012 14:07:08 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id DCB5A21F858D for ; Mon, 11 Jun 2012 14:07:06 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 023061200D46; Mon, 11 Jun 2012 23:07:04 +0200 (CEST) Date: Mon, 11 Jun 2012 23:07:04 +0200 (CEST) Message-Id: <20120611.230704.439935195.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120611124743.GA64394@elstar.local> References: <20120610134939.GD60379@elstar.local> <20120611124743.GA64394@elstar.local> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 21:07:08 -0000 Juergen Schoenwaelder wrote: > On Mon, Jun 11, 2012 at 01:13:10PM +0200, Ladislav Lhotka wrote: > > > h) p19: Is "missing-element" the right error-tag? If a router with the > > > requested name does not exist, then it is not a missing > > > element in the XML sense. Is this perhaps "data-missing"? > > > > I wasn't sure here. So "missing-element" would be used only if an element is > > missing that is mandatory according to the schema? > > RFC 6241 error descriptions are not super precise. My reading of > > error-tag: missing-element > error-type: protocol, application > error-severity: error > error-info: : name of the missing element > Description: An expected element is missing. > > is that we are talking about missing XML element - but then the text > just says element. I guess NETCONF implementors should clarify what > their use of the error-tags really is. We use 'missing-element' for missing XML elements. 6241 uses the term 'element' for XML elements (almost consistently :) The descripton for "data-missing" is: Description: Request could not be completed because the relevant data model content does not exist. For example, a "delete" operation was attempted on data that does not exist. So in this case the error-tag should be "data-missing". > > > l) p36/p45: The route list is indexed by seqno, which is a "sequential > > > number of the route". What does this mean? Do I have to do > > > a major renumbering just to insert a route? Why not using > > > "dest-prefix next-hop" as a key and eliminating seqno or > > > something like that? > > > > It would be too limiting to require that "dest-prefix next-hop" be > > unique. Why is this too limiting? > > there is no natural key to be used here and the list can be very long. So it > > could be a royal pain for the client to always have to select a unique key > > for each entry. > > > > A good solution to this problem might be to leave the assignment of the key > > to the server - and then the sequential numbers can really be sorted in the > > datastore. It is how it is done in Mikrotik routers and I find it quite > > handy. Maybe it could become another item in the NETCONF 2.0 wishlist. I think Andy described the problem with this approach for NETCONF that there is no way for the server to tell the client what the newly assigned index is. > > But for the time being I don't really know how to deal with this > > issue. Should I change the key type to an opaque string? Currently this list is ordered-by user, and has a key which is described as being the "sequentional number", which seems a bit confusing. An opaque string is imo better. /martin From alex@cisco.com Mon Jun 11 16:59:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2822221F8514 for ; Mon, 11 Jun 2012 16:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2J55y1fJofV for ; Mon, 11 Jun 2012 16:59:33 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id EC3FE21F8513 for ; Mon, 11 Jun 2012 16:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=3941; q=dns/txt; s=iport; t=1339459173; x=1340668773; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=EJi0OBRwD1dErI+Ak6MieeRAL7CPaI57XLB9SgGpUYU=; b=IxTnzsH+zmjzUhGr66/3010DfSixQyD4VsmyrNDoQMaoSF7lXaoQy0M5 qvrzKv8e/Vov0OEMLjchs1HApVMWBi8rp0mM74qgKoaXiyu/RkGnz2P1P pSy3lAX0gVIQ3jDpDzS1L8endCVr3vAMes6kHDLESDVQT5eXQ5cnhLOIL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANiF1k+Q/khN/2dsb2JhbABFtRiBB4IYAQEBAwEBAQEPAR0KNAsFBwQCAQgOAgEEAQEBCgYXAQYBJh8JCAEBBAESCBqHZAULmQmfc4skhTFgA4hAmnOBZoMAgTgj X-IronPort-AV: E=Sophos;i="4.75,752,1330905600"; d="scan'208";a="5661089" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-3.cisco.com with ESMTP; 11 Jun 2012 23:59:31 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5BNweeE020561; Mon, 11 Jun 2012 23:59:31 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jun 2012 16:59:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jun 2012 16:59:26 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790BBDE98A@xmb-sjc-239.amer.cisco.com> In-Reply-To: <20120611.154846.863925517358651472.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 Thread-Index: Ac1H2O8f9U/NhuoeRNS1ol4hdlO3zwAUfLNQ References: <20120610134825.GB60379@elstar.local> <20120611.154846.863925517358651472.mbj@tail-f.com> From: "Alexander Clemm (alex)" To: "Martin Bjorklund" , X-OriginalArrivalTime: 11 Jun 2012 23:59:27.0531 (UTC) FILETIME=[3BF65FB0:01CD482E] Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 23:59:34 -0000 Hello Martin, I have reviewed the draft as well, here are my comments p5 - location leaf is optional but mandatory in case the type represents a physical interface. This is not reflected in the YANG module. For consistency reasons, it seems that if it is supposed to be mandatory, this needs to be added in the YANG module, which may however become overly complex in turn. Alternatively, remove this condition. =20 p7 - ifPromiscuousode not mapped because not a configuration object. Agree with this in spirit, but neither is ifIndex, yet it is included. It might be good to add a comment why to keep ifIndex (important for mappings, want it persisted between reboots, etc etc)=20 p10 - leaf name "A device MAY restrict the allowed values for this leaf...." It would be good to provide a section that provides clear instructions/ recommendations how to provide such restrictions. (An implementation will have to be clear on what those restrictions are, as ultimately they will need to be validated.) Section 3.1 could be expanded for this purpose, which already talks about how to augment this for interface type specific data. =20 p10 - leaf description "This leaf MAY be mapped to ifAlias..." Similar comment - if an implementation restricts the values, where is this specified. Since this is more a binary choice - either it maps to ifAlias or it doesn't - it seems this should be supported in the model itself, perhaps using the feature construct. =20 p10 - leaf type: If the value of this leaf can be derived from the name, does this need to be mandatory? Or rather, does this not introduce another integrity constraint or depend on device feature (the ability to derive the type from the interface name)? =20 p11 - leaf enabled: Why not simply call the leaf adminStatus? Seems a little clearer. Of course, then it can no longer be simply be a Boolean; however, the term "enabled" appears more like a concept of an operational state to me. =20 As a side note, if the purpose of this is to turn on or off an interface, have you considered defining this as an RPC? This might come in handy also in light of the Netconf-light discussions. If all that a device supports is a copy-config in its entirety, you would need to replace the entire configuration whenever you want to enable or disable a single interface. Arguably, this could simply be defined as its own operation instead. --- Alex -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Monday, June 11, 2012 6:49 AM To: j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 Juergen Schoenwaelder wrote: > I have reviewed draft-ietf-netmod-interfaces-cfg-04 and here are my > comments/questions. >=20 > a) p9: s/2011/2012/ Ok. > b) p15: s/destined to it/it should receive and process/ (twice) >=20 > interfaces/interface also allows to modify the MTU - so perhaps > this needs to be reflected as well, i.e., setting the MTU to a very > small value can be used to slow down interfaces. Ok. > c) p17: Are the references RFC2579, RFC6241, RFC6242 really normative? > The routing document I think has RFC6241 and RFC 6242 as > informative. No, fixed. > Perhaps we should also explicitely refer to > RFC6536 or even encourage its implementation. This seems like a good idea. But we should probably update the Security Sections Template with this reference. RFC 6087 has a link to the template, but apparently this link is now broken :( http://www.ops.ietf.org/netconf/yang-security-considerations.txt /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From alex@cisco.com Mon Jun 11 17:30:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753BA21F852A for ; Mon, 11 Jun 2012 17:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bk6AeFNI660X for ; Mon, 11 Jun 2012 17:30:18 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C17B521F849A for ; Mon, 11 Jun 2012 17:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=3049; q=dns/txt; s=iport; t=1339461018; x=1340670618; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=EZ9oxIvuKm0NrjHIXTUZagdpn1ftSLBSHJG80V9t7kQ=; b=FtTv55XVMSJMHrWzl09nZsvIyY0UYATZAMJo5NbhemqeCKnKAXP4PogG E8ZVron0RXxtc0dJMmOx8GNnmiR+ScvaQbq2XHA2nWzOaE8ULOr6LlROJ bmJ/EflvphtbVxUm7UN88ZYN0G9XI8Zkzhmzz375yMbafvAapgmKO4/e6 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAI2M1k+rRDoH/2dsb2JhbABCA7UYgQeCGAEBAQQBAQEPAR0KNBcCAgIBCBABBAEBCwYXAQYBGgwfCQgBAQQTCBqHaAELmRyfdQSLIIJxBYI7YAOIQJpzgWaDAIE2Iw X-IronPort-AV: E=Sophos;i="4.75,752,1330905600"; d="scan'208";a="45442900" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 12 Jun 2012 00:30:18 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5C0UIWY008232 for ; Tue, 12 Jun 2012 00:30:18 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Jun 2012 17:30:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jun 2012 17:30:17 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790BBDE99E@xmb-sjc-239.amer.cisco.com> In-Reply-To: <20120610134853.GC60379@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] review of draft-ietf-netmod-ip-cfg-03 Thread-Index: Ac1HD80qCn5ef6fZSJ6Y8V+wj4hR+QBISwug References: <20120610134853.GC60379@elstar.local> From: "Alexander Clemm (alex)" To: X-OriginalArrivalTime: 12 Jun 2012 00:30:18.0343 (UTC) FILETIME=[8B21DF70:01CD4832] Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 00:30:19 -0000 I have also reviewed the draft and just a few questions/comments: p6 leaf enabled: I am not entirely clear about the semantics of this leaf. What happens if enabled is set to "false" - is this equivalent to the entire container being absent? =20 Another way of phrasing this is, why is this leaf required at all - why not simply make container ipv4 a presence container - if it is present, ipv4 is enabled, if not, it is not. =20 p8 leaf enabled - same comment for IPv6 as for IPv4 General - presumably ipv6 be assumed to be ubiquitous and supported by any device that supports Netconf, still the question if there is a need to declare an ipv6 feature? =20 Thank you --- Alex -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Sunday, June 10, 2012 6:49 AM To: netmod@ietf.org Subject: [netmod] review of draft-ietf-netmod-ip-cfg-03 I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my comments/questions. a) p1: I am wondering whether the title is correct. The document really is concerned with the configuration of IP interfaces as far as I understand it. It does not do routing and it also leaves out configuration things such as reassembly timers, default TTLs, etc. So would a more accurate title be "A Yang Data Model for IP Interface Configuration"? And if so, should the module name become ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? b) Should there be an Acknowledgements section? We have quite some decent reviews... c) s/create-temporary-addressed/create-temporary-addresses/ d) p5: The objects ipNetToPhysicalTable and ipAddressStatus are writable in the IP-MIB but do not represent configuration, and are thus not mapped to the YANG module. This seems odd. Static address mappings can typically be configured and some people do this (either for security or performance reasons). As far as I understand things in the Linux world, address mappings seem to be interface specific. e) p6: s/2011/2012/ f) p10: If I do not what autoconf address at all, I have to set all create-* leaves to false? Should there be a global switch? Not sure, just asking... g) p13: Should there be text discussing ipv4/forwarding and ipv6/forwarding? Or the impact of the autoconf knobs? h) p14: Are the references RFC6241, RFC6242 really normative? The routing document I think has RFC6241 and RFC 6242 as informative. Perhaps we should also explicitely refer to RFC6536 or even encourage its implementation. i) Add IPv6 config to the example? /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From lhotka@nic.cz Tue Jun 12 01:30:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928B521F85A3 for ; Tue, 12 Jun 2012 01:30:37 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcYrMd2mnTqi for ; Tue, 12 Jun 2012 01:30:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id B591221F8510 for ; Tue, 12 Jun 2012 01:30:36 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id EA91F141258; Tue, 12 Jun 2012 10:30:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339489836; bh=8x0If/iJf1Ck5FF6uPFJyl2Kd1gBJCB2Ajk5lEdrgIg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=N5Up1EAH203zwfLEmvJkRTeARcK5EIQlJVznpzVkH4FlMtJbieSt6L7Ir7YvfiKqU wsGQ9JQFhHPExpJLOMOeY5BDb4i187U9fBMFbcXXtlU84bBJWt1MEzR0INyKgLS8NR 9BHd1QEaWb813auA8boWUj8oCjMxoI9pxU6y0+3I= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120611.230704.439935195.mbj@tail-f.com> Date: Tue, 12 Jun 2012 10:30:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <76338863-75E4-43F3-8B36-5F19EA59F04D@nic.cz> References: <20120610134939.GD60379@elstar.local> <20120611124743.GA64394@elstar.local> <20120611.230704.439935195.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-routing-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 08:30:37 -0000 On Jun 11, 2012, at 11:07 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Mon, Jun 11, 2012 at 01:13:10PM +0200, Ladislav Lhotka wrote: >>>> h) p19: Is "missing-element" the right error-tag? If a router with = the >>>> requested name does not exist, then it is not a missing >>>> element in the XML sense. Is this perhaps "data-missing"? >>>=20 >>> I wasn't sure here. So "missing-element" would be used only if an = element is >>> missing that is mandatory according to the schema? >>=20 >> RFC 6241 error descriptions are not super precise. My reading of >>=20 >> error-tag: missing-element >> error-type: protocol, application >> error-severity: error >> error-info: : name of the missing element >> Description: An expected element is missing. >>=20 >> is that we are talking about missing XML element - but then the text >> just says element. I guess NETCONF implementors should clarify what >> their use of the error-tags really is. >=20 > We use 'missing-element' for missing XML elements. 6241 uses the term > 'element' for XML elements (almost consistently :) >=20 > The descripton for "data-missing" is: >=20 > Description: Request could not be completed because the relevant > data model content does not exist. For example, > a "delete" operation was attempted on > data that does not exist. >=20 > So in this case the error-tag should be "data-missing". OK, I will change it accordingly. >=20 >>>> l) p36/p45: The route list is indexed by seqno, which is a = "sequential >>>> number of the route". What does this mean? Do I have to = do >>>> a major renumbering just to insert a route? Why not = using >>>> "dest-prefix next-hop" as a key and eliminating seqno or >>>> something like that? >>>=20 >>> It would be too limiting to require that "dest-prefix next-hop" be >>> unique. >=20 > Why is this too limiting? Two routes having the same dest-prefix and next-hop may differ in other = attributes that will be added via augmentation by other modules, e.g. = for policy routing. Linux example: # ip route add 192.0.2.0/24 tos 0x01 via 77.48.224.129 # ip route add 192.0.2.0/24 tos 0x10 via 77.48.224.129 >=20 >>> there is no natural key to be used here and the list can be very = long. So it >>> could be a royal pain for the client to always have to select a = unique key >>> for each entry. >>>=20 >>> A good solution to this problem might be to leave the assignment of = the key >>> to the server - and then the sequential numbers can really be sorted = in the >>> datastore. It is how it is done in Mikrotik routers and I find it = quite >>> handy. Maybe it could become another item in the NETCONF 2.0 = wishlist. >=20 > I think Andy described the problem with this approach for NETCONF that > there is no way for the server to tell the client what the newly > assigned index is. Why? The client can use get-config whenever the numbering of entries is = needed. >=20 >>> But for the time being I don't really know how to deal with this >>> issue. Should I change the key type to an opaque string? >=20 > Currently this list is ordered-by user, and has a key which is > described as being the "sequentional number", which seems a bit > confusing. An opaque string is imo better. Strings would consume more memory, which may be an issue with very long = lists. And it can still be difficult for the client to determine a = unique key for a new entry. 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 mbj@tail-f.com Tue Jun 12 03:54:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42D221F8589 for ; Tue, 12 Jun 2012 03:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uU-xsu1syBGv for ; Tue, 12 Jun 2012 03:54:55 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2DE21F851C for ; Tue, 12 Jun 2012 03:54:55 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F1BE21200CF2; Tue, 12 Jun 2012 12:54:52 +0200 (CEST) Date: Tue, 12 Jun 2012 12:54:52 +0200 (CEST) Message-Id: <20120612.125452.1645516036024914306.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120610134853.GC60379@elstar.local> References: <20120610134853.GC60379@elstar.local> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 10:54:55 -0000 Juergen Schoenwaelder wrote: > I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my > comments/questions. > > a) p1: I am wondering whether the title is correct. The document > really is concerned with the configuration of IP interfaces as far > as I understand it. It does not do routing and it also leaves out > configuration things such as reassembly timers, default TTLs, etc. > So would a more accurate title be "A Yang Data Model for IP > Interface Configuration"? And if so, should the module name become > ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? Do we want to add global parameters such as default TTLs? If not, I do not mind changing the title. > b) Should there be an Acknowledgements section? We have quite some decent > reviews... Absolutely, now added. > c) s/create-temporary-addressed/create-temporary-addresses/ Fixed. > d) p5: > > The objects ipNetToPhysicalTable and ipAddressStatus are writable in > the IP-MIB but do not represent configuration, and are thus not > mapped to the YANG module. > > This seems odd. Static address mappings can typically be configured > and some people do this (either for security or performance > reasons). As far as I understand things in the Linux world, address > mappings seem to be interface specific. For some discussion/questions, see http://www.ietf.org/mail-archive/web/netmod/current/msg06514.html. ipNetToPhysicalTable says: As the entries in this table are typically not persistent when this object is written the entity SHOULD NOT save the change to non-volatile storage. which is why I did not include this. > e) p6: s/2011/2012/ Fixed. > f) p10: If I do not what autoconf address at all, I have to set all > create-* leaves to false? Should there be a global switch? Not > sure, just asking... I think we discussed this but can't find any notes. So, should there be an option to disable stateless autoconfiguration on an ipv6-enabled interface? > g) p13: Should there be text discussing ipv4/forwarding and > ipv6/forwarding? Or the impact of the autoconf knobs? RFC 4293 has text for ipForwarding and ipv6IpForwarding, so we should probably have something similar. What would the security impact be for the autoconf parameters? > h) p14: Are the references RFC6241, RFC6242 really normative? > The routing document I think has RFC6241 and RFC 6242 as > informative. Perhaps we should also explicitely refer to > RFC6536 or even encourage its implementation. Yes. Same as for ip-cfg. > i) Add IPv6 config to the example? Ok. /martin From j.schoenwaelder@jacobs-university.de Tue Jun 12 04:14:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B05C21F864C for ; Tue, 12 Jun 2012 04:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.119 X-Spam-Level: X-Spam-Status: No, score=-103.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FW27glu3ZU8 for ; Tue, 12 Jun 2012 04:14:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4B51E21F8643 for ; Tue, 12 Jun 2012 04:14:33 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A09AA20BEA; Tue, 12 Jun 2012 13:14:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pomSFFSaIWob; Tue, 12 Jun 2012 13:14:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24C3E2096B; Tue, 12 Jun 2012 13:14:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 139121FC175C; Tue, 12 Jun 2012 13:14:30 +0200 (CEST) Date: Tue, 12 Jun 2012 13:14:30 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120612111428.GD70760@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120610134853.GC60379@elstar.local> <20120612.125452.1645516036024914306.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120612.125452.1645516036024914306.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:14:34 -0000 On Tue, Jun 12, 2012 at 12:54:52PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my > > comments/questions. > > > > a) p1: I am wondering whether the title is correct. The document > > really is concerned with the configuration of IP interfaces as far > > as I understand it. It does not do routing and it also leaves out > > configuration things such as reassembly timers, default TTLs, etc. > > So would a more accurate title be "A Yang Data Model for IP > > Interface Configuration"? And if so, should the module name become > > ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? > > Do we want to add global parameters such as default TTLs? If not, I > do not mind changing the title. I do not know how much bigger this makes the project... > > d) p5: > > > > The objects ipNetToPhysicalTable and ipAddressStatus are writable in > > the IP-MIB but do not represent configuration, and are thus not > > mapped to the YANG module. > > > > This seems odd. Static address mappings can typically be configured > > and some people do this (either for security or performance > > reasons). As far as I understand things in the Linux world, address > > mappings seem to be interface specific. > > For some discussion/questions, see > http://www.ietf.org/mail-archive/web/netmod/current/msg06514.html. > > ipNetToPhysicalTable says: > > As the entries in this table are typically not persistent > when this object is written the entity SHOULD NOT save the > change to non-volatile storage. > > which is why I did not include this. Well, that might be true for the MIB. I happen to run boxes that have static mappings and I happen to run boxes that do proxyarp stuff. I am not saying this has to be included or not, I was however somewhat irritated by the reasoning. Seems we need to settle what the real scope of this data model is. > > f) p10: If I do not what autoconf address at all, I have to set all > > create-* leaves to false? Should there be a global switch? Not > > sure, just asking... > > I think we discussed this but can't find any notes. So, should there > be an option to disable stateless autoconfiguration on an ipv6-enabled > interface? I guess someone needs to check what the IPv6 specs really say about this. I have boxes that have static IPv6 addresses configured and I would prefer them to ignore any wired RAs on those links. > > g) p13: Should there be text discussing ipv4/forwarding and > > ipv6/forwarding? Or the impact of the autoconf knobs? > > RFC 4293 has text for ipForwarding and ipv6IpForwarding, so we should > probably have something similar. What would the security impact be > for the autoconf parameters? The reason we use statically configured IPv4 and IPv6 addresses on our servers is to improve their robustness. We considered moving to static address mappings as well but did not go there (yet). If you use autoconfig, then you have to trust something and whether that trust is justified is something to consider. /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 Jun 12 04:18:40 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E89D21F865C for ; Tue, 12 Jun 2012 04:18:40 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncUXDdnwe47g for ; Tue, 12 Jun 2012 04:18:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3000021F8657 for ; Tue, 12 Jun 2012 04:18:39 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 67674141258; Tue, 12 Jun 2012 13:18:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339499918; bh=Uahf8Qq07mBXmCKXc2yp7BFUKTrtbr9n8heg+VhjlZI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=bqXovr/W4IVmrmwqQNfO/kSOIN+zfJkt2F8vF1Qill1HR+ZMWOga/bqj0nu7kkWvj nJz0v+Ro9+PZAX61HnNaqV4Vi4DbMxr+2PN/+3tgRs1N7tuI/hZCSsFzqy7wh4jHaL +XI5GH0v5E9PAygY/MIOEh02i+Ce9yBl2zSbRZio= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120612.125452.1645516036024914306.mbj@tail-f.com> Date: Tue, 12 Jun 2012 13:18:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120610134853.GC60379@elstar.local> <20120612.125452.1645516036024914306.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:18:40 -0000 On Jun 12, 2012, at 12:54 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my >> comments/questions. >>=20 >> a) p1: I am wondering whether the title is correct. The document >> really is concerned with the configuration of IP interfaces as far >> as I understand it. It does not do routing and it also leaves out >> configuration things such as reassembly timers, default TTLs, etc. >> So would a more accurate title be "A Yang Data Model for IP >> Interface Configuration"? And if so, should the module name become >> ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? >=20 > Do we want to add global parameters such as default TTLs? If not, I > do not mind changing the title. Then there are also the global operational data structures from sec. 5.1 = of RFC 4861: neighbor cache, etc. I think it is better to add the = necessary global data and leave the scope of the I-D and module as "core = IP". Lada =20 >=20 >> b) Should there be an Acknowledgements section? We have quite some = decent >> reviews... >=20 > Absolutely, now added. >=20 >> c) s/create-temporary-addressed/create-temporary-addresses/ >=20 > Fixed. >=20 >> d) p5: >>=20 >> The objects ipNetToPhysicalTable and ipAddressStatus are writable = in >> the IP-MIB but do not represent configuration, and are thus not >> mapped to the YANG module. >>=20 >> This seems odd. Static address mappings can typically be configured >> and some people do this (either for security or performance >> reasons). As far as I understand things in the Linux world, address >> mappings seem to be interface specific. >=20 > For some discussion/questions, see > http://www.ietf.org/mail-archive/web/netmod/current/msg06514.html. >=20 > ipNetToPhysicalTable says: >=20 > As the entries in this table are typically not persistent > when this object is written the entity SHOULD NOT save the > change to non-volatile storage. >=20 > which is why I did not include this. >=20 >=20 >> e) p6: s/2011/2012/ >=20 > Fixed. >=20 >> f) p10: If I do not what autoconf address at all, I have to set all >> create-* leaves to false? Should there be a global switch? Not >> sure, just asking... >=20 > I think we discussed this but can't find any notes. So, should there > be an option to disable stateless autoconfiguration on an ipv6-enabled > interface? >=20 >> g) p13: Should there be text discussing ipv4/forwarding and >> ipv6/forwarding? Or the impact of the autoconf knobs? >=20 > RFC 4293 has text for ipForwarding and ipv6IpForwarding, so we should > probably have something similar. What would the security impact be > for the autoconf parameters? >=20 >=20 >> h) p14: Are the references RFC6241, RFC6242 really normative? >> The routing document I think has RFC6241 and RFC 6242 as >> informative. Perhaps we should also explicitely refer to >> RFC6536 or even encourage its implementation. >=20 > Yes. Same as for ip-cfg. >=20 >=20 >> i) Add IPv6 config to the example? >=20 > Ok. >=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 mbj@tail-f.com Tue Jun 12 04:36:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5299721F866B for ; Tue, 12 Jun 2012 04:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KyCD0igMu77 for ; Tue, 12 Jun 2012 04:36:32 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6323821F8663 for ; Tue, 12 Jun 2012 04:36:32 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 975E71200AD8; Tue, 12 Jun 2012 13:36:31 +0200 (CEST) Date: Tue, 12 Jun 2012 13:36:31 +0200 (CEST) Message-Id: <20120612.133631.1256315680281708071.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BBDE98A@xmb-sjc-239.amer.cisco.com> References: <20120610134825.GB60379@elstar.local> <20120611.154846.863925517358651472.mbj@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BBDE98A@xmb-sjc-239.amer.cisco.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:36:33 -0000 Hi Alex, Thanks for your reviews! Comments inline. "Alexander Clemm (alex)" wrote: > Hello Martin, > > I have reviewed the draft as well, here are my comments > > p5 - location leaf is optional but mandatory in case the type represents > a physical interface. This is not reflected in the YANG module. For > consistency reasons, it seems that if it is supposed to be mandatory, > this needs to be added in the YANG module, which may however become > overly complex in turn. Alternatively, remove this condition. It doesn't make much sense to make 'location' mandatory in the data model. However, you are right that the text and YANG module are not consistent. I will clarify that this in the YANG module. > p7 - ifPromiscuousode not mapped because not a configuration object. > Agree with this in spirit, but neither is ifIndex, yet it is included. > It might be good to add a comment why to keep ifIndex (important for > mappings, want it persisted between reboots, etc etc) Actually, ifIndex is not included in the configuration model - it is included as a non-config object, in order to facilitate the mapping. This document does not assume anything about if/how ifIndex is persistent between reboots. > p10 - leaf name "A device MAY restrict the allowed values for this > leaf...." It would be good to provide a section that provides clear > instructions/ recommendations how to provide such restrictions. (An > implementation will have to be clear on what those restrictions are, as > ultimately they will need to be validated.) Section 3.1 could be > expanded for this purpose, which already talks about how to augment this > for interface type specific data. The current text says: Such an implementation MAY restrict the allowed values for this leaf so that it matches the restrictions of ifName."; reference "RFC 2863: The Interfaces Group MIB - ifName"; This really just refers the reader to the ifName definition (which leads to RFC 2579 DisplayString, which in turn references RFC 854). I would prefer to not duplicate this text, but keep the reference. > p10 - leaf description "This leaf MAY be mapped to ifAlias..." Similar > comment - if an implementation restricts the values, where is this > specified. Since this is more a binary choice - either it maps to > ifAlias or it doesn't - it seems this should be supported in the model > itself, perhaps using the feature construct. Whether this leaf is mapped to ifAlias or not doesn't affect this data model, so defining a feature is probably not useful. The text was included to guide implementors that implement both this data model and IF-MIB. > p10 - leaf type: If the value of this leaf can be derived from the > name, does this need to be mandatory? In the general case, the value of this leaf cannot necessarily be dervied from the name. The basic assumption is that all interfaces MUST have a type. Thus, this leaf is mandatory (it must exist in a valid config). Note that the name is an arbitrary string. However, many devices do not allow arbitrary strings; instead they encode the type (and location) in the name. Different systems have different such naming schemes, of course. > Or rather, does this not > introduce another integrity constraint or depend on device feature (the > ability to derive the type from the interface name)? > p11 - leaf enabled: Why not simply call the leaf adminStatus? Seems a > little clearer. Of course, then it can no longer be simply be a > Boolean; however, the term "enabled" appears more like a concept of an > operational state to me. In a previous version it was actually called if-admin-status. I think we changed it b/c it does not have the exact same semantics as ifAdminStatus, and also the term "enabled" is used in other data models (routing, ip). > As a side note, if the purpose of this is to turn on or off an > interface, have you considered defining this as an RPC? No, this is a persistently stored configuration object, so it should not be modelled as an RPC. > This might come > in handy also in light of the Netconf-light discussions. If all that a > device supports is a copy-config in its entirety, you would need to > replace the entire configuration whenever you want to enable or disable > a single interface. This is OT, but if the device only supports copy-config then you have to live with that... any tiny little change requires you to send everything. OTOH, such a constrained device probably doesn't have too many config params. /martin From mbj@tail-f.com Tue Jun 12 04:38:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EF421F866C for ; Tue, 12 Jun 2012 04:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIqTYq4h-90E for ; Tue, 12 Jun 2012 04:37:59 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id AC48121F8663 for ; Tue, 12 Jun 2012 04:37:59 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id EF4C11200AD8; Tue, 12 Jun 2012 13:37:58 +0200 (CEST) Date: Tue, 12 Jun 2012 13:37:58 +0200 (CEST) Message-Id: <20120612.133758.544594921302340818.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120610134853.GC60379@elstar.local> <20120612.125452.1645516036024914306.mbj@tail-f.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:38:00 -0000 Ladislav Lhotka wrote: > > On Jun 12, 2012, at 12:54 PM, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > >> I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my > >> comments/questions. > >> > >> a) p1: I am wondering whether the title is correct. The document > >> really is concerned with the configuration of IP interfaces as far > >> as I understand it. It does not do routing and it also leaves out > >> configuration things such as reassembly timers, default TTLs, etc. > >> So would a more accurate title be "A Yang Data Model for IP > >> Interface Configuration"? And if so, should the module name become > >> ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? > > > > Do we want to add global parameters such as default TTLs? If not, I > > do not mind changing the title. > > Then there are also the global operational data structures from > sec. 5.1 of RFC 4861: neighbor cache, etc. I think it is better to add > the necessary global data and leave the scope of the I-D and module as > "core IP". So what is the "necessary global data" we should add? /martin From j.schoenwaelder@jacobs-university.de Tue Jun 12 04:52:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A5421F8619 for ; Tue, 12 Jun 2012 04:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.131 X-Spam-Level: X-Spam-Status: No, score=-103.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiOrXkjAsK+h for ; Tue, 12 Jun 2012 04:52:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8C421F8617 for ; Tue, 12 Jun 2012 04:52:52 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B82CA20BF6; Tue, 12 Jun 2012 13:52:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TrQRyMTnXDI4; Tue, 12 Jun 2012 13:52:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4508F20BE8; Tue, 12 Jun 2012 13:52:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8C4A21FC1A02; Tue, 12 Jun 2012 13:52:49 +0200 (CEST) Date: Tue, 12 Jun 2012 13:52:49 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120612115249.GF70760@elstar.local> Mail-Followup-To: Martin Bjorklund , alex@cisco.com, netmod@ietf.org References: <20120610134825.GB60379@elstar.local> <20120611.154846.863925517358651472.mbj@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BBDE98A@xmb-sjc-239.amer.cisco.com> <20120612.133631.1256315680281708071.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120612.133631.1256315680281708071.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:52:53 -0000 On Tue, Jun 12, 2012 at 01:36:31PM +0200, Martin Bjorklund wrote: > > p10 - leaf name "A device MAY restrict the allowed values for this > > leaf...." It would be good to provide a section that provides clear > > instructions/ recommendations how to provide such restrictions. (An > > implementation will have to be clear on what those restrictions are, as > > ultimately they will need to be validated.) Section 3.1 could be > > expanded for this purpose, which already talks about how to augment this > > for interface type specific data. > > The current text says: > > Such an implementation MAY restrict the allowed values > for this leaf so that it matches the restrictions of > ifName."; > reference > "RFC 2863: The Interfaces Group MIB - ifName"; > > This really just refers the reader to the ifName definition (which > leads to RFC 2579 DisplayString, which in turn references RFC 854). I > would prefer to not duplicate this text, but keep the reference. > > > p10 - leaf description "This leaf MAY be mapped to ifAlias..." Similar > > comment - if an implementation restricts the values, where is this > > specified. Since this is more a binary choice - either it maps to > > ifAlias or it doesn't - it seems this should be supported in the model > > itself, perhaps using the feature construct. > > Whether this leaf is mapped to ifAlias or not doesn't affect this data > model, so defining a feature is probably not useful. The text was > included to guide implementors that implement both this data model and > IF-MIB. I am personally fine with the references. One thing we could do, however, is to specify how a server reacts that enforces ifName / ifAlias restrictions and you send it some fancy UTF-8 characters. /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 Jun 12 04:57:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C46821F8668 for ; Tue, 12 Jun 2012 04:57:17 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCeCKYjfpzfS for ; Tue, 12 Jun 2012 04:57:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A3A8821F8667 for ; Tue, 12 Jun 2012 04:57:16 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id CB7D9141298; Tue, 12 Jun 2012 13:57:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339502235; bh=JvUOQYLYfZux0n+ds3sVsEKQSUvpZDFsQSkc61cqICA=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QzmutSSd+AdqN9oR4atcahjAphXwjv+Q9AYbir2FBk/uDrWemQZO7wC8YalTHbjIM YwMxjb++0XvRyhOkyhiqlE71N06zHEf/CTRHXkxT1LxgA1lmgvamY+HBWEga6Jux6D iPSmL+Lh8eRiEInWFqeI39tD1hPvEPkznoufN8sU= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120612.133758.544594921302340818.mbj@tail-f.com> Date: Tue, 12 Jun 2012 13:57:11 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20120610134853.GC60379@elstar.local> <20120612.125452.1645516036024914306.mbj@tail-f.com> <20120612.133758.544594921302340818.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:57:17 -0000 On Jun 12, 2012, at 1:37 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> >> On Jun 12, 2012, at 12:54 PM, Martin Bjorklund wrote: >> >>> Juergen Schoenwaelder wrote: >>>> I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my >>>> comments/questions. >>>> >>>> a) p1: I am wondering whether the title is correct. The document >>>> really is concerned with the configuration of IP interfaces as far >>>> as I understand it. It does not do routing and it also leaves out >>>> configuration things such as reassembly timers, default TTLs, etc. >>>> So would a more accurate title be "A Yang Data Model for IP >>>> Interface Configuration"? And if so, should the module name become >>>> ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? >>> >>> Do we want to add global parameters such as default TTLs? If not, I >>> do not mind changing the title. >> >> Then there are also the global operational data structures from >> sec. 5.1 of RFC 4861: neighbor cache, etc. I think it is better to add >> the necessary global data and leave the scope of the I-D and module as >> "core IP". > > So what is the "necessary global data" we should add? They are specified in said RFC: 1. neighbor cache 2. destination cache 3. prefix list 4. default router list The latter two are in the routing module but the former two aren't. Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jun 12 05:08:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED73621F85DF for ; Tue, 12 Jun 2012 05:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpZfvbmD-Hu7 for ; Tue, 12 Jun 2012 05:08:25 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8F19121F8616 for ; Tue, 12 Jun 2012 05:08:24 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6C8821200AD8; Tue, 12 Jun 2012 14:08:23 +0200 (CEST) Date: Tue, 12 Jun 2012 14:08:23 +0200 (CEST) Message-Id: <20120612.140823.1156163636011612056.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120612115249.GF70760@elstar.local> References: <196FFAC4F80A9142A8C30A7EE9C33B790BBDE98A@xmb-sjc-239.amer.cisco.com> <20120612.133631.1256315680281708071.mbj@tail-f.com> <20120612115249.GF70760@elstar.local> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 12:08:26 -0000 Juergen Schoenwaelder wrote: > On Tue, Jun 12, 2012 at 01:36:31PM +0200, Martin Bjorklund wrote: > > > > p10 - leaf name "A device MAY restrict the allowed values for this > > > leaf...." It would be good to provide a section that provides clear > > > instructions/ recommendations how to provide such restrictions. (An > > > implementation will have to be clear on what those restrictions are, as > > > ultimately they will need to be validated.) Section 3.1 could be > > > expanded for this purpose, which already talks about how to augment this > > > for interface type specific data. > > > > The current text says: > > > > Such an implementation MAY restrict the allowed values > > for this leaf so that it matches the restrictions of > > ifName."; > > reference > > "RFC 2863: The Interfaces Group MIB - ifName"; > > > > This really just refers the reader to the ifName definition (which > > leads to RFC 2579 DisplayString, which in turn references RFC 854). I > > would prefer to not duplicate this text, but keep the reference. > > > > > p10 - leaf description "This leaf MAY be mapped to ifAlias..." Similar > > > comment - if an implementation restricts the values, where is this > > > specified. Since this is more a binary choice - either it maps to > > > ifAlias or it doesn't - it seems this should be supported in the model > > > itself, perhaps using the feature construct. > > > > Whether this leaf is mapped to ifAlias or not doesn't affect this data > > model, so defining a feature is probably not useful. The text was > > included to guide implementors that implement both this data model and > > IF-MIB. > > I am personally fine with the references. One thing we could do, > however, is to specify how a server reacts that enforces ifName / > ifAlias restrictions and you send it some fancy UTF-8 characters. Ok. Something like this maybe: If a NETCONF server that implements this restriction is sent a value that doesn't match the restriction, it MUST reply with an rpc-error with the error-tag 'invalid-value'."; /martin From alex@cisco.com Tue Jun 12 15:01:28 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39BE21F867F for ; Tue, 12 Jun 2012 15:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVA5T4itGRCe for ; Tue, 12 Jun 2012 15:01:27 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE9B21F867E for ; Tue, 12 Jun 2012 15:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=4296; q=dns/txt; s=iport; t=1339538487; x=1340748087; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=60DIro4bou526elln8SFBugxeQZuCWIzimOfIWQE5FU=; b=fF1nFgaqHQMKkUPZ3h8cb4ZiS0d9d6N55w0RNCaTOycFNE/jX4NAwuB3 Zd51OzJg72EVM24hAdDS5DqDHBME76QhvXcsYj0vcvbMoVxD7gwwSxNIj DPZz85PMjweqwhjyKimxrej4Yj3yjXX2mJ1oXcgPDYoHhSqOi67fd5noE k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACe710+rRDoJ/2dsb2JhbABFtTaBB4IYAQEBAwESAR0KPwULAgEIDhQGGAYBVgEBBBsah2QEAZlNn36QWGADiECadIFmgwCBOCM X-IronPort-AV: E=Sophos;i="4.75,759,1330905600"; d="scan'208";a="45564491" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 12 Jun 2012 22:01:27 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5CM1RZo031183; Tue, 12 Jun 2012 22:01:27 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jun 2012 15:01:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2012 15:01:26 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790BC8834F@xmb-sjc-239.amer.cisco.com> In-Reply-To: <20120612.133631.1256315680281708071.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 Thread-Index: Ac1Ij6DrAurNikVqRL+S9D3j2WuTYQAQG0WQ References: <20120610134825.GB60379@elstar.local><20120611.154846.863925517358651472.mbj@tail-f.com><196FFAC4F80A9142A8C30A7EE9C33B790BBDE98A@xmb-sjc-239.amer.cisco.com> <20120612.133631.1256315680281708071.mbj@tail-f.com> From: "Alexander Clemm (alex)" To: "Martin Bjorklund" X-OriginalArrivalTime: 12 Jun 2012 22:01:27.0060 (UTC) FILETIME=[EA15FD40:01CD48E6] Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 22:01:28 -0000 Hello Martin, thank you for your response - some replies below, delineated Thanks --- Alex ... > p7 - ifPromiscuousode not mapped because not a configuration object. > Agree with this in spirit, but neither is ifIndex, yet it is included. > It might be good to add a comment why to keep ifIndex (important for > mappings, want it persisted between reboots, etc etc)=20 Actually, ifIndex is not included in the configuration model - it is included as a non-config object, in order to facilitate the mapping. This document does not assume anything about if/how ifIndex is persistent between reboots. =20 My comment pertained to the reason that is given for not including ifPromiscousMode. I agree with the fact that it is not included, and I agree also with having ifIndex there to facilitate mappings. However, since neither ifPromiscuousMode nor ifIndex are part of the configuration model, yet ifIndex is included, not being part of the configuration model is by itself not enough reason for an object to be excluded. Hence the comment that it might be good to include a brief explanation what it is that makes ifIndex special. =20 > p10 - leaf name "A device MAY restrict the allowed values for this > leaf...." It would be good to provide a section that provides clear > instructions/ recommendations how to provide such restrictions. (An > implementation will have to be clear on what those restrictions are, as > ultimately they will need to be validated.) Section 3.1 could be > expanded for this purpose, which already talks about how to augment this > for interface type specific data. =20 The current text says: Such an implementation MAY restrict the allowed values for this leaf so that it matches the restrictions of ifName."; reference "RFC 2863: The Interfaces Group MIB - ifName"; This really just refers the reader to the ifName definition (which leads to RFC 2579 DisplayString, which in turn references RFC 854). I would prefer to not duplicate this text, but keep the reference. =20 The text given in the leaf description makes sense and clearly is all that can be specified here. My comment pertains to the product that now wants to implement that. This implementation may very well (as specified here) restrict the allowed values. How and where are these restrictions to be expressed? One way is to not express these at all. In that case, some validation above and beyond what is specified in the YANG module needs to occur, and the rules for that validation are not obvious from the YANG module itself. An alternative would consist in introducing an augmentation that defines these additional constraints. I believe the usefulness of the document would be improved if it could provide some guidance on how to do that instead of leaving it up to readers of the document to figure it out for themselves; it would make the spec easier to use and show implementers how the value of YANG-based validation can still be derived. =20 ..... > As a side note, if the purpose of this is to turn on or off an > interface, have you considered defining this as an RPC? No, this is a persistently stored configuration object, so it should not be modelled as an RPC. I understand this is MODELED as a persistently stored configuration object, but it doesn't have to be that. You can also interpret this simply as an action. Just as a consideration, with regards to the Netconf-light discussion, if you force people to replace the entire configuration each time they plan to enable or disable a single interface will seem awkward - just my 2 cents. =20 > This might come > in handy also in light of the Netconf-light discussions. If all that a > device supports is a copy-config in its entirety, you would need to > replace the entire configuration whenever you want to enable or disable > a single interface. This is OT, but if the device only supports copy-config then you have to live with that... any tiny little change requires you to send everything. OTOH, such a constrained device probably doesn't have too many config params. From j.schoenwaelder@jacobs-university.de Tue Jun 12 19:49:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1461221F872E for ; Tue, 12 Jun 2012 19:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.141 X-Spam-Level: X-Spam-Status: No, score=-103.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74dm+fCQgdmg for ; Tue, 12 Jun 2012 19:49:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 393E421F8718 for ; Tue, 12 Jun 2012 19:49:07 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 296DB20BF6; Wed, 13 Jun 2012 04:49:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NCK3bxjILK7Z; Wed, 13 Jun 2012 04:49:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 27C2A20BF5; Wed, 13 Jun 2012 04:49:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 91A2E1FC2C5E; Wed, 13 Jun 2012 04:49:04 +0200 (CEST) Date: Wed, 13 Jun 2012 04:49:04 +0200 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20120613024904.GA73647@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , Martin Bjorklund , netmod@ietf.org References: <20120610134825.GB60379@elstar.local> <20120611.154846.863925517358651472.mbj@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BBDE98A@xmb-sjc-239.amer.cisco.com> <20120612.133631.1256315680281708071.mbj@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC8834F@xmb-sjc-239.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BC8834F@xmb-sjc-239.amer.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 02:49:08 -0000 On Tue, Jun 12, 2012 at 03:01:26PM -0700, Alexander Clemm (alex) wrote: > > > As a side note, if the purpose of this is to turn on or off an > > interface, have you considered defining this as an RPC? > > No, this is a persistently stored configuration object, so it should > not be modelled as an RPC. > > > > I understand this is MODELED as a persistently stored configuration > object, but it doesn't have to be that. You can also interpret this > simply as an action. Just as a consideration, with regards to the > Netconf-light discussion, if you force people to replace the entire > configuration each time they plan to enable or disable a single > interface will seem awkward - just my 2 cents. > > > Its awkward but introducing separate RPCs for every possible configuration change is hopeless and a high price for supporting one specific class of devices. NETCONF Light was originally designed for really small devices where replacing the entire (but small) structured config is already an improvement over replacing the whole firmware to turn something on/off. I think we should not let considerations for such devices impact the design of data models that are primarily targeting devices that can easily support NETCONF. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Jun 13 00:24:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6048221F8625 for ; Wed, 13 Jun 2012 00:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1iGAi+7r52u for ; Wed, 13 Jun 2012 00:24:10 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E1B3E21F860E for ; Wed, 13 Jun 2012 00:24:09 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 34EFE1200DB8; Wed, 13 Jun 2012 09:24:08 +0200 (CEST) Date: Wed, 13 Jun 2012 09:24:08 +0200 (CEST) Message-Id: <20120613.092408.1747766587053200776.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BC8834F@xmb-sjc-239.amer.cisco.com> References: <196FFAC4F80A9142A8C30A7EE9C33B790BBDE98A@xmb-sjc-239.amer.cisco.com> <20120612.133631.1256315680281708071.mbj@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC8834F@xmb-sjc-239.amer.cisco.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 07:24:11 -0000 Hi, "Alexander Clemm (alex)" wrote: > Hello Martin, > > thank you for your response - some replies below, delineated > > Thanks > --- Alex > > ... > > > > p7 - ifPromiscuousode not mapped because not a configuration object. > > Agree with this in spirit, but neither is ifIndex, yet it is included. > > It might be good to add a comment why to keep ifIndex (important for > > mappings, want it persisted between reboots, etc etc) > > Actually, ifIndex is not included in the configuration model - it is > included as a non-config object, in order to facilitate the mapping. > This document does not assume anything about if/how ifIndex is > persistent between reboots. > > > > > My comment pertained to the reason that is given for not including > ifPromiscousMode. It is writable in the MIB, but does not represent configuration. Hence it is not included. ifIndex is not writable in the MIB, so the reason for not including ifPromiscousMode does not apply to ifIndex. Do you have a suggestion for some text to make this more clear? > > p10 - leaf name "A device MAY restrict the allowed values for this > > leaf...." It would be good to provide a section that provides clear > > instructions/ recommendations how to provide such restrictions. (An > > implementation will have to be clear on what those restrictions are, > as > > ultimately they will need to be validated.) Section 3.1 could be > > expanded for this purpose, which already talks about how to augment > this > > for interface type specific data. > > The current text says: > > Such an implementation MAY restrict the allowed values > for this leaf so that it matches the restrictions of > ifName."; > reference > "RFC 2863: The Interfaces Group MIB - ifName"; > > This really just refers the reader to the ifName definition (which > leads to RFC 2579 DisplayString, which in turn references RFC 854). I > would prefer to not duplicate this text, but keep the reference. > > > > > The text given in the leaf description makes sense and clearly is all > that can be specified here. My comment pertains to the product that now > wants to implement that. This implementation may very well (as > specified here) restrict the allowed values. How and where are these > restrictions to be expressed? One way is to not express these at all. > In that case, some validation above and beyond what is specified in the > YANG module needs to occur Yes, this is the current situation. > and the rules for that validation are not > obvious from the YANG module itself. Correct. The YANG module doesn't have any formal restriction, but it allows implementations to restrict values according to the rules of a DisplayString. > An alternative would consist in > introducing an augmentation that defines these additional > constraints. Unfortunately, this isn't really possible with standard YANG. You cannot add constraints via augmentations. > I believe the usefulness of the document would be improved if it could > provide some guidance on how to do that instead of leaving it up to > readers of the document to figure it out for themselves; it would make > the spec easier to use and show implementers how the value of YANG-based > validation can still be derived. > > > > > ..... > > > As a side note, if the purpose of this is to turn on or off an > > interface, have you considered defining this as an RPC? > > No, this is a persistently stored configuration object, so it should > not be modelled as an RPC. > > > > I understand this is MODELED as a persistently stored configuration > object, but it doesn't have to be that. You can also interpret this > simply as an action. Just as a consideration, with regards to the > Netconf-light discussion, if you force people to replace the entire > configuration each time they plan to enable or disable a single > interface will seem awkward - just my 2 cents. > > I agree with Juergens comment on this one. If we start to add RPCs to change some config params, where do we stop? NETCONF is by design "document-oriented" (see Juergen's expired http://tools.ietf.org/id/draft-schoenw-sming-lessons-01.txt) and we should not change that. /martin From yihuan@cisco.com Wed Jun 13 10:16:02 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB04021F85D5 for ; Wed, 13 Jun 2012 10:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.602 X-Spam-Level: X-Spam-Status: No, score=-8.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LLOWxx-w7ND for ; Wed, 13 Jun 2012 10:16:02 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id EB09D21F85A4 for ; Wed, 13 Jun 2012 10:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yihuan@cisco.com; l=8111; q=dns/txt; s=iport; t=1339607761; x=1340817361; h=date:subject:from:to:message-id:mime-version; bh=ah4kju1yZ/hyhywQ2mvwNv/CfzPwE/I3opheC1Yl0+c=; b=ky69X5M+SEJQ6ctE/dJbbLu/DPsBYvuaeg1QZVgUT7SVc54C+3mF8vzC QBybOvheQJPSleMafrPq5HzZo90+BUOxDd3HsQC52VUBHLO+KzFUfZbOe TVHbqaotnSzb/cErj5K47BHRzFYGiBcoU6yp/jgebi3nbrN1YkGvTRcdK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAHK2E+rRDoH/2dsb2JhbABFgkWxX4EdgQeCHxIBKk+BKzWHaJh5gSiffo4ngxsDiEGMYIVUiEKBZoMA X-IronPort-AV: E=Sophos;i="4.75,765,1330905600"; d="scan'208,217";a="48726910" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 13 Jun 2012 17:15:59 +0000 Received: from [10.154.203.136] ([10.154.203.136]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5DHFvFi031241 for ; Wed, 13 Jun 2012 17:15:59 GMT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Wed, 13 Jun 2012 10:15:58 -0700 From: "yihuan@cisco.com" To: Message-ID: Thread-Topic: review of draft-ietf-netmod-interfaces-cfg-04 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3422427359_2307566" Subject: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 17:16:02 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3422427359_2307566 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I have reviewed draft-ietf-netmod-interfaces-cfg-04 and here are my comments/questions. 1. Leaf "link-up-down-trap-enable" uses an enumeration type whearas leaf "enable" type is boolean. How the enum and boolean types will be used differently? If not, should they be consistent? If yes, please explain the difference in the I-D. 2. In Example VLAN Interface Module, even thought "must" could put anywhere as a sub statement for leaf. It would be better to keep consistent sub statement sequence for better coding style. 3. The must statement "/if:interfaces/if:interface[if:name = current()]" + "/vlan:vlan-tagging = true" will never be reached. When augmenting, the additional leaves in the container only applies when 'must' condition is true. Two augment container can not exist at the same time for one interface name (key) instance since in this instance, if:type can not be 'l2vlan' and ('ethernetCsmacd' or 'ieee8023adLag'. Thanks, Lisa --B_3422427359_2307566 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable 
I have reviewed draft-ietf-netmod-interfaces=
-cfg-04 and here are my
comments/questions.
1. Leaf "link-up-down-trap-enable" uses an enumeration t=
ype whearas leaf "enable" type is boolean. How the enum and boolean types wi=
ll be used differently? If not, should they be consistent? If yes, please ex=
plain the difference in the I-D.

2. In Example VLAN Interface Module, even thought "m=
ust" could put anywhere as a sub statement for leaf. It would be better to k=
eep consistent sub statement sequence for better coding style.

3. The must statement =
"/if:interfaces/if:interface[if:name =3D current()]"
            + "/vlan:vlan-taggin=
g =3D true" will never be reached. When augmenting, the additional leaves in t=
he container only applies when 'must' condition is true. Two augment contain=
er can not exist at the same time for one interface name (key) instance sinc=
e in this instance, if:type can not be 'l2vlan' and ('ethernetCsmacd' or 'ie=
ee8023adLag'.

Thanks,

Lisa
=
--B_3422427359_2307566-- From yihuan@cisco.com Wed Jun 13 10:17:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A16221F8541 for ; Wed, 13 Jun 2012 10:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.902 X-Spam-Level: X-Spam-Status: No, score=-8.902 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzVjLsE8BtgE for ; Wed, 13 Jun 2012 10:17:47 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A138B21F853C for ; Wed, 13 Jun 2012 10:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yihuan@cisco.com; l=4569; q=dns/txt; s=iport; t=1339607866; x=1340817466; h=date:subject:from:to:message-id:mime-version; bh=SwVgwKmY+asvCB4u9v8/Oigwv0SI9JdZw3Pp3vAVx6s=; b=S4VoQONIhakBxTTdu0M/gxS0px0CsP20AErWFJ5dpLFfEMK1BSGsCXfR kcWMx7UYElMCpdjzEh38EFjDaKFNZlTdtUk5T7uxyAlQ33/HtGqewFFXH VmyTKPDY1bu78TSdKDMcATpbBoCi86cf80WUd4eX/QEbM/eWVvrEsA6O3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAHK2E+rRDoH/2dsb2JhbABFgkWxX4EdgQeCHxIBKk+BKzWHaJh5gSiffpFCA4hBjGCFVIhCgWaDAA X-IronPort-AV: E=Sophos;i="4.75,765,1330905600"; d="scan'208,217";a="45697533" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 13 Jun 2012 17:17:45 +0000 Received: from [10.154.203.136] ([10.154.203.136]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5DHHis7000546 for ; Wed, 13 Jun 2012 17:17:44 GMT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Wed, 13 Jun 2012 10:17:44 -0700 From: "yihuan@cisco.com" To: "netmod@ietf.org" Message-ID: Thread-Topic: review of draft-ietf-netmod-iana-if-type-04 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3422427465_2321102" Subject: [netmod] review of draft-ietf-netmod-iana-if-type-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 17:17:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3422427465_2321102 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I have reviewed draft-ietf-netmod-iana-if-type-04 and here are my comments/questions. 1. General comments. The enum and type definition needs more description or reference documentation. 2. 3. basicISDN and primaryISDN are no longer used. Should I-D use status 'obsolete'? 4. 5. Thanks, 6. Lisa 7. --B_3422427465_2321102 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable 
I have reviewed draft-ietf-netmod-iana-if-type-04 and here are my
comments/questions.
  1. General comments. The enum and type definition=
 needs more description or reference documentation.
  2.  basicISDN and primaryISDN are no=
 longer used. Should I-D use status 'obsolete'?

    Thanks,
    Lisa
=
--B_3422427465_2321102-- From mbj@tail-f.com Wed Jun 13 14:15:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FBB21F85A4 for ; Wed, 13 Jun 2012 14:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxsjJ+3-48dm for ; Wed, 13 Jun 2012 14:15:26 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E28B021F85A3 for ; Wed, 13 Jun 2012 14:15:25 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id F10651200DB0; Wed, 13 Jun 2012 23:15:24 +0200 (CEST) Date: Wed, 13 Jun 2012 23:15:24 +0200 (CEST) Message-Id: <20120613.231524.533322923.mbj@tail-f.com> To: yihuan@cisco.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:15:27 -0000 Hi, "yihuan@cisco.com" wrote: > I have reviewed draft-ietf-netmod-interfaces-cfg-04 and here are my > comments/questions. > 1. Leaf "link-up-down-trap-enable" uses an enumeration type whearas leaf > "enable" type is boolean. How the enum and boolean types will be used > differently? If not, should they be consistent? If yes, please explain the > difference in the I-D. The only reason they are different is that the leaf "enabled" typically is a boolean in other YANG models (but maybe it shouldn't...), and link-up-down-trap-enable uses the exact same values as in the MIB. > 2. In Example VLAN Interface Module, even thought "must" could put anywhere > as a sub statement for leaf. It would be better to keep consistent sub > statement sequence for better coding style. I do not understand what you mean. Could you try to rephrase? > 3. The must statement "/if:interfaces/if:interface[if:name = current()]" > + "/vlan:vlan-tagging = true" will never be reached. When > augmenting, the additional leaves in the container only applies when 'must' > condition is true. Two augment container can not exist at the same time for > one interface name (key) instance since in this instance, if:type can not be > 'l2vlan' and ('ethernetCsmacd' or 'ieee8023adLag'. No, the must statement is correct. It says that for an interface of type 'l2vlan', its 'base-interface' must refer to a interface that has vlan-tagging = true. For example: eth0 ethernerCsmacd true vlan1 l2vlan eth0 /martin From mbj@tail-f.com Wed Jun 13 14:21:15 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BC211E809C for ; Wed, 13 Jun 2012 14:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jXE6TXzpdJz for ; Wed, 13 Jun 2012 14:21:15 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 29DCA11E8097 for ; Wed, 13 Jun 2012 14:21:15 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C8D91200AC8; Wed, 13 Jun 2012 23:21:12 +0200 (CEST) Date: Wed, 13 Jun 2012 23:21:11 +0200 (CEST) Message-Id: <20120613.232111.304448987.mbj@tail-f.com> To: yihuan@cisco.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-iana-if-type-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:21:15 -0000 Hi, "yihuan@cisco.com" wrote: > I have reviewed draft-ietf-netmod-iana-if-type-04 and here are my > comments/questions. > 1. General comments. The enum and type definition needs more description or > reference documentation. This module is just a YANG-version of the IANA "ifType definitions" registry. So the text in the YANG module is the text in this registry. > 2. > 3. basicISDN and primaryISDN are no longer used. Should I-D use status > 'obsolete'? Since they are not marked as obsolete in the IANA registry, they are obsolete in this module. If they should be marked as obsolete, the change should go into the IANA registry. /martin From alex@cisco.com Wed Jun 13 14:34:22 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873FE11E8098 for ; Wed, 13 Jun 2012 14:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpSJCetL7v4q for ; Wed, 13 Jun 2012 14:34:21 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 84E1C11E8097 for ; Wed, 13 Jun 2012 14:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=3307; q=dns/txt; s=iport; t=1339623261; x=1340832861; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=HGpHNjBqYTMkPxvJR/oJPwC24cee9cjadnD9GKrKcZI=; b=bE849/cz5ZDy4INxSwvab5w7cxVRQDRD3y55txPfvKJ8HQT4uPsLzQSS AAm+0XLj1t98i4Y9rwv/skN+5bp/FKhF0Wr7aATPsxnCFOuM9lt5kFmwR a6au2YhCTBsNNyE6gtWW3tm6D3X9W7ihd3aJ624eLD52Xk7yzh0IlKQJF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPIG2U+rRDoJ/2dsb2JhbABFtT+BB4IYAQEBAwESAR0KPwULAgEIDhQGGAYBVgEBBBsah2QEAQuaOaACkGJgA4hBjXKNBIFmgwCBOCM X-IronPort-AV: E=Sophos;i="4.75,766,1330905600"; d="scan'208";a="48761614" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 13 Jun 2012 21:34:21 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5DLYLld003949; Wed, 13 Jun 2012 21:34:21 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 14:34:20 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2012 14:34:19 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790BC88707@xmb-sjc-239.amer.cisco.com> In-Reply-To: <20120613.092408.1747766587053200776.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 Thread-Index: Ac1JNYckvv9yh9fDTraA67pjRcMxiwAWdK7A References: <196FFAC4F80A9142A8C30A7EE9C33B790BBDE98A@xmb-sjc-239.amer.cisco.com><20120612.133631.1256315680281708071.mbj@tail-f.com><196FFAC4F80A9142A8C30A7EE9C33B790BC8834F@xmb-sjc-239.amer.cisco.com> <20120613.092408.1747766587053200776.mbj@tail-f.com> From: "Alexander Clemm (alex)" To: "Martin Bjorklund" X-OriginalArrivalTime: 13 Jun 2012 21:34:20.0972 (UTC) FILETIME=[4B4666C0:01CD49AC] Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:34:22 -0000 Hi Martin, inline replies w/ Thanks --- Alex ... It is writable in the MIB, but does not represent configuration. Hence it is not included. ifIndex is not writable in the MIB, so the reason for not including ifPromiscousMode does not apply to ifIndex. Do you have a suggestion for some text to make this more clear? =20 How about adding something like the following just after the original sentence (modify as appropriate: Original sentence: The IF-MIB also defines the writable object ifPromiscuousMode. Since this object typically is not a configuration object, it is not mapped to the "ietf-interfaces" module. Possible addition: =20 The object ifIndex, while it is not a configuration object either, is fairly ubiquitous and hence mapped to the "ietf-interfaces" module in order to facilitate mappings between interface configuration information and information in MIBs. =20 I believe the usefulness of the document would be improved if it could > provide some guidance on how to do that instead of leaving it up to > readers of the document to figure it out for themselves; it would make > the spec easier to use and show implementers how the value of YANG-based > validation can still be derived. =20 >=20 So, is there another way of address this issue? What are implementers to do if they have constraints - are there any recommendations that can be made? =20 - Should they treat this outside Netconf/YANG? This is not very satisfactory because it detriments the value proposition and usefulness of this object as validation has to occur in different places anyway, but being clear about it doesn't leave people second-guessing. =20 - Introduce augmentation with a second "shadow object" which does have the appropriate constraints, including a constraint that its value must mirror/be set to the same value of the other object? (That would presumably be legal, correct?, but ugly & I hope not) - Make use of deviation? =20 - Other options? =20 .... I agree with Juergens comment on this one. If we start to add RPCs to change some config params, where do we stop? NETCONF is by design "document-oriented" (see Juergen's expired http://tools.ietf.org/id/draft-schoenw-sming-lessons-01.txt) and we should not change that. I understand the argument about config params, but there is a grey line between this and RPCs, and RPCs are also supported by Netconf despite its document-orientation. (Any RPC could be addressed also through parameters - think Ping MIB - I agree this would be awkward which is why I consider this a feature.) To me, configuration is something that guides the behavior of a system, versus an RPC which define actions to be taken at a particular instant in time. This particular case is a borderline case which can be argued either way, that I can agree with. (I don't think whether an interface is enabled or disabled is just "any" config parameter, it is of a different nature than e.g. a config parameter that defines an interface name.) Do we have guidelines when to use which? =20 From mbj@tail-f.com Wed Jun 13 14:52:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F7A21F84B4 for ; Wed, 13 Jun 2012 14:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66b82Ru4Nqxs for ; Wed, 13 Jun 2012 14:52:38 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3069621F8472 for ; Wed, 13 Jun 2012 14:52:38 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E4B161200DB2; Wed, 13 Jun 2012 23:52:36 +0200 (CEST) Date: Wed, 13 Jun 2012 23:52:36 +0200 (CEST) Message-Id: <20120613.235236.119602680.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BC88707@xmb-sjc-239.amer.cisco.com> References: <196FFAC4F80A9142A8C30A7EE9C33B790BC8834F@xmb-sjc-239.amer.cisco.com> <20120613.092408.1747766587053200776.mbj@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC88707@xmb-sjc-239.amer.cisco.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 21:52:38 -0000 Hi, "Alexander Clemm (alex)" wrote: > Hi Martin, > > inline replies w/ > > Thanks > --- Alex > > Unfortunately, this isn't really possible with standard YANG. You > cannot add constraints via augmentations. > > > > I believe the usefulness of the document would be improved if it could > > provide some guidance on how to do that instead of leaving it up to > > readers of the document to figure it out for themselves; it would make > > the spec easier to use and show implementers how the value of > YANG-based > > validation can still be derived. > > > > > So, is there another way of address this issue? What are implementers > to do if they have constraints - are there any recommendations that can > be made? > - Should they treat this outside Netconf/YANG? This is not very > satisfactory because it detriments the value proposition and usefulness > of this object as validation has to occur in different places anyway, > but being clear about it doesn't leave people second-guessing. > - Introduce augmentation with a second "shadow object" which does have > the appropriate constraints, including a constraint that its value must > mirror/be set to the same value of the other object? (That would > presumably be legal, correct?, but ugly & I hope not) > - Make use of deviation? This might be possible, although it requires that the restriction can be formally expressed in YANG - for a string it means that you define a regexp that enforces the restriction. Sometimes this is not possible, and then you have to resort to descriptions in plain text, and enforment in special code. > > I understand the argument about config params, but there is a grey line > between this and RPCs, and RPCs are also supported by Netconf despite > its document-orientation. (Any RPC could be addressed also through > parameters - think Ping MIB - I agree this would be awkward which is why > I consider this a feature.) To me, configuration is something that > guides the behavior of a system, versus an RPC which define actions to > be taken at a particular instant in time. This particular case is a > borderline case which can be argued either way, that I can agree with. > (I don't think whether an interface is enabled or disabled is just "any" > config parameter, it is of a different nature than e.g. a config > parameter that defines an interface name.) Do we have guidelines when > to use which? If you want the value to be part of a config backup, it should be modelled as data. /martin From alex@cisco.com Wed Jun 13 15:03:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B7C21F8512 for ; Wed, 13 Jun 2012 15:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TQgrD7FkO3q for ; Wed, 13 Jun 2012 15:03:11 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7DB21F850F for ; Wed, 13 Jun 2012 15:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=3448; q=dns/txt; s=iport; t=1339624991; x=1340834591; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Qg57lLocgYX5xlQNaBrb4dGNw8MRiteng9oA4j/cyJw=; b=nKWd+Q0dwpsFVoIMShqpihLe2j71ZuSv2nqBatFg4lM/kmEWc0/FBIIB P4M131LMugwr860uVlBSRpOfETB6VYWMW01qJn34DVJLPvkeHKmEMul7x wFuBz7hDXP+40PG6luRV5Ya8s7YZa3c0GgWJmDGo8bFMY49O1p1gfrI3X c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAP0M2U+rRDoH/2dsb2JhbABFtT6BB4IYAQEBBBIBHQo/DAQCAQgOAgEEAQEBCgYXAQYBRQkIAQEEEwgah2gBmkugAYsxAoUvYAOIQZp2gWaDAIE4Iw X-IronPort-AV: E=Sophos;i="4.75,766,1330905600"; d="scan'208";a="45736571" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 13 Jun 2012 22:03:10 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5DM3A9Q006689; Wed, 13 Jun 2012 22:03:10 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 15:03:10 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jun 2012 15:03:09 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790BC8873E@xmb-sjc-239.amer.cisco.com> In-Reply-To: <20120613.235236.119602680.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 Thread-Index: Ac1Jrtqhlu1MdP6FRjmE9TgGSJ2XOQAADT5g References: <196FFAC4F80A9142A8C30A7EE9C33B790BC8834F@xmb-sjc-239.amer.cisco.com><20120613.092408.1747766587053200776.mbj@tail-f.com><196FFAC4F80A9142A8C30A7EE9C33B790BC88707@xmb-sjc-239.amer.cisco.com> <20120613.235236.119602680.mbj@tail-f.com> From: "Alexander Clemm (alex)" To: "Martin Bjorklund" X-OriginalArrivalTime: 13 Jun 2012 22:03:10.0630 (UTC) FILETIME=[523B4460:01CD49B0] Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 22:03:11 -0000 Hi Martin, thank you for your response to the 2nd item. Regarding the 1st, in short what you are saying is that we are running into the limitations of YANG here (which implementers in this case will likely encounter) but it should not necessary to give guidance. I understand that you can add enforcements in separate code and describe them separate from the YANG module itself. I had been wondering if it is possible to do a little better than that but I can live with it. =20 Regards --- Alex -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Wednesday, June 13, 2012 2:53 PM To: Alexander Clemm (alex) Cc: j.schoenwaelder@jacobs-university.de; netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 Hi, "Alexander Clemm (alex)" wrote: > Hi Martin, >=20 > inline replies w/ >=20 > Thanks > --- Alex >=20 > Unfortunately, this isn't really possible with standard YANG. You > cannot add constraints via augmentations. >=20 >=20 > > I believe the usefulness of the document would be improved if it could > > provide some guidance on how to do that instead of leaving it up to > > readers of the document to figure it out for themselves; it would make > > the spec easier to use and show implementers how the value of > YANG-based > > validation can still be derived. =20 > >=20 >=20 > > So, is there another way of address this issue? What are implementers > to do if they have constraints - are there any recommendations that can > be made? =20 > - Should they treat this outside Netconf/YANG? This is not very > satisfactory because it detriments the value proposition and usefulness > of this object as validation has to occur in different places anyway, > but being clear about it doesn't leave people second-guessing. =20 > - Introduce augmentation with a second "shadow object" which does have > the appropriate constraints, including a constraint that its value must > mirror/be set to the same value of the other object? (That would > presumably be legal, correct?, but ugly & I hope not) > - Make use of deviation? =20 This might be possible, although it requires that the restriction can be formally expressed in YANG - for a string it means that you define a regexp that enforces the restriction. Sometimes this is not possible, and then you have to resort to descriptions in plain text, and enforment in special code. > > I understand the argument about config params, but there is a grey line > between this and RPCs, and RPCs are also supported by Netconf despite > its document-orientation. (Any RPC could be addressed also through > parameters - think Ping MIB - I agree this would be awkward which is why > I consider this a feature.) To me, configuration is something that > guides the behavior of a system, versus an RPC which define actions to > be taken at a particular instant in time. This particular case is a > borderline case which can be argued either way, that I can agree with. > (I don't think whether an interface is enabled or disabled is just "any" > config parameter, it is of a different nature than e.g. a config > parameter that defines an interface name.) Do we have guidelines when > to use which? =20 If you want the value to be part of a config backup, it should be modelled as data. /martin From yihuan@cisco.com Wed Jun 13 15:25:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9D121F85C3 for ; Wed, 13 Jun 2012 15:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.75 X-Spam-Level: X-Spam-Status: No, score=-9.75 tagged_above=-999 required=5 tests=[AWL=0.849, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9x4AABjOpf0 for ; Wed, 13 Jun 2012 15:25:17 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id EED0321F85C2 for ; Wed, 13 Jun 2012 15:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=yihuan@cisco.com; l=1058; q=dns/txt; s=iport; t=1339626317; x=1340835917; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=v/0fQeRuz6amSejC9KOFH0MInA1UbKYqymaoGWwJr5Q=; b=X/vE9WELqDS2Epueardf/Zz0ITSUBgXWEJQi73omNmQnFmA/UkuLG420 BJiWYzFvb9KAsw2S+FtOxpZKoKUlBXzTcnxBLK45h2MqXKED0xtolj6VX sTxJ/sxlXTGrVKAI6Mjqb0DhM7x+pFdswZEb6r3PAFPeqbapJOLxm9EOP Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAE0S2U+rRDoI/2dsb2JhbABFtT6BB4IYAQEBAwESAScCATwTCA4KgQUGDgUJGYdkBAyaP6AEkUIDiEGMYIVUiEKBZoMA X-IronPort-AV: E=Sophos;i="4.75,766,1330905600"; d="scan'208";a="48851647" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 13 Jun 2012 22:25:16 +0000 Received: from [10.21.169.138] ([10.21.169.138]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5DMPFFh003120; Wed, 13 Jun 2012 22:25:16 GMT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Wed, 13 Jun 2012 15:25:14 -0700 From: "yihuan@cisco.com" To: Martin Bjorklund Message-ID: Thread-Topic: [netmod] review of draft-ietf-netmod-iana-if-type-04 In-Reply-To: <20120613.232111.304448987.mbj@tail-f.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-iana-if-type-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 22:25:17 -0000 I noticed that the MIB is lack of documentation as well. I would say it was poorly designed. I found an iana document which has more information. If you could add them to the YANG, it adds more value. http://www.iana.org/assignments/smi-numbers. Thanks, Lisa On 6/13/12 2:21 PM, "Martin Bjorklund" wrote: >Hi, > >"yihuan@cisco.com" wrote: >> I have reviewed draft-ietf-netmod-iana-if-type-04 and here are my >> comments/questions. >> 1. General comments. The enum and type definition needs more >>description or >> reference documentation. > >This module is just a YANG-version of the IANA "ifType definitions" >registry. So the text in the YANG module is the text in this >registry. > >> 2. >> 3. basicISDN and primaryISDN are no longer used. Should I-D use status >> 'obsolete'? > >Since they are not marked as obsolete in the IANA registry, they >are obsolete in this module. If they should be marked as obsolete, >the change should go into the IANA registry. > > >/martin From alex@cisco.com Wed Jun 13 18:51:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE0B11E80D2 for ; Wed, 13 Jun 2012 18:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5N8iYXF6Tfx for ; Wed, 13 Jun 2012 18:51:31 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3F54311E80CE for ; Wed, 13 Jun 2012 18:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=5223; q=dns/txt; s=iport; t=1339638691; x=1340848291; h=mime-version:subject:date:message-id:from:to; bh=LlP7QnXHj7l19n4XSRk++bvTPR8pzzxuCspH5XirfzQ=; b=c+xyTcJN79wkRut5sJCmPqwTicyOyVeXk/w1XRpYIWC3iPxikAmUkInL /WOY9yIE9tPKG6kxi2KCkLk/le1Q8S9re3kxp8sctkV7m8YFi1gWDs7ED gIxXEW/yL0v+o7CB/gN2IZaoB7iRQ7Z6bExhBLzCEu6DShjbAgm9kF/Tm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHND2U+rRDoG/2dsb2JhbABFgkWyfIEHghoBBAwGAQkRA1sBKgYYB1cBBBsah2gBmROBKKAGjiaCO2ADiEGadoFmgwA X-IronPort-AV: E=Sophos;i="4.75,768,1330905600"; d="scan'208,217";a="45763127" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 14 Jun 2012 01:51:30 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5E1pUfb004898 for ; Thu, 14 Jun 2012 01:51:30 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 18:51:30 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD49D0.3314839E" x-cr-puzzleid: {D27790B8-AD60-4091-9BE8-3BC02F92D18D} x-cr-hashedpuzzle: AC9C AIPT Akmn BoFI CsRF C4v1 DrIs EyO2 GA7s H2j8 JRcm JXXy J1tD KS84 KtdI K5dn; 1; bgBlAHQAbQBvAGQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {D27790B8-AD60-4091-9BE8-3BC02F92D18D}; YQBsAGUAeABAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Thu, 14 Jun 2012 01:51:19 GMT; RABhAHQAYQAgAG0AbwBkAGUAbAAgAHMAdAByAHUAYwB0AHUAcgBlACAAbgBvAHQAYQB0AGkAbwBuACAAYwBvAG4AdgBlAG4AdABpAG8AbgBzAA== Content-class: urn:content-classes:message Date: Wed, 13 Jun 2012 18:51:19 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790BC88851@xmb-sjc-239.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Data model structure notation conventions Thread-Index: Ac1J0DGlPuh6+sBYSC+dj60YluQFBg== From: "Alexander Clemm (alex)" To: X-OriginalArrivalTime: 14 Jun 2012 01:51:30.0812 (UTC) FILETIME=[382D23C0:01CD49D0] Subject: [netmod] Data model structure notation conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 01:51:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD49D0.3314839E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a question regarding the notation conventions with which the Internet Drafts provide an overview of the structure of YANG modules. (Example, section 3 in draft-ietf-netmod-interfaces-cfg-04) I really like that aspect of the Drafts a lot as it provides a very simple way to visualize what is going on and look at the forest, not the trees. =20 =20 I notice that "?" is used to indicate that a leaf is optional. What I am wondering is why it was not instead decided to use "!" to indicate that a leaf is mandatory. "Mandatory" was chosen as a substatement/keyword in YANG, not "optional", presumably because a much larger number of leaves would turn out to be optional than mandatory and hence a more compact specification would result. However, the same is true for the structure summary, where instead of appending most nodes with a "?", much fewer nodes could be appended with a "!" (and the connection with the corresponding YANG keywords would be more direct, not inversely direct, providing for slightly improved continuity). =20 =20 On similar lines, I am wondering whether it was considered to use a prefix when "config =3D false", instead of prepending every node with = "rw" or "ro" (the "r" itself looking redundant)? =20 =20 Regards --- Alex =20 ------_=_NextPart_001_01CD49D0.3314839E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a question regarding the notation = conventions with which the Internet Drafts provide an overview of the structure of YANG = modules.  (Example, section 3 in draft-ietf-netmod-interfaces-cfg-04)  I = really like that aspect of the Drafts a lot as it provides a very simple way to = visualize what is going on and look at the forest, not the trees.  =

 

I notice that “?” is used to indicate = that a leaf is optional. What I am wondering is why it was not instead decided = to use “!” to indicate that a leaf is mandatory.  “Mandatory” was = chosen as a substatement/keyword in YANG, not “optional”, = presumably because a much larger number of leaves would turn out to be optional = than mandatory and hence a more compact specification would result.  = However, the same is true for the structure summary, where instead of appending = most nodes with a “?”, much fewer nodes could be appended with a = “!” (and the connection with the corresponding YANG keywords would be more = direct, not inversely direct, providing for slightly improved continuity).  =

 

On similar lines, I am wondering whether it was = considered to use a prefix when “config =3D false”, instead of = prepending every node with “rw” or “ro” (the “r” = itself looking redundant)? 

 

Regards

--- Alex    

------_=_NextPart_001_01CD49D0.3314839E-- From lhotka@nic.cz Wed Jun 13 23:37:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EF321F86E5 for ; Wed, 13 Jun 2012 23:37:37 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEa4AmoVQuWf for ; Wed, 13 Jun 2012 23:37:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9480421F8551 for ; Wed, 13 Jun 2012 23:37:36 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 949DA13FB24; Thu, 14 Jun 2012 08:37:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339655851; bh=kvISYoL+auYMtru0Un1OdkuedyVaEIDzXTf9RnhdbZM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PPFf/wLDz44iOQ6tTWruvcBdTDkhrKrvaSq3w/fo70z9OVY4cn6QeaM4FMN0RbelZ ENGGz86+NdH7hwsaOOdR8f5R+/FyuzBU+xxtuNDl5BHjaugkJxPj2nV0Gt42p9WoBt NplSZyQsyigKP3ogJVMw2pk3Pfw+eWFOt05DvnxQ= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BC8884B@xmb-sjc-239.amer.cisco.com> Date: Thu, 14 Jun 2012 08:37:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <20A81050-3F9A-4DC8-B924-7C5CF7575A54@nic.cz> References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <61037589-3D44-455A-9DFF-5FC904870666@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC8821B@xmb-sjc-239.amer.cisco.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC8884B@xmb-sjc-239.amer.cisco.com> To: "Alexander Clemm (alex)" X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus on the way forwardwithNetconf-Light] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 06:37:37 -0000 On Jun 14, 2012, at 3:37 AM, Alexander Clemm (alex) wrote: > Hi, >=20 > here is one example: >=20 > The definition of identity allows to specify a base identity, allowing > to build an "identity hierarchy". However, if I subsequently want to > specify a condition or a constraint that pertains to all identities = that > were derived from the same base identity, I need to enumerate every > single one of the identities. This makes the definition of the > condition/constraint unnecessarily complex. Even worse, every time I > introduce a new identity that is derived from the same base identity, = I > need to update the conditions/constraints which may have been defined = in > an entirely different place. This basically also defeats the purpose = of > using identities, instead of enums, to allow for extending a set of > enumerated values without having to revise the original definition. Yes, one of the proposed XPath extension functions is derived-from(). = The others are: - deref() (for dereferencing instance identifiers), - is-bit-set(), - if-feature() - if-module() - if-capability() > =20 >=20 > For example, think of the following identity hierarchy: > flow > +-- audioflow > +-- pandora > +-- rhapsody > +-- spotify > +-- ... >=20 > If I have a constraint that pertains to audioflows, I need to = enumerate > a long list of subidentities instead of the single base identity, and > need to update that constraint whenever a new identity that identifies = a > new audioflow is introduced. =20 >=20 > (Maybe this part of the thread actually belongs on the netmod mailer, > not netconf) Right, so I am moving it to the netmod list. Lada > --- Alex >=20 >=20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 > Sent: Wednesday, June 13, 2012 2:13 AM > To: Alexander Clemm (alex); Carl Moberg > Cc: Netconf > Subject: RE: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying > aconsensus on the way forwardwithNetconf-Light] >=20 > "Alexander Clemm (alex)" writes: >=20 >> Just my 2 cents, one aspect that seems a bit clumsy in YANG concerns > the >> specification of conditions and constraints. While it is certainly >> possible to argue that it does the job, it is fairly hard to use. If > it >=20 > Could you be more specific? What is exactly hard? Is it that, for > example, one needs to carefully count the number of double dots in = order > to get to a remote node? Or missing semantics? >=20 >> is hard to use, things might be left up to implementations while they >> really should be captured in the spec. It might be worthwhile to >> consider possible alternatives to the current scheme, such as being > able >> to refer to a more "procedural" way to refer to constraints, rather > than >> the declarative way it is now. >=20 > We have been discussing the addition of several new XPath functions, = but > mainly for supporting special YANG data types, so nothing really > procedural. Can you give some examples? >=20 > Thanks, Lada >=20 >> --- Alex >>=20 >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of Carl Moberg >> Sent: Tuesday, June 12, 2012 6:52 AM >> To: Ladislav Lhotka >> Cc: Netconf >> Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying >> aconsensus on the way forwardwithNetconf-Light] >>=20 >>=20 >> On Jun 12, 2012, at 11:58 AM, Ladislav Lhotka wrote: >>=20 >>> Carl Moberg writes: >>>> For the record; I don't actually see any strong suggestions that >> there are any features that are "too heavy-weight, clumsy or broken" > in >> NETCONF or YANG. At least I have never heard that type of feedback > from >> the implementations that we've been working with. Sure, there are > issues >> and challenges with implementing server-side NETCONF (and YANG) >> particularly around retrofitting it on top of existing software >> infrastructure, but I have no experience that there are show stopping >> aspects to it that must be fixed. >>>=20 >>> OK, let me mention one thing: the design of is wrong. = A >> standard approach would be to have one expression for locating the > node >> to be updated and another one for specifying the changes. This is how > it >> is done e.g. in XQuery Update or in databases. attempts > to >> do both steps in one shot which doesn't really work all that great. >> While this may not be a showstopper, it certainly causes problems - > cf. >> the parallel discussion in the NETMOD list regarding keys for route >> lists. With a separate locator expression, the NETCONF client = wouldn't >> have to care about list keys all that much and just use any > appropriate >> attributes for selecting a list entry. >>=20 >>=20 >>=20 >> I agree that it's not perfect. It's about as good/bad as some other >> protocols (e.g. SNMP). But the point that I come back to is that it's >> certainly good enough (even with that imperfection and others) that = it >> has the potential to radically improve the way we do configuration >> management in networks. Making it a moving target instead of widely >> applying what we have would be a case of over optimization IMHO. >>=20 >> Now, this looks like one dead horse :-) >>=20 >> -- >> Carl Moberg, Tail-f Systems >> mailto:calle@tail-f.com >> twitter: @cmoberg >> http://www.tail-f.com/ >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Jun 13 23:54:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE5B21F8672 for ; Wed, 13 Jun 2012 23:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spYXexTPsCoa for ; Wed, 13 Jun 2012 23:54:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6E11D21F8671 for ; Wed, 13 Jun 2012 23:54:18 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9AFF220BD4; Thu, 14 Jun 2012 08:54:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id d4XMHE2tz-tJ; Thu, 14 Jun 2012 08:54:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BCBD20BC1; Thu, 14 Jun 2012 08:54:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 45FED1FC3D6A; Thu, 14 Jun 2012 08:54:15 +0200 (CEST) Date: Thu, 14 Jun 2012 08:54:15 +0200 From: Juergen Schoenwaelder To: "Alexander Clemm (alex)" Message-ID: <20120614065415.GA75228@elstar.local> Mail-Followup-To: "Alexander Clemm (alex)" , Martin Bjorklund , netmod@ietf.org References: <196FFAC4F80A9142A8C30A7EE9C33B790BBDE98A@xmb-sjc-239.amer.cisco.com> <20120612.133631.1256315680281708071.mbj@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC8834F@xmb-sjc-239.amer.cisco.com> <20120613.092408.1747766587053200776.mbj@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC88707@xmb-sjc-239.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BC88707@xmb-sjc-239.amer.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 06:54:19 -0000 On Wed, Jun 13, 2012 at 02:34:19PM -0700, Alexander Clemm (alex) wrote: > .... > > Unfortunately, this isn't really possible with standard YANG. You > cannot add constraints via augmentations. > > > > I believe the usefulness of the document would be improved if it could > > provide some guidance on how to do that instead of leaving it up to > > readers of the document to figure it out for themselves; it would make > > the spec easier to use and show implementers how the value of > YANG-based > > validation can still be derived. > > > > > So, is there another way of address this issue? What are implementers > to do if they have constraints - are there any recommendations that can > be made? > - Should they treat this outside Netconf/YANG? This is not very > satisfactory because it detriments the value proposition and usefulness > of this object as validation has to occur in different places anyway, > but being clear about it doesn't leave people second-guessing. > - Introduce augmentation with a second "shadow object" which does have > the appropriate constraints, including a constraint that its value must > mirror/be set to the same value of the other object? (That would > presumably be legal, correct?, but ugly & I hope not) > - Make use of deviation? > - Other options? > The simple answer is that a value that is not supported causes a meaningful error to be returned. As a matter of fact, it was never possible to capture all constraints in machine readable format. And while we talk here about constraints that originate from another standard, we also face reality constraints that are device or operating system specific. This grey area always existed and it will continue to exit. We deal with that by returning a meaningful error and textual descriptions. The reality is that my OS has certain restrictions. The SNMP MIB module has certain restrictions. The YANG module has certain restrictions. We do not know what the OS restrictions are so we can't do much (other than providing an error indication). We know what the SNMP restrictions are and we know that YANG supports a superset. This is what we deal with. The rest is outside. (In fact, there might be implementations that decide to support more flexible YANG names and choose to tweak the SNMP code to render stuff into what the IF-MIB allows - perhaps they needed to do this anyway because the underlying OS was never limited to IF-MIB contraints and perhaps not even to ietf-interfaces constraints as they do not even enforce a character set.) Bottom line: I believe what is in the I-D is the best we can do. /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 Jun 14 00:10:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E5C21F8472 for ; Thu, 14 Jun 2012 00:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0jZtPZq5E-I for ; Thu, 14 Jun 2012 00:10:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF7221F844F for ; Thu, 14 Jun 2012 00:10:26 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 6535A13FB24; Thu, 14 Jun 2012 09:10:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339657823; bh=Yhj2hCOByH+jnLu/0Qwksj4nqTWMWuNZwMekdDuS5cs=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PwhVbEy6Xd0eQIroa6KClahj3LZRGMPkrY5zc4c56NiZ1YDkblnqEA/OWLS/fwbsF Vp6p5HDbdT7Kwz3CK+vI8U+5w4ReB1FI7kwUBVX+KN/oZzrCVslVgGLqIDVWsfZ7Fp ACtEp/u+2p3CzDjPjaWgiPB6d5hMmI4O1Gx0sFwk= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ladislav Lhotka In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BC88851@xmb-sjc-239.amer.cisco.com> Date: Thu, 14 Jun 2012 09:10:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <969D1BA5-E60E-472B-A1C7-536A7B66DF74@nic.cz> References: <196FFAC4F80A9142A8C30A7EE9C33B790BC88851@xmb-sjc-239.amer.cisco.com> To: "Alexander Clemm (alex)" X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Data model structure notation conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 07:10:27 -0000 On Jun 14, 2012, at 3:51 AM, Alexander Clemm (alex) wrote: > Hi, > =20 > I have a question regarding the notation conventions with which the = Internet Drafts provide an overview of the structure of YANG modules. = (Example, section 3 in draft-ietf-netmod-interfaces-cfg-04) I really = like that aspect of the Drafts a lot as it provides a very simple way to = visualize what is going on and look at the forest, not the trees.=20 > =20 > I notice that =93?=94 is used to indicate that a leaf is optional. = What I am wondering is why it was not instead decided to use =93!=94 to = indicate that a leaf is mandatory. =93Mandatory=94 was chosen as a = substatement/keyword in YANG, not =93optional=94, presumably because a = much larger number of leaves would turn out to be optional than = mandatory and hence a more compact specification would result. However, = the same is true for the structure summary, where instead of appending = most nodes with a =93?=94, much fewer nodes could be appended with a =93!=94= (and the connection with the corresponding YANG keywords would be more = direct, not inversely direct, providing for slightly improved = continuity). I think it is a good point. Also, it might be helpful to indicate nodes = that are conditional, i.e. dependent on a 'when' statement. For example, = the subtree "routing-tables" in the routing draft looks like this: +--rw routing-tables +--rw routing-table [name] +--rw name +--rw address-family? +--rw safi? +--rw description? +--ro routes | +--ro route | +--ro source-protocol | +--ro age | +--ro outgoing-interface? | +--ro v4ur:dest-prefix? | +--ro v4ur:next-hop? | +--ro v6ur:dest-prefix? | +--ro v6ur:next-hop? =85 This gives a false impression that the data model contains sibling nodes = with the same local name ("dest-prefix" and "next-hop"), which would of = course be a dubious design. But it is not the case because each pair of = nodes is only valid for specific values of "address-family" and "safi" = (IPv4/IPv6 unicast). It is however more complicated than "?" (or "!") because entire subtrees = might be conditional. One possibility could be to change "+" into "*" for the root of the = conditional subtree and "|" into "I", for example *-- rw cond-container I +-- rw cond-leaf-1 I +-- rw cond-leaf-2 +-- rw noncond-leaf Lada > =20 > =20 > On similar lines, I am wondering whether it was considered to use a = prefix when =93config =3D false=94, instead of prepending every node = with =93rw=94 or =93ro=94 (the =93r=94 itself looking redundant)?=20 > =20 > Regards > --- Alex =20 > _______________________________________________ > 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 Jun 14 00:35:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA5621F8555 for ; Thu, 14 Jun 2012 00:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUB2hL5Mswem for ; Thu, 14 Jun 2012 00:35:26 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3635521F852D for ; Thu, 14 Jun 2012 00:35:26 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 2B3A81200DB8; Thu, 14 Jun 2012 09:35:24 +0200 (CEST) Date: Thu, 14 Jun 2012 09:35:23 +0200 (CEST) Message-Id: <20120614.093523.491095987.mbj@tail-f.com> To: yihuan@cisco.com From: Martin Bjorklund In-Reply-To: References: <20120613.232111.304448987.mbj@tail-f.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-iana-if-type-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 07:35:27 -0000 "yihuan@cisco.com" wrote: > I noticed that the MIB is lack of documentation as well. I would say it > was poorly designed. I found an iana document which has more information. > If you could add them to the YANG, it adds more value. > http://www.iana.org/assignments/smi-numbers. Actually, the YANG module was originally generated from this registry, and I have since then manually updated the last ~10 entries. So I believe the YANG module has all info found in the registry. The only exception is that the registry sometimes has a person's name/email listed as a reference - this info is not copied to the YANG module. Only references to proper documents are kept. If anything is missing, please let me know. /martin From mbj@tail-f.com Thu Jun 14 00:58:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A540821F85D1 for ; Thu, 14 Jun 2012 00:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0-nUAcxxsEK for ; Thu, 14 Jun 2012 00:58:37 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 103CE21F85CC for ; Thu, 14 Jun 2012 00:58:36 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 356CE1200DB8; Thu, 14 Jun 2012 09:58:36 +0200 (CEST) Date: Thu, 14 Jun 2012 09:58:35 +0200 (CEST) Message-Id: <20120614.095835.401067499.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BC88851@xmb-sjc-239.amer.cisco.com> References: <196FFAC4F80A9142A8C30A7EE9C33B790BC88851@xmb-sjc-239.amer.cisco.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Data model structure notation conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 07:58:37 -0000 Hi Alex, "Alexander Clemm (alex)" wrote: > I have a question regarding the notation conventions with which the > Internet Drafts provide an overview of the structure of YANG modules. > (Example, section 3 in draft-ietf-netmod-interfaces-cfg-04) I really > like that aspect of the Drafts a lot as it provides a very simple way to > visualize what is going on and look at the forest, not the trees. Glad you like it; I use it all the time when I get (large) data models to review and also during data model design. > I notice that "?" is used to indicate that a leaf is optional. What I am > wondering is why it was not instead decided to use "!" to indicate that > a leaf is mandatory. "Mandatory" was chosen as a substatement/keyword > in YANG, not "optional", presumably because a much larger number of > leaves would turn out to be optional than mandatory and hence a more > compact specification would result. However, the same is true for the > structure summary, where instead of appending most nodes with a "?", > much fewer nodes could be appended with a "!" (and the connection with > the corresponding YANG keywords would be more direct, not inversely > direct, providing for slightly improved continuity). > > On similar lines, I am wondering whether it was considered to use a > prefix when "config = false", instead of prepending every node with "rw" > or "ro" (the "r" itself looking redundant)? Good points! The reson for this is that I really liked the -f tree output from smidump, so I implemented -f tree in pyang, and I more or less used the same notation as smidump. The '?' and '*' was used simply b/c those are common symbols known to many people (from regexps), as are rw/ro. The complete syntax is: is one of: + for current x for deprecated o for obsolete is one of: rw for configuration data ro for non-configuration data -x for rpcs -n for notifications is the name of the node () means that the node is a choice node :() means that the node is a case node If the node is augmented into the tree from another module, its name is printed as :. is one of: ? for an optional leaf or presence container * for a leaf-list [] for a list's keys is the name of the type for leafs and leaf-lists So this tree output is typically generated using pyang, and then copied into the documents. pyang also has support for generating UML, javascript trees, and hyperbolic trees from YANG modules. See http://code.google.com/p/pyang/wiki/UMLOutput and http://code.google.com/p/pyang/wiki/JSTreeandHyperTree for screenshots. /martin From mbj@tail-f.com Thu Jun 14 01:08:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E79821F866D for ; Thu, 14 Jun 2012 01:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-0.879, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhOz6va0OCk4 for ; Thu, 14 Jun 2012 01:08:32 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id EC07E21F866B for ; Thu, 14 Jun 2012 01:08:31 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id B8A581200DB8; Thu, 14 Jun 2012 10:08:30 +0200 (CEST) Date: Thu, 14 Jun 2012 10:08:30 +0200 (CEST) Message-Id: <20120614.100830.145536564.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <969D1BA5-E60E-472B-A1C7-536A7B66DF74@nic.cz> References: <196FFAC4F80A9142A8C30A7EE9C33B790BC88851@xmb-sjc-239.amer.cisco.com> <969D1BA5-E60E-472B-A1C7-536A7B66DF74@nic.cz> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Data model structure notation conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 08:08:32 -0000 Ladislav Lhotka wrote: > > On Jun 14, 2012, at 3:51 AM, Alexander Clemm (alex) wrote: > > > Hi, > > > > I have a question regarding the notation conventions with which the Internet > > Drafts provide an overview of the structure of YANG modules. (Example, > > section 3 in draft-ietf-netmod-interfaces-cfg-04) I really like that aspect > > of the Drafts a lot as it provides a very simple way to visualize what is > > going on and look at the forest, not the trees. > > > > I notice that $B!H(B?$B!I(B is used to indicate that a leaf is optional. What I am > > wondering is why it was not instead decided to use $B!H(B!$B!I(B to indicate that a > > leaf is mandatory. $B!H(BMandatory$B!I(B was chosen as a substatement/keyword in YANG, > > not $B!H(Boptional$B!I(B, presumably because a much larger number of leaves would turn > > out to be optional than mandatory and hence a more compact specification > > would result. However, the same is true for the structure summary, where > > instead of appending most nodes with a $B!H(B?$B!I(B, much fewer nodes could be > > appended with a $B!H(B!$B!I(B (and the connection with the corresponding YANG keywords > > would be more direct, not inversely direct, providing for slightly improved > > continuity). > > I think it is a good point. Also, it might be helpful to indicate nodes that > are conditional, i.e. dependent on a 'when' statement. For example, the subtree > "routing-tables" in the routing draft looks like this: > > +--rw routing-tables > +--rw routing-table [name] > +--rw name > +--rw address-family? > +--rw safi? > +--rw description? > +--ro routes > | +--ro route > | +--ro source-protocol > | +--ro age > | +--ro outgoing-interface? > | +--ro v4ur:dest-prefix? > | +--ro v4ur:next-hop? > | +--ro v6ur:dest-prefix? > | +--ro v6ur:next-hop? > $B!D(B > > This gives a false impression that the data model contains sibling nodes with > the same local name ("dest-prefix" and "next-hop"), which would of course be a > dubious design. But it is not the case because each pair of nodes is only valid > for specific values of "address-family" and "safi" (IPv4/IPv6 unicast). > > It is however more complicated than "?" (or "!") because entire subtrees might > be conditional. > One possibility could be to change "+" into "*" for the root of the conditional > subtree and "|" into "I", for example > > *-- rw cond-container > I +-- rw cond-leaf-1 > I +-- rw cond-leaf-2 > +-- rw noncond-leaf When I implemented the output in pyang I tried some different ideas, but soon realized that using too many symbols make the diagram difficult to read. I would like to be able to give the diagram to people without too much YANG knowledge, and they should be able to get the idea. We have to accept that we cannot capture everything in this diagram - it gives an informative overview of the structure; for details you have to go the YANG definitions. One thing I did add was a weird syntax for choice/case; it is not obvious it helps... /martin From mbj@tail-f.com Thu Jun 14 01:19:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DED21F86A1 for ; Thu, 14 Jun 2012 01:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJaTIeTf0xPP for ; Thu, 14 Jun 2012 01:19:58 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id EB33021F869F for ; Thu, 14 Jun 2012 01:19:56 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 335801200DB8; Thu, 14 Jun 2012 10:19:56 +0200 (CEST) Date: Thu, 14 Jun 2012 10:19:55 +0200 (CEST) Message-Id: <20120614.101955.325070865.mbj@tail-f.com> To: alex@cisco.com From: Martin Bjorklund In-Reply-To: <196FFAC4F80A9142A8C30A7EE9C33B790BC8873E@xmb-sjc-239.amer.cisco.com> References: <196FFAC4F80A9142A8C30A7EE9C33B790BC88707@xmb-sjc-239.amer.cisco.com> <20120613.235236.119602680.mbj@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC8873E@xmb-sjc-239.amer.cisco.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 08:19:58 -0000 "Alexander Clemm (alex)" wrote: > Hi Martin, > > thank you for your response to the 2nd item. > > Regarding the 1st, in short what you are saying is that we are running > into the limitations of YANG here (which implementers in this case will > likely encounter) but it should not necessary to give guidance. I > understand that you can add enforcements in separate code and describe > them separate from the YANG module itself. I had been wondering if it > is possible to do a little better than that but I can live with it. I think Juergen's reply describes the problem well. As for the guidance part; I think that the current text is sufficient when it says: This leaf MAY be mapped to ifName by an implementation. Such an implementation MAY restrict the allowed values for this leaf so that it matches the restrictions of ifName. If a NETCONF server that implements this restriction is sent a value that doesn't match the restriction, it MUST reply with an rpc-error with the error-tag 'invalid-value'."; reference "RFC 2863: The Interfaces Group MIB - ifName"; (the last sentence is new) The text mentions that ifName has some restrictions, and it gives a reference to its defintion. But in general I absolutely agree with you. A formal definition of a restriction is better than one described in plain text. However, sometimes it is not possible to define a restriction formally (depending on the formal language available of course). /martin From lhotka@nic.cz Thu Jun 14 01:28:11 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8507E21F85D5 for ; Thu, 14 Jun 2012 01:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jj3aVlCNEMqG for ; Thu, 14 Jun 2012 01:28:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5791D21F8599 for ; Thu, 14 Jun 2012 01:28:10 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id A08F913FB24; Thu, 14 Jun 2012 10:28:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339662489; bh=tti6f9G1GWGFCntiPGwB57KIt2Wd9+uaKZIJrtiChgI=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pI6Lc/4oOupiqHnr+zFY6SgikvWhkyhm08+zudBpVty8Tz1Jcrz3Hb08mKihMrIMH OF8Z9jaoZq7OknqaE6BbZk2WPXJz79rsNpNv++G/2hZjM0E0PKwzuFx7CYpdIjTBWP jM/0Zh1BMriomtZfVEwR4Nu8La+OHWDQNi4NDsl8= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-2022-jp From: Ladislav Lhotka In-Reply-To: <20120614.100830.145536564.mbj@tail-f.com> Date: Thu, 14 Jun 2012 10:28:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0ED6C039-955C-4F79-B33C-3DEC26C447E7@nic.cz> References: <196FFAC4F80A9142A8C30A7EE9C33B790BC88851@xmb-sjc-239.amer.cisco.com> <969D1BA5-E60E-472B-A1C7-536A7B66DF74@nic.cz> <20120614.100830.145536564.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Data model structure notation conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 08:28:11 -0000 On Jun 14, 2012, at 10:08 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Jun 14, 2012, at 3:51 AM, Alexander Clemm (alex) wrote: >>=20 >>> Hi, >>>=20 >>> I have a question regarding the notation conventions with which the = Internet >>> Drafts provide an overview of the structure of YANG modules. = (Example, >>> section 3 in draft-ietf-netmod-interfaces-cfg-04) I really like that = aspect >>> of the Drafts a lot as it provides a very simple way to visualize = what is >>> going on and look at the forest, not the trees. >>>=20 >>> I notice that =1B$B!H=1B(B?=1B$B!I=1B(B is used to indicate that a = leaf is optional. What I am >>> wondering is why it was not instead decided to use =1B$B!H=1B(B!=1B$B!= I=1B(B to indicate that a >>> leaf is mandatory. =1B$B!H=1B(BMandatory=1B$B!I=1B(B was chosen as = a substatement/keyword in YANG, >>> not =1B$B!H=1B(Boptional=1B$B!I=1B(B, presumably because a much = larger number of leaves would turn >>> out to be optional than mandatory and hence a more compact = specification >>> would result. However, the same is true for the structure summary, = where >>> instead of appending most nodes with a =1B$B!H=1B(B?=1B$B!I=1B(B, = much fewer nodes could be >>> appended with a =1B$B!H=1B(B!=1B$B!I=1B(B (and the connection with = the corresponding YANG keywords >>> would be more direct, not inversely direct, providing for slightly = improved >>> continuity). >>=20 >> I think it is a good point. Also, it might be helpful to indicate = nodes that >> are conditional, i.e. dependent on a 'when' statement. For example, = the subtree >> "routing-tables" in the routing draft looks like this: >>=20 >> +--rw routing-tables >> +--rw routing-table [name] >> +--rw name >> +--rw address-family? >> +--rw safi? >> +--rw description? >> +--ro routes >> | +--ro route >> | +--ro source-protocol >> | +--ro age >> | +--ro outgoing-interface? >> | +--ro v4ur:dest-prefix? >> | +--ro v4ur:next-hop? >> | +--ro v6ur:dest-prefix? >> | +--ro v6ur:next-hop? >> =1B$B!D=1B(B >>=20 >> This gives a false impression that the data model contains sibling = nodes with >> the same local name ("dest-prefix" and "next-hop"), which would of = course be a >> dubious design. But it is not the case because each pair of nodes is = only valid >> for specific values of "address-family" and "safi" (IPv4/IPv6 = unicast). >>=20 >> It is however more complicated than "?" (or "!") because entire = subtrees might >> be conditional. >> One possibility could be to change "+" into "*" for the root of the = conditional >> subtree and "|" into "I", for example >>=20 >> *-- rw cond-container >> I +-- rw cond-leaf-1 >> I +-- rw cond-leaf-2 >> +-- rw noncond-leaf >=20 > When I implemented the output in pyang I tried some different ideas, > but soon realized that using too many symbols make the diagram > difficult to read. I would like to be able to give the diagram to > people without too much YANG knowledge, and they should be able to get > the idea. We have to accept that we cannot capture everything in this > diagram - it gives an informative overview of the structure; for > details you have to go the YANG definitions. Yes, it is not easy to find the right compromise. In the routing draft I = also removed the datatypes on the right, but that was because some lines = exceeded 72 chars. >=20 > One thing I did add was a weird syntax for choice/case; it is not > obvious it helps=1B$B!D=1B(B But it would be really confusing without it. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mrothman@cisco.com Wed Jun 13 17:48:17 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F9511E80DB for ; Wed, 13 Jun 2012 17:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyFBsSYC--9x for ; Wed, 13 Jun 2012 17:48:14 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 351E111E80C2 for ; Wed, 13 Jun 2012 17:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mrothman@cisco.com; l=54655; q=dns/txt; s=iport; t=1339634894; x=1340844494; h=mime-version:subject:date:message-id:from:to; bh=4Rq61UeT7qQjKFFd4Nh02tr+hMu2egFYenhbXTaB9hM=; b=AQZuDO+RN0M4mz9egXHRzVrU4BcQxWvmJ813yhvkKUfIKKdyYrq1o9A8 bGJyYG6K/FH0IxE1CiTEEcS2VxdczQjrwBPZCFPdRwJiXOOMngV5GpCy8 HJeP5SHd71jixwovT3NppNiRbnCp5BJJpB8ciL82x+kUUVcGSdZKH6DGA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADQ02U+rRDoI/2dsb2JhbABFgkWyfIEHghoBBBIBCREDWwEaEAYQAQcHSA8BBBsah2gBmRGBKKAHkGFgA4hBmnaBZoMA X-IronPort-AV: E=Sophos;i="4.75,768,1330905600"; d="scan'208,217";a="48869527" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 14 Jun 2012 00:48:13 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5E0mDUv006885 for ; Thu, 14 Jun 2012 00:48:13 GMT Received: from xmb-sjc-22b.amer.cisco.com ([128.107.191.112]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Jun 2012 17:48:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD49C7.6070A9F9" Date: Wed, 13 Jun 2012 17:48:11 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: YANG-types for Multicast Addresses Thread-Index: Ac1Jx1/XkTgWMrIeTseBH3PGEIIppw== From: "Markus Rothmann -X (mrothman - Universitaet der Bundeswehr Muenchen at Cisco)" To: X-OriginalArrivalTime: 14 Jun 2012 00:48:12.0992 (UTC) FILETIME=[607FCC00:01CD49C7] X-Mailman-Approved-At: Thu, 14 Jun 2012 02:31:02 -0700 Subject: [netmod] YANG-types for Multicast Addresses X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 00:54:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD49C7.6070A9F9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, in the process of defining a YANG module for IP-multicast, I have written some types based on the "IP-address"-types in the ietf-inet-types module ("urn:ietf:params:xml:ns:yang:ietf-inet-types"). They further restrict the patterns used to match the ranges 224/4 and ff00::/8 for IP-multicast and 232/8 and FF3x::/32 for source-specific multicast. Are these types of more general interest? Are there suggestions where those definitions should be added? =20 Regards, __________ Markus Rothmann, B.Sc. University of the German Federal Armed Forces Munich Cisco NOSTG Architecture, SJ-23 =20 =20 =20 =20 typedef IP-Multicast-Group-Address { description "The IP-Multicast-Group-Address type represents an IP multicast address and is IP version neutral. The format of the textual representations implies the IP version."; type union { type IPv4-Multicast-Group-Address; type IPv6-Multicast-Group-Address; } =20 } // typedef IP-Multicast-Group-Address =20 =20 typedef IPv4-Multicast-Group-Address { description "The IPv4-Multicast-Group-Address type represents an IPv4 multicast address in dotted-quad notation."; reference "RFC4607"; type string { pattern '(2((2[4-9])|(3[0-9]))\.)(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0 -5])\.){2}([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; } } // typedef IPv4-Multicast-Group-Address =20 =20 typedef IPv6-Multicast-Group-Address { description "The IPv6-Multicast-Group-Address type represents an IPv6 address in full, mixed, shortened, and shortened-mixed notation."; reference "RFC4291 2.7. ietf-inet-types:ipv6-address"; type string { pattern =20 '(((FF|ff)[0-9a-fA-F]{2}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:) ?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25 [0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'; pattern =20 '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^: ]+)?)'; } } // typedef IPv6-Multicast-Group-Address =20 =20 =20 =20 typedef IP-Multicast-Group-Address-Prefix { description "The IP-Multicast-Group-Address-Prefix type represents an IP multicast address prefix and is IP version neutral. The format of the textual representations implies the IP version. It includes a prefix-length, separated by a '/' sign."; type union { type IPv4-Multicast-Group-Address-Prefix; type IPv6-Multicast-Group-Address-Prefix; } =20 } // typedef IP-Multicast-Group-Address-Prefix =20 =20 typedef IPv4-Multicast-Group-Address-Prefix { description "The IPv4-Multicast-Group-Address-Prefix type represents an IPv4 multicast address prefix in dotted-quad notation. It includes a prefix-length, separated by a '/' sign."; reference "RFC4607"; type string { pattern '(2((2[4-9])|(3[0-9]))\.)(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0 -5])\.){2}([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(/(([4-9])|( [1-2][0-9])|(3[0-2])))'; } } // typedef IPv4-Multicast-Group-Address-Prefix =20 =20 typedef IPv6-Multicast-Group-Address-Prefix { description "The IPv6-Multicast-Group-Address-Prefix type represents an IPv6 multicast address prefix in full, mixed, shortened, and shortened-mixed notation. It includes a prefix-length, separated by a '/' sign."; reference "RFC4291 2.7. ietf-inet-types:ipv6-address"; type string { pattern =20 '(((FF|ff)[0-9a-fA-F]{2}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:) ?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25 [0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))(/((1[6-9])|([2-9][0-9])|(1[0-1][0- 9])|(12[0-8])))'; pattern =20 '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^: ]+)?)(/.+)'; } } // typedef IPv6-Multicast-Group-Address-Prefix =20 =20 =20 =20 typedef IP-SSM-Group-Address { description "The IP-SSM-Group-Address type represents an IP source-specific multicast address and is IP version neutral. The format of the textual representations implies the IP version."; type union { type IPv4-SSM-Group-Address; type IPv6-SSM-Group-Address; } } // typedef IP-SSM-Group-Address =20 =20 typedef IPv4-SSM-Group-Address { description "The IPv4-SSM-Group-Address type represents an IPv4 source-specific multicast address in dotted-quad notation. IPv4 addresses in the 232/8 range are designated as SSM."; reference "RFC4607 IANA IPv4 Multicast Address Space Registry"; type string { pattern '(232\.)(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){2}([0-9]| [1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; } } // typedef IPv4-SSM-Group-Address =20 =20 typedef IPv6-SSM-Group-Address { description "The IPv6-SSM-Group-Address type represents an IPv6 source-specific multicast group address in shortened and shortened-mixed notation."; reference "RFC4607"; type string { pattern =20 '((FF3|ff3)([0-9a-fA-F]{1}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4} :)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}( 25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'; pattern =20 '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]+)?::(([^:]+:)*[^: ]+)?)'; } } // typedef IPv6-SSM-Group-Address =20 =20 =20 =20 ------_=_NextPart_001_01CD49C7.6070A9F9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,= 

in the process =
of defining a YANG module for IP-multicast, I have written some types =
based on the “IP-address”-types in the ietf-inet-types =
module ("urn:ietf:params:xml:ns:yang:ietf-inet-types"). They =
further restrict the patterns used to match the ranges 224/4 and =
ff00::/8 for IP-multicast and 232/8 and FF3x::/32 for source-specific =
multicast. Are these types of more general =
interest?
Are there suggestions where =
those definitions should be added?
 
Regards,


__________



Markus
Rothmann, B.Sc.



University
of the German Federal Armed Forces Munich



Cisco
NOSTG Architecture, SJ-23



 
 
 


 



       =
typedef =
IP-Multicast-Group-Address
{



      &nb=
sp;     
description=
 =
"The
IP-Multicast-Group-Address type represents an IP multicast address and =
is IP
version neutral. The format of the textual representations implies the =
IP
version.";



      &nb=
sp;     
type=
 =
union =
{



      &nb=
sp;           &nbs=
p;
type=

IPv4-Multicast-Group-Address;



      &nb=
sp;           &nbs=
p;
type=

IPv6-Multicast-Group-Address;



      &nb=
sp;     
}            =




       } =
// typedef
IP-Multicast-Group-Address



 



 



       =
typedef
IPv4-Multicast-Group-Address {



      &nb=
sp;     
description=
 =
"The =
IPv4-Multicast-Group-Address
type represents an IPv4 multicast address in dotted-quad =
notation.";



      &nb=
sp;     
reference =
"RFC46=
07";



      &nb=
sp;     
type=
 =
string =
{



      &nb=
sp;           &nbs=
p;
pattern =
'(2((2[4-9]=
)|(3[0-9]))\.)(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){2}([=
0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';



      &nb=
sp;     
}



       } =
// typedef
IPv4-Multicast-Group-Address



 



 



       =
typedef
IPv6-Multicast-Group-Address {



      &nb=
sp;     
description=
 =
"The =
IPv6-Multicast-Group-Address
type represents an IPv6 address in full, mixed, shortened, and =
shortened-mixed
notation.";



      &nb=
sp;     
reference =
"RFC42=
91 2.7.



      &=
nbsp;           &n=
bsp;       
   ietf-inet-types:ipv6-address";



      &nb=
sp;     
type=
 =
string =
{



      &nb=
sp;           &nbs=
p;
pattern



      &nb=
sp;           &nbs=
p;       
'(((FF|ff)[=
0-9a-fA-F]{2}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA=
-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][=
0-9]|[01]?[0-9]?[0-9])))';



      &nb=
sp;           &nbs=
p;
pattern



      &nb=
sp;           &nbs=
p;
       '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*))=
)|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)';



      
       }



       } =
// typedef
IPv6-Multicast-Group-Address



 



 



 



 



       =
typedef
IP-Multicast-Group-Address-Prefix {



      &nb=
sp;     
description=
 =
"The
IP-Multicast-Group-Address-Prefix type represents an IP multicast =
address
prefix and is IP version neutral. The format of the textual =
representations
implies the IP version. It includes a prefix-length, separated by a '/'
sign.";



      &nb=
sp;     
type=
 =
union =
{



      &nb=
sp;           &nbs=
p;
type=

IPv4-Multicast-Group-Address-Prefix;



      &nb=
sp;           &nbs=
p;
type=

IPv6-Multicast-Group-Address-Prefix;



      &nb=
sp;     
}            =




       } =
// typedef
IP-Multicast-Group-Address-Prefix



 



 



       =
typedef =
IPv4-Multicast-Group-Address-Prefix
{



      &nb=
sp;     
description=
 =
"The
IPv4-Multicast-Group-Address-Prefix type represents an IPv4 multicast =
address
prefix in dotted-quad notation. It includes a prefix-length, separated =
by a '/'
sign.";



      &nb=
sp;     
reference =
"RFC46=
07";



      &nb=
sp;     
type=
 =
string =
{



      &nb=
sp;           &nbs=
p;
pattern =
'(2((2[4-9]=
)|(3[0-9]))\.)(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){2}([=
0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])(/(([4-9])|([1-2][0-9])|(=
3[0-2])))';



      &nb=
sp;     
}



       } =
// typedef
IPv4-Multicast-Group-Address-Prefix



 



 



       =
typedef
IPv6-Multicast-Group-Address-Prefix {



      &nb=
sp;     
description=
 =
"The
IPv6-Multicast-Group-Address-Prefix type represents an IPv6 multicast =
address
prefix in full, mixed, shortened, and shortened-mixed notation. It =
includes a
prefix-length, separated by a '/' sign.";



      &nb=
sp;     
reference =
"RFC42=
91 2.7.



      &=
nbsp;           &n=
bsp;       
   ietf-inet-types:ipv6-address";



      &nb=
sp;     
type=
 =
string =
{



      &nb=
sp;           &nbs=
p;
pattern



      &nb=
sp;           &nbs=
p;       
'(((FF|ff)[=
0-9a-fA-F]{2}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA=
-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][=
0-9]|[01]?[0-9]?[0-9])))(/((1[6-9])|([2-9][0-9])|(1[0-1][0-9])|(12[0-8]))=
)';



      &nb=
sp;           &nbs=
p;
pattern



      &nb=
sp;           &nbs=
p;
       '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*))=
)|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(/.+)';



      &nb=
sp;     
}



       } =
// typedef
IPv6-Multicast-Group-Address-Prefix



       =




 



 



 



       =
typedef =
IP-SSM-Group-Address
{



      &nb=
sp;     
description=
 =
"The
IP-SSM-Group-Address type represents an IP source-specific multicast =
address
and is IP version neutral. The format of the textual representations =
implies
the IP version.";



      &nb=
sp;     
type=
 =
union =
{



      &nb=
sp;           &nbs=
p;
type=
 =
IPv4-SSM-Group-Address;



      &nb=
sp;           &nbs=
p;
type=

IPv6-SSM-Group-Address;



      &nb=
sp;     
}



       } =
// typedef
IP-SSM-Group-Address



       =




 



       =
typedef
IPv4-SSM-Group-Address {



      &nb=
sp;     
description=
 =
"The =
IPv4-SSM-Group-Address
type represents an IPv4 source-specific multicast address in dotted-quad
notation.



      &=
nbsp;           &n=
bsp;           &nb=
sp; 
 IPv4 addresses in the 232/8 range are designated as =
SSM.";



      &nb=
sp;     
reference =
"RFC46=
07



      &=
nbsp;           &n=
bsp;           &nb=
sp; 
IANA IPv4 Multicast Address Space Registry";



      &nb=
sp;     
type=
 =
string =
{



      &nb=
sp;           &nbs=
p;
pattern =
'(232\.)(([=
0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){2}([0-9]|[1-9][0-9]|1=
[0-9][0-9]|2[0-4][0-9]|25[0-5])';



      &nb=
sp;     
}



       } =
// typedef
IPv4-SSM-Group-Address



       =




 



       =
typedef
IPv6-SSM-Group-Address {



      &nb=
sp;     
description=
  =
"The
IPv6-SSM-Group-Address type represents an IPv6 source-specific multicast =
group
address in shortened and shortened-mixed notation.";



      &nb=
sp;     
reference =
"RFC46=
07";



      &nb=
sp;     
type=
 =
string =
{



      &nb=
sp;           &nbs=
p;
pattern



      &nb=
sp;           &nbs=
p;       
'((FF3|ff3)=
([0-9a-fA-F]{1}):)([0-9a-fA-F]{0,4}:){0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-=
fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4=
][0-9]|[01]?[0-9]?[0-9])))';



      &nb=
sp;           &nbs=
p;
pattern



      &nb=
sp;           &nbs=
p;
       '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*))=
)|((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)';



      &nb=
sp;     
}



       } // typedef
IPv6-SSM-Group-Address



 



 



 



 
------_=_NextPart_001_01CD49C7.6070A9F9-- From alex@cisco.com Thu Jun 14 14:28:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C90821F85BD for ; Thu, 14 Jun 2012 14:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lk7ufOLGKJ4 for ; Thu, 14 Jun 2012 14:28:54 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 66C6D21F84A0 for ; Thu, 14 Jun 2012 14:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=3216; q=dns/txt; s=iport; t=1339709334; x=1340918934; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DVoRcdR2xoe58AWB66DksYFjldDX8TI4Lo+vMC+Cy/A=; b=RTkb0v5FYs+TFLxokBy3BrnTSYf671mTG6rUZ+GtYLaBIOCWKYmsj8aG Gl8z50vm8gF1UbR49oditqDEuPR7y4ur2I33Ciq6CjiS32S18qQ1/MFMJ ovKbi/RJAcvL1CTiBuqUkB2AthRJzHqZqhchnJJsBRdAGoXhTKnSgRw8L A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN9W2k+rRDoG/2dsb2JhbABFtT6BB4IYAQEBAwESAR0KPwUHBAIBCA4DBAEBAQoGFwEGAUUJCAEBBBMIGodkBAELmXegDosyhTFgA4hBjXKNBIFmgwA X-IronPort-AV: E=Sophos;i="4.75,773,1330905600"; d="scan'208";a="48911832" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 14 Jun 2012 21:28:54 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5ELSsv3006809; Thu, 14 Jun 2012 21:28:54 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jun 2012 14:28:53 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jun 2012 14:28:53 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790BC88ABD@xmb-sjc-239.amer.cisco.com> In-Reply-To: <20120614.095835.401067499.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Data model structure notation conventions Thread-Index: Ac1KA4HFWWQvjvteTCWEl7wLXjtmEQAcPlVA References: <196FFAC4F80A9142A8C30A7EE9C33B790BC88851@xmb-sjc-239.amer.cisco.com> <20120614.095835.401067499.mbj@tail-f.com> From: "Alexander Clemm (alex)" To: "Martin Bjorklund" X-OriginalArrivalTime: 14 Jun 2012 21:28:53.0950 (UTC) FILETIME=[B2C48DE0:01CD4A74] Cc: netmod@ietf.org Subject: Re: [netmod] Data model structure notation conventions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:28:55 -0000 Thanks, Martin, for the explanation. =20 --- Alex -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Thursday, June 14, 2012 12:59 AM To: Alexander Clemm (alex) Cc: netmod@ietf.org Subject: Re: [netmod] Data model structure notation conventions Hi Alex, "Alexander Clemm (alex)" wrote: > I have a question regarding the notation conventions with which the > Internet Drafts provide an overview of the structure of YANG modules. > (Example, section 3 in draft-ietf-netmod-interfaces-cfg-04) I really > like that aspect of the Drafts a lot as it provides a very simple way to > visualize what is going on and look at the forest, not the trees. =20 Glad you like it; I use it all the time when I get (large) data models to review and also during data model design. > I notice that "?" is used to indicate that a leaf is optional. What I am > wondering is why it was not instead decided to use "!" to indicate that > a leaf is mandatory. "Mandatory" was chosen as a substatement/keyword > in YANG, not "optional", presumably because a much larger number of > leaves would turn out to be optional than mandatory and hence a more > compact specification would result. However, the same is true for the > structure summary, where instead of appending most nodes with a "?", > much fewer nodes could be appended with a "!" (and the connection with > the corresponding YANG keywords would be more direct, not inversely > direct, providing for slightly improved continuity). =20 > > On similar lines, I am wondering whether it was considered to use a > prefix when "config =3D false", instead of prepending every node with "rw" > or "ro" (the "r" itself looking redundant)? =20 Good points! The reson for this is that I really liked the -f tree output from smidump, so I implemented -f tree in pyang, and I more or less used the same notation as smidump. The '?' and '*' was used simply b/c those are common symbols known to many people (from regexps), as are rw/ro. The complete syntax is: is one of: + for current x for deprecated o for obsolete is one of: rw for configuration data ro for non-configuration data -x for rpcs -n for notifications is the name of the node () means that the node is a choice node :() means that the node is a case node If the node is augmented into the tree from another module, its name is printed as :. is one of: ? for an optional leaf or presence container * for a leaf-list [] for a list's keys is the name of the type for leafs and leaf-lists So this tree output is typically generated using pyang, and then copied into the documents. pyang also has support for generating UML, javascript trees, and hyperbolic trees from YANG modules. See http://code.google.com/p/pyang/wiki/UMLOutput and http://code.google.com/p/pyang/wiki/JSTreeandHyperTree for screenshots. /martin From alex@cisco.com Thu Jun 14 15:26:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08F11E809B for ; Thu, 14 Jun 2012 15:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.269 X-Spam-Level: X-Spam-Status: No, score=-10.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSjfJR-gVTuz for ; Thu, 14 Jun 2012 15:26:25 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBC911E807F for ; Thu, 14 Jun 2012 15:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=6263; q=dns/txt; s=iport; t=1339712780; x=1340922380; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tNqqtFHhVerXS0OHFa4Z27aw2Xc8FYfHbnuRI+Zq46o=; b=kREbQ6ZCr7taMM2sgZmfm/6lx1gGF+gNFZfs9o7pFu+xAo6awSRPoJ/1 SUP62hgjp63mZAf01W989UM5olUZvrKfwqIkaZjsut0SEKmO0Ad08lAAN XnneIkwyZ/O4EiaK74yhD6lWz/QaL9IEl8Xom+Zou/FOdXL8J2Jfa84MG E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANBk2k+rRDoG/2dsb2JhbAA8CbU9gQeCGAEBAQMBAQEBDwEdCjQLBQcEAgEIEQQBAQEKBhMEAQYBJh8JCAEBBBMIGodkBAELmXagDosyEYUgYAOIQZp2gWaDAA X-IronPort-AV: E=Sophos;i="4.75,773,1330905600"; d="scan'208";a="49001465" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 14 Jun 2012 22:26:19 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q5EMQJZt008968; Thu, 14 Jun 2012 22:26:19 GMT Received: from xmb-sjc-239.amer.cisco.com ([128.107.191.105]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jun 2012 15:26:19 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {C4FFA419-D300-4C09-A12B-93954F069CBE} x-cr-hashedpuzzle: DREa EsmX HAPK IXOE IpXa JGaz JrGY MWv+ N4Dl N4ES PhJE QzaF R/1m SCcX SOZM ThVF; 2; bABoAG8AdABrAGEAQABuAGkAYwAuAGMAegA7AG4AZQB0AG0AbwBkAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {C4FFA419-D300-4C09-A12B-93954F069CBE}; YQBsAGUAeABAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Thu, 14 Jun 2012 22:26:14 GMT; UgBFADoAIABbAE4AZQB0AGMAbwBuAGYAXQAgAFcARwAgAEMAbwBuAHMAZQBuAHMAdQBzACAAYwBhAGwAbAA6ACAATgBlAHQAYwBvAG4AZgAgADIALgAwAD8AIABbAHcAYQBzADoAIABUAHIAeQBpAG4AZwAgAGEAYwBvAG4AcwBlAG4AcwB1AHMAIABvAG4AIAB0AGgAZQAgAHcAYQB5ACAAZgBvAHIAdwBhAHIAZAB3AGkAdABoAE4AZQB0AGMAbwBuAGYALQBMAGkAZwBoAHQAXQA= Content-class: urn:content-classes:message Date: Thu, 14 Jun 2012 15:26:14 -0700 Message-ID: <196FFAC4F80A9142A8C30A7EE9C33B790BC88B2D@xmb-sjc-239.amer.cisco.com> In-Reply-To: <20A81050-3F9A-4DC8-B924-7C5CF7575A54@nic.cz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus on the way forwardwithNetconf-Light] Thread-Index: Ac1J+DGOCZJndkgPTlinDwTZX7xmEAAhAuCQ References: <201206111248.q5BCmC02017907@idle.juniper.net> <3F92D55E-A617-4834-9A9B-0D46D5624744@nic.cz> <61037589-3D44-455A-9DFF-5FC904870666@tail-f.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC8821B@xmb-sjc-239.amer.cisco.com> <196FFAC4F80A9142A8C30A7EE9C33B790BC8884B@xmb-sjc-239.amer.cisco.com> <20A81050-3F9A-4DC8-B924-7C5CF7575A54@nic.cz> From: "Alexander Clemm (alex)" To: "Ladislav Lhotka" X-OriginalArrivalTime: 14 Jun 2012 22:26:19.0543 (UTC) FILETIME=[B8805270:01CD4A7C] Cc: netmod@ietf.org Subject: Re: [netmod] [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus on the way forwardwithNetconf-Light] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 22:26:26 -0000 Hello Ladislav, exactly; those extension functions that you describe would make a huge difference. deref() seems of particular relevance as well. =20 Regards --- Alex -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Wednesday, June 13, 2012 11:37 PM To: Alexander Clemm (alex) Cc: netmod@ietf.org Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying aconsensus on the way forwardwithNetconf-Light] On Jun 14, 2012, at 3:37 AM, Alexander Clemm (alex) wrote: > Hi, >=20 > here is one example: >=20 > The definition of identity allows to specify a base identity, allowing > to build an "identity hierarchy". However, if I subsequently want to > specify a condition or a constraint that pertains to all identities that > were derived from the same base identity, I need to enumerate every > single one of the identities. This makes the definition of the > condition/constraint unnecessarily complex. Even worse, every time I > introduce a new identity that is derived from the same base identity, I > need to update the conditions/constraints which may have been defined in > an entirely different place. This basically also defeats the purpose of > using identities, instead of enums, to allow for extending a set of > enumerated values without having to revise the original definition. Yes, one of the proposed XPath extension functions is derived-from(). The others are: - deref() (for dereferencing instance identifiers), - is-bit-set(), - if-feature() - if-module() - if-capability() > =20 >=20 > For example, think of the following identity hierarchy: > flow > +-- audioflow > +-- pandora > +-- rhapsody > +-- spotify > +-- ... >=20 > If I have a constraint that pertains to audioflows, I need to enumerate > a long list of subidentities instead of the single base identity, and > need to update that constraint whenever a new identity that identifies a > new audioflow is introduced. =20 >=20 > (Maybe this part of the thread actually belongs on the netmod mailer, > not netconf) Right, so I am moving it to the netmod list. Lada > --- Alex >=20 >=20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 > Sent: Wednesday, June 13, 2012 2:13 AM > To: Alexander Clemm (alex); Carl Moberg > Cc: Netconf > Subject: RE: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying > aconsensus on the way forwardwithNetconf-Light] >=20 > "Alexander Clemm (alex)" writes: >=20 >> Just my 2 cents, one aspect that seems a bit clumsy in YANG concerns > the >> specification of conditions and constraints. While it is certainly >> possible to argue that it does the job, it is fairly hard to use. If > it >=20 > Could you be more specific? What is exactly hard? Is it that, for > example, one needs to carefully count the number of double dots in order > to get to a remote node? Or missing semantics? >=20 >> is hard to use, things might be left up to implementations while they >> really should be captured in the spec. It might be worthwhile to >> consider possible alternatives to the current scheme, such as being > able >> to refer to a more "procedural" way to refer to constraints, rather > than >> the declarative way it is now. >=20 > We have been discussing the addition of several new XPath functions, but > mainly for supporting special YANG data types, so nothing really > procedural. Can you give some examples? >=20 > Thanks, Lada >=20 >> --- Alex >>=20 >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On >> Behalf Of Carl Moberg >> Sent: Tuesday, June 12, 2012 6:52 AM >> To: Ladislav Lhotka >> Cc: Netconf >> Subject: Re: [Netconf] WG Consensus call: Netconf 2.0? [was: Trying >> aconsensus on the way forwardwithNetconf-Light] >>=20 >>=20 >> On Jun 12, 2012, at 11:58 AM, Ladislav Lhotka wrote: >>=20 >>> Carl Moberg writes: >>>> For the record; I don't actually see any strong suggestions that >> there are any features that are "too heavy-weight, clumsy or broken" > in >> NETCONF or YANG. At least I have never heard that type of feedback > from >> the implementations that we've been working with. Sure, there are > issues >> and challenges with implementing server-side NETCONF (and YANG) >> particularly around retrofitting it on top of existing software >> infrastructure, but I have no experience that there are show stopping >> aspects to it that must be fixed. >>>=20 >>> OK, let me mention one thing: the design of is wrong. A >> standard approach would be to have one expression for locating the > node >> to be updated and another one for specifying the changes. This is how > it >> is done e.g. in XQuery Update or in databases. attempts > to >> do both steps in one shot which doesn't really work all that great. >> While this may not be a showstopper, it certainly causes problems - > cf. >> the parallel discussion in the NETMOD list regarding keys for route >> lists. With a separate locator expression, the NETCONF client wouldn't >> have to care about list keys all that much and just use any > appropriate >> attributes for selecting a list entry. >>=20 >>=20 >>=20 >> I agree that it's not perfect. It's about as good/bad as some other >> protocols (e.g. SNMP). But the point that I come back to is that it's >> certainly good enough (even with that imperfection and others) that it >> has the potential to radically improve the way we do configuration >> management in networks. Making it a moving target instead of widely >> applying what we have would be a case of over optimization IMHO. >>=20 >> Now, this looks like one dead horse :-) >>=20 >> -- >> Carl Moberg, Tail-f Systems >> mailto:calle@tail-f.com >> twitter: @cmoberg >> http://www.tail-f.com/ >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Fri Jun 15 12:08:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EDF21F854F for ; Fri, 15 Jun 2012 12:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6AgWH4--IS6 for ; Fri, 15 Jun 2012 12:08:18 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 01D5021F8541 for ; Fri, 15 Jun 2012 12:08:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q5FJ8GwM031813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Jun 2012 21:08:16 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q5FJ87hu006761; Fri, 15 Jun 2012 21:08:13 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Jun 2012 21:08:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jun 2012 21:08:08 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403E95E21@DEMUEXC006.nsn-intra.net> In-Reply-To: <7E1CAB62-9E7F-48BC-907F-DB6E0A787008@nic.cz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] Fwd: New Version Notification fordraft-lhotka-yang-json-01.txt Thread-Index: Ac1DDCtOxBGcWBcFRZ6ioIBbhTvrQAIHW2qQ References: <20120605110606.19150.76771.idtracker@ietfa.amsl.com> <7E1CAB62-9E7F-48BC-907F-DB6E0A787008@nic.cz> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Ladislav Lhotka" , X-OriginalArrivalTime: 15 Jun 2012 19:08:09.0359 (UTC) FILETIME=[33CFF9F0:01CD4B2A] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2088 X-purgate-ID: 151667::1339787296-00003CDD-D465456A/0-0/0-0 Cc: ext Andy Bierman Subject: Re: [netmod] Fwd: New Version Notification fordraft-lhotka-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 19:08:19 -0000 Hi Lada, this is a very valuable draft to enable JSON fans to use YANG.=20 If not done already I would suggest to forward the draft announcement to APP-Discuss and Core maillists. Do you have an experimental implementation already? Martin, Andy: How about pyang or yuma integration? Cheers,=20 Mehmet=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of ext > Ladislav Lhotka > Sent: Tuesday, June 05, 2012 1:12 PM > To: netmod@ietf.org > Subject: [netmod] Fwd: New Version Notification fordraft-lhotka-yang-json-01.txt >=20 > Hi, >=20 > this is a new revision of the JSON mapping draft. The main change is a more liberal > approach to namespaces - an explicit namespace identifier must be used in JSON only > where the local name is ambiguous, which should hopefully be almost nowhere. >=20 > Comments are welcome. >=20 > Lada >=20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Subject: New Version Notification for draft-lhotka-yang-json-01.txt > > Date: June 5, 2012 1:06:06 PM GMT+02:00 > > To: lhotka@nic.cz > > > > A new version of I-D, draft-lhotka-yang-json-01.txt has been successfully submitted > by Ladislav Lhotka and posted to the IETF repository. > > > > Filename: draft-lhotka-yang-json > > Revision: 01 > > Title: Modeling JSON Text with YANG > > Creation date: 2012-06-05 > > WG ID: Individual Submission > > Number of pages: 12 > > > > Abstract: > > This document defines rules for mapping data models expressed in YANG > > to configuration and operational state data encoded as JSON text. It > > does so by specifying a procedure for translating the subset of YANG- > > compatible XML documents to JSON text, and vice versa. > > > > > > > > > > The IETF Secretariat >=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 From lhotka@nic.cz Fri Jun 15 13:53:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0877A11E80D0 for ; Fri, 15 Jun 2012 13:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCTt-l4uA+aM for ; Fri, 15 Jun 2012 13:53:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6047011E8088 for ; Fri, 15 Jun 2012 13:53:24 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 96D4C13FB25; Fri, 15 Jun 2012 22:53:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1339793603; bh=vxvtEfzy+StKD7SbgPIYBpygc54ycyYhwBpSGjTnGM0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XkTbW7x2p8MnVVxCJjkNFX2LPzkYNqJg3KQ+ed6KXDh1R81w2/5UTFrOLIgGIXoCt MQ7UkUObqZHX5pcvjnZzAq0D8UzRwWu5p2wZltDG5pZM2/xGnFzqG16kQbZl+neBzv IGk3aLSrEdVdvD1dEFE6ubK1V+pd4mKFj4iSMVXQ= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6403E95E21@DEMUEXC006.nsn-intra.net> Date: Fri, 15 Jun 2012 22:53:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120605110606.19150.76771.idtracker@ietfa.amsl.com> <7E1CAB62-9E7F-48BC-907F-DB6E0A787008@nic.cz> <80A0822C5E9A4440A5117C2F4CD36A6403E95E21@DEMUEXC006.nsn-intra.net> To: "Ersue, Mehmet (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: ext Andy Bierman , netmod@ietf.org Subject: Re: [netmod] New Version Notification fordraft-lhotka-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 20:53:27 -0000 Hi Mehmet, On Jun 15, 2012, at 9:08 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi Lada, >=20 > this is a very valuable draft to enable JSON fans to use YANG.=20 > If not done already I would suggest to forward the draft announcement = to > APP-Discuss and Core mail lists. I sent an announcement of -00 revision to app-discuss but didn't get any = reaction. >=20 > Do you have an experimental implementation already? Not yet, but I plan to write at least the JSON->XML part. >=20 > Martin, Andy: How about pyang or yuma integration? Andy mentioned he'd been using it already. Lada >=20 > Cheers,=20 > Mehmet=20 >=20 >=20 >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf Of ext >> Ladislav Lhotka >> Sent: Tuesday, June 05, 2012 1:12 PM >> To: netmod@ietf.org >> Subject: [netmod] Fwd: New Version Notification > fordraft-lhotka-yang-json-01.txt >>=20 >> Hi, >>=20 >> this is a new revision of the JSON mapping draft. The main change is = a > more liberal >> approach to namespaces - an explicit namespace identifier must be = used > in JSON only >> where the local name is ambiguous, which should hopefully be almost > nowhere. >>=20 >> Comments are welcome. >>=20 >> Lada >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-lhotka-yang-json-01.txt >>> Date: June 5, 2012 1:06:06 PM GMT+02:00 >>> To: lhotka@nic.cz >>>=20 >>> A new version of I-D, draft-lhotka-yang-json-01.txt has been > successfully submitted >> by Ladislav Lhotka and posted to the IETF repository. >>>=20 >>> Filename: draft-lhotka-yang-json >>> Revision: 01 >>> Title: Modeling JSON Text with YANG >>> Creation date: 2012-06-05 >>> WG ID: Individual Submission >>> Number of pages: 12 >>>=20 >>> Abstract: >>> This document defines rules for mapping data models expressed in > YANG >>> to configuration and operational state data encoded as JSON text. > It >>> does so by specifying a procedure for translating the subset of > YANG- >>> compatible XML documents to JSON text, and vice versa. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=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 andy@yumaworks.com Fri Jun 15 14:21:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A39311E80D0 for ; Fri, 15 Jun 2012 14:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b14jO5g+5mib for ; Fri, 15 Jun 2012 14:21:06 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2E6011E8088 for ; Fri, 15 Jun 2012 14:21:05 -0700 (PDT) Received: by lagv3 with SMTP id v3so2484186lag.31 for ; Fri, 15 Jun 2012 14:21:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=KPSY/tF/rV7LGscJaEAve6oi+t1yrKCHh9v3+r0DAJo=; b=liyrp56B4F97/yBAIXny61OughZLHbglkk9aUyBBTZfMG6nMEYJENm8pg/yJdiwbnJ 01vcZOB9luV3RdQZhgHcRKAaTxiE+kSugkvri/+dQ/aWp+3r9GmbVriRFQrMuQ+G2BcJ 3++L/0nRKOPo3tJZqfwQ8aNlsSddHqolg2qQv4ljEsgbdYgK5ApFDedgIh/+cid5+tOq glFvDCxBz6wWaLhkDrmw0Gb19E9EKr8g+cFeli1LJ0jEl3TgUBhfGzJe8rAaLrnCNMpF p0J2uNDa0VUvo0rNkpVPdPXQNQvyMKjQnqq5XF75L+DRmc+2gd6Vb/NYElEjLPvrx4AU NE9w== MIME-Version: 1.0 Received: by 10.152.104.44 with SMTP id gb12mr6819690lab.29.1339795264683; Fri, 15 Jun 2012 14:21:04 -0700 (PDT) Received: by 10.114.22.169 with HTTP; Fri, 15 Jun 2012 14:21:04 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <20120605110606.19150.76771.idtracker@ietfa.amsl.com> <7E1CAB62-9E7F-48BC-907F-DB6E0A787008@nic.cz> <80A0822C5E9A4440A5117C2F4CD36A6403E95E21@DEMUEXC006.nsn-intra.net> Date: Fri, 15 Jun 2012 14:21:04 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=f46d04088ef5d2c06b04c2896460 X-Gm-Message-State: ALoCoQmu2b7U0iM7fmpk9aRu6gpmcT/+P0LRgi0YSfKBDQtktVrY2EUlKPSD/pLEZqyaKZ+AcqnD Cc: ext Andy Bierman , netmod@ietf.org Subject: Re: [netmod] New Version Notification fordraft-lhotka-yang-json-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 21:21:07 -0000 --f46d04088ef5d2c06b04c2896460 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 15, 2012 at 1:53 PM, Ladislav Lhotka wrote: > Hi Mehmet, > > On Jun 15, 2012, at 9:08 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > Hi Lada, > > > > this is a very valuable draft to enable JSON fans to use YANG. > > If not done already I would suggest to forward the draft announcement to > > APP-Discuss and Core mail lists. > > I sent an announcement of -00 revision to app-discuss but didn't get any > reaction. > > > > > Do you have an experimental implementation already? > > Not yet, but I plan to write at least the JSON->XML part. > > > > > Martin, Andy: How about pyang or yuma integration? > > Andy mentioned he'd been using it already. > > I said I plan to use it, but it may be awhile before I have time to work on it. It is planned for a commercial version of yuma, not the open-source version. > Lada > > > > > Cheers, > > Mehmet > > > > > Andy > >> -----Original Message----- > >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > > Behalf Of ext > >> Ladislav Lhotka > >> Sent: Tuesday, June 05, 2012 1:12 PM > >> To: netmod@ietf.org > >> Subject: [netmod] Fwd: New Version Notification > > fordraft-lhotka-yang-json-01.txt > >> > >> Hi, > >> > >> this is a new revision of the JSON mapping draft. The main change is a > > more liberal > >> approach to namespaces - an explicit namespace identifier must be used > > in JSON only > >> where the local name is ambiguous, which should hopefully be almost > > nowhere. > >> > >> Comments are welcome. > >> > >> Lada > >> > >> Begin forwarded message: > >> > >>> From: internet-drafts@ietf.org > >>> Subject: New Version Notification for draft-lhotka-yang-json-01.txt > >>> Date: June 5, 2012 1:06:06 PM GMT+02:00 > >>> To: lhotka@nic.cz > >>> > >>> A new version of I-D, draft-lhotka-yang-json-01.txt has been > > successfully submitted > >> by Ladislav Lhotka and posted to the IETF repository. > >>> > >>> Filename: draft-lhotka-yang-json > >>> Revision: 01 > >>> Title: Modeling JSON Text with YANG > >>> Creation date: 2012-06-05 > >>> WG ID: Individual Submission > >>> Number of pages: 12 > >>> > >>> Abstract: > >>> This document defines rules for mapping data models expressed in > > YANG > >>> to configuration and operational state data encoded as JSON text. > > It > >>> does so by specifying a procedure for translating the subset of > > YANG- > >>> compatible XML documents to JSON text, and vice versa. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --f46d04088ef5d2c06b04c2896460 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 15, 2012 at 1:53 PM, Ladislav Lh= otka <lhotka@nic.cz> wrote:
Hi Mehmet,

On Jun 15, 2012, at 9:08 PM, Ersue, Mehmet (NSN - DE/Munich) wrote:

> Hi Lada,
>
> this is a very valuable draft to enable JSON fans to use YANG.
> If not done already I would suggest to forward the draft announcement = to
> APP-Discuss and Core mail lists.

I sent an announcement of -00 revision to app-discuss but didn't get an= y reaction.

>
> Do you have an experimental implementation already?

Not yet, but I plan to write at least the JSON->XML part.

>
> Martin, Andy: How about pyang or yuma integration?

Andy mentioned he'd been using it already.


I said I plan to use it, but it may be= awhile before I have time to work on it.
It is planned for a com= mercial version of yuma, not the open-source version.

=A0
Lada

>
> Cheers,
> Mehmet
>
>


Andy

=
=A0
>> -----Original Message-----
>> From: netmod-bounces@ie= tf.org [mailto:netmod-bounce= s@ietf.org] On
> Behalf Of ext
>> Ladislav Lhotka
>> Sent: Tuesday, June 05, 2012 1:12 PM
>> To: netmod@ietf.org
>> Subject: [netmod] Fwd: New Version Notification
> fordraft-lhotka-yang-json-01.txt
>>
>> Hi,
>>
>> this is a new revision of the JSON mapping draft. The main change = is a
> more liberal
>> approach to namespaces - an explicit namespace identifier must be = used
> in JSON only
>> where the local name is ambiguous, which should hopefully be almos= t
> nowhere.
>>
>> Comments are welcome.
>>
>> Lada
>>
>> Begin forwarded message:
>>
>>> From: internet-dra= fts@ietf.org
>>> Subject: New Version Notification for draft-lhotka-yang-json-0= 1.txt
>>> Date: June 5, 2012 1:06:06 PM GMT+02:00
>>> To: lhotka@nic.cz
>>>
>>> A new version of I-D, draft-lhotka-yang-json-01.txt has been > successfully submitted
>> by Ladislav Lhotka and posted to the IETF repository.
>>>
>>> Filename: =A0 =A0draft-lhotka-yang-json
>>> Revision: =A0 =A001
>>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 Modeling JSON Text with YAN= G
>>> Creation date: =A0 =A0 =A0 2012-06-05
>>> WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
>>> Number of pages: 12
>>>
>>> Abstract:
>>> =A0This document defines rules for mapping data models express= ed in
> YANG
>>> =A0to configuration and operational state data encoded as JSON= text.
> It
>>> =A0does so by specifying a procedure for translating the subse= t of
> YANG-
>>> =A0compatible XML documents to JSON text, and vice versa.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

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





--f46d04088ef5d2c06b04c2896460-- From Jonathan.Hansford@generaldynamics.uk.com Wed Jun 20 01:29:51 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F04421F872A; Wed, 20 Jun 2012 01:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.418 X-Spam-Level: X-Spam-Status: No, score=-4.418 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yclVv-6hvZr; Wed, 20 Jun 2012 01:29:51 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 66BDB21F871E; Wed, 20 Jun 2012 01:29:49 -0700 (PDT) Received: from [85.158.136.3:60688] by server-8.bemta-5.messagelabs.com id CB/11-10278-CF981EF4; Wed, 20 Jun 2012 08:29:48 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-12.tower-123.messagelabs.com!1340180988!27338413!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23901 invoked from network); 20 Jun 2012 08:29:48 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-12.tower-123.messagelabs.com with SMTP; 20 Jun 2012 08:29:48 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 20 Jun 2012 09:29:43 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.137]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jun 2012 09:29:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4EBE.D5BF20F0" Date: Wed, 20 Jun 2012 09:29:46 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Possibility of a NETCONF and YANG Primer Thread-Index: Ac1Ovtmk4Ot3qYOeQPGWncLDGfEcgA== From: To: , X-OriginalArrivalTime: 20 Jun 2012 08:29:43.0670 (UTC) FILETIME=[D7E87160:01CD4EBE] Subject: [netmod] Possibility of a NETCONF and YANG Primer X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:29:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD4EBE.D5BF20F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 Hi, =20 Were I to undertake writing a NETCONF and YANG primer, could someone point me at any documents or particular email threads that would help me gain an understanding of the discussions, guidelines, etc. that helped shape them? For example, would I be right in assuming that RFC3444, RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? =20 Thanks, =20 Jonathan This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 ------_=_NextPart_001_01CD4EBE.D5BF20F0 Content-Type: text/HTML; charset="us-ascii" Content-Transfer-Encoding: 7bit X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1

Hi,

 

Were I to undertake writing a NETCONF and YANG primer, could someone point me at any documents or particular email threads that would help me gain an understanding of the discussions, guidelines, etc. that helped shape them? For example, would I be right in assuming that RFC3444, RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact?

 

Thanks,

 

Jonathan

This email and any files attached are intended for the addressee and may contain information of a confidential nature. If you are not the intended recipient, be aware that this email was sent to you in error and you should not disclose, distribute, print, copy or make other use of this email or its attachments. Such actions, in fact, may be unlawful. In compliance with the various Regulations and Acts, General Dynamics United Kingdom Limited reserves the right to monitor (and examine for viruses) all emails and email attachments, both inbound and outbound. Email communications and their attachments may not be secure or error- or virus-free and the company does not accept liability or responsibility for such matters or the consequences thereof. General Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and Wales No: 1911653.

------_=_NextPart_001_01CD4EBE.D5BF20F0-- From j.schoenwaelder@jacobs-university.de Wed Jun 20 01:43:14 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D7421F8609; Wed, 20 Jun 2012 01:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aajn8kbRNrfV; Wed, 20 Jun 2012 01:43:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 12F3B21F870B; Wed, 20 Jun 2012 01:43:11 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11E9320BEB; Wed, 20 Jun 2012 10:43:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id l4btFIh73SWy; Wed, 20 Jun 2012 10:43:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33F6F207E0; Wed, 20 Jun 2012 10:43:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8E516201B140; Wed, 20 Jun 2012 10:43:08 +0200 (CEST) Date: Wed, 20 Jun 2012 10:43:08 +0200 From: Juergen Schoenwaelder To: Jonathan.Hansford@generaldynamics.uk.com Message-ID: <20120620084308.GA77034@elstar.local> Mail-Followup-To: Jonathan.Hansford@generaldynamics.uk.com, netconf@ietf.org, netmod@ietf.org References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Possibility of a NETCONF and YANG Primer X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:43:15 -0000 On Wed, Jun 20, 2012 at 09:29:46AM +0100, Jonathan.Hansford@generaldynamics.uk.com wrote: > Hi, > > Were I to undertake writing a NETCONF and YANG primer, could someone > point me at any documents or particular email threads that would help me > gain an understanding of the discussions, guidelines, etc. that helped > shape them? For example, would I be right in assuming that RFC3444, > RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? > RFC3535 has been important in getting the IETF to start work on a new network configuration protocol. It also delievered some requirements but other than that it did not really influence much of the design. Some of us wrote an IEEE Communications Magazine paper providing a concise summary of what NETCONF / YANG is. Perhaps this is useful. http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=5560601&contentType=Journals+%26+Magazines&sortType%3Dasc_p_Sequence%26filter%3DAND%28p_IS_Number%3A5560574%29%26rowsPerPage%3D50 And then there is of course also RFC 6244 which has some motivation and introductory material. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Wed Jun 20 01:55:22 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413FB21F8731; Wed, 20 Jun 2012 01:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd+qJgAHBnNs; Wed, 20 Jun 2012 01:55:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id CCDB921F8707; Wed, 20 Jun 2012 01:55:17 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q5K8tCY1031157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jun 2012 10:55:12 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q5K8t64o029466; Wed, 20 Jun 2012 10:55:12 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jun 2012 10:55:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jun 2012 10:55:05 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6403EE4F64@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120620084308.GA77034@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Possibility of a NETCONF and YANG Primer Thread-Index: Ac1OwL/hr5bhecBgS+eW554dfGEKkgAAXjEA References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> <20120620084308.GA77034@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 20 Jun 2012 08:55:06.0746 (UTC) FILETIME=[63BB65A0:01CD4EC2] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2058 X-purgate-ID: 151667::1340182515-0000425E-869BFCA8/0-0/0-0 Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Possibility of a NETCONF and YANG Primer X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 08:55:22 -0000 Please check also http://tools.ietf.org/html/rfc6087=20 "Guidelines for Authors and Reviewers of YANG Data Model Documents".=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Juergen Schoenwaelder > Sent: Wednesday, June 20, 2012 10:43 AM > To: Jonathan.Hansford@generaldynamics.uk.com > Cc: netconf@ietf.org; netmod@ietf.org > Subject: Re: [Netconf] Possibility of a NETCONF and YANG Primer >=20 > On Wed, Jun 20, 2012 at 09:29:46AM +0100, > Jonathan.Hansford@generaldynamics.uk.com wrote: > > Hi, > > > > Were I to undertake writing a NETCONF and YANG primer, could someone > > point me at any documents or particular email threads that would help me > > gain an understanding of the discussions, guidelines, etc. that helped > > shape them? For example, would I be right in assuming that RFC3444, > > RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? > > >=20 > RFC3535 has been important in getting the IETF to start work on a new > network configuration protocol. It also delievered some requirements > but other than that it did not really influence much of the design. >=20 > Some of us wrote an IEEE Communications Magazine paper providing a > concise summary of what NETCONF / YANG is. Perhaps this is useful. >=20 > http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=3D&arnumber=3D556060= 1&c ontentType=3D > Journals+%26+Magazines&sortType%3Dasc_p_Sequence%26filter%3DAND%28p_IS_N > umber%3A5560574%29%26rowsPerPage%3D50 >=20 > And then there is of course also RFC 6244 which has some motivation > and introductory material. >=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 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Wed Jun 20 02:08:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2048D21F86FD; Wed, 20 Jun 2012 02:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2PxLwB4F24r; Wed, 20 Jun 2012 02:08:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2B221F86FA; Wed, 20 Jun 2012 02:08:30 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 223AD13FD87; Wed, 20 Jun 2012 11:08:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340183307; bh=MmtXVP+GZ1W+blelw/FC3ejkvrUYvzwUo7Si6c6KlhU=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lgkL4EWQPSV4V1nbsYgReQYf1u7R7HUVjIyUfSeEbaPOm+kklOhcbCNzggEl6k+1Y copciqVqQ8kaZTK8sYaS2KF2IkgbYvu3YdnZwv8yu+NhzzkEt+Q01Q6TFWQ9lxjzBq DQtw5SYNZKfc/5qLTDTGm6oSun2J0akIG7Dq65LY= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> Date: Wed, 20 Jun 2012 11:08:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <27FAA8EC-1DFC-47F4-9B25-A48BF5543C79@nic.cz> References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> To: X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] Possibility of a NETCONF and YANG Primer X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 09:08:31 -0000 On Jun 20, 2012, at 10:29 AM, = wrote: > Hi, > =20 > Were I to undertake writing a NETCONF and YANG primer, could someone = point me at any documents or particular email threads that would help me = gain an understanding of the discussions, guidelines, etc. that helped = shape them? For example, would I be right in assuming that RFC3444, = RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? Regarding YANG and DSDL mapping, some tutorials are available at = yang-central.org. Lada > =20 > Thanks, > =20 > Jonathan >=20 > This email and any files attached are intended for the addressee and = may contain information of a confidential nature. If you are not the = intended recipient, be aware that this email was sent to you in error = and you should not disclose, distribute, print, copy or make other use = of this email or its attachments. Such actions, in fact, may be = unlawful. In compliance with the various Regulations and Acts, General = Dynamics United Kingdom Limited reserves the right to monitor (and = examine for viruses) all emails and email attachments, both inbound and = outbound. Email communications and their attachments may not be secure = or error- or virus-free and the company does not accept liability or = responsibility for such matters or the consequences thereof. General = Dynamics United Kingdom Limited, Registered Office: 21 Holborn Viaduct, = London EC1A 2DY. Registered in England and Wales No: 1911653. >=20 > _______________________________________________ > 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 Wed Jun 20 05:39:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047C421F870B; Wed, 20 Jun 2012 05:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGbGYdmnHl9L; Wed, 20 Jun 2012 05:39:57 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4516421F86DC; Wed, 20 Jun 2012 05:39:56 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F236B1200CF2; Wed, 20 Jun 2012 14:39:54 +0200 (CEST) Date: Wed, 20 Jun 2012 14:39:54 +0200 (CEST) Message-Id: <20120620.143954.975189795650856992.mbj@tail-f.com> To: Jonathan.Hansford@generaldynamics.uk.com From: Martin Bjorklund In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] Possibility of a NETCONF and YANG Primer X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 12:39:58 -0000 wrote: > Hi, > > > > Were I to undertake writing a NETCONF and YANG primer, could someone > point me at any documents or particular email threads that would help me > gain an understanding of the discussions, guidelines, etc. that helped > shape them? For example, would I be right in assuming that RFC3444, > RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? For YANG, there are some notes available at http://www.yang-central.org/twiki/bin/view/Main/YangDocuments, for example http://www.yang-central.org/twiki/bin/view/Main/WhyYang. I should also say that I think this is a great idea! I very much encourage you to write this document. If you start writing something, I am pretty sure others (myself included) can help with information, or even text for certain sections. /martin From randy_presuhn@mindspring.com Wed Jun 20 10:04:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8316021F8763; Wed, 20 Jun 2012 10:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.392 X-Spam-Level: X-Spam-Status: No, score=-101.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdgHoMC2aMVb; Wed, 20 Jun 2012 10:04:47 -0700 (PDT) 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 9FD8321F8700; Wed, 20 Jun 2012 10:04:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hiFS1HNX5ek0BzyVSGm30rYvkSrEEamE5LFZoWd77LZOcFOuVILf0/T3+W16SMtw; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.50.205] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ShOKk-0008RI-Dz; Wed, 20 Jun 2012 13:04:46 -0400 Message-ID: <002601cd4f07$4f8209a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> <27FAA8EC-1DFC-47F4-9B25-A48BF5543C79@nic.cz> Date: Wed, 20 Jun 2012 10:08:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1bbd31b5f81886e3d25738e16f00db322350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.50.205 Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Possibility of a NETCONF and YANG Primer X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 17:04:48 -0000 Hi - Jonathan.Hansford@generaldynamics.uk.com wrote: > Were I to undertake writing a NETCONF and YANG primer, > could someone point me at any documents or particular email > threads that would help me gain an understanding of the discussions, > guidelines, etc. that helped shape them? ... You might also find some background material in https://datatracker.ietf.org/doc/draft-presuhn-rcdml/ Like RFC3535, though it delivered some requirements, its actual influence on the design is another question. Randy From ietfc@btconnect.com Wed Jun 20 11:18:49 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88E121F877E; Wed, 20 Jun 2012 11:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.839 X-Spam-Level: X-Spam-Status: No, score=-4.839 tagged_above=-999 required=5 tests=[AWL=1.760, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUOsaycq789q; Wed, 20 Jun 2012 11:18:49 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4707D21F877C; Wed, 20 Jun 2012 11:18:49 -0700 (PDT) Received: from mail165-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Jun 2012 18:17:24 +0000 Received: from mail165-tx2 (localhost [127.0.0.1]) by mail165-tx2-R.bigfish.com (Postfix) with ESMTP id ECEE11E0290; Wed, 20 Jun 2012 18:17:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I542M4015Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail165-tx2 (localhost.localdomain [127.0.0.1]) by mail165-tx2 (MessageSwitch) id 1340216243327275_32019; Wed, 20 Jun 2012 18:17:23 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.247]) by mail165-tx2.bigfish.com (Postfix) with ESMTP id 4D27F4A0068; Wed, 20 Jun 2012 18:17:23 +0000 (UTC) Received: from DB3PRD0702HT003.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Jun 2012 18:17:21 +0000 Received: from BY2PRD0410HT004.namprd04.prod.outlook.com (157.56.236.85) by pod51017.outlook.com (10.3.4.151) with Microsoft SMTP Server (TLS) id 14.15.86.1; Wed, 20 Jun 2012 18:18:32 +0000 Message-ID: <017401cd4f10$a0873920$4001a8c0@gateway.2wire.net> From: t.petch To: , , References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> Date: Wed, 20 Jun 2012 19:15:00 +0100 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.236.85] X-OriginatorOrg: btconnect.com Subject: Re: [netmod] [Netconf] Possibility of a NETCONF and YANG Primer X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 18:18:50 -0000 ----- Original Message ----- From: To: ; Sent: Wednesday, June 20, 2012 9:29 AM Were I to undertake writing a NETCONF and YANG primer, could someone point me at any documents or particular email threads that would help me gain an understanding of the discussions, guidelines, etc. that helped shape them? For example, would I be right in assuming that RFC3444, RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? I was assuming it would be an RFC, Informational. There are precedents for other protocols, although not too many. I too would be happy to review and comment. Tom Petch PS I wish you could eliminate the trailer that says your e-mails may be confidential, although I realise corporate culture makes that very difficult. Which is perhaps why there are a number of gmail addresses on IETF lists. Thanks, Jonathan From mbj@tail-f.com Wed Jun 20 13:10:39 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE0F11E8083; Wed, 20 Jun 2012 13:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft5olFGTQwJQ; Wed, 20 Jun 2012 13:10:35 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id AC47411E8087; Wed, 20 Jun 2012 13:10:35 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 9BD001200D85; Wed, 20 Jun 2012 22:10:33 +0200 (CEST) Date: Wed, 20 Jun 2012 22:10:33 +0200 (CEST) Message-Id: <20120620.221033.441138909.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <017401cd4f10$a0873920$4001a8c0@gateway.2wire.net> References: <83C941F7F59F3F42AC017AD1E650546206CDD464@GDUKADH850.uk1.r-org.net> <017401cd4f10$a0873920$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Jonathan.Hansford@generaldynamics.uk.com, netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Possibility of a NETCONF and YANG Primer X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 20:10:40 -0000 t.petch wrote: > ----- Original Message ----- > From: > To: ; > Sent: Wednesday, June 20, 2012 9:29 AM > > Were I to undertake writing a NETCONF and YANG primer, could someone > point me at any documents or particular email threads that would help me > gain an understanding of the discussions, guidelines, etc. that helped > shape them? For example, would I be right in assuming that RFC3444, > RFC3535 and possibly draft-schoenw-sming-lessons-01 had an impact? > > > I was assuming it would be an RFC, Informational. There are precedents > for other protocols, although not too many. I think a web site might be better. It can be perceived as "lighter" and easier to read, and you are not limited to 72 ascii chars per line :) It is easier to make pretty pictures etc. I think both pyang and yangdump has options to generate pretty html versions of YANG modules. /martin From jeffrey.K.lange@ge.com Fri Jun 22 05:53:37 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0A921F8496 for ; Fri, 22 Jun 2012 05:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4lLrWv9QudA for ; Fri, 22 Jun 2012 05:53:35 -0700 (PDT) Received: from exprod5og109.obsmtp.com (exprod5og109.obsmtp.com [64.18.0.188]) by ietfa.amsl.com (Postfix) with ESMTP id 65E0721F8470 for ; Fri, 22 Jun 2012 05:53:34 -0700 (PDT) Received: from cinmlip11.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob109.postini.com ([64.18.4.12]) with SMTP ID DSNKT+RqzQtuAjj1qTxQKcdmizH5N3L3UQu8@postini.com; Fri, 22 Jun 2012 05:53:35 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by cinmlip11.e2k.ad.ge.com with ESMTP; 22 Jun 2012 08:53:32 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jun 2012 08:53:31 -0400 Received: from CINMBCNA03.e2k.ad.ge.com (3.159.212.57) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 22 Jun 2012 08:53:31 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA03.e2k.ad.ge.com ([169.254.3.14]) with mapi id 14.02.0283.003; Fri, 22 Jun 2012 08:53:31 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: ietf-system: timezone-utc-offset Thread-Index: Ac1QdKsNKID7x3/NQD+98jr20yH9FQ== Date: Fri, 22 Jun 2012 12:53:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA63BBCINMBCNA02e2kad_" MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jun 2012 12:53:31.0725 (UTC) FILETIME=[06FD77D0:01CD5076] Subject: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 12:53:37 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA63BBCINMBCNA02e2kad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Currently timezone-location and timezone-name are defined in the YANG modle= with "if-feature", but timezone-utc-offset is not. I think that this shou= ld also be gated on an if-feature. If I plan on having timezone support in= my product, I want to ensure that daylight savings time is properly reflec= ted. To do this I'd use the zoneinfo database or the like. If I also need= ed to support the manual setting of time offsets, I'd need to put custom co= de everywhere in the system where a time is calculated rather than just rel= ying on the standard system APIs to give me the current and correct time. Without having this as a feature you are implying that I MUST support this = additional functionality if I want to use the ietf-system model. Perhaps a config false leaf that returns the current UTC offset would be us= eful too. That way if you set the timezone via a name, you can also check = to ensure that it is really the UTC offset you are expecting. Thanks, Jeff Lange Lead Software Engineer GE Energy Services Digital Energy T +1 585 242 8375 F +1 585 241 5590 Jeffrey.K.Lange@ge.com www.GEDigitalEnergy.com 175 Science Parkway Rochester, NY 14620 United States GE imagination at work --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA63BBCINMBCNA02e2kad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Currently timezone-location and timezone-name are de= fined in the YANG modle with “if-feature”, but timezone-utc-off= set is not.  I think that this should also be gated on an if-feature.&= nbsp; If I plan on having timezone support in my product, I want to ensure that daylight savings time is properly reflected.  T= o do this I’d use the zoneinfo database or the like.  If I also = needed to support the manual setting of time offsets, I’d need to put= custom code everywhere in the system where a time is calculated rather than just relying on the standard system APIs to give me= the current and correct time.

 

Without having this as a feature you are implying th= at I MUST support this additional functionality if I want to use the ietf-s= ystem model.

 

Perhaps a config false leaf that returns the current= UTC offset would be useful too.  That way if you set the timezone via= a name, you can also check to ensure that it is really the UTC offset you = are expecting.

 

Thanks,

 

Jeff Lange
Lead Software Engineer
GE Energy Services
Digital Energy

T +1 585 242 8375
F +1 585 241 5590
Jeffrey.K.Lange@ge.com
www.GEDigitalEnergy.com

175 Science Parkway
Rochester, NY 14620 United States

GE imagination at work

 

--_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA63BBCINMBCNA02e2kad_-- From andy@yumaworks.com Fri Jun 22 07:48:19 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C95521F8620 for ; Fri, 22 Jun 2012 07:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.87 X-Spam-Level: X-Spam-Status: No, score=-2.87 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SODjVrplg9O2 for ; Fri, 22 Jun 2012 07:48:18 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D336521F8611 for ; Fri, 22 Jun 2012 07:48:17 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4030738lbb.31 for ; Fri, 22 Jun 2012 07:48:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=cOUS/hN6KH3sr7d3ZtZEFaAHBe8pQZ4gUTNC9wjKghM=; b=Z17RlNsOCAb2vg+mg1dYY4GvXklD/JBk4KT/gE4q6nrifo1aIhbPvPLIDYOiEXHahP D5Kuq2Gwkd27lGFB1X7usbKiJ51ho0GepGo2/AA9zMRWAaaZCJevI7u1rugHu5XR9sR2 wQWHU0dSWp/hA5muPqyhO67rugm66WsDPWyuvaP6VD7pHB0rjwuY+RlDuDJ7qzLrRrAH Y71p4JuCIVFWdnzB4N/jG9BARG39CiokQcSfpNuBUWxwpJNhnL3xsBwt/yjmfaVg/WKR bjSOu48YJjVGIXTsN+jrtNgeX0L6fOue5LzpYvTUpOXrX6zwoc9+wC+4p70JoEIDOCfB 8alw== MIME-Version: 1.0 Received: by 10.112.32.35 with SMTP id f3mr1620568lbi.47.1340376496349; Fri, 22 Jun 2012 07:48:16 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Fri, 22 Jun 2012 07:48:16 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: Date: Fri, 22 Jun 2012 07:48:16 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy)" Content-Type: multipart/alternative; boundary=bcaec554dfeeee21df04c310b8d5 X-Gm-Message-State: ALoCoQkqG9Hcgw0Cfqr4wTS4jB0diA5mmZijwjrXWUjllc6E9FwBe5X/b5VIhGw8XNE6KLYZk4V+ Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 14:48:19 -0000 --bcaec554dfeeee21df04c310b8d5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Jun 22, 2012 at 5:53 AM, Lange, Jeffrey K (GE Energy) < jeffrey.K.lange@ge.com> wrote: > Currently timezone-location and timezone-name are defined in the YANG > modle with =93if-feature=94, but timezone-utc-offset is not. I think tha= t this > should also be gated on an if-feature. If I plan on having timezone > support in my product, I want to ensure that daylight savings time is > properly reflected. To do this I=92d use the zoneinfo database or the li= ke. > If I also needed to support the manual setting of time offsets, I=92d nee= d to > put custom code everywhere in the system where a time is calculated rathe= r > than just relying on the standard system APIs to give me the current and > correct time.**** > > ** > why is this leaf so hard to support? > ** > > Without having this as a feature you are implying that I MUST support thi= s > additional functionality if I want to use the ietf-system model.**** > > ** > that's how YANG conformance works > ** > > Perhaps a config false leaf that returns the current UTC offset would be > useful too. That way if you set the timezone via a name, you can also > check to ensure that it is really the UTC offset you are expecting.**** > > ** > I don't think any changes are needed. A device should support setting the timezone. The config-true leaf also returns the current value. Andy > ** > > Thanks,**** > > ** ** > > *Jeff Lange* > Lead Software Engineer > GE Energy Services > Digital Energy > > T *+1 585 242 8375* > F *+1 585 241 5590* > Jeffrey.K.Lange@ge.com > www.GEDigitalEnergy.com > > 175 Science Parkway > Rochester, NY 14620 United States > > GE imagination at work > > **** > > ** ** > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --bcaec554dfeeee21df04c310b8d5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 22, 2012 at 5:53 AM, Lange, = Jeffrey K (GE Energy) <jeffrey.K.lange@ge.com> wrote:

Currently timezone-location and timezone-name are de= fined in the YANG modle with =93if-feature=94, but timezone-utc-offset is n= ot.=A0 I think that this should also be gated on an if-feature.=A0 If I pla= n on having timezone support in my product, I want to ensure that daylight savings time is properly reflected.=A0 To d= o this I=92d use the zoneinfo database or the like.=A0 If I also needed to = support the manual setting of time offsets, I=92d need to put custom code e= verywhere in the system where a time is calculated rather than just relying on the standard system APIs to give me= the current and correct time.

=A0


why is this leaf so hard to support?
=A0

Without having this as a feature you are implying th= at I MUST support this additional functionality if I want to use the ietf-s= ystem model.

=A0


that's how YANG conformance works
=A0

Perhaps a config false leaf that returns the current= UTC offset would be useful too.=A0 That way if you set the timezone via a = name, you can also check to ensure that it is really the UTC offset you are= expecting.

=A0


I don't think any changes are needed.
A device should = support setting the timezone.
The config-true leaf also returns t= he current value.

Andy

=A0

Thanks,

=A0

Jeff Lange
Lead Software Engineer
GE Energy Services
Digital Energy

T=A0+1 585 242 8375
F=A0+1 585 241 5590
Jeffrey.K.Lange= @ge.com
www.GEDigitalE= nergy.com

175 Science Parkway
Rochester,=A0NY=A014620=A0United States

GE imagination at work

=A0


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


--bcaec554dfeeee21df04c310b8d5-- From jeffrey.K.lange@ge.com Fri Jun 22 08:04:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E45D21F8668 for ; Fri, 22 Jun 2012 08:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2ThbS6bFhpP for ; Fri, 22 Jun 2012 08:04:17 -0700 (PDT) Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by ietfa.amsl.com (Postfix) with ESMTP id 47EE021F8611 for ; Fri, 22 Jun 2012 08:04:17 -0700 (PDT) Received: from alpmlip12.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKT+SJcP8UGlFaqdvi/sY6t0RR0A8SopJD@postini.com; Fri, 22 Jun 2012 08:04:17 PDT Received: from unknown (HELO cinmlef06.e2k.ad.ge.com) ([3.159.213.37]) by alpmlip12.e2k.ad.ge.com with ESMTP; 22 Jun 2012 11:04:14 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jun 2012 11:04:13 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jun 2012 11:04:13 -0400 Received: from CINMBCNA05.e2k.ad.ge.com (3.159.212.59) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 22 Jun 2012 11:04:12 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA05.e2k.ad.ge.com ([169.254.5.129]) with mapi id 14.02.0283.003; Fri, 22 Jun 2012 11:04:12 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Andy Bierman Thread-Topic: [netmod] ietf-system: timezone-utc-offset Thread-Index: Ac1QdKsNKID7x3/NQD+98jr20yH9FQAMupYAAAgjSbA= Date: Fri, 22 Jun 2012 15:04:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jun 2012 15:04:13.0277 (UTC) FILETIME=[48EB58D0:01CD5088] Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 15:04:18 -0000 >why is this leaf so hard to support? Because by allowing someone to specify a UTC offset, you are losing the=A0a= bility to take advantage of setting the timezone via the tzdatabase which m= eans that if you have no way of automatically adjusting for daylight saving= s time. Sure you could 'guess' the timezone based on the UTC offset, but = that is hardly an exact method. I don't want to have to write a whole bunch of utility code just to get the= current time when all the standard system APIs know how to use /etc/localt= ime -Jeff Jeff Lange Lead Software Engineer GE Energy Services Digital Energy T=A0+1 585 242 8375 F=A0+1 585 241 5590 Jeffrey.K.Lange@ge.com www.GEDigitalEnergy.com 175 Science Parkway Rochester,=A0NY=A014620=A0United States GE imagination at work From j.schoenwaelder@jacobs-university.de Fri Jun 22 08:22:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAE021F86B2 for ; Fri, 22 Jun 2012 08:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.197 X-Spam-Level: X-Spam-Status: No, score=-103.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHWW0WfHZSwx for ; Fri, 22 Jun 2012 08:22:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EF8F621F85E4 for ; Fri, 22 Jun 2012 08:22:31 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFF8320BFE; Fri, 22 Jun 2012 17:22:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XZfVqbvf0jbB; Fri, 22 Jun 2012 17:22:30 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95CD720BFC; Fri, 22 Jun 2012 17:22:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 341CB201FEF5; Fri, 22 Jun 2012 17:22:30 +0200 (CEST) Date: Fri, 22 Jun 2012 17:22:30 +0200 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy)" Message-ID: <20120622152230.GA85847@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy)" , Andy Bierman , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 15:22:32 -0000 On Fri, Jun 22, 2012 at 03:04:12PM +0000, Lange, Jeffrey K (GE Energy) wrote: > > >why is this leaf so hard to support? > > Because by allowing someone to specify a UTC offset, you are losing the ability to take advantage of setting the timezone via the tzdatabase which means that if you have no way of automatically adjusting for daylight savings time. Sure you could 'guess' the timezone based on the UTC offset, but that is hardly an exact method. If someone configures lets say UTC offset +1, he likely wants exactly that and does not want any daylight savings time changes. > I don't want to have to write a whole bunch of utility code just to get the current time when all the standard system APIs know how to use /etc/localtime > I do not think you have to write lots of complicated code. On Unix systems, library functions control which timezone your process lives in. And there are even zone files for GMT+1, GMT-1, ... hence setting a system's time to UTC +1 is also not a big deal. /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 Jun 22 08:33:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4A021F8716 for ; Fri, 22 Jun 2012 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6tK-R-S73Ug for ; Fri, 22 Jun 2012 08:33:54 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5570421F86EA for ; Fri, 22 Jun 2012 08:33:54 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4087092lbb.31 for ; Fri, 22 Jun 2012 08:33:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZuBO/YWGVY5H0/z3TYJRSdJRISYkdtoE6kAQASmfh4A=; b=BS03eneV090avLdcFdfvwEMPhcxVdsCacqcbnt2fO4VnmeV9D+JDgwdZt1aEe3HLjJ WCx51BiGm4e05aE58jQH7rcbD15OMEe2+JV26Qp2Rdns4KJBalRW6YYaFLV80XjHDpOy Li9gp37x4JcfxMlRCy2CSMguMkkJylfgTTeYDXP7uQno4BYmjydCB7F6mNwxmCd/ZTV0 uK12NpnTBAUDpfo905tURNanYhK0lynhWkw2xtjdz/78i1r76f6G9gnI8mSB+dELKHLV hF63LK8qhR3nPJvyJAtqbzAou7iJoSrj2wg90ozJhZ69IQMdyTTNWGNuTFMmZMZT77mI k7EQ== MIME-Version: 1.0 Received: by 10.112.45.168 with SMTP id o8mr1620437lbm.88.1340379233282; Fri, 22 Jun 2012 08:33:53 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Fri, 22 Jun 2012 08:33:53 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: Date: Fri, 22 Jun 2012 08:33:53 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy)" Content-Type: multipart/alternative; boundary=bcaec554dda610692204c3115c55 X-Gm-Message-State: ALoCoQkPlM1Br2Ewsbao/ciBPnRtVxog9xVWG6fTrcSX8JEX7jBadHKxe2NxG3pnT3dvGTHorZ/s Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 15:33:55 -0000 --bcaec554dda610692204c3115c55 Content-Type: text/plain; charset=ISO-8859-1 Hi, I can see your point. The intent was to make timezone-utc-offset mandatory as a fallback. I can see making this optional with a YANG feature. There is no way in YANG to say "the server MUST implement 1 of these 3 features" except in a random description-stmt. By definition, all YANG features are purely optional. Andy On Fri, Jun 22, 2012 at 8:04 AM, Lange, Jeffrey K (GE Energy) < jeffrey.K.lange@ge.com> wrote: > > >why is this leaf so hard to support? > > Because by allowing someone to specify a UTC offset, you are losing > the ability to take advantage of setting the timezone via the tzdatabase > which means that if you have no way of automatically adjusting for daylight > savings time. Sure you could 'guess' the timezone based on the UTC > offset, but that is hardly an exact method. > > I don't want to have to write a whole bunch of utility code just to get > the current time when all the standard system APIs know how to use > /etc/localtime > > -Jeff > > Jeff Lange > Lead Software Engineer > GE Energy Services > Digital Energy > > T +1 585 242 8375 > F +1 585 241 5590 > Jeffrey.K.Lange@ge.com > www.GEDigitalEnergy.com > > 175 Science Parkway > Rochester, NY 14620 United States > > GE imagination at work > > > > > --bcaec554dda610692204c3115c55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I can see your point.
The intent was to ma= ke timezone-utc-offset mandatory as a fallback.
I can see making = this optional with a YANG feature.
There is no way in YANG to say= "the server MUST implement 1 of
these 3 features" except in a random description-stmt.
= By definition, all YANG features are purely optional.

<= div>
Andy


On Fri= , Jun 22, 2012 at 8:04 AM, Lange, Jeffrey K (GE Energy) &= lt;jeffrey.K.la= nge@ge.com> wrote:

>why is this leaf so hard to support?

Because by allowing someone to specify a UTC offset, you are losing the=A0a= bility to take advantage of setting the timezone via the tzdatabase which m= eans that if you have no way of automatically adjusting for daylight saving= s time. =A0 Sure you could 'guess' the timezone based on the UTC of= fset, but that is hardly an exact method.

I don't want to have to write a whole bunch of utility code just to get= the current time when all the standard system APIs know how to use /etc/lo= caltime

-Jeff

Jeff Lange
Lead Software Engineer
GE Energy Services
Digital Energy

T=A0+1 585 242 8375
F=A0+1 585 241 5590
Jeffrey.K.Lange@ge.com
www.GEDigitalE= nergy.com

175 Science Parkway
Rochester,=A0NY=A014620=A0United States

GE imagination at work





--bcaec554dda610692204c3115c55-- From jeffrey.K.lange@ge.com Fri Jun 22 08:41:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5029621F85C0 for ; Fri, 22 Jun 2012 08:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcW5uF7S91S4 for ; Fri, 22 Jun 2012 08:41:48 -0700 (PDT) Received: from exprod5og112.obsmtp.com (exprod5og112.obsmtp.com [64.18.0.24]) by ietfa.amsl.com (Postfix) with ESMTP id EEADB21F8528 for ; Fri, 22 Jun 2012 08:41:47 -0700 (PDT) Received: from alpmlip10.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob112.postini.com ([64.18.4.12]) with SMTP ID DSNKT+SSOt0uy/xq86KsTanLdx0y2I12cqAJ@postini.com; Fri, 22 Jun 2012 08:41:48 PDT Received: from unknown (HELO cinmlef12.e2k.ad.ge.com) ([3.159.213.59]) by alpmlip10.e2k.ad.ge.com with ESMTP; 22 Jun 2012 11:41:43 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef12.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jun 2012 11:41:43 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Jun 2012 11:41:42 -0400 Received: from CINMBCNA05.e2k.ad.ge.com (3.159.212.59) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 22 Jun 2012 11:41:42 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA05.e2k.ad.ge.com ([169.254.5.129]) with mapi id 14.02.0283.003; Fri, 22 Jun 2012 11:41:42 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Juergen Schoenwaelder Thread-Topic: [netmod] ietf-system: timezone-utc-offset Thread-Index: Ac1QdKsNKID7x3/NQD+98jr20yH9FQAMupYAAAgjSbD//8h2AIAAQAig Date: Fri, 22 Jun 2012 15:41:41 +0000 Message-ID: References: <20120622152230.GA85847@elstar.local> In-Reply-To: <20120622152230.GA85847@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jun 2012 15:41:42.0607 (UTC) FILETIME=[859FDDF0:01CD508D] Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 15:41:50 -0000 > >=20 > > >why is this leaf so hard to support? > >=20 > > Because by allowing someone to specify a UTC offset, you are losing the= =A0ability to take advantage of setting the timezone via the tzdatabase whi= ch means that if you have no way of automatically adjusting for daylight sa= vings time. Sure you could 'guess' the timezone based on the UTC offset, = but that is hardly an exact method. > > If someone configures lets say UTC offset +1, he likely wants exactly tha= t and does not want any daylight savings time changes. I can buy that, but perhaps there should be some description text stating t= hat if the device supports automatic DST adjustment, setting the timezone v= ia the utc-offset will prevent DST adjustments. Or even some way of config= uring if you want the device to observe DST or not (perhaps that's just set= ting via the utc-offset).. and in that vein, should there be a config false= or a feature that says if a device can even support DST? > > > I don't want to have to write a whole bunch of utility code just to=20 > > get the current time when all the standard system APIs know how to use= =20 > > /etc/localtime >=20 >=20 > I do not think you have to write lots of complicated code. On Unix system= s, library functions control which timezone your process lives in. And ther= e are even zone files for GMT+1, GMT-1, ... hence setting a system's time t= o UTC +1 is also not a big deal. I hadn't seen these zone files, that would help as long as you limit the of= fsets to exact hours (I believe Afghanistan is a +4:30 during DST however)= =20 It's amazing how something as simple as time can be so damn complex :-) -Jeff Jeff Lange Lead Software Engineer GE Energy Services Digital Energy T=A0+1 585 242 8375 F=A0+1 585 241 5590 Jeffrey.K.Lange@ge.com www.GEDigitalEnergy.com 175 Science Parkway Rochester,=A0NY=A014620=A0United States GE imagination at work From phil@juniper.net Fri Jun 22 09:33:30 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DDF21F8704 for ; Fri, 22 Jun 2012 09:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2esWbDiB53z7 for ; Fri, 22 Jun 2012 09:33:28 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0179921F8621 for ; Fri, 22 Jun 2012 09:33:18 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT+SeTpia3nYI0te6ECV3/K7gWSl3NuIc@postini.com; Fri, 22 Jun 2012 09:33:21 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 22 Jun 2012 09:31:54 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q5MGVsh43323; Fri, 22 Jun 2012 09:31:54 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q5MGVrOA042732; Fri, 22 Jun 2012 12:31:53 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201206221631.q5MGVrOA042732@idle.juniper.net> To: "Lange, Jeffrey K (GE Energy)" In-Reply-To: Date: Fri, 22 Jun 2012 12:31:53 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 16:33:30 -0000 >> If someone configures lets say UTC offset +1, he likely wants exactly that and does no >>t want any daylight savings time changes. In the real world, this is not likely. Folks want the real time zone with the real local rules, however annoying those rules are. >It's amazing how something as simple as time can be so damn complex :-) Time is an _amazingly_ complex issue. BSD has done a great job here and makes the Gold Standard. The zoneinfo files in /usr/share/zoneinfo/ describe 459 sets of time zone rules, covering not only current rules but historical rules so files with pre-DST-changes timestamps are displayed correctly. Handles exotics like Sun Time and Indiana Amazingly complex...... If you are making an offset, be sure to allow stuff like "EST5EDT". FWIW: The 459 number above is freebsd 8.2; macosx has 580 and BSD head has even more. Hurray! JUNOS-11.4 lists 427, as well as naked numbers and EST5EDT and other values supported by BSD. Thanks, Phil From j.schoenwaelder@jacobs-university.de Fri Jun 22 09:33:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D18C21F86BE for ; Fri, 22 Jun 2012 09:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cql7VbQdA2rG for ; Fri, 22 Jun 2012 09:33:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 22FB321F8705 for ; Fri, 22 Jun 2012 09:33:46 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F22C820BFA; Fri, 22 Jun 2012 18:33:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Aa01jlzwwHyR; Fri, 22 Jun 2012 18:33:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 603EC20BE1; Fri, 22 Jun 2012 18:33:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EC83620204B0; Fri, 22 Jun 2012 18:33:44 +0200 (CEST) Date: Fri, 22 Jun 2012 18:33:44 +0200 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy)" Message-ID: <20120622163344.GA87006@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy)" , Andy Bierman , "netmod@ietf.org" References: <20120622152230.GA85847@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 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] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 16:33:48 -0000 On Fri, Jun 22, 2012 at 03:41:41PM +0000, Lange, Jeffrey K (GE Energy) wrote: > > > > > > > >why is this leaf so hard to support? > > > > > > Because by allowing someone to specify a UTC offset, you are losing the ability to take advantage of setting the timezone via the tzdatabase which means that if you have no way of automatically adjusting for daylight savings time. Sure you could 'guess' the timezone based on the UTC offset, but that is hardly an exact method. > > > > If someone configures lets say UTC offset +1, he likely wants exactly that and does not want any daylight savings time changes. > > I can buy that, but perhaps there should be some description text stating that if the device supports automatic DST adjustment, setting the timezone via the utc-offset will prevent DST adjustments. This is what I assumed this means. If you have to manage devices in many different time zones, you soon discover the value of absolute timezone offsets so you can easily compare timestamps in logs without having to ask the question whether in the time zones involved had DST changes or not. Perhaps we need clarification that absolute offset means absolute offset. > Or even some way of configuring if you want the device to observe DST or not (perhaps that's just setting via the utc-offset).. and in that vein, should there be a config false or a feature that says if a device can even support DST? Do the zones in the zone files not take care of this? Some are fixed, some are moving, no? > > And there are even zone files for GMT+1, GMT-1, ... hence setting a system's time to UTC +1 is also not a big deal. > > I hadn't seen these zone files, that would help as long as you limit the offsets to exact hours (I believe Afghanistan is a +4:30 during DST however) Yep. But then I would perhaps start thinking about how to generate the proper zone file instead of having two mechanisms to support in my code. I think for simple zones with fixed offsets, this is rather simple (you create a one line zone definition and you compile it using zic into a zone file). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Jun 22 09:43:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31C521F8773 for ; Fri, 22 Jun 2012 09:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DH0CJusocnV for ; Fri, 22 Jun 2012 09:43:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 223A421F8771 for ; Fri, 22 Jun 2012 09:43:29 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5397320BFA; Fri, 22 Jun 2012 18:43:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 16eDphvKC3md; Fri, 22 Jun 2012 18:43:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBB8220BE1; Fri, 22 Jun 2012 18:43:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 88A78202058D; Fri, 22 Jun 2012 18:43:27 +0200 (CEST) Date: Fri, 22 Jun 2012 18:43:27 +0200 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20120622164327.GA87056@elstar.local> Mail-Followup-To: Phil Shafer , "Lange, Jeffrey K (GE Energy)" , "netmod@ietf.org" References: <201206221631.q5MGVrOA042732@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201206221631.q5MGVrOA042732@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 16:43:30 -0000 On Fri, Jun 22, 2012 at 12:31:53PM -0400, Phil Shafer wrote: > Time is an _amazingly_ complex issue. BSD has done a great job here > and makes the Gold Standard. The zoneinfo files in /usr/share/zoneinfo/ > describe 459 sets of time zone rules, covering not only current rules > but historical rules so files with pre-DST-changes timestamps are > displayed correctly. Handles exotics like Sun Time and Indiana > Amazingly complex...... > > If you are making an offset, be sure to allow stuff like "EST5EDT". > > FWIW: The 459 number above is freebsd 8.2; macosx has 580 and BSD > head has even more. Hurray! JUNOS-11.4 lists 427, as well as naked > numbers and EST5EDT and other values supported by BSD. I think the maintenance of the zones moved to IANA as described in RFC 6557. I am not sure BSD owns the credits of having the Gold Standard. At the end, it is almost always a few individuals who do the work most people use without every thinking about 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 Sat Jun 23 07:37:27 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C528F21F84CD for ; Sat, 23 Jun 2012 07:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KKoy6LhRMIp for ; Sat, 23 Jun 2012 07:37:27 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3D60021F8480 for ; Sat, 23 Jun 2012 07:37:26 -0700 (PDT) Received: from localhost (213-65-181-96-no181.tbcn.telia.com [213.65.181.96]) by mail.tail-f.com (Postfix) with ESMTPSA id 4627B1200DB5; Sat, 23 Jun 2012 16:37:22 +0200 (CEST) Date: Sat, 23 Jun 2012 16:37:17 +0200 (CEST) Message-Id: <20120623.163717.383201565.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <20120622152230.GA85847@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 14:37:27 -0000 "Lange, Jeffrey K (GE Energy)" wrote: > = > > > = > > > >why is this leaf so hard to support? > > > = > > > Because by allowing someone to specify a UTC offset, you are losi= ng > > > the=A0ability to take advantage of setting the timezone via the t= zdatabase > > > which means that if you have no way of automatically adjusting fo= r > > > daylight savings time. Sure you could 'guess' the timezone based= on the > > > UTC offset, but that is hardly an exact method. > > > > If someone configures lets say UTC offset +1, he likely wants exact= ly that > > and does not want any daylight savings time changes. > = > I can buy that, but perhaps there should be some description text sta= ting that > if the device supports automatic DST adjustment, setting the timezone= via the > utc-offset will prevent DST adjustments. This is reasonable. I think we should make this clarification. > > > I don't want to have to write a whole bunch of utility code just = to = > > > get the current time when all the standard system APIs know how t= o use = > > > /etc/localtime > > = > > = > > I do not think you have to write lots of complicated code. So... do you think that this is still an issue, or would the clarification above be enough? /martin From phil@juniper.net Sat Jun 23 15:55:01 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408BE21F8639 for ; Sat, 23 Jun 2012 15:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUgJWNCJHUc3 for ; Sat, 23 Jun 2012 15:55:00 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 91C6521F8638 for ; Sat, 23 Jun 2012 15:54:56 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT+ZJP/C8jhkyaU2jDp2nji2oedzlMzup@postini.com; Sat, 23 Jun 2012 15:55:00 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 23 Jun 2012 15:53:24 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q5NMrNh65635; Sat, 23 Jun 2012 15:53:23 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q5NMrLuS048124; Sat, 23 Jun 2012 18:53:22 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201206232253.q5NMrLuS048124@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20120622164327.GA87056@elstar.local> Date: Sat, 23 Jun 2012 18:53:21 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 22:55:01 -0000 Juergen Schoenwaelder writes: >I think the maintenance of the zones moved to IANA as described in RFC >6557. I am not sure BSD owns the credits of having the Gold Standard. Yup, BSD was just the place it first appeared, IIRC. 4.3BSD. >At the end, it is almost always a few individuals who do the work most >people use without every thinking about it. ;-) Yup, of course. Arthur Olson and Paul Eggert did most of the the ctime lib, but there is a wide/wild community that contributed ideas, etc. Thanks, Phil From phil@juniper.net Sat Jun 23 16:03:13 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81FF21F8638 for ; Sat, 23 Jun 2012 16:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndd6-nk5z4jM for ; Sat, 23 Jun 2012 16:03:13 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 43E3F21F8634 for ; Sat, 23 Jun 2012 16:03:10 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT+ZLLSGnoCajl2wTNBX+WXl8/FD+k4LV@postini.com; Sat, 23 Jun 2012 16:03:13 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 23 Jun 2012 15:57:21 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q5NMvKh68285; Sat, 23 Jun 2012 15:57:20 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q5NMvJVp048181; Sat, 23 Jun 2012 18:57:19 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201206232257.q5NMvJVp048181@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20120622163344.GA87006@elstar.local> Date: Sat, 23 Jun 2012 18:57:19 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2012 23:03:14 -0000 Juergen Schoenwaelder writes: >If you have to manage devices in >many different time zones, you soon discover the value of absolute >timezone offsets so you can easily compare timestamps in logs without >having to ask the question whether in the time zones involved had DST >changes or not. FWIW, this is not my experience. Machines get set to the time zone of the NOC (or person) that cares for them. Sort of crazy, but true. One of the benefits of syslog-ng is that we can ship timestamps as structured data and let the host store/display them in whatever time zone is desired. Thanks, Phil From mbj@tail-f.com Sun Jun 24 23:03:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F14A21F851A for ; Sun, 24 Jun 2012 23:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5siuhtZnuHj for ; Sun, 24 Jun 2012 23:03:03 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDE821F8507 for ; Sun, 24 Jun 2012 23:03:02 -0700 (PDT) Received: from localhost (95.209.156.174.bredband.tre.se [95.209.156.174]) by mail.tail-f.com (Postfix) with ESMTPSA id AE5AB1200D57; Mon, 25 Jun 2012 08:02:57 +0200 (CEST) Date: Mon, 25 Jun 2012 08:02:51 +0200 (CEST) Message-Id: <20120625.080251.522233675.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120612.133758.544594921302340818.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 06:03:03 -0000 Ladislav Lhotka wrote: > > On Jun 12, 2012, at 1:37 PM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> > >> On Jun 12, 2012, at 12:54 PM, Martin Bjorklund wrote: > >> > >>> Juergen Schoenwaelder wrote: > >>>> I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my > >>>> comments/questions. > >>>> > >>>> a) p1: I am wondering whether the title is correct. The document > >>>> really is concerned with the configuration of IP interfaces as far > >>>> as I understand it. It does not do routing and it also leaves out > >>>> configuration things such as reassembly timers, default TTLs, etc. > >>>> So would a more accurate title be "A Yang Data Model for IP > >>>> Interface Configuration"? And if so, should the module name become > >>>> ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? > >>> > >>> Do we want to add global parameters such as default TTLs? If not, I > >>> do not mind changing the title. > >> > >> Then there are also the global operational data structures from > >> sec. 5.1 of RFC 4861: neighbor cache, etc. I think it is better to add > >> the necessary global data and leave the scope of the I-D and module as > >> "core IP". > > > > So what is the "necessary global data" we should add? > > They are specified in said RFC: > > 1. neighbor cache > 2. destination cache > 3. prefix list > 4. default router list > > The latter two are in the routing module but the former two aren't. But RFC 4861 specifies these as data structures per interface. So even if we add those Juergen's comment still applies. /martin From mbj@tail-f.com Sun Jun 24 23:31:21 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41FE21F856C for ; Sun, 24 Jun 2012 23:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vt82hsTBm0-p for ; Sun, 24 Jun 2012 23:31:17 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id ABAE821F855F for ; Sun, 24 Jun 2012 23:31:17 -0700 (PDT) Received: from localhost (95.209.156.174.bredband.tre.se [95.209.156.174]) by mail.tail-f.com (Postfix) with ESMTPSA id E0B3A1200D2F; Mon, 25 Jun 2012 08:31:05 +0200 (CEST) Date: Mon, 25 Jun 2012 08:30:36 +0200 (CEST) Message-Id: <20120625.083036.514882828.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120612111428.GD70760@elstar.local> References: <20120610134853.GC60379@elstar.local> <20120612.125452.1645516036024914306.mbj@tail-f.com> <20120612111428.GD70760@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 06:31:21 -0000 Juergen Schoenwaelder wrote: > On Tue, Jun 12, 2012 at 12:54:52PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my > > > comments/questions. [...] > > > d) p5: > > > > > > The objects ipNetToPhysicalTable and ipAddressStatus are writable in > > > the IP-MIB but do not represent configuration, and are thus not > > > mapped to the YANG module. > > > > > > This seems odd. Static address mappings can typically be configured > > > and some people do this (either for security or performance > > > reasons). As far as I understand things in the Linux world, address > > > mappings seem to be interface specific. > > > > For some discussion/questions, see > > http://www.ietf.org/mail-archive/web/netmod/current/msg06514.html. > > > > ipNetToPhysicalTable says: > > > > As the entries in this table are typically not persistent > > when this object is written the entity SHOULD NOT save the > > change to non-volatile storage. > > > > which is why I did not include this. > > Well, that might be true for the MIB. I happen to run boxes that have > static mappings and I happen to run boxes that do proxyarp stuff. I am > not saying this has to be included or not Ok. So let's ask the question: Do you think we should include configuration parameters for this? If so, do you have a suggestion for the data model? > , I was however somewhat > irritated by the reasoning. The text talks about the relationship to the MIB, so it reflects the MIB definition. > > > f) p10: If I do not what autoconf address at all, I have to set all > > > create-* leaves to false? Should there be a global switch? Not > > > sure, just asking... > > > > I think we discussed this but can't find any notes. So, should there > > be an option to disable stateless autoconfiguration on an ipv6-enabled > > interface? > > I guess someone needs to check what the IPv6 specs really say about > this. I have boxes that have static IPv6 addresses configured and I > would prefer them to ignore any wired RAs on those links. Actually, since create-temporary-addresses is false by default, there is really just one leaf you have to set to false. So adding another leaf to control this leaf is probably overkill. > > > g) p13: Should there be text discussing ipv4/forwarding and > > > ipv6/forwarding? Or the impact of the autoconf knobs? > > > > RFC 4293 has text for ipForwarding and ipv6IpForwarding, so we should > > probably have something similar. What would the security impact be > > for the autoconf parameters? > > The reason we use statically configured IPv4 and IPv6 addresses on our > servers is to improve their robustness. We considered moving to static > address mappings as well but did not go there (yet). If you use > autoconfig, then you have to trust something and whether that trust is > justified is something to consider. I will need help with this. Could you suggest a paragraph to add? /martin From lhotka@nic.cz Mon Jun 25 02:46:03 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DFC21F8474 for ; Mon, 25 Jun 2012 02:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvyENvuiKYIf for ; Mon, 25 Jun 2012 02:45:58 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7991D21F8475 for ; Mon, 25 Jun 2012 02:45:58 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id 7D7F613F7BA; Mon, 25 Jun 2012 11:45:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340617550; bh=gvmabz/7GnP6QtJQdthA6MqNypRCZK+HiERX8qlG01A=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Zvn1UyIgF+28wOUluscoeYmBjHyLc3hnwHQS1pFWbzWU5UNHrXFHq13Vq+fg3ASbI dNaYuDZWpChUK1sjmdjHWk2nA6SAJa+y7R4pgnJKNz4SXtzTyeE+/jgxypD2+/k8OF 8WGJfycmslfgRKn6JRjq6fUuSrMSNhEX7EUH31aE= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120625.080251.522233675.mbj@tail-f.com> Date: Mon, 25 Jun 2012 11:45:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0E552CBA-788E-4E27-81CB-5F1053B96D20@nic.cz> References: <20120612.133758.544594921302340818.mbj@tail-f.com> <20120625.080251.522233675.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 09:46:03 -0000 On Jun 25, 2012, at 8:02 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Jun 12, 2012, at 1:37 PM, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>> On Jun 12, 2012, at 12:54 PM, Martin Bjorklund wrote: >>>>=20 >>>>> Juergen Schoenwaelder = wrote: >>>>>> I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my >>>>>> comments/questions. >>>>>>=20 >>>>>> a) p1: I am wondering whether the title is correct. The document >>>>>> really is concerned with the configuration of IP interfaces as = far >>>>>> as I understand it. It does not do routing and it also leaves out >>>>>> configuration things such as reassembly timers, default TTLs, = etc. >>>>>> So would a more accurate title be "A Yang Data Model for IP >>>>>> Interface Configuration"? And if so, should the module name = become >>>>>> ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? >>>>>=20 >>>>> Do we want to add global parameters such as default TTLs? If not, = I >>>>> do not mind changing the title. >>>>=20 >>>> Then there are also the global operational data structures from >>>> sec. 5.1 of RFC 4861: neighbor cache, etc. I think it is better to = add >>>> the necessary global data and leave the scope of the I-D and module = as >>>> "core IP". >>>=20 >>> So what is the "necessary global data" we should add? >>=20 >> They are specified in said RFC: >>=20 >> 1. neighbor cache >> 2. destination cache >> 3. prefix list >> 4. default router list >>=20 >> The latter two are in the routing module but the former two aren't. >=20 > But RFC 4861 specifies these as data structures per interface. So Right, although it seems strange. In the implementations I am aware of, = the data structures for 1, 2 and 4 (routing table, forwarding table, = routing cache) are global. Only "prefix list" is clearly per-interface. > even if we add those Juergen's comment still applies. Juergen's comment certainly applies. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From jeffrey.K.lange@ge.com Mon Jun 25 04:55:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C113521F8505 for ; Mon, 25 Jun 2012 04:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHpGY9EXwBLl for ; Mon, 25 Jun 2012 04:55:07 -0700 (PDT) Received: from exprod5og114.obsmtp.com (exprod5og114.obsmtp.com [64.18.0.28]) by ietfa.amsl.com (Postfix) with ESMTP id 81C2421F8472 for ; Mon, 25 Jun 2012 04:55:05 -0700 (PDT) Received: from alpmlip12.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob114.postini.com ([64.18.4.12]) with SMTP ID DSNKT+hRmHiP7XrQyU6Fqv1C2t6cEg+OF5ZW@postini.com; Mon, 25 Jun 2012 04:55:07 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by alpmlip12.e2k.ad.ge.com with ESMTP; 25 Jun 2012 07:55:04 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Jun 2012 07:55:03 -0400 Received: from CINMBCNA04.e2k.ad.ge.com (3.159.212.58) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 25 Jun 2012 07:55:03 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA04.e2k.ad.ge.com ([169.254.4.136]) with mapi id 14.02.0283.003; Mon, 25 Jun 2012 07:55:03 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Martin Bjorklund Thread-Topic: [netmod] ietf-system: timezone-utc-offset Thread-Index: Ac1QdKsNKID7x3/NQD+98jr20yH9FQAMupYAAAgjSbD//8h2AIAAQAiggAFFqoD//UwXwA== Date: Mon, 25 Jun 2012 11:55:02 +0000 Message-ID: References: <20120622152230.GA85847@elstar.local> <20120623.163717.383201565.mbj@tail-f.com> In-Reply-To: <20120623.163717.383201565.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jun 2012 11:55:03.0885 (UTC) FILETIME=[5B64CFD0:01CD52C9] Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 11:55:07 -0000 > So... do you think that this is still an issue, or would the clarificatio= n above be enough? > >/martin I think the textual clarification should be enough. -Jeff From j.schoenwaelder@jacobs-university.de Mon Jun 25 05:28:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F47B21F84A0 for ; Mon, 25 Jun 2012 05:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6feN8V1OcDe for ; Mon, 25 Jun 2012 05:28:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3FC21F847C for ; Mon, 25 Jun 2012 05:28:52 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 325B221561; Mon, 25 Jun 2012 14:28:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4Sesek-qNt9A; Mon, 25 Jun 2012 14:28:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACEC72155C; Mon, 25 Jun 2012 14:28:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 01D2F202802C; Mon, 25 Jun 2012 14:28:49 +0200 (CEST) Date: Mon, 25 Jun 2012 14:28:49 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120625122849.GA39195@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <20120612.133758.544594921302340818.mbj@tail-f.com> <20120625.080251.522233675.mbj@tail-f.com> <0E552CBA-788E-4E27-81CB-5F1053B96D20@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E552CBA-788E-4E27-81CB-5F1053B96D20@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 12:28:56 -0000 On Mon, Jun 25, 2012 at 11:45:50AM +0200, Ladislav Lhotka wrote: > > >> They are specified in said RFC: > >> > >> 1. neighbor cache > >> 2. destination cache > >> 3. prefix list > >> 4. default router list > >> > >> The latter two are in the routing module but the former two aren't. > > > > But RFC 4861 specifies these as data structures per interface. So > > Right, although it seems strange. In the implementations I am aware of, the data structures for 1, 2 and 4 (routing table, forwarding table, routing cache) are global. Only "prefix list" is clearly per-interface. > Junos seems to configure arp entries on an interface. Both, Cisco and Linus seem to have an interface (sometimes called device) as a mandatory argument. While the kernel may just have one table, I think it is safe to follow RFC 4861, no? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Jun 25 07:51:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627F021F864D for ; Mon, 25 Jun 2012 07:51:32 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ksXxcOh9Czd for ; Mon, 25 Jun 2012 07:51:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AB44D21F8623 for ; Mon, 25 Jun 2012 07:51:31 -0700 (PDT) Received: from [10.0.0.2] (128.211.broadband6.iol.cz [88.101.211.128]) by mail.nic.cz (Postfix) with ESMTPSA id 81A0114035C; Mon, 25 Jun 2012 16:51:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340635890; bh=fkLmzxyemJpzVlpQ+SY5afUqvaJoNmKARBC6fDq5uUk=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=jvNyNpsw7HF9huyg52hRNgQeJilyJ5sb/vbzIrNEFoNTKO/h/zZqOGCzzQQ0Pr6mg fc7oftHvEP6ixipP6VotNfFLcVK+2o41w1AXLu0guilABiwW/jk+bhwHbC9HlKoYSE KInIy6VcV519qrBPop3mwsLdgd2KzR3ZU+7q8qZA= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120625122849.GA39195@elstar.local> Date: Mon, 25 Jun 2012 16:51:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120612.133758.544594921302340818.mbj@tail-f.com> <20120625.080251.522233675.mbj@tail-f.com> <0E552CBA-788E-4E27-81CB-5F1053B96D20@nic.cz> <20120625122849.GA39195@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 14:51:32 -0000 On Jun 25, 2012, at 2:28 PM, Juergen Schoenwaelder wrote: > On Mon, Jun 25, 2012 at 11:45:50AM +0200, Ladislav Lhotka wrote: >>=20 >>>> They are specified in said RFC: >>>>=20 >>>> 1. neighbor cache >>>> 2. destination cache >>>> 3. prefix list >>>> 4. default router list >>>>=20 >>>> The latter two are in the routing module but the former two aren't. >>>=20 >>> But RFC 4861 specifies these as data structures per interface. So >>=20 >> Right, although it seems strange. In the implementations I am aware = of, the data structures for 1, 2 and 4 (routing table, forwarding table, = routing cache) are global. Only "prefix list" is clearly per-interface. >>=20 >=20 > Junos seems to configure arp entries on an interface. Both, Cisco and > Linus seem to have an interface (sometimes called device) as a > mandatory argument. While the kernel may just have one table, I think > it is safe to follow RFC 4861, no? I think it is generally useful to be able to see the entire ARP table = without being forced to iterate over all interfaces, but also have = options to filter the data, e.g. to view the entries for a selected = interface. This way we can satisfy 4861 requirements, too, because we keep the = necessary information for each interface even though the underlying data = structure is global. 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Jun 25 08:13:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F10321F847E for ; Mon, 25 Jun 2012 08:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1cXdqmJ2wRA for ; Mon, 25 Jun 2012 08:13:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 79EA521F847C for ; Mon, 25 Jun 2012 08:13:41 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C877720C6F; Mon, 25 Jun 2012 17:13:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kIC4yQnLH3FE; Mon, 25 Jun 2012 17:13:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21DC920C6C; Mon, 25 Jun 2012 17:13:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CB77820285CD; Mon, 25 Jun 2012 17:13:39 +0200 (CEST) Date: Mon, 25 Jun 2012 17:13:39 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120625151339.GA40375@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <20120612.133758.544594921302340818.mbj@tail-f.com> <20120625.080251.522233675.mbj@tail-f.com> <0E552CBA-788E-4E27-81CB-5F1053B96D20@nic.cz> <20120625122849.GA39195@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] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 15:13:42 -0000 On Mon, Jun 25, 2012 at 04:51:27PM +0200, Ladislav Lhotka wrote: > > On Jun 25, 2012, at 2:28 PM, Juergen Schoenwaelder wrote: > > > On Mon, Jun 25, 2012 at 11:45:50AM +0200, Ladislav Lhotka wrote: > >> > >>>> They are specified in said RFC: > >>>> > >>>> 1. neighbor cache > >>>> 2. destination cache > >>>> 3. prefix list > >>>> 4. default router list > >>>> > >>>> The latter two are in the routing module but the former two aren't. > >>> > >>> But RFC 4861 specifies these as data structures per interface. So > >> > >> Right, although it seems strange. In the implementations I am aware of, the data structures for 1, 2 and 4 (routing table, forwarding table, routing cache) are global. Only "prefix list" is clearly per-interface. > >> > > > > Junos seems to configure arp entries on an interface. Both, Cisco and > > Linus seem to have an interface (sometimes called device) as a > > mandatory argument. While the kernel may just have one table, I think > > it is safe to follow RFC 4861, no? > > I think it is generally useful to be able to see the entire ARP table without being forced to iterate over all interfaces, but also have options to filter the data, e.g. to view the entries for a selected interface. > > This way we can satisfy 4861 requirements, too, because we keep the necessary information for each interface even though the underlying data structure is global. We are talking about configuration. /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 Jun 25 08:25:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF67F21F8517 for ; Mon, 25 Jun 2012 08:25:32 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLdvYDYIHJGa for ; Mon, 25 Jun 2012 08:25:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id F408B21F84D6 for ; Mon, 25 Jun 2012 08:25:31 -0700 (PDT) Received: from [10.0.0.2] (128.211.broadband6.iol.cz [88.101.211.128]) by mail.nic.cz (Postfix) with ESMTPSA id EBE0113F7BA; Mon, 25 Jun 2012 17:25:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340637931; bh=F591eGOGh5wkKLO6UoXrCfIb/Kc9i91/FlKi9CQ8Dqc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pJo64bpf3G+pakUsyCkdiR71d56ytmtmP/VECA/E4xte1MqN1k0NAqHitJUCO8huv cIrwLBk88ZaUdha+9rnlTY/QlBt3pXx8Wvc69XGQWl+WOqY0sNUvKopvEpF6DYTQSr kZRTrdezmljdDaDvgXojSjNlEel62QlnHmh+o+KY= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120625151339.GA40375@elstar.local> Date: Mon, 25 Jun 2012 17:25:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120612.133758.544594921302340818.mbj@tail-f.com> <20120625.080251.522233675.mbj@tail-f.com> <0E552CBA-788E-4E27-81CB-5F1053B96D20@nic.cz> <20120625122849.GA39195@elstar.local> <20120625151339.GA40375@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 15:25:32 -0000 On Jun 25, 2012, at 5:13 PM, Juergen Schoenwaelder wrote: > On Mon, Jun 25, 2012 at 04:51:27PM +0200, Ladislav Lhotka wrote: >>=20 >> On Jun 25, 2012, at 2:28 PM, Juergen Schoenwaelder wrote: >>=20 >>> On Mon, Jun 25, 2012 at 11:45:50AM +0200, Ladislav Lhotka wrote: >>>>=20 >>>>>> They are specified in said RFC: >>>>>>=20 >>>>>> 1. neighbor cache >>>>>> 2. destination cache >>>>>> 3. prefix list >>>>>> 4. default router list >>>>>>=20 >>>>>> The latter two are in the routing module but the former two = aren't. >>>>>=20 >>>>> But RFC 4861 specifies these as data structures per interface. So >>>>=20 >>>> Right, although it seems strange. In the implementations I am aware = of, the data structures for 1, 2 and 4 (routing table, forwarding table, = routing cache) are global. Only "prefix list" is clearly per-interface. >>>>=20 >>>=20 >>> Junos seems to configure arp entries on an interface. Both, Cisco = and >>> Linus seem to have an interface (sometimes called device) as a >>> mandatory argument. While the kernel may just have one table, I = think >>> it is safe to follow RFC 4861, no? >>=20 >> I think it is generally useful to be able to see the entire ARP table = without being forced to iterate over all interfaces, but also have = options to filter the data, e.g. to view the entries for a selected = interface. >>=20 >> This way we can satisfy 4861 requirements, too, because we keep the = necessary information for each interface even though the underlying data = structure is global. >=20 > We are talking about configuration. We should talk about both operational state data and configuration, and = 4861 clearly talks about state data. But even for configuration, I am = not convinced that having manually configured ARP entries spread over = different places is a good design. 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 Jun 25 09:20:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2857921F8530 for ; Mon, 25 Jun 2012 09:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.206 X-Spam-Level: X-Spam-Status: No, score=-103.206 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akgHEmq+7+Zs for ; Mon, 25 Jun 2012 09:20:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 97BF121F8535 for ; Mon, 25 Jun 2012 09:20:14 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CC5F20C88; Mon, 25 Jun 2012 18:20:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1mxenRRwQtbC; Mon, 25 Jun 2012 18:20:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3D7420C7B; Mon, 25 Jun 2012 18:20:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D06B120286A3; Mon, 25 Jun 2012 18:20:12 +0200 (CEST) Date: Mon, 25 Jun 2012 18:20:12 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120625162012.GA40503@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <20120612.133758.544594921302340818.mbj@tail-f.com> <20120625.080251.522233675.mbj@tail-f.com> <0E552CBA-788E-4E27-81CB-5F1053B96D20@nic.cz> <20120625122849.GA39195@elstar.local> <20120625151339.GA40375@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] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 16:20:16 -0000 On Mon, Jun 25, 2012 at 05:25:30PM +0200, Ladislav Lhotka wrote: > > > We are talking about configuration. > > We should talk about both operational state data and configuration, > and 4861 clearly talks about state data. But even for configuration, > I am not convinced that having manually configured ARP entries > spread over different places is a good design. The title of the I-D is "A YANG Data Model for IP Configuration" and I think that is by intention. If static ARP (or ND) entries are associated with an interface, it perhaps starts to make sense that they appear/disappear when that interfaces is configured/unconfigured. At least one router vendor seems to be doing it that way. /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 Jun 25 10:06:43 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BE821F847D for ; Mon, 25 Jun 2012 10:06:43 -0700 (PDT) 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=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJw3l4qPugPX for ; Mon, 25 Jun 2012 10:06:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A504521F847C for ; Mon, 25 Jun 2012 10:06:42 -0700 (PDT) Received: from [10.0.0.2] (128.211.broadband6.iol.cz [88.101.211.128]) by mail.nic.cz (Postfix) with ESMTPSA id DFFBC13F7BA; Mon, 25 Jun 2012 19:06:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340644002; bh=mntj4JP5Rf86P560bR13DFJZeV6F46hPHiXiSDcvwZ0=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vBXed1Mv5MFHyl4xrneMMPi9KHASkznC0tgQmTNnl4rHXl2pP16keD1zW0W6TsAeB 8wt5tBhBil2LK+ZzoKfzxAGkndrM236gx5AuDgUwHIeEcJbscvamLAZI02qILVKdKp 7AFB6XlblXENijsdn8zwM2KpFrY0E+N3LK3uRCoE= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120625162012.GA40503@elstar.local> Date: Mon, 25 Jun 2012 19:06:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <697D1BE4-A7BF-428B-8612-8789ADABC215@nic.cz> References: <20120612.133758.544594921302340818.mbj@tail-f.com> <20120625.080251.522233675.mbj@tail-f.com> <0E552CBA-788E-4E27-81CB-5F1053B96D20@nic.cz> <20120625122849.GA39195@elstar.local> <20120625151339.GA40375@elstar.local> <20120625162012.GA40503@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 17:06:43 -0000 On Jun 25, 2012, at 6:20 PM, Juergen Schoenwaelder wrote: > On Mon, Jun 25, 2012 at 05:25:30PM +0200, Ladislav Lhotka wrote: >>=20 >>> We are talking about configuration. >>=20 >> We should talk about both operational state data and configuration, >> and 4861 clearly talks about state data. But even for configuration, >> I am not convinced that having manually configured ARP entries >> spread over different places is a good design. >=20 > The title of the I-D is "A YANG Data Model for IP Configuration" and I > think that is by intention. Hmm, this interpretation surprises me. So the state data tables are = intentionally left out? I think it is quite important that the client = have a way for querying the tables, either using generic or via a = special RPC method. =20 >=20 >=20 > If static ARP (or ND) entries are associated with an interface, it > perhaps starts to make sense that they appear/disappear when that > interfaces is configured/unconfigured. At least one router vendor > seems to be doing it that way. In FreeBSD, the '-i' option is only applicable to display operations of = the arp(8) command (as a filter). In Linux, it can be optionally = specified also when setting a manual entry. If it is not, the kernel = will assign it to the interface that happens to be configured with the = corresponding prefix. By forcing manual ARP entries to be bound to = interfaces, we lose this kind of semantics. 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 ietfc@btconnect.com Tue Jun 26 03:55:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E2E21F8613 for ; Tue, 26 Jun 2012 03:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNAOJrxC3PTg for ; Tue, 26 Jun 2012 03:55:51 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 801DF21F8609 for ; Tue, 26 Jun 2012 03:55:51 -0700 (PDT) Received: from mail151-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Jun 2012 10:54:10 +0000 Received: from mail151-ch1 (localhost [127.0.0.1]) by mail151-ch1-R.bigfish.com (Postfix) with ESMTP id 4632EE0138; Tue, 26 Jun 2012 10:54:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT012.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542M1432Izz1202hzz1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail151-ch1 (localhost.localdomain [127.0.0.1]) by mail151-ch1 (MessageSwitch) id 1340708048605007_23775; Tue, 26 Jun 2012 10:54:08 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.232]) by mail151-ch1.bigfish.com (Postfix) with ESMTP id 87B5942009C; Tue, 26 Jun 2012 10:54:08 +0000 (UTC) Received: from DB3PRD0702HT012.eurprd07.prod.outlook.com (157.55.224.141) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Jun 2012 10:54:08 +0000 Received: from AMSPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.5) by pod51017.outlook.com (10.3.5.132) with Microsoft SMTP Server (TLS) id 14.15.86.1; Tue, 26 Jun 2012 10:55:33 +0000 Message-ID: <014d01cd5389$b7e86c60$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka , Juergen Schoenwaelder References: <20120612.133758.544594921302340818.mbj@tail-f.com><20120625.080251.522233675.mbj@tail-f.com><0E552CBA-788E-4E27-81CB-5F1053B96D20@nic.cz><20120625122849 Date: Tue, 26 Jun 2012 11:49:45 +0100 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.5] X-OriginatorOrg: btconnect.com Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 10:55:52 -0000 ---- Original Message ----- From: "Ladislav Lhotka" To: "Juergen Schoenwaelder" Cc: Sent: Monday, June 25, 2012 3:51 PM > > On Jun 25, 2012, at 2:28 PM, Juergen Schoenwaelder wrote: > > > On Mon, Jun 25, 2012 at 11:45:50AM +0200, Ladislav Lhotka wrote: > >> > >>>> They are specified in said RFC: > >>>> > >>>> 1. neighbor cache > >>>> 2. destination cache > >>>> 3. prefix list > >>>> 4. default router list > >>>> > >>>> The latter two are in the routing module but the former two aren't. > >>> > >>> But RFC 4861 specifies these as data structures per interface. So > >> > >> Right, although it seems strange. In the implementations I am aware of, the data structures for 1, 2 and 4 (routing table, forwarding table, routing cache) are global. Only "prefix list" is clearly per-interface. > >> > > > > Junos seems to configure arp entries on an interface. Both, Cisco and > > Linus seem to have an interface (sometimes called device) as a > > mandatory argument. While the kernel may just have one table, I think > > it is safe to follow RFC 4861, no? > > I think it is generally useful to be able to see the entire ARP table without being forced to iterate over all interfaces, but also have options to filter the data, e.g. to view the entries for a selected interface. View yes, but that is a function of the viewing software. The routers I am familiar with have a table per interface, and may well have the same IP address on two different interfaces with different L2 addresses, so in a combined view, I expect the table to include a column for the interface, and it does. Of course, the underlying implementation may be a single table with a column for the interface as well, but however it is achieved, I see interface as a part of the table entry. Tom Petch > > This way we can satisfy 4861 requirements, too, because we keep the necessary information for each interface even though the underlying data structure is global. > > 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 andy@yumaworks.com Tue Jun 26 08:28:05 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC4D21F855B for ; Tue, 26 Jun 2012 08:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrXNtp2Ochqo for ; Tue, 26 Jun 2012 08:28:04 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 363B721F85F3 for ; Tue, 26 Jun 2012 08:28:03 -0700 (PDT) Received: by bkty8 with SMTP id y8so35050bkt.31 for ; Tue, 26 Jun 2012 08:28:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=zbBdUmzqhvXKfugtMhs+IAOGlbAthePPWhy66dA3Pxg=; b=l2RIbL3+1Znmh/BU3nE6//rFhqMeM0dPv/dFKTbQKMv/6j2XLAMViOEm/UpxHU027Z si199l9UT1r7FF4lCxXmU2KcLiGhTPmZkAJpOOisATXllVfOWdbf2WE2v2v3IJq/rX2g NwM7WzPSp5spxTKzH3x6iap21BGdcLHEb5owKBMv/dUyagJbL8Uvz6GId7WJ5ds2IaSc rBuZLHEGL22hjN1aNz2M5xGdiHV7L5oaaoIgO8HbS70vTyvh48IfifIJdNtt1p/Obwoy emHfLv1d3i7M0SsA10jCK78lN2KPfM6Yz1Sc+tljTC5lYOo5VQVNEFNA9qozXbV50iCG xRWw== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr16463536lab.47.1340724482605; Tue, 26 Jun 2012 08:28:02 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Tue, 26 Jun 2012 08:28:02 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120623.163717.383201565.mbj@tail-f.com> References: <20120622152230.GA85847@elstar.local> <20120623.163717.383201565.mbj@tail-f.com> Date: Tue, 26 Jun 2012 08:28:02 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=f46d0435c1d28703df04c361be6f X-Gm-Message-State: ALoCoQntsetoFM4tLGGJcwrnZqfz0RvaxEU4urodT9KLjzEWuP8FsAmdXUK6H7xEF4zrvgicc7FX Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:28:05 -0000 --f46d0435c1d28703df04c361be6f Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 23, 2012 at 7:37 AM, Martin Bjorklund wrote: > "Lange, Jeffrey K (GE Energy)" wrote: > > > > > > > > > > >why is this leaf so hard to support? > > > > > > > > Because by allowing someone to specify a UTC offset, you are losing > > > > the ability to take advantage of setting the timezone via the > tzdatabase > > > > which means that if you have no way of automatically adjusting for > > > > daylight savings time. Sure you could 'guess' the timezone based on > the > > > > UTC offset, but that is hardly an exact method. > > > > > > If someone configures lets say UTC offset +1, he likely wants exactly > that > > > and does not want any daylight savings time changes. > > > > I can buy that, but perhaps there should be some description text > stating that > > if the device supports automatic DST adjustment, setting the timezone > via the > > utc-offset will prevent DST adjustments. > > This is reasonable. I think we should make this clarification. > > Does this clarification mean the server MUST disable automatic DST adjustment if the timezone-utc-offset leaf exists? That seems to be implied by the YANG choice (timezone-location is deleted if timezone-utc-offset is set.) I will add a clarification in the description-stmt anyway. Andy > > > > I don't want to have to write a whole bunch of utility code just to > > > > get the current time when all the standard system APIs know how to > use > > > > /etc/localtime > > > > > > > > > I do not think you have to write lots of complicated code. > > So... do you think that this is still an issue, or would the > clarification above be enough? > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --f46d0435c1d28703df04c361be6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jun 23, 2012 at 7:37 AM, Martin = Bjorklund <mbj@tail-f.com> wrote:
"Lange, Jeffrey K (GE Energy)" <jeffrey.K.lange@ge.com> wrote:
>
> > >
> > > >why is this leaf so hard to support?
> > >
> > > Because by allowing someone to specify a UTC offset, you are= losing
> > > the=A0ability to take advantage of setting the timezone via = the tzdatabase
> > > which means that if you have no way of automatically adjusti= ng for
> > > daylight savings time. =A0Sure you could 'guess' the= timezone based on the
> > > UTC offset, but that is hardly an exact method.
> >
> > If someone configures lets say UTC offset +1, he likely wants exa= ctly that
> > and does not want any daylight savings time changes.
>
> I can buy that, but perhaps there should be some description text stat= ing that
> if the device supports automatic DST adjustment, setting the timezone = via the
> utc-offset will prevent DST adjustments.

This is reasonable. =A0I think we should make this clarification.


Does this clarification mean the serve= r MUST disable automatic DST adjustment
if the timezone-utc-offse= t leaf exists? =A0 =A0That seems to be implied by
the YANG choice= (timezone-location is deleted if timezone-utc-offset is set.)
I will add a clarification in the description-stmt anyway.
<= br>

Andy


= =A0
> > > I don't want to have to write a whole bunch of utility c= ode just to
> > > get the current time when all the standard system APIs know = how to use
> > > /etc/localtime
> >
> >
> > I do not think you have to write lots of complicated code.

So... do you think that this is still an issue, or would the
clarification above be enough?


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

--f46d0435c1d28703df04c361be6f-- From andy@yumaworks.com Tue Jun 26 08:41:39 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284A721F8609 for ; Tue, 26 Jun 2012 08:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF0+FLGF36r8 for ; Tue, 26 Jun 2012 08:41:38 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6EF121F85AF for ; Tue, 26 Jun 2012 08:41:37 -0700 (PDT) Received: by eaaq13 with SMTP id q13so32147eaa.31 for ; Tue, 26 Jun 2012 08:41:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ECfqtCLw4S1lKo7/yshzlH+t23DipeC9AMcgUGjptm0=; b=ZUVCxMqEHGYg/ccjIAWHcqVHJ+P/yIg8sc9Okui3mXGHJkJOL53ylZX0M2UKJVpGx5 FAGH6CpavgzZVNM2g1x5q3LGpmxlKDq8CjtFthl/L2qpn9I1LpMsB7RB2JiHDDPBSzls O+MTgXLLFW7fmrQT/+ETtjT1/ifZTHM72CM9Olv26wQidpx4jnkgjigAtRepmVnhkpk8 f+qU6lR7I+kPXTord96WI3ls4mhQN9ZI77gWrhPh7XzfvzBRzKfDkBui9zRpHc/+GVzi jdzQFlhTcoML17XvkwyTWWygp94wfHGqHagD5CVs9gcEpRSsi4gOZpmmeHdqp4W6GXVi LwtA== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr16509132lab.47.1340725296797; Tue, 26 Jun 2012 08:41:36 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Tue, 26 Jun 2012 08:41:36 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <4F75B7AC.2070206@tail-f.com> References: <6DD5C845-4B7E-4C12-8587-79A27DF9212E@gmail.com> <4F75B7AC.2070206@tail-f.com> Date: Tue, 26 Jun 2012 08:41:36 -0700 Message-ID: From: Andy Bierman To: Per Hedeland Content-Type: multipart/alternative; boundary=f46d0435c1d20e97f004c361efa0 X-Gm-Message-State: ALoCoQlWgtbJX67MGcHg0VnzBsOTUP4qTpESdpoGNr3Y3at+7oQS2NKFTx9WRI4gSbWSqZeDtWQB Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-system-mgmt NTP server issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:41:40 -0000 --f46d0435c1d20e97f004c361efa0 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Fri, Mar 30, 2012 at 6:39 AM, Per Hedeland wrote: > On 2012-03-27 14:23, Andrew McGregor wrote:.... > > Thus the tree should be something more like: > > > > +--rw system > > ... > > +--rw ntp > > +--rw use-ntp? boolean > > +--rw ntp-server [address] > > +--rw type ntp-association-type > > +--rw address inet:host > > +--rw enabled boolean > > +--rw iburst boolean > > +--rw prefer boolean > > +--rw true boolean > > > > where ntp-association-type is an enum with values 'server' 'peer' or > > 'pool' and the booleans iburst, noselect, prefer and true are as > > defined by the NTP reference implementation. > > I guess the question here is wether this should be a model for a generic > standard NTP client, or for the (so-called) reference implementation. > Personally I think the only reasonable choice is the former, among other > things there exists viable freely-available alternatives to the reference > implementation, and vendors can presumably augment the model with > proprietary knobs. > > I'm pretty sure that 'pool' and 'iburst', although useful and relevant > here, are not part of the NTP standard, and I don't believe 'prefer' is > either. The 'true' as a configuration option is unknown to me even for > the reference implementation, but I may be missing it in the plethora of > options. Traditionally the reference implementation uses "magic" > 127.127.x.x addresses to indicate a reference clock. In any case I doubt > that it is meaningful for this model to cover the configuration of > reference clocks. > > The concept of 'server' and 'peer' association modes are part of the > standard, and may be useful to be able to configure, the alternative > being to have 'server' be implicit. I'm not sure that 'peer' has more > merit than the possibility to configure broadcast/multicast client > modes, though. > > Another viewpoint is that the model should also - or maybe instead - > cover the configuration of a SNTP client, which may well be the only > thing that many devices have. As far as the standard is concerned, a > SNTP client has a single server - i.e. the obviously desirable > possibility to have multiple servers for redundancy, and the manner in > which they are selected/combined, is outside the standard. In this case > the ordered-by user prioritized list in the current draft may make > sense. > > I'm afraid I don't have good specific suggestions for alternate text at > this point, just wanted to give another opinion... > We need to decide what to do. The module current has the leafs described above. If the WG wants to expand the NTP support, then I am ready to punt the entire NTP configuration to the NTP WG, not NETMOD WG. If the WG wants to remove 'iburst', 'prefer', and/or 'true', and let other data models augment or replace this container in the ietf-system module, then that would be good to know. At this point I am leaving these 3 objects in the module, and not adding any new ones. > --Per Hedeland > Andy --f46d0435c1d20e97f004c361efa0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,


On Fri, Mar 30, 2012 at 6:39 AM,= Per Hedeland <per@tail-f.com> wrote:
On 2012-03-27 14:23, Andrew McGregor wrote:....
> Thus the tree should be something more like:
>
> +--rw system
> =A0 =A0 =A0 ...
> =A0 =A0 =A0 =A0 =A0+--rw ntp
> =A0 =A0 =A0 =A0 =A0 =A0 +--rw use-ntp? =A0 =A0 =A0boolean
> =A0 =A0 =A0 =A0 =A0 =A0 +--rw ntp-server [address]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw type =A0 =A0 =A0 ntp-association-= type
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw address =A0 =A0inet:host
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw enabled =A0 =A0boolean
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw iburst =A0 =A0 boolean
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw prefer =A0 =A0 boolean
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--rw true =A0 =A0 =A0 boolean
>
> where ntp-association-type is an enum with values 'server' = 9;peer' or
> 'pool' and the booleans iburst, noselect, prefer and true are = as
> defined by the NTP reference implementation.

I guess the question here is wether this should be a model for a generic standard NTP client, or for the (so-called) reference implementation.
Personally I think the only reasonable choice is the former, among other things there exists viable freely-available alternatives to the reference implementation, and vendors can presumably augment the model with
proprietary knobs.

I'm pretty sure that 'pool' and 'iburst', although usef= ul and relevant
here, are not part of the NTP standard, and I don't believe 'prefer= ' is
either. The 'true' as a configuration option is unknown to me even = for
the reference implementation, but I may be missing it in the plethora of options. Traditionally the reference implementation uses "magic"<= br> 127.127.x.x addresses to indicate a reference clock. In any case I doubt that it is meaningful for this model to cover the configuration of
reference clocks.

The concept of 'server' and 'peer' association modes are pa= rt of the
standard, and may be useful to be able to configure, the alternative
being to have 'server' be implicit. I'm not sure that 'peer= ' has more
merit than the possibility to configure broadcast/multicast client
modes, though.

Another viewpoint is that the model should also - or maybe instead -
cover the configuration of a SNTP client, which may well be the only
thing that many devices have. As far as the standard is concerned, a
SNTP client has a single server - i.e. the obviously desirable
possibility to have multiple servers for redundancy, and the manner in
which they are selected/combined, is outside the standard. In this case
the ordered-by user prioritized list in the current draft may make
sense.

I'm afraid I don't have good specific suggestions for alternate tex= t at
this point, just wanted to give another opinion...
We need to decide what to do.
The module current has = the leafs described above.
If the WG wants to expand the NTP supp= ort, then I am ready
to punt the entire NTP configuration to the NTP WG, not NETMOD WG.
If the WG wants to remove 'iburst', 'prefer', and/or= 'true', and let other
data models augment or replace thi= s container in the ietf-system module,
then that would be good to know.

At this poin= t I am leaving these 3 objects in the module, and not
adding any = new ones.



--Per Hedeland

Andy
=

--f46d0435c1d20e97f004c361efa0-- From jeffrey.K.lange@ge.com Tue Jun 26 08:44:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D9221F861C for ; Tue, 26 Jun 2012 08:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.087 X-Spam-Level: X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7dv3kaQ3ghG for ; Tue, 26 Jun 2012 08:44:30 -0700 (PDT) Received: from exprod5og112.obsmtp.com (exprod5og112.obsmtp.com [64.18.0.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC0C21F84FE for ; Tue, 26 Jun 2012 08:44:25 -0700 (PDT) Received: from cinmlip10.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob112.postini.com ([64.18.4.12]) with SMTP ID DSNKT+nY2AEctMpBH/SUxdDwRrZ/PvSDFbNd@postini.com; Tue, 26 Jun 2012 08:44:25 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by cinmlip10.e2k.ad.ge.com with ESMTP; 26 Jun 2012 11:41:21 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jun 2012 11:41:21 -0400 Received: from CINMBCNA06.e2k.ad.ge.com (3.159.212.61) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 26 Jun 2012 11:41:21 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA06.e2k.ad.ge.com ([169.254.6.116]) with mapi id 14.02.0283.003; Tue, 26 Jun 2012 11:41:20 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Andy Bierman , Martin Bjorklund Thread-Topic: [netmod] ietf-system: timezone-utc-offset Thread-Index: Ac1QdKsNKID7x3/NQD+98jr20yH9FQAMupYAAAgjSbD//8h2AIAAQAiggAFFqoCABMUtAIAAP/hA Date: Tue, 26 Jun 2012 15:41:19 +0000 Message-ID: References: <20120622152230.GA85847@elstar.local> <20120623.163717.383201565.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA67BECINMBCNA02e2kad_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jun 2012 15:41:21.0603 (UTC) FILETIME=[22C1E930:01CD53B2] Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 15:44:31 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA67BECINMBCNA02e2kad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >Does this clarification mean the server MUST disable automatic DST adjustm= ent >if the timezone-utc-offset leaf exists? That seems to be implied by >the YANG choice (timezone-location is deleted if timezone-utc-offset is se= t.) >I will add a clarification in the description-stmt anyway. That is how I would interpret this. -Jeff --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA67BECINMBCNA02e2kad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>Does this c= larification mean the server MUST disable automatic DST adjustment

>if the time= zone-utc-offset leaf exists?    That seems to be implied by<= /o:p>

>the YANG ch= oice (timezone-location is deleted if timezone-utc-offset is set.)

>I will add = a clarification in the description-stmt anyway.

 

That is how I would inter= pret this.

 <= /p>

-Jeff

 <= /p>

--_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA67BECINMBCNA02e2kad_-- From mbj@tail-f.com Tue Jun 26 12:24:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF17111E80CB for ; Tue, 26 Jun 2012 12:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR7HhODCGN5q for ; Tue, 26 Jun 2012 12:24:42 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE7811E809F for ; Tue, 26 Jun 2012 12:24:42 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 2457612008BC; Tue, 26 Jun 2012 21:24:40 +0200 (CEST) Date: Tue, 26 Jun 2012 21:24:39 +0200 (CEST) Message-Id: <20120626.212439.458795946.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120610134853.GC60379@elstar.local> References: <20120610134853.GC60379@elstar.local> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 19:24:42 -0000 Hi, Juergen Schoenwaelder wrote: > a) p1: I am wondering whether the title is correct. The document > really is concerned with the configuration of IP interfaces as far > as I understand it. It does not do routing and it also leaves out > configuration things such as reassembly timers, default TTLs, etc. > So would a more accurate title be "A Yang Data Model for IP > Interface Configuration"? And if so, should the module name become > ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? Going back to this one - should we explicitly limit the scope of this to IP interface config (and thus rename the module and document), or is it ok as it is? Personally I think the current title is fine; if we want to add more (non-interface specific) stuff in the future we would revise this document. But I can also live with the more limited scope and title. So what do others think? /martin From jeffrey.K.lange@ge.com Tue Jun 26 13:02:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8784A21F84C8 for ; Tue, 26 Jun 2012 13:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toD4NWAHRmFh for ; Tue, 26 Jun 2012 13:02:07 -0700 (PDT) Received: from exprod5og112.obsmtp.com (exprod5og112.obsmtp.com [64.18.0.24]) by ietfa.amsl.com (Postfix) with ESMTP id 175DF21F844D for ; Tue, 26 Jun 2012 13:02:06 -0700 (PDT) Received: from cinmlip10.e2k.ad.ge.com ([12.71.149.1]) (using TLSv1) by exprod5ob112.postini.com ([64.18.4.12]) with SMTP ID DSNKT+oVORHCLF9/OTCpTPNe/zgOgiZ92fql@postini.com; Tue, 26 Jun 2012 13:02:07 PDT Received: from unknown (HELO cinmlef12.e2k.ad.ge.com) ([3.159.213.59]) by cinmlip10.e2k.ad.ge.com with ESMTP; 26 Jun 2012 16:01:55 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef12.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jun 2012 16:01:55 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jun 2012 16:01:54 -0400 Received: from CINMBCNA05.e2k.ad.ge.com (3.159.212.59) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 26 Jun 2012 16:01:53 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA05.e2k.ad.ge.com ([169.254.5.129]) with mapi id 14.02.0283.003; Tue, 26 Jun 2012 16:01:53 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Andy Bierman , Martin Bjorklund Thread-Topic: [netmod] ietf-system: timezone-utc-offset Thread-Index: Ac1QdKsNKID7x3/NQD+98jr20yH9FQAMupYAAAgjSbD//8h2AIAAQAiggAFFqoCABMUtAIAAP/hAgAA4VFA= Date: Tue, 26 Jun 2012 20:01:53 +0000 Message-ID: References: <20120622152230.GA85847@elstar.local> <20120623.163717.383201565.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jun 2012 20:01:54.0461 (UTC) FILETIME=[88AABCD0:01CD53D6] Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 20:02:08 -0000 Not to beat a dead horse or anything but... =3D) The ietf-system module defines an enumeration for each of the timezone-name= values. Why is the timezone-location not also an enumeration? I think th= is would greatly increase the usability as far as the end user is concerned= . I would propose that just like there is an iana-if-type model, there should= be an iana-timezone model seeing as the list is controlled by iana (http:= //www.iana.org/time-zones) I would be willing to assemble this file if this is acceptable. Thanks, -Jeff From andy@yumaworks.com Tue Jun 26 14:39:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F4F21F85C0 for ; Tue, 26 Jun 2012 14:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BxpxpyBQyZ0 for ; Tue, 26 Jun 2012 14:39:26 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C7BDC21F85BD for ; Tue, 26 Jun 2012 14:39:25 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so665349lbb.31 for ; Tue, 26 Jun 2012 14:39:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZKqqAobWFaNC+FWHHMzrwKmL94CUmMSohRyol0SRY9k=; b=HlV47seA8r1o/SVDzf0jmCmM4NVk9PwUrKYdXlF5zEDCcHH1ya3UoHd8d4V3khTx8W Hfu1Kg7dI7bWbQ0cWvmqsKvoT3pdy/PPN0F2oVKk1z5dffGv9yalG+CZgdRiKy9+7tuP EA2P9tl37a3KwirUXD25o2jPys1ep9czHER7dBfmZtQFI0ei4NA3PQFBFNNATMycOR/5 eZ8/DZbf2hoA1e2ukfjefflsYOsWPRx/bBuJCTUljoySKdtY2dh0hF8Ba404XvrUu8r8 3DUF70ZEJBXUbz7LQ8xfe9S1ba5shNopNXXopwcEvtrwd4t5EG7tZVkvKTkTGo7bnE1h TOWA== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr17673323lab.47.1340746764597; Tue, 26 Jun 2012 14:39:24 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Tue, 26 Jun 2012 14:39:24 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <20120622152230.GA85847@elstar.local> <20120623.163717.383201565.mbj@tail-f.com> Date: Tue, 26 Jun 2012 14:39:24 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy)" Content-Type: multipart/alternative; boundary=f46d0435c1d2a3390404c366ee67 X-Gm-Message-State: ALoCoQkYAlceYo5XOuBcRw0Vo6sSpNcdimuEwUwPqkucQ2L8NfdVS4Mz/3LVwfnf25vXIBK5vY3G Cc: "netmod@ietf.org" Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 21:39:26 -0000 --f46d0435c1d2a3390404c366ee67 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 26, 2012 at 1:01 PM, Lange, Jeffrey K (GE Energy) < jeffrey.K.lange@ge.com> wrote: > Not to beat a dead horse or anything but... =) > > The ietf-system module defines an enumeration for each of the > timezone-name values. Why is the timezone-location not also an > enumeration? I think this would greatly increase the usability as far as > the end user is concerned. > > timezone-name is being removed. It has duplicates and is unusable for an identifier. > I would propose that just like there is an iana-if-type model, there > should be an iana-timezone model seeing as the list is controlled by iana ( > http://www.iana.org/time-zones) > > I would be willing to assemble this file if this is acceptable. > OK with me. > > Thanks, > -Jeff > Andy --f46d0435c1d2a3390404c366ee67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 26, 2012 at 1:01 PM, Lange, = Jeffrey K (GE Energy) <jeffrey.K.lange@ge.com> wrote:
Not to beat a dead horse or anything but... =A0=3D)

The ietf-system module defines an enumeration for each of the timezone-name= values. =A0Why is the timezone-location not also an enumeration? =A0I thin= k this would greatly increase the usability as far as the end user is conce= rned.



timezone-name is being = removed.
It has duplicates and is unusable for =A0an identifier.<= /div>
=A0
I would propose that just like there is an iana-if-type model, there should= be an iana-timezone model =A0seeing as the list is controlled by iana (http://www.iana.o= rg/time-zones)

I would be willing to assemble this file if this is acceptable.

OK with me.

=A0

Thanks,
-Jeff

Andy
=A0
--f46d0435c1d2a3390404c366ee67-- From j.schoenwaelder@jacobs-university.de Wed Jun 27 01:17:42 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6605821F8643 for ; Wed, 27 Jun 2012 01:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VUuWoyYCI6F for ; Wed, 27 Jun 2012 01:17:40 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 40CC121F85D3 for ; Wed, 27 Jun 2012 01:17:39 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 843CB20BDB; Wed, 27 Jun 2012 10:17:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Qlznz0KMIY4r; Wed, 27 Jun 2012 10:17:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1169620BDA; Wed, 27 Jun 2012 10:17:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D9408202B8D6; Wed, 27 Jun 2012 10:17:36 +0200 (CEST) Date: Wed, 27 Jun 2012 10:17:36 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120627081736.GB47893@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120610134853.GC60379@elstar.local> <20120626.212439.458795946.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120626.212439.458795946.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 08:17:43 -0000 On Tue, Jun 26, 2012 at 09:24:39PM +0200, Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: > > a) p1: I am wondering whether the title is correct. The document > > really is concerned with the configuration of IP interfaces as far > > as I understand it. It does not do routing and it also leaves out > > configuration things such as reassembly timers, default TTLs, etc. > > So would a more accurate title be "A Yang Data Model for IP > > Interface Configuration"? And if so, should the module name become > > ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? > > Going back to this one - should we explicitly limit the scope of this > to IP interface config (and thus rename the module and document), or > is it ok as it is? Personally I think the current title is fine; if > we want to add more (non-interface specific) stuff in the future we > would revise this document. But I can also live with the more limited > scope and title. So what do others think? It might be a reasonable plan to call the module ietf-ip with the understanding that we likely will have to add stuff to it that we leave out in the first revision. But if that is the plan, it might be worth spelling it out for instance in the Introduction, e.g. by stating that the first revision of this data model focusses on IP interface configuration and that it is expected to future revisions will add more knobs to configure IP. It might also be useful to spell out in the Introduction that IP routing related configuration objects are defined in the routing data model. Having some more text in the introduction likely helps to set the expectations right. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Jun 27 02:11:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5895921F864C for ; Wed, 27 Jun 2012 02:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ElVX1P434ad for ; Wed, 27 Jun 2012 02:11:19 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDCE21F864B for ; Wed, 27 Jun 2012 02:11:19 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 467C520C1A; Wed, 27 Jun 2012 11:11:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pM11yU3E8rXD; Wed, 27 Jun 2012 11:11:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3EF720BFD; Wed, 27 Jun 2012 11:11:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C236F202BC5E; Wed, 27 Jun 2012 11:11:16 +0200 (CEST) Date: Wed, 27 Jun 2012 11:11:16 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120627091116.GA48378@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120610134853.GC60379@elstar.local> <20120612.125452.1645516036024914306.mbj@tail-f.com> <20120612111428.GD70760@elstar.local> <20120625.083036.514882828.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120625.083036.514882828.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 09:11:24 -0000 On Mon, Jun 25, 2012 at 08:30:36AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Jun 12, 2012 at 12:54:52PM +0200, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my > > > > comments/questions. > > [...] > > > > > d) p5: > > > > > > > > The objects ipNetToPhysicalTable and ipAddressStatus are writable in > > > > the IP-MIB but do not represent configuration, and are thus not > > > > mapped to the YANG module. > > > > > > > > This seems odd. Static address mappings can typically be configured > > > > and some people do this (either for security or performance > > > > reasons). As far as I understand things in the Linux world, address > > > > mappings seem to be interface specific. > > > > > > For some discussion/questions, see > > > http://www.ietf.org/mail-archive/web/netmod/current/msg06514.html. > > > > > > ipNetToPhysicalTable says: > > > > > > As the entries in this table are typically not persistent > > > when this object is written the entity SHOULD NOT save the > > > change to non-volatile storage. > > > > > > which is why I did not include this. > > > > Well, that might be true for the MIB. I happen to run boxes that have > > static mappings and I happen to run boxes that do proxyarp stuff. I am > > not saying this has to be included or not > > Ok. So let's ask the question: Do you think we should include > configuration parameters for this? If so, do you have a suggestion > for the data model? It is not clear what the WG things about it since only a few people commented. More input would help. > > > > f) p10: If I do not what autoconf address at all, I have to set all > > > > create-* leaves to false? Should there be a global switch? Not > > > > sure, just asking... > > > > > > I think we discussed this but can't find any notes. So, should there > > > be an option to disable stateless autoconfiguration on an ipv6-enabled > > > interface? > > > > I guess someone needs to check what the IPv6 specs really say about > > this. I have boxes that have static IPv6 addresses configured and I > > would prefer them to ignore any wired RAs on those links. > > Actually, since create-temporary-addresses is false by default, there > is really just one leaf you have to set to false. So adding another > leaf to control this leaf is probably overkill. OK, consider this closed. > > > > g) p13: Should there be text discussing ipv4/forwarding and > > > > ipv6/forwarding? Or the impact of the autoconf knobs? > > > > > > RFC 4293 has text for ipForwarding and ipv6IpForwarding, so we should > > > probably have something similar. What would the security impact be > > > for the autoconf parameters? > > > > The reason we use statically configured IPv4 and IPv6 addresses on our > > servers is to improve their robustness. We considered moving to static > > address mappings as well but did not go there (yet). If you use > > autoconfig, then you have to trust something and whether that trust is > > justified is something to consider. > > I will need help with this. Could you suggest a paragraph to add? Here is a first attempt to provide constructive input: ipv4/forwarding and ipv6/forwarding: These nodes control whether IP packets are forwarded on this interface. By disabling or enabling forwarding on a interface, an attacker might impact network connectivity. ipv6/autoconf: The leafs in this branch control the autoconfiguration of IPv6 addresses and in particular whether temporary addresses are used or not. By modifying the corresponding leafs, an attacker might impact the addresses used by a node and thus the indirectly the privacy of the users using the node. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Jun 27 03:25:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D4421F8661 for ; Wed, 27 Jun 2012 03:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlbvLWqFD10D for ; Wed, 27 Jun 2012 03:25:18 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 64D3D21F864B for ; Wed, 27 Jun 2012 03:25:17 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B2E2212008BC; Wed, 27 Jun 2012 12:25:14 +0200 (CEST) Date: Wed, 27 Jun 2012 12:25:14 +0200 (CEST) Message-Id: <20120627.122514.857075493543911307.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120627081736.GB47893@elstar.local> References: <20120610134853.GC60379@elstar.local> <20120626.212439.458795946.mbj@tail-f.com> <20120627081736.GB47893@elstar.local> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:25:18 -0000 Juergen Schoenwaelder wrote: > On Tue, Jun 26, 2012 at 09:24:39PM +0200, Martin Bjorklund wrote: > > Hi, > > > > Juergen Schoenwaelder wrote: > > > a) p1: I am wondering whether the title is correct. The document > > > really is concerned with the configuration of IP interfaces as far > > > as I understand it. It does not do routing and it also leaves out > > > configuration things such as reassembly timers, default TTLs, etc. > > > So would a more accurate title be "A Yang Data Model for IP > > > Interface Configuration"? And if so, should the module name become > > > ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip? > > > > Going back to this one - should we explicitly limit the scope of this > > to IP interface config (and thus rename the module and document), or > > is it ok as it is? Personally I think the current title is fine; if > > we want to add more (non-interface specific) stuff in the future we > > would revise this document. But I can also live with the more limited > > scope and title. So what do others think? > > It might be a reasonable plan to call the module ietf-ip with the > understanding that we likely will have to add stuff to it that we > leave out in the first revision. But if that is the plan, it might be > worth spelling it out for instance in the Introduction, e.g. by > stating that the first revision of this data model focusses on IP > interface configuration and that it is expected to future revisions > will add more knobs to configure IP. It might also be useful to spell > out in the Introduction that IP routing related configuration objects > are defined in the routing data model. Having some more text in the > introduction likely helps to set the expectations right. Ok, I expanded the Introduction by 300%! This is the new text: This document defines a YANG ^RFC6020^ data model for configuration of IP implementations. The initial version of this data model focuses on configuration parameters for interfaces. It is expected that future revisions of this data model might add other kinds of IP configuration parameters. Configuration parameters to control IP routing are defined in ^I-D.ietf-netmod-routing-cfg^. /martin From j.schoenwaelder@jacobs-university.de Wed Jun 27 03:50:52 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8ECC21F86C7 for ; Wed, 27 Jun 2012 03:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.211 X-Spam-Level: X-Spam-Status: No, score=-103.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiDsZl8aVnWC for ; Wed, 27 Jun 2012 03:50:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 02D0D21F866B for ; Wed, 27 Jun 2012 03:50:52 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 509C820C15; Wed, 27 Jun 2012 12:50:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WEwVnrpX03Fr; Wed, 27 Jun 2012 12:50:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D92DE20BFE; Wed, 27 Jun 2012 12:50:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C3A78202C21B; Wed, 27 Jun 2012 12:50:50 +0200 (CEST) Date: Wed, 27 Jun 2012 12:50:50 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120627105050.GB49359@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20120610134853.GC60379@elstar.local> <20120626.212439.458795946.mbj@tail-f.com> <20120627081736.GB47893@elstar.local> <20120627.122514.857075493543911307.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120627.122514.857075493543911307.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 10:50:52 -0000 On Wed, Jun 27, 2012 at 12:25:14PM +0200, Martin Bjorklund wrote: > Ok, I expanded the Introduction by 300%! This is the new text: [...] > The initial version of this data model focuses on configuration > parameters for interfaces. It is expected that future revisions of > this data model might add other kinds of IP configuration parameters. I would remove the might here. The phrase "is expected" already makes this conditional. Or even shorter (but reducing your expansion score a bit): Future revisions of this data model might add other kinds of IP configuration parameters. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Wed Jun 27 04:05:32 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3292F21F8694 for ; Wed, 27 Jun 2012 04:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.791 X-Spam-Level: X-Spam-Status: No, score=-3.791 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMQzMZ7OqwWI for ; Wed, 27 Jun 2012 04:05:31 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 0591B21F8697 for ; Wed, 27 Jun 2012 04:05:22 -0700 (PDT) Received: from mail195-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Jun 2012 11:03:38 +0000 Received: from mail195-co1 (localhost [127.0.0.1]) by mail195-co1-R.bigfish.com (Postfix) with ESMTP id 557838C0070; Wed, 27 Jun 2012 11:03:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT008.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail195-co1 (localhost.localdomain [127.0.0.1]) by mail195-co1 (MessageSwitch) id 1340795014865696_32130; Wed, 27 Jun 2012 11:03:34 +0000 (UTC) Received: from CO1EHSMHS029.bigfish.com (unknown [10.243.78.245]) by mail195-co1.bigfish.com (Postfix) with ESMTP id C7EE160044; Wed, 27 Jun 2012 11:03:34 +0000 (UTC) Received: from DB3PRD0702HT008.eurprd07.prod.outlook.com (157.55.224.141) by CO1EHSMHS029.bigfish.com (10.243.66.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Jun 2012 11:03:34 +0000 Received: from AMSPRD0410HT001.eurprd04.prod.outlook.com (157.56.248.37) by pod51017.outlook.com (10.3.4.173) with Microsoft SMTP Server (TLS) id 14.15.86.1; Wed, 27 Jun 2012 11:05:14 +0000 Message-ID: <017c01cd5454$3bbde860$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Martin Bjorklund References: <20120622152230.GA85847@elstar.local><20120623.163717.383201565.mbj@tail-f.com> Date: Wed, 27 Jun 2012 12:00:00 +0100 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.37] X-OriginatorOrg: btconnect.com Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 11:05:32 -0000 ----- Original Message ----- From: "Andy Bierman" To: "Martin Bjorklund" Cc: Sent: Tuesday, June 26, 2012 4:28 PM > On Sat, Jun 23, 2012 at 7:37 AM, Martin Bjorklund wrote: > > > "Lange, Jeffrey K (GE Energy)" wrote: > > > > > > > > > > > > > >why is this leaf so hard to support? > > > > > > > > > > Because by allowing someone to specify a UTC offset, you are losing > > > > > the ability to take advantage of setting the timezone via the > > tzdatabase > > > > > which means that if you have no way of automatically adjusting for > > > > > daylight savings time. Sure you could 'guess' the timezone based on > > the > > > > > UTC offset, but that is hardly an exact method. > > > > > > > > If someone configures lets say UTC offset +1, he likely wants exactly > > that > > > > and does not want any daylight savings time changes. > > > > > > I can buy that, but perhaps there should be some description text > > stating that > > > if the device supports automatic DST adjustment, setting the timezone > > via the > > > utc-offset will prevent DST adjustments. > > > > This is reasonable. I think we should make this clarification. > > > > > Does this clarification mean the server MUST disable automatic DST > adjustment > if the timezone-utc-offset leaf exists? That seems to be implied by > the YANG choice (timezone-location is deleted if timezone-utc-offset is > set.) > I will add a clarification in the description-stmt anyway. It is still not very user-riendly. When I configure a Windows PC, probably the commonest device on the planet, I have a drop-down which allows me to choose between GMT-12 through to GMT+12 wth a textual name for each which is not the same as the string that you use. The locale for this is UK, I cannot remember what I got when last I configured a PC in North America, but think that this is the sort of identifier that the real world uses. And yes, there is also a tick box for "Automatically adjust clock for daylight saving changes" so this is what we should offer. (My mobile phone does not adjust for daylight saving, I have to do it manually). Tom Petch > Andy > > > > > > > > > I don't want to have to write a whole bunch of utility code just to > > > > > get the current time when all the standard system APIs know how to > > use > > > > > /etc/localtime > > > > > > > > > > > > I do not think you have to write lots of complicated code. > > > > So... do you think that this is still an issue, or would the > > clarification above be enough? > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From j.schoenwaelder@jacobs-university.de Wed Jun 27 05:00:47 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0201321F8610 for ; Wed, 27 Jun 2012 05:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxMfCcafMFjc for ; Wed, 27 Jun 2012 05:00:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5231E21F85F0 for ; Wed, 27 Jun 2012 05:00:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AF4020C39; Wed, 27 Jun 2012 14:00:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ScILsjHqiTNb; Wed, 27 Jun 2012 14:00:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1CA420C0F; Wed, 27 Jun 2012 14:00:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B00D2202C50F; Wed, 27 Jun 2012 14:00:44 +0200 (CEST) Date: Wed, 27 Jun 2012 14:00:44 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20120627120044.GE49359@elstar.local> Mail-Followup-To: "t.petch" , Andy Bierman , Martin Bjorklund , netmod@ietf.org References: <20120622152230.GA85847@elstar.local> <20120623.163717.383201565.mbj@tail-f.com> <017c01cd5454$3bbde860$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <017c01cd5454$3bbde860$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 12:00:47 -0000 On Wed, Jun 27, 2012 at 12:00:00PM +0100, t.petch wrote: > And yes, there is also a tick box for > "Automatically adjust clock for daylight saving changes" > so this is what we should offer. There is not DST regulation that applies to a fixed UTC offset. DST regulations are country/region specific. Hence, selection GMT+x and selecting adjust clock for daylight saving changes is only something Windows knows how to do. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jeffrey.K.lange@ge.com Wed Jun 27 06:22:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E3521F85FD for ; Wed, 27 Jun 2012 06:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.658 X-Spam-Level: X-Spam-Status: No, score=-4.658 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_50=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSBii6vwu9GR for ; Wed, 27 Jun 2012 06:22:31 -0700 (PDT) Received: from exprod5og105.obsmtp.com (exprod5og105.obsmtp.com [64.18.0.180]) by ietfa.amsl.com (Postfix) with ESMTP id A197721F85CF for ; Wed, 27 Jun 2012 06:22:30 -0700 (PDT) Received: from alpmlip12.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob105.postini.com ([64.18.4.12]) with SMTP ID DSNKT+sJFofh2nfnaZAqYmv6EV9XfXJARa8j@postini.com; Wed, 27 Jun 2012 06:22:30 PDT Received: from unknown (HELO alpmlef01.e2k.ad.ge.com) ([3.159.18.10]) by alpmlip12.e2k.ad.ge.com with ESMTP; 27 Jun 2012 09:21:20 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by alpmlef01.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 09:21:20 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 09:21:18 -0400 Received: from CINMBCNA05.e2k.ad.ge.com (3.159.212.59) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 27 Jun 2012 09:21:18 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA05.e2k.ad.ge.com ([169.254.5.129]) with mapi id 14.02.0283.003; Wed, 27 Jun 2012 09:21:18 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: iana-timezones.yang proposal Thread-Index: Ac1UZ5zKdi90QqprQ+qLElq9kCvf9Q== Date: Wed, 27 Jun 2012 13:21:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2012 13:21:18.0894 (UTC) FILETIME=[BCC404E0:01CD5467] Subject: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 13:22:34 -0000 As I mentioned earlier, the current free-form timezone-location string in t= he ietf-system module is not very user friendly, and those timezone locatio= n strings are actually an IANA controlled entity. I have created an iana-t= imezones module using the timezones and any textual descriptions found in t= he zone.tab file found in the Time Zone Data v. 2012c downloaded from the i= ana website. This has resulted in an enumeration with 415 values. I have a= lso modified the ietf-system module to use this new data type. The data was extracted from the zone.tab file using the following cryptic c= ombination of grep, cat, sort, and awk :-) grep -h -v "^#" zone.tab |awk '{ printf ("%s ", $3); sep=3D""; for (i=3D4; = i<=3DNF; i++) {printf("%s%s",sep,$i); sep=3DOFS}; printf("\n");}' |sort -g = |cat -n |awk '{ printf(" enum \"%s\" {\n value %s;\n des= cription\n \"", $2, $1); sep=3D""; for (i=3D3; i<=3DNF; i++) {prin= tf("%s%s",sep,$i); sep=3DOFS}; print "\";\n }" }' I pretty much took the header info from the iana-if-type module verbatim, w= ith minor changes to reflect the fact that it is for timezones, so odds are= this would need to be adjusted to be in the correct format. Not every entry in the enumeration has a description, because not every ent= ry in the zone.tab file has a description. I'm not sure if this would be k= osher in an official release or not. Below is the changes needed for ietf-system: diff --git a/ietf-system@2012-01-31.yang b/ietf-system@2012-01-31.yang index dd26ea1..4e7952c 100644 --- a/ietf-system@2012-01-31.yang +++ b/ietf-system@2012-01-31.yang @@ -11,6 +11,9 @@ module ietf-system { import ietf-netconf-acm { prefix nacm; } + import iana-timezones { + prefix ianatz; + } =20 organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group= "; contact @@ -882,9 +885,9 @@ module ietf-system { "Configure the system timezone information."; leaf timezone-location { if-feature timezone-location; - type string; + type ianatz:iana-timezone; description - "The TZ database location identifier string + "The TZ database location enumeration to use for the system, such as 'Europe/Stockholm'."; } leaf timezone-name { And below is the full text of the iana-timezones.yang file I have created module iana-timezones { namespace "urn:ietf:params:xml:ns:yang:iana-timezones"; prefix ianatz; organization "IANA"; contact " Internet Assigned Numbers Authority =20 Postal: ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 =20 Tel: +1 310 823 9358 E-Mail: iana&iana.org"; description "This YANG module defines the iana-timezone typedef, which contains YANG definitions for IANA-registered timezones. =20 This YANG module is maintained by IANA, and reflects the IANA Time Zone Database. (http://www.iana.org/time-zones) =20 The latest revision of this YANG module can be obtained from the IANA web site. =20 Copyright (c) 2011 IETF Trust and the persons identified as authors of the code. All rights reserved. =20 Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). =20 This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2012-06-27 { description "Initial revision. Using IANA Time Zone Data v. 2012c (Released 2012-03-27)"; reference "RFC XXXX: TITLE"; } typedef iana-timezone { type enumeration { enum "Africa/Abidjan" { value 1; description ""; } enum "Africa/Accra" { value 2; description ""; } enum "Africa/Addis_Ababa" { value 3; description ""; } enum "Africa/Algiers" { value 4; description ""; } enum "Africa/Asmara" { value 5; description ""; } enum "Africa/Bamako" { value 6; description ""; } enum "Africa/Bangui" { value 7; description ""; } enum "Africa/Banjul" { value 8; description ""; } enum "Africa/Bissau" { value 9; description ""; } enum "Africa/Blantyre" { value 10; description ""; } enum "Africa/Brazzaville" { value 11; description ""; } enum "Africa/Bujumbura" { value 12; description ""; } enum "Africa/Cairo" { value 13; description ""; } enum "Africa/Casablanca" { value 14; description ""; } enum "Africa/Ceuta" { value 15; description "Ceuta & Melilla"; } enum "Africa/Conakry" { value 16; description ""; } enum "Africa/Dakar" { value 17; description ""; } enum "Africa/Dar_es_Salaam" { value 18; description ""; } enum "Africa/Djibouti" { value 19; description ""; } enum "Africa/Douala" { value 20; description ""; } enum "Africa/El_Aaiun" { value 21; description ""; } enum "Africa/Freetown" { value 22; description ""; } enum "Africa/Gaborone" { value 23; description ""; } enum "Africa/Harare" { value 24; description ""; } enum "Africa/Johannesburg" { value 25; description ""; } enum "Africa/Juba" { value 26; description ""; } enum "Africa/Kampala" { value 27; description ""; } enum "Africa/Khartoum" { value 28; description ""; } enum "Africa/Kigali" { value 29; description ""; } enum "Africa/Kinshasa" { value 30; description "west Dem. Rep. of Congo"; } enum "Africa/Lagos" { value 31; description ""; } enum "Africa/Libreville" { value 32; description ""; } enum "Africa/Lome" { value 33; description ""; } enum "Africa/Luanda" { value 34; description ""; } enum "Africa/Lubumbashi" { value 35; description "east Dem. Rep. of Congo"; } enum "Africa/Lusaka" { value 36; description ""; } enum "Africa/Malabo" { value 37; description ""; } enum "Africa/Maputo" { value 38; description ""; } enum "Africa/Maseru" { value 39; description ""; } enum "Africa/Mbabane" { value 40; description ""; } enum "Africa/Mogadishu" { value 41; description ""; } enum "Africa/Monrovia" { value 42; description ""; } enum "Africa/Nairobi" { value 43; description ""; } enum "Africa/Ndjamena" { value 44; description ""; } enum "Africa/Niamey" { value 45; description ""; } enum "Africa/Nouakchott" { value 46; description ""; } enum "Africa/Ouagadougou" { value 47; description ""; } enum "Africa/Porto-Novo" { value 48; description ""; } enum "Africa/Sao_Tome" { value 49; description ""; } enum "Africa/Tripoli" { value 50; description ""; } enum "Africa/Tunis" { value 51; description ""; } enum "Africa/Windhoek" { value 52; description ""; } enum "America/Adak" { value 53; description "Aleutian Islands"; } enum "America/Anchorage" { value 54; description "Alaska Time"; } enum "America/Anguilla" { value 55; description ""; } enum "America/Antigua" { value 56; description ""; } enum "America/Araguaina" { value 57; description "Tocantins"; } enum "America/Argentina/Buenos_Aires" { value 58; description "Buenos Aires (BA, CF)"; } enum "America/Argentina/Catamarca" { value 59; description "Catamarca (CT), Chubut (CH)"; } enum "America/Argentina/Cordoba" { value 60; description "most locations (CB, CC, CN, ER, FM, MN, SE, SF)"; } enum "America/Argentina/Jujuy" { value 61; description "Jujuy (JY)"; } enum "America/Argentina/La_Rioja" { value 62; description "La Rioja (LR)"; } enum "America/Argentina/Mendoza" { value 63; description "Mendoza (MZ)"; } enum "America/Argentina/Rio_Gallegos" { value 64; description "Santa Cruz (SC)"; } enum "America/Argentina/Salta" { value 65; description "(SA, LP, NQ, RN)"; } enum "America/Argentina/San_Juan" { value 66; description "San Juan (SJ)"; } enum "America/Argentina/San_Luis" { value 67; description "San Luis (SL)"; } enum "America/Argentina/Tucuman" { value 68; description "Tucuman (TM)"; } enum "America/Argentina/Ushuaia" { value 69; description "Tierra del Fuego (TF)"; } enum "America/Aruba" { value 70; description ""; } enum "America/Asuncion" { value 71; description ""; } enum "America/Atikokan" { value 72; description "Eastern Standard Time - Atikokan, Ontario and Southampton I, Nun= avut"; } enum "America/Bahia" { value 73; description "Bahia"; } enum "America/Bahia_Banderas" { value 74; description "Mexican Central Time - Bahia de Banderas"; } enum "America/Barbados" { value 75; description ""; } enum "America/Belem" { value 76; description "Amapa, E Para"; } enum "America/Belize" { value 77; description ""; } enum "America/Blanc-Sablon" { value 78; description "Atlantic Standard Time - Quebec - Lower North Shore"; } enum "America/Boa_Vista" { value 79; description "Roraima"; } enum "America/Bogota" { value 80; description ""; } enum "America/Boise" { value 81; description "Mountain Time - south Idaho & east Oregon"; } enum "America/Cambridge_Bay" { value 82; description "Mountain Time - west Nunavut"; } enum "America/Campo_Grande" { value 83; description "Mato Grosso do Sul"; } enum "America/Cancun" { value 84; description "Central Time - Quintana Roo"; } enum "America/Caracas" { value 85; description ""; } enum "America/Cayenne" { value 86; description ""; } enum "America/Cayman" { value 87; description ""; } enum "America/Chicago" { value 88; description "Central Time"; } enum "America/Chihuahua" { value 89; description "Mexican Mountain Time - Chihuahua away from US border"; } enum "America/Costa_Rica" { value 90; description ""; } enum "America/Creston" { value 91; description "Mountain Standard Time - Creston, British Columbia"; } enum "America/Cuiaba" { value 92; description "Mato Grosso"; } enum "America/Curacao" { value 93; description ""; } enum "America/Danmarkshavn" { value 94; description "east coast, north of Scoresbysund"; } enum "America/Dawson_Creek" { value 95; description "Mountain Standard Time - Dawson Creek & Fort Saint John, British= Columbia"; } enum "America/Dawson" { value 96; description "Pacific Time - north Yukon"; } enum "America/Denver" { value 97; description "Mountain Time"; } enum "America/Detroit" { value 98; description "Eastern Time - Michigan - most locations"; } enum "America/Dominica" { value 99; description ""; } enum "America/Edmonton" { value 100; description "Mountain Time - Alberta, east British Columbia & west Saskatchew= an"; } enum "America/Eirunepe" { value 101; description "W Amazonas"; } enum "America/El_Salvador" { value 102; description ""; } enum "America/Fortaleza" { value 103; description "NE Brazil (MA, PI, CE, RN, PB)"; } enum "America/Glace_Bay" { value 104; description "Atlantic Time - Nova Scotia - places that did not observe DST 19= 66-1971"; } enum "America/Godthab" { value 105; description "most locations"; } enum "America/Goose_Bay" { value 106; description "Atlantic Time - Labrador - most locations"; } enum "America/Grand_Turk" { value 107; description ""; } enum "America/Grenada" { value 108; description ""; } enum "America/Guadeloupe" { value 109; description ""; } enum "America/Guatemala" { value 110; description ""; } enum "America/Guayaquil" { value 111; description "mainland"; } enum "America/Guyana" { value 112; description ""; } enum "America/Halifax" { value 113; description "Atlantic Time - Nova Scotia (most places), PEI"; } enum "America/Havana" { value 114; description ""; } enum "America/Hermosillo" { value 115; description "Mountain Standard Time - Sonora"; } enum "America/Indiana/Indianapolis" { value 116; description "Eastern Time - Indiana - most locations"; } enum "America/Indiana/Knox" { value 117; description "Central Time - Indiana - Starke County"; } enum "America/Indiana/Marengo" { value 118; description "Eastern Time - Indiana - Crawford County"; } enum "America/Indiana/Petersburg" { value 119; description "Eastern Time - Indiana - Pike County"; } enum "America/Indiana/Tell_City" { value 120; description "Central Time - Indiana - Perry County"; } enum "America/Indiana/Vevay" { value 121; description "Eastern Time - Indiana - Switzerland County"; } enum "America/Indiana/Vincennes" { value 122; description "Eastern Time - Indiana - Daviess, Dubois, Knox & Martin Counties= "; } enum "America/Indiana/Winamac" { value 123; description "Eastern Time - Indiana - Pulaski County"; } enum "America/Inuvik" { value 124; description "Mountain Time - west Northwest Territories"; } enum "America/Iqaluit" { value 125; description "Eastern Time - east Nunavut - most locations"; } enum "America/Jamaica" { value 126; description ""; } enum "America/Juneau" { value 127; description "Alaska Time - Alaska panhandle"; } enum "America/Kentucky/Louisville" { value 128; description "Eastern Time - Kentucky - Louisville area"; } enum "America/Kentucky/Monticello" { value 129; description "Eastern Time - Kentucky - Wayne County"; } enum "America/Kralendijk" { value 130; description ""; } enum "America/La_Paz" { value 131; description ""; } enum "America/Lima" { value 132; description ""; } enum "America/Los_Angeles" { value 133; description "Pacific Time"; } enum "America/Lower_Princes" { value 134; description ""; } enum "America/Maceio" { value 135; description "Alagoas, Sergipe"; } enum "America/Managua" { value 136; description ""; } enum "America/Manaus" { value 137; description "E Amazonas"; } enum "America/Marigot" { value 138; description ""; } enum "America/Martinique" { value 139; description ""; } enum "America/Matamoros" { value 140; description "US Central Time - Coahuila, Durango, Nuevo Leon, Tamaulipas near= US border"; } enum "America/Mazatlan" { value 141; description "Mountain Time - S Baja, Nayarit, Sinaloa"; } enum "America/Menominee" { value 142; description "Central Time - Michigan - Dickinson, Gogebic, Iron & Menominee C= ounties"; } enum "America/Merida" { value 143; description "Central Time - Campeche, Yucatan"; } enum "America/Metlakatla" { value 144; description "Metlakatla Time - Annette Island"; } enum "America/Mexico_City" { value 145; description "Central Time - most locations"; } enum "America/Miquelon" { value 146; description ""; } enum "America/Moncton" { value 147; description "Atlantic Time - New Brunswick"; } enum "America/Monterrey" { value 148; description "Mexican Central Time - Coahuila, Durango, Nuevo Leon, Tamaulipas= away from US border"; } enum "America/Montevideo" { value 149; description ""; } enum "America/Montreal" { value 150; description "Eastern Time - Quebec - most locations"; } enum "America/Montserrat" { value 151; description ""; } enum "America/Nassau" { value 152; description ""; } enum "America/New_York" { value 153; description "Eastern Time"; } enum "America/Nipigon" { value 154; description "Eastern Time - Ontario & Quebec - places that did not observe DS= T 1967-1973"; } enum "America/Nome" { value 155; description "Alaska Time - west Alaska"; } enum "America/Noronha" { value 156; description "Atlantic islands"; } enum "America/North_Dakota/Beulah" { value 157; description "Central Time - North Dakota - Mercer County"; } enum "America/North_Dakota/Center" { value 158; description "Central Time - North Dakota - Oliver County"; } enum "America/North_Dakota/New_Salem" { value 159; description "Central Time - North Dakota - Morton County (except Mandan area)= "; } enum "America/Ojinaga" { value 160; description "US Mountain Time - Chihuahua near US border"; } enum "America/Panama" { value 161; description ""; } enum "America/Pangnirtung" { value 162; description "Eastern Time - Pangnirtung, Nunavut"; } enum "America/Paramaribo" { value 163; description ""; } enum "America/Phoenix" { value 164; description "Mountain Standard Time - Arizona"; } enum "America/Port-au-Prince" { value 165; description ""; } enum "America/Port_of_Spain" { value 166; description ""; } enum "America/Porto_Velho" { value 167; description "Rondonia"; } enum "America/Puerto_Rico" { value 168; description ""; } enum "America/Rainy_River" { value 169; description "Central Time - Rainy River & Fort Frances, Ontario"; } enum "America/Rankin_Inlet" { value 170; description "Central Time - central Nunavut"; } enum "America/Recife" { value 171; description "Pernambuco"; } enum "America/Regina" { value 172; description "Central Standard Time - Saskatchewan - most locations"; } enum "America/Resolute" { value 173; description "Central Standard Time - Resolute, Nunavut"; } enum "America/Rio_Branco" { value 174; description "Acre"; } enum "America/Santa_Isabel" { value 175; description "Mexican Pacific Time - Baja California away from US border"; } enum "America/Santarem" { value 176; description "W Para"; } enum "America/Santiago" { value 177; description "most locations"; } enum "America/Santo_Domingo" { value 178; description ""; } enum "America/Sao_Paulo" { value 179; description "S & SE Brazil (GO, DF, MG, ES, RJ, SP, PR, SC, RS)"; } enum "America/Scoresbysund" { value 180; description "Scoresbysund / Ittoqqortoormiit"; } enum "America/Shiprock" { value 181; description "Mountain Time - Navajo"; } enum "America/Sitka" { value 182; description "Alaska Time - southeast Alaska panhandle"; } enum "America/St_Barthelemy" { value 183; description ""; } enum "America/St_Johns" { value 184; description "Newfoundland Time, including SE Labrador"; } enum "America/St_Kitts" { value 185; description ""; } enum "America/St_Lucia" { value 186; description ""; } enum "America/St_Thomas" { value 187; description ""; } enum "America/St_Vincent" { value 188; description ""; } enum "America/Swift_Current" { value 189; description "Central Standard Time - Saskatchewan - midwest"; } enum "America/Tegucigalpa" { value 190; description ""; } enum "America/Thule" { value 191; description "Thule / Pituffik"; } enum "America/Thunder_Bay" { value 192; description "Eastern Time - Thunder Bay, Ontario"; } enum "America/Tijuana" { value 193; description "US Pacific Time - Baja California near US border"; } enum "America/Toronto" { value 194; description "Eastern Time - Ontario - most locations"; } enum "America/Tortola" { value 195; description ""; } enum "America/Vancouver" { value 196; description "Pacific Time - west British Columbia"; } enum "America/Whitehorse" { value 197; description "Pacific Time - south Yukon"; } enum "America/Winnipeg" { value 198; description "Central Time - Manitoba & west Ontario"; } enum "America/Yakutat" { value 199; description "Alaska Time - Alaska panhandle neck"; } enum "America/Yellowknife" { value 200; description "Mountain Time - central Northwest Territories"; } enum "Antarctica/Casey" { value 201; description "Casey Station, Bailey Peninsula"; } enum "Antarctica/Davis" { value 202; description "Davis Station, Vestfold Hills"; } enum "Antarctica/DumontDUrville" { value 203; description "Dumont-d'Urville Station, Terre Adelie"; } enum "Antarctica/Macquarie" { value 204; description "Macquarie Island Station, Macquarie Island"; } enum "Antarctica/Mawson" { value 205; description "Mawson Station, Holme Bay"; } enum "Antarctica/McMurdo" { value 206; description "McMurdo Station, Ross Island"; } enum "Antarctica/Palmer" { value 207; description "Palmer Station, Anvers Island"; } enum "Antarctica/Rothera" { value 208; description "Rothera Station, Adelaide Island"; } enum "Antarctica/South_Pole" { value 209; description "Amundsen-Scott Station, South Pole"; } enum "Antarctica/Syowa" { value 210; description "Syowa Station, E Ongul I"; } enum "Antarctica/Vostok" { value 211; description "Vostok Station, Lake Vostok"; } enum "Arctic/Longyearbyen" { value 212; description ""; } enum "Asia/Aden" { value 213; description ""; } enum "Asia/Almaty" { value 214; description "most locations"; } enum "Asia/Amman" { value 215; description ""; } enum "Asia/Anadyr" { value 216; description "Moscow+08 - Bering Sea"; } enum "Asia/Aqtau" { value 217; description "Atyrau (Atirau, Gur'yev), Mangghystau (Mankistau)"; } enum "Asia/Aqtobe" { value 218; description "Aqtobe (Aktobe)"; } enum "Asia/Ashgabat" { value 219; description ""; } enum "Asia/Baghdad" { value 220; description ""; } enum "Asia/Bahrain" { value 221; description ""; } enum "Asia/Baku" { value 222; description ""; } enum "Asia/Bangkok" { value 223; description ""; } enum "Asia/Beirut" { value 224; description ""; } enum "Asia/Bishkek" { value 225; description ""; } enum "Asia/Brunei" { value 226; description ""; } enum "Asia/Choibalsan" { value 227; description "Dornod, Sukhbaatar"; } enum "Asia/Chongqing" { value 228; description "central China - Sichuan, Yunnan, Guangxi, Shaanxi, Guizhou, etc.= "; } enum "Asia/Colombo" { value 229; description ""; } enum "Asia/Damascus" { value 230; description ""; } enum "Asia/Dhaka" { value 231; description ""; } enum "Asia/Dili" { value 232; description ""; } enum "Asia/Dubai" { value 233; description ""; } enum "Asia/Dushanbe" { value 234; description ""; } enum "Asia/Gaza" { value 235; description "Gaza Strip"; } enum "Asia/Harbin" { value 236; description "Heilongjiang (except Mohe), Jilin"; } enum "Asia/Hebron" { value 237; description "West Bank"; } enum "Asia/Ho_Chi_Minh" { value 238; description ""; } enum "Asia/Hong_Kong" { value 239; description ""; } enum "Asia/Hovd" { value 240; description "Bayan-Olgiy, Govi-Altai, Hovd, Uvs, Zavkhan"; } enum "Asia/Irkutsk" { value 241; description "Moscow+05 - Lake Baikal"; } enum "Asia/Jakarta" { value 242; description "Java & Sumatra"; } enum "Asia/Jayapura" { value 243; description "west New Guinea (Irian Jaya) & Malukus (Moluccas)"; } enum "Asia/Jerusalem" { value 244; description ""; } enum "Asia/Kabul" { value 245; description ""; } enum "Asia/Kamchatka" { value 246; description "Moscow+08 - Kamchatka"; } enum "Asia/Karachi" { value 247; description ""; } enum "Asia/Kashgar" { value 248; description "west Tibet & Xinjiang"; } enum "Asia/Kathmandu" { value 249; description ""; } enum "Asia/Kolkata" { value 250; description ""; } enum "Asia/Krasnoyarsk" { value 251; description "Moscow+04 - Yenisei River"; } enum "Asia/Kuala_Lumpur" { value 252; description "peninsular Malaysia"; } enum "Asia/Kuching" { value 253; description "Sabah & Sarawak"; } enum "Asia/Kuwait" { value 254; description ""; } enum "Asia/Macau" { value 255; description ""; } enum "Asia/Magadan" { value 256; description "Moscow+08 - Magadan"; } enum "Asia/Makassar" { value 257; description "east & south Borneo, Sulawesi (Celebes), Bali, Nusa Tengarra, we= st Timor"; } enum "Asia/Manila" { value 258; description ""; } enum "Asia/Muscat" { value 259; description ""; } enum "Asia/Nicosia" { value 260; description ""; } enum "Asia/Novokuznetsk" { value 261; description "Moscow+03 - Novokuznetsk"; } enum "Asia/Novosibirsk" { value 262; description "Moscow+03 - Novosibirsk"; } enum "Asia/Omsk" { value 263; description "Moscow+03 - west Siberia"; } enum "Asia/Oral" { value 264; description "West Kazakhstan"; } enum "Asia/Phnom_Penh" { value 265; description ""; } enum "Asia/Pontianak" { value 266; description "west & central Borneo"; } enum "Asia/Pyongyang" { value 267; description ""; } enum "Asia/Qatar" { value 268; description ""; } enum "Asia/Qyzylorda" { value 269; description "Qyzylorda (Kyzylorda, Kzyl-Orda)"; } enum "Asia/Rangoon" { value 270; description ""; } enum "Asia/Riyadh" { value 271; description ""; } enum "Asia/Sakhalin" { value 272; description "Moscow+07 - Sakhalin Island"; } enum "Asia/Samarkand" { value 273; description "west Uzbekistan"; } enum "Asia/Seoul" { value 274; description ""; } enum "Asia/Shanghai" { value 275; description "east China - Beijing, Guangdong, Shanghai, etc."; } enum "Asia/Singapore" { value 276; description ""; } enum "Asia/Taipei" { value 277; description ""; } enum "Asia/Tashkent" { value 278; description "east Uzbekistan"; } enum "Asia/Tbilisi" { value 279; description ""; } enum "Asia/Tehran" { value 280; description ""; } enum "Asia/Thimphu" { value 281; description ""; } enum "Asia/Tokyo" { value 282; description ""; } enum "Asia/Ulaanbaatar" { value 283; description "most locations"; } enum "Asia/Urumqi" { value 284; description "most of Tibet & Xinjiang"; } enum "Asia/Vientiane" { value 285; description ""; } enum "Asia/Vladivostok" { value 286; description "Moscow+07 - Amur River"; } enum "Asia/Yakutsk" { value 287; description "Moscow+06 - Lena River"; } enum "Asia/Yekaterinburg" { value 288; description "Moscow+02 - Urals"; } enum "Asia/Yerevan" { value 289; description ""; } enum "Atlantic/Azores" { value 290; description "Azores"; } enum "Atlantic/Bermuda" { value 291; description ""; } enum "Atlantic/Canary" { value 292; description "Canary Islands"; } enum "Atlantic/Cape_Verde" { value 293; description ""; } enum "Atlantic/Faroe" { value 294; description ""; } enum "Atlantic/Madeira" { value 295; description "Madeira Islands"; } enum "Atlantic/Reykjavik" { value 296; description ""; } enum "Atlantic/South_Georgia" { value 297; description ""; } enum "Atlantic/Stanley" { value 298; description ""; } enum "Atlantic/St_Helena" { value 299; description ""; } enum "Australia/Adelaide" { value 300; description "South Australia"; } enum "Australia/Brisbane" { value 301; description "Queensland - most locations"; } enum "Australia/Broken_Hill" { value 302; description "New South Wales - Yancowinna"; } enum "Australia/Currie" { value 303; description "Tasmania - King Island"; } enum "Australia/Darwin" { value 304; description "Northern Territory"; } enum "Australia/Eucla" { value 305; description "Western Australia - Eucla area"; } enum "Australia/Hobart" { value 306; description "Tasmania - most locations"; } enum "Australia/Lindeman" { value 307; description "Queensland - Holiday Islands"; } enum "Australia/Lord_Howe" { value 308; description "Lord Howe Island"; } enum "Australia/Melbourne" { value 309; description "Victoria"; } enum "Australia/Perth" { value 310; description "Western Australia - most locations"; } enum "Australia/Sydney" { value 311; description "New South Wales - most locations"; } enum "Europe/Amsterdam" { value 312; description ""; } enum "Europe/Andorra" { value 313; description ""; } enum "Europe/Athens" { value 314; description ""; } enum "Europe/Belgrade" { value 315; description ""; } enum "Europe/Berlin" { value 316; description ""; } enum "Europe/Bratislava" { value 317; description ""; } enum "Europe/Brussels" { value 318; description ""; } enum "Europe/Bucharest" { value 319; description ""; } enum "Europe/Budapest" { value 320; description ""; } enum "Europe/Chisinau" { value 321; description ""; } enum "Europe/Copenhagen" { value 322; description ""; } enum "Europe/Dublin" { value 323; description ""; } enum "Europe/Gibraltar" { value 324; description ""; } enum "Europe/Guernsey" { value 325; description ""; } enum "Europe/Helsinki" { value 326; description ""; } enum "Europe/Isle_of_Man" { value 327; description ""; } enum "Europe/Istanbul" { value 328; description ""; } enum "Europe/Jersey" { value 329; description ""; } enum "Europe/Kaliningrad" { value 330; description "Moscow-01 - Kaliningrad"; } enum "Europe/Kiev" { value 331; description "most locations"; } enum "Europe/Lisbon" { value 332; description "mainland"; } enum "Europe/Ljubljana" { value 333; description ""; } enum "Europe/London" { value 334; description ""; } enum "Europe/Luxembourg" { value 335; description ""; } enum "Europe/Madrid" { value 336; description "mainland"; } enum "Europe/Malta" { value 337; description ""; } enum "Europe/Mariehamn" { value 338; description ""; } enum "Europe/Minsk" { value 339; description ""; } enum "Europe/Monaco" { value 340; description ""; } enum "Europe/Moscow" { value 341; description "Moscow+00 - west Russia"; } enum "Europe/Oslo" { value 342; description ""; } enum "Europe/Paris" { value 343; description ""; } enum "Europe/Podgorica" { value 344; description ""; } enum "Europe/Prague" { value 345; description ""; } enum "Europe/Riga" { value 346; description ""; } enum "Europe/Rome" { value 347; description ""; } enum "Europe/Samara" { value 348; description "Moscow+00 - Samara, Udmurtia"; } enum "Europe/San_Marino" { value 349; description ""; } enum "Europe/Sarajevo" { value 350; description ""; } enum "Europe/Simferopol" { value 351; description "central Crimea"; } enum "Europe/Skopje" { value 352; description ""; } enum "Europe/Sofia" { value 353; description ""; } enum "Europe/Stockholm" { value 354; description ""; } enum "Europe/Tallinn" { value 355; description ""; } enum "Europe/Tirane" { value 356; description ""; } enum "Europe/Uzhgorod" { value 357; description "Ruthenia"; } enum "Europe/Vaduz" { value 358; description ""; } enum "Europe/Vatican" { value 359; description ""; } enum "Europe/Vienna" { value 360; description ""; } enum "Europe/Vilnius" { value 361; description ""; } enum "Europe/Volgograd" { value 362; description "Moscow+00 - Caspian Sea"; } enum "Europe/Warsaw" { value 363; description ""; } enum "Europe/Zagreb" { value 364; description ""; } enum "Europe/Zaporozhye" { value 365; description "Zaporozh'ye, E Lugansk / Zaporizhia, E Luhansk"; } enum "Europe/Zurich" { value 366; description ""; } enum "Indian/Antananarivo" { value 367; description ""; } enum "Indian/Chagos" { value 368; description ""; } enum "Indian/Christmas" { value 369; description ""; } enum "Indian/Cocos" { value 370; description ""; } enum "Indian/Comoro" { value 371; description ""; } enum "Indian/Kerguelen" { value 372; description ""; } enum "Indian/Mahe" { value 373; description ""; } enum "Indian/Maldives" { value 374; description ""; } enum "Indian/Mauritius" { value 375; description ""; } enum "Indian/Mayotte" { value 376; description ""; } enum "Indian/Reunion" { value 377; description ""; } enum "Pacific/Apia" { value 378; description ""; } enum "Pacific/Auckland" { value 379; description "most locations"; } enum "Pacific/Chatham" { value 380; description "Chatham Islands"; } enum "Pacific/Chuuk" { value 381; description "Chuuk (Truk) and Yap"; } enum "Pacific/Easter" { value 382; description "Easter Island & Sala y Gomez"; } enum "Pacific/Efate" { value 383; description ""; } enum "Pacific/Enderbury" { value 384; description "Phoenix Islands"; } enum "Pacific/Fakaofo" { value 385; description ""; } enum "Pacific/Fiji" { value 386; description ""; } enum "Pacific/Funafuti" { value 387; description ""; } enum "Pacific/Galapagos" { value 388; description "Galapagos Islands"; } enum "Pacific/Gambier" { value 389; description "Gambier Islands"; } enum "Pacific/Guadalcanal" { value 390; description ""; } enum "Pacific/Guam" { value 391; description ""; } enum "Pacific/Honolulu" { value 392; description "Hawaii"; } enum "Pacific/Johnston" { value 393; description "Johnston Atoll"; } enum "Pacific/Kiritimati" { value 394; description "Line Islands"; } enum "Pacific/Kosrae" { value 395; description "Kosrae"; } enum "Pacific/Kwajalein" { value 396; description "Kwajalein"; } enum "Pacific/Majuro" { value 397; description "most locations"; } enum "Pacific/Marquesas" { value 398; description "Marquesas Islands"; } enum "Pacific/Midway" { value 399; description "Midway Islands"; } enum "Pacific/Nauru" { value 400; description ""; } enum "Pacific/Niue" { value 401; description ""; } enum "Pacific/Norfolk" { value 402; description ""; } enum "Pacific/Noumea" { value 403; description ""; } enum "Pacific/Pago_Pago" { value 404; description ""; } enum "Pacific/Palau" { value 405; description ""; } enum "Pacific/Pitcairn" { value 406; description ""; } enum "Pacific/Pohnpei" { value 407; description "Pohnpei (Ponape)"; } enum "Pacific/Port_Moresby" { value 408; description ""; } enum "Pacific/Rarotonga" { value 409; description ""; } enum "Pacific/Saipan" { value 410; description ""; } enum "Pacific/Tahiti" { value 411; description "Society Islands"; } enum "Pacific/Tarawa" { value 412; description "Gilbert Islands"; } enum "Pacific/Tongatapu" { value 413; description ""; } enum "Pacific/Wake" { value 414; description "Wake Island"; } enum "Pacific/Wallis" { value 415; description ""; } } } } Jeff Lange Lead Software Engineer GE Energy Services Digital Energy T=A0+1 585 242 8375 F=A0+1 585 241 5590 Jeffrey.K.Lange@ge.com www.GEDigitalEnergy.com 175 Science Parkway Rochester,=A0NY=A014620=A0United States GE imagination at work From andy@yumaworks.com Wed Jun 27 06:39:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CB221F8718 for ; Wed, 27 Jun 2012 06:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zLCqD8GYv6U for ; Wed, 27 Jun 2012 06:39:33 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF57821F8714 for ; Wed, 27 Jun 2012 06:39:31 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1769185lbb.31 for ; Wed, 27 Jun 2012 06:39:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=UTYxB0wtnArM5arRpiNUG1uiXuOL8vCizl+yE4Br5oY=; b=FkQws/Y4MHKkGQX9W5lI4zoQCdHtNdZnCwF+YVTyEUMgs6XFylYtyrkdB1L8qOIydc hDOrOXog74bRZQk+vtk1WdRYy2eOlI9yiXhd6Oguld6yEGTz+Be7+Wuv1U16/rEAckYZ 0ts9BOVT9Bj2CAFEbAG/d5tzJVwQcBw9b25isOB30pDRg6v2WHbI8JBzhRdMNi/kL/FG hnlLNnVfChZIhvghAp2WmTcE6j0EJm0U79RQXfD/oR9iYznyb+mM1RYs+IlffEwRIUwO A8vbi9cqgV4xTith94pbSvQ9TawaqkwfeVnsXeSoBj2NBwKbYb7IHr5zpiHDj8XfkY96 cQCQ== MIME-Version: 1.0 Received: by 10.112.36.132 with SMTP id q4mr9612849lbj.63.1340804365750; Wed, 27 Jun 2012 06:39:25 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 27 Jun 2012 06:39:25 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: Date: Wed, 27 Jun 2012 06:39:25 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy)" Content-Type: multipart/alternative; boundary=e0cb4efe3254ef130504c374577c X-Gm-Message-State: ALoCoQmspGrBP4tmAN8kNY4Xvh53j80MQxXNNSBu2Bsl2oDAMy9HMFstb0j6m43mxu5OPQqNaQ22 Cc: "netmod@ietf.org" Subject: Re: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 13:39:38 -0000 --e0cb4efe3254ef130504c374577c Content-Type: text/plain; charset=ISO-8859-1 I'll read it when you publish it as an I-D. I can change the ietf-system module after you publish and the WG agrees to publish your module. Andy On Wed, Jun 27, 2012 at 6:21 AM, Lange, Jeffrey K (GE Energy) < jeffrey.K.lange@ge.com> wrote: > As I mentioned earlier, the current free-form timezone-location string in > the ietf-system module is not very user friendly, and those timezone > location strings are actually an IANA controlled entity. I have created an > iana-timezones module using the timezones and any textual descriptions > found in the zone.tab file found in the Time Zone Data v. 2012c downloaded > from the iana website. This has resulted in an enumeration with 415 values. > I have also modified the ietf-system module to use this new data type. > > The data was extracted from the zone.tab file using the following cryptic > combination of grep, cat, sort, and awk :-) > > grep -h -v "^#" zone.tab |awk '{ printf ("%s ", $3); sep=""; for (i=4; > i<=NF; i++) {printf("%s%s",sep,$i); sep=OFS}; printf("\n");}' |sort -g |cat > -n |awk '{ printf(" enum \"%s\" {\n value %s;\n > description\n \"", $2, $1); sep=""; for (i=3; i<=NF; i++) > {printf("%s%s",sep,$i); sep=OFS}; print "\";\n }" }' > > I pretty much took the header info from the iana-if-type module verbatim, > with minor changes to reflect the fact that it is for timezones, so odds > are this would need to be adjusted to be in the correct format. > > Not every entry in the enumeration has a description, because not every > entry in the zone.tab file has a description. I'm not sure if this would > be kosher in an official release or not. > > Below is the changes needed for ietf-system: > > diff --git a/ietf-system@2012-01-31.yang b/ietf-system@2012-01-31.yang > index dd26ea1..4e7952c 100644 > --- a/ietf-system@2012-01-31.yang > +++ b/ietf-system@2012-01-31.yang > @@ -11,6 +11,9 @@ module ietf-system { > import ietf-netconf-acm { > prefix nacm; > } > + import iana-timezones { > + prefix ianatz; > + } > > organization "IETF NETMOD (NETCONF Data Modeling Language) Working > Group"; > contact > @@ -882,9 +885,9 @@ module ietf-system { > "Configure the system timezone information."; > leaf timezone-location { > if-feature timezone-location; > - type string; > + type ianatz:iana-timezone; > description > - "The TZ database location identifier string > + "The TZ database location enumeration > to use for the system, such as 'Europe/Stockholm'."; > } > leaf timezone-name { > > > > And below is the full text of the iana-timezones.yang file I have created > > > module iana-timezones { > namespace "urn:ietf:params:xml:ns:yang:iana-timezones"; > prefix ianatz; > > organization "IANA"; > contact > " Internet Assigned Numbers Authority > > Postal: ICANN > 4676 Admiralty Way, Suite 330 > Marina del Rey, CA 90292 > > Tel: +1 310 823 9358 > E-Mail: iana&iana.org"; > description > "This YANG module defines the iana-timezone typedef, which > contains YANG definitions for IANA-registered timezones. > > This YANG module is maintained by IANA, and reflects the > IANA Time Zone Database. > (http://www.iana.org/time-zones) > > The latest revision of this YANG module can be obtained from > the IANA web site. > > Copyright (c) 2011 IETF Trust and the persons identified as > authors of the code. All rights reserved. > > Redistribution and use in source and binary forms, with or > without modification, is permitted pursuant to, and subject > to the license terms contained in, the Simplified BSD License > set forth in Section 4.c of the IETF Trust's Legal Provisions > Relating to IETF Documents > (http://trustee.ietf.org/license-info). > > This version of this YANG module is part of RFC XXXX; see > the RFC itself for full legal notices."; > > revision 2012-06-27 { > description > "Initial revision. Using IANA Time Zone Data v. 2012c > (Released 2012-03-27)"; > reference "RFC XXXX: TITLE"; > } > typedef iana-timezone { > type enumeration { > enum "Africa/Abidjan" { > value 1; > description > ""; > } > enum "Africa/Accra" { > value 2; > description > ""; > } > enum "Africa/Addis_Ababa" { > value 3; > description > ""; > } > enum "Africa/Algiers" { > value 4; > description > ""; > } > enum "Africa/Asmara" { > value 5; > description > ""; > } > enum "Africa/Bamako" { > value 6; > description > ""; > } > enum "Africa/Bangui" { > value 7; > description > ""; > } > enum "Africa/Banjul" { > value 8; > description > ""; > } > enum "Africa/Bissau" { > value 9; > description > ""; > } > enum "Africa/Blantyre" { > value 10; > description > ""; > } > enum "Africa/Brazzaville" { > value 11; > description > ""; > } > enum "Africa/Bujumbura" { > value 12; > description > ""; > } > enum "Africa/Cairo" { > value 13; > description > ""; > } > enum "Africa/Casablanca" { > value 14; > description > ""; > } > enum "Africa/Ceuta" { > value 15; > description > "Ceuta & Melilla"; > } > enum "Africa/Conakry" { > value 16; > description > ""; > } > enum "Africa/Dakar" { > value 17; > description > ""; > } > enum "Africa/Dar_es_Salaam" { > value 18; > description > ""; > } > enum "Africa/Djibouti" { > value 19; > description > ""; > } > enum "Africa/Douala" { > value 20; > description > ""; > } > enum "Africa/El_Aaiun" { > value 21; > description > ""; > } > enum "Africa/Freetown" { > value 22; > description > ""; > } > enum "Africa/Gaborone" { > value 23; > description > ""; > } > enum "Africa/Harare" { > value 24; > description > ""; > } > enum "Africa/Johannesburg" { > value 25; > description > ""; > } > enum "Africa/Juba" { > value 26; > description > ""; > } > enum "Africa/Kampala" { > value 27; > description > ""; > } > enum "Africa/Khartoum" { > value 28; > description > ""; > } > enum "Africa/Kigali" { > value 29; > description > ""; > } > enum "Africa/Kinshasa" { > value 30; > description > "west Dem. Rep. of Congo"; > } > enum "Africa/Lagos" { > value 31; > description > ""; > } > enum "Africa/Libreville" { > value 32; > description > ""; > } > enum "Africa/Lome" { > value 33; > description > ""; > } > enum "Africa/Luanda" { > value 34; > description > ""; > } > enum "Africa/Lubumbashi" { > value 35; > description > "east Dem. Rep. of Congo"; > } > enum "Africa/Lusaka" { > value 36; > description > ""; > } > enum "Africa/Malabo" { > value 37; > description > ""; > } > enum "Africa/Maputo" { > value 38; > description > ""; > } > enum "Africa/Maseru" { > value 39; > description > ""; > } > enum "Africa/Mbabane" { > value 40; > description > ""; > } > enum "Africa/Mogadishu" { > value 41; > description > ""; > } > enum "Africa/Monrovia" { > value 42; > description > ""; > } > enum "Africa/Nairobi" { > value 43; > description > ""; > } > enum "Africa/Ndjamena" { > value 44; > description > ""; > } > enum "Africa/Niamey" { > value 45; > description > ""; > } > enum "Africa/Nouakchott" { > value 46; > description > ""; > } > enum "Africa/Ouagadougou" { > value 47; > description > ""; > } > enum "Africa/Porto-Novo" { > value 48; > description > ""; > } > enum "Africa/Sao_Tome" { > value 49; > description > ""; > } > enum "Africa/Tripoli" { > value 50; > description > ""; > } > enum "Africa/Tunis" { > value 51; > description > ""; > } > enum "Africa/Windhoek" { > value 52; > description > ""; > } > enum "America/Adak" { > value 53; > description > "Aleutian Islands"; > } > enum "America/Anchorage" { > value 54; > description > "Alaska Time"; > } > enum "America/Anguilla" { > value 55; > description > ""; > } > enum "America/Antigua" { > value 56; > description > ""; > } > enum "America/Araguaina" { > value 57; > description > "Tocantins"; > } > enum "America/Argentina/Buenos_Aires" { > value 58; > description > "Buenos Aires (BA, CF)"; > } > enum "America/Argentina/Catamarca" { > value 59; > description > "Catamarca (CT), Chubut (CH)"; > } > enum "America/Argentina/Cordoba" { > value 60; > description > "most locations (CB, CC, CN, ER, FM, MN, SE, SF)"; > } > enum "America/Argentina/Jujuy" { > value 61; > description > "Jujuy (JY)"; > } > enum "America/Argentina/La_Rioja" { > value 62; > description > "La Rioja (LR)"; > } > enum "America/Argentina/Mendoza" { > value 63; > description > "Mendoza (MZ)"; > } > enum "America/Argentina/Rio_Gallegos" { > value 64; > description > "Santa Cruz (SC)"; > } > enum "America/Argentina/Salta" { > value 65; > description > "(SA, LP, NQ, RN)"; > } > enum "America/Argentina/San_Juan" { > value 66; > description > "San Juan (SJ)"; > } > enum "America/Argentina/San_Luis" { > value 67; > description > "San Luis (SL)"; > } > enum "America/Argentina/Tucuman" { > value 68; > description > "Tucuman (TM)"; > } > enum "America/Argentina/Ushuaia" { > value 69; > description > "Tierra del Fuego (TF)"; > } > enum "America/Aruba" { > value 70; > description > ""; > } > enum "America/Asuncion" { > value 71; > description > ""; > } > enum "America/Atikokan" { > value 72; > description > "Eastern Standard Time - Atikokan, Ontario and Southampton I, > Nunavut"; > } > enum "America/Bahia" { > value 73; > description > "Bahia"; > } > enum "America/Bahia_Banderas" { > value 74; > description > "Mexican Central Time - Bahia de Banderas"; > } > enum "America/Barbados" { > value 75; > description > ""; > } > enum "America/Belem" { > value 76; > description > "Amapa, E Para"; > } > enum "America/Belize" { > value 77; > description > ""; > } > enum "America/Blanc-Sablon" { > value 78; > description > "Atlantic Standard Time - Quebec - Lower North Shore"; > } > enum "America/Boa_Vista" { > value 79; > description > "Roraima"; > } > enum "America/Bogota" { > value 80; > description > ""; > } > enum "America/Boise" { > value 81; > description > "Mountain Time - south Idaho & east Oregon"; > } > enum "America/Cambridge_Bay" { > value 82; > description > "Mountain Time - west Nunavut"; > } > enum "America/Campo_Grande" { > value 83; > description > "Mato Grosso do Sul"; > } > enum "America/Cancun" { > value 84; > description > "Central Time - Quintana Roo"; > } > enum "America/Caracas" { > value 85; > description > ""; > } > enum "America/Cayenne" { > value 86; > description > ""; > } > enum "America/Cayman" { > value 87; > description > ""; > } > enum "America/Chicago" { > value 88; > description > "Central Time"; > } > enum "America/Chihuahua" { > value 89; > description > "Mexican Mountain Time - Chihuahua away from US border"; > } > enum "America/Costa_Rica" { > value 90; > description > ""; > } > enum "America/Creston" { > value 91; > description > "Mountain Standard Time - Creston, British Columbia"; > } > enum "America/Cuiaba" { > value 92; > description > "Mato Grosso"; > } > enum "America/Curacao" { > value 93; > description > ""; > } > enum "America/Danmarkshavn" { > value 94; > description > "east coast, north of Scoresbysund"; > } > enum "America/Dawson_Creek" { > value 95; > description > "Mountain Standard Time - Dawson Creek & Fort Saint John, British > Columbia"; > } > enum "America/Dawson" { > value 96; > description > "Pacific Time - north Yukon"; > } > enum "America/Denver" { > value 97; > description > "Mountain Time"; > } > enum "America/Detroit" { > value 98; > description > "Eastern Time - Michigan - most locations"; > } > enum "America/Dominica" { > value 99; > description > ""; > } > enum "America/Edmonton" { > value 100; > description > "Mountain Time - Alberta, east British Columbia & west > Saskatchewan"; > } > enum "America/Eirunepe" { > value 101; > description > "W Amazonas"; > } > enum "America/El_Salvador" { > value 102; > description > ""; > } > enum "America/Fortaleza" { > value 103; > description > "NE Brazil (MA, PI, CE, RN, PB)"; > } > enum "America/Glace_Bay" { > value 104; > description > "Atlantic Time - Nova Scotia - places that did not observe DST > 1966-1971"; > } > enum "America/Godthab" { > value 105; > description > "most locations"; > } > enum "America/Goose_Bay" { > value 106; > description > "Atlantic Time - Labrador - most locations"; > } > enum "America/Grand_Turk" { > value 107; > description > ""; > } > enum "America/Grenada" { > value 108; > description > ""; > } > enum "America/Guadeloupe" { > value 109; > description > ""; > } > enum "America/Guatemala" { > value 110; > description > ""; > } > enum "America/Guayaquil" { > value 111; > description > "mainland"; > } > enum "America/Guyana" { > value 112; > description > ""; > } > enum "America/Halifax" { > value 113; > description > "Atlantic Time - Nova Scotia (most places), PEI"; > } > enum "America/Havana" { > value 114; > description > ""; > } > enum "America/Hermosillo" { > value 115; > description > "Mountain Standard Time - Sonora"; > } > enum "America/Indiana/Indianapolis" { > value 116; > description > "Eastern Time - Indiana - most locations"; > } > enum "America/Indiana/Knox" { > value 117; > description > "Central Time - Indiana - Starke County"; > } > enum "America/Indiana/Marengo" { > value 118; > description > "Eastern Time - Indiana - Crawford County"; > } > enum "America/Indiana/Petersburg" { > value 119; > description > "Eastern Time - Indiana - Pike County"; > } > enum "America/Indiana/Tell_City" { > value 120; > description > "Central Time - Indiana - Perry County"; > } > enum "America/Indiana/Vevay" { > value 121; > description > "Eastern Time - Indiana - Switzerland County"; > } > enum "America/Indiana/Vincennes" { > value 122; > description > "Eastern Time - Indiana - Daviess, Dubois, Knox & Martin > Counties"; > } > enum "America/Indiana/Winamac" { > value 123; > description > "Eastern Time - Indiana - Pulaski County"; > } > enum "America/Inuvik" { > value 124; > description > "Mountain Time - west Northwest Territories"; > } > enum "America/Iqaluit" { > value 125; > description > "Eastern Time - east Nunavut - most locations"; > } > enum "America/Jamaica" { > value 126; > description > ""; > } > enum "America/Juneau" { > value 127; > description > "Alaska Time - Alaska panhandle"; > } > enum "America/Kentucky/Louisville" { > value 128; > description > "Eastern Time - Kentucky - Louisville area"; > } > enum "America/Kentucky/Monticello" { > value 129; > description > "Eastern Time - Kentucky - Wayne County"; > } > enum "America/Kralendijk" { > value 130; > description > ""; > } > enum "America/La_Paz" { > value 131; > description > ""; > } > enum "America/Lima" { > value 132; > description > ""; > } > enum "America/Los_Angeles" { > value 133; > description > "Pacific Time"; > } > enum "America/Lower_Princes" { > value 134; > description > ""; > } > enum "America/Maceio" { > value 135; > description > "Alagoas, Sergipe"; > } > enum "America/Managua" { > value 136; > description > ""; > } > enum "America/Manaus" { > value 137; > description > "E Amazonas"; > } > enum "America/Marigot" { > value 138; > description > ""; > } > enum "America/Martinique" { > value 139; > description > ""; > } > enum "America/Matamoros" { > value 140; > description > "US Central Time - Coahuila, Durango, Nuevo Leon, Tamaulipas near > US border"; > } > enum "America/Mazatlan" { > value 141; > description > "Mountain Time - S Baja, Nayarit, Sinaloa"; > } > enum "America/Menominee" { > value 142; > description > "Central Time - Michigan - Dickinson, Gogebic, Iron & Menominee > Counties"; > } > enum "America/Merida" { > value 143; > description > "Central Time - Campeche, Yucatan"; > } > enum "America/Metlakatla" { > value 144; > description > "Metlakatla Time - Annette Island"; > } > enum "America/Mexico_City" { > value 145; > description > "Central Time - most locations"; > } > enum "America/Miquelon" { > value 146; > description > ""; > } > enum "America/Moncton" { > value 147; > description > "Atlantic Time - New Brunswick"; > } > enum "America/Monterrey" { > value 148; > description > "Mexican Central Time - Coahuila, Durango, Nuevo Leon, Tamaulipas > away from US border"; > } > enum "America/Montevideo" { > value 149; > description > ""; > } > enum "America/Montreal" { > value 150; > description > "Eastern Time - Quebec - most locations"; > } > enum "America/Montserrat" { > value 151; > description > ""; > } > enum "America/Nassau" { > value 152; > description > ""; > } > enum "America/New_York" { > value 153; > description > "Eastern Time"; > } > enum "America/Nipigon" { > value 154; > description > "Eastern Time - Ontario & Quebec - places that did not observe > DST 1967-1973"; > } > enum "America/Nome" { > value 155; > description > "Alaska Time - west Alaska"; > } > enum "America/Noronha" { > value 156; > description > "Atlantic islands"; > } > enum "America/North_Dakota/Beulah" { > value 157; > description > "Central Time - North Dakota - Mercer County"; > } > enum "America/North_Dakota/Center" { > value 158; > description > "Central Time - North Dakota - Oliver County"; > } > enum "America/North_Dakota/New_Salem" { > value 159; > description > "Central Time - North Dakota - Morton County (except Mandan > area)"; > } > enum "America/Ojinaga" { > value 160; > description > "US Mountain Time - Chihuahua near US border"; > } > enum "America/Panama" { > value 161; > description > ""; > } > enum "America/Pangnirtung" { > value 162; > description > "Eastern Time - Pangnirtung, Nunavut"; > } > enum "America/Paramaribo" { > value 163; > description > ""; > } > enum "America/Phoenix" { > value 164; > description > "Mountain Standard Time - Arizona"; > } > enum "America/Port-au-Prince" { > value 165; > description > ""; > } > enum "America/Port_of_Spain" { > value 166; > description > ""; > } > enum "America/Porto_Velho" { > value 167; > description > "Rondonia"; > } > enum "America/Puerto_Rico" { > value 168; > description > ""; > } > enum "America/Rainy_River" { > value 169; > description > "Central Time - Rainy River & Fort Frances, Ontario"; > } > enum "America/Rankin_Inlet" { > value 170; > description > "Central Time - central Nunavut"; > } > enum "America/Recife" { > value 171; > description > "Pernambuco"; > } > enum "America/Regina" { > value 172; > description > "Central Standard Time - Saskatchewan - most locations"; > } > enum "America/Resolute" { > value 173; > description > "Central Standard Time - Resolute, Nunavut"; > } > enum "America/Rio_Branco" { > value 174; > description > "Acre"; > } > enum "America/Santa_Isabel" { > value 175; > description > "Mexican Pacific Time - Baja California away from US border"; > } > enum "America/Santarem" { > value 176; > description > "W Para"; > } > enum "America/Santiago" { > value 177; > description > "most locations"; > } > enum "America/Santo_Domingo" { > value 178; > description > ""; > } > enum "America/Sao_Paulo" { > value 179; > description > "S & SE Brazil (GO, DF, MG, ES, RJ, SP, PR, SC, RS)"; > } > enum "America/Scoresbysund" { > value 180; > description > "Scoresbysund / Ittoqqortoormiit"; > } > enum "America/Shiprock" { > value 181; > description > "Mountain Time - Navajo"; > } > enum "America/Sitka" { > value 182; > description > "Alaska Time - southeast Alaska panhandle"; > } > enum "America/St_Barthelemy" { > value 183; > description > ""; > } > enum "America/St_Johns" { > value 184; > description > "Newfoundland Time, including SE Labrador"; > } > enum "America/St_Kitts" { > value 185; > description > ""; > } > enum "America/St_Lucia" { > value 186; > description > ""; > } > enum "America/St_Thomas" { > value 187; > description > ""; > } > enum "America/St_Vincent" { > value 188; > description > ""; > } > enum "America/Swift_Current" { > value 189; > description > "Central Standard Time - Saskatchewan - midwest"; > } > enum "America/Tegucigalpa" { > value 190; > description > ""; > } > enum "America/Thule" { > value 191; > description > "Thule / Pituffik"; > } > enum "America/Thunder_Bay" { > value 192; > description > "Eastern Time - Thunder Bay, Ontario"; > } > enum "America/Tijuana" { > value 193; > description > "US Pacific Time - Baja California near US border"; > } > enum "America/Toronto" { > value 194; > description > "Eastern Time - Ontario - most locations"; > } > enum "America/Tortola" { > value 195; > description > ""; > } > enum "America/Vancouver" { > value 196; > description > "Pacific Time - west British Columbia"; > } > enum "America/Whitehorse" { > value 197; > description > "Pacific Time - south Yukon"; > } > enum "America/Winnipeg" { > value 198; > description > "Central Time - Manitoba & west Ontario"; > } > enum "America/Yakutat" { > value 199; > description > "Alaska Time - Alaska panhandle neck"; > } > enum "America/Yellowknife" { > value 200; > description > "Mountain Time - central Northwest Territories"; > } > enum "Antarctica/Casey" { > value 201; > description > "Casey Station, Bailey Peninsula"; > } > enum "Antarctica/Davis" { > value 202; > description > "Davis Station, Vestfold Hills"; > } > enum "Antarctica/DumontDUrville" { > value 203; > description > "Dumont-d'Urville Station, Terre Adelie"; > } > enum "Antarctica/Macquarie" { > value 204; > description > "Macquarie Island Station, Macquarie Island"; > } > enum "Antarctica/Mawson" { > value 205; > description > "Mawson Station, Holme Bay"; > } > enum "Antarctica/McMurdo" { > value 206; > description > "McMurdo Station, Ross Island"; > } > enum "Antarctica/Palmer" { > value 207; > description > "Palmer Station, Anvers Island"; > } > enum "Antarctica/Rothera" { > value 208; > description > "Rothera Station, Adelaide Island"; > } > enum "Antarctica/South_Pole" { > value 209; > description > "Amundsen-Scott Station, South Pole"; > } > enum "Antarctica/Syowa" { > value 210; > description > "Syowa Station, E Ongul I"; > } > enum "Antarctica/Vostok" { > value 211; > description > "Vostok Station, Lake Vostok"; > } > enum "Arctic/Longyearbyen" { > value 212; > description > ""; > } > enum "Asia/Aden" { > value 213; > description > ""; > } > enum "Asia/Almaty" { > value 214; > description > "most locations"; > } > enum "Asia/Amman" { > value 215; > description > ""; > } > enum "Asia/Anadyr" { > value 216; > description > "Moscow+08 - Bering Sea"; > } > enum "Asia/Aqtau" { > value 217; > description > "Atyrau (Atirau, Gur'yev), Mangghystau (Mankistau)"; > } > enum "Asia/Aqtobe" { > value 218; > description > "Aqtobe (Aktobe)"; > } > enum "Asia/Ashgabat" { > value 219; > description > ""; > } > enum "Asia/Baghdad" { > value 220; > description > ""; > } > enum "Asia/Bahrain" { > value 221; > description > ""; > } > enum "Asia/Baku" { > value 222; > description > ""; > } > enum "Asia/Bangkok" { > value 223; > description > ""; > } > enum "Asia/Beirut" { > value 224; > description > ""; > } > enum "Asia/Bishkek" { > value 225; > description > ""; > } > enum "Asia/Brunei" { > value 226; > description > ""; > } > enum "Asia/Choibalsan" { > value 227; > description > "Dornod, Sukhbaatar"; > } > enum "Asia/Chongqing" { > value 228; > description > "central China - Sichuan, Yunnan, Guangxi, Shaanxi, Guizhou, > etc."; > } > enum "Asia/Colombo" { > value 229; > description > ""; > } > enum "Asia/Damascus" { > value 230; > description > ""; > } > enum "Asia/Dhaka" { > value 231; > description > ""; > } > enum "Asia/Dili" { > value 232; > description > ""; > } > enum "Asia/Dubai" { > value 233; > description > ""; > } > enum "Asia/Dushanbe" { > value 234; > description > ""; > } > enum "Asia/Gaza" { > value 235; > description > "Gaza Strip"; > } > enum "Asia/Harbin" { > value 236; > description > "Heilongjiang (except Mohe), Jilin"; > } > enum "Asia/Hebron" { > value 237; > description > "West Bank"; > } > enum "Asia/Ho_Chi_Minh" { > value 238; > description > ""; > } > enum "Asia/Hong_Kong" { > value 239; > description > ""; > } > enum "Asia/Hovd" { > value 240; > description > "Bayan-Olgiy, Govi-Altai, Hovd, Uvs, Zavkhan"; > } > enum "Asia/Irkutsk" { > value 241; > description > "Moscow+05 - Lake Baikal"; > } > enum "Asia/Jakarta" { > value 242; > description > "Java & Sumatra"; > } > enum "Asia/Jayapura" { > value 243; > description > "west New Guinea (Irian Jaya) & Malukus (Moluccas)"; > } > enum "Asia/Jerusalem" { > value 244; > description > ""; > } > enum "Asia/Kabul" { > value 245; > description > ""; > } > enum "Asia/Kamchatka" { > value 246; > description > "Moscow+08 - Kamchatka"; > } > enum "Asia/Karachi" { > value 247; > description > ""; > } > enum "Asia/Kashgar" { > value 248; > description > "west Tibet & Xinjiang"; > } > enum "Asia/Kathmandu" { > value 249; > description > ""; > } > enum "Asia/Kolkata" { > value 250; > description > ""; > } > enum "Asia/Krasnoyarsk" { > value 251; > description > "Moscow+04 - Yenisei River"; > } > enum "Asia/Kuala_Lumpur" { > value 252; > description > "peninsular Malaysia"; > } > enum "Asia/Kuching" { > value 253; > description > "Sabah & Sarawak"; > } > enum "Asia/Kuwait" { > value 254; > description > ""; > } > enum "Asia/Macau" { > value 255; > description > ""; > } > enum "Asia/Magadan" { > value 256; > description > "Moscow+08 - Magadan"; > } > enum "Asia/Makassar" { > value 257; > description > "east & south Borneo, Sulawesi (Celebes), Bali, Nusa Tengarra, > west Timor"; > } > enum "Asia/Manila" { > value 258; > description > ""; > } > enum "Asia/Muscat" { > value 259; > description > ""; > } > enum "Asia/Nicosia" { > value 260; > description > ""; > } > enum "Asia/Novokuznetsk" { > value 261; > description > "Moscow+03 - Novokuznetsk"; > } > enum "Asia/Novosibirsk" { > value 262; > description > "Moscow+03 - Novosibirsk"; > } > enum "Asia/Omsk" { > value 263; > description > "Moscow+03 - west Siberia"; > } > enum "Asia/Oral" { > value 264; > description > "West Kazakhstan"; > } > enum "Asia/Phnom_Penh" { > value 265; > description > ""; > } > enum "Asia/Pontianak" { > value 266; > description > "west & central Borneo"; > } > enum "Asia/Pyongyang" { > value 267; > description > ""; > } > enum "Asia/Qatar" { > value 268; > description > ""; > } > enum "Asia/Qyzylorda" { > value 269; > description > "Qyzylorda (Kyzylorda, Kzyl-Orda)"; > } > enum "Asia/Rangoon" { > value 270; > description > ""; > } > enum "Asia/Riyadh" { > value 271; > description > ""; > } > enum "Asia/Sakhalin" { > value 272; > description > "Moscow+07 - Sakhalin Island"; > } > enum "Asia/Samarkand" { > value 273; > description > "west Uzbekistan"; > } > enum "Asia/Seoul" { > value 274; > description > ""; > } > enum "Asia/Shanghai" { > value 275; > description > "east China - Beijing, Guangdong, Shanghai, etc."; > } > enum "Asia/Singapore" { > value 276; > description > ""; > } > enum "Asia/Taipei" { > value 277; > description > ""; > } > enum "Asia/Tashkent" { > value 278; > description > "east Uzbekistan"; > } > enum "Asia/Tbilisi" { > value 279; > description > ""; > } > enum "Asia/Tehran" { > value 280; > description > ""; > } > enum "Asia/Thimphu" { > value 281; > description > ""; > } > enum "Asia/Tokyo" { > value 282; > description > ""; > } > enum "Asia/Ulaanbaatar" { > value 283; > description > "most locations"; > } > enum "Asia/Urumqi" { > value 284; > description > "most of Tibet & Xinjiang"; > } > enum "Asia/Vientiane" { > value 285; > description > ""; > } > enum "Asia/Vladivostok" { > value 286; > description > "Moscow+07 - Amur River"; > } > enum "Asia/Yakutsk" { > value 287; > description > "Moscow+06 - Lena River"; > } > enum "Asia/Yekaterinburg" { > value 288; > description > "Moscow+02 - Urals"; > } > enum "Asia/Yerevan" { > value 289; > description > ""; > } > enum "Atlantic/Azores" { > value 290; > description > "Azores"; > } > enum "Atlantic/Bermuda" { > value 291; > description > ""; > } > enum "Atlantic/Canary" { > value 292; > description > "Canary Islands"; > } > enum "Atlantic/Cape_Verde" { > value 293; > description > ""; > } > enum "Atlantic/Faroe" { > value 294; > description > ""; > } > enum "Atlantic/Madeira" { > value 295; > description > "Madeira Islands"; > } > enum "Atlantic/Reykjavik" { > value 296; > description > ""; > } > enum "Atlantic/South_Georgia" { > value 297; > description > ""; > } > enum "Atlantic/Stanley" { > value 298; > description > ""; > } > enum "Atlantic/St_Helena" { > value 299; > description > ""; > } > enum "Australia/Adelaide" { > value 300; > description > "South Australia"; > } > enum "Australia/Brisbane" { > value 301; > description > "Queensland - most locations"; > } > enum "Australia/Broken_Hill" { > value 302; > description > "New South Wales - Yancowinna"; > } > enum "Australia/Currie" { > value 303; > description > "Tasmania - King Island"; > } > enum "Australia/Darwin" { > value 304; > description > "Northern Territory"; > } > enum "Australia/Eucla" { > value 305; > description > "Western Australia - Eucla area"; > } > enum "Australia/Hobart" { > value 306; > description > "Tasmania - most locations"; > } > enum "Australia/Lindeman" { > value 307; > description > "Queensland - Holiday Islands"; > } > enum "Australia/Lord_Howe" { > value 308; > description > "Lord Howe Island"; > } > enum "Australia/Melbourne" { > value 309; > description > "Victoria"; > } > enum "Australia/Perth" { > value 310; > description > "Western Australia - most locations"; > } > enum "Australia/Sydney" { > value 311; > description > "New South Wales - most locations"; > } > enum "Europe/Amsterdam" { > value 312; > description > ""; > } > enum "Europe/Andorra" { > value 313; > description > ""; > } > enum "Europe/Athens" { > value 314; > description > ""; > } > enum "Europe/Belgrade" { > value 315; > description > ""; > } > enum "Europe/Berlin" { > value 316; > description > ""; > } > enum "Europe/Bratislava" { > value 317; > description > ""; > } > enum "Europe/Brussels" { > value 318; > description > ""; > } > enum "Europe/Bucharest" { > value 319; > description > ""; > } > enum "Europe/Budapest" { > value 320; > description > ""; > } > enum "Europe/Chisinau" { > value 321; > description > ""; > } > enum "Europe/Copenhagen" { > value 322; > description > ""; > } > enum "Europe/Dublin" { > value 323; > description > ""; > } > enum "Europe/Gibraltar" { > value 324; > description > ""; > } > enum "Europe/Guernsey" { > value 325; > description > ""; > } > enum "Europe/Helsinki" { > value 326; > description > ""; > } > enum "Europe/Isle_of_Man" { > value 327; > description > ""; > } > enum "Europe/Istanbul" { > value 328; > description > ""; > } > enum "Europe/Jersey" { > value 329; > description > ""; > } > enum "Europe/Kaliningrad" { > value 330; > description > "Moscow-01 - Kaliningrad"; > } > enum "Europe/Kiev" { > value 331; > description > "most locations"; > } > enum "Europe/Lisbon" { > value 332; > description > "mainland"; > } > enum "Europe/Ljubljana" { > value 333; > description > ""; > } > enum "Europe/London" { > value 334; > description > ""; > } > enum "Europe/Luxembourg" { > value 335; > description > ""; > } > enum "Europe/Madrid" { > value 336; > description > "mainland"; > } > enum "Europe/Malta" { > value 337; > description > ""; > } > enum "Europe/Mariehamn" { > value 338; > description > ""; > } > enum "Europe/Minsk" { > value 339; > description > ""; > } > enum "Europe/Monaco" { > value 340; > description > ""; > } > enum "Europe/Moscow" { > value 341; > description > "Moscow+00 - west Russia"; > } > enum "Europe/Oslo" { > value 342; > description > ""; > } > enum "Europe/Paris" { > value 343; > description > ""; > } > enum "Europe/Podgorica" { > value 344; > description > ""; > } > enum "Europe/Prague" { > value 345; > description > ""; > } > enum "Europe/Riga" { > value 346; > description > ""; > } > enum "Europe/Rome" { > value 347; > description > ""; > } > enum "Europe/Samara" { > value 348; > description > "Moscow+00 - Samara, Udmurtia"; > } > enum "Europe/San_Marino" { > value 349; > description > ""; > } > enum "Europe/Sarajevo" { > value 350; > description > ""; > } > enum "Europe/Simferopol" { > value 351; > description > "central Crimea"; > } > enum "Europe/Skopje" { > value 352; > description > ""; > } > enum "Europe/Sofia" { > value 353; > description > ""; > } > enum "Europe/Stockholm" { > value 354; > description > ""; > } > enum "Europe/Tallinn" { > value 355; > description > ""; > } > enum "Europe/Tirane" { > value 356; > description > ""; > } > enum "Europe/Uzhgorod" { > value 357; > description > "Ruthenia"; > } > enum "Europe/Vaduz" { > value 358; > description > ""; > } > enum "Europe/Vatican" { > value 359; > description > ""; > } > enum "Europe/Vienna" { > value 360; > description > ""; > } > enum "Europe/Vilnius" { > value 361; > description > ""; > } > enum "Europe/Volgograd" { > value 362; > description > "Moscow+00 - Caspian Sea"; > } > enum "Europe/Warsaw" { > value 363; > description > ""; > } > enum "Europe/Zagreb" { > value 364; > description > ""; > } > enum "Europe/Zaporozhye" { > value 365; > description > "Zaporozh'ye, E Lugansk / Zaporizhia, E Luhansk"; > } > enum "Europe/Zurich" { > value 366; > description > ""; > } > enum "Indian/Antananarivo" { > value 367; > description > ""; > } > enum "Indian/Chagos" { > value 368; > description > ""; > } > enum "Indian/Christmas" { > value 369; > description > ""; > } > enum "Indian/Cocos" { > value 370; > description > ""; > } > enum "Indian/Comoro" { > value 371; > description > ""; > } > enum "Indian/Kerguelen" { > value 372; > description > ""; > } > enum "Indian/Mahe" { > value 373; > description > ""; > } > enum "Indian/Maldives" { > value 374; > description > ""; > } > enum "Indian/Mauritius" { > value 375; > description > ""; > } > enum "Indian/Mayotte" { > value 376; > description > ""; > } > enum "Indian/Reunion" { > value 377; > description > ""; > } > enum "Pacific/Apia" { > value 378; > description > ""; > } > enum "Pacific/Auckland" { > value 379; > description > "most locations"; > } > enum "Pacific/Chatham" { > value 380; > description > "Chatham Islands"; > } > enum "Pacific/Chuuk" { > value 381; > description > "Chuuk (Truk) and Yap"; > } > enum "Pacific/Easter" { > value 382; > description > "Easter Island & Sala y Gomez"; > } > enum "Pacific/Efate" { > value 383; > description > ""; > } > enum "Pacific/Enderbury" { > value 384; > description > "Phoenix Islands"; > } > enum "Pacific/Fakaofo" { > value 385; > description > ""; > } > enum "Pacific/Fiji" { > value 386; > description > ""; > } > enum "Pacific/Funafuti" { > value 387; > description > ""; > } > enum "Pacific/Galapagos" { > value 388; > description > "Galapagos Islands"; > } > enum "Pacific/Gambier" { > value 389; > description > "Gambier Islands"; > } > enum "Pacific/Guadalcanal" { > value 390; > description > ""; > } > enum "Pacific/Guam" { > value 391; > description > ""; > } > enum "Pacific/Honolulu" { > value 392; > description > "Hawaii"; > } > enum "Pacific/Johnston" { > value 393; > description > "Johnston Atoll"; > } > enum "Pacific/Kiritimati" { > value 394; > description > "Line Islands"; > } > enum "Pacific/Kosrae" { > value 395; > description > "Kosrae"; > } > enum "Pacific/Kwajalein" { > value 396; > description > "Kwajalein"; > } > enum "Pacific/Majuro" { > value 397; > description > "most locations"; > } > enum "Pacific/Marquesas" { > value 398; > description > "Marquesas Islands"; > } > enum "Pacific/Midway" { > value 399; > description > "Midway Islands"; > } > enum "Pacific/Nauru" { > value 400; > description > ""; > } > enum "Pacific/Niue" { > value 401; > description > ""; > } > enum "Pacific/Norfolk" { > value 402; > description > ""; > } > enum "Pacific/Noumea" { > value 403; > description > ""; > } > enum "Pacific/Pago_Pago" { > value 404; > description > ""; > } > enum "Pacific/Palau" { > value 405; > description > ""; > } > enum "Pacific/Pitcairn" { > value 406; > description > ""; > } > enum "Pacific/Pohnpei" { > value 407; > description > "Pohnpei (Ponape)"; > } > enum "Pacific/Port_Moresby" { > value 408; > description > ""; > } > enum "Pacific/Rarotonga" { > value 409; > description > ""; > } > enum "Pacific/Saipan" { > value 410; > description > ""; > } > enum "Pacific/Tahiti" { > value 411; > description > "Society Islands"; > } > enum "Pacific/Tarawa" { > value 412; > description > "Gilbert Islands"; > } > enum "Pacific/Tongatapu" { > value 413; > description > ""; > } > enum "Pacific/Wake" { > value 414; > description > "Wake Island"; > } > enum "Pacific/Wallis" { > value 415; > description > ""; > } > } > } > } > > Jeff Lange > Lead Software Engineer > GE Energy Services > Digital Energy > > T +1 585 242 8375 > F +1 585 241 5590 > Jeffrey.K.Lange@ge.com > www.GEDigitalEnergy.com > > 175 Science Parkway > Rochester, NY 14620 United States > > GE imagination at work > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --e0cb4efe3254ef130504c374577c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'll read it when you publish it as an I-D.
I can change the ietf-s= ystem module after you publish
and the WG agrees to=A0publish you= r module.


Andy


On Wed, Jun 27, 2012 at 6:21 AM, Lange, Jeffrey K (GE Energy) <jeffre= y.K.lange@ge.com> wrote:
As I mentioned earlier, the current free-form timezone-location string in t= he ietf-system module is not very user friendly, and those timezone locatio= n strings are actually an IANA controlled entity. =A0I have created an iana= -timezones module using the timezones and any textual descriptions found in= the zone.tab file found in the Time Zone Data v. 2012c downloaded from the= iana website. This has resulted in an enumeration with 415 values. =A0I ha= ve also modified the ietf-system module to use this new data type.

The data was extracted from the zone.tab file using the following cryptic c= ombination of grep, cat, sort, and awk :-)

grep -h -v "^#" zone.tab |awk '{ printf ("%s ", $3)= ; sep=3D""; for (i=3D4; i<=3DNF; i++) {printf("%s%s"= ,sep,$i); sep=3DOFS}; printf("\n");}' |sort -g |cat -n |awk &= #39;{ printf(" =A0 =A0 =A0enum \"%s\" {\n =A0 =A0 =A0 =A0val= ue %s;\n =A0 =A0 =A0 =A0description\n =A0 =A0 =A0 =A0 =A0\"", $2,= $1); sep=3D""; for (i=3D3; i<=3DNF; i++) {printf("%s%s&q= uot;,sep,$i); sep=3DOFS}; =A0print "\";\n =A0 =A0 =A0}" }= 9;

I pretty much took the header info from the iana-if-type module verbatim, w= ith minor changes to reflect the fact that it is for timezones, so odds are= this would need to be adjusted to be in the correct format.

Not every entry in the enumeration has a description, because not every ent= ry in the zone.tab file has a description. =A0I'm not sure if this woul= d be kosher in an official release or not.

Below is the changes needed for ietf-system:

diff --git a/ietf-system@2012-01-31.yang b/ietf-system@2012-01-31.yang
index dd26ea1..4e7952c 100644
--- a/ietf-system@2012-01-31.yang
+++ b/ietf-system@2012-01-31.yang
@@ -11,6 +11,9 @@ module ietf-system {
=A0 import ietf-netconf-acm {
=A0 =A0 prefix nacm;
=A0 }
+ =A0import iana-timezones {
+ =A0 =A0prefix ianatz;
+ =A0}

=A0 organization "IETF NETMOD (NETCONF Data Modeling Language) Workin= g Group";
=A0 contact
@@ -882,9 +885,9 @@ module ietf-system {
=A0 =A0 =A0 =A0 =A0 "Configure the system timezone information."= ;
=A0 =A0 =A0 =A0 leaf timezone-location {
=A0 =A0 =A0 =A0 =A0 if-feature timezone-location;
- =A0 =A0 =A0 =A0 =A0type string;
+ =A0 =A0 =A0 =A0 =A0type ianatz:iana-timezone;
=A0 =A0 =A0 =A0 =A0 description
- =A0 =A0 =A0 =A0 =A0 =A0"The TZ database location identifier string + =A0 =A0 =A0 =A0 =A0 =A0"The TZ database location enumeration
=A0 =A0 =A0 =A0 =A0 =A0 =A0to use for the system, such as 'Europe/Stoc= kholm'.";
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 leaf timezone-name {



And below is the full text of the iana-timezones.yang file I have created

module iana-timezones {
=A0namespace "urn:ietf:params:xml:ns:yang:iana-timezones";
=A0prefix ianatz;

=A0organization "IANA";
=A0contact
=A0 =A0" =A0 =A0 =A0 =A0Internet Assigned Numbers Authority

=A0 =A0 Postal: ICANN
=A0 =A0 =A0 =A0 =A0 =A0 4676 Admiralty Way, Suite 330
=A0 =A0 =A0 =A0 =A0 =A0 Marina del Rey, CA 90292

=A0 =A0 Tel: =A0 =A0+1 310 823 9358
=A0 =A0 E-Mail: iana&ian= a.org";
=A0description
=A0 =A0"This YANG module defines the iana-timezone typedef, which
=A0 =A0 contains YANG definitions for IANA-registered timezones.

=A0 =A0 This YANG module is maintained by IANA, and reflects the
=A0 =A0 IANA Time Zone Database.
=A0 =A0 (http= ://www.iana.org/time-zones)

=A0 =A0 The latest revision of this YANG module can be obtained from
=A0 =A0 the IANA web site.

=A0 =A0 Copyright (c) 2011 IETF Trust and the persons identified as
=A0 =A0 authors of the code. =A0All rights reserved.

=A0 =A0 Redistribution and use in source and binary forms, with or
=A0 =A0 without modification, is permitted pursuant to, and subject
=A0 =A0 to the license terms contained in, the Simplified BSD License
=A0 =A0 set forth in Section 4.c of the IETF Trust's Legal Provisions<= br> =A0 =A0 Relating to IETF Documents
=A0 =A0 (http://trustee.ietf.org/license-info).

=A0 =A0 This version of this YANG module is part of RFC XXXX; see
=A0 =A0 the RFC itself for full legal notices.";

=A0revision 2012-06-27 {
=A0 =A0description
=A0 =A0 =A0"Initial revision. Using IANA Time Zone Data v. 2012c
=A0 =A0 =A0 (Released 2012-03-27)";
=A0 =A0reference "RFC XXXX: TITLE";
=A0}
=A0typedef iana-timezone {
=A0 =A0type enumeration {
=A0 =A0 =A0enum "Africa/Abidjan" {
=A0 =A0 =A0 =A0value 1;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Accra" {
=A0 =A0 =A0 =A0value 2;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Addis_Ababa" {
=A0 =A0 =A0 =A0value 3;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Algiers" {
=A0 =A0 =A0 =A0value 4;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Asmara" {
=A0 =A0 =A0 =A0value 5;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Bamako" {
=A0 =A0 =A0 =A0value 6;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Bangui" {
=A0 =A0 =A0 =A0value 7;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Banjul" {
=A0 =A0 =A0 =A0value 8;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Bissau" {
=A0 =A0 =A0 =A0value 9;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Blantyre" {
=A0 =A0 =A0 =A0value 10;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Brazzaville" {
=A0 =A0 =A0 =A0value 11;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Bujumbura" {
=A0 =A0 =A0 =A0value 12;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Cairo" {
=A0 =A0 =A0 =A0value 13;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Casablanca" {
=A0 =A0 =A0 =A0value 14;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Ceuta" {
=A0 =A0 =A0 =A0value 15;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Ceuta & Melilla";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Conakry" {
=A0 =A0 =A0 =A0value 16;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Dakar" {
=A0 =A0 =A0 =A0value 17;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Dar_es_Salaam" {
=A0 =A0 =A0 =A0value 18;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Djibouti" {
=A0 =A0 =A0 =A0value 19;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Douala" {
=A0 =A0 =A0 =A0value 20;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/El_Aaiun" {
=A0 =A0 =A0 =A0value 21;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Freetown" {
=A0 =A0 =A0 =A0value 22;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Gaborone" {
=A0 =A0 =A0 =A0value 23;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Harare" {
=A0 =A0 =A0 =A0value 24;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Johannesburg" {
=A0 =A0 =A0 =A0value 25;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Juba" {
=A0 =A0 =A0 =A0value 26;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Kampala" {
=A0 =A0 =A0 =A0value 27;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Khartoum" {
=A0 =A0 =A0 =A0value 28;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Kigali" {
=A0 =A0 =A0 =A0value 29;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Kinshasa" {
=A0 =A0 =A0 =A0value 30;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"west Dem. Rep. of Congo";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Lagos" {
=A0 =A0 =A0 =A0value 31;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Libreville" {
=A0 =A0 =A0 =A0value 32;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Lome" {
=A0 =A0 =A0 =A0value 33;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Luanda" {
=A0 =A0 =A0 =A0value 34;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Lubumbashi" {
=A0 =A0 =A0 =A0value 35;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"east Dem. Rep. of Congo";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Lusaka" {
=A0 =A0 =A0 =A0value 36;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Malabo" {
=A0 =A0 =A0 =A0value 37;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Maputo" {
=A0 =A0 =A0 =A0value 38;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Maseru" {
=A0 =A0 =A0 =A0value 39;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Mbabane" {
=A0 =A0 =A0 =A0value 40;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Mogadishu" {
=A0 =A0 =A0 =A0value 41;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Monrovia" {
=A0 =A0 =A0 =A0value 42;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Nairobi" {
=A0 =A0 =A0 =A0value 43;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Ndjamena" {
=A0 =A0 =A0 =A0value 44;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Niamey" {
=A0 =A0 =A0 =A0value 45;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Nouakchott" {
=A0 =A0 =A0 =A0value 46;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Ouagadougou" {
=A0 =A0 =A0 =A0value 47;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Porto-Novo" {
=A0 =A0 =A0 =A0value 48;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Sao_Tome" {
=A0 =A0 =A0 =A0value 49;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Tripoli" {
=A0 =A0 =A0 =A0value 50;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Tunis" {
=A0 =A0 =A0 =A0value 51;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Africa/Windhoek" {
=A0 =A0 =A0 =A0value 52;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Adak" {
=A0 =A0 =A0 =A0value 53;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Aleutian Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Anchorage" {
=A0 =A0 =A0 =A0value 54;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Alaska Time";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Anguilla" {
=A0 =A0 =A0 =A0value 55;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Antigua" {
=A0 =A0 =A0 =A0value 56;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Araguaina" {
=A0 =A0 =A0 =A0value 57;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Tocantins";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/Buenos_Aires" {
=A0 =A0 =A0 =A0value 58;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Buenos Aires (BA, CF)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/Catamarca" {
=A0 =A0 =A0 =A0value 59;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Catamarca (CT), Chubut (CH)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/Cordoba" {
=A0 =A0 =A0 =A0value 60;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"most locations (CB, CC, CN, ER, FM, MN, SE, SF)&q= uot;;
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/Jujuy" {
=A0 =A0 =A0 =A0value 61;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Jujuy (JY)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/La_Rioja" {
=A0 =A0 =A0 =A0value 62;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"La Rioja (LR)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/Mendoza" {
=A0 =A0 =A0 =A0value 63;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mendoza (MZ)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/Rio_Gallegos" {
=A0 =A0 =A0 =A0value 64;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Santa Cruz (SC)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/Salta" {
=A0 =A0 =A0 =A0value 65;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"(SA, LP, NQ, RN)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/San_Juan" {
=A0 =A0 =A0 =A0value 66;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"San Juan (SJ)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/San_Luis" {
=A0 =A0 =A0 =A0value 67;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"San Luis (SL)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/Tucuman" {
=A0 =A0 =A0 =A0value 68;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Tucuman (TM)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Argentina/Ushuaia" {
=A0 =A0 =A0 =A0value 69;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Tierra del Fuego (TF)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Aruba" {
=A0 =A0 =A0 =A0value 70;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Asuncion" {
=A0 =A0 =A0 =A0value 71;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Atikokan" {
=A0 =A0 =A0 =A0value 72;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Standard Time - Atikokan, Ontario and Sou= thampton I, Nunavut";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Bahia" {
=A0 =A0 =A0 =A0value 73;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Bahia";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Bahia_Banderas" {
=A0 =A0 =A0 =A0value 74;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mexican Central Time - Bahia de Banderas"; =A0 =A0 =A0}
=A0 =A0 =A0enum "America/Barbados" {
=A0 =A0 =A0 =A0value 75;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Belem" {
=A0 =A0 =A0 =A0value 76;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Amapa, E Para";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Belize" {
=A0 =A0 =A0 =A0value 77;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Blanc-Sablon" {
=A0 =A0 =A0 =A0value 78;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Atlantic Standard Time - Quebec - Lower North Sho= re";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Boa_Vista" {
=A0 =A0 =A0 =A0value 79;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Roraima";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Bogota" {
=A0 =A0 =A0 =A0value 80;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Boise" {
=A0 =A0 =A0 =A0value 81;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Time - south Idaho & east Oregon&quo= t;;
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Cambridge_Bay" {
=A0 =A0 =A0 =A0value 82;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Time - west Nunavut";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Campo_Grande" {
=A0 =A0 =A0 =A0value 83;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mato Grosso do Sul";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Cancun" {
=A0 =A0 =A0 =A0value 84;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - Quintana Roo";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Caracas" {
=A0 =A0 =A0 =A0value 85;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Cayenne" {
=A0 =A0 =A0 =A0value 86;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Cayman" {
=A0 =A0 =A0 =A0value 87;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Chicago" {
=A0 =A0 =A0 =A0value 88;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Chihuahua" {
=A0 =A0 =A0 =A0value 89;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mexican Mountain Time - Chihuahua away from US bo= rder";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Costa_Rica" {
=A0 =A0 =A0 =A0value 90;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Creston" {
=A0 =A0 =A0 =A0value 91;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Standard Time - Creston, British Columbi= a";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Cuiaba" {
=A0 =A0 =A0 =A0value 92;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mato Grosso";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Curacao" {
=A0 =A0 =A0 =A0value 93;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Danmarkshavn" {
=A0 =A0 =A0 =A0value 94;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"east coast, north of Scoresbysund";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Dawson_Creek" {
=A0 =A0 =A0 =A0value 95;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Standard Time - Dawson Creek & Fort = Saint John, British Columbia";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Dawson" {
=A0 =A0 =A0 =A0value 96;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Pacific Time - north Yukon";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Denver" {
=A0 =A0 =A0 =A0value 97;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Time";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Detroit" {
=A0 =A0 =A0 =A0value 98;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Michigan - most locations"; =A0 =A0 =A0}
=A0 =A0 =A0enum "America/Dominica" {
=A0 =A0 =A0 =A0value 99;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Edmonton" {
=A0 =A0 =A0 =A0value 100;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Time - Alberta, east British Columbia &a= mp; west Saskatchewan";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Eirunepe" {
=A0 =A0 =A0 =A0value 101;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"W Amazonas";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/El_Salvador" {
=A0 =A0 =A0 =A0value 102;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Fortaleza" {
=A0 =A0 =A0 =A0value 103;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"NE Brazil (MA, PI, CE, RN, PB)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Glace_Bay" {
=A0 =A0 =A0 =A0value 104;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Atlantic Time - Nova Scotia - places that did not= observe DST 1966-1971";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Godthab" {
=A0 =A0 =A0 =A0value 105;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Goose_Bay" {
=A0 =A0 =A0 =A0value 106;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Atlantic Time - Labrador - most locations";<= br> =A0 =A0 =A0}
=A0 =A0 =A0enum "America/Grand_Turk" {
=A0 =A0 =A0 =A0value 107;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Grenada" {
=A0 =A0 =A0 =A0value 108;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Guadeloupe" {
=A0 =A0 =A0 =A0value 109;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Guatemala" {
=A0 =A0 =A0 =A0value 110;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Guayaquil" {
=A0 =A0 =A0 =A0value 111;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"mainland";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Guyana" {
=A0 =A0 =A0 =A0value 112;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Halifax" {
=A0 =A0 =A0 =A0value 113;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Atlantic Time - Nova Scotia (most places), PEI&qu= ot;;
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Havana" {
=A0 =A0 =A0 =A0value 114;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Hermosillo" {
=A0 =A0 =A0 =A0value 115;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Standard Time - Sonora";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Indiana/Indianapolis" {
=A0 =A0 =A0 =A0value 116;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Indiana - most locations"; =A0 =A0 =A0}
=A0 =A0 =A0enum "America/Indiana/Knox" {
=A0 =A0 =A0 =A0value 117;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - Indiana - Starke County";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Indiana/Marengo" {
=A0 =A0 =A0 =A0value 118;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Indiana - Crawford County"; =A0 =A0 =A0}
=A0 =A0 =A0enum "America/Indiana/Petersburg" {
=A0 =A0 =A0 =A0value 119;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Indiana - Pike County";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Indiana/Tell_City" {
=A0 =A0 =A0 =A0value 120;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - Indiana - Perry County";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Indiana/Vevay" {
=A0 =A0 =A0 =A0value 121;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Indiana - Switzerland County"= ;
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Indiana/Vincennes" {
=A0 =A0 =A0 =A0value 122;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Indiana - Daviess, Dubois, Knox &a= mp; Martin Counties";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Indiana/Winamac" {
=A0 =A0 =A0 =A0value 123;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Indiana - Pulaski County"; =A0 =A0 =A0}
=A0 =A0 =A0enum "America/Inuvik" {
=A0 =A0 =A0 =A0value 124;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Time - west Northwest Territories";=
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Iqaluit" {
=A0 =A0 =A0 =A0value 125;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - east Nunavut - most locations"= ;;
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Jamaica" {
=A0 =A0 =A0 =A0value 126;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Juneau" {
=A0 =A0 =A0 =A0value 127;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Alaska Time - Alaska panhandle";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Kentucky/Louisville" {
=A0 =A0 =A0 =A0value 128;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Kentucky - Louisville area";<= br> =A0 =A0 =A0}
=A0 =A0 =A0enum "America/Kentucky/Monticello" {
=A0 =A0 =A0 =A0value 129;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Kentucky - Wayne County";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Kralendijk" {
=A0 =A0 =A0 =A0value 130;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/La_Paz" {
=A0 =A0 =A0 =A0value 131;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Lima" {
=A0 =A0 =A0 =A0value 132;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Los_Angeles" {
=A0 =A0 =A0 =A0value 133;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Pacific Time";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Lower_Princes" {
=A0 =A0 =A0 =A0value 134;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Maceio" {
=A0 =A0 =A0 =A0value 135;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Alagoas, Sergipe";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Managua" {
=A0 =A0 =A0 =A0value 136;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Manaus" {
=A0 =A0 =A0 =A0value 137;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"E Amazonas";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Marigot" {
=A0 =A0 =A0 =A0value 138;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Martinique" {
=A0 =A0 =A0 =A0value 139;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Matamoros" {
=A0 =A0 =A0 =A0value 140;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"US Central Time - Coahuila, Durango, Nuevo Leon, = Tamaulipas near US border";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Mazatlan" {
=A0 =A0 =A0 =A0value 141;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Time - S Baja, Nayarit, Sinaloa"; =A0 =A0 =A0}
=A0 =A0 =A0enum "America/Menominee" {
=A0 =A0 =A0 =A0value 142;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - Michigan - Dickinson, Gogebic, Iro= n & Menominee Counties";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Merida" {
=A0 =A0 =A0 =A0value 143;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - Campeche, Yucatan";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Metlakatla" {
=A0 =A0 =A0 =A0value 144;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Metlakatla Time - Annette Island";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Mexico_City" {
=A0 =A0 =A0 =A0value 145;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Miquelon" {
=A0 =A0 =A0 =A0value 146;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Moncton" {
=A0 =A0 =A0 =A0value 147;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Atlantic Time - New Brunswick";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Monterrey" {
=A0 =A0 =A0 =A0value 148;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mexican Central Time - Coahuila, Durango, Nuevo L= eon, Tamaulipas away from US border";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Montevideo" {
=A0 =A0 =A0 =A0value 149;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Montreal" {
=A0 =A0 =A0 =A0value 150;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Quebec - most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Montserrat" {
=A0 =A0 =A0 =A0value 151;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Nassau" {
=A0 =A0 =A0 =A0value 152;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/New_York" {
=A0 =A0 =A0 =A0value 153;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Nipigon" {
=A0 =A0 =A0 =A0value 154;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Ontario & Quebec - places that= did not observe DST 1967-1973";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Nome" {
=A0 =A0 =A0 =A0value 155;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Alaska Time - west Alaska";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Noronha" {
=A0 =A0 =A0 =A0value 156;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Atlantic islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/North_Dakota/Beulah" {
=A0 =A0 =A0 =A0value 157;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - North Dakota - Mercer County"= ;
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/North_Dakota/Center" {
=A0 =A0 =A0 =A0value 158;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - North Dakota - Oliver County"= ;
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/North_Dakota/New_Salem" {
=A0 =A0 =A0 =A0value 159;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - North Dakota - Morton County (exce= pt Mandan area)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Ojinaga" {
=A0 =A0 =A0 =A0value 160;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"US Mountain Time - Chihuahua near US border"= ;
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Panama" {
=A0 =A0 =A0 =A0value 161;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Pangnirtung" {
=A0 =A0 =A0 =A0value 162;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Pangnirtung, Nunavut";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Paramaribo" {
=A0 =A0 =A0 =A0value 163;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Phoenix" {
=A0 =A0 =A0 =A0value 164;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Standard Time - Arizona";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Port-au-Prince" {
=A0 =A0 =A0 =A0value 165;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Port_of_Spain" {
=A0 =A0 =A0 =A0value 166;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Porto_Velho" {
=A0 =A0 =A0 =A0value 167;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Rondonia";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Puerto_Rico" {
=A0 =A0 =A0 =A0value 168;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Rainy_River" {
=A0 =A0 =A0 =A0value 169;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - Rainy River & Fort Frances, On= tario";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Rankin_Inlet" {
=A0 =A0 =A0 =A0value 170;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - central Nunavut";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Recife" {
=A0 =A0 =A0 =A0value 171;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Pernambuco";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Regina" {
=A0 =A0 =A0 =A0value 172;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Standard Time - Saskatchewan - most locat= ions";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Resolute" {
=A0 =A0 =A0 =A0value 173;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Standard Time - Resolute, Nunavut";<= br> =A0 =A0 =A0}
=A0 =A0 =A0enum "America/Rio_Branco" {
=A0 =A0 =A0 =A0value 174;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Acre";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Santa_Isabel" {
=A0 =A0 =A0 =A0value 175;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mexican Pacific Time - Baja California away from = US border";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Santarem" {
=A0 =A0 =A0 =A0value 176;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"W Para";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Santiago" {
=A0 =A0 =A0 =A0value 177;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Santo_Domingo" {
=A0 =A0 =A0 =A0value 178;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Sao_Paulo" {
=A0 =A0 =A0 =A0value 179;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"S & SE Brazil (GO, DF, MG, ES, RJ, SP, PR, SC= , RS)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Scoresbysund" {
=A0 =A0 =A0 =A0value 180;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Scoresbysund / Ittoqqortoormiit";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Shiprock" {
=A0 =A0 =A0 =A0value 181;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Time - Navajo";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Sitka" {
=A0 =A0 =A0 =A0value 182;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Alaska Time - southeast Alaska panhandle"; =A0 =A0 =A0}
=A0 =A0 =A0enum "America/St_Barthelemy" {
=A0 =A0 =A0 =A0value 183;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/St_Johns" {
=A0 =A0 =A0 =A0value 184;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Newfoundland Time, including SE Labrador"; =A0 =A0 =A0}
=A0 =A0 =A0enum "America/St_Kitts" {
=A0 =A0 =A0 =A0value 185;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/St_Lucia" {
=A0 =A0 =A0 =A0value 186;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/St_Thomas" {
=A0 =A0 =A0 =A0value 187;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/St_Vincent" {
=A0 =A0 =A0 =A0value 188;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Swift_Current" {
=A0 =A0 =A0 =A0value 189;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Standard Time - Saskatchewan - midwest&qu= ot;;
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Tegucigalpa" {
=A0 =A0 =A0 =A0value 190;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Thule" {
=A0 =A0 =A0 =A0value 191;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Thule / Pituffik";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Thunder_Bay" {
=A0 =A0 =A0 =A0value 192;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Thunder Bay, Ontario";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Tijuana" {
=A0 =A0 =A0 =A0value 193;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"US Pacific Time - Baja California near US border&= quot;;
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Toronto" {
=A0 =A0 =A0 =A0value 194;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Eastern Time - Ontario - most locations"; =A0 =A0 =A0}
=A0 =A0 =A0enum "America/Tortola" {
=A0 =A0 =A0 =A0value 195;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Vancouver" {
=A0 =A0 =A0 =A0value 196;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Pacific Time - west British Columbia";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Whitehorse" {
=A0 =A0 =A0 =A0value 197;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Pacific Time - south Yukon";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Winnipeg" {
=A0 =A0 =A0 =A0value 198;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Central Time - Manitoba & west Ontario";=
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Yakutat" {
=A0 =A0 =A0 =A0value 199;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Alaska Time - Alaska panhandle neck";
=A0 =A0 =A0}
=A0 =A0 =A0enum "America/Yellowknife" {
=A0 =A0 =A0 =A0value 200;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mountain Time - central Northwest Territories&quo= t;;
=A0 =A0 =A0}
=A0 =A0 =A0enum "Antarctica/Casey" {
=A0 =A0 =A0 =A0value 201;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Casey Station, Bailey Peninsula";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Antarctica/Davis" {
=A0 =A0 =A0 =A0value 202;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Davis Station, Vestfold Hills";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Antarctica/DumontDUrville" {
=A0 =A0 =A0 =A0value 203;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Dumont-d'Urville Station, Terre Adelie";=
=A0 =A0 =A0}
=A0 =A0 =A0enum "Antarctica/Macquarie" {
=A0 =A0 =A0 =A0value 204;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Macquarie Island Station, Macquarie Island";=
=A0 =A0 =A0}
=A0 =A0 =A0enum "Antarctica/Mawson" {
=A0 =A0 =A0 =A0value 205;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Mawson Station, Holme Bay";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Antarctica/McMurdo" {
=A0 =A0 =A0 =A0value 206;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"McMurdo Station, Ross Island";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Antarctica/Palmer" {
=A0 =A0 =A0 =A0value 207;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Palmer Station, Anvers Island";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Antarctica/Rothera" {
=A0 =A0 =A0 =A0value 208;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Rothera Station, Adelaide Island";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Antarctica/South_Pole" {
=A0 =A0 =A0 =A0value 209;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Amundsen-Scott Station, South Pole";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Antarctica/Syowa" {
=A0 =A0 =A0 =A0value 210;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Syowa Station, E Ongul I";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Antarctica/Vostok" {
=A0 =A0 =A0 =A0value 211;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Vostok Station, Lake Vostok";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Arctic/Longyearbyen" {
=A0 =A0 =A0 =A0value 212;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Aden" {
=A0 =A0 =A0 =A0value 213;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Almaty" {
=A0 =A0 =A0 =A0value 214;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Amman" {
=A0 =A0 =A0 =A0value 215;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Anadyr" {
=A0 =A0 =A0 =A0value 216;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+08 - Bering Sea";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Aqtau" {
=A0 =A0 =A0 =A0value 217;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Atyrau (Atirau, Gur'yev), Mangghystau (Mankis= tau)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Aqtobe" {
=A0 =A0 =A0 =A0value 218;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Aqtobe (Aktobe)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Ashgabat" {
=A0 =A0 =A0 =A0value 219;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Baghdad" {
=A0 =A0 =A0 =A0value 220;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Bahrain" {
=A0 =A0 =A0 =A0value 221;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Baku" {
=A0 =A0 =A0 =A0value 222;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Bangkok" {
=A0 =A0 =A0 =A0value 223;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Beirut" {
=A0 =A0 =A0 =A0value 224;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Bishkek" {
=A0 =A0 =A0 =A0value 225;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Brunei" {
=A0 =A0 =A0 =A0value 226;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Choibalsan" {
=A0 =A0 =A0 =A0value 227;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Dornod, Sukhbaatar";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Chongqing" {
=A0 =A0 =A0 =A0value 228;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"central China - Sichuan, Yunnan, Guangxi, Shaanxi= , Guizhou, etc.";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Colombo" {
=A0 =A0 =A0 =A0value 229;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Damascus" {
=A0 =A0 =A0 =A0value 230;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Dhaka" {
=A0 =A0 =A0 =A0value 231;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Dili" {
=A0 =A0 =A0 =A0value 232;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Dubai" {
=A0 =A0 =A0 =A0value 233;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Dushanbe" {
=A0 =A0 =A0 =A0value 234;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Gaza" {
=A0 =A0 =A0 =A0value 235;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Gaza Strip";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Harbin" {
=A0 =A0 =A0 =A0value 236;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Heilongjiang (except Mohe), Jilin";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Hebron" {
=A0 =A0 =A0 =A0value 237;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"West Bank";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Ho_Chi_Minh" {
=A0 =A0 =A0 =A0value 238;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Hong_Kong" {
=A0 =A0 =A0 =A0value 239;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Hovd" {
=A0 =A0 =A0 =A0value 240;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Bayan-Olgiy, Govi-Altai, Hovd, Uvs, Zavkhan"= ;
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Irkutsk" {
=A0 =A0 =A0 =A0value 241;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+05 - Lake Baikal";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Jakarta" {
=A0 =A0 =A0 =A0value 242;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Java & Sumatra";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Jayapura" {
=A0 =A0 =A0 =A0value 243;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"west New Guinea (Irian Jaya) & Malukus (Moluc= cas)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Jerusalem" {
=A0 =A0 =A0 =A0value 244;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Kabul" {
=A0 =A0 =A0 =A0value 245;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Kamchatka" {
=A0 =A0 =A0 =A0value 246;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+08 - Kamchatka";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Karachi" {
=A0 =A0 =A0 =A0value 247;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Kashgar" {
=A0 =A0 =A0 =A0value 248;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"west Tibet & Xinjiang";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Kathmandu" {
=A0 =A0 =A0 =A0value 249;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Kolkata" {
=A0 =A0 =A0 =A0value 250;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Krasnoyarsk" {
=A0 =A0 =A0 =A0value 251;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+04 - Yenisei River";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Kuala_Lumpur" {
=A0 =A0 =A0 =A0value 252;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"peninsular Malaysia";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Kuching" {
=A0 =A0 =A0 =A0value 253;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Sabah & Sarawak";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Kuwait" {
=A0 =A0 =A0 =A0value 254;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Macau" {
=A0 =A0 =A0 =A0value 255;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Magadan" {
=A0 =A0 =A0 =A0value 256;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+08 - Magadan";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Makassar" {
=A0 =A0 =A0 =A0value 257;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"east & south Borneo, Sulawesi (Celebes), Bali= , Nusa Tengarra, west Timor";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Manila" {
=A0 =A0 =A0 =A0value 258;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Muscat" {
=A0 =A0 =A0 =A0value 259;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Nicosia" {
=A0 =A0 =A0 =A0value 260;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Novokuznetsk" {
=A0 =A0 =A0 =A0value 261;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+03 - Novokuznetsk";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Novosibirsk" {
=A0 =A0 =A0 =A0value 262;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+03 - Novosibirsk";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Omsk" {
=A0 =A0 =A0 =A0value 263;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+03 - west Siberia";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Oral" {
=A0 =A0 =A0 =A0value 264;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"West Kazakhstan";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Phnom_Penh" {
=A0 =A0 =A0 =A0value 265;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Pontianak" {
=A0 =A0 =A0 =A0value 266;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"west & central Borneo";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Pyongyang" {
=A0 =A0 =A0 =A0value 267;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Qatar" {
=A0 =A0 =A0 =A0value 268;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Qyzylorda" {
=A0 =A0 =A0 =A0value 269;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Qyzylorda (Kyzylorda, Kzyl-Orda)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Rangoon" {
=A0 =A0 =A0 =A0value 270;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Riyadh" {
=A0 =A0 =A0 =A0value 271;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Sakhalin" {
=A0 =A0 =A0 =A0value 272;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+07 - Sakhalin Island";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Samarkand" {
=A0 =A0 =A0 =A0value 273;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"west Uzbekistan";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Seoul" {
=A0 =A0 =A0 =A0value 274;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Shanghai" {
=A0 =A0 =A0 =A0value 275;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"east China - Beijing, Guangdong, Shanghai, etc.&q= uot;;
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Singapore" {
=A0 =A0 =A0 =A0value 276;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Taipei" {
=A0 =A0 =A0 =A0value 277;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Tashkent" {
=A0 =A0 =A0 =A0value 278;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"east Uzbekistan";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Tbilisi" {
=A0 =A0 =A0 =A0value 279;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Tehran" {
=A0 =A0 =A0 =A0value 280;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Thimphu" {
=A0 =A0 =A0 =A0value 281;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Tokyo" {
=A0 =A0 =A0 =A0value 282;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Ulaanbaatar" {
=A0 =A0 =A0 =A0value 283;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Urumqi" {
=A0 =A0 =A0 =A0value 284;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"most of Tibet & Xinjiang";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Vientiane" {
=A0 =A0 =A0 =A0value 285;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Vladivostok" {
=A0 =A0 =A0 =A0value 286;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+07 - Amur River";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Yakutsk" {
=A0 =A0 =A0 =A0value 287;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+06 - Lena River";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Yekaterinburg" {
=A0 =A0 =A0 =A0value 288;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+02 - Urals";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Asia/Yerevan" {
=A0 =A0 =A0 =A0value 289;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Atlantic/Azores" {
=A0 =A0 =A0 =A0value 290;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Azores";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Atlantic/Bermuda" {
=A0 =A0 =A0 =A0value 291;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Atlantic/Canary" {
=A0 =A0 =A0 =A0value 292;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Canary Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Atlantic/Cape_Verde" {
=A0 =A0 =A0 =A0value 293;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Atlantic/Faroe" {
=A0 =A0 =A0 =A0value 294;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Atlantic/Madeira" {
=A0 =A0 =A0 =A0value 295;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Madeira Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Atlantic/Reykjavik" {
=A0 =A0 =A0 =A0value 296;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Atlantic/South_Georgia" {
=A0 =A0 =A0 =A0value 297;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Atlantic/Stanley" {
=A0 =A0 =A0 =A0value 298;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Atlantic/St_Helena" {
=A0 =A0 =A0 =A0value 299;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Adelaide" {
=A0 =A0 =A0 =A0value 300;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"South Australia";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Brisbane" {
=A0 =A0 =A0 =A0value 301;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Queensland - most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Broken_Hill" {
=A0 =A0 =A0 =A0value 302;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"New South Wales - Yancowinna";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Currie" {
=A0 =A0 =A0 =A0value 303;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Tasmania - King Island";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Darwin" {
=A0 =A0 =A0 =A0value 304;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Northern Territory";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Eucla" {
=A0 =A0 =A0 =A0value 305;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Western Australia - Eucla area";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Hobart" {
=A0 =A0 =A0 =A0value 306;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Tasmania - most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Lindeman" {
=A0 =A0 =A0 =A0value 307;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Queensland - Holiday Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Lord_Howe" {
=A0 =A0 =A0 =A0value 308;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Lord Howe Island";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Melbourne" {
=A0 =A0 =A0 =A0value 309;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Victoria";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Perth" {
=A0 =A0 =A0 =A0value 310;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Western Australia - most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Australia/Sydney" {
=A0 =A0 =A0 =A0value 311;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"New South Wales - most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Amsterdam" {
=A0 =A0 =A0 =A0value 312;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Andorra" {
=A0 =A0 =A0 =A0value 313;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Athens" {
=A0 =A0 =A0 =A0value 314;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Belgrade" {
=A0 =A0 =A0 =A0value 315;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Berlin" {
=A0 =A0 =A0 =A0value 316;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Bratislava" {
=A0 =A0 =A0 =A0value 317;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Brussels" {
=A0 =A0 =A0 =A0value 318;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Bucharest" {
=A0 =A0 =A0 =A0value 319;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Budapest" {
=A0 =A0 =A0 =A0value 320;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Chisinau" {
=A0 =A0 =A0 =A0value 321;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Copenhagen" {
=A0 =A0 =A0 =A0value 322;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Dublin" {
=A0 =A0 =A0 =A0value 323;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Gibraltar" {
=A0 =A0 =A0 =A0value 324;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Guernsey" {
=A0 =A0 =A0 =A0value 325;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Helsinki" {
=A0 =A0 =A0 =A0value 326;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Isle_of_Man" {
=A0 =A0 =A0 =A0value 327;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Istanbul" {
=A0 =A0 =A0 =A0value 328;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Jersey" {
=A0 =A0 =A0 =A0value 329;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Kaliningrad" {
=A0 =A0 =A0 =A0value 330;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow-01 - Kaliningrad";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Kiev" {
=A0 =A0 =A0 =A0value 331;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Lisbon" {
=A0 =A0 =A0 =A0value 332;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"mainland";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Ljubljana" {
=A0 =A0 =A0 =A0value 333;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/London" {
=A0 =A0 =A0 =A0value 334;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Luxembourg" {
=A0 =A0 =A0 =A0value 335;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Madrid" {
=A0 =A0 =A0 =A0value 336;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"mainland";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Malta" {
=A0 =A0 =A0 =A0value 337;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Mariehamn" {
=A0 =A0 =A0 =A0value 338;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Minsk" {
=A0 =A0 =A0 =A0value 339;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Monaco" {
=A0 =A0 =A0 =A0value 340;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Moscow" {
=A0 =A0 =A0 =A0value 341;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+00 - west Russia";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Oslo" {
=A0 =A0 =A0 =A0value 342;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Paris" {
=A0 =A0 =A0 =A0value 343;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Podgorica" {
=A0 =A0 =A0 =A0value 344;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Prague" {
=A0 =A0 =A0 =A0value 345;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Riga" {
=A0 =A0 =A0 =A0value 346;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Rome" {
=A0 =A0 =A0 =A0value 347;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Samara" {
=A0 =A0 =A0 =A0value 348;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+00 - Samara, Udmurtia";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/San_Marino" {
=A0 =A0 =A0 =A0value 349;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Sarajevo" {
=A0 =A0 =A0 =A0value 350;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Simferopol" {
=A0 =A0 =A0 =A0value 351;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"central Crimea";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Skopje" {
=A0 =A0 =A0 =A0value 352;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Sofia" {
=A0 =A0 =A0 =A0value 353;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Stockholm" {
=A0 =A0 =A0 =A0value 354;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Tallinn" {
=A0 =A0 =A0 =A0value 355;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Tirane" {
=A0 =A0 =A0 =A0value 356;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Uzhgorod" {
=A0 =A0 =A0 =A0value 357;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Ruthenia";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Vaduz" {
=A0 =A0 =A0 =A0value 358;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Vatican" {
=A0 =A0 =A0 =A0value 359;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Vienna" {
=A0 =A0 =A0 =A0value 360;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Vilnius" {
=A0 =A0 =A0 =A0value 361;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Volgograd" {
=A0 =A0 =A0 =A0value 362;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Moscow+00 - Caspian Sea";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Warsaw" {
=A0 =A0 =A0 =A0value 363;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Zagreb" {
=A0 =A0 =A0 =A0value 364;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Zaporozhye" {
=A0 =A0 =A0 =A0value 365;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Zaporozh'ye, E Lugansk / Zaporizhia, E Luhans= k";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Europe/Zurich" {
=A0 =A0 =A0 =A0value 366;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Indian/Antananarivo" {
=A0 =A0 =A0 =A0value 367;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Indian/Chagos" {
=A0 =A0 =A0 =A0value 368;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Indian/Christmas" {
=A0 =A0 =A0 =A0value 369;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Indian/Cocos" {
=A0 =A0 =A0 =A0value 370;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Indian/Comoro" {
=A0 =A0 =A0 =A0value 371;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Indian/Kerguelen" {
=A0 =A0 =A0 =A0value 372;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Indian/Mahe" {
=A0 =A0 =A0 =A0value 373;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Indian/Maldives" {
=A0 =A0 =A0 =A0value 374;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Indian/Mauritius" {
=A0 =A0 =A0 =A0value 375;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Indian/Mayotte" {
=A0 =A0 =A0 =A0value 376;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Indian/Reunion" {
=A0 =A0 =A0 =A0value 377;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Apia" {
=A0 =A0 =A0 =A0value 378;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Auckland" {
=A0 =A0 =A0 =A0value 379;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Chatham" {
=A0 =A0 =A0 =A0value 380;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Chatham Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Chuuk" {
=A0 =A0 =A0 =A0value 381;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Chuuk (Truk) and Yap";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Easter" {
=A0 =A0 =A0 =A0value 382;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Easter Island & Sala y Gomez";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Efate" {
=A0 =A0 =A0 =A0value 383;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Enderbury" {
=A0 =A0 =A0 =A0value 384;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Phoenix Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Fakaofo" {
=A0 =A0 =A0 =A0value 385;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Fiji" {
=A0 =A0 =A0 =A0value 386;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Funafuti" {
=A0 =A0 =A0 =A0value 387;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Galapagos" {
=A0 =A0 =A0 =A0value 388;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Galapagos Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Gambier" {
=A0 =A0 =A0 =A0value 389;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Gambier Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Guadalcanal" {
=A0 =A0 =A0 =A0value 390;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Guam" {
=A0 =A0 =A0 =A0value 391;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Honolulu" {
=A0 =A0 =A0 =A0value 392;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Hawaii";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Johnston" {
=A0 =A0 =A0 =A0value 393;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Johnston Atoll";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Kiritimati" {
=A0 =A0 =A0 =A0value 394;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Line Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Kosrae" {
=A0 =A0 =A0 =A0value 395;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Kosrae";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Kwajalein" {
=A0 =A0 =A0 =A0value 396;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Kwajalein";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Majuro" {
=A0 =A0 =A0 =A0value 397;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"most locations";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Marquesas" {
=A0 =A0 =A0 =A0value 398;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Marquesas Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Midway" {
=A0 =A0 =A0 =A0value 399;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Midway Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Nauru" {
=A0 =A0 =A0 =A0value 400;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Niue" {
=A0 =A0 =A0 =A0value 401;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Norfolk" {
=A0 =A0 =A0 =A0value 402;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Noumea" {
=A0 =A0 =A0 =A0value 403;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Pago_Pago" {
=A0 =A0 =A0 =A0value 404;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Palau" {
=A0 =A0 =A0 =A0value 405;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Pitcairn" {
=A0 =A0 =A0 =A0value 406;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Pohnpei" {
=A0 =A0 =A0 =A0value 407;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Pohnpei (Ponape)";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Port_Moresby" {
=A0 =A0 =A0 =A0value 408;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Rarotonga" {
=A0 =A0 =A0 =A0value 409;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Saipan" {
=A0 =A0 =A0 =A0value 410;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Tahiti" {
=A0 =A0 =A0 =A0value 411;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Society Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Tarawa" {
=A0 =A0 =A0 =A0value 412;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Gilbert Islands";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Tongatapu" {
=A0 =A0 =A0 =A0value 413;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Wake" {
=A0 =A0 =A0 =A0value 414;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"Wake Island";
=A0 =A0 =A0}
=A0 =A0 =A0enum "Pacific/Wallis" {
=A0 =A0 =A0 =A0value 415;
=A0 =A0 =A0 =A0description
=A0 =A0 =A0 =A0 =A0"";
=A0 =A0 =A0}
=A0 =A0}
=A0}
}

Jeff Lange
Lead Software Engineer
GE Energy Services
Digital Energy

T=A0+1 585 242 8375
F=A0+1 585 241 5590
Jeffrey.K.Lange@ge.com
www.GEDigitalE= nergy.com

175 Science Parkway
Rochester,=A0NY=A014620=A0United States

GE imagination at work


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

--e0cb4efe3254ef130504c374577c-- From jeffrey.K.lange@ge.com Wed Jun 27 06:55:04 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE6E21F876D for ; Wed, 27 Jun 2012 06:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.078 X-Spam-Level: X-Spam-Status: No, score=-6.078 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp3X-oxLC13n for ; Wed, 27 Jun 2012 06:55:03 -0700 (PDT) Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by ietfa.amsl.com (Postfix) with ESMTP id E905021F8757 for ; Wed, 27 Jun 2012 06:55:02 -0700 (PDT) Received: from alpmlip11.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKT+sQtjF6hyaJjqrVhlSqr4ve4tRsSb2Y@postini.com; Wed, 27 Jun 2012 06:55:03 PDT Received: from unknown (HELO cinmlef06.e2k.ad.ge.com) ([3.159.213.37]) by alpmlip11.e2k.ad.ge.com with ESMTP; 27 Jun 2012 09:54:58 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef06.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 09:54:58 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 09:54:58 -0400 Received: from CINMBCNA06.e2k.ad.ge.com (3.159.212.61) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 27 Jun 2012 09:54:57 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA06.e2k.ad.ge.com ([169.254.6.116]) with mapi id 14.02.0283.003; Wed, 27 Jun 2012 09:54:57 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Andy Bierman Thread-Topic: [netmod] iana-timezones.yang proposal Thread-Index: Ac1UZ5zKdi90QqprQ+qLElq9kCvf9QAJC5qAAAfwbrA= Date: Wed, 27 Jun 2012 13:54:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA68FFCINMBCNA02e2kad_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2012 13:54:58.0246 (UTC) FILETIME=[7064AE60:01CD546C] Cc: "netmod@ietf.org" Subject: Re: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 13:55:04 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA68FFCINMBCNA02e2kad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I'll read it when you publish it as an I-D. > I can change the ietf-system module after you publish > and the WG agrees to publish your module. > > Andy Pardon my ignorance on this one, but how does one go about creating an I-D = for this? as I'm not a member of the working group would I even be able to= do this? -Jeff --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA68FFCINMBCNA02e2kad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> I'll read = it when you publish it as an I-D.

> I can chan= ge the ietf-system module after you publish

> and the WG= agrees to publish your module.

> <= /span>

> Andy<= /o:p>

 

 <= /p>

Pardon my ignorance on th= is one, but how does one go about creating an I-D for this?  as I̵= 7;m not a member of the working group would I even be able to do this?=

-Jeff

 

--_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA68FFCINMBCNA02e2kad_-- From j.schoenwaelder@jacobs-university.de Wed Jun 27 07:00:48 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8528D21F877A for ; Wed, 27 Jun 2012 07:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJVsbaj-vqB7 for ; Wed, 27 Jun 2012 07:00:48 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5D24221F8779 for ; Wed, 27 Jun 2012 07:00:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC6C420C37; Wed, 27 Jun 2012 16:00:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XS6V0roSYgs8; Wed, 27 Jun 2012 16:00:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 018F220C2F; Wed, 27 Jun 2012 16:00:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9C1B0202D03D; Wed, 27 Jun 2012 16:00:41 +0200 (CEST) Date: Wed, 27 Jun 2012 16:00:41 +0200 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy)" Message-ID: <20120627140041.GB51402@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy)" , Andy Bierman , "netmod@ietf.org" References: 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] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 14:00:48 -0000 On Wed, Jun 27, 2012 at 01:54:56PM +0000, Lange, Jeffrey K (GE Energy) wrote: > > I'll read it when you publish it as an I-D. > > I can change the ietf-system module after you publish > > and the WG agrees to publish your module. > > > > Andy > > > Pardon my ignorance on this one, but how does one go about creating an I-D for this? as I'm not a member of the working group would I even be able to do this? The procedure is rather simple. You post an individual I-D, say draft-lange-netmod-iana-timezone-00.txt, and if the WG supports it, the I-D might become a WG document (and then the name changes to draft-ietf-netmod-iana-timezone-00.txt or something like that). One critical part in this case will be the IANA Considerations section since IANA would be in charge to keep the YANG module updated whenever they change the timezone database and that needs to be clearly explained such that IANA can do the job. /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 Jun 27 07:58:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8043921F871E for ; Wed, 27 Jun 2012 07:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbSaGbb4C6Id for ; Wed, 27 Jun 2012 07:57:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD1521F871D for ; Wed, 27 Jun 2012 07:57:59 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1864023lbb.31 for ; Wed, 27 Jun 2012 07:57:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=FZBdzw3XLuEETm3IXwNjQTcxZFghYAKqhuZrmAYxs0s=; b=lIbqqzlEQMCZsW0ezObOVkFB4up8wb/5tG+JLD0ul78QTGzmxarL5MBkHbqJa9GItd 7iXJpm/F8+iQVuy7/5z99W7EvhuXMuzFpdTJMOvmMFED4h9JNcHnftEjsIY7wyN6cCbw qFEbPsjwWwuvnET7ZrAzf6MIcDIG4/RwK/jILFl+fDgdQTPnW6lMf8J/IU3Y6nrEMo2r NH9yh/PC5iZnl6ODSbAZ9ursUTbBdfy2WPPepQi7iw8/U2V1QFBRoanCrjmERMHylWDM prMt6lQ01Y23OneXAZaBsWWJVdZfP7h5Naa968hMt8J1lyLgEBpUa+a8O3qqw5lNqt3t sggA== MIME-Version: 1.0 Received: by 10.112.86.132 with SMTP id p4mr9471504lbz.22.1340809078319; Wed, 27 Jun 2012 07:57:58 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 27 Jun 2012 07:57:58 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120627140041.GB51402@elstar.local> References: <20120627140041.GB51402@elstar.local> Date: Wed, 27 Jun 2012 07:57:58 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Lange, Jeffrey K (GE Energy)" , Andy Bierman , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=bcaec554d522d32d6e04c3757065 X-Gm-Message-State: ALoCoQm7cT+xT4A2MP6LCCph3EnicyA1OsDahhZtXXL0gHi44cVd72eiE++9ELVKtFT4sxi9uy36 Subject: Re: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 14:58:00 -0000 --bcaec554d522d32d6e04c3757065 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 7:00 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jun 27, 2012 at 01:54:56PM +0000, Lange, Jeffrey K (GE Energy) > wrote: > > > I'll read it when you publish it as an I-D. > > > I can change the ietf-system module after you publish > > > and the WG agrees to publish your module. > > > > > > Andy > > > > > > Pardon my ignorance on this one, but how does one go about creating an > I-D for this? as I'm not a member of the working group would I even be > able to do this? > > The procedure is rather simple. You post an individual I-D, say > draft-lange-netmod-iana-timezone-00.txt, and if the WG supports it, > the I-D might become a WG document (and then the name changes to > draft-ietf-netmod-iana-timezone-00.txt or something like that). One > critical part in this case will be the IANA Considerations section > since IANA would be in charge to keep the YANG module updated whenever > they change the timezone database and that needs to be clearly > explained such that IANA can do the job. > My concerns are with the IANA duplication. I prefer to keep the ietf-system YANG module decoupled from changes in timezones throughout the world. Using an enumeration means that vendors have to ship a specific version of the timezones YANG module with each server. When the IANA registry is updated, the iana-*.yang file has to be updated, and a new RFC published. After that, vendors hopefully will update their YANG modules to the latest version, and new products will have the updated version as they are released. The vendor has to know exactly what version of the YANG module to advertise, based on the tzdata library that is installed. This seems difficult to maintain. The code is likely to be updated faster than the YANG modules can be re-deployed. If the YANG module does not match what the code actually supports, then it is not helping, it just making things worse. > /js > > Andy --bcaec554d522d32d6e04c3757065 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 7:00 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 27, 2012 at 01:54:56PM +0000, La= nge, Jeffrey K (GE Energy) wrote:
> > I'll read it when you publish it as an I-D.
> > I can change the ietf-system module after you publish
> > and the WG agrees to publish your module.
> >
> > Andy
>
>
> Pardon my ignorance on this one, but how does one go about creating an= I-D for this? =A0as I'm not a member of the working group would I even= be able to do this?

The procedure is rather simple. You post an individual I-D, say
draft-lange-netmod-iana-timezone-00.txt, and if the WG supports it,
the I-D might become a WG document (and then the name changes to
draft-ietf-netmod-iana-timezone-00.txt or something like that). =A0One
critical part in this case will be the IANA Considerations section
since IANA would be in charge to keep the YANG module updated whenever
they change the timezone database and that needs to be clearly
explained such that IANA can do the job.

My concerns are with the IANA duplication.

means that vendors have to ship a specific version of the
ti= mezones YANG module with each server.

When the IAN= A registry is updated, the iana-*.yang file has to be updated,=A0
and a new RFC published. =A0After that, vendors hopefully will update their=
of the YANG module to advertise, based on the tzdata library that is i= nstalled.
This seems difficult to maintain.

<= div>The code is likely to be updated faster than the YANG modules can be re= -deployed.
If the YANG module does not match what the code actually supports, the= n
it is not helping, it just making things worse.

<= /div>


/js


Andy
=A0
=
--bcaec554d522d32d6e04c3757065-- From jeffrey.K.lange@ge.com Wed Jun 27 08:09:54 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC71721F864F for ; Wed, 27 Jun 2012 08:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.143 X-Spam-Level: X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tdT5FFbFtUT for ; Wed, 27 Jun 2012 08:09:54 -0700 (PDT) Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by ietfa.amsl.com (Postfix) with ESMTP id AC3B921F8622 for ; Wed, 27 Jun 2012 08:09:49 -0700 (PDT) Received: from alpmlip10.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKT+siPdjjnqoZ0Y3yZfUU/WOjkDE8sRN/@postini.com; Wed, 27 Jun 2012 08:09:49 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by alpmlip10.e2k.ad.ge.com with ESMTP; 27 Jun 2012 11:09:48 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jun 2012 11:09:48 -0400 Received: from CINMBCNA04.e2k.ad.ge.com (3.159.212.58) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 27 Jun 2012 11:09:47 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA04.e2k.ad.ge.com ([169.254.4.136]) with mapi id 14.02.0283.003; Wed, 27 Jun 2012 11:09:47 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] iana-timezones.yang proposal Thread-Index: Ac1UZ5zKdi90QqprQ+qLElq9kCvf9QAJC5qAAAfwbrD//8ZtgIAAEAEAgABBEHA= Date: Wed, 27 Jun 2012 15:09:46 +0000 Message-ID: References: <20120627140041.GB51402@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2012 15:09:48.0234 (UTC) FILETIME=[E4A27AA0:01CD5476] Subject: Re: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:09:54 -0000 >My concerns are with the IANA duplication. > >I prefer to keep the ietf-system YANG module decoupled from >changes in timezones throughout the world. =A0 Using an enumeration >means that vendors have to ship a specific version of the >timezones YANG module with each server. > >When the IANA registry is updated, the iana-*.yang file has to be updated,= =A0 >and a new RFC published. =A0After that, vendors hopefully will update thei= r >YANG modules to the latest version, and new products will have the updated >version as they are released. =A0The vendor has to know exactly what versi= on >of the YANG module to advertise, based on the tzdata library that is insta= lled. >This seems difficult to maintain. > >The code is likely to be updated faster than the YANG modules can be re-de= ployed. >If the YANG module does not match what the code actually supports, then >it is not helping, it just making things worse. I think that the impact is actually not that great because the YANG module = only lists the timezone names, not the rules associated with each timezone = in the world. I don't have any hard references to back me up on this, but = I would assume that adding a new timezone location is far less common than = changing the rules for a particular timezone. -Jeff From andy@yumaworks.com Wed Jun 27 08:19:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA72C21F873A for ; Wed, 27 Jun 2012 08:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WPeWFHDCtoS for ; Wed, 27 Jun 2012 08:19:25 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A01221F8736 for ; Wed, 27 Jun 2012 08:19:24 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1888456lbb.31 for ; Wed, 27 Jun 2012 08:19:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ylwGf+k4HIacZygBwECQF1HHoFE8SSVtaDfZxTp9nIg=; b=FlHHJqqL744TIe9rDxP5BYjaOk/NkzGHi2vXslHDLNxspnKVRpcO0rfrCMEPPP5sE8 sthVyfl0CRs1TewuM4d7Ny+giLTpDrEC3Is04YC4hKDqX1lmiwIDCY+6vEdOyqLm/A45 wlOxRx4TtdqScYVOAM+NWWtEood6xrJlMmrr38hknvMG0vaHbWrWfeJb97gYZ7AgVQm8 Bqy8LzLMG13jza1027+EyDmtyFjYSKu9NQ5Ib4IjhL6y4pZxj5kNfFgX3JpQGHznjovs NnrjujgzEQM/lWAOFNCrb5p3s1T3T3av7d5Up8M3bSDcMDNQ2dXC/yELy6Y2iE28jGzv 9fBA== MIME-Version: 1.0 Received: by 10.112.32.35 with SMTP id f3mr9818491lbi.47.1340810363557; Wed, 27 Jun 2012 08:19:23 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 27 Jun 2012 08:19:22 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: References: <20120627140041.GB51402@elstar.local> Date: Wed, 27 Jun 2012 08:19:22 -0700 Message-ID: From: Andy Bierman To: "Lange, Jeffrey K (GE Energy)" Content-Type: multipart/alternative; boundary=bcaec554dfee6e587d04c375bd72 X-Gm-Message-State: ALoCoQkUQJwUY2JmfqshHmGwD2bC3UrbIZBarRw8xka9bjTypaj/lAulHLrcoOb3Gl5sUWhgSxTR Cc: "netmod@ietf.org" Subject: Re: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:19:25 -0000 --bcaec554dfee6e587d04c375bd72 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 8:09 AM, Lange, Jeffrey K (GE Energy) < jeffrey.K.lange@ge.com> wrote: > > >My concerns are with the IANA duplication. > > > >I prefer to keep the ietf-system YANG module decoupled from > >changes in timezones throughout the world. Using an enumeration > >means that vendors have to ship a specific version of the > >timezones YANG module with each server. > > > >When the IANA registry is updated, the iana-*.yang file has to be > updated, > >and a new RFC published. After that, vendors hopefully will update their > >YANG modules to the latest version, and new products will have the updated > >version as they are released. The vendor has to know exactly what version > >of the YANG module to advertise, based on the tzdata library that is > installed. > >This seems difficult to maintain. > > > >The code is likely to be updated faster than the YANG modules can be > re-deployed. > >If the YANG module does not match what the code actually supports, then > >it is not helping, it just making things worse. > > I think that the impact is actually not that great because the YANG module > only lists the timezone names, not the rules associated with each timezone > in the world. I don't have any hard references to back me up on this, but > I would assume that adding a new timezone location is far less common than > changing the rules for a particular timezone. > > Good point -- adding new timezones is probably rare, so the module will not need to change very often. Probably less often than interface types. You might want to use that draft as a template for your draft: http://www.ietf.org/id/draft-ietf-netmod-iana-if-type-04.txt Andy > -Jeff > > --bcaec554dfee6e587d04c375bd72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 8:09 AM, Lange, = Jeffrey K (GE Energy) <jeffrey.K.lange@ge.com> wrote:

>My concerns are with the IANA duplication.
>
>I prefer to keep the ietf-system YANG module decoupled from
>changes in timezones throughout the world. =A0 Using an enumeration
>means that vendors have to ship a specific version of the
>timezones YANG module with each server.
>
>When the IANA registry is updated, the iana-*.yang file has to be updat= ed,=A0
>and a new RFC published. =A0After that, vendors hopefully will update t= heir
>YANG modules to the latest version, and new products will have the upda= ted
>version as they are released. =A0The vendor has to know exactly what ve= rsion
>of the YANG module to advertise, based on the tzdata library that is in= stalled.
>This seems difficult to maintain.
>
>The code is likely to be updated faster than the YANG modules can be re= -deployed.
>If the YANG module does not match what the code actually supports, then=
>it is not helping, it just making things worse.

I think that the impact is actually not that great because the YANG module = only lists the timezone names, not the rules associated with each timezone = in the world. =A0I don't have any hard references to back me up on this= , but I would assume that adding a new timezone location is far less common= than changing the rules for a particular timezone.



Good point -- adding ne= w timezones is probably rare, so the module will
not need to chan= ge very often. =A0Probably less often than interface types.
You m= ight want to use that draft as a template for your draft:



Andy

=A0
-Jeff


--bcaec554dfee6e587d04c375bd72-- From j.schoenwaelder@jacobs-university.de Wed Jun 27 08:21:57 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2823021F8799 for ; Wed, 27 Jun 2012 08:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.2 X-Spam-Level: X-Spam-Status: No, score=-103.2 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltUY7+bzIJ2l for ; Wed, 27 Jun 2012 08:21:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF3C21F8763 for ; Wed, 27 Jun 2012 08:21:56 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B7BF20BEE; Wed, 27 Jun 2012 17:21:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VHfMRl5YbLMY; Wed, 27 Jun 2012 17:21:55 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EBAF120BEB; Wed, 27 Jun 2012 17:21:54 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id C7820202D361; Wed, 27 Jun 2012 17:21:54 +0200 (CEST) Date: Wed, 27 Jun 2012 17:21:54 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120627152154.GB52020@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Andy Bierman , "Lange, Jeffrey K (GE Energy)" , "netmod@ietf.org" References: <20120627140041.GB51402@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] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:21:57 -0000 On Wed, Jun 27, 2012 at 07:57:58AM -0700, Andy Bierman wrote: > > My concerns are with the IANA duplication. > > I prefer to keep the ietf-system YANG module decoupled from > changes in timezones throughout the world. Using an enumeration > means that vendors have to ship a specific version of the > timezones YANG module with each server. > > When the IANA registry is updated, the iana-*.yang file has to be updated, > and a new RFC published. After that, vendors hopefully will update their > YANG modules to the latest version, and new products will have the updated > version as they are released. The vendor has to know exactly what version > of the YANG module to advertise, based on the tzdata library that is > installed. > This seems difficult to maintain. > > The code is likely to be updated faster than the YANG modules can be > re-deployed. > If the YANG module does not match what the code actually supports, then > it is not helping, it just making things worse. Minor correction: IANA maintained modules are not published as RFCs. The rest of your argument may apply. I have no clue how much the _names_ have changed over the last few years but it should likely be possible to find out somehow. /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 Jun 27 08:30:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F92121F87B6 for ; Wed, 27 Jun 2012 08:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.88 X-Spam-Level: X-Spam-Status: No, score=-2.88 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2XvNBO2nomB for ; Wed, 27 Jun 2012 08:30:05 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8A4D21F87B3 for ; Wed, 27 Jun 2012 08:30:04 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so1900818lbb.31 for ; Wed, 27 Jun 2012 08:30:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=LfgvLCizJdMPY0q8Tky4JGot3o7seow6FBwVms5XaBw=; b=G82dmhr3g/rn74qlUm4bLWVWdl76VjbBDeOB/qUwOS9U0TcxEMvgfenRVlFFbMRbBj djgR+uqZtQe1oVtcP3l3OISP/x7Aeid6iZMTuqkP78YLoTwxM2ROHNoIE6hchFCHymJi uepXFvdDhR73bq51HOYQog7XZH+lIsuSAs6BwrCJJTnuMjnYIeEHxrf93WiVsinwSjoP Jv7ZeAZTGsCzJRwLJGz94PmyDpeqOVnVIaY/HFt1EW9TxLVU6uwDhpoYAvQ2MJVVWo88 4eDrVKQfB2RnZJbkbi02QK6A/NOx+5PcMStyjspCj1rbGdsFEczDkNSpbk62C5gvllJF KtGg== MIME-Version: 1.0 Received: by 10.112.43.37 with SMTP id t5mr10043672lbl.89.1340811003613; Wed, 27 Jun 2012 08:30:03 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Wed, 27 Jun 2012 08:30:03 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120627152154.GB52020@elstar.jacobs.jacobs-university.de> References: <20120627140041.GB51402@elstar.local> <20120627152154.GB52020@elstar.jacobs.jacobs-university.de> Date: Wed, 27 Jun 2012 08:30:03 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Lange, Jeffrey K (GE Energy)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=e0cb4efe344c94d3c204c375e367 X-Gm-Message-State: ALoCoQlISvs0QuoTcap6WgosdcGbvYMzEnpJYM0i5kbHRTnJ5qFlcGzsprqtivaVpVJkxjAmfRK9 Subject: Re: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:30:06 -0000 --e0cb4efe344c94d3c204c375e367 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 27, 2012 at 8:21 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jun 27, 2012 at 07:57:58AM -0700, Andy Bierman wrote: > > > > My concerns are with the IANA duplication. > > > > I prefer to keep the ietf-system YANG module decoupled from > > changes in timezones throughout the world. Using an enumeration > > means that vendors have to ship a specific version of the > > timezones YANG module with each server. > > > > When the IANA registry is updated, the iana-*.yang file has to be > updated, > > and a new RFC published. After that, vendors hopefully will update their > > YANG modules to the latest version, and new products will have the > updated > > version as they are released. The vendor has to know exactly what > version > > of the YANG module to advertise, based on the tzdata library that is > > installed. > > This seems difficult to maintain. > > > > The code is likely to be updated faster than the YANG modules can be > > re-deployed. > > If the YANG module does not match what the code actually supports, then > > it is not helping, it just making things worse. > > Minor correction: IANA maintained modules are not published as RFCs. > The rest of your argument may apply. I have no clue how much the > _names_ have changed over the last few years but it should likely be > possible to find out somehow. > > I'm confused. So what will happen with draft-ietf-netmod-iana-if-type-04? Isn't it going to be published as an RFC? How can tools like yuma extract a YANG module, so when the statement "import iana-if-type" is parsed, a module exists to import? I think the NETMOD WG is signing up to make sure these RFCs get re-published as needed. > /js > > Andy --e0cb4efe344c94d3c204c375e367 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 27, 2012 at 8:21 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 27, 2012 at 07:57:58AM -0700, An= dy Bierman wrote:
>
> My concerns are with the IANA duplication.
>
> I prefer to keep the ietf-system YANG module decoupled from
> changes in timezones throughout the world. =A0 Using an enumeration > means that vendors have to ship a specific version of the
> timezones YANG module with each server.
>
> When the IANA registry is updated, the iana-*.yang file has to be upda= ted,
> and a new RFC published. =A0After that, vendors hopefully will update = their
> YANG modules to the latest version, and new products will have the upd= ated
> version as they are released. =A0The vendor has to know exactly what v= ersion
> of the YANG module to advertise, based on the tzdata library that is > installed.
> This seems difficult to maintain.
>
> The code is likely to be updated faster than the YANG modules can be > re-deployed.
> If the YANG module does not match what the code actually supports, the= n
> it is not helping, it just making things worse.

Minor correction: IANA maintained modules are not published as RFCs.
The rest of your argument may apply. I have no clue how much the
_names_ have changed over the last few years but it should likely be
possible to find out somehow.


I'm confused.
So what will happen with= =A0 draft-ietf-netmod-iana-if-type-04?=
Isn't it going to be published as an RFC?
How can tools = like yuma extract a YANG module, so when
the statement "impo= rt iana-if-type" is parsed, a module
exists to import?

I think the NETMOD WG is signing up to make sure these = RFCs
get re-published as needed.


=A0
/js


Andy

--e0cb4efe344c94d3c204c375e367-- From j.schoenwaelder@jacobs-university.de Wed Jun 27 08:51:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA06621F8739 for ; Wed, 27 Jun 2012 08:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSuvvVAhsyJQ for ; Wed, 27 Jun 2012 08:51:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4077E21F8736 for ; Wed, 27 Jun 2012 08:51:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 948F120C07; Wed, 27 Jun 2012 17:51:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZyKq9-kCn-fx; Wed, 27 Jun 2012 17:51:09 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35CF120C05; Wed, 27 Jun 2012 17:51:08 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id C6457202D58B; Wed, 27 Jun 2012 17:51:07 +0200 (CEST) Date: Wed, 27 Jun 2012 17:51:07 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120627155107.GE52020@elstar.jacobs.jacobs-university.de> Mail-Followup-To: Andy Bierman , "Lange, Jeffrey K (GE Energy)" , "netmod@ietf.org" References: <20120627140041.GB51402@elstar.local> <20120627152154.GB52020@elstar.jacobs.jacobs-university.de> 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] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:51:12 -0000 On Wed, Jun 27, 2012 at 08:30:03AM -0700, Andy Bierman wrote: [...] > I'm confused. > So what will happen with draft-ietf-netmod-iana-if-type-04? > Isn't it going to be published as an RFC? > How can tools like yuma extract a YANG module, so when > the statement "import iana-if-type" is parsed, a module > exists to import? > > I think the NETMOD WG is signing up to make sure these RFCs > get re-published as needed. Please check the IANA considerations of these documents whether they are clear enough and if not lets us know. /js PS: Changes to the IANAifType-MIB do not cause a new RFC to appear. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Jun 27 08:51:51 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28D221F8739 for ; Wed, 27 Jun 2012 08:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d82YJGTzWNp7 for ; Wed, 27 Jun 2012 08:51:51 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id F362B21F8736 for ; Wed, 27 Jun 2012 08:51:50 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id C92731200AD8; Wed, 27 Jun 2012 17:51:48 +0200 (CEST) Date: Wed, 27 Jun 2012 17:51:47 +0200 (CEST) Message-Id: <20120627.175147.457776630.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20120627152154.GB52020@elstar.jacobs.jacobs-university.de> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:51:52 -0000 Andy Bierman wrote: > On Wed, Jun 27, 2012 at 8:21 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Wed, Jun 27, 2012 at 07:57:58AM -0700, Andy Bierman wrote: > > > > > > My concerns are with the IANA duplication. > > > > > > I prefer to keep the ietf-system YANG module decoupled from > > > changes in timezones throughout the world. Using an enumeration > > > means that vendors have to ship a specific version of the > > > timezones YANG module with each server. > > > > > > When the IANA registry is updated, the iana-*.yang file has to be > > updated, > > > and a new RFC published. After that, vendors hopefully will update their > > > YANG modules to the latest version, and new products will have the > > updated > > > version as they are released. The vendor has to know exactly what > > version > > > of the YANG module to advertise, based on the tzdata library that is > > > installed. > > > This seems difficult to maintain. > > > > > > The code is likely to be updated faster than the YANG modules can be > > > re-deployed. > > > If the YANG module does not match what the code actually supports, then > > > it is not helping, it just making things worse. > > > > Minor correction: IANA maintained modules are not published as RFCs. > > The rest of your argument may apply. I have no clue how much the > > _names_ have changed over the last few years but it should likely be > > possible to find out somehow. > > > > > I'm confused. > So what will happen with draft-ietf-netmod-iana-if-type-04? > Isn't it going to be published as an RFC? Yes. This is the process to hand over an initial module to IANA. >From there, IANA maintains the YANG module, and publishes new revisions on their web site. Just like they do with IF-MIB. No new RFCs are published. /martin From mbj@tail-f.com Wed Jun 27 08:53:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAED821F8782 for ; Wed, 27 Jun 2012 08:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fb0HwhDaVnuc for ; Wed, 27 Jun 2012 08:53:12 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 12FDF21F875D for ; Wed, 27 Jun 2012 08:53:12 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 380751200043; Wed, 27 Jun 2012 17:53:11 +0200 (CEST) Date: Wed, 27 Jun 2012 17:53:10 +0200 (CEST) Message-Id: <20120627.175310.18714426.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: <20120627.175147.457776630.mbj@tail-f.com> References: <20120627152154.GB52020@elstar.jacobs.jacobs-university.de> <20120627.175147.457776630.mbj@tail-f.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 15:53:13 -0000 Sorry, s/IF-MIB/IANAifType-MIB/ /martin Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Jun 27, 2012 at 8:21 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Wed, Jun 27, 2012 at 07:57:58AM -0700, Andy Bierman wrote: > > > > > > > > My concerns are with the IANA duplication. > > > > > > > > I prefer to keep the ietf-system YANG module decoupled from > > > > changes in timezones throughout the world. Using an enumeration > > > > means that vendors have to ship a specific version of the > > > > timezones YANG module with each server. > > > > > > > > When the IANA registry is updated, the iana-*.yang file has to be > > > updated, > > > > and a new RFC published. After that, vendors hopefully will update their > > > > YANG modules to the latest version, and new products will have the > > > updated > > > > version as they are released. The vendor has to know exactly what > > > version > > > > of the YANG module to advertise, based on the tzdata library that is > > > > installed. > > > > This seems difficult to maintain. > > > > > > > > The code is likely to be updated faster than the YANG modules can be > > > > re-deployed. > > > > If the YANG module does not match what the code actually supports, then > > > > it is not helping, it just making things worse. > > > > > > Minor correction: IANA maintained modules are not published as RFCs. > > > The rest of your argument may apply. I have no clue how much the > > > _names_ have changed over the last few years but it should likely be > > > possible to find out somehow. > > > > > > > > I'm confused. > > So what will happen with draft-ietf-netmod-iana-if-type-04? > > Isn't it going to be published as an RFC? > > Yes. This is the process to hand over an initial module to IANA. > From there, IANA maintains the YANG module, and publishes new > revisions on their web site. Just like they do with IF-MIB. No new > RFCs are published. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From randy_presuhn@mindspring.com Wed Jun 27 12:17:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EC621F8720 for ; Wed, 27 Jun 2012 12:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.54 X-Spam-Level: X-Spam-Status: No, score=-99.54 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_15=0.6, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOfVfiQZnHYb for ; Wed, 27 Jun 2012 12:17:07 -0700 (PDT) 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 45DF121F8723 for ; Wed, 27 Jun 2012 12:17:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=XP9t37mT7DfLB2YBsv+ZmAYaPpMoR5vASRG++T9JX7OtiQQekbcvGXV9/dfRmIU3; 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.38.144.250] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Sjxjb-00011T-Oc for netmod@ietf.org; Wed, 27 Jun 2012 15:17:04 -0400 Message-ID: <004501cd5499$f9df41a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20120622152230.GA85847@elstar.local><20120623.163717.383201565.mbj@tail-f.com><017c01cd5454$3bbde860$4001a8c0@gateway.2wire.net> <20120627120044.GE49359@elstar.local> Date: Wed, 27 Jun 2012 12:20:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1ab72cde78c9cc760c58d67eee7fd8665350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.144.250 Subject: Re: [netmod] ietf-system: timezone-utc-offset X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:17:07 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "t.petch" > Cc: > Sent: Wednesday, June 27, 2012 5:00 AM > Subject: Re: [netmod] ietf-system: timezone-utc-offset ... > On Wed, Jun 27, 2012 at 12:00:00PM +0100, t.petch wrote: > > > And yes, there is also a tick box for > > "Automatically adjust clock for daylight saving changes" > > so this is what we should offer. > > There is not DST regulation that applies to a fixed UTC offset. DST > regulations are country/region specific. Hence, selection GMT+x and > selecting adjust clock for daylight saving changes is only something > Windows knows how to do. ;-) Concrete example: GMT -07 (Arizona) does not do DST while GMT-07 (Mountain) does. Even "Arizona" is a bit of a misnomer; for example the Navajo Nation within Arizona's borders uses Mountain time rather than Arizona time. Randy From mbj@tail-f.com Wed Jun 27 12:57:31 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6C611E80A5 for ; Wed, 27 Jun 2012 12:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz3pyyyiwdyB for ; Wed, 27 Jun 2012 12:57:30 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAF211E809A for ; Wed, 27 Jun 2012 12:57:30 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id CE82C1200043; Wed, 27 Jun 2012 21:57:27 +0200 (CEST) Date: Wed, 27 Jun 2012 21:57:27 +0200 (CEST) Message-Id: <20120627.215727.304709352.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120627091116.GA48378@elstar.local> References: <20120612111428.GD70760@elstar.local> <20120625.083036.514882828.mbj@tail-f.com> <20120627091116.GA48378@elstar.local> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:57:31 -0000 Juergen Schoenwaelder wrote: > On Mon, Jun 25, 2012 at 08:30:36AM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Tue, Jun 12, 2012 at 12:54:52PM +0200, Martin Bjorklund wrote: > > > > Juergen Schoenwaelder wrote: > > > > > I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my > > > > > comments/questions. > > > > [...] > > > > > > > d) p5: > > > > > > > > > > The objects ipNetToPhysicalTable and ipAddressStatus are writable in > > > > > the IP-MIB but do not represent configuration, and are thus not > > > > > mapped to the YANG module. > > > > > > > > > > This seems odd. Static address mappings can typically be configured > > > > > and some people do this (either for security or performance > > > > > reasons). As far as I understand things in the Linux world, address > > > > > mappings seem to be interface specific. > > > > > > > > For some discussion/questions, see > > > > http://www.ietf.org/mail-archive/web/netmod/current/msg06514.html. > > > > > > > > ipNetToPhysicalTable says: > > > > > > > > As the entries in this table are typically not persistent > > > > when this object is written the entity SHOULD NOT save the > > > > change to non-volatile storage. > > > > > > > > which is why I did not include this. > > > > > > Well, that might be true for the MIB. I happen to run boxes that have > > > static mappings and I happen to run boxes that do proxyarp stuff. I am > > > not saying this has to be included or not > > > > Ok. So let's ask the question: Do you think we should include > > configuration parameters for this? If so, do you have a suggestion > > for the data model? > > It is not clear what the WG things about it since only a few people > commented. More input would help. With some input from Juergen, here's a sketch of a data model to configure static ip-to-link-layer mappings, one for ipv4 and one for ipv6: augment "/if:interfaces/if:interface" { container ipv4 { // as currently defined in the draft ... list arp { // name? key "ip"; // entries end up as static arp cache entries leaf ip { type inet:ipv4-address; } leaf phys-address { type yang:phys-address; } } } container ipv6 { // as currently defined in the draft ... list neighbor { // name? key "ip"; // entries end up as static neighbor cache entries leaf ip { type inet:ipv6-address; } leaf phys-address { type yang:phys-address; } } } } So, what do people think? Should something like this be included in this data model? It seems most OSes / systems implement this functionality, and it is supported in the IP-MIB. /martin From j.schoenwaelder@jacobs-university.de Wed Jun 27 22:31:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA6A11E8155 for ; Wed, 27 Jun 2012 22:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jV8r2fLCuzII for ; Wed, 27 Jun 2012 22:31:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 26C6D11E80F0 for ; Wed, 27 Jun 2012 22:31:24 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F58020CB0; Thu, 28 Jun 2012 07:31:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AaiBnuhmMlPR; Thu, 28 Jun 2012 07:31:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52D6D20C13; Thu, 28 Jun 2012 07:31:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 59C84202E10B; Thu, 28 Jun 2012 07:31:21 +0200 (CEST) Date: Thu, 28 Jun 2012 07:31:21 +0200 From: Juergen Schoenwaelder To: jeffrey.k.lange@ge.com Message-ID: <20120628053120.GA54197@elstar.local> Mail-Followup-To: jeffrey.k.lange@ge.com, netmod@ietf.org References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 05:31:27 -0000 On Wed, Jun 27, 2012 at 03:37:03PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IANA Timezone Database YANG Module > Author(s) : Jeffrey Lange > Filename : draft-lange-netmod-iana-timezones-00.txt > Pages : 40 > Date : 2012-06-27 > > Abstract: > This document defines the initial version of the iana-timezone YANG > module. Thanks for putting this together. Perhaps the I-D should refer to RFC 6667 and the rules therein under which circumstances new TZ names are created. In fact, it seems that the maintenance really is in the hands of the TZ Coordinator and IANA is essentially providing infrastructure and the framework in which he does his work. So most likely, in practical terms, the TZ coordinator would have to create the YANG module as well. Since the database is in a machine readable form, I guess what he likely need is an advanced version of your script that automatically generates the YANG module and if it changes, it needs to be pushed to the IANA place where the YANG modules are published. In other words, I think some discussion with IANA and the current TZ coordinator might be needed to come up with a workable procedure how this would work. /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 Jun 27 23:28:33 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AA511E8170 for ; Wed, 27 Jun 2012 23:28:33 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0C6VwANKFCGP for ; Wed, 27 Jun 2012 23:28:33 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CFFF811E8097 for ; Wed, 27 Jun 2012 23:28:32 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 6D236140467; Thu, 28 Jun 2012 08:28:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340864904; bh=N7kICVUfdnqfHAgadm+8SepOLQl8yWaiA81tPqIF7+g=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=OLzt4eQv0JPtoi/yB8SBi2vBALRx6FhnG8HO4XMJ8/q5t5/aYGW4uKIhSvKLGBG4x JMddUHOIr0xnbYz0xc4l14R/sHCOypgYixUuIHzpNjG+ANXKZBaSS78KMQan1yMgoi StF00+kQxAH+RJn7KoW3lDQoQ66OgHxVR93p6ods= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120627.215727.304709352.mbj@tail-f.com> Date: Thu, 28 Jun 2012 08:28:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120612111428.GD70760@elstar.local> <20120625.083036.514882828.mbj@tail-f.com> <20120627091116.GA48378@elstar.local> <20120627.215727.304709352.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 06:28:33 -0000 On Jun 27, 2012, at 9:57 PM, Martin Bjorklund wrote: > With some input from Juergen, here's a sketch of a data model to > configure static ip-to-link-layer mappings, one for ipv4 and one for > ipv6: >=20 > augment "/if:interfaces/if:interface" { > container ipv4 { > // as currently defined in the draft > ... > list arp { // name? > key "ip"; > // entries end up as static arp cache entries > leaf ip { > type inet:ipv4-address; > } > leaf phys-address { > type yang:phys-address; > } > } > } > container ipv6 { > // as currently defined in the draft > ... > list neighbor { // name? > key "ip"; > // entries end up as static neighbor cache entries > leaf ip { > type inet:ipv6-address; > } > leaf phys-address { > type yang:phys-address; > } > } > } > } =20 >=20 > So, what do people think? Should something like this be included in > this data model? It seems most OSes / systems implement this > functionality, and it is supported in the IP-MIB. As we discussed earlier, implementations allow for configuring static = ARP or neighbor cache entries either globally (IOS, *BSD) or per = interface (JUNOS), and some allow both (Linux). By having this = configuration under "if:interface" we are losing the former option. So I = would prefer the global variant, which is more general because each = entry can contain an "interface-ref" leaf to make the entry = interface-specific. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Jun 28 00:39:22 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561D621F8813 for ; Thu, 28 Jun 2012 00:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaOtN28UlD0o for ; Thu, 28 Jun 2012 00:39:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEE321F8720 for ; Thu, 28 Jun 2012 00:11:57 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7C6A20CD3; Thu, 28 Jun 2012 09:11:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ogWXrW0J2M-g; Thu, 28 Jun 2012 09:11:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0C3320CD2; Thu, 28 Jun 2012 09:11:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 53BD1202E228; Thu, 28 Jun 2012 09:11:55 +0200 (CEST) Date: Thu, 28 Jun 2012 09:11:55 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120628071154.GA54468@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <20120612111428.GD70760@elstar.local> <20120625.083036.514882828.mbj@tail-f.com> <20120627091116.GA48378@elstar.local> <20120627.215727.304709352.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: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 07:39:22 -0000 On Thu, Jun 28, 2012 at 08:28:23AM +0200, Ladislav Lhotka wrote: > > As we discussed earlier, implementations allow for configuring static ARP or neighbor cache entries either globally (IOS, *BSD) or per interface (JUNOS), and some allow both (Linux). By having this configuration under "if:interface" we are losing the former option. So I would prefer the global variant, which is more general because each entry can contain an "interface-ref" leaf to make the entry interface-specific. > Which system allows ARP / ND entries to be configured that are not associated with an interface? /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 Jun 28 01:31:51 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7949021F8908 for ; Thu, 28 Jun 2012 01:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-FTD8omahl2 for ; Thu, 28 Jun 2012 01:31:51 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D070121F88FE for ; Thu, 28 Jun 2012 01:31:50 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C90D1200B84; Thu, 28 Jun 2012 10:31:48 +0200 (CEST) Date: Thu, 28 Jun 2012 10:31:48 +0200 (CEST) Message-Id: <20120628.103148.991980626356570748.mbj@tail-f.com> To: jeffrey.k.lange@ge.com From: Martin Bjorklund In-Reply-To: <20120628053120.GA54197@elstar.local> References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> <20120628053120.GA54197@elstar.local> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 08:31:51 -0000 Hi, Juergen Schoenwaelder wrote: > On Wed, Jun 27, 2012 at 03:37:03PM -0700, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > > > > Title : IANA Timezone Database YANG Module > > Author(s) : Jeffrey Lange > > Filename : draft-lange-netmod-iana-timezones-00.txt > > Pages : 40 > > Date : 2012-06-27 > > > > Abstract: > > This document defines the initial version of the iana-timezone YANG > > module. > > Thanks for putting this together. Perhaps the I-D should refer to RFC > 6667 and the rules therein under which circumstances new TZ names are > created. In fact, it seems that the maintenance really is in the hands > of the TZ Coordinator and IANA is essentially providing infrastructure > and the framework in which he does his work. So most likely, in > practical terms, the TZ coordinator would have to create the YANG > module as well. Since the database is in a machine readable form, I > guess what he likely need is an advanced version of your script that > automatically generates the YANG module and if it changes, it needs to > be pushed to the IANA place where the YANG modules are published. I think the module probably has to be maintained manually by IANA. The reason for this is the YANG update rule (Section 10 of RFC 6020): o An "enumeration" type may have new enums added, provided the old enums's values do not change. The current enum list is sorted in alphabetic order, and it must be clear to IANA that they need to alloacte a new value for the new value. So they can probably not just re-generate the module from their database - unless they add the value to their db of course. I just realized that you didn't include the value statement in this version (it was there in your first proposal). I suggest you put it back for the reasons given above. Some comments on the module: 1. You should probably fix your script to trim empty descriptions: enum "Africa/Abidjan" { description ""; } should be enum "Africa/Abidjan" { value 1; } 2. You should add a description and a reference to the typedef. The reference should point to the IANA registry: ("http://www.iana.org/time-zones") 3. And a nit - there's a trailing "<" in the introduction: Whenever a new timezone name is added to the IANA "timezone database", the iana-timezones module is updated by IANA.< /martin From mbj@tail-f.com Thu Jun 28 03:42:57 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BD421F85D7 for ; Thu, 28 Jun 2012 03:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zC5UWDhV2Ct3 for ; Thu, 28 Jun 2012 03:42:56 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B2D6921F85D6 for ; Thu, 28 Jun 2012 03:42:56 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9DBFB1200A6E; Thu, 28 Jun 2012 12:42:55 +0200 (CEST) Date: Thu, 28 Jun 2012 12:42:55 +0200 (CEST) Message-Id: <20120628.124255.2194135616541986952.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20120627091116.GA48378@elstar.local> <20120627.215727.304709352.mbj@tail-f.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:42:57 -0000 Ladislav Lhotka wrote: > > On Jun 27, 2012, at 9:57 PM, Martin Bjorklund wrote: > > > With some input from Juergen, here's a sketch of a data model to > > configure static ip-to-link-layer mappings, one for ipv4 and one for > > ipv6: > > > > augment "/if:interfaces/if:interface" { > > container ipv4 { > > // as currently defined in the draft > > ... > > list arp { // name? > > key "ip"; > > // entries end up as static arp cache entries > > leaf ip { > > type inet:ipv4-address; > > } > > leaf phys-address { > > type yang:phys-address; > > } > > } > > } > > container ipv6 { > > // as currently defined in the draft > > ... > > list neighbor { // name? > > key "ip"; > > // entries end up as static neighbor cache entries > > leaf ip { > > type inet:ipv6-address; > > } > > leaf phys-address { > > type yang:phys-address; > > } > > } > > } > > } > > > > So, what do people think? Should something like this be included in > > this data model? It seems most OSes / systems implement this > > functionality, and it is supported in the IP-MIB. First of all - do you think we should add something like this to the configuration model? I know you have talked about adding the neighbor cache, but I always thought you meant only monitoring of the neighbor cache. > As we discussed earlier, implementations allow for configuring static > ARP or neighbor cache entries either globally (IOS, *BSD) or per > interface (JUNOS), and some allow both (Linux). By having this > configuration under "if:interface" we are losing the former option. So > I would prefer the global variant, which is more general because each > entry can contain an "interface-ref" leaf to make the entry > interface-specific. In Junos it is even configured per address (subnet) per interface. This makes sense since if you configure a mapping for an IP address that is not part of your subnets, this mapping will never be used. In fact, also linux checks that the static arp entry belongs to your subnet. I didn't want to put it under address, since this would require you to configure a static address - OTOH on systems where you use static arp entries you probably also use static IP addresses... /martin From j.schoenwaelder@jacobs-university.de Thu Jun 28 03:56:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959FD21F8646 for ; Thu, 28 Jun 2012 03:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBqR1w8KuRiD for ; Thu, 28 Jun 2012 03:56:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8669F21F84D5 for ; Thu, 28 Jun 2012 03:56:54 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D224620C04; Thu, 28 Jun 2012 12:56:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SfPRPrQG73CZ; Thu, 28 Jun 2012 12:56:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5845420BFA; Thu, 28 Jun 2012 12:56:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C02C2202E9CE; Thu, 28 Jun 2012 12:56:51 +0200 (CEST) Date: Thu, 28 Jun 2012 12:56:51 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120628105651.GA55294@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20120627091116.GA48378@elstar.local> <20120627.215727.304709352.mbj@tail-f.com> <20120628.124255.2194135616541986952.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120628.124255.2194135616541986952.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:56:55 -0000 On Thu, Jun 28, 2012 at 12:42:55PM +0200, Martin Bjorklund wrote: > > As we discussed earlier, implementations allow for configuring static > > ARP or neighbor cache entries either globally (IOS, *BSD) or per > > interface (JUNOS), and some allow both (Linux). By having this > > configuration under "if:interface" we are losing the former option. So > > I would prefer the global variant, which is more general because each > > entry can contain an "interface-ref" leaf to make the entry > > interface-specific. > > In Junos it is even configured per address (subnet) per interface. > This makes sense since if you configure a mapping for an IP address > that is not part of your subnets, this mapping will never be used. In > fact, also linux checks that the static arp entry belongs to your > subnet. My Debian and Ubuntu boxes (kernel 2.6.32) apparently do this without any checks: $ sudo ip neigh add 1.1.1.1 lladdr 01:02:03:04:05:06 dev eth1 $ sudo ip neigh add 2442::4224 lladdr 01:02:03:04:05:06 dev eth1 Note 1.1.1.1 is not meaningful on the subnet nor is 2442::4224. > I didn't want to put it under address, since this would require you to > configure a static address - OTOH on systems where you use static arp > entries you probably also use static IP addresses... Probably but not necessarily. I would not force 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 mbj@tail-f.com Thu Jun 28 04:04:38 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC7B21F8661 for ; Thu, 28 Jun 2012 04:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5icXUvQV8Vua for ; Thu, 28 Jun 2012 04:04:38 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D671121F8483 for ; Thu, 28 Jun 2012 04:04:37 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 9B5D11200AC8; Thu, 28 Jun 2012 13:04:36 +0200 (CEST) Date: Thu, 28 Jun 2012 13:04:36 +0200 (CEST) Message-Id: <20120628.130436.1665065526792842690.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120628105651.GA55294@elstar.local> References: <20120628.124255.2194135616541986952.mbj@tail-f.com> <20120628105651.GA55294@elstar.local> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 11:04:38 -0000 Juergen Schoenwaelder wrote: > On Thu, Jun 28, 2012 at 12:42:55PM +0200, Martin Bjorklund wrote: > > > > As we discussed earlier, implementations allow for configuring static > > > ARP or neighbor cache entries either globally (IOS, *BSD) or per > > > interface (JUNOS), and some allow both (Linux). By having this > > > configuration under "if:interface" we are losing the former option. So > > > I would prefer the global variant, which is more general because each > > > entry can contain an "interface-ref" leaf to make the entry > > > interface-specific. > > > > In Junos it is even configured per address (subnet) per interface. > > This makes sense since if you configure a mapping for an IP address > > that is not part of your subnets, this mapping will never be used. In > > fact, also linux checks that the static arp entry belongs to your > > subnet. > > My Debian and Ubuntu boxes (kernel 2.6.32) apparently do this without > any checks: > > $ sudo ip neigh add 1.1.1.1 lladdr 01:02:03:04:05:06 dev eth1 > $ sudo ip neigh add 2442::4224 lladdr 01:02:03:04:05:06 dev eth1 Interesting. arp -s gives an error if you try this. Ok, so know we know we should use 'ip' to implement this data model on linux ;) /martin > Note 1.1.1.1 is not meaningful on the subnet nor is 2442::4224. > > > I didn't want to put it under address, since this would require you to > > configure a static address - OTOH on systems where you use static arp > > entries you probably also use static IP addresses... > > Probably but not necessarily. I would not force 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 lhotka@nic.cz Thu Jun 28 04:13:25 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6F221F865B for ; Thu, 28 Jun 2012 04:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOrpz9IuzXcj for ; Thu, 28 Jun 2012 04:13:25 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 96A1C21F8657 for ; Thu, 28 Jun 2012 04:13:24 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.120]) by mail.nic.cz (Postfix) with ESMTPSA id B2F73140467; Thu, 28 Jun 2012 13:13:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1340882002; bh=lYvcwUz9QLLBzxHD+0iM4QRkH9F47ts4kdIqTq7QCXM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=erl67YKHkHC6t4Sll59m2e+Ff5ZrLAp48T011VPQ+0Rx4/SYzNPShb+smrRiKQodN lukXHpz8NAvKnAEERBS+g/H5PM8rVZJjMtu/Igym9Xf42iIUbSQTPZrImKTHwW3CP3 moPvx4hB83X8QATCUChpTNp4O3arE2CT4R7iT/G4= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ladislav Lhotka In-Reply-To: <20120628.124255.2194135616541986952.mbj@tail-f.com> Date: Thu, 28 Jun 2012 13:13:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5FAD8474-4F90-4106-8464-AA4ECB10FDFC@nic.cz> References: <20120627091116.GA48378@elstar.local> <20120627.215727.304709352.mbj@tail-f.com> <20120628.124255.2194135616541986952.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 11:13:25 -0000 On Jun 28, 2012, at 12:42 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Jun 27, 2012, at 9:57 PM, Martin Bjorklund wrote: >>=20 >>> With some input from Juergen, here's a sketch of a data model to >>> configure static ip-to-link-layer mappings, one for ipv4 and one for >>> ipv6: >>>=20 >>> augment "/if:interfaces/if:interface" { >>> container ipv4 { >>> // as currently defined in the draft >>> ... >>> list arp { // name? >>> key "ip"; >>> // entries end up as static arp cache entries >>> leaf ip { >>> type inet:ipv4-address; >>> } >>> leaf phys-address { >>> type yang:phys-address; >>> } >>> } >>> } >>> container ipv6 { >>> // as currently defined in the draft >>> ... >>> list neighbor { // name? >>> key "ip"; >>> // entries end up as static neighbor cache entries >>> leaf ip { >>> type inet:ipv6-address; >>> } >>> leaf phys-address { >>> type yang:phys-address; >>> } >>> } >>> } >>> } =20 >>>=20 >>> So, what do people think? Should something like this be included in >>> this data model? It seems most OSes / systems implement this >>> functionality, and it is supported in the IP-MIB. >=20 > First of all - do you think we should add something like this to the > configuration model? I know you have talked about adding the neighbor > cache, but I always thought you meant only monitoring of the neighbor > cache. >=20 >> As we discussed earlier, implementations allow for configuring static >> ARP or neighbor cache entries either globally (IOS, *BSD) or per >> interface (JUNOS), and some allow both (Linux). By having this >> configuration under "if:interface" we are losing the former option. = So >> I would prefer the global variant, which is more general because each >> entry can contain an "interface-ref" leaf to make the entry >> interface-specific. >=20 > In Junos it is even configured per address (subnet) per interface. > This makes sense since if you configure a mapping for an IP address > that is not part of your subnets, this mapping will never be used. In > fact, also linux checks that the static arp entry belongs to your > subnet. Yes, but it is done dynamically, so the same (global) static ARP entry = remains valid even after the interface changes its name. ARP entries represent information about external devices, so it is not a = property of a particular interface. The linkage to an interface is only = indirect - without having an interface on the same IP subnet, the local = device has no way for using that information. A device may also have multiple connections to the same subnet, and then = the ARP entry should be equally valid for all connected interfaces. Lada =20 >=20 > I didn't want to put it under address, since this would require you to > configure a static address - OTOH on systems where you use static arp > entries you probably also use static IP addresses... >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Jun 28 04:14:23 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276D521F865B for ; Thu, 28 Jun 2012 04:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ1h9Svb7+U4 for ; Thu, 28 Jun 2012 04:14:22 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8A07521F85DF for ; Thu, 28 Jun 2012 04:14:22 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C6FAB1200AE5; Thu, 28 Jun 2012 13:14:21 +0200 (CEST) Date: Thu, 28 Jun 2012 13:14:21 +0200 (CEST) Message-Id: <20120628.131421.1845219448400288944.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120628.130436.1665065526792842690.mbj@tail-f.com> References: <20120628.124255.2194135616541986952.mbj@tail-f.com> <20120628105651.GA55294@elstar.local> <20120628.130436.1665065526792842690.mbj@tail-f.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 11:14:23 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Jun 28, 2012 at 12:42:55PM +0200, Martin Bjorklund wrote: > > > > > > As we discussed earlier, implementations allow for configuring static > > > > ARP or neighbor cache entries either globally (IOS, *BSD) or per > > > > interface (JUNOS), and some allow both (Linux). By having this > > > > configuration under "if:interface" we are losing the former option. So > > > > I would prefer the global variant, which is more general because each > > > > entry can contain an "interface-ref" leaf to make the entry > > > > interface-specific. > > > > > > In Junos it is even configured per address (subnet) per interface. > > > This makes sense since if you configure a mapping for an IP address > > > that is not part of your subnets, this mapping will never be used. In > > > fact, also linux checks that the static arp entry belongs to your > > > subnet. > > > > My Debian and Ubuntu boxes (kernel 2.6.32) apparently do this without > > any checks: > > > > $ sudo ip neigh add 1.1.1.1 lladdr 01:02:03:04:05:06 dev eth1 > > $ sudo ip neigh add 2442::4224 lladdr 01:02:03:04:05:06 dev eth1 > > Interesting. arp -s gives an error if you try this. Ok, I should have RTFM. If -i is not given it will consult the routing table, and can't find the interface. Sorry for the noise. /martin From j.schoenwaelder@jacobs-university.de Thu Jun 28 04:38:06 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2778D21F8460 for ; Thu, 28 Jun 2012 04:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF9FC8f8UlZI for ; Thu, 28 Jun 2012 04:38:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1BE21F8459 for ; Thu, 28 Jun 2012 04:38:05 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54E5920C20; Thu, 28 Jun 2012 13:38:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HQqAa2B-jREy; Thu, 28 Jun 2012 13:38:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC1CF20C1A; Thu, 28 Jun 2012 13:38:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 355BF202EABA; Thu, 28 Jun 2012 13:38:03 +0200 (CEST) Date: Thu, 28 Jun 2012 13:38:02 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20120628113801.GB55294@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20120628.124255.2194135616541986952.mbj@tail-f.com> <20120628105651.GA55294@elstar.local> <20120628.130436.1665065526792842690.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120628.130436.1665065526792842690.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 11:38:06 -0000 On Thu, Jun 28, 2012 at 01:04:36PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Jun 28, 2012 at 12:42:55PM +0200, Martin Bjorklund wrote: > > > > > > As we discussed earlier, implementations allow for configuring static > > > > ARP or neighbor cache entries either globally (IOS, *BSD) or per > > > > interface (JUNOS), and some allow both (Linux). By having this > > > > configuration under "if:interface" we are losing the former option. So > > > > I would prefer the global variant, which is more general because each > > > > entry can contain an "interface-ref" leaf to make the entry > > > > interface-specific. > > > > > > In Junos it is even configured per address (subnet) per interface. > > > This makes sense since if you configure a mapping for an IP address > > > that is not part of your subnets, this mapping will never be used. In > > > fact, also linux checks that the static arp entry belongs to your > > > subnet. > > > > My Debian and Ubuntu boxes (kernel 2.6.32) apparently do this without > > any checks: > > > > $ sudo ip neigh add 1.1.1.1 lladdr 01:02:03:04:05:06 dev eth1 > > $ sudo ip neigh add 2442::4224 lladdr 01:02:03:04:05:06 dev eth1 > > Interesting. arp -s gives an error if you try this. > > Ok, so know we know we should use 'ip' to implement this data model on > linux ;) Apparently, arp used an ioctl to create the entry while the ip utility talks via a netlink socket to the kernel. The ioctl interface seems to check while the netlink interface does not. Well, here is likely why. The command sudo arp -s 1.1.1.1 01:02:03:04:05:06 does not identify an interface. Hence, the kernel most likely uses the IP address to find the interface. If you specify the interface sudo arp -i eth1 -s 1.1.1.1 01:02:03:04:05:06 then even Linux arp does what it is told to do. (And if you want to do fancy proxyarp stuff, being able to create arbitrary arp entries might even be useful.) /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 Jun 28 04:44:08 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0CE21F857D for ; Thu, 28 Jun 2012 04:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.21 X-Spam-Level: X-Spam-Status: No, score=-103.21 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTqsc29UuZIS for ; Thu, 28 Jun 2012 04:44:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A1A6921F857A for ; Thu, 28 Jun 2012 04:44:07 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC25F20C1D; Thu, 28 Jun 2012 13:44:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mQ4zbWOl8nce; Thu, 28 Jun 2012 13:44:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D97720BF6; Thu, 28 Jun 2012 13:44:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 86F21202EB6B; Thu, 28 Jun 2012 13:44:06 +0200 (CEST) Date: Thu, 28 Jun 2012 13:44:06 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120628114406.GA55096@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <20120627091116.GA48378@elstar.local> <20120627.215727.304709352.mbj@tail-f.com> <20120628.124255.2194135616541986952.mbj@tail-f.com> <5FAD8474-4F90-4106-8464-AA4ECB10FDFC@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5FAD8474-4F90-4106-8464-AA4ECB10FDFC@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 11:44:08 -0000 On Thu, Jun 28, 2012 at 01:13:22PM +0200, Ladislav Lhotka wrote: > > > ARP entries represent information about external devices, so it is > not a property of a particular interface. The linkage to an > interface is only indirect - without having an interface on the same > IP subnet, the local device has no way for using that information. I would argue that the mapping information is only valid on a certain interface. I have never seen arp entries that are not associated to an interface. The IP subnet linkage does not seem to really exist, at least not on Linux. And if you do strange proxyarp stuff, you might even do proxyarp for devices that do not belong to the subnet you are using on that specific interface. > A device may also have multiple connections to the same subnet, and > then the ARP entry should be equally valid for all connected > interfaces. I would have to try this to see what kernels really do. I assume they use the interface specific mapping and might likely have duplicate entries in the arp table for the different interfaces. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jeffrey.K.lange@ge.com Thu Jun 28 05:44:00 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFFB21F8523 for ; Thu, 28 Jun 2012 05:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.967 X-Spam-Level: X-Spam-Status: No, score=-5.967 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZS-au9+jEuX for ; Thu, 28 Jun 2012 05:43:59 -0700 (PDT) Received: from exprod5og104.obsmtp.com (exprod5og104.obsmtp.com [64.18.0.178]) by ietfa.amsl.com (Postfix) with ESMTP id CC58B21F84D6 for ; Thu, 28 Jun 2012 05:43:57 -0700 (PDT) Received: from alpmlip11.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob104.postini.com ([64.18.4.12]) with SMTP ID DSNKT+xRjBe3c55iQFluUy4exCuk/WW7jm/0@postini.com; Thu, 28 Jun 2012 05:43:57 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by alpmlip11.e2k.ad.ge.com with ESMTP; 28 Jun 2012 08:43:55 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jun 2012 08:43:55 -0400 Received: from CINMBCNA03.e2k.ad.ge.com (3.159.212.57) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 28 Jun 2012 08:43:54 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA03.e2k.ad.ge.com ([169.254.3.14]) with mapi id 14.02.0283.003; Thu, 28 Jun 2012 08:43:54 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Martin Bjorklund Thread-Topic: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt Thread-Index: AQHNVO9Trc0EvVJrbkCzilxixtCsc5cPqhoAgAAAG6A= Date: Thu, 28 Jun 2012 12:43:54 +0000 Message-ID: References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> <20120628053120.GA54197@elstar.local> <20120628.103148.991980626356570748.mbj@tail-f.com> In-Reply-To: <20120628.103148.991980626356570748.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jun 2012 12:43:55.0388 (UTC) FILETIME=[ADF1EBC0:01CD552B] Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 12:44:00 -0000 >I think the module probably has to be maintained manually by IANA. >The reason for this is the YANG update rule (Section 10 of RFC 6020): > > o An "enumeration" type may have new enums added, provided the old > enums's values do not change. > >The current enum list is sorted in alphabetic order, and it must be clear = to IANA that they need to alloacte a new value for the new value. So they = can probably not just re-generate >the module from their database - unless = they add the value to their db of course. I sorted this alphabetically for readability, the zone.tab file I built it = from is sorted as stated in the file: # The table is sorted first by country, then an order within the country t= hat # (1) makes some geographical sense, and # (2) puts the most populous zones first, where that does not contradict (= 1). So that also is a bit arbitrary as well. Should I leave the enums in alpha= betical order? Or should it match what the zone.tab file does? > >I just realized that you didn't include the value statement in this versio= n (it was there in your first proposal). I suggest you put it back for the= reasons given above. I pulled those out because they don't map to anything in particular, they w= ere just an incrementing number that I used. There is no concept of an ID = number for entries in the TZ database, just the location string itself... = thoughts? How does the statement "provided the old enums's values do not change" app= ly to YANG enums that don't use values? Does that imply that all enums shou= ld have a value tag if they ever want to be considered maintainable? > >Some comments on the module: > >1. You should probably fix your script to trim empty descriptions: > > enum "Africa/Abidjan" { > description > ""; > } > > should be > > enum "Africa/Abidjan" { > value 1; > } > Easy enough. > >2. You should add a description and a reference to the typedef. The > reference should point to the IANA registry: > ("http://www.iana.org/time-zones") > Can do. > >3. And a nit - there's a trailing "<" in the introduction: > > Whenever a new timezone name is added to the IANA "timezone > database", the iana-timezones module is updated by IANA.< Typo =3D) >/martin -Jeff From j.schoenwaelder@jacobs-university.de Thu Jun 28 06:02:34 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB2921F8568 for ; Thu, 28 Jun 2012 06:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.911 X-Spam-Level: X-Spam-Status: No, score=-102.911 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izu2sedJDL1P for ; Thu, 28 Jun 2012 06:02:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC2C21F8567 for ; Thu, 28 Jun 2012 06:02:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C79520C12; Thu, 28 Jun 2012 15:02:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zX_KPh1NqCs0; Thu, 28 Jun 2012 15:02:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B581A20C2C; Thu, 28 Jun 2012 15:02:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DAE19202EE06; Thu, 28 Jun 2012 15:02:30 +0200 (CEST) Date: Thu, 28 Jun 2012 15:02:30 +0200 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy)" Message-ID: <20120628130230.GA55885@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy)" , Martin Bjorklund , "netmod@ietf.org" References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> <20120628053120.GA54197@elstar.local> <20120628.103148.991980626356570748.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: "netmod@ietf.org" Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 13:02:34 -0000 On Thu, Jun 28, 2012 at 12:43:54PM +0000, Lange, Jeffrey K (GE Energy) wrote: > >I think the module probably has to be maintained manually by IANA. > >The reason for this is the YANG update rule (Section 10 of RFC 6020): > > > > o An "enumeration" type may have new enums added, provided the old > > enums's values do not change. > > > >The current enum list is sorted in alphabetic order, and it must be clear to IANA that they need to alloacte a new value for the new value. So they can probably not just re-generate >the module from their database - unless they add the value to their db of course. > > I sorted this alphabetically for readability, the zone.tab file I built it from is sorted as stated in the file: > # The table is sorted first by country, then an order within the country that > # (1) makes some geographical sense, and > # (2) puts the most populous zones first, where that does not contradict (1). > > So that also is a bit arbitrary as well. Should I leave the enums in alphabetical order? Or should it match what the zone.tab file does? Any order is likely irrelevant over time. See below. > >I just realized that you didn't include the value statement in this version (it was there in your first proposal). I suggest you put it back for the reasons given above. > > I pulled those out because they don't map to anything in particular, they were just an incrementing number that I used. There is no concept of an ID number for entries in the TZ database, just the location string itself... thoughts? Would be nice there were one. Otherwise, the translation needs to assign one and never change it afterwards. > How does the statement "provided the old enums's values do not change" apply to YANG enums that don't use values? Does that imply that all enums should have a value tag if they ever want to be considered maintainable? If there is no value statement, then the enums are numbered automatically. This means that the order may never change (and it is harder to figure out what the 30th enum's value really is unless you use tools). See RFC 6020 section 9.6.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 mbj@tail-f.com Thu Jun 28 06:10:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22A321F8496 for ; Thu, 28 Jun 2012 06:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXU94o+gXiww for ; Thu, 28 Jun 2012 06:10:55 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3502821F85AF for ; Thu, 28 Jun 2012 06:10:55 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 244F91200AE5; Thu, 28 Jun 2012 15:10:54 +0200 (CEST) Date: Thu, 28 Jun 2012 15:10:53 +0200 (CEST) Message-Id: <20120628.151053.917190434192028680.mbj@tail-f.com> To: jeffrey.K.lange@ge.com From: Martin Bjorklund In-Reply-To: References: <20120628053120.GA54197@elstar.local> <20120628.103148.991980626356570748.mbj@tail-f.com> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 13:10:55 -0000 "Lange, Jeffrey K (GE Energy)" wrote: > >I think the module probably has to be maintained manually by IANA. > >The reason for this is the YANG update rule (Section 10 of RFC 6020): > > > > o An "enumeration" type may have new enums added, provided the old > > enums's values do not change. > > > >The current enum list is sorted in alphabetic order, and it must be > >clear to IANA that they need to alloacte a new value for the new > >value. So they can probably not just re-generate >the module from > >their database - unless they add the value to their db of course. > > I sorted this alphabetically for readability, the zone.tab file I > built it from is sorted as stated in the file: > # The table is sorted first by country, then an order within the > # country that > # (1) makes some geographical sense, and > # (2) puts the most populous zones first, where that does not > # contradict (1). > > So that also is a bit arbitrary as well. Should I leave the enums in > alphabetical order? Or should it match what the zone.tab file does? I think you should keep them in the same order as in the zone.tab file. Anyone can easily sort them alphabetically if they want to, but it is harder the other way around. > >I just realized that you didn't include the value statement in this > >version (it was there in your first proposal). I suggest you put it > >back for the reasons given above. > > I pulled those out because they don't map to anything in particular, > they were just an incrementing number that I used. There is no > concept of an ID number for entries in the TZ database, just the > location string itself... thoughts? > > How does the statement "provided the old enums's values do not change" > apply to YANG enums that don't use values? Does that imply that all > enums should have a value tag if they ever want to be considered > maintainable? No, but the update procedure must be clear. With explicit values the instructions to IANA would be: 1. allocate a new value for the new timezone 2. add a new enum statement in the proper order (as defined in the zone.tab) Without explicit values you would have to always add entries at the end (or use values for the new entries, but that would be even worse...) /martin From j.schoenwaelder@jacobs-university.de Thu Jun 28 06:12:16 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A06B21F84B9 for ; Thu, 28 Jun 2012 06:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.906 X-Spam-Level: X-Spam-Status: No, score=-102.906 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3ZB6ROluu9s for ; Thu, 28 Jun 2012 06:12:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A019E21F8496 for ; Thu, 28 Jun 2012 06:12:15 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC94F20C30; Thu, 28 Jun 2012 15:12:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RJX2JeWqyb6r; Thu, 28 Jun 2012 15:12:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DCF820C04; Thu, 28 Jun 2012 15:12:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8E067202EEEA; Thu, 28 Jun 2012 15:12:13 +0200 (CEST) Date: Thu, 28 Jun 2012 15:12:13 +0200 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy)" , Martin Bjorklund , "netmod@ietf.org" Message-ID: <20120628131213.GA55958@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy)" , Martin Bjorklund , "netmod@ietf.org" References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> <20120628053120.GA54197@elstar.local> <20120628.103148.991980626356570748.mbj@tail-f.com> <20120628130230.GA55885@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120628130230.GA55885@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 13:12:16 -0000 On Thu, Jun 28, 2012 at 03:02:30PM +0200, Juergen Schoenwaelder wrote: > > So that also is a bit arbitrary as well. Should I leave the enums in alphabetical order? Or should it match what the zone.tab file does? > > Any order is likely irrelevant over time. See below. > Well, I realize this statement is not really helpful / correct. You can keept the enums defined in the order they are defined in the TZ database but then the value statements MUST be used and the numbers over time won't be assigned in a strictly increasing order. This means that YANG tools can use the definition order (if they are able to access it) or they might end up using the numeric value order, which will over time be increasingly meaningless. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jeffrey.K.lange@ge.com Thu Jun 28 06:49:58 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC5121F84E7 for ; Thu, 28 Jun 2012 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.27 X-Spam-Level: X-Spam-Status: No, score=-6.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyLVFbj00PRJ for ; Thu, 28 Jun 2012 06:49:58 -0700 (PDT) Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8C57621F84DF for ; Thu, 28 Jun 2012 06:49:57 -0700 (PDT) Received: from alpmlip14.e2k.ad.ge.com ([12.43.191.1]) (using TLSv1) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKT+xhBFxewYKfuGTUpIUgO7Md8nMFw1X6@postini.com; Thu, 28 Jun 2012 06:49:57 PDT Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by alpmlip14.e2k.ad.ge.com with ESMTP; 28 Jun 2012 09:49:55 -0400 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jun 2012 09:49:54 -0400 Received: from CINMBCNA01.e2k.ad.ge.com (3.159.212.55) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 28 Jun 2012 09:49:54 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA01.e2k.ad.ge.com ([169.254.1.155]) with mapi id 14.02.0283.003; Thu, 28 Jun 2012 09:49:54 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt Thread-Index: AQHNVO9Trc0EvVJrbkCzilxixtCsc5cPqhoAgAAAG6CAAEuHAIAAAreA///GRuA= Date: Thu, 28 Jun 2012 13:49:53 +0000 Message-ID: References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> <20120628053120.GA54197@elstar.local> <20120628.103148.991980626356570748.mbj@tail-f.com> <20120628130230.GA55885@elstar.local> <20120628131213.GA55958@elstar.local> In-Reply-To: <20120628131213.GA55958@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jun 2012 13:49:54.0937 (UTC) FILETIME=[E6052690:01CD5534] Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 13:49:58 -0000 I have a general question about the description text. I took the text dire= ctly from the iana-if-type module, but it has the text This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; Now from the conversations yesterday, am I correct in saying that this will= NOT map to a particular RFC due to how iana controls their documents? If = this is true, the description text in the iana-if-type module should also b= e updated to reflect this. Also the email is listed as iana&iana.org I assume that this is a typo and= should also be changed in the iana-if-type document. -Jeff From j.schoenwaelder@jacobs-university.de Thu Jun 28 07:23:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3A821F85B1 for ; Thu, 28 Jun 2012 07:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id splJ0ChXUjg1 for ; Thu, 28 Jun 2012 07:23:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D01D621F85B8 for ; Thu, 28 Jun 2012 07:23:51 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 089B220C31; Thu, 28 Jun 2012 16:23:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cG8X72_Pqrjq; Thu, 28 Jun 2012 16:23:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F90B20C2D; Thu, 28 Jun 2012 16:23:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EB7AE202F129; Thu, 28 Jun 2012 16:23:48 +0200 (CEST) Date: Thu, 28 Jun 2012 16:23:48 +0200 From: Juergen Schoenwaelder To: "Lange, Jeffrey K (GE Energy)" Message-ID: <20120628142348.GA56180@elstar.local> Mail-Followup-To: "Lange, Jeffrey K (GE Energy)" , "netmod@ietf.org" References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> <20120628053120.GA54197@elstar.local> <20120628.103148.991980626356570748.mbj@tail-f.com> <20120628130230.GA55885@elstar.local> <20120628131213.GA55958@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] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 14:23:56 -0000 On Thu, Jun 28, 2012 at 01:49:53PM +0000, Lange, Jeffrey K (GE Energy) wrote: > I have a general question about the description text. I took the text directly from the iana-if-type module, but it has the text > > This version of this YANG module is part of RFC XXXX; see > the RFC itself for full legal notices."; > > Now from the conversations yesterday, am I correct in saying that this will NOT map to a particular RFC due to how iana controls their documents? If this is true, the description text in the iana-if-type module should also be updated to reflect this. The initial version is an RFC and hence the statement is correct. The question whether the legal framework then also applies to subsequently IANA maintained modules likely leads to a major discussion if we ask it... > Also the email is listed as iana&iana.org I assume that this is a typo and should also be changed in the iana-if-type document. I recently had a discussion about this with IANA and it seems right now they prefer this style because they believe it helps them fighting spam. (I think they are likely confused about this but I decided not to try to convince them otherwise, at least not via email.) /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 Jun 28 07:38:24 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68E121F8513 for ; Thu, 28 Jun 2012 07:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.892 X-Spam-Level: X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaASwW3OSsmK for ; Thu, 28 Jun 2012 07:38:22 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7943D21F8503 for ; Thu, 28 Jun 2012 07:38:22 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3472362lbb.31 for ; Thu, 28 Jun 2012 07:38:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XMT2fs3OT0sHksRYF0AvvQSayZthDo5j++cGYYj6zzY=; b=H0Ad2QVxkG6nRdYor9yIIu0okLpsMnVWY27r3xXBFJHbWVj5pixu4QPcVc4TOMJ3ml 1kParaQ0Mx4rn95/uNHhDDmbu67A+Hj+UoLopCpGq6n6CpVVSHXVP8K1lYKJ5iq9XM7c 7FKcs2eWBOr1qZ6NWahZNUHpdlhf0uNlLpBTDPmJda+ssHO+qesxD+eqRexUHE1o6OAR LWq685JttdWE19oSJAi3a2fCIbqa7xtW49g0kNtRTjVh1Y85MWqSkqtTt32EEyuci/Tx IS6D9icllLlQThrhKLTkXI6mLxoSG8FexLKJJzcPu/U025YEfJ/rKiQV+R+IDkbl/vnc w3QQ== MIME-Version: 1.0 Received: by 10.112.86.132 with SMTP id p4mr1250160lbz.22.1340894299223; Thu, 28 Jun 2012 07:38:19 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Thu, 28 Jun 2012 07:38:18 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120627.175147.457776630.mbj@tail-f.com> References: <20120627152154.GB52020@elstar.jacobs.jacobs-university.de> <20120627.175147.457776630.mbj@tail-f.com> Date: Thu, 28 Jun 2012 07:38:18 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=bcaec554d52262f6be04c389482c X-Gm-Message-State: ALoCoQlBCG/i1xqY4unhL4RmARyW+VSvQ7Kh0U9UD+gBi9B7Amd8qoSVsoxuODcjdoF3U0RANwRR Cc: netmod@ietf.org Subject: Re: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 14:38:25 -0000 --bcaec554d52262f6be04c389482c Content-Type: text/plain; charset=ISO-8859-1 .... > > > > > I'm confused. > > So what will happen with draft-ietf-netmod-iana-if-type-04? > > Isn't it going to be published as an RFC? > > Yes. This is the process to hand over an initial module to IANA. > From there, IANA maintains the YANG module, and publishes new > revisions on their web site. Just like they do with IF-MIB. No new > RFCs are published. > > This is fine I guess, as long as the IANA update announcement goes to the same mailing list as an RFC announcement. In general this approach has a conformance flaw -- normative references. In the referencing document really intends that a specific version (or later) be used of the registry, there is no way to do that. The normative RFC reference is the same for all versions of the registry. > /martin > Andy --bcaec554d52262f6be04c389482c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
....
> >
> I'm confused.
> So what will happen with =A0draft-ietf-netmod-iana-if-type-04?
> Isn't it going to be published as an RFC?

Yes. =A0This is the process to hand over an initial module to IANA.
>From there, IANA maintains the YANG module, and publishes new
revisions on their web site. =A0Just like they do with IF-MIB. =A0No new RFCs are published.



This is fine I guess, as long as the = IANA update announcement
goes to the same mailing list as an RFC = announcement.

In general this approach has a conformance flaw -- norm= ative references.
In the referencing document really intends that= a specific version (or later)
be used of the registry, there is = no way to do that. =A0The normative RFC
reference is the same for all versions of the registry.

=

=
/martin


Andy
--bcaec554d52262f6be04c389482c-- From j.schoenwaelder@jacobs-university.de Thu Jun 28 07:51:04 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAD921F856C for ; Thu, 28 Jun 2012 07:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.202 X-Spam-Level: X-Spam-Status: No, score=-103.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IeN1Bzsu2Wu for ; Thu, 28 Jun 2012 07:50:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 73EAE21F856D for ; Thu, 28 Jun 2012 07:50:56 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C964B20C31; Thu, 28 Jun 2012 16:50:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3YlTF6UcQvk1; Thu, 28 Jun 2012 16:50:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 550BC20C1D; Thu, 28 Jun 2012 16:50:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F3C02202F235; Thu, 28 Jun 2012 16:50:54 +0200 (CEST) Date: Thu, 28 Jun 2012 16:50:54 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20120628145054.GB56180@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , jeffrey.K.lange@ge.com, netmod@ietf.org References: <20120627152154.GB52020@elstar.jacobs.jacobs-university.de> <20120627.175147.457776630.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: netmod@ietf.org Subject: Re: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 14:51:04 -0000 On Thu, Jun 28, 2012 at 07:38:18AM -0700, Andy Bierman wrote: > .... > > > > > > > > I'm confused. > > > So what will happen with draft-ietf-netmod-iana-if-type-04? > > > Isn't it going to be published as an RFC? > > > > Yes. This is the process to hand over an initial module to IANA. > > From there, IANA maintains the YANG module, and publishes new > > revisions on their web site. Just like they do with IF-MIB. No new > > RFCs are published. > > > > > > This is fine I guess, as long as the IANA update announcement > goes to the same mailing list as an RFC announcement. > > In general this approach has a conformance flaw -- normative references. > In the referencing document really intends that a specific version (or > later) > be used of the registry, there is no way to do that. The normative RFC > reference is the same for all versions of the registry. If there is a flaw, then it likely applies to many things maintained by IANA including several MIB modules. I do not think we are going to address that as part of the NETMOD WG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Jonathan.Hansford@generaldynamics.uk.com Thu Jun 28 07:59:09 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7E521F857F for ; Thu, 28 Jun 2012 07:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.955 X-Spam-Level: X-Spam-Status: No, score=-4.955 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5s1rdgVwYgWf for ; Thu, 28 Jun 2012 07:59:08 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 68B1021F8501 for ; Thu, 28 Jun 2012 07:59:08 -0700 (PDT) Received: from [85.158.136.35:56747] by server-5.bemta-5.messagelabs.com id DD/54-02722-B317CEF4; Thu, 28 Jun 2012 14:59:07 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-7.tower-125.messagelabs.com!1340895547!30587829!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12249 invoked from network); 28 Jun 2012 14:59:07 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-7.tower-125.messagelabs.com with SMTP; 28 Jun 2012 14:59:07 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 28 Jun 2012 15:59:06 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jun 2012 15:58:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jun 2012 15:58:15 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E650546206D4C3D4@GDUKADH850.uk1.r-org.net> In-Reply-To: <20120628131213.GA55958@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt Thread-Index: Ac1VPnI8PSHfPYfOSvqse0l/9+xtbw== References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com><20120628053120.GA54197@elstar.local><20120628.103148.991980626356570748.mbj@tail-f.com><20120628130230.GA55885@elstar.local> <20120628131213.GA55958@elstar.local> From: To: , , , X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 28 Jun 2012 14:58:12.0882 (UTC) FILETIME=[7095EF20:01CD553E] Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 14:59:09 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: 28 June 2012 14:12 > To: Lange, Jeffrey K (GE Energy); Martin Bjorklund; netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt >=20 > On Thu, Jun 28, 2012 at 03:02:30PM +0200, Juergen Schoenwaelder wrote: >=20 > > > So that also is a bit arbitrary as well. Should I leave the enums in > alphabetical order? Or should it match what the zone.tab file does? > > > > Any order is likely irrelevant over time. See below. > > >=20 > Well, I realize this statement is not really helpful / correct. You > can keept the enums defined in the order they are defined in the TZ > database but then the value statements MUST be used and the numbers > over time won't be assigned in a strictly increasing order. This means > that YANG tools can use the definition order (if they are able to > access it) or they might end up using the numeric value order, which > will over time be increasingly meaningless. Still learning here, but RFC6087 states: If extensibility of enumerated values is required, then the 'identityref' data type SHOULD be used instead of an enumeration or other built-in type. So why are enums being considered over identityrefs? >=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 This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From mbj@tail-f.com Thu Jun 28 08:03:12 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E5721F8548 for ; Thu, 28 Jun 2012 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjMV38eIwA9Z for ; Thu, 28 Jun 2012 08:03:12 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 408D221F8539 for ; Thu, 28 Jun 2012 08:03:12 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B69CE1200A6E; Thu, 28 Jun 2012 17:03:10 +0200 (CEST) Date: Thu, 28 Jun 2012 17:03:10 +0200 (CEST) Message-Id: <20120628.170310.618791618530311134.mbj@tail-f.com> To: Jonathan.Hansford@generaldynamics.uk.com From: Martin Bjorklund In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206D4C3D4@GDUKADH850.uk1.r-org.net> References: <20120628130230.GA55885@elstar.local> <20120628131213.GA55958@elstar.local> <83C941F7F59F3F42AC017AD1E650546206D4C3D4@GDUKADH850.uk1.r-org.net> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:03:13 -0000 wrote: > > -----Original Message----- > > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: 28 June 2012 14:12 > > To: Lange, Jeffrey K (GE Energy); Martin Bjorklund; netmod@ietf.org > > Subject: Re: [netmod] I-D Action: > draft-lange-netmod-iana-timezones-00.txt > > > > On Thu, Jun 28, 2012 at 03:02:30PM +0200, Juergen Schoenwaelder wrote: > > > > > > So that also is a bit arbitrary as well. Should I leave the enums > in > > alphabetical order? Or should it match what the zone.tab file does? > > > > > > Any order is likely irrelevant over time. See below. > > > > > > > Well, I realize this statement is not really helpful / correct. You > > can keept the enums defined in the order they are defined in the TZ > > database but then the value statements MUST be used and the numbers > > over time won't be assigned in a strictly increasing order. This means > > that YANG tools can use the definition order (if they are able to > > access it) or they might end up using the numeric value order, which > > will over time be increasingly meaningless. > > Still learning here, but RFC6087 states: > > If extensibility of enumerated values is required, then the > 'identityref' data type SHOULD be used instead of an enumeration or > other built-in type. > > So why are enums being considered over identityrefs? In this case, you really do not want the kind of extensibility that identities give you - with an identity you get decentralized extensibility; anyone can add their own new value. That's probably not what you need for timezones... /martin From andy@yumaworks.com Thu Jun 28 08:07:18 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B03121F85D2 for ; Thu, 28 Jun 2012 08:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pqahowohtVH for ; Thu, 28 Jun 2012 08:07:17 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE22421F85CE for ; Thu, 28 Jun 2012 08:07:16 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3506908lbb.31 for ; Thu, 28 Jun 2012 08:07:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=w/M8Sk+expLzxCjKvdTLuTkEVfUbrtGzRAaOANdKZFo=; b=gJ+FHsi2UkpHk+d7kE6Iw4iN8B7lwYNHtGba0M1BeSYpTVroOtKBg80HQG5WcRiDPu ANDcWC/EmFpYOSTSdDIrJqGqO2MBlDJzj5468+U6maGUMywLwlGTuR3rG0TMglBvmuKC XLwuw7zeDf0frmSJtvlJwpjyz10LY5hoUsqfdOMTGA6Y8bfVvonTro+BA7ryvLI5B/o/ KcWQA9N5RaWmI4UfflusJ4jHk3KheZQa8qiP9N3CPlSJafmnuxuqPzRowSrzMsEQJn1l J2r7Suh7g91lMP6tipYomrQePUkl2LMIvr28oXeG5eMy+2fkwOSN5Jr9gcNF/gN5DfPT yoXA== MIME-Version: 1.0 Received: by 10.112.86.166 with SMTP id q6mr1332731lbz.6.1340896035834; Thu, 28 Jun 2012 08:07:15 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Thu, 28 Jun 2012 08:07:15 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206D4C3D4@GDUKADH850.uk1.r-org.net> References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> <20120628053120.GA54197@elstar.local> <20120628.103148.991980626356570748.mbj@tail-f.com> <20120628130230.GA55885@elstar.local> <20120628131213.GA55958@elstar.local> <83C941F7F59F3F42AC017AD1E650546206D4C3D4@GDUKADH850.uk1.r-org.net> Date: Thu, 28 Jun 2012 08:07:15 -0700 Message-ID: From: Andy Bierman To: Jonathan.Hansford@generaldynamics.uk.com Content-Type: multipart/alternative; boundary=f46d0401faede58d2f04c389afd3 X-Gm-Message-State: ALoCoQkZ1C+bOjFUo4QexkhNC4j87+IZO0onXTII99+cIzKwGIWm+F3R+XsZn0inAG/Tzkc2Upt6 Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:07:18 -0000 --f46d0401faede58d2f04c389afd3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 28, 2012 at 7:58 AM, wrote: > > -----Original Message----- > > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: 28 June 2012 14:12 > > To: Lange, Jeffrey K (GE Energy); Martin Bjorklund; netmod@ietf.org > > Subject: Re: [netmod] I-D Action: > draft-lange-netmod-iana-timezones-00.txt > > > > On Thu, Jun 28, 2012 at 03:02:30PM +0200, Juergen Schoenwaelder wrote: > > > > > > So that also is a bit arbitrary as well. Should I leave the enums > in > > alphabetical order? Or should it match what the zone.tab file does? > > > > > > Any order is likely irrelevant over time. See below. > > > > > > > Well, I realize this statement is not really helpful / correct. You > > can keept the enums defined in the order they are defined in the TZ > > database but then the value statements MUST be used and the numbers > > over time won't be assigned in a strictly increasing order. This means > > that YANG tools can use the definition order (if they are able to > > access it) or they might end up using the numeric value order, which > > will over time be increasingly meaningless. > > Still learning here, but RFC6087 states: > > If extensibility of enumerated values is required, then the > 'identityref' data type SHOULD be used instead of an enumeration or > other built-in type. > > So why are enums being considered over identityrefs? > > That text should be clarified. If a centralized naming authority is used, then enumeration is OK, and less complex than identityref. For distributed naming authority, an identityref is needed. (Identityref is a QName -- module-prefix:identity-name). Also, enums are allowed to have many chars in them that would be invalid in a YANG identifier. (e.g. '/' would make every timezone location invalid) > > > /js > > > Andy --f46d0401faede58d2f04c389afd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 28, 2012 at 7:58 AM, <Jonathan.Hansford@generaldynamics.uk.com> = wrote:
> -----Original Message-----
> From: Juergen Schoenwaelder
[mailto:j.schoenwae= lder@jacobs-university.de]
> Sent: 28 June 2012 14:12
> To: Lange, Jeffrey K (GE Energy); Martin Bjorklund; netmod@ietf.org
> Subject: Re: [netmod] I-D Action:
draft-lange-netmod-iana-timezones-00.txt
>
> On Thu, Jun 28, 2012 at 03:02:30PM +0200, Juergen Schoenwaelder wrote:=
>
> > > So that also is a bit arbitrary as well. =A0Should I leave t= he enums
in
> alphabetical order? Or should it match what the zone.tab file does? > >
> > Any order is likely irrelevant over time. See below.
> >
>
> Well, I realize this statement is not really helpful / correct. You > can keept the enums defined in the order they are defined in the TZ > database but then the value statements MUST be used and the numbers > over time won't be assigned in a strictly increasing order. This m= eans
> that YANG tools can use the definition order (if they are able to
> access it) or they might end up using the numeric value order, which > will over time be increasingly meaningless.

Still learning here, but RFC6087 states:

If extensibility of enumerated values is required, then the
'identityref' data type SHOULD be used instead of an enumeration or=
other built-in type.

So why are enums being considered over identityrefs?


That text should be clarified. =A0If a= centralized naming authority
is used, then enumeration is OK, an= d less complex than identityref.
For distributed naming authority= , an identityref is needed.
(Identityref is a QName -- module-prefix:identity-name).
Also, enums are allowed to have many chars in them that
would be invalid in a YANG identifier. (e.g. '/' would make ever= y
timezone location invalid)


>
> /js
>


Andy

=
--f46d0401faede58d2f04c389afd3-- From j.schoenwaelder@jacobs-university.de Thu Jun 28 08:08:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAE321F858A for ; Thu, 28 Jun 2012 08:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.903 X-Spam-Level: X-Spam-Status: No, score=-102.903 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNnpW3ygd58P for ; Thu, 28 Jun 2012 08:08:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 160A321F8513 for ; Thu, 28 Jun 2012 08:08:26 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65C8520C31; Thu, 28 Jun 2012 17:08:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zNUYOkmeqQaa; Thu, 28 Jun 2012 17:08:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B86F20BF6; Thu, 28 Jun 2012 17:08:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C1AA2202F3AC; Thu, 28 Jun 2012 17:08:23 +0200 (CEST) Date: Thu, 28 Jun 2012 17:08:23 +0200 From: Juergen Schoenwaelder To: Jonathan.Hansford@generaldynamics.uk.com Message-ID: <20120628150821.GC56180@elstar.local> Mail-Followup-To: Jonathan.Hansford@generaldynamics.uk.com, jeffrey.K.lange@ge.com, mbj@tail-f.com, netmod@ietf.org References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> <20120628053120.GA54197@elstar.local> <20120628.103148.991980626356570748.mbj@tail-f.com> <20120628130230.GA55885@elstar.local> <20120628131213.GA55958@elstar.local> <83C941F7F59F3F42AC017AD1E650546206D4C3D4@GDUKADH850.uk1.r-org.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83C941F7F59F3F42AC017AD1E650546206D4C3D4@GDUKADH850.uk1.r-org.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:08:27 -0000 On Thu, Jun 28, 2012 at 03:58:15PM +0100, Jonathan.Hansford@generaldynamics.uk.com wrote: > > -----Original Message----- > > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: 28 June 2012 14:12 > > To: Lange, Jeffrey K (GE Energy); Martin Bjorklund; netmod@ietf.org > > Subject: Re: [netmod] I-D Action: > draft-lange-netmod-iana-timezones-00.txt > > > > On Thu, Jun 28, 2012 at 03:02:30PM +0200, Juergen Schoenwaelder wrote: > > > > > > So that also is a bit arbitrary as well. Should I leave the enums > in > > alphabetical order? Or should it match what the zone.tab file does? > > > > > > Any order is likely irrelevant over time. See below. > > > > > > > Well, I realize this statement is not really helpful / correct. You > > can keept the enums defined in the order they are defined in the TZ > > database but then the value statements MUST be used and the numbers > > over time won't be assigned in a strictly increasing order. This means > > that YANG tools can use the definition order (if they are able to > > access it) or they might end up using the numeric value order, which > > will over time be increasingly meaningless. > > Still learning here, but RFC6087 states: > > If extensibility of enumerated values is required, then the > 'identityref' data type SHOULD be used instead of an enumeration or > other built-in type. > > So why are enums being considered over identityrefs? Because that was proposed on the list. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Jonathan.Hansford@generaldynamics.uk.com Thu Jun 28 08:17:50 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8229721F85A5 for ; Thu, 28 Jun 2012 08:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.066 X-Spam-Level: X-Spam-Status: No, score=-5.066 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLq-XrxfYRrO for ; Thu, 28 Jun 2012 08:17:49 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 84D7F21F842A for ; Thu, 28 Jun 2012 08:17:48 -0700 (PDT) Received: from [85.158.139.3:19701] by server-4.bemta-5.messagelabs.com id FB/B7-27831-B957CEF4; Thu, 28 Jun 2012 15:17:47 +0000 X-Env-Sender: Jonathan.Hansford@generaldynamics.uk.com X-Msg-Ref: server-10.tower-90.messagelabs.com!1340896667!26329185!1 X-Originating-IP: [217.33.196.17] X-StarScan-Version: 6.5.10; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27826 invoked from network); 28 Jun 2012 15:17:47 -0000 Received: from unknown (HELO mail.generaldynamics.uk.com) (217.33.196.17) by server-10.tower-90.messagelabs.com with SMTP; 28 Jun 2012 15:17:47 -0000 Received: from mail.generaldynamics.uk.com (HELO gdukadh864.uk1.r-org.net) ([172.16.40.142]) by mail.generaldynamics.uk.com with ESMTP; 28 Jun 2012 16:17:46 +0100 Received: from GDUKADH850.uk1.r-org.net ([172.16.40.138]) by gdukadh864.uk1.r-org.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jun 2012 16:16:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jun 2012 16:16:59 +0100 Message-ID: <83C941F7F59F3F42AC017AD1E650546206D4C3E8@GDUKADH850.uk1.r-org.net> In-Reply-To: <20120628.170310.618791618530311134.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt Thread-Index: Ac1VPyJtRvMH/5/KRVevzkuI5a1NgAAACZkQ References: <20120628130230.GA55885@elstar.local><20120628131213.GA55958@elstar.local><83C941F7F59F3F42AC017AD1E650546206D4C3D4@GDUKADH850.uk1.r-org.net> <20120628.170310.618791618530311134.mbj@tail-f.com> From: To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-OriginalArrivalTime: 28 Jun 2012 15:16:56.0118 (UTC) FILETIME=[0E162560:01CD5541] Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:17:50 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: 28 June 2012 16:03 > To: Jonathan Hansford > Cc: j.schoenwaelder@jacobs-university.de; jeffrey.K.lange@ge.com; > netmod@ietf.org > Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt >=20 > wrote: > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: 28 June 2012 14:12 > > > To: Lange, Jeffrey K (GE Energy); Martin Bjorklund; netmod@ietf.org > > > Subject: Re: [netmod] I-D Action: > > draft-lange-netmod-iana-timezones-00.txt > > > > > > On Thu, Jun 28, 2012 at 03:02:30PM +0200, Juergen Schoenwaelder wrote: > > > > > > > > So that also is a bit arbitrary as well. Should I leave the enums > > in > > > alphabetical order? Or should it match what the zone.tab file does? > > > > > > > > Any order is likely irrelevant over time. See below. > > > > > > > > > > Well, I realize this statement is not really helpful / correct. You > > > can keept the enums defined in the order they are defined in the TZ > > > database but then the value statements MUST be used and the numbers > > > over time won't be assigned in a strictly increasing order. This means > > > that YANG tools can use the definition order (if they are able to > > > access it) or they might end up using the numeric value order, which > > > will over time be increasingly meaningless. > > > > Still learning here, but RFC6087 states: > > > > If extensibility of enumerated values is required, then the > > 'identityref' data type SHOULD be used instead of an enumeration or > > other built-in type. > > > > So why are enums being considered over identityrefs? >=20 > In this case, you really do not want the kind of extensibility that > identities give you - with an identity you get decentralized > extensibility; anyone can add their own new value. That's probably > not what you need for timezones... >=20 Some might want to add military timezones (http://www.worldtimezone.com/wtz-map-military.html). Jonathan >=20 > /martin This email and any files attached are intended for the addressee and may = contain information of a confidential nature. If you are not the intended= recipient, be aware that this email was sent to you in error and you sho= uld not disclose, distribute, print, copy or make other use of this email= or its attachments. Such actions, in fact, may be unlawful. In complianc= e with the various Regulations and Acts, General Dynamics United Kingdom = Limited reserves the right to monitor (and examine for viruses) all email= s and email attachments, both inbound and outbound. Email communications = and their attachments may not be secure or error- or virus-free and the c= ompany does not accept liability or responsibility for such matters or th= e consequences thereof. General Dynamics United Kingdom Limited, Register= ed Office: 21 Holborn Viaduct, London EC1A 2DY. Registered in England and= Wales No: 1911653.=20 From andy@yumaworks.com Thu Jun 28 08:20:55 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260DF21F85FD for ; Thu, 28 Jun 2012 08:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81cnQfU5u+3L for ; Thu, 28 Jun 2012 08:20:54 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B177A21F85FB for ; Thu, 28 Jun 2012 08:20:53 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3522328lbb.31 for ; Thu, 28 Jun 2012 08:20:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=j4BXGtU3c7+9kNw9dpz9nIOATfhXCRbr0XbAoT8ooCc=; b=e9EfbZkDZETESjdHr5J2vNoQTOkbKSozPWX79JN2saZfDcfBOq4lsNzEA8TNPzQ1cV ssby77e9DLU0bsonzV/mnj9YAuVO6Jj5yIjKzoZex0BhmSl/OjBIuJdsC3sqdp4YEXlO 6ceuZGlHURFhziY86siNzURKjlHJ9NCHQ3kyWgrrWeiV/kArwE/DaCLgXg9VjmX/8Jl2 Z/kQX1SWhVn0wVpFMALmEw0CS4boJkjCedqMPnydhHj+oEGmTtVui7fVLAzw/kf4JLqz IHApK3RL1KBU0MEw5yV1jCT04MxKcZ+M3oxavy/nMQh8ChiHdbZIk/+gliZdOqu+Ahpk 0srA== MIME-Version: 1.0 Received: by 10.112.86.166 with SMTP id q6mr1354692lbz.6.1340896849780; Thu, 28 Jun 2012 08:20:49 -0700 (PDT) Received: by 10.114.19.72 with HTTP; Thu, 28 Jun 2012 08:20:49 -0700 (PDT) X-Originating-IP: [75.84.168.164] In-Reply-To: <20120628150821.GC56180@elstar.local> References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> <20120628053120.GA54197@elstar.local> <20120628.103148.991980626356570748.mbj@tail-f.com> <20120628130230.GA55885@elstar.local> <20120628131213.GA55958@elstar.local> <83C941F7F59F3F42AC017AD1E650546206D4C3D4@GDUKADH850.uk1.r-org.net> <20120628150821.GC56180@elstar.local> Date: Thu, 28 Jun 2012 08:20:49 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Jonathan.Hansford@generaldynamics.uk.com, jeffrey.K.lange@ge.com, mbj@tail-f.com, netmod@ietf.org Content-Type: multipart/alternative; boundary=f46d0401faed69607e04c389e007 X-Gm-Message-State: ALoCoQk6eI69HrHqZma7ZYEFfjb11+L6fUGMW47B938lp5OgFXavGrlp1ZF7WmSNxvENaufqbVEh Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:20:55 -0000 --f46d0401faed69607e04c389e007 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 28, 2012 at 8:08 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jun 28, 2012 at 03:58:15PM +0100, > Jonathan.Hansford@generaldynamics.uk.com wrote: > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: 28 June 2012 14:12 > > > To: Lange, Jeffrey K (GE Energy); Martin Bjorklund; netmod@ietf.org > > > Subject: Re: [netmod] I-D Action: > > draft-lange-netmod-iana-timezones-00.txt > > > > > > On Thu, Jun 28, 2012 at 03:02:30PM +0200, Juergen Schoenwaelder wrote: > > > > > > > > So that also is a bit arbitrary as well. Should I leave the enums > > in > > > alphabetical order? Or should it match what the zone.tab file does? > > > > > > > > Any order is likely irrelevant over time. See below. > > > > > > > > > > Well, I realize this statement is not really helpful / correct. You > > > can keept the enums defined in the order they are defined in the TZ > > > database but then the value statements MUST be used and the numbers > > > over time won't be assigned in a strictly increasing order. This means > > > that YANG tools can use the definition order (if they are able to > > > access it) or they might end up using the numeric value order, which > > > will over time be increasingly meaningless. > > > > Still learning here, but RFC6087 states: > > > > If extensibility of enumerated values is required, then the > > 'identityref' data type SHOULD be used instead of an enumeration or > > other built-in type. > > > > So why are enums being considered over identityrefs? > > Because that was proposed on the list. ;-) > Wonder who proposed it? :-) I can't change ietf-system.yang to import this typedef until the document is accepted as a WG document, so the new version about to be published will not use it yet -- unless the WG can adopt this document via the mailing list. I haven't seen any objections, and all issues have been addressed (within scope of this WG). > /js > Andy --f46d0401faed69607e04c389e007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jun 28, 2012 at 8:08 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jun 28, 2012 at 03:58:15PM +0100, Jonathan.Hansford= @generaldynamics.uk.com wrote:
> > -----Original Message-----
> > From: Juergen Schoenwaelder
> [mailto:j.scho= enwaelder@jacobs-university.de]
> > Sent: 28 June 2012 14:12
> > To: Lange, Jeffrey K (GE Energy); Martin Bjorklund; netmod@ietf.org
> > Subject: Re: [netmod] I-D Action:
> draft-lange-netmod-iana-timezones-00.txt
> >
> > On Thu, Jun 28, 2012 at 03:02:30PM +0200, Juergen Schoenwaelder w= rote:
> >
> > > > So that also is a bit arbitrary as well. =A0Should I le= ave the enums
> in
> > alphabetical order? Or should it match what the zone.tab file doe= s?
> > >
> > > Any order is likely irrelevant over time. See below.
> > >
> >
> > Well, I realize this statement is not really helpful / correct. Y= ou
> > can keept the enums defined in the order they are defined in the = TZ
> > database but then the value statements MUST be used and the numbe= rs
> > over time won't be assigned in a strictly increasing order. T= his means
> > that YANG tools can use the definition order (if they are able to=
> > access it) or they might end up using the numeric value order, wh= ich
> > will over time be increasingly meaningless.
>
> Still learning here, but RFC6087 states:
>
> If extensibility of enumerated values is required, then the
> 'identityref' data type SHOULD be used instead of an enumerati= on or
> other built-in type.
>
> So why are enums being considered over identityrefs?

Because that was proposed on the list. ;-)

<= div>
Wonder who proposed it? =A0:-)

= I can't change ietf-system.yang to import this typedef until
the document is accepted as a WG document, so the new
version abo= ut to be published will not use it yet --
unless the WG can adopt= this document via the mailing list.

I haven't= seen any objections, and all issues have been addressed
(within scope of this WG).



/js

Andy

--f46d0401faed69607e04c389e007-- From jeffrey.K.lange@ge.com Thu Jun 28 08:26:26 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D486321F8637 for ; Thu, 28 Jun 2012 08:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.295 X-Spam-Level: X-Spam-Status: No, score=-6.295 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NThTJiqkeXoP for ; Thu, 28 Jun 2012 08:26:26 -0700 (PDT) Received: from exprod5og103.obsmtp.com (exprod5og103.obsmtp.com [64.18.0.145]) by ietfa.amsl.com (Postfix) with ESMTP id 659C021F8636 for ; Thu, 28 Jun 2012 08:26:25 -0700 (PDT) Received: from alpmlip13.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob103.postini.com ([64.18.4.12]) with SMTP ID DSNKT+x3oJLzfoMUAkbufhIwiooCeCxHKShJ@postini.com; Thu, 28 Jun 2012 08:26:25 PDT Received: from unknown (HELO cinmlef09.e2k.ad.ge.com) ([3.159.213.56]) by alpmlip13.e2k.ad.ge.com with ESMTP; 28 Jun 2012 11:26:23 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef09.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jun 2012 11:26:23 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jun 2012 11:26:22 -0400 Received: from CINMBCNA04.e2k.ad.ge.com (3.159.212.58) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.283.3; Thu, 28 Jun 2012 11:26:22 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.71]) by CINMBCNA04.e2k.ad.ge.com ([169.254.4.136]) with mapi id 14.02.0283.003; Thu, 28 Jun 2012 11:26:22 -0400 From: "Lange, Jeffrey K (GE Energy)" To: Andy Bierman , Juergen Schoenwaelder , "Jonathan.Hansford@generaldynamics.uk.com" , "mbj@tail-f.com" , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt Thread-Index: AQHNVO9Trc0EvVJrbkCzilxixtCsc5cPqhoAgAAAG6CAAEuHAIAAAreAgAAdoICAAALUgIAAA3qA//++DtA= Date: Thu, 28 Jun 2012 15:26:21 +0000 Message-ID: References: <20120627223703.1415.77965.idtracker@ietfa.amsl.com> <20120628053120.GA54197@elstar.local> <20120628.103148.991980626356570748.mbj@tail-f.com> <20120628130230.GA55885@elstar.local> <20120628131213.GA55958@elstar.local> <83C941F7F59F3F42AC017AD1E650546206D4C3D4@GDUKADH850.uk1.r-org.net> <20120628150821.GC56180@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA6C82CINMBCNA02e2kad_" MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jun 2012 15:26:22.0733 (UTC) FILETIME=[5FD0BBD0:01CD5542] Subject: Re: [netmod] I-D Action: draft-lange-netmod-iana-timezones-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:26:27 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA6C82CINMBCNA02e2kad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >Because that was proposed on the list. ;-) > > >Wonder who proposed it? :-) > >I can't change ietf-system.yang to import this typedef until >the document is accepted as a WG document, so the new >version about to be published will not use it yet -- >unless the WG can adopt this document via the mailing list. > >I haven't seen any objections, and all issues have been addressed >(within scope of this WG). > >Andy I have just submitted version -01 of draft-lange-netmod-iana-timezones tha= t hopefully should address most of the issues raised on the list. -Jeff --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA6C82CINMBCNA02e2kad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>Because tha= t was proposed on the list. ;-)

> =

> =

>Wonder who = proposed it?  :-)

> =

>I can't cha= nge ietf-system.yang to import this typedef until

>the documen= t is accepted as a WG document, so the new

>version abo= ut to be published will not use it yet --

>unless the = WG can adopt this document via the mailing list.

> =

>I haven't s= een any objections, and all issues have been addressed

>(within sco= pe of this WG).

> =

>Andy

 <= /p>

I have just submitted ver= sion -01 of  draft-lange-netmod-iana-timezones that hopefully should a= ddress most of the issues raised on the list.

 <= /p>

-Jeff

 <= /p>

--_000_B0FB1FAC2C7B234D87DCEBF309F703C51BAA6C82CINMBCNA02e2kad_-- From ietfc@btconnect.com Thu Jun 28 08:53:41 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ACE21F853D for ; Thu, 28 Jun 2012 08:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.776 X-Spam-Level: X-Spam-Status: No, score=-3.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKPAGEm8ulGs for ; Thu, 28 Jun 2012 08:53:40 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9975721F8530 for ; Thu, 28 Jun 2012 08:53:40 -0700 (PDT) Received: from mail99-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Jun 2012 15:51:53 +0000 Received: from mail99-ch1 (localhost [127.0.0.1]) by mail99-ch1-R.bigfish.com (Postfix) with ESMTP id 5CA74400427; Thu, 28 Jun 2012 15:51:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT008.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah304l) Received: from mail99-ch1 (localhost.localdomain [127.0.0.1]) by mail99-ch1 (MessageSwitch) id 1340898711722670_27737; Thu, 28 Jun 2012 15:51:51 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail99-ch1.bigfish.com (Postfix) with ESMTP id A46638005E; Thu, 28 Jun 2012 15:51:51 +0000 (UTC) Received: from DB3PRD0702HT008.eurprd07.prod.outlook.com (157.55.224.141) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Jun 2012 15:51:50 +0000 Received: from DB3PRD0410HT003.eurprd04.prod.outlook.com (157.56.252.21) by pod51017.outlook.com (10.3.4.173) with Microsoft SMTP Server (TLS) id 14.15.86.1; Thu, 28 Jun 2012 15:53:28 +0000 Message-ID: <00e501cd5545$a85a3180$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Martin Bjorklund References: <20120627152154.GB52020@elstar.jacobs.jacobs-university.de><20120627.175147.457776630.mbj@tail-f.com> Date: Thu, 28 Jun 2012 16:49:46 +0100 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.21] X-OriginatorOrg: btconnect.com Cc: netmod@ietf.org Subject: Re: [netmod] iana-timezones.yang proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 15:53:41 -0000 ----- Original Message ----- From: "Andy Bierman" To: "Martin Bjorklund" Cc: Sent: Thursday, June 28, 2012 3:38 PM > .... > > > > > > > I'm confused. > > > So what will happen with draft-ietf-netmod-iana-if-type-04? > > > Isn't it going to be published as an RFC? > > > > Yes. This is the process to hand over an initial module to IANA. > > From there, IANA maintains the YANG module, and publishes new > > revisions on their web site. Just like they do with IF-MIB. No new > > RFCs are published. > > > This is fine I guess, as long as the IANA update announcement > goes to the same mailing list as an RFC announcement. > > In general this approach has a conformance flaw -- normative references. > In the referencing document really intends that a specific version (or > later) > be used of the registry, there is no way to do that. The normative RFC > reference is the same for all versions of the registry. Andy Some IANA registries are updated only by Standards track RFC, in which case you see the RFC. Others are updated by, eg, Expert Review, in which case there is no RFC and, AFAIK, no IANA announcement. But the RFC that initiates the registry should state what is involved in the expert review, who does what, what discussion or notification should take place on what lists before a registry is updated. This happens in the nexus of URI schemes, e-mail, Content-types and such like. But once there is a IANA registry, then that is the Normative definition of it, references to it by URL as for any other website; and yes you can associate a date with it, to ensure that a previous version of the web page is used, not something that is often done in the IETF but is there to be used. So you can make any rule you want about updating it - eg insist that the registry contains a version number updated by one every time the contents change - provided you get it into that initial RFC in a form that IANA can understand and action; and if IANA have any problems, they flag them early, as at IETF Last Call. Tom Petch > > > /martin > > > > > Andy From j.schoenwaelder@jacobs-university.de Thu Jun 28 14:55:07 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF0811E80C7 for ; Thu, 28 Jun 2012 14:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLTgbbQk9qau for ; Thu, 28 Jun 2012 14:55:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B322911E80C6 for ; Thu, 28 Jun 2012 14:55:06 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 095B820C07; Thu, 28 Jun 2012 23:55:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kithIBWqfAP8; Thu, 28 Jun 2012 23:55:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A19BB20C1D; Thu, 28 Jun 2012 23:55:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 65097202FB4A; Thu, 28 Jun 2012 23:55:04 +0200 (CEST) Date: Thu, 28 Jun 2012 23:55:04 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20120628215504.GA57255@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] ietf 84 wg session X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 21:55:07 -0000 Hi, the draft agenda for the IETF 84 in Vancouver meeting is out. https://datatracker.ietf.org/meeting/84/agenda.txt The NETMOD session (1:30:00) has been scheduled as follows: Tuesday, Afternoon Session III 1700-1830 Room Name: Regency B NETCONF is currently scheduled for Monday 1540-1710. Note that the IETF agenda is still subject to changes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Fri Jun 29 05:01:29 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4963921F86FA for ; Fri, 29 Jun 2012 05:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2rxkI9E9CEm for ; Fri, 29 Jun 2012 05:01:28 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id AEE3321F86F7 for ; Fri, 29 Jun 2012 05:01:13 -0700 (PDT) Received: from localhost (213-65-181-96-no181.tbcn.telia.com [213.65.181.96]) by mail.tail-f.com (Postfix) with ESMTPSA id 8BC861200A6E for ; Fri, 29 Jun 2012 14:00:56 +0200 (CEST) Date: Fri, 29 Jun 2012 14:00:55 +0200 (CEST) Message-Id: <20120629.140055.94907899.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20120628.124255.2194135616541986952.mbj@tail-f.com> References: <20120627.215727.304709352.mbj@tail-f.com> <20120628.124255.2194135616541986952.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] Static addr mapping (Was: review of draft-ietf-netmod-ip-cfg-03) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 12:01:29 -0000 Hi, So far, I have not seen a single reply in favor of adding this feature to the data model, so right now it seems to me we should not add this. /martin Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On Jun 27, 2012, at 9:57 PM, Martin Bjorklund wrote: > > > > > With some input from Juergen, here's a sketch of a data model to > > > configure static ip-to-link-layer mappings, one for ipv4 and one for > > > ipv6: > > > > > > augment "/if:interfaces/if:interface" { > > > container ipv4 { > > > // as currently defined in the draft > > > ... > > > list arp { // name? > > > key "ip"; > > > // entries end up as static arp cache entries > > > leaf ip { > > > type inet:ipv4-address; > > > } > > > leaf phys-address { > > > type yang:phys-address; > > > } > > > } > > > } > > > container ipv6 { > > > // as currently defined in the draft > > > ... > > > list neighbor { // name? > > > key "ip"; > > > // entries end up as static neighbor cache entries > > > leaf ip { > > > type inet:ipv6-address; > > > } > > > leaf phys-address { > > > type yang:phys-address; > > > } > > > } > > > } > > > } > > > > > > So, what do people think? Should something like this be included in > > > this data model? It seems most OSes / systems implement this > > > functionality, and it is supported in the IP-MIB. > > First of all - do you think we should add something like this to the > configuration model? I know you have talked about adding the neighbor > cache, but I always thought you meant only monitoring of the neighbor > cache. > > > As we discussed earlier, implementations allow for configuring static > > ARP or neighbor cache entries either globally (IOS, *BSD) or per > > interface (JUNOS), and some allow both (Linux). By having this > > configuration under "if:interface" we are losing the former option. So > > I would prefer the global variant, which is more general because each > > entry can contain an "interface-ref" leaf to make the entry > > interface-specific. > > In Junos it is even configured per address (subnet) per interface. > This makes sense since if you configure a mapping for an IP address > that is not part of your subnets, this mapping will never be used. In > fact, also linux checks that the static arp entry belongs to your > subnet. > > I didn't want to put it under address, since this would require you to > configure a static address - OTOH on systems where you use static arp > entries you probably also use static IP addresses... > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From calle@tail-f.com Fri Jun 29 05:33:53 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE3521F873A for ; Fri, 29 Jun 2012 05:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHk3qNiPbJfZ for ; Fri, 29 Jun 2012 05:33:52 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4B15621F8724 for ; Fri, 29 Jun 2012 05:33:52 -0700 (PDT) Received: from calle-macbook.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E1E291200AC8; Fri, 29 Jun 2012 14:33:50 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Carl Moberg In-Reply-To: <20120629.140055.94907899.mbj@tail-f.com> Date: Fri, 29 Jun 2012 14:33:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45DE2CD0-DBB4-470D-A4BB-E71787B3E56F@tail-f.com> References: <20120627.215727.304709352.mbj@tail-f.com> <20120628.124255.2194135616541986952.mbj@tail-f.com> <20120629.140055.94907899.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1278) Cc: netmod@ietf.org Subject: Re: [netmod] Static addr mapping (Was: review of draft-ietf-netmod-ip-cfg-03) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 12:33:53 -0000 I'll bite. I think we should add this feature to the data models since = I believe there are use cases for it in VM-heavy data centers where = dynamic ARP processes need to be kept to a bare minimum. I think that = case is important enough and since the feature is supported in most = mainstream OSes I think it should go into the standard model. On Jun 29, 2012, at 14:00 PM, Martin Bjorklund wrote: > Hi, >=20 > So far, I have not seen a single reply in favor of adding this feature > to the data model, so right now it seems to me we should not add this. >=20 >=20 > /martin >=20 >=20 >=20 >=20 > Martin Bjorklund wrote: >> Ladislav Lhotka wrote: >>>=20 >>> On Jun 27, 2012, at 9:57 PM, Martin Bjorklund wrote: >>>=20 >>>> With some input from Juergen, here's a sketch of a data model to >>>> configure static ip-to-link-layer mappings, one for ipv4 and one = for >>>> ipv6: >>>>=20 >>>> augment "/if:interfaces/if:interface" { >>>> container ipv4 { >>>> // as currently defined in the draft >>>> ... >>>> list arp { // name? >>>> key "ip"; >>>> // entries end up as static arp cache entries >>>> leaf ip { >>>> type inet:ipv4-address; >>>> } >>>> leaf phys-address { >>>> type yang:phys-address; >>>> } >>>> } >>>> } >>>> container ipv6 { >>>> // as currently defined in the draft >>>> ... >>>> list neighbor { // name? >>>> key "ip"; >>>> // entries end up as static neighbor cache entries >>>> leaf ip { >>>> type inet:ipv6-address; >>>> } >>>> leaf phys-address { >>>> type yang:phys-address; >>>> } >>>> } >>>> } >>>> } =20 >>>>=20 >>>> So, what do people think? Should something like this be included = in >>>> this data model? It seems most OSes / systems implement this >>>> functionality, and it is supported in the IP-MIB. >>=20 >> First of all - do you think we should add something like this to the >> configuration model? I know you have talked about adding the = neighbor >> cache, but I always thought you meant only monitoring of the neighbor >> cache. >>=20 >>> As we discussed earlier, implementations allow for configuring = static >>> ARP or neighbor cache entries either globally (IOS, *BSD) or per >>> interface (JUNOS), and some allow both (Linux). By having this >>> configuration under "if:interface" we are losing the former option. = So >>> I would prefer the global variant, which is more general because = each >>> entry can contain an "interface-ref" leaf to make the entry >>> interface-specific. >>=20 >> In Junos it is even configured per address (subnet) per interface. >> This makes sense since if you configure a mapping for an IP address >> that is not part of your subnets, this mapping will never be used. = In >> fact, also linux checks that the static arp entry belongs to your >> subnet. >>=20 >> I didn't want to put it under address, since this would require you = to >> configure a static address - OTOH on systems where you use static arp >> entries you probably also use static IP addresses... >>=20 >>=20 >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Carl Moberg, Tail-f Systems mailto:calle@tail-f.com twitter: @cmoberg http://www.tail-f.com/ From lhotka@nic.cz Fri Jun 29 07:51:56 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474E621F8749 for ; Fri, 29 Jun 2012 07:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5JYHnkyCd6m for ; Fri, 29 Jun 2012 07:51:29 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9E74821F8747 for ; Fri, 29 Jun 2012 07:51:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id A623C54040C for ; Fri, 29 Jun 2012 16:51:27 +0200 (CEST) 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 Y2RAeI8fNMZT for ; Fri, 29 Jun 2012 16:51:21 +0200 (CEST) Received: from localhost (birdie-w.lhotkovi.cz [172.29.2.202]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E2484540011 for ; Fri, 29 Jun 2012 16:51:20 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20120628114406.GA55096@elstar.local> References: <20120627091116.GA48378@elstar.local> <20120627.215727.304709352.mbj@tail-f.com> <20120628.124255.2194135616541986952.mbj@tail-f.com> <5FAD8474-4F90-4106-8464-AA4ECB10FDFC@nic.cz> <20120628114406.GA55096@elstar.local> User-Agent: Notmuch/0.12+113~gde05574 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Fri, 29 Jun 2012 16:51:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] review of draft-ietf-netmod-ip-cfg-03 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 14:51:56 -0000 Juergen Schoenwaelder writes: > On Thu, Jun 28, 2012 at 01:13:22PM +0200, Ladislav Lhotka wrote: >> >> >> ARP entries represent information about external devices, so it is >> not a property of a particular interface. The linkage to an >> interface is only indirect - without having an interface on the same >> IP subnet, the local device has no way for using that information. > > I would argue that the mapping information is only valid on a certain > interface. I have never seen arp entries that are not associated to an > interface. The IP subnet linkage does not seem to really exist, at > least not on Linux. And if you do strange proxyarp stuff, you might > even do proxyarp for devices that do not belong to the subnet you are > using on that specific interface. Yes, you are right, each neighbour entry is indeed associated with an interface. Looking into kernel source, the neigh_create() function has a "dev" parameter which is a pointer to a device/interface. Sorry for the noise. I now support the neigbour discovery additions proposed by Martin. Lada > >> A device may also have multiple connections to the same subnet, and >> then the ARP entry should be equally valid for all connected >> interfaces. > > I would have to try this to see what kernels really do. I assume they > use the interface specific mapping and might likely have duplicate > entries in the arp table for the different interfaces. > > /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 From internet-drafts@ietf.org Sat Jun 30 15:36:57 2012 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01CB21F855B; Sat, 30 Jun 2012 15:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-IpzAHaBqTh; Sat, 30 Jun 2012 15:36:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0714E21F84F2; Sat, 30 Jun 2012 15:36:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120630223627.12013.54961.idtracker@ietfa.amsl.com> Date: Sat, 30 Jun 2012 15:36:27 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 22:36:58 -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 : YANG Data Model for System Management Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-01.txt Pages : 31 Date : 2012-06-30 Abstract: This document defines a YANG data model for the configuration and identification of the management system of a device. 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-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/