From lhotka@cesnet.cz Tue Nov 1 06:56:33 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35F01F0C72 for ; Tue, 1 Nov 2011 06:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irl24eR-2B6X for ; Tue, 1 Nov 2011 06:56:30 -0700 (PDT) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by ietfa.amsl.com (Postfix) with ESMTP id D9E6F11E8163 for ; Tue, 1 Nov 2011 06:56:29 -0700 (PDT) Received: from localhost (jaromir.lhotkovi.cz [172.29.2.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id CB820DC005B; Tue, 1 Nov 2011 14:56:30 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20111028.141955.488159309.mbj@tail-f.com> References: <20111028.141955.488159309.mbj@tail-f.com> User-Agent: Notmuch/0.9 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Tue, 01 Nov 2011 14:56:26 +0100 Message-ID: <87wrbkhrp1.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] ip config issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:56:33 -0000 On Fri, 28 Oct 2011 14:19:55 +0200 (CEST), Martin Bjorklund wrote: > Hi, > > I have posted a new version (-01) of the ip-config draft. It is now > possible to configure non-contiguous netmasks, as discussed > previously. > > There are a couple of other issues, not yet handled. > > * ip-01 primary, secondary, and preferred address > > Lada suggested that we need to specify the primary address on an > interface, and he pointed to the solution of two router vendors for > doing this. Phil sent some links to Juniper's documentation. > > It seems to be that these two vendors have the same terminology, but > different meaning of the term "primary address". In one case it > seems to be the source address used for all outgoing packets on the > interface, and in the other it seems to be the source address used > for outgoing multi- and broadcast (?) packets. > > Phil also mentioned "preferred address", which seems to be the > source address used for outgoing unicast packets on the *subnet* > (i.e., there can be one "preferred address" per subnet on an > interface (I think)). The last feature is IMO somewhat esoteric, but it shows how difficult it will be to find a common denominator even for the few most popular platforms. And here we are dealing with very basic stuff. > > So it seems there are two concepts here: > > default source on interface > > default source in subnet > > Q. Is my understanding correct? > > Q. If it is, do we need any, both, or more of these concepts? > > > * ip-02 iv6 auto-link-local-address leaf > > Lada suggested that maybe there should be a way to tell the server > to not automatically assign a link-local unicast address for an ipv6 > interface. > > Q. Is this a useful (and implementable) parameter? Hmm, probably it is not a good idea at all because the link-local address is used e.g. in neighbor discovery, so it could break IPv6 operation. What could be useful is a switch for enabling/disabling stateless address autoconfiguration, as it is done e.g. in Linux via /proc/sys/net/ipv6/conf//accept_ra Lada > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Nov 1 07:26:13 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E0421F9852 for ; Tue, 1 Nov 2011 07:26:13 -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 CkT6CmFY7sLf for ; Tue, 1 Nov 2011 07:26: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 C1F3021F9850 for ; Tue, 1 Nov 2011 07:26:05 -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 15B971200100; Tue, 1 Nov 2011 15:26:04 +0100 (CET) Date: Tue, 01 Nov 2011 15:26:03 +0100 (CET) Message-Id: <20111101.152603.1491671184180529616.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <87wrbkhrp1.fsf@cesnet.cz> References: <20111028.141955.488159309.mbj@tail-f.com> <87wrbkhrp1.fsf@cesnet.cz> 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] ip config issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 14:26:13 -0000 Ladislav Lhotka wrote: > On Fri, 28 Oct 2011 14:19:55 +0200 (CEST), Martin Bjorklund wrote: > > Hi, > > > > I have posted a new version (-01) of the ip-config draft. It is now > > possible to configure non-contiguous netmasks, as discussed > > previously. > > > > There are a couple of other issues, not yet handled. > > > > * ip-01 primary, secondary, and preferred address > > > > Lada suggested that we need to specify the primary address on an > > interface, and he pointed to the solution of two router vendors for > > doing this. Phil sent some links to Juniper's documentation. > > > > It seems to be that these two vendors have the same terminology, but > > different meaning of the term "primary address". In one case it > > seems to be the source address used for all outgoing packets on the > > interface, and in the other it seems to be the source address used > > for outgoing multi- and broadcast (?) packets. > > > > Phil also mentioned "preferred address", which seems to be the > > source address used for outgoing unicast packets on the *subnet* > > (i.e., there can be one "preferred address" per subnet on an > > interface (I think)). > > The last feature is IMO somewhat esoteric, but it shows how difficult it > will be to find a common denominator even for the few most popular > platforms. And here we are dealing with very basic stuff. Is it esoteric? It seems quite useful to me. We need to define a model that is useful, but not too limiting for people that want to add esoteric stuff. But I am still not sure my understanding of these parameters is correct. > > * ip-02 iv6 auto-link-local-address leaf > > > > Lada suggested that maybe there should be a way to tell the server > > to not automatically assign a link-local unicast address for an ipv6 > > interface. > > > > Q. Is this a useful (and implementable) parameter? > > Hmm, probably it is not a good idea at all because the link-local > address is used e.g. in neighbor discovery, so it could break IPv6 > operation. Well, if we had a auto-link-local-address leaf, we would require the operator to configure a link-local address manually, if he sets auto-link-local-address to false. > What could be useful is a switch for enabling/disabling stateless address > autoconfiguration This would include the link-local address, right? Also, RFC 4862 require a configuration variable DupAddrDetectTransmits. Should we also add an 'enabled' leaf under ipv6, so that if ipv6 is enabled, by default the address autoconfiguration process runs and assigns a link-local address? /martin From phil@juniper.net Tue Nov 1 08:25:55 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A898E21F8CD9 for ; Tue, 1 Nov 2011 08:25:55 -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 E3RFHs6PkBLz for ; Tue, 1 Nov 2011 08:25:55 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0C721F8CCB for ; Tue, 1 Nov 2011 08:25:51 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP; Tue, 01 Nov 2011 08:25:55 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 1 Nov 2011 08:21:29 -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 pA1FLRh37460; Tue, 1 Nov 2011 08:21:28 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id pA1Er51o053359; Tue, 1 Nov 2011 14:53:05 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201111011453.pA1Er51o053359@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <87wrbkhrp1.fsf@cesnet.cz> Date: Tue, 1 Nov 2011 10:53:05 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] ip config issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 15:25:55 -0000 Ladislav Lhotka writes: >The last feature is IMO somewhat esoteric, but it shows how difficult it >will be to find a common denominator even for the few most popular >platforms. And here we are dealing with very basic stuff. A lot of flags like this seem esoteric until you find out the number of customers that use them ;^) >> So it seems there are two concepts here: >> default source on interface >> default source in subnet I think there's a default for the subnet and multiple subnets per interface, and the only way go out an interface is either a subnet-based route or an interface-specific request ("ping 10.1.1.1 interface fe-1/1/1"), so you need both. You also need the idea of a default address for the entire device, which is also in the strange-but-not-rare category. Thanks, Phil From lhotka@cesnet.cz Tue Nov 1 09:51:59 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DD821F8FE4 for ; Tue, 1 Nov 2011 09:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1dZCjnyxwDK for ; Tue, 1 Nov 2011 09:51:58 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 8A31F21F8FE0 for ; Tue, 1 Nov 2011 09:51:58 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id 272522CDE05C; Tue, 1 Nov 2011 17:51:47 +0100 (CET) Message-ID: <4EB023A3.5060109@cesnet.cz> Date: Tue, 01 Nov 2011 17:51:47 +0100 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <20111028.141955.488159309.mbj@tail-f.com> <87wrbkhrp1.fsf@cesnet.cz> <20111101.152603.1491671184180529616.mbj@tail-f.com> In-Reply-To: <20111101.152603.1491671184180529616.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] ip config issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 16:51:59 -0000 Dne 1.11.2011 15:26, Martin Bjorklund napsal(a): > Ladislav Lhotka wrote: >> On Fri, 28 Oct 2011 14:19:55 +0200 (CEST), Martin Bjorklund wrote: >>> Hi, >>> >>> I have posted a new version (-01) of the ip-config draft. It is now >>> possible to configure non-contiguous netmasks, as discussed >>> previously. >>> >>> There are a couple of other issues, not yet handled. >>> >>> * ip-01 primary, secondary, and preferred address >>> >>> Lada suggested that we need to specify the primary address on an >>> interface, and he pointed to the solution of two router vendors for >>> doing this. Phil sent some links to Juniper's documentation. >>> >>> It seems to be that these two vendors have the same terminology, but >>> different meaning of the term "primary address". In one case it >>> seems to be the source address used for all outgoing packets on the >>> interface, and in the other it seems to be the source address used >>> for outgoing multi- and broadcast (?) packets. >>> >>> Phil also mentioned "preferred address", which seems to be the >>> source address used for outgoing unicast packets on the *subnet* >>> (i.e., there can be one "preferred address" per subnet on an >>> interface (I think)). >> The last feature is IMO somewhat esoteric, but it shows how difficult it >> will be to find a common denominator even for the few most popular >> platforms. And here we are dealing with very basic stuff. > Is it esoteric? It seems quite useful to me. Well, I have never seen multiple addresses belonging to the same IP subnet configured on the same interface. But I have also never seen non-contiguous netmasks - I do admit academic networking is special. > > We need to define a model that is useful, but not too limiting for > people that want to add esoteric stuff. Yes, but there is potentially no end of esoteric features, knobs, bells and whistles, so perhaps we can leave such stuff to vendors who want to please their customers and also to differentiate from their competitors. At the end of the day, I think we will have to determine - actually for all modules we aim to develop - what is the canonical "IETF configuration model" for the given subsystem, otherwise we may never get to an end. > > But I am still not sure my understanding of these parameters is > correct. > > >>> * ip-02 iv6 auto-link-local-address leaf >>> >>> Lada suggested that maybe there should be a way to tell the server >>> to not automatically assign a link-local unicast address for an ipv6 >>> interface. >>> >>> Q. Is this a useful (and implementable) parameter? >> Hmm, probably it is not a good idea at all because the link-local >> address is used e.g. in neighbor discovery, so it could break IPv6 >> operation. > Well, if we had a auto-link-local-address leaf, we would require the > operator to configure a link-local address manually, if he sets > auto-link-local-address to false. Yes, but I don't really see any motivation for doing so. Is there any implementation that allows this? > >> What could be useful is a switch for enabling/disabling stateless address >> autoconfiguration > This would include the link-local address, right? Also, RFC 4862 > require a configuration variable DupAddrDetectTransmits. I mean addresses configured from router advertisements, I don't know whether they can include link-local addresses (I doubt it). > > Should we also add an 'enabled' leaf under ipv6, so that if > ipv6 is enabled, by default the address autoconfiguration process runs > and assigns a link-local address? What's normally done is that if IPv6 is enabled, a link-local address is configured for each interface and hosts (not routers) also accept RAs from which they configure a global address and default route. But while listening to RAs may be disabled even for hosts, I am not sure it is possible to disable creation of EUI-64-based LL addresses. What about making "ipv6" a presence container? If it is present, LL address would be configured on that interface. Lada > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Tue Nov 1 10:14:10 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527D01F0CC4 for ; Tue, 1 Nov 2011 10:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 DiUyV23NeVqq for ; Tue, 1 Nov 2011 10:14:09 -0700 (PDT) Received: from omr2.networksolutionsemail.com (omr2.networksolutionsemail.com [205.178.146.52]) by ietfa.amsl.com (Postfix) with ESMTP id B106E1F0CC3 for ; Tue, 1 Nov 2011 10:14:09 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr2.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id pA1HCPI3022029 for ; Tue, 1 Nov 2011 13:12:27 -0400 Authentication-Results: cm-omr9 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:35219] helo=[192.168.0.9]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 8B/B4-02416-87820BE4; Tue, 01 Nov 2011 13:12:25 -0400 Message-ID: <4EB02878.30701@andybierman.com> Date: Tue, 01 Nov 2011 10:12:24 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ladislav Lhotka References: <20111028.141955.488159309.mbj@tail-f.com> <87wrbkhrp1.fsf@cesnet.cz> <20111101.152603.1491671184180529616.mbj@tail-f.com> <4EB023A3.5060109@cesnet.cz> In-Reply-To: <4EB023A3.5060109@cesnet.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ip config issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 17:14:10 -0000 On 11/01/2011 09:51 AM, Ladislav Lhotka wrote: > Dne 1.11.2011 15:26, Martin Bjorklund napsal(a): >> Ladislav Lhotka wrote: ... >> >> We need to define a model that is useful, but not too limiting for >> people that want to add esoteric stuff. > > Yes, but there is potentially no end of esoteric features, knobs, bells and whistles, so perhaps we can leave such stuff to vendors who want to please their customers and also to differentiate from > their competitors. At the end of the day, I think we will have to determine - actually for all modules we aim to develop - what is the canonical "IETF configuration model" for the given subsystem, > otherwise we may never get to an end. > ... I agree with Lada. The first order problem is "what to standardize". Our goal is to do common things in a common way. If at least two vendors roughly agree to implement a knob then it may be worth standardizing. If zero or one vendor is willing to implement the knob, then why bother standardizing it? We have YANG augment-stmt for a reason. > Lada > >> >> >> /martin > > Andy From mbj@tail-f.com Tue Nov 1 11:45:11 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B3921F9B0D for ; Tue, 1 Nov 2011 11:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.232, 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 FSTHBYyyBDbQ for ; Tue, 1 Nov 2011 11:45:11 -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 4C9B521F9B0C for ; Tue, 1 Nov 2011 11:45:11 -0700 (PDT) Received: from localhost (unknown [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A68B11200100; Tue, 1 Nov 2011 19:44:31 +0100 (CET) Date: Tue, 01 Nov 2011 19:44:30 +0100 (CET) Message-Id: <20111101.194430.376899300.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4EB02878.30701@andybierman.com> References: <20111101.152603.1491671184180529616.mbj@tail-f.com> <4EB023A3.5060109@cesnet.cz> <4EB02878.30701@andybierman.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] ip config issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 18:45:11 -0000 Andy Bierman wrote: > I agree with Lada. > The first order problem is "what to standardize". > Our goal is to do common things in a common way. Absolutely! In this particular case, the problem ("primary address") was brought up by Lada, and Phil acknowledged the need for it, so it makes sense to discuss it. /martin From ietf@andybierman.com Tue Nov 1 12:54:06 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE561F0C36 for ; Tue, 1 Nov 2011 12:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 uEUkXyJvLAax for ; Tue, 1 Nov 2011 12:54:05 -0700 (PDT) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by ietfa.amsl.com (Postfix) with ESMTP id 527B71F0CD5 for ; Tue, 1 Nov 2011 12:54:05 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id pA1JoFj2011659 for ; Tue, 1 Nov 2011 15:50:15 -0400 Authentication-Results: cm-omr5 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:36761] helo=[192.168.0.9]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 2A/08-05735-77D40BE4; Tue, 01 Nov 2011 15:50:15 -0400 Message-ID: <4EB04D76.1000805@andybierman.com> Date: Tue, 01 Nov 2011 12:50:14 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Martin Bjorklund References: <20111101.152603.1491671184180529616.mbj@tail-f.com> <4EB023A3.5060109@cesnet.cz> <4EB02878.30701@andybierman.com> <20111101.194430.376899300.mbj@tail-f.com> In-Reply-To: <20111101.194430.376899300.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] ip config issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:54:06 -0000 On 11/01/2011 11:44 AM, Martin Bjorklund wrote: > Andy Bierman wrote: >> I agree with Lada. >> The first order problem is "what to standardize". >> Our goal is to do common things in a common way. > > Absolutely! In this particular case, the problem ("primary address") > was brought up by Lada, and Phil acknowledged the need for it, so it > makes sense to discuss it. > OK -- I think multiple vendors support this under different names. I think in general it is good to gauge implementation interest for everything wrt/ [mandatory, if-feature, optional, deferred, rejected] status. > > > /martin > > Andy From lhotka@cesnet.cz Thu Nov 3 01:26:07 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAF31F0C93 for ; Thu, 3 Nov 2011 01:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx91KsuxZm1H for ; Thu, 3 Nov 2011 01:26:06 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 71B5E1F0C92 for ; Thu, 3 Nov 2011 01:26:06 -0700 (PDT) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id 17E882CDE05D; Thu, 3 Nov 2011 09:26:05 +0100 (CET) Message-ID: <4EB2501C.9070202@cesnet.cz> Date: Thu, 03 Nov 2011 09:26:04 +0100 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <20111101.152603.1491671184180529616.mbj@tail-f.com> <4EB023A3.5060109@cesnet.cz> <4EB02878.30701@andybierman.com> <20111101.194430.376899300.mbj@tail-f.com> In-Reply-To: <20111101.194430.376899300.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] ip config issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 08:26:07 -0000 Dne 1.11.2011 19:44, Martin Bjorklund napsal(a): > Andy Bierman wrote: >> I agree with Lada. >> The first order problem is "what to standardize". >> Our goal is to do common things in a common way. > Absolutely! In this particular case, the problem ("primary address") > was brought up by Lada, and Phil acknowledged the need for it, so it > makes sense to discuss it. Agreed, we have to decide what knobs are generally needed. In this particular case of source address selection, IPv6 provides relatively clear guidelines (RFC 3484) while in IPv4 this seems to be underspecified, which opened space for vendor creativity (btw. Linux "ip" utility has its share of esoteric features, too). Lada > > > > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From david.kessens@nsn.com Fri Nov 4 03:16:38 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DEB21F85DB for ; Fri, 4 Nov 2011 03:16:38 -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 udLYs1uoYVfR for ; Fri, 4 Nov 2011 03:16:37 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF6C21F85CE for ; Fri, 4 Nov 2011 03:16:37 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pA4AGZcg013468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 4 Nov 2011 11:16:35 +0100 Received: from localhost.localdomain ([10.138.48.40]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA4AGY2B020137 for ; Fri, 4 Nov 2011 11:16:35 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id pA4AGVn1002737 for ; Fri, 4 Nov 2011 03:16:32 -0700 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id pA4AGTB5002736 for netmod@ietf.org; Fri, 4 Nov 2011 03:16:29 -0700 Date: Fri, 4 Nov 2011 03:16:28 -0700 From: David Kessens To: netmod@ietf.org Message-ID: <20111104101628.GA2606@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] Last Call: iana-if-type-01 & interfaces-cfg-02 (20111121) 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, 04 Nov 2011 10:16:38 -0000 Hi, I would hereby like to start a Last Call for: http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-02.txt http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-01.txt The drafts seem to stabilized enough so it is time to determine whether they are ready to be send to the IESG for approval. Please indicate your support by Nov 21 2011, but preferably before our working group session on Nov 15. I would like to see at least three reviews of the drafts to make sure that we have had sufficient review to move them to the next level so please indicate whether you have reviewed the current drafts when you state your support. Thanks! David Kessens co-chair netmod wg --- From wwwrun@rfc-editor.org Fri Nov 4 03:55:42 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A21521F8C09 for ; Fri, 4 Nov 2011 03:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAiTIz9jQDUL for ; Fri, 4 Nov 2011 03:55:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9C71B21F8BF6 for ; Fri, 4 Nov 2011 03:55:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E0FCB6219F; Fri, 4 Nov 2011 03:51:09 -0700 (PDT) To: phil@juniper.net, dromasca@avaya.com, rbonica@juniper.net, david.kessens@nsn.com, j.schoenwaelder@jacobs-university.de From: RFC Errata System Message-Id: <20111104105109.E0FCB6219F@rfc-editor.org> Date: Fri, 4 Nov 2011 03:51:09 -0700 (PDT) Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Technical Errata Reported] RFC6244 (3012) 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, 04 Nov 2011 10:55:42 -0000 The following errata report has been submitted for RFC6244, "An Architecture for Network Management Using NETCONF and YANG". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6244&eid=3012 -------------------------------------- Type: Technical Reported by: Martin Bjorklund Section: 2.2.1 Original Text ------------- | reference | Value must appear elsewhere in the data | Corrected Text -------------- | type leafref | Value must appear elsewhere in the data | Notes ----- The "reference" statement is used as a reference to some other specification. The column heading is "Statement". It is not obvious that "type leafref" is a Statement, so I am not sure if the proposed corrected text is enough. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6244 (draft-ietf-netmod-arch-10) -------------------------------------- Title : An Architecture for Network Management Using NETCONF and YANG Publication Date : June 2011 Author(s) : P. Shafer Category : INFORMATIONAL Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From bertietf@bwijnen.net Fri Nov 4 09:19:52 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9D21F8CB2 for ; Fri, 4 Nov 2011 09:19:52 -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 BRjbhc4p-133 for ; Fri, 4 Nov 2011 09:19:51 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 753AB21F8CAD for ; Fri, 4 Nov 2011 09:19:50 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RMMUd-0006qM-PL; Fri, 04 Nov 2011 17:19:49 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RMMUd-00018I-Jm; Fri, 04 Nov 2011 17:19:47 +0100 Message-ID: <4EB410A3.3050903@bwijnen.net> Date: Fri, 04 Nov 2011 17:19:47 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: David Kessens References: <20111104101628.GA2606@nsn.com> In-Reply-To: <20111104101628.GA2606@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd47484cdda7013bd0f3ee3eb5951b9ab60 Cc: netmod@ietf.org Subject: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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, 04 Nov 2011 16:19:52 -0000 I read draft-ietf-netmod-interfaces-cfg-02.txt And I believe it is ready and in good shape for sending it to our AD for publication as PS. A few nits/questions (no showstoppers): - I have not been following all the YANG discussions close enough (I fear). So when I see in sect 3: +--rw enabled? boolean +--ro if-index* int32 Then I wonder: what the ? mark and the asterisk mean here? Is that documented somewhere? Think of many readers, few writers for YANG documents. - I see leaf link-up-down-trap-enable { I understand this comes from the IF-MIB, but would we not rather call them events or notifications? Do we really want to carry around the "trap" terminology around for the rest of our lives? - page 11 toward the end: not operate on top of any other intertface (as defined in s/intertface/interface/ - page 20 Eth0 nicely uses the example IP address from range 192.0.2.0/24 Eth1 however uses 192.168.1.1 ?? I understand that with preflength of 24 this is the only way to differentiate the (sub-)networks So I can live with it. But formally it would not be allowed to be used in examples. Bert On 11/4/11 11:16 AM, David Kessens wrote: > > Hi, > > I would hereby like to start a Last Call for: > > http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-02.txt > http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-01.txt > > The drafts seem to stabilized enough so it is time to determine whether > they are ready to be send to the IESG for approval. > > Please indicate your support by Nov 21 2011, but preferably before our > working group session on Nov 15. I would like to see at least three reviews > of the drafts to make sure that we have had sufficient review to move them > to the next level so please indicate whether you have reviewed the current > drafts when you state your support. > > Thanks! > > David Kessens > co-chair netmod wg > --- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From mbj@tail-f.com Sat Nov 5 12:34:00 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B61721F85F1 for ; Sat, 5 Nov 2011 12:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.186, 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 xqfWiatPmSFJ for ; Sat, 5 Nov 2011 12:33: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 2CB0E21F85EF for ; Sat, 5 Nov 2011 12:33:58 -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 359511200CEE; Sat, 5 Nov 2011 20:33:55 +0100 (CET) Date: Sat, 05 Nov 2011 20:33:52 +0100 (CET) Message-Id: <20111105.203352.185723065.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <4EB410A3.3050903@bwijnen.net> References: <20111104101628.GA2606@nsn.com> <4EB410A3.3050903@bwijnen.net> 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] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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, 05 Nov 2011 19:34:00 -0000 Hi, "Bert Wijnen (IETF)" wrote: > A few nits/questions (no showstoppers): > - I have not been following all the YANG discussions > close enough (I fear). So when I see in sect 3: > > +--rw enabled? boolean > +--ro if-index* int32 > > Then I wonder: what the ? mark and the asterisk mean > here? Is that documented somewhere? > Think of many readers, few writers for YANG documents. This is not defined in any standard; it happens to be the output from pyang (-f tree). '?' means optional leaf (zero or one), and '*' means leaf-list (zero or many). But this figure is intended to show the structure of the YANG module, so if it helps I think we can remove the '?' and '*'. > - I see > leaf link-up-down-trap-enable { > I understand this comes from the IF-MIB, > but would we not rather call them events > or notifications? Do we really want to > carry around the "trap" terminology around > for the rest of our lives? The MIB leaf is called ifLinkUpDownTrapEnable, and in order to not confuse users I think it is best to use the same name. David Harrington also shared some experience around this in http://www.ietf.org/mail-archive/web/netmod/current/msg05533.html. > - page 11 toward the end: > not operate on top of any other intertface (as defined in > s/intertface/interface/ Fixed. > - page 20 > Eth0 nicely uses the example IP address from range 192.0.2.0/24 > Eth1 however uses 192.168.1.1 ?? > I understand that with preflength of 24 this is the only > way to differentiate the (sub-)networks > So I can live with it. But formally it would not be allowed to > be used in examples. I changed this to 198.51.100.1, using the 198.51.100.0/24 block as defined in RFC 5737. (I also did s/NETCOMF/NETCONF/) /martin From bertietf@bwijnen.net Sun Nov 6 02:10:59 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E5221F84A0 for ; Sun, 6 Nov 2011 02:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IME38zvRgnk1 for ; Sun, 6 Nov 2011 02:10:59 -0800 (PST) Received: from relay61.tele2.vuurwerk.nl (relay61.tele2.vuurwerk.nl [62.250.3.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7875721F8496 for ; Sun, 6 Nov 2011 02:10:36 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.indetel.net with smtp (Exim 4.69) (envelope-from ) id 1RMzgE-0007vu-0p; Sun, 06 Nov 2011 11:10:22 +0100 Message-ID: <12639D5ACD234A3A90930AC40116B4B8@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Martin Bjorklund" References: <20111104101628.GA2606@nsn.com><4EB410A3.3050903@bwijnen.net> <20111105.203352.185723065.mbj@tail-f.com> In-Reply-To: <20111105.203352.185723065.mbj@tail-f.com> Date: Sun, 6 Nov 2011 11:02:36 +0100 Organization: Consultant MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463 Cc: netmod@ietf.org Subject: Re: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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: Sun, 06 Nov 2011 10:10:59 -0000 Inline ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; Sent: Saturday, November 05, 2011 8:33 PM Subject: Re: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.txt > Hi, > > "Bert Wijnen (IETF)" wrote: >> A few nits/questions (no showstoppers): >> - I have not been following all the YANG discussions >> close enough (I fear). So when I see in sect 3: >> >> +--rw enabled? boolean >> +--ro if-index* int32 >> >> Then I wonder: what the ? mark and the asterisk mean >> here? Is that documented somewhere? >> Think of many readers, few writers for YANG documents. > > This is not defined in any standard; it happens to be the output from > pyang (-f tree). '?' means optional leaf (zero or one), and '*' means > leaf-list (zero or many). > > But this figure is intended to show the structure of the YANG module, > so if it helps I think we can remove the '?' and '*'. > Well, I do think that the inof is useful./helpful. So why not add a line of text that says something like: In the below diagram, a '?' means optional leaf (zero or one), and a '*' means leaf-list (zero or many). Bert >> - I see >> leaf link-up-down-trap-enable { >> I understand this comes from the IF-MIB, >> but would we not rather call them events >> or notifications? Do we really want to >> carry around the "trap" terminology around >> for the rest of our lives? > > The MIB leaf is called ifLinkUpDownTrapEnable, and in order to not > confuse users I think it is best to use the same name. David > Harrington also shared some experience around this in > http://www.ietf.org/mail-archive/web/netmod/current/msg05533.html. > >> - page 11 toward the end: >> not operate on top of any other intertface (as defined in >> s/intertface/interface/ > > Fixed. > >> - page 20 >> Eth0 nicely uses the example IP address from range 192.0.2.0/24 >> Eth1 however uses 192.168.1.1 ?? >> I understand that with preflength of 24 this is the only >> way to differentiate the (sub-)networks >> So I can live with it. But formally it would not be allowed to >> be used in examples. > > I changed this to 198.51.100.1, using the 198.51.100.0/24 block as > defined in RFC 5737. > > > (I also did s/NETCOMF/NETCONF/) > > > /martin From lhotka@cesnet.cz Sun Nov 6 02:49:38 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995DD21F844C for ; Sun, 6 Nov 2011 02:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpMyEqpqZSE8 for ; Sun, 6 Nov 2011 02:49:38 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id EDD0D21F844B for ; Sun, 6 Nov 2011 02:49:37 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id 53A012CDE05D for ; Sun, 6 Nov 2011 11:49:32 +0100 (CET) Message-ID: <4EB6663C.8000208@cesnet.cz> Date: Sun, 06 Nov 2011 11:49:32 +0100 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netmod@ietf.org References: <20111104101628.GA2606@nsn.com><4EB410A3.3050903@bwijnen.net> <20111105.203352.185723065.mbj@tail-f.com> <12639D5ACD234A3A90930AC40116B4B8@BertLaptop> In-Reply-To: <12639D5ACD234A3A90930AC40116B4B8@BertLaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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: Sun, 06 Nov 2011 10:49:38 -0000 Dne 6.11.2011 11:02, Bert Wijnen (IETF) napsal(a): > Inline > > ----- Original Message ----- From: "Martin Bjorklund" > To: > Cc: ; > Sent: Saturday, November 05, 2011 8:33 PM > Subject: Re: [netmod] My review for Last > Call:draft-ietf-netmod-interfaces-cfg-02.txt > > >> Hi, >> >> "Bert Wijnen (IETF)" wrote: >>> A few nits/questions (no showstoppers): >>> - I have not been following all the YANG discussions >>> close enough (I fear). So when I see in sect 3: >>> >>> +--rw enabled? boolean >>> +--ro if-index* int32 >>> >>> Then I wonder: what the ? mark and the asterisk mean >>> here? Is that documented somewhere? >>> Think of many readers, few writers for YANG documents. >> >> This is not defined in any standard; it happens to be the output from >> pyang (-f tree). '?' means optional leaf (zero or one), and '*' means >> leaf-list (zero or many). >> >> But this figure is intended to show the structure of the YANG module, >> so if it helps I think we can remove the '?' and '*'. >> > > Well, I do think that the inof is useful./helpful. So why not add a > line of text > that says something like: > > In the below diagram, a '?' means optional leaf (zero or one), and a > '*' > means leaf-list (zero or many). +1 Lada > > Bert > > > >>> - I see >>> leaf link-up-down-trap-enable { >>> I understand this comes from the IF-MIB, >>> but would we not rather call them events >>> or notifications? Do we really want to >>> carry around the "trap" terminology around >>> for the rest of our lives? >> >> The MIB leaf is called ifLinkUpDownTrapEnable, and in order to not >> confuse users I think it is best to use the same name. David >> Harrington also shared some experience around this in >> http://www.ietf.org/mail-archive/web/netmod/current/msg05533.html. >> >>> - page 11 toward the end: >>> not operate on top of any other intertface (as defined in >>> s/intertface/interface/ >> >> Fixed. >> >>> - page 20 >>> Eth0 nicely uses the example IP address from range 192.0.2.0/24 >>> Eth1 however uses 192.168.1.1 ?? >>> I understand that with preflength of 24 this is the only >>> way to differentiate the (sub-)networks >>> So I can live with it. But formally it would not be allowed to >>> be used in examples. >> >> I changed this to 198.51.100.1, using the 198.51.100.0/24 block as >> defined in RFC 5737. >> >> >> (I also did s/NETCOMF/NETCONF/) >> >> >> /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From phil@juniper.net Sun Nov 6 11:13:56 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D6C21F8564 for ; Sun, 6 Nov 2011 11:13:56 -0800 (PST) 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 hbhAEME8ej11 for ; Sun, 6 Nov 2011 11:13:55 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id A6F5421F853E for ; Sun, 6 Nov 2011 11:13:50 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Sun, 06 Nov 2011 11:13:55 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 6 Nov 2011 11:11:48 -0800 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 pA6JBlh35193; Sun, 6 Nov 2011 11:11:47 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id pA6IhJij091742; Sun, 6 Nov 2011 18:43:20 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201111061843.pA6IhJij091742@idle.juniper.net> To: "Bert Wijnen (IETF)" In-Reply-To: <12639D5ACD234A3A90930AC40116B4B8@BertLaptop> Date: Sun, 6 Nov 2011 13:43:19 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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: Sun, 06 Nov 2011 19:13:56 -0000 "Bert Wijnen \(IETF\)" writes: > In the below diagram, a '?' means optional leaf (zero or one), and a '*' > means leaf-list (zero or many). Are you inventing a new syntax for YANG using ascii art? Do you want to use the UML style of "0..1" and "0..infinity"? Or is this even a good idea at all? How about it we give YANG reader YANG terms instead? We don't need to confuse them with this new diagraming syntax. Make a column for "leaf", "leaf-list", "container", etc and a column for mandatory. Or use real text: +-- description (an optional, writable leaf of type string) +-- type (a mandatory, writable leaf of type ianaift:iana-if-type) Inventing a new syntax here is just a very bad idea. Why is "if-index" not writable? (No, I've not read the document, but think this is a bug). And why is enabled the knob instead of disabled, since it will have to be set on 99.9% of interfaces? It makes a common source of errors that you can easily remove. Thanks, Phil From j.schoenwaelder@jacobs-university.de Sun Nov 6 11:25:12 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07F221F8569 for ; Sun, 6 Nov 2011 11:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.139 X-Spam-Level: X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=0.110, 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 udU9czdRr7Zk for ; Sun, 6 Nov 2011 11:25:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EE5C621F8564 for ; Sun, 6 Nov 2011 11:25:11 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F301620D7A; Sun, 6 Nov 2011 20:25:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4aiwQQzHgyC8; Sun, 6 Nov 2011 20:25:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9676220D79; Sun, 6 Nov 2011 20:25:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0CF351B55AF6; Sun, 6 Nov 2011 20:24:52 +0100 (CET) Date: Sun, 6 Nov 2011 20:24:52 +0100 From: Juergen Schoenwaelder To: Phil Shafer Message-ID: <20111106192451.GB19375@elstar.local> Mail-Followup-To: Phil Shafer , "Bert Wijnen (IETF)" , netmod@ietf.org References: <12639D5ACD234A3A90930AC40116B4B8@BertLaptop> <201111061843.pA6IhJij091742@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111061843.pA6IhJij091742@idle.juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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: Sun, 06 Nov 2011 19:25:12 -0000 On Sun, Nov 06, 2011 at 01:43:19PM -0500, Phil Shafer wrote: > "Bert Wijnen \(IETF\)" writes: > > In the below diagram, a '?' means optional leaf (zero or one), and a '*' > > means leaf-list (zero or many). > > Are you inventing a new syntax for YANG using ascii art? Do you > want to use the UML style of "0..1" and "0..infinity"? Or is this > even a good idea at all? > > How about it we give YANG reader YANG terms instead? We don't > need to confuse them with this new diagraming syntax. Make > a column for "leaf", "leaf-list", "container", etc and a > column for mandatory. Or use real text: > > +-- description (an optional, writable leaf of type string) > +-- type (a mandatory, writable leaf of type ianaift:iana-if-type) > > Inventing a new syntax here is just a very bad idea. I (as a reader) find the compact tree diagram extremely useful to get a quick to read and fast to understand overview. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Sun Nov 6 11:49:30 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B28421F858D for ; Sun, 6 Nov 2011 11:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 Pu75PI6M3W6S for ; Sun, 6 Nov 2011 11:49:29 -0800 (PST) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEDE21F858C for ; Sun, 6 Nov 2011 11:49:29 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pA6JnPqV020961 for ; Sun, 6 Nov 2011 14:49:27 -0500 Authentication-Results: cm-omr14 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:44532] helo=[192.168.0.9]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E7/49-05187-4C4E6BE4; Sun, 06 Nov 2011 14:49:25 -0500 Message-ID: <4EB6E4C4.6030307@andybierman.com> Date: Sun, 06 Nov 2011 11:49:24 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Phil Shafer , "Bert Wijnen (IETF)" , netmod@ietf.org References: <12639D5ACD234A3A90930AC40116B4B8@BertLaptop> <201111061843.pA6IhJij091742@idle.juniper.net> <20111106192451.GB19375@elstar.local> In-Reply-To: <20111106192451.GB19375@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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: Sun, 06 Nov 2011 19:49:30 -0000 On 11/06/2011 11:24 AM, Juergen Schoenwaelder wrote: > On Sun, Nov 06, 2011 at 01:43:19PM -0500, Phil Shafer wrote: >> "Bert Wijnen \(IETF\)" writes: >>> In the below diagram, a '?' means optional leaf (zero or one), and a '*' >>> means leaf-list (zero or many). >> >> Are you inventing a new syntax for YANG using ascii art? Do you >> want to use the UML style of "0..1" and "0..infinity"? Or is this >> even a good idea at all? >> >> How about it we give YANG reader YANG terms instead? We don't >> need to confuse them with this new diagraming syntax. Make >> a column for "leaf", "leaf-list", "container", etc and a >> column for mandatory. Or use real text: >> >> +-- description (an optional, writable leaf of type string) >> +-- type (a mandatory, writable leaf of type ianaift:iana-if-type) >> >> Inventing a new syntax here is just a very bad idea. > > I (as a reader) find the compact tree diagram extremely useful to get > a quick to read and fast to understand overview. > I agree, but the syntax should be explained. There are 2 goals here, which may not be obvious: 1) provide quick lookup of data tree structure 2) avoid redundant or inconsistent normative text that results from a traditional introduction section > /js > Andy From phil@juniper.net Sun Nov 6 23:12:15 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D5921F848C for ; Sun, 6 Nov 2011 23:12:15 -0800 (PST) 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 xiWqFznkJ-vq for ; Sun, 6 Nov 2011 23:12:14 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4218F21F8438 for ; Sun, 6 Nov 2011 23:12:02 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP; Sun, 06 Nov 2011 23:12:06 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 6 Nov 2011 23:09:18 -0800 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 pA779Gh01932; Sun, 6 Nov 2011 23:09:16 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id pA76elBR094637; Mon, 7 Nov 2011 06:40:48 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201111070640.pA76elBR094637@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20111106192451.GB19375@elstar.local> Date: Mon, 7 Nov 2011 01:40:47 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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, 07 Nov 2011 07:12:15 -0000 Juergen Schoenwaelder writes: >I (as a reader) find the compact tree diagram extremely useful to get >a quick to read and fast to understand overview. Looks like it's trying to be relax-ng compact form. The best way to help folks learn YANG is to use YANG terms, like "leaf-list" instead of "*". You may be able to make this jump, but newer readers will not. Thanks, Phil From mbj@tail-f.com Mon Nov 7 01:10:31 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE08F21F87C9 for ; Mon, 7 Nov 2011 01:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 438zklYduWAe for ; Mon, 7 Nov 2011 01:10:31 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id CD66E21F85A8 for ; Mon, 7 Nov 2011 01:10:30 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id EE6EE12008CD; Mon, 7 Nov 2011 10:10:04 +0100 (CET) Date: Mon, 07 Nov 2011 10:10:04 +0100 (CET) Message-Id: <20111107.101004.2176384251775544437.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201111061843.pA6IhJij091742@idle.juniper.net> References: <12639D5ACD234A3A90930AC40116B4B8@BertLaptop> <201111061843.pA6IhJij091742@idle.juniper.net> 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] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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, 07 Nov 2011 09:10:32 -0000 Hi, Phil Shafer wrote: > "Bert Wijnen \(IETF\)" writes: > > In the below diagram, a '?' means optional leaf (zero or one), and a '*' > > means leaf-list (zero or many). > > Are you inventing a new syntax for YANG using ascii art? No. > Do you > want to use the UML style of "0..1" and "0..infinity"? No. > Or is this > even a good idea at all? > > How about it we give YANG reader YANG terms instead? As Juergen et. al. already pointed out, this figure is there to show the *structure* of the data model (which, incidentally, the document also says). It is not a YANG replacement. Ok, maybe the point is more clear if we do: OLD: The module "ietf-interfaces" has the following structure: NEW: The data model defined in the module "ietf-interfaces" has the following structure: > We don't > need to confuse them with this new diagraming syntax. Make > a column for "leaf", "leaf-list", "container", etc and a > column for mandatory. Or use real text: > > +-- description (an optional, writable leaf of type string) > +-- type (a mandatory, writable leaf of type ianaift:iana-if-type) First, this would not solve the same problem (display the structure of the data model), and second, I definitely don't think we need another syntax for YANG. > Why is "if-index" not writable? ifIndex is not config in the MIB, and this node just reflects the MIB defintion. > And why is enabled the knob instead of disabled, since it > will have to be set on 99.9% of interfaces? It makes a > common source of errors that you can easily remove. The default value is "true" which means that for 99.9% of the interfaces you don't see it anyway. If we rename this to "disabled", I think maybe it should be of type "empty". /martin From bertietf@bwijnen.net Mon Nov 7 01:46:25 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998C321F86A4 for ; Mon, 7 Nov 2011 01:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 vJp3NX00Z64S for ; Mon, 7 Nov 2011 01:46:25 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3E321F85A4 for ; Mon, 7 Nov 2011 01:46:23 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RNLmV-0006Zb-RG; Mon, 07 Nov 2011 10:46:20 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest114.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RNLmV-0001XH-O3; Mon, 07 Nov 2011 10:46:19 +0100 Message-ID: <4EB7A8EB.1080106@bwijnen.net> Date: Mon, 07 Nov 2011 10:46:19 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: David Kessens References: <20111104101628.GA2606@nsn.com> In-Reply-To: <20111104101628.GA2606@nsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd440910cb624c02775558e44434280a626 Cc: netmod@ietf.org Subject: [netmod] my review of: draft-ietf-netmod-iana-if-type-01 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, 07 Nov 2011 09:46:25 -0000 I did read this document and agree that it is ready for publication as stds track RFC. My understanding is that new ifTypes (enumerations) or changes (depracating) can ONLY be made in this module if a corresponding addition or change if made to the ianaIftype-MIB module. This I conclude from the IANA Considerations clause. Is this clear to everyone, also new readers (i.e. people who are not so familiar with SNMP and MIB modules? Bert From phil@juniper.net Mon Nov 7 04:27:23 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C22921F8B4C for ; Mon, 7 Nov 2011 04:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=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 06FYuivOeNOW for ; Mon, 7 Nov 2011 04:27:23 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9308E21F8AD2 for ; Mon, 7 Nov 2011 04:27:18 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Mon, 07 Nov 2011 04:27:22 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 7 Nov 2011 04:23:36 -0800 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 pA7CNWh50675; Mon, 7 Nov 2011 04:23:35 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id pA7Bt4Xe097094; Mon, 7 Nov 2011 11:55:04 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201111071155.pA7Bt4Xe097094@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20111107.101004.2176384251775544437.mbj@tail-f.com> Date: Mon, 7 Nov 2011 06:55:04 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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, 07 Nov 2011 12:27:23 -0000 Martin Bjorklund writes: >As Juergen et. al. already pointed out, this figure is there to show >the *structure* of the data model (which, incidentally, the document >also says). It is not a YANG replacement. My point is that the first few YANG modules will make a huge precedent that folks are sure to follow. By making this structure diagram using non-YANG terms you are teaching readers to thing "*", "?", etc instead of using YANG terminology. >> Why is "if-index" not writable? >ifIndex is not config in the MIB, and this node just reflects the MIB >defintion. But if-index needs to be configable if one wants to tell the box which if-index to use.kkk >If we rename this to "disabled", I think maybe it should be of type >"empty". Yes, I'd prefer to see if done that way. Thanks, Phil From per@tail-f.com Mon Nov 7 04:52:57 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7909021F8B2F for ; Mon, 7 Nov 2011 04:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HFQDaw0Ctpp for ; Mon, 7 Nov 2011 04:52:57 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id EA5FC21F8488 for ; Mon, 7 Nov 2011 04:52:56 -0800 (PST) Received: from mars.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C403812008CD; Mon, 7 Nov 2011 13:52:55 +0100 (CET) Message-ID: <4EB7D4A7.2040702@tail-f.com> Date: Mon, 07 Nov 2011 13:52:55 +0100 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.13) Gecko/20110202 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phil Shafer References: <201111071155.pA7Bt4Xe097094@idle.juniper.net> In-Reply-To: <201111071155.pA7Bt4Xe097094@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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, 07 Nov 2011 12:52:57 -0000 On 2011-11-07 12:55, Phil Shafer wrote: > Martin Bjorklund writes: > >> If we rename this to "disabled", I think maybe it should be of type >> "empty". > > Yes, I'd prefer to see if done that way. I disagree - a non-negated boolean seems much clearer to me, and as Martin pointed out, there is no operational difference - since the default is "true", you need neither set it nor see it for an enabled interface. Well, the difference is that you would have to do (the NETCONF equivalent of) 'delete disabled' instead of 'set enabled true' to enable a previously disabled interface - not a win as far as I can see. --Per Hedeland From lhotka@cesnet.cz Mon Nov 7 05:01:40 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C4021F86AA for ; Mon, 7 Nov 2011 05:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqjWv4edy09y for ; Mon, 7 Nov 2011 05:01:36 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id B0EBB21F8569 for ; Mon, 7 Nov 2011 05:01:35 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id 321572CDE058 for ; Mon, 7 Nov 2011 14:01:34 +0100 (CET) Message-ID: <4EB7D6AE.5000208@cesnet.cz> Date: Mon, 07 Nov 2011 14:01:34 +0100 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netmod@ietf.org References: <201111071155.pA7Bt4Xe097094@idle.juniper.net> In-Reply-To: <201111071155.pA7Bt4Xe097094@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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, 07 Nov 2011 13:01:40 -0000 Dne 7.11.2011 12:55, Phil Shafer napsal(a): > Martin Bjorklund writes: >> As Juergen et. al. already pointed out, this figure is there to show >> the *structure* of the data model (which, incidentally, the document >> also says). It is not a YANG replacement. > My point is that the first few YANG modules will make a huge precedent > that folks are sure to follow. By making this structure diagram > using non-YANG terms you are teaching readers to thing "*", "?", > etc instead of using YANG terminology. I also like the compact graphical representation (and often find myself runing "pyang -f tree ..."). And I don't think it competes with YANG terminology in any way. > >>> Why is "if-index" not writable? >> ifIndex is not config in the MIB, and this node just reflects the MIB >> defintion. > But if-index needs to be configable if one wants to tell > the box which if-index to use.kkk > >> If we rename this to "disabled", I think maybe it should be of type >> "empty". > Yes, I'd prefer to see if done that way. I agree with Phil here. Actually, we also have the 'presence' flag on containers for this purpose but I haven't seen any use of them so far. I guess it is because 'presence' doesn't allow for pre-configuring the function but keeping it disabled. Lada > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Nov 7 05:12:32 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8407A21F8562 for ; Mon, 7 Nov 2011 05:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMi23-QOOFu4 for ; Mon, 7 Nov 2011 05:12:28 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id EFF6121F8B45 for ; Mon, 7 Nov 2011 05:12:27 -0800 (PST) Received: from [IPv6:2001:718:1a02:7:219:99ff:fead:6129] (unknown [IPv6:2001:718:1a02:7:219:99ff:fead:6129]) by office2.cesnet.cz (Postfix) with ESMTPSA id 060662CDE05F for ; Mon, 7 Nov 2011 14:12:27 +0100 (CET) Message-ID: <4EB7D93B.5060000@cesnet.cz> Date: Mon, 07 Nov 2011 14:12:27 +0100 From: Ladislav Lhotka User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: netmod@ietf.org References: <201111071155.pA7Bt4Xe097094@idle.juniper.net> <4EB7D4A7.2040702@tail-f.com> In-Reply-To: <4EB7D4A7.2040702@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] My review for Last Call:draft-ietf-netmod-interfaces-cfg-02.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, 07 Nov 2011 13:12:32 -0000 Dne 7.11.2011 13:52, Per Hedeland napsal(a): > On 2011-11-07 12:55, Phil Shafer wrote: >> Martin Bjorklund writes: >> >>> If we rename this to "disabled", I think maybe it should be of type >>> "empty". >> Yes, I'd prefer to see if done that way. > I disagree - a non-negated boolean seems much clearer to me, and as > Martin pointed out, there is no operational difference - since the > default is "true", you need neither set it nor see it for an enabled > interface. Well, the difference is that you would have to do (the > NETCONF equivalent of) 'delete disabled' instead of 'set enabled true' > to enable a previously disabled interface - not a win as far as I can > see. We also have to take into account the different modes of handling defaults. With "report-all", the 99.9 % "enabled" leafs can be a real nuisance. works the same in all modes. Moreover, an empty 'disabled' leaf is IMO slightly more readable in XPath expressions, e.g. when "not(disabled)"; versus when "enabled = 'true'" Lada > > --Per Hedeland > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From lhotka@cesnet.cz Mon Nov 7 07:01:59 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798C621F8444 for ; Mon, 7 Nov 2011 07:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCVtgKma198l for ; Mon, 7 Nov 2011 07:01:58 -0800 (PST) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1E821F8B17 for ; Mon, 7 Nov 2011 07:01:58 -0800 (PST) Received: from localhost (jaromir.lhotkovi.cz [172.29.2.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id 96AA1DC005B for ; Mon, 7 Nov 2011 16:01:57 +0100 (CET) From: Ladislav Lhotka To: NETMOD Working Group User-Agent: Notmuch/0.9 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Mail-Followup-To: NETMOD Working Group Date: Mon, 07 Nov 2011 16:01:55 +0100 Message-ID: <87pqh4ht7g.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [netmod] LL review of interfaces-cfg-02 & iana-if-type-01 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, 07 Nov 2011 15:01:59 -0000 Hi, I reviewed the drafts, I think both are in a good shape and can be handed over to the IESG. Concerning both drafts: Is it correct to have the NETMOD WG as the "Registrant Contact" in the URI registrations? RFC 3688 says: "In the case of IETF developed standards, the Registrant will be the IESG." I found a typo in iana-if-type-01: s/registrered/registered/ Other typos I noticed have already been discovered. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From bertietf@bwijnen.net Mon Nov 7 07:28:00 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0501421F8B10 for ; Mon, 7 Nov 2011 07:28:00 -0800 (PST) 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 XFdmsYMKHhBh for ; Mon, 7 Nov 2011 07:27:59 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 78C9621F8AD1 for ; Mon, 7 Nov 2011 07:27:59 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RNR78-0004Yp-8o for netmod@ietf.org; Mon, 07 Nov 2011 16:27:58 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=guest114.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RNR78-0000Jt-5A for netmod@ietf.org; Mon, 07 Nov 2011 16:27:58 +0100 Message-ID: <4EB7F8FD.7050701@bwijnen.net> Date: Mon, 07 Nov 2011 16:27:57 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: NETMOD Working Group References: <87pqh4ht7g.fsf@cesnet.cz> In-Reply-To: <87pqh4ht7g.fsf@cesnet.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4b3cc1a454adb4d0792a60439bac11bf5 Subject: Re: [netmod] LL review of interfaces-cfg-02 & iana-if-type-01 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, 07 Nov 2011 15:28:00 -0000 Good comment. I did catch that one in a NETCONF document. And there we changedit to "IESG". We better follow the rules and be consistent in these things. Bert On 11/7/11 4:01 PM, Ladislav Lhotka wrote: > Concerning both drafts: Is it correct to have the NETMOD WG as the > "Registrant Contact" in the URI registrations? RFC 3688 says: > > "In the case of IETF developed standards, the Registrant will be the > IESG." From lhotka@cesnet.cz Mon Nov 7 07:40:32 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF90821F8922 for ; Mon, 7 Nov 2011 07:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPh3GvIoccFv for ; Mon, 7 Nov 2011 07:40:28 -0800 (PST) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by ietfa.amsl.com (Postfix) with ESMTP id AF4E321F8C1C for ; Mon, 7 Nov 2011 07:40:28 -0800 (PST) Received: from localhost (jaromir.lhotkovi.cz [172.29.2.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id 76405DC005B; Mon, 7 Nov 2011 16:40:26 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20111028.141955.488159309.mbj@tail-f.com> References: <20111028.141955.488159309.mbj@tail-f.com> User-Agent: Notmuch/0.9 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Mon, 07 Nov 2011 16:40:24 +0100 Message-ID: <87mxc8hrfb.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] ip config issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 15:40:33 -0000 Hi, after reconsidering all pros and cons, I think the best option is to leave the scope of the ip-cfg draft (and contents of the module) as it is, even though I previously suggested some extensions. WRT primary, preferred etc.: Simple devices should be fine with the existing data model - they either don't have the source address selection problem at all, or can use a non-configurable selection algorithm. For routers etc., these flags can easily be added via augmenting. WRT non-contiguous mask: I still think it's an esoteric insanity but, as Tom Petch pointed out, standards leave it as an option, albeit with reservations. So it should probably stay in the module because it would otherwise be difficult to obtain it via augmenting. I think it is quite important to get this module out of the doors asap. Lada PS. The typo "familiy" I found in -00 is still present in -01 (twice). On Fri, 28 Oct 2011 14:19:55 +0200 (CEST), Martin Bjorklund wrote: > Hi, > > I have posted a new version (-01) of the ip-config draft. It is now > possible to configure non-contiguous netmasks, as discussed > previously. > > There are a couple of other issues, not yet handled. > > * ip-01 primary, secondary, and preferred address > > Lada suggested that we need to specify the primary address on an > interface, and he pointed to the solution of two router vendors for > doing this. Phil sent some links to Juniper's documentation. > > It seems to be that these two vendors have the same terminology, but > different meaning of the term "primary address". In one case it > seems to be the source address used for all outgoing packets on the > interface, and in the other it seems to be the source address used > for outgoing multi- and broadcast (?) packets. > > Phil also mentioned "preferred address", which seems to be the > source address used for outgoing unicast packets on the *subnet* > (i.e., there can be one "preferred address" per subnet on an > interface (I think)). > > So it seems there are two concepts here: > > default source on interface > > default source in subnet > > Q. Is my understanding correct? > > Q. If it is, do we need any, both, or more of these concepts? > > > * ip-02 iv6 auto-link-local-address leaf > > Lada suggested that maybe there should be a way to tell the server > to not automatically assign a link-local unicast address for an ipv6 > interface. > > Q. Is this a useful (and implementable) parameter? > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Nov 7 11:57:51 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8818821F8558 for ; Mon, 7 Nov 2011 11:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.133, 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 hXEy1hT1VCri for ; Mon, 7 Nov 2011 11:57:51 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 09EB421F853E for ; Mon, 7 Nov 2011 11:57:51 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 4DC1B12008CD; Mon, 7 Nov 2011 20:57:50 +0100 (CET) Date: Mon, 07 Nov 2011 20:57:49 +0100 (CET) Message-Id: <20111107.205749.512292395.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <87pqh4ht7g.fsf@cesnet.cz> References: <87pqh4ht7g.fsf@cesnet.cz> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] LL review of interfaces-cfg-02 & iana-if-type-01 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, 07 Nov 2011 19:57:51 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > I reviewed the drafts, I think both are in a good shape and can be handed > over to the IESG. > > Concerning both drafts: Is it correct to have the NETMOD WG as the > "Registrant Contact" in the URI registrations? RFC 3688 says: > > "In the case of IETF developed standards, the Registrant will be the > IESG." Yes, fixed in both documents. > I found a typo in iana-if-type-01: > > s/registrered/registered/ Fixed. /martin From mbj@tail-f.com Mon Nov 7 12:01:42 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6404311E809F for ; Mon, 7 Nov 2011 12:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.116, 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 4YjSNfvMD+Kw for ; Mon, 7 Nov 2011 12:01:42 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1921F0C51 for ; Mon, 7 Nov 2011 12:01:33 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id CF91F12008CD; Mon, 7 Nov 2011 21:01:32 +0100 (CET) Date: Mon, 07 Nov 2011 21:01:31 +0100 (CET) Message-Id: <20111107.210131.227530889.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <4EB7A8EB.1080106@bwijnen.net> References: <20111104101628.GA2606@nsn.com> <4EB7A8EB.1080106@bwijnen.net> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] my review of: draft-ietf-netmod-iana-if-type-01 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, 07 Nov 2011 20:01:42 -0000 Hi, "Bert Wijnen (IETF)" wrote: > My understanding is that new ifTypes (enumerations) or > changes (depracating) can ONLY be made in this module > if a corresponding addition or change if made to the > ianaIftype-MIB module. > > This I conclude from the IANA Considerations clause. The Introduction also says: This document defines the initial version of the iana-if-type YANG module. This module reflects IANA's "ifType definitions" registry. /martin From bertietf@bwijnen.net Mon Nov 7 12:14:53 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A3411E80B8 for ; Mon, 7 Nov 2011 12:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 1AF1C78+7Tkf for ; Mon, 7 Nov 2011 12:14:53 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 39EFD11E8093 for ; Mon, 7 Nov 2011 12:14:53 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RNVak-0006cT-HL; Mon, 07 Nov 2011 21:14:51 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RNVak-0001jR-BC; Mon, 07 Nov 2011 21:14:50 +0100 Message-ID: <4EB83C39.9050104@bwijnen.net> Date: Mon, 07 Nov 2011 21:14:49 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <20111104101628.GA2606@nsn.com> <4EB7A8EB.1080106@bwijnen.net> <20111107.210131.227530889.mbj@tail-f.com> In-Reply-To: <20111107.210131.227530889.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd471ab537be4ed16acf7e6d5abe99cca9e Cc: netmod@ietf.org Subject: Re: [netmod] my review of: draft-ietf-netmod-iana-if-type-01 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, 07 Nov 2011 20:14:53 -0000 Inline On 11/7/11 9:01 PM, Martin Bjorklund wrote: > Hi, > > "Bert Wijnen (IETF)" wrote: >> My understanding is that new ifTypes (enumerations) or >> changes (depracating) can ONLY be made in this module >> if a corresponding addition or change if made to the >> ianaIftype-MIB module. >> >> This I conclude from the IANA Considerations clause. > > The Introduction also says: > > This document defines the initial version of the iana-if-type YANG > module. This module reflects IANA's "ifType definitions" registry. > > In the end, the netmod-iana-if-types YANG module will live its own live on the IANA web pages. Probably best to be specific in the MODULE DESCRIPTION clause. At least in my opinion, which is of course just one opinion. Bert > /martin > From mbj@tail-f.com Mon Nov 7 12:36:10 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5249A21F8AEA for ; Mon, 7 Nov 2011 12:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.103, 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 20taKIFSAE2A for ; Mon, 7 Nov 2011 12:36:09 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C4F8421F8AC3 for ; Mon, 7 Nov 2011 12:36:09 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 519551200D13; Mon, 7 Nov 2011 21:36:01 +0100 (CET) Date: Mon, 07 Nov 2011 21:36:00 +0100 (CET) Message-Id: <20111107.213600.315328355.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <4EB83C39.9050104@bwijnen.net> References: <4EB7A8EB.1080106@bwijnen.net> <20111107.210131.227530889.mbj@tail-f.com> <4EB83C39.9050104@bwijnen.net> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] my review of: draft-ietf-netmod-iana-if-type-01 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, 07 Nov 2011 20:36:10 -0000 "Bert Wijnen (IETF)" wrote: > Inline > > On 11/7/11 9:01 PM, Martin Bjorklund wrote: > > Hi, > > > > "Bert Wijnen (IETF)" wrote: > >> My understanding is that new ifTypes (enumerations) or > >> changes (depracating) can ONLY be made in this module > >> if a corresponding addition or change if made to the > >> ianaIftype-MIB module. > >> > >> This I conclude from the IANA Considerations clause. > > > > The Introduction also says: > > > > This document defines the initial version of the iana-if-type YANG > > module. This module reflects IANA's "ifType definitions" registry. > > > > > In the end, the netmod-iana-if-types YANG module will live its own live > on the IANA web pages. Probably best to be specific in the MODULE > DESCRIPTION clause. Ah, ok. So what do you suggest? Is just adding: This module reflects IANA's "ifType definitions" registry. enough? Should we also mention that the module is maintained by IANA? /martin From bertietf@bwijnen.net Mon Nov 7 13:22:48 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E695721F8B43 for ; Mon, 7 Nov 2011 13:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 5-jXC+26PImD for ; Mon, 7 Nov 2011 13:22:48 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4DF21F8B1A for ; Mon, 7 Nov 2011 13:22:48 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RNWeU-0002Og-2J; Mon, 07 Nov 2011 22:22:47 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RNWeT-0005xV-RI; Mon, 07 Nov 2011 22:22:45 +0100 Message-ID: <4EB84C25.80902@bwijnen.net> Date: Mon, 07 Nov 2011 22:22:45 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Martin Bjorklund References: <4EB7A8EB.1080106@bwijnen.net> <20111107.210131.227530889.mbj@tail-f.com> <4EB83C39.9050104@bwijnen.net> <20111107.213600.315328355.mbj@tail-f.com> In-Reply-To: <20111107.213600.315328355.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd43340af6535f1d5d491dc95245eee9707 Cc: netmod@ietf.org Subject: Re: [netmod] my review of: draft-ietf-netmod-iana-if-type-01 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, 07 Nov 2011 21:22:49 -0000 >> In the end, the netmod-iana-if-types YANG module will live its own live >> on the IANA web pages. Probably best to be specific in the MODULE >> DESCRIPTION clause. > > Ah, ok. So what do you suggest? Is just adding: > > This module reflects IANA's "ifType definitions" registry. > > enough? Should we also mention that the module is maintained by IANA? > Yep, and stating that it is maintained by IANA also makes sense in my view. Bert > > /martin > From j.schoenwaelder@jacobs-university.de Tue Nov 8 06:27:29 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F148E21F8C67 for ; Tue, 8 Nov 2011 06:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.154 X-Spam-Level: X-Spam-Status: No, score=-103.154 tagged_above=-999 required=5 tests=[AWL=0.095, 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 fprTjMFwk1u9 for ; Tue, 8 Nov 2011 06:27:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C870C21F8AEE for ; Tue, 8 Nov 2011 06:27:28 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAF2C20DAA; Tue, 8 Nov 2011 15:27:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id P7QKOWxXLHyP; Tue, 8 Nov 2011 15:27:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 187AC20CD3; Tue, 8 Nov 2011 15:27:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4EE061BA9908; Tue, 8 Nov 2011 15:27:07 +0100 (CET) Date: Tue, 8 Nov 2011 15:27:06 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111108142705.GC3081@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <201110102123.RAA29925@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110102123.RAA29925@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: imports 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, 08 Nov 2011 14:27:30 -0000 David, I agree that your writeup how imports should be translated is much better than what we had so far. As far as I can tell from reading the text, the algorithm seems to produce the right behaviour. I have merged your proposed text into the draft and I plan to update my libsmi implementation accordingly, perhaps I manage during my trip to Taipei. /js On Mon, Oct 10, 2011 at 05:23:42PM -0400, David Reid wrote: > I modified our MIB to yang conversion tool to conform to > draft-ietf-netmod-smi-yang-01. Overall, I think the document > is in good shape, but I did run into a few issues for which I > will try to propose solutions. > > To test, I converted all the current standard MIBs to yang and > then ran the converted modules through pyang. I also compared my > output on a couple of the modules to the smidump output. pyang > generated a number of warnings and a few errors. There are also > some differences between what I produce and what smidump produces. > I modified my tool to produce yang modules that compile with no > warnings or errors under pyang and I'm going to try to propose some > text that will address these issues. I have some questions > about some other issues and I need to study some of the issues more before > I can make an intelligent comment. > > I'll address some issues with imports in this message and address other > issues in subsequent messages. I found 3 basic issues with imports: > > 1. Lots of modules produce the pyang warning "imported module FOO not used". > That's not fatal, but I think we can re-write the imports section to > address this. Some examples include object identifier assignments and > objects referenced in conformance and compliance statements. > > 2. There were a couple of errors where we reference objects in > modules that were not imported. Here is an example: ADSL-LINE-EXT-MIB > defines the notification adslAtucFailedFastRThreshTrap which includes the > object adslAtucPerfCurr15MinFailedFastR. adslAtucPerfCurr15MinFailedFastR > is defined in a table that augments adslAtucPerfDataEntry. > adslAtucPerfDataEntry is imported. adslAtucPerfDataEntry is indexed by > ifIndex. ifIndex is not imported in the MIB module since it is not directly > referenced. But in the yang notification, we have to include ifIndex, > therefore, ifIndex needs to be imported. > > 3. A few SMIv2 modules IMPORT from SMIv1 modules, but we don't define rules > for converting SMIv1 modules. For example, RMON2-MIB is an SMIv2 module > which imports from TOKEN-RING-RMON-MIB which is an SMIv1 module. Lots of > modules import RMON2-MIB to get ZeroBasedCounter32, so I think it is > important that RMON2-MIB work (there's also the issue with the same object > used multiple times in the index clause -- I'll address that in a subsequent > message). I don't want to waste a lot of time on SMIv1, but if SMIv2 modules > IMPORT from SMIv1 modules I think we need to address that. See my suggestion > below. > > Here is the text for my proposed solutions. > > In section 4, remove Table 3 and replace the text in the bullet > points with the following: > > o Process each item in each SMIv2 IMPORT clause as follows: > > (1) If an import statement for this SMIv2 module has already been > generated, then ignore this item. > > (2) Otherwise, if the SMIv2 module name is SNMPv2-SMI or SNMPv2-CONF, > then ignore this item. Note that these two modules can be > completely ignored since all definitions in these modules are > translated by translation rules. > > (3) Otherwise, if this item is a textual convention matching one > of the textual conventions in the SMIv2 types column of > Table 1 (MacAddress, PhysAddress, or TimeStamp) then ignore > this item. > > [Note: We may want to add more TCs than just these 3. I'll address > that in a separate e-mail] > > (4) Otherwise, if the item is used in a SYNTAX clause of an OBJECT-TYPE > whose MAX-ACCESS is not accessible-for-notify, then generate an > import statement as described below. > > (5) Otherwise, if the item is used in an OBJECTS clause of a > NOTIFICATION-TYPE, then generate an import statement as described > below. > > (6) Otherwise, if the item is used in an INDEX or AUGMENTS clause, > then generate an import statement as described below. > > (7) Otherwise, ignore this item. Some examples of this case are > OBJECT IDENTIFIER assignments and objects that are only referenced > in MODULE-COMPLIANCE, OBJECT-GROUP, or NOTIFICATION-GROUP clauses. > > o Generate any additional imports statements as required by the type > translations according to the type mapping table (Table 1). This > requires the translator to consider all the types used in the > translation unit in order to produce the imports. > > o Generate an import statement for the yang module ietf-yang-smiv2 with > the prefix smiv2 if extensions from ietf-yang-smiv2 will be used in > the translated yang module. > > Add the following sentence somewhere, perhaps at the end of the first > paragraph in section 1, to address the case where an SMIv2 module imports > from an SMIv1 module: > > SMIv1 modules may be converted to YANG by first following the rules in > RFC 3584 to convert the SMIv1 module to SMIv2, then following the rules > in this document to convert to YANG. > > -David Reid > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Nov 8 08:13:23 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5321F8B05 for ; Tue, 8 Nov 2011 08:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.156 X-Spam-Level: X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=0.093, 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 6-Y8Hiq8wbyV for ; Tue, 8 Nov 2011 08:13:22 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0AB21F88B7 for ; Tue, 8 Nov 2011 08:13:21 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D519A20DAE; Tue, 8 Nov 2011 17:13:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TC3Hm4rApOXW; Tue, 8 Nov 2011 17:13:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B03020DA9; Tue, 8 Nov 2011 17:13:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 65F3E1BA9D16; Tue, 8 Nov 2011 17:13:00 +0100 (CET) Date: Tue, 8 Nov 2011 17:13:00 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111108161300.GA4222@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <201110102126.RAA00111@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110102126.RAA00111@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: 2 more issues 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, 08 Nov 2011 16:13:23 -0000 On Mon, Oct 10, 2011 at 05:26:30PM -0400, David Reid wrote: > > Here are a couple more issues with the mib to yang conversion and proposed > solutions. > > Problem: > If a table index is accessible-for-notify, it is not translated to yang. > For example, in MIP-MIB (RFC 2006), the object mipSecViolatorAddress is > a table index and has a MAX-ACCESS of accessible-for-notify. According > to the current conversion rules (section 8.1), mipSecViolatorAddress > will be dropped. But since it is a table index, it must be preserved. > > Proposed Solution: > Add the following sentence as the second sentence in section 1.8: > Additionally, columnar objects with a MAX-ACCESS of accessible-for-notify > are translated to YANG leaf statements if that columnar object is part of > the INDEX clause of the table containing that columnar object. Yes, this makes sense. I have added the sentence you suggested. > Problem: > RMON2-MIB (RFC 4502) has an INDEX clause in which the same object appears > twice. Specifically, alHostEntry's INDEX clause uses protocolDirLocalIndex > twice. Following the current conversion rules results in a translated > document that violates the YANG rule that a leaf identifier MUST NOT appear > more than once in the key. > > Proposed Solution: > Section 8.3 in the last bullet point on page 15, add a sentence somthing > like this: If the same object appears more than once in the INDEX > clause, append - to the second and subsequent duplicate object names > where is a number representing the number of times that object has > appeared up to this point in the INDEX clause. [not sure I stated that > clearly. I'm trying to say that the key statement for alHostEntry should be > key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex nlHostAddress protocolDirLocalIndex-2";] I have tried to create text: o The SMIv2 INDEX clause is mapped to the YANG key clause listing the columnar objects forming the key of the YANG list. If the same object appears more than once in the INDEX clause, append '-' to the object name where '' counts the occurances of the object in the INDEX clause, starting from 1. This would result in key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex-1 " "nlHostAddress protocolDirLocalIndex-2"; which is slightly different since it modifies all duplicate names while you left the first untouched. I guess we also need to state that in this case also multiple leafs with suitable names need to be generated, right? Hm, this is really a nasty corner case to deal with. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From reid@snmp.com Tue Nov 8 08:46:02 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261AB21F8B80 for ; Tue, 8 Nov 2011 08:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 mPsKdhFxraK5 for ; Tue, 8 Nov 2011 08:46:01 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4857721F8B7F for ; Tue, 8 Nov 2011 08:46:00 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA10104; Tue, 8 Nov 2011 11:45:59 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA02052; Tue, 8 Nov 2011 11:45:58 -0500 (EST) Message-Id: <201111081645.LAA02052@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Tue, 08 Nov 2011 17:13:00 +0100. <20111108161300.GA4222@elstar.local> Date: Tue, 08 Nov 2011 11:45:58 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: 2 more issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 16:46:02 -0000 > > Problem: > > RMON2-MIB (RFC 4502) has an INDEX clause in which the same object appears > > twice. Specifically, alHostEntry's INDEX clause uses protocolDirLocalIndex > > twice. Following the current conversion rules results in a translated > > document that violates the YANG rule that a leaf identifier MUST NOT appear > > more than once in the key. > > > > Proposed Solution: > > Section 8.3 in the last bullet point on page 15, add a sentence somthing > > like this: If the same object appears more than once in the INDEX > > clause, append - to the second and subsequent duplicate object names > > where is a number representing the number of times that object has > > appeared up to this point in the INDEX clause. [not sure I stated that > > clearly. I'm trying to say that the key statement for alHostEntry should be > > key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex nlHostAddress protocolDirLocalIndex-2";] > > I have tried to create text: > > o The SMIv2 INDEX clause is mapped to the YANG key clause listing > the columnar objects forming the key of the YANG list. If the > same object appears more than once in the INDEX clause, append > '-' to the object name where '' counts the occurances of the > object in the INDEX clause, starting from 1. That sounds good. > > This would result in > > key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex-1 " > "nlHostAddress protocolDirLocalIndex-2"; > > which is slightly different since it modifies all duplicate names > while you left the first untouched. That's fine. Your way does make the text read a little better. > I guess we also need to state that > in this case also multiple leafs with suitable names need to be > generated, right? Yes. I did that in my implementation, but I guess my text didn't say that. > Hm, this is really a nasty corner case to deal with. Yep. RMON-2 is the only MIB I know of that does this. But a lot of MIBs import from RMON-2, so I think it's worth dealing with. -David Reid From j.schoenwaelder@jacobs-university.de Tue Nov 8 11:23:13 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859ED11E8094 for ; Tue, 8 Nov 2011 11:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.158 X-Spam-Level: X-Spam-Status: No, score=-103.158 tagged_above=-999 required=5 tests=[AWL=0.091, 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 FohyNBipNzFZ for ; Tue, 8 Nov 2011 11:23:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9E97A11E808B for ; Tue, 8 Nov 2011 11:23:12 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F06BF20D85; Tue, 8 Nov 2011 20:23:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JEn9cnL9YAtX; Tue, 8 Nov 2011 20:23:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20FEE20D79; Tue, 8 Nov 2011 20:23:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E64F71BAA24D; Tue, 8 Nov 2011 20:22:53 +0100 (CET) Date: Tue, 8 Nov 2011 20:22:53 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111108192253.GB5219@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <20111108161300.GA4222@elstar.local> <201111081645.LAA02052@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111081645.LAA02052@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: 2 more issues 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, 08 Nov 2011 19:23:13 -0000 On Tue, Nov 08, 2011 at 11:45:58AM -0500, David Reid wrote: > > > Problem: > > > RMON2-MIB (RFC 4502) has an INDEX clause in which the same object appears > > > twice. Specifically, alHostEntry's INDEX clause uses protocolDirLocalIndex > > > twice. Following the current conversion rules results in a translated > > > document that violates the YANG rule that a leaf identifier MUST NOT appear > > > more than once in the key. > > > > > > Proposed Solution: > > > Section 8.3 in the last bullet point on page 15, add a sentence somthing > > > like this: If the same object appears more than once in the INDEX > > > clause, append - to the second and subsequent duplicate object names > > > where is a number representing the number of times that object has > > > appeared up to this point in the INDEX clause. [not sure I stated that > > > clearly. I'm trying to say that the key statement for alHostEntry should be > > > key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex nlHostAddress protocolDirLocalIndex-2";] > > > > I have tried to create text: > > > > o The SMIv2 INDEX clause is mapped to the YANG key clause listing > > the columnar objects forming the key of the YANG list. If the > > same object appears more than once in the INDEX clause, append > > '-' to the object name where '' counts the occurances of the > > object in the INDEX clause, starting from 1. > > That sounds good. > > > > > This would result in > > > > key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex-1 " > > "nlHostAddress protocolDirLocalIndex-2"; > > > > which is slightly different since it modifies all duplicate names > > while you left the first untouched. > > That's fine. Your way does make the text read a little better. While biking home, I realized this is broken. We have to keep the original leaf untouched because it might be referenced elsewhere. So we need to introduce additional leafs and we should give them names that they will never ever conflict with an SMIv2 name. I suggest to use an underscore character since underscore character are not allowed in SMIv2 land. Since in many programming languages an underscore is used to mark an identifier as "somewhat private", we could do this here as well to mark identifiers created by the translation algorithm by prefixing them with an underscore. So we would have something like key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex " "nlHostAddress _protocolDirLocalIndex2"; > > Hm, this is really a nasty corner case to deal with. > > Yep. RMON-2 is the only MIB I know of that does this. But a lot of > MIBs import from RMON-2, so I think it's worth dealing with. Yes, no doubt, we need to be able to translate all valid SMIv2 MIB modules of the IETF to valid YANG modules. This is a good test. I think I will even add the RMON2 case as an 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 Tue Nov 8 11:35:20 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5B421F8B34 for ; Tue, 8 Nov 2011 11:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.16 X-Spam-Level: X-Spam-Status: No, score=-103.16 tagged_above=-999 required=5 tests=[AWL=0.089, 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 0S5ejJDDz5CB for ; Tue, 8 Nov 2011 11:35:20 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9EF21F8B1E for ; Tue, 8 Nov 2011 11:35:11 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4B3020D89; Tue, 8 Nov 2011 20:35:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qPf9yYYazGN9; Tue, 8 Nov 2011 20:35:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B98320D85; Tue, 8 Nov 2011 20:35:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CABA41BAA346; Tue, 8 Nov 2011 20:34:53 +0100 (CET) Date: Tue, 8 Nov 2011 20:34:53 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111108193453.GD5219@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <201110112053.QAA12845@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110112053.QAA12845@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: minor typos 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, 08 Nov 2011 19:35:21 -0000 On Tue, Oct 11, 2011 at 04:53:53PM -0400, David Reid wrote: > Here are a few very minor nits in draft-ietf-netmod-smi-yang-01: > > Section 1, first sentence > s/an translation/a translation/ fixed > Section 4, first sentence of 2nd paragraph: > s/which followed/which is followed/ fixed > Section 8.1, first sentence. Also, section 10.1, second bullet: > s/""read-create"/"read-create"/ fixed > Section 10.2 > The description statement for object-1 and object-2 is mission ']'. > I think it might be better to just remove the description statement from > the example for automatically generated nodes. fixed (I kept the descriptions for now) > Section 11: > in the alias extension, the argument statement is missing a ';'. fixed /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From reid@snmp.com Tue Nov 8 12:12:48 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4561C21F8AD1 for ; Tue, 8 Nov 2011 12:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 hYwOxkN65Yn0 for ; Tue, 8 Nov 2011 12:12:47 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 64D2021F8ACC for ; Tue, 8 Nov 2011 12:12:47 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA28056; Tue, 8 Nov 2011 15:12:46 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA09056; Tue, 8 Nov 2011 15:12:46 -0500 (EST) Message-Id: <201111082012.PAA09056@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Tue, 08 Nov 2011 20:22:53 +0100. <20111108192253.GB5219@elstar.local> Date: Tue, 08 Nov 2011 15:12:45 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: 2 more issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 20:12:48 -0000 > On Tue, Nov 08, 2011 at 11:45:58AM -0500, David Reid wrote: > > > > Problem: > > > > RMON2-MIB (RFC 4502) has an INDEX clause in which the same object appears > > > > twice. Specifically, alHostEntry's INDEX clause uses protocolDirLocalIndex > > > > twice. Following the current conversion rules results in a translated > > > > document that violates the YANG rule that a leaf identifier MUST NOT appear > > > > more than once in the key. > > > > > > > > Proposed Solution: > > > > Section 8.3 in the last bullet point on page 15, add a sentence somthing > > > > like this: If the same object appears more than once in the INDEX > > > > clause, append - to the second and subsequent duplicate object names > > > > where is a number representing the number of times that object has > > > > appeared up to this point in the INDEX clause. [not sure I stated that > > > > clearly. I'm trying to say that the key statement for alHostEntry should be > > > > key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex nlHostAddress protocolDirLocalIndex-2";] > > > > > > I have tried to create text: > > > > > > o The SMIv2 INDEX clause is mapped to the YANG key clause listing > > > the columnar objects forming the key of the YANG list. If the > > > same object appears more than once in the INDEX clause, append > > > '-' to the object name where '' counts the occurances of the > > > object in the INDEX clause, starting from 1. > > > > That sounds good. > > > > > > > > This would result in > > > > > > key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex-1 " > > > "nlHostAddress protocolDirLocalIndex-2"; > > > > > > which is slightly different since it modifies all duplicate names > > > while you left the first untouched. > > > > That's fine. Your way does make the text read a little better. > > While biking home, I realized this is broken. We have to keep the > original leaf untouched because it might be referenced elsewhere. So > we need to introduce additional leafs and we should give them names > that they will never ever conflict with an SMIv2 name. I suggest to > use an underscore character since underscore character are not allowed > in SMIv2 land. Since in many programming languages an underscore is > used to mark an identifier as "somewhat private", we could do this > here as well to mark identifiers created by the translation algorithm > by prefixing them with an underscore. So we would have something like > > key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex " > "nlHostAddress _protocolDirLocalIndex2"; Good point. Why is it necessary to never ever conflict with an SMIv2 name? Is it not good enough that it does not conflict with any names in that module? -David Reid From j.schoenwaelder@jacobs-university.de Wed Nov 9 03:52:49 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E43E21F8C61 for ; Wed, 9 Nov 2011 03:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.162 X-Spam-Level: X-Spam-Status: No, score=-103.162 tagged_above=-999 required=5 tests=[AWL=0.087, 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 oJTQEC6Fan0z for ; Wed, 9 Nov 2011 03:52:48 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABDC21F8C5F for ; Wed, 9 Nov 2011 03:52:48 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F17720D5C; Wed, 9 Nov 2011 12:52:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xyiXj6w1hljS; Wed, 9 Nov 2011 12:52:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C168320DE6; Wed, 9 Nov 2011 12:52:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1A4E31BAAEBA; Wed, 9 Nov 2011 12:52:27 +0100 (CET) Date: Wed, 9 Nov 2011 12:52:27 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111109115227.GC263@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <20111108192253.GB5219@elstar.local> <201111082012.PAA09056@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111082012.PAA09056@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: 2 more issues 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, 09 Nov 2011 11:52:49 -0000 On Tue, Nov 08, 2011 at 03:12:45PM -0500, David Reid wrote: > > While biking home, I realized this is broken. We have to keep the > > original leaf untouched because it might be referenced elsewhere. So > > we need to introduce additional leafs and we should give them names > > that they will never ever conflict with an SMIv2 name. I suggest to > > use an underscore character since underscore character are not allowed > > in SMIv2 land. Since in many programming languages an underscore is > > used to mark an identifier as "somewhat private", we could do this > > here as well to mark identifiers created by the translation algorithm > > by prefixing them with an underscore. So we would have something like > > > > key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex " > > "nlHostAddress _protocolDirLocalIndex2"; > > Good point. > > Why is it necessary to never ever conflict with an SMIv2 name? Is it not > good enough that it does not conflict with any names in that module? I think it is generally a good idea to keep namespaces clean. Suppose someone adds a MIB object protocolDirLocalIndex-2 to RMON2-MIB. Although perhaps unlikely, we would have a serious problem with our translation algorithm if it happens. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From reid@snmp.com Wed Nov 9 06:13:26 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C5F21F8B9D for ; Wed, 9 Nov 2011 06:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 u04PFF-NvvXJ for ; Wed, 9 Nov 2011 06:13:26 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id A15E321F8B40 for ; Wed, 9 Nov 2011 06:13:25 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA17045; Wed, 9 Nov 2011 09:13:11 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id JAA01601; Wed, 9 Nov 2011 09:13:06 -0500 (EST) Message-Id: <201111091413.JAA01601@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Wed, 09 Nov 2011 12:52:27 +0100. <20111109115227.GC263@elstar.local> Date: Wed, 09 Nov 2011 09:13:06 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: 2 more issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 14:13:26 -0000 > On Tue, Nov 08, 2011 at 03:12:45PM -0500, David Reid wrote: > > > > While biking home, I realized this is broken. We have to keep the > > > original leaf untouched because it might be referenced elsewhere. So > > > we need to introduce additional leafs and we should give them names > > > that they will never ever conflict with an SMIv2 name. I suggest to > > > use an underscore character since underscore character are not allowed > > > in SMIv2 land. Since in many programming languages an underscore is > > > used to mark an identifier as "somewhat private", we could do this > > > here as well to mark identifiers created by the translation algorithm > > > by prefixing them with an underscore. So we would have something like > > > > > > key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex " > > > "nlHostAddress _protocolDirLocalIndex2"; > > > > Good point. > > > > Why is it necessary to never ever conflict with an SMIv2 name? Is it not > > good enough that it does not conflict with any names in that module? > > I think it is generally a good idea to keep namespaces clean. Suppose > someone adds a MIB object protocolDirLocalIndex-2 to RMON2-MIB. > Although perhaps unlikely, we would have a serious problem with our > translation algorithm if it happens. That makes sense. I like your idea of using a leading underscore. -David Reid From j.schoenwaelder@jacobs-university.de Wed Nov 9 07:25:16 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E136A21F8C28 for ; Wed, 9 Nov 2011 07:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.164 X-Spam-Level: X-Spam-Status: No, score=-103.164 tagged_above=-999 required=5 tests=[AWL=0.085, 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 RBHrgBe-fGrx for ; Wed, 9 Nov 2011 07:25:12 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 40AF921F8AFA for ; Wed, 9 Nov 2011 07:25:12 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6AFFB20E13; Wed, 9 Nov 2011 16:25:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Rg1jJduhdx5c; Wed, 9 Nov 2011 16:25:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F49D20DE0; Wed, 9 Nov 2011 16:25:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8EBDC1BAC1C9; Wed, 9 Nov 2011 16:24:46 +0100 (CET) Date: Wed, 9 Nov 2011 16:24:46 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111109152445.GG263@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <201110121912.PAA25588@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110121912.PAA25588@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 15:25:17 -0000 On Wed, Oct 12, 2011 at 03:12:34PM -0400, David Reid wrote: > I have a few suggestions for ietf-yang-smiv2.yang in > draft-ietf-netmod-smi-yang-01: > > 1. Add an extension to indicate if an index object is IMPLIED. I believe that > with this one addition a tool could get all of the MIB information it > needs from the converted yang module. > > extension implied { > argument "index"; > description > "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then > the implied statement is present in the yang module and takes as > an argument the name of the IMPLIED index object."; > reference > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > } I am not strictly against it but I do not really understand the use case for this. For data shipped over NETCONF, it does not matter whether the INDEX is IMPLIED or not. > 2. Modify the description clause of the oid extension to allow a more > user-friendly format. For example, ifEntry could be written as > ifTable.1 instead of 1.3.6.1.2.1.2.2.1, or perhaps just .1 as a > short hand notation. > > extension oid { > argument "value"; > description > "The oid statement takes as an argument the object identifier > assigned to an SMIv2 definition. The object identifier value > is written in dotted decimal notation. If an oid statement > exists for the parent object identifier, then the value may > be written in a short hand notation of the form > . or just > .. For example, the oid value for ifTable from > IF-MIB would be '1.3.6.1.2.1.2.2'. The value for ifEntry could be > '1.3.6.1.2.1.2.2.1', 'ifTable.1', or simply '.1'. Similarily, > ifDescr could be '1.3.6.1.2.1.2.2.1.2', 'ifEntry.2', or '.2'"; > reference > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > } This already was discussed and so far it seems Andy and me prefer to keep the value a full OID. If other representations are really needed, we should have additional aliases instead of complicating life by allowing translations to generate whatever they prefer. > 3. The alias extension is a useful addition. I would like to see it mentioned > in the body of the document much like the oid extension is mentioned. Here > are the suggested changes: > > Section 7: > > The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for > intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER > assignments MAY be translated into smiv2:alias statements, see the > YANG extension defined in Section 11. OK > Section 8.6, first paragraph: > > An OBJECT-TYPE macro invocation defining an augmenting conceptual > table MAY be translated into an smiv2:alias statement, see the > YANG extension defined in Section 11. The clauses of the macro are > translated as follows: > > o The SMIv2 SYNTAX clause is ignored. > > o The SMIv2 UNITS clause is ignored. > > o The SMIv2 MAX-ACCESS clause is ignored. > > o The SMIv2 STATUS clause is mapped to the YANG status statement. > The generation of the YANG status statement is skipped if the > value of the STATUS clause is current. > > o The SMIv2 DESCRIPTION clause is mapped to the YANG description > statement. > > o The SMIv2 REFERENCE clause is mapped to the YANG reference > statement. > > o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be > translated into an smiv2:oid statement, see the YANG extension > defined in Section 11. I am not sure I understand what you are trying to achieve. Is your idea to stick the status/description/reference statements into the alias statement? > Section 8.6, second paragraph, add one more bullet: > > o The name of the SMIv2 OBJECT-TYPE macro invocation MAY be > translated into an smiv2:alias statement, see the YANG extension > defined in Section 11. If we add this here, would we not also have to add this at other places, e.g. sections 8.1, 8.3, 9 and likely a few more places? Perhaps we should agree on what we are producing. Right now, smidump translates ifEntry into a YANG leaf that has an embedded smiv2:oid statement. In addition, I am creating a top-level smiv2:alias statement for all defined SMIv2 identifiers containing another smiv2:oid statement, that is, for the ifEntry I have: // .. list ifEntry { key "ifIndex"; description "An entry containing management information applicable to a particular interface."; smiv2:oid "1.3.6.1.2.1.2.2.1"; // ... } // ... smiv2:alias "ifEntry" { smiv2:oid "1.3.6.1.2.1.2.2.1"; } > 4. With respect to generating the smiv2 extensions, I would prefer MAY to be > changed to SHOULD to encourage implementations to include the extensions. I am OK with that change. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Nov 9 08:04:49 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444E621F8C43 for ; Wed, 9 Nov 2011 08:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.166 X-Spam-Level: X-Spam-Status: No, score=-103.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 31D7x7A6uk1y for ; Wed, 9 Nov 2011 08:04:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AD96B21F8BC5 for ; Wed, 9 Nov 2011 08:04:44 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D5AA20D00; Wed, 9 Nov 2011 17:04:44 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PHLMD8rQ1EAs; Wed, 9 Nov 2011 17:04:42 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48B8220D01; Wed, 9 Nov 2011 17:04:42 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B26841BAC2FE; Wed, 9 Nov 2011 17:04:24 +0100 (CET) Date: Wed, 9 Nov 2011 17:04:24 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111109160424.GA1441@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <201110132119.RAA06352@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110132119.RAA06352@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: type mapping table 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, 09 Nov 2011 16:04:49 -0000 On Thu, Oct 13, 2011 at 05:19:10PM -0400, David Reid wrote: > I have a few questions about Table 1 which defines the maping of SMIv2 > types to YANG types. > > 1. OBJECT IDENTIFIER maps to yang:object-identifier. Should it be > yang:object-identifier-128? Makes sense (unfortunately ;-). > 2. Table 1 maps all the built-in SMIv2 types to yang types or typedefs, which > is clearly necessary. It also maps 3 common textual conventions. I was > wondering why these 3 where chosen. I guess I would have expected either > that more TCs would be mapped (like ZeroBasedCounter32 for example) or none > of the TCs would be mapped. I'm not suggesting any changes, just trying > to understand the reasoning behind the way it is done. I probably simply overlooked the ZeroBasedCounter* types. They are listed as having an equivalent type in the YANG world in Table 1 of RFC 6021. > 3. This is related to #2 above. Would it make sense to map TruthValue to > boolean since the TruthValue labels (true/false) match the netconf > encoding of booleans. This might makes sense. The translation of the TruthValue TC results in an enumeration defining the two enum values 'true' and 'false' and hence the on the wire result in XML instance documents really is the same. By using boolean, we would loose the assigned numeric values of the enums, so a reader of the translated MIB module would have to know that true is represented as 1 and false as 2 in the SNMP world (but then for NETCONF payload and YANG/NETCONF aware applications, this does not matter at all). I think I can go either direction on this. > 4. I'm not entirely comfortable using DISPLAY-HINT to determine the type. If > we didn't use DISPLAY-HINT, we could consider creating mapping rules for > some of the well known string-type TCs like DisplayString, Utf8String, > SnmpAdminString, etc. Although I don't really like having a lot of > special case mapping rules, so I'm not sure this is a good idea. Yes, trying to enumerate TCs that are to be treated as strings instead of binary data is not going to work well here. The difficulty here is that there is no way to extend the list of well known TCs without causing different results when modules are translated at different points in time, something we should avoid. > Side note: CHARACTER-MIB (rfc1658) uses DisplayString without importing it. > I've seen other MIBs do that with DisplayString. I added a hack to my tool > to handle that case. I don't think the document needs to account for broken > MIBs, but I thought I'd point this one out since it is in a standard MIB. But at the end, these are broken SMIv2 modules. If you need to translate them, simply fix the module before running the translator. The IETF MIB modules that have such problems and are shipped with smidump have been fixed manually. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From reid@snmp.com Wed Nov 9 09:46:10 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8012511E809C for ; Wed, 9 Nov 2011 09:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 JJXmB-mSPJwZ for ; Wed, 9 Nov 2011 09:46:09 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1C60A11E809D for ; Wed, 9 Nov 2011 09:46:09 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA03190; Wed, 9 Nov 2011 12:45:44 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA07192; Wed, 9 Nov 2011 12:45:39 -0500 (EST) Message-Id: <201111091745.MAA07192@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Wed, 09 Nov 2011 16:24:46 +0100. <20111109152445.GG263@elstar.local> Date: Wed, 09 Nov 2011 12:45:39 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 17:46:10 -0000 > On Wed, Oct 12, 2011 at 03:12:34PM -0400, David Reid wrote: > > I have a few suggestions for ietf-yang-smiv2.yang in > > draft-ietf-netmod-smi-yang-01: > > > > 1. Add an extension to indicate if an index object is IMPLIED. I believe that > > with this one addition a tool could get all of the MIB information it > > needs from the converted yang module. > > > > extension implied { > > argument "index"; > > description > > "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then > > the implied statement is present in the yang module and takes as > > an argument the name of the IMPLIED index object."; > > reference > > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > > } > > I am not strictly against it but I do not really understand the use > case for this. For data shipped over NETCONF, it does not matter > whether the INDEX is IMPLIED or not. We use the same method routines to supply data to the netconf server and the SNMP agent (and CLI and web). The current smiv2 extensions provide every other useful piece of information from the SMIv2 module except this one. With this one addition, my yang compiler can read the converted module and produce method routines that can be used by both netconf and SNMP. Maybe this is a silly argument since I can of course use my MIB compiler to read the original MIB document and get the same result, which is what I normally do. But I can imagine that a netconf/yang shop might prefer to drive all the tools from yang modules and expect SNMP to come along for free. Additionally, our sort order is the same for netconf and SNMP. This is not a requirement, but it seems logical. The implied extension gives the netconf client a hint about the ordering. > > > 2. Modify the description clause of the oid extension to allow a more > > user-friendly format. For example, ifEntry could be written as > > ifTable.1 instead of 1.3.6.1.2.1.2.2.1, or perhaps just .1 as a > > short hand notation. > > > > extension oid { > > argument "value"; > > description > > "The oid statement takes as an argument the object identifier > > assigned to an SMIv2 definition. The object identifier value > > is written in dotted decimal notation. If an oid statement > > exists for the parent object identifier, then the value may > > be written in a short hand notation of the form > > . or just > > .. For example, the oid value for ifTable from > > IF-MIB would be '1.3.6.1.2.1.2.2'. The value for ifEntry could be > > '1.3.6.1.2.1.2.2.1', 'ifTable.1', or simply '.1'. Similarily, > > ifDescr could be '1.3.6.1.2.1.2.2.1.2', 'ifEntry.2', or '.2'"; > > reference > > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > > } > > This already was discussed and so far it seems Andy and me prefer to > keep the value a full OID. If other representations are really needed, > we should have additional aliases instead of complicating life by > allowing translations to generate whatever they prefer. The main reason I wanted to add this was to make the yang module more readable. It does not help my tools in any way. It also makes it easier for the yang module writer. Of course, this document is aimed at automated tools doing the translation. But I plan to use these extensions in some cases to manually assign OIDs to objects defined in yang modules so that I can access them from SNMP. > > > 3. The alias extension is a useful addition. I would like to see it mentioned > > in the body of the document much like the oid extension is mentioned. Here > > are the suggested changes: > > > > Section 7: > > > > The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for > > intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER > > assignments MAY be translated into smiv2:alias statements, see the > > YANG extension defined in Section 11. > > OK > > > Section 8.6, first paragraph: > > > > An OBJECT-TYPE macro invocation defining an augmenting conceptual > > table MAY be translated into an smiv2:alias statement, see the > > YANG extension defined in Section 11. The clauses of the macro are > > translated as follows: > > > > o The SMIv2 SYNTAX clause is ignored. > > > > o The SMIv2 UNITS clause is ignored. > > > > o The SMIv2 MAX-ACCESS clause is ignored. > > > > o The SMIv2 STATUS clause is mapped to the YANG status statement. > > The generation of the YANG status statement is skipped if the > > value of the STATUS clause is current. > > > > o The SMIv2 DESCRIPTION clause is mapped to the YANG description > > statement. > > > > o The SMIv2 REFERENCE clause is mapped to the YANG reference > > statement. > > > > o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be > > translated into an smiv2:oid statement, see the YANG extension > > defined in Section 11. > > I am not sure I understand what you are trying to achieve. Is your > idea to stick the status/description/reference statements into the > alias statement? I was trying to move the information from comments to machine readable fields. I think the text in the current document was written before we had the alias extension, so adding comments was the only way to preserve the information. The only parts I really need are the descriptor and oid. ifXTable would look like this: smiv2:alias ifXTable { smiv2:oid "1.3.6.1.2.1.31.1.1"; description "A list of interface entries. The number of entries is given by the value of ifNumber. This table contains additional objects for the interface table."; } > > > Section 8.6, second paragraph, add one more bullet: > > > > o The name of the SMIv2 OBJECT-TYPE macro invocation MAY be > > translated into an smiv2:alias statement, see the YANG extension > > defined in Section 11. > > If we add this here, would we not also have to add this at other > places, e.g. sections 8.1, 8.3, 9 and likely a few more places? > Perhaps we should agree on what we are producing. Right now, smidump > translates ifEntry into a YANG leaf that has an embedded smiv2:oid > statement. In addition, I am creating a top-level smiv2:alias > statement for all defined SMIv2 identifiers containing another > smiv2:oid statement, that is, for the ifEntry I have: The only reason I wanted alias here was because the descriptor for augmenting tables is not otherwise in the yang module. It is not needed in the other sections since the descriptor is translation to yang. I think I do the translation a little different than you, see below. > > // .. > > list ifEntry { > key "ifIndex"; > description > "An entry containing management information applicable to a > particular interface."; > smiv2:oid "1.3.6.1.2.1.2.2.1"; > > // ... > } > > // ... > > smiv2:alias "ifEntry" { > smiv2:oid "1.3.6.1.2.1.2.2.1"; > } I don't create an alias for ifEntry since the descriptor and smiv2:oid are included in the list definition. I only create an alias for things not otherwise included like ifMIB, ifMIBObjects, and interfaces. The problem I had was that I was not translating the descriptor for augmenting entries like ifXEntry. ifEntry looks something like this: list ifEntry { smiv2:oid "1.3.6.1.2.1.2.2.1"; key "ifIndex"; description ... ifXEntry looks somthing like this: augment /ifTable/ifEntry { smiv2:oid "1.3.6.1.2.1.31.1.1.1"; description .... The missing piece is the descriptor ifXEntry. I wanted to do something like this: augment /ifTable/ifEntry { smiv2:alias "ifXEntry" { smiv2:oid "1.3.6.1.2.1.31.1.1.1"; } description I guess I could just as easily put the alias outside the augment container and no changes would be required. But I kind of like having it inside the augment container. > > > 4. With respect to generating the smiv2 extensions, I would prefer MAY to be > > changed to SHOULD to encourage implementations to include the extensions. > > I am OK with that change. > > /js > -David Reid From spakes@snmp.com Wed Nov 9 13:52:14 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8496E11E8085 for ; Wed, 9 Nov 2011 13:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_48=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 Zu75ldJkn+wm for ; Wed, 9 Nov 2011 13:52:13 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5612811E8080 for ; Wed, 9 Nov 2011 13:52:12 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA20309; Wed, 9 Nov 2011 16:52:09 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA13548; Wed, 9 Nov 2011 16:51:58 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 9 Nov 2011 16:51:57 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20111109160424.GA1441@elstar.local> Message-ID: References: <201110132119.RAA06352@adminfs.snmp.com> <20111109160424.GA1441@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] mib to yang conversion: type mapping table X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 21:52:14 -0000 On Wed, 9 Nov 2011, Juergen Schoenwaelder wrote: > On Thu, Oct 13, 2011 at 05:19:10PM -0400, David Reid wrote: > > I have a few questions about Table 1 which defines the maping of SMIv2 > > types to YANG types. > > > > 1. OBJECT IDENTIFIER maps to yang:object-identifier. Should it be > > yang:object-identifier-128? > > Makes sense (unfortunately ;-). > > > 2. Table 1 maps all the built-in SMIv2 types to yang types or > typedefs, which is clearly necessary. It also maps 3 common > textual conventions. I was wondering why these 3 where chosen. I > guess I would have expected either that more TCs would be mapped > (like ZeroBasedCounter32 for example) or none of the TCs would > be mapped. I'm not suggesting any changes, just trying to > understand the reasoning behind the way it is done. > > I probably simply overlooked the ZeroBasedCounter* types. They are > listed as having an equivalent type in the YANG world in Table 1 of > RFC 6021. > > > 3. This is related to #2 above. Would it make sense to map > TruthValue to boolean since the TruthValue labels (true/false) > match the netconf encoding of booleans. > > This might makes sense. The translation of the TruthValue TC results > in an enumeration defining the two enum values 'true' and 'false' and > hence the on the wire result in XML instance documents really is the > same. By using boolean, we would loose the assigned numeric values of > the enums, so a reader of the translated MIB module would have to know > that true is represented as 1 and false as 2 in the SNMP world (but > then for NETCONF payload and YANG/NETCONF aware applications, this > does not matter at all). I think I can go either direction on this. The TruthValue TC and YANG boolean represent the same information, even if the enumerated values are different. The document should map TruthValue to boolean. A software entity that handles both SNMP and NETCONF data should be prepared to transform between the SNMP-centric [1,2] and NETCONF-centric [0,1] enumerations. I believe this same line of reasoning should prevail even when the semantic equivalency is not as clear-cut. When draft-ietf-netmod-yang-types-01.txt was current, I built this list of SMIv2 types and textual conventions and their semantic equivalents for YANG. I found out later that yang:date-and-time is a near superset of DateAndTime, since it can represent Zulu time in addition to UTC time, so only partially equivalent. SMIv2 YANG Reference ----- ---- --------- Integer32 int32 RFC 2578 INTEGER int32 RFC 1155 Unsigned32 uint32 RFC 2578 UInteger32 uint32 RFC 1442 DisplayString string RFC 1213 OctetString binary RFC 1155 Null empty RFC 1155 Opaque binary RFC 2578 TruthValue boolean RFC 2579 AutonomousType identityref RFC 2579 Bits bits RFC 2579 Counter32 yang:counter32 RFC 2578 Counter yang:counter32 RFC 1155 ZeroBasedCounter32 yang:zero-based-counter32 RFC 4502 Counter64 yang:counter64 RFC 2578 ZeroBasedCounter64 yang:zero-based-counter64 RFC 2856 Gauge32 yang:gauge32 RFC 2578 Gauge yang:gauge32 RFC 1155 CounterBasedGauge64 yang:gauge64 RFC 2856 ObjectID yang:object-identifier-128 RFC 2578 DateAndTime yang:date-and-time RFC 2579 TimeTicks yang:timeticks RFC 2578 TimeStamp yang:timestamp RFC 2579 PhysAddress yang:phys-address RFC 2579 InetVersion inet:ip-version RFC 4001 Dscp inet:dscp RFC 3289 IPv6FlowLabel inet:flow-label RFC 3595 InetPortNumber inet:port-number RFC 4001 InetAutonomousSystemNumber inet:as-number RFC 4001 InetAddressIPv4 inet:ipv4-address RFC 4001 InetAddressIPv4z inet:ipv4-address RFC 4001 IpAddress inet:ipv4-address RFC 2578 InetAddressIPv6 inet:ipv6-address RFC 4001 InetAddressIPv6z inet:ipv6-address RFC 4001 InetAddressDNS inet:domain-name RFC 4001 InetAddress inet:host RFC 4001 Uri inet:uri RFC 5017 MacAddress ieee:mac-address RFC 2579 BridgeId ieee:bridgeid RFC 4188 VlanId ieee:vlanid RFC 4363 I tried to be thorough, but I too have probably overlooked some TCs from standard MIBs. If the document is going to map any of the standards-track TCs to YANG, I believe it should map all of them (that have a YANG equivalent). The document should identify the transformations that are necessary to covert data between formats. > > Side note: CHARACTER-MIB (rfc1658) uses DisplayString without > > importing it. I've seen other MIBs do that with DisplayString. > > I added a hack to my tool to handle that case. I don't think the > > document needs to account for broken MIBs, but I thought I'd > > point this one out since it is in a standard MIB. > > But at the end, these are broken SMIv2 modules. If you need to > translate them, simply fix the module before running the translator. > The IETF MIB modules that have such problems and are shipped with > smidump have been fixed manually. I observed that DisplayString existed before SMIv2. It was defined in RFC 1158 and later in RFC 1213. RFC 1213 was a Full Standard at the time RFC 1658 was published. RFC 1443 (predecessor to the current SNMPv2-TC, RFC 2579) was published as Proprosed Standard in April, 1993, a little more than a year before RFC 1658 was published in July, 1994. That suggests that RFC 1658 should have been changed to import from RFC 1443 before it was published. However, the author may have reasoned that the Full Standard definition of DisplayString in RFC 1213 trumped the then-Proposed Standard TC. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From spakes@snmp.com Wed Nov 9 14:40:18 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A14C11E808E for ; Wed, 9 Nov 2011 14:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 3jJnSMwRa+4L for ; Wed, 9 Nov 2011 14:40:17 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2136311E8087 for ; Wed, 9 Nov 2011 14:40:16 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA22717; Wed, 9 Nov 2011 17:40:03 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA14626; Wed, 9 Nov 2011 17:39:59 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 9 Nov 2011 17:39:58 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20111109152445.GG263@elstar.local> Message-ID: References: <201110121912.PAA25588@adminfs.snmp.com> <20111109152445.GG263@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:40:18 -0000 On Wed, 9 Nov 2011, Juergen Schoenwaelder wrote: > On Wed, Oct 12, 2011 at 03:12:34PM -0400, David Reid wrote: > > I have a few suggestions for ietf-yang-smiv2.yang in > > draft-ietf-netmod-smi-yang-01: > > > > 1. Add an extension to indicate if an index object is IMPLIED. I believe that > > with this one addition a tool could get all of the MIB information it > > needs from the converted yang module. > > > > extension implied { > > argument "index"; > > description > > "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then > > the implied statement is present in the yang module and takes as > > an argument the name of the IMPLIED index object."; > > reference > > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > > } For tables that are indexed by a human-readable string, the writer of an SMIv2 document uses the IMPLIED keyword to specify that the order in which the data should be presented is alphabetic. Otherwise, such a table would be returned in order by length of string from shortest to longest; e.g., 'fred' returned before 'barney'. RFC 6020 has a Section 7.7.1 on Ordering that introduces the ordered-by substatement. All of the data described by a converted SMIv2 document represents state data (as far as NETCONF is concerned), so by definition it is all "system ordered" and the order does not matter. A NETCONF client interacting with a multiprotocol entity must be prepared to accept the data in any order, not just the "typical" order suggested by the RFC; i.e., For example, a list of valid users would typically be sorted alphabetically, since the order in which the users appeared in the configuration would not impact the creation of those users' accounts. Still, I believe the presence or absence of the IMPLIED keyword is a detail that should not be lost when a document is converted to YANG. The absence of the IMPLIED keyword may be more meaningful than the presence of the IMPLIED keyword, but this information would not be available if the converted document discards it. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From randy_presuhn@mindspring.com Wed Nov 9 15:25:49 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCEA11E809C for ; Wed, 9 Nov 2011 15:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 9MqHKtMBSz5a for ; Wed, 9 Nov 2011 15:25:49 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id E9A7611E809A for ; Wed, 9 Nov 2011 15:25:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nEWFMeGPX8OiAAAuzrzREga82f127w4DHxb7KCnQeuC2Z7Bpg1XV0RubrVLLBwWO; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.50.109] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1ROHWb-0008Rw-TQ for netmod@ietf.org; Wed, 09 Nov 2011 18:25:46 -0500 Message-ID: <000e01cc9f37$0266a200$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201110121912.PAA25588@adminfs.snmp.com><20111109152445.GG263@elstar.local> Date: Wed, 9 Nov 2011 15:26:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f00c3eb694b9e9a470a107ae54d9084fd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.50.109 Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 23:25:49 -0000 Hi - > From: "David Spakes" > To: "Juergen Schoenwaelder" > Cc: > Sent: Wednesday, November 09, 2011 2:39 PM > Subject: Re: [netmod] ietf-yang-smiv2 ... > For tables that are indexed by a human-readable string, the writer of an > SMIv2 document uses the IMPLIED keyword to specify that the order in > which the data should be presented is alphabetic. ... But IMPLIED doesn't even accomplish that. For UTF-8 a naive sort by code point gives incorrect results for most languages. Even for pure ASCII values the order is not alphabetic by any reasonable definition: "O'Hara" would precede "Oahu" but not "O'connor". "aardvark" would follow "ZEBRA", and "Zebra" would be between "Aardvark" and "aardvark". IMPLIED doesn't even accomplish what it set out to do, so I remain to be convinced that there is any value in carrying that semantic into the NETCONF world. Randy From mbj@tail-f.com Thu Nov 10 01:14:04 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B3A21F8B1C for ; Thu, 10 Nov 2011 01:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB7VW4PP5u+q for ; Thu, 10 Nov 2011 01:14:04 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C0E1721F8B06 for ; Thu, 10 Nov 2011 01:14:03 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 42F181200100; Thu, 10 Nov 2011 10:14:01 +0100 (CET) Date: Thu, 10 Nov 2011 10:14:01 +0100 (CET) Message-Id: <20111110.101401.1354142776762462090.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <201111091745.MAA07192@adminfs.snmp.com> References: <20111109152445.GG263@elstar.local> <201111091745.MAA07192@adminfs.snmp.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 09:14:04 -0000 Hi, David Reid wrote: > > On Wed, Oct 12, 2011 at 03:12:34PM -0400, David Reid wrote: > > > I have a few suggestions for ietf-yang-smiv2.yang in > > > draft-ietf-netmod-smi-yang-01: > > > > > > 1. Add an extension to indicate if an index object is IMPLIED. I believe that > > > with this one addition a tool could get all of the MIB information it > > > needs from the converted yang module. > > > > > > extension implied { > > > argument "index"; > > > description > > > "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then > > > the implied statement is present in the yang module and takes as > > > an argument the name of the IMPLIED index object."; > > > reference > > > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > > > } > > > > I am not strictly against it but I do not really understand the use > > case for this. For data shipped over NETCONF, it does not matter > > whether the INDEX is IMPLIED or not. > > We use the same method routines to supply data to the netconf server and > the SNMP agent (and CLI and web). The current smiv2 extensions provide > every other useful piece of information from the SMIv2 module except this one. > > With this one addition, my yang compiler can read the converted module and > produce method routines that can be used by both netconf and SNMP. > Maybe this is a silly argument since I can of course use my MIB compiler to > read the original MIB document and get the same result, which is what I > normally do. But I can imagine that a netconf/yang shop might prefer to > drive all the tools from yang modules and expect SNMP to come along for free. > > Additionally, our sort order is the same for netconf and SNMP. This is not > a requirement, but it seems logical. The implied extension gives the netconf > client a hint about the ordering. I agree with David, for the same reason. We do the same - drive both the SNMP agent and NETCONF server from the same module - and currently we have a vendor-specific extension for implied. > > > 2. Modify the description clause of the oid extension to allow a more > > > user-friendly format. For example, ifEntry could be written as > > > ifTable.1 instead of 1.3.6.1.2.1.2.2.1, or perhaps just .1 as a > > > short hand notation. > > > > > > extension oid { > > > argument "value"; > > > description > > > "The oid statement takes as an argument the object identifier > > > assigned to an SMIv2 definition. The object identifier value > > > is written in dotted decimal notation. If an oid statement > > > exists for the parent object identifier, then the value may > > > be written in a short hand notation of the form > > > . or just > > > .. For example, the oid value for ifTable from > > > IF-MIB would be '1.3.6.1.2.1.2.2'. The value for ifEntry could be > > > '1.3.6.1.2.1.2.2.1', 'ifTable.1', or simply '.1'. Similarily, > > > ifDescr could be '1.3.6.1.2.1.2.2.1.2', 'ifEntry.2', or '.2'"; > > > reference > > > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > > > } > > > > This already was discussed and so far it seems Andy and me prefer to > > keep the value a full OID. If other representations are really needed, > > we should have additional aliases instead of complicating life by > > allowing translations to generate whatever they prefer. > > The main reason I wanted to add this was to make the yang module more readable. > It does not help my tools in any way. It also makes it easier for the yang > module writer. Of course, this document is aimed at automated tools doing the > translation. But I plan to use these extensions in some cases to manually > assign OIDs to objects defined in yang modules so that I can access them from > SNMP. Again I am with David. Our current vendor-specific oid statement accepts this shorthand notation, for the same reason. > > > 3. The alias extension is a useful addition. I would like to see it mentioned > > > in the body of the document much like the oid extension is mentioned. Here > > > are the suggested changes: > > > > > > Section 7: > > > > > > The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for > > > intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER > > > assignments MAY be translated into smiv2:alias statements, see the > > > YANG extension defined in Section 11. > > > > OK > > > > > Section 8.6, first paragraph: > > > > > > An OBJECT-TYPE macro invocation defining an augmenting conceptual > > > table MAY be translated into an smiv2:alias statement, see the > > > YANG extension defined in Section 11. The clauses of the macro are > > > translated as follows: > > > > > > o The SMIv2 SYNTAX clause is ignored. > > > > > > o The SMIv2 UNITS clause is ignored. > > > > > > o The SMIv2 MAX-ACCESS clause is ignored. > > > > > > o The SMIv2 STATUS clause is mapped to the YANG status statement. > > > The generation of the YANG status statement is skipped if the > > > value of the STATUS clause is current. > > > > > > o The SMIv2 DESCRIPTION clause is mapped to the YANG description > > > statement. > > > > > > o The SMIv2 REFERENCE clause is mapped to the YANG reference > > > statement. > > > > > > o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be > > > translated into an smiv2:oid statement, see the YANG extension > > > defined in Section 11. > > > > I am not sure I understand what you are trying to achieve. Is your > > idea to stick the status/description/reference statements into the > > alias statement? > > I was trying to move the information from comments to machine readable fields. > I think the text in the current document was written before we had the alias > extension, so adding comments was the only way to preserve the information. > The only parts I really need are the descriptor and oid. ifXTable would look > like this: > > smiv2:alias ifXTable { > smiv2:oid "1.3.6.1.2.1.31.1.1"; > description > "A list of interface entries. The number of entries is > given by the value of ifNumber. This table contains > additional objects for the interface table."; > } I like David's idea. I prefer a formal statement instead of comments. > > > 4. With respect to generating the smiv2 extensions, I would prefer MAY to be > > > changed to SHOULD to encourage implementations to include the extensions. > > > > I am OK with that change. This makes me wonder what the 2119 language tries to convey in this document. What does interoperability mean for this spec? The text says that it is used for: enabling read-only access to data objects defined in SMIv2 MIB modules via NETCONF With the possible exception of smiv2:oid, none of the extensions are needed in order to fulfill this goal. >From this perspective, the extensions should be OPTIONAL. OTOH, maybe our goal is actually more than just providing read-only access via NETCONF. Maybe what we really want is that David's tool should be able to use the YANG module produced by smidump, and my tool to use the YANG module produced by David's compiler. This can happen e.g. if my NETCONF client uses to read a YANG module from David's server. If this is the case, all these extensions should be REQUIRED. /martin From spakes@snmp.com Thu Nov 10 08:25:31 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CA321F8AF5 for ; Thu, 10 Nov 2011 08:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.750, 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 BJv2+1yKXtqd for ; Thu, 10 Nov 2011 08:25:30 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id E0DB521F8AF4 for ; Thu, 10 Nov 2011 08:25:29 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA18995; Thu, 10 Nov 2011 11:25:19 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA06399; Thu, 10 Nov 2011 11:25:10 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 10 Nov 2011 11:25:10 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Randy Presuhn In-Reply-To: <000e01cc9f37$0266a200$6b01a8c0@oemcomputer> Message-ID: References: <201110121912.PAA25588@adminfs.snmp.com><20111109152445.GG263@elstar.local> <000e01cc9f37$0266a200$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 16:25:31 -0000 On Wed, 9 Nov 2011, Randy Presuhn wrote: > Hi - > > > From: "David Spakes" > > To: "Juergen Schoenwaelder" > > Cc: > > Sent: Wednesday, November 09, 2011 2:39 PM > > Subject: Re: [netmod] ietf-yang-smiv2 > ... > > For tables that are indexed by a human-readable string, the writer of an > > SMIv2 document uses the IMPLIED keyword to specify that the order in > > which the data should be presented is alphabetic. ... > > But IMPLIED doesn't even accomplish that. For UTF-8 a naive sort by > code point gives incorrect results for most languages. Even for pure > ASCII values the order is not alphabetic by any reasonable definition: > > "O'Hara" would precede "Oahu" but not "O'connor". > "aardvark" would follow "ZEBRA", and "Zebra" would > be between "Aardvark" and "aardvark". IMPLIED doesn't > even accomplish what it set out to do, so I remain to be > convinced that there is any value in carrying that semantic > into the NETCONF world. > > Randy The objective is not to preserve the idiosyncrasies of SNMP in NETCONF. The objective is to preserve information from the source SMIv2 document in the converted YANG document. There is no reason to arbitrarily discard the IMPLIED information. Since we are talking about a YANG extension here, the application that handles the converted document can disregard the IMPLIED information. It has no obligation to even parse the statement. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From j.schoenwaelder@jacobs-university.de Fri Nov 11 13:20:48 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2149321F8678 for ; Fri, 11 Nov 2011 13:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.171 X-Spam-Level: X-Spam-Status: No, score=-103.171 tagged_above=-999 required=5 tests=[AWL=0.078, 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 fML6FsalYW3b for ; Fri, 11 Nov 2011 13:20:47 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 284B221F8669 for ; Fri, 11 Nov 2011 13:20:46 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2276020EBA; Fri, 11 Nov 2011 22:20:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id L0hmxcWqLukU; Fri, 11 Nov 2011 22:20:43 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2A8620D7C; Fri, 11 Nov 2011 22:20:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DC64A1BB062E; Fri, 11 Nov 2011 22:20:24 +0100 (CET) Date: Fri, 11 Nov 2011 22:20:24 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111111212024.GB11426@elstar.local> Mail-Followup-To: Martin Bjorklund , reid@snmp.com, netmod@ietf.org References: <20111109152445.GG263@elstar.local> <201111091745.MAA07192@adminfs.snmp.com> <20111110.101401.1354142776762462090.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111110.101401.1354142776762462090.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 21:20:48 -0000 On Thu, Nov 10, 2011 at 10:14:01AM +0100, Martin Bjorklund wrote: > > > > 2. Modify the description clause of the oid extension to allow a more > > > > user-friendly format. For example, ifEntry could be written as > > > > ifTable.1 instead of 1.3.6.1.2.1.2.2.1, or perhaps just .1 as a > > > > short hand notation. > > > > > > > > extension oid { > > > > argument "value"; > > > > description > > > > "The oid statement takes as an argument the object identifier > > > > assigned to an SMIv2 definition. The object identifier value > > > > is written in dotted decimal notation. If an oid statement > > > > exists for the parent object identifier, then the value may > > > > be written in a short hand notation of the form > > > > . or just > > > > .. For example, the oid value for ifTable from > > > > IF-MIB would be '1.3.6.1.2.1.2.2'. The value for ifEntry could be > > > > '1.3.6.1.2.1.2.2.1', 'ifTable.1', or simply '.1'. Similarily, > > > > ifDescr could be '1.3.6.1.2.1.2.2.1.2', 'ifEntry.2', or '.2'"; > > > > reference > > > > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > > > > } > > > > > > This already was discussed and so far it seems Andy and me prefer to > > > keep the value a full OID. If other representations are really needed, > > > we should have additional aliases instead of complicating life by > > > allowing translations to generate whatever they prefer. > > > > The main reason I wanted to add this was to make the yang module more readable. > > It does not help my tools in any way. It also makes it easier for the yang > > module writer. Of course, this document is aimed at automated tools doing the > > translation. But I plan to use these extensions in some cases to manually > > assign OIDs to objects defined in yang modules so that I can access them from > > SNMP. > > Again I am with David. Our current vendor-specific oid statement > accepts this shorthand notation, for the same reason. Are we producing extensions for machine generated translations or for stuff written by humans? For machine generation and processing, I think a simple predicatable format is to be preferred. > > > > 3. The alias extension is a useful addition. I would like to see it mentioned > > > > in the body of the document much like the oid extension is mentioned. Here > > > > are the suggested changes: > > > > > > > > Section 7: > > > > > > > > The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for > > > > intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER > > > > assignments MAY be translated into smiv2:alias statements, see the > > > > YANG extension defined in Section 11. > > > > > > OK > > > > > > > Section 8.6, first paragraph: > > > > > > > > An OBJECT-TYPE macro invocation defining an augmenting conceptual > > > > table MAY be translated into an smiv2:alias statement, see the > > > > YANG extension defined in Section 11. The clauses of the macro are > > > > translated as follows: > > > > > > > > o The SMIv2 SYNTAX clause is ignored. > > > > > > > > o The SMIv2 UNITS clause is ignored. > > > > > > > > o The SMIv2 MAX-ACCESS clause is ignored. > > > > > > > > o The SMIv2 STATUS clause is mapped to the YANG status statement. > > > > The generation of the YANG status statement is skipped if the > > > > value of the STATUS clause is current. > > > > > > > > o The SMIv2 DESCRIPTION clause is mapped to the YANG description > > > > statement. > > > > > > > > o The SMIv2 REFERENCE clause is mapped to the YANG reference > > > > statement. > > > > > > > > o The value of the SMIv2 OBJECT-TYPE macro invocation MAY be > > > > translated into an smiv2:oid statement, see the YANG extension > > > > defined in Section 11. > > > > > > I am not sure I understand what you are trying to achieve. Is your > > > idea to stick the status/description/reference statements into the > > > alias statement? > > > > I was trying to move the information from comments to machine readable fields. > > I think the text in the current document was written before we had the alias > > extension, so adding comments was the only way to preserve the information. > > The only parts I really need are the descriptor and oid. ifXTable would look > > like this: > > > > smiv2:alias ifXTable { > > smiv2:oid "1.3.6.1.2.1.31.1.1"; > > description > > "A list of interface entries. The number of entries is > > given by the value of ifNumber. This table contains > > additional objects for the interface table."; > > } > > I like David's idea. I prefer a formal statement instead of comments. So if we do this, would if be valid to repeat descriptions etc. for other mappable constructs as well? > > > > 4. With respect to generating the smiv2 extensions, I would prefer MAY to be > > > > changed to SHOULD to encourage implementations to include the extensions. > > > > > > I am OK with that change. > > This makes me wonder what the 2119 language tries to convey in this > document. What does interoperability mean for this spec? The text > says that it is used for: > > enabling read-only access to data objects defined in SMIv2 MIB > modules via NETCONF > > With the possible exception of smiv2:oid, none of the extensions are > needed in order to fulfill this goal. Even the smiv2:oid is not needed for this. > From this perspective, the extensions should be OPTIONAL. > > OTOH, maybe our goal is actually more than just providing read-only > access via NETCONF. Maybe what we really want is that David's tool > should be able to use the YANG module produced by smidump, and my tool > to use the YANG module produced by David's compiler. This can happen > e.g. if my NETCONF client uses to read a YANG module from > David's server. > > If this is the case, all these extensions should be REQUIRED. What do _you_ think is the goal? Implementation wise, all this does not really matter since generating the smiv2:* statements is not a big deal and ignoring the smiv2:* statements in a YANG document is also easy. And both David's and my implementation have the code, the question is whether it is permanently on or not. Perhaps you are right, we should either turn it permanently on or really treat it as an optional feature. I personally do not care much. /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 Nov 11 13:28:18 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6978021F8A7E for ; Fri, 11 Nov 2011 13:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.172 X-Spam-Level: X-Spam-Status: No, score=-103.172 tagged_above=-999 required=5 tests=[AWL=0.077, 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 fzUR74nW9zcJ for ; Fri, 11 Nov 2011 13:28:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 696A421F8A70 for ; Fri, 11 Nov 2011 13:28:17 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BED6320EBA; Fri, 11 Nov 2011 22:28:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rwC1ShpnAszc; Fri, 11 Nov 2011 22:28:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56EF020EB2; Fri, 11 Nov 2011 22:28:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 718711BB06A7; Fri, 11 Nov 2011 22:27:58 +0100 (CET) Date: Fri, 11 Nov 2011 22:27:58 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20111111212758.GC11426@elstar.local> Mail-Followup-To: David Spakes , David Reid , netmod@ietf.org References: <201110132119.RAA06352@adminfs.snmp.com> <20111109160424.GA1441@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] mib to yang conversion: type mapping table 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, 11 Nov 2011 21:28:18 -0000 On Wed, Nov 09, 2011 at 04:51:57PM -0500, David Spakes wrote: > The TruthValue TC and YANG boolean represent the same information, > even if the enumerated values are different. The document should > map TruthValue to boolean. A software entity that handles both > SNMP and NETCONF data should be prepared to transform between the > SNMP-centric [1,2] and NETCONF-centric [0,1] enumerations. I believe > this same line of reasoning should prevail even when the semantic > equivalency is not as clear-cut. YANG does not assign any numeric representation for true and false as far as I can tell. > > > Side note: CHARACTER-MIB (rfc1658) uses DisplayString without > > > importing it. I've seen other MIBs do that with DisplayString. > > > I added a hack to my tool to handle that case. I don't think the > > > document needs to account for broken MIBs, but I thought I'd > > > point this one out since it is in a standard MIB. > > > > But at the end, these are broken SMIv2 modules. If you need to > > translate them, simply fix the module before running the translator. > > The IETF MIB modules that have such problems and are shipped with > > smidump have been fixed manually. > > > I observed that DisplayString existed before SMIv2. It was defined > in RFC 1158 and later in RFC 1213. RFC 1213 was a Full Standard at the > time RFC 1658 was published. > > RFC 1443 (predecessor to the current SNMPv2-TC, RFC 2579) was published > as Proprosed Standard in April, 1993, a little more than a year before > RFC 1658 was published in July, 1994. That suggests that RFC 1658 should > have been changed to import from RFC 1443 before it was published. > However, the author may have reasoned that the Full Standard definition > of DisplayString in RFC 1213 trumped the then-Proposed Standard TC. The issue is that RFC 1658 uses DisplayString without importing it and hence RFC 1658 is broken. It does not matter whether other documents had a DisplayString around that time or not. /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 Nov 11 14:31:53 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B8021F854D for ; Fri, 11 Nov 2011 14:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.093, 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 u-F80+xEie8t for ; Fri, 11 Nov 2011 14:31:53 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDF821F8546 for ; Fri, 11 Nov 2011 14:31:52 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 68B2C1200CF2; Fri, 11 Nov 2011 23:31:49 +0100 (CET) Date: Fri, 11 Nov 2011 23:31:47 +0100 (CET) Message-Id: <20111111.233147.264446585.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20111111212024.GB11426@elstar.local> References: <201111091745.MAA07192@adminfs.snmp.com> <20111110.101401.1354142776762462090.mbj@tail-f.com> <20111111212024.GB11426@elstar.local> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 22:31:53 -0000 Juergen Schoenwaelder wrote: > On Thu, Nov 10, 2011 at 10:14:01AM +0100, Martin Bjorklund wrote: > > This makes me wonder what the 2119 language tries to convey in this > > document. What does interoperability mean for this spec? The text > > says that it is used for: > > > > enabling read-only access to data objects defined in SMIv2 MIB > > modules via NETCONF > > > > With the possible exception of smiv2:oid, none of the extensions are > > needed in order to fulfill this goal. > > Even the smiv2:oid is not needed for this. > > > From this perspective, the extensions should be OPTIONAL. > > > > OTOH, maybe our goal is actually more than just providing read-only > > access via NETCONF. Maybe what we really want is that David's tool > > should be able to use the YANG module produced by smidump, and my tool > > to use the YANG module produced by David's compiler. This can happen > > e.g. if my NETCONF client uses to read a YANG module from > > David's server. > > > > If this is the case, all these extensions should be REQUIRED. > > What do _you_ think is the goal? Here's a use case. Suppose you want to implement a proxy that provides this read-only access to SNMP data over NETCONF, i.e., a NETCONF server that speaks SNMP southbound to provide this data (which happens to be close to what I am working on right now). In this case, the "oid" statement is necessary, as is "implied". The others ("display-hint", "defval" etc), are not really important for this use case. So, I prefer the extensions to be REQUIRED. If get a module converted by some tool that is compliant with this spec, I can use it in my proxy. If these extensions are OPTIONAL, I cannot work with all compliant tools. Since non-important extensions are trivial to ignore, it is not a problem for YANG tools to always get them. /martin From spakes@snmp.com Fri Nov 11 14:41:59 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE9221F8450 for ; Fri, 11 Nov 2011 14:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 3Z7El2mTelcC for ; Fri, 11 Nov 2011 14:41:59 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8A66721F844C for ; Fri, 11 Nov 2011 14:41:58 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA18683; Fri, 11 Nov 2011 17:41:52 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA06692; Fri, 11 Nov 2011 17:41:52 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 11 Nov 2011 17:41:51 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20111111.233147.264446585.mbj@tail-f.com> Message-ID: References: <201111091745.MAA07192@adminfs.snmp.com> <20111110.101401.1354142776762462090.mbj@tail-f.com> <20111111212024.GB11426@elstar.local> <20111111.233147.264446585.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 22:41:59 -0000 On Fri, 11 Nov 2011, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Nov 10, 2011 at 10:14:01AM +0100, Martin Bjorklund wrote: > > > This makes me wonder what the 2119 language tries to convey in this > > > document. What does interoperability mean for this spec? The text > > > says that it is used for: > > > > > > enabling read-only access to data objects defined in SMIv2 MIB > > > modules via NETCONF > > > > > > With the possible exception of smiv2:oid, none of the extensions are > > > needed in order to fulfill this goal. > > > > Even the smiv2:oid is not needed for this. > > > > > From this perspective, the extensions should be OPTIONAL. > > > > > > OTOH, maybe our goal is actually more than just providing read-only > > > access via NETCONF. Maybe what we really want is that David's tool > > > should be able to use the YANG module produced by smidump, and my tool > > > to use the YANG module produced by David's compiler. This can happen > > > e.g. if my NETCONF client uses to read a YANG module from > > > David's server. > > > > > > If this is the case, all these extensions should be REQUIRED. > > > > What do _you_ think is the goal? > > Here's a use case. Suppose you want to implement a proxy that > provides this read-only access to SNMP data over NETCONF, i.e., a > NETCONF server that speaks SNMP southbound to provide this data (which > happens to be close to what I am working on right now). In this case, > the "oid" statement is necessary, as is "implied". The others > ("display-hint", "defval" etc), are not really important for this use > case. > > So, I prefer the extensions to be REQUIRED. If get a module converted > by some tool that is compliant with this spec, I can use it in my > proxy. If these extensions are OPTIONAL, I cannot work with all > compliant tools. > > Since non-important extensions are trivial to ignore, it is not a > problem for YANG tools to always get them. I am also working on multiprotocol entities that will support both NETCONF and SNMP (proxy being one example). I agree with Martin. I prefer that the extensions be REQUIRED. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From lhotka@cesnet.cz Sun Nov 13 20:00:47 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3049F11E809A for ; Sun, 13 Nov 2011 20:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 3TO1njrYCCSX for ; Sun, 13 Nov 2011 20:00:37 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id B8A5511E8095 for ; Sun, 13 Nov 2011 20:00:36 -0800 (PST) Received: from dhcp-37d6.meeting.ietf.org (dhcp-37d6.meeting.ietf.org [130.129.55.214]) by office2.cesnet.cz (Postfix) with ESMTPSA id D6FF62CDE058 for ; Mon, 14 Nov 2011 05:00:33 +0100 (CET) From: Ladislav Lhotka Content-Type: multipart/signed; boundary="Apple-Mail=_93E748C7-DA3D-43B5-ADEA-C4527819612B"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 14 Nov 2011 12:00:28 +0800 Message-Id: <67570C50-DA5C-442B-A031-6AFF5F1730A3@cesnet.cz> To: netmod@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [netmod] crypt-hash 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, 14 Nov 2011 04:00:47 -0000 --Apple-Mail=_93E748C7-DA3D-43B5-ADEA-C4527819612B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, in the ietf-system module, the regex pattern used in the "crypt-hash" = typedef is incorrect. At least, parentheses must be used to enclose the = alternative values for hash function id: $0$.*|$(1|5|6)$[a-zA-Z0-9./]{2,16}$.* The hash value is also base-64 encoded, right? So the regex pattern = should only allow "[a-zA-Z0-9./]" instead of ".". Can the hash value be = empty? If not, the asterisks should be replaced with "+". Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_93E748C7-DA3D-43B5-ADEA-C4527819612B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE0MDQwMDI5WjAjBgkqhkiG9w0BCQQxFgQU9Qh2MpXw4ToOOv5W+1P2CcZT8MkwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQAlyXjOJ8jQG/qAr4/xrcZfZRY3 sUc7dv+/wDMMh12b4KwWX0PF5L4Ff5I80QqR5GTK66DB0gD4b+AEFVIOtohoUfNiVab21cncSuDb iJLkmrrQSU/K64ldll2S2OPq0RK+O2umzfmXhib2sBCFMOEWT72ehiUXZ6OlVJLz0LjcQJUZGUuE LqCC9heyXAVzj6UD04yVzKByyVZ90kXboB0JYPoKBkDYXjknV0Ie+sClWLbM8PT6e68yODFQm8lX ltV6MCGLa3g6APFk3KGuh/GyD3LfnCOeMPnq9Wm59VtzICsER5KogSyyIXuSq4CR2ljIMuIjbeCD pEc6/67XraiEAAAAAAAA --Apple-Mail=_93E748C7-DA3D-43B5-ADEA-C4527819612B-- From j.schoenwaelder@jacobs-university.de Sun Nov 13 20:15:08 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DB011E81D3 for ; Sun, 13 Nov 2011 20:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.174 X-Spam-Level: X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 FyebGiRbYaHJ for ; Sun, 13 Nov 2011 20:15:08 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A274811E81C5 for ; Sun, 13 Nov 2011 20:15:07 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9515020DB9; Mon, 14 Nov 2011 05:15:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yGrf9cstztPe; Mon, 14 Nov 2011 05:15:04 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6133720DAD; Mon, 14 Nov 2011 05:15:04 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 09B9D1BB2B7E; Mon, 14 Nov 2011 05:14:46 +0100 (CET) Date: Mon, 14 Nov 2011 05:14:46 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111114041446.GA15961@elstar.local> Mail-Followup-To: Martin Bjorklund , david.kessens@nsn.com, netmod@ietf.org References: <20110714164507.GG30209@nsn.com> <20110724.135622.441773029.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110724.135622.441773029.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Last Call: draft-ietf-netmod-smi-yang-01 (20110704) 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, 14 Nov 2011 04:15:09 -0000 On Sun, Jul 24, 2011 at 01:56:22PM -0400, Martin Bjorklund wrote: > Hi, > > I have reviewed this document, and I think it is ready for > publication, with some (mostly minor) edits: > > > Section 3 > > When you read this document from the beginning, it is not clear what > this section is for. Later in the document there are backwards > references to it, so it gets clear. I suggest to add a sentence in > the beginning of section 3, which says something like: "This section > describes an algorithm to generate unique module prefixes, to be > used in the import statements." > fixed > Table 2 > > Says "YANG / SMIv2 Module". Should be only YANG module? > > If so, also > > s/well known SMIv2 and YANG modules/well known YANG modules/g > fixed > Section 3 > > This section talks about "module name", "SMIv2 module name". I > think it should only mention "YANG module name". Now, since the > YANG module name is later defined to be the SMIv2 module name, it > doesn't really matter for the end result, but it is clearer if the > alg. describes how a prefix (which is a YANG construct) is generated > from the YANG module name. > > > s/by tokenizing an SMIv2 module name/ > by tokenizing the YANG module name/ > > s/The tokens derived from a module name/ > The tokens derived from the module name/ > > s/shortest sequence of token/ > shortest sequence of tokens/ > > s/at least two token/at least two tokens/ fixed > Section 4 > > s/constant prefix, which followed/ > constant prefix followed/ fixed > Table 3 > > This table explicitly lists some SNMPv2-SMI symbols, and then > there's a catch all clause that all SNMPv2-SMI symbols are ignored > during import. I suggest the explicit symbols are removed. fixed by adopting David's rewrite of the import algorithm > Table 3 > > This table and following text says that all symbols in > SNMPv2-CONF are translated by translation rules. But there are no > translation rules for the macros in SNMPv2-CONF. I suggest you add > a section that describes how these macros are handled - i.e., that > they are not translated at all. fixed by adopting David's rewrite of the import algorithm > Table 3 > > This table lists 'snmpTraps' from SNMPv2-MIB. But why is that one > special? Suppose someone imported 'snmpMIBObjects' from > SNMPv2-MIB. Why is this different? fixed by adopting David's rewrite of the import algorithm > Section 4 > > "according to the type mapping table" > > Add a reference "according to the type mapping table (see table 1)" fixed > Section 4 > > "This requires to consider all the types used in the translation > unit" > > What is a translation unit? I changed the working to avoid this term. > Section 4.1 > > "The translation of the IF-MIB [RFC2863] leads to the YANG module > frame" > > What is a module frame? OK, I will try to be more explicit to avoid new undefined terms. > Section 5.1 > > "Furthermore, SMIv2 modules generated from SMIv1 modules may miss an > invocation of the MODULE-IDENTITY macro as well" > > So what will the top-level container be in this case? > > Since the concept of a top-level container is used later in the > translation, this needs to be specified. I have created an open issue for this. The likely resolution is that we use the SMIv2 module name as the top-level container. > Section 7 > > "OBJECT IDENTIFIER assignments are not translated into YANG > statements" > > Isn't this what the new smiv2:alias statement was supposed to be > used for? Will change if we make smiv2 mandatory to generate. Open issue for now. > Section 8.1 > > "All leaf statements for scalar objects are created in the top-level > container" > > OK -- but I just want to point out that this leads to a model where > you need to be careful with using filters if you don't want to get > all data for a module. yep - created an open issue for it. > Section 8.4 > > container ifTable { > config false; > > where did the config false statement come from? > > Ok, it's not wrong, but unnecessary. It's perfectly fine if your > implementatiomn generates it, but it should be removed from this > example, otherwise a reader might think he missed something. Copied from smidump - removed. > Section 8.6 > > I think the name, description, reference and value of the augmenting > OBJECT-TYPE should not be captured in comments, but in a smiv2:alias > statement. For example: > > OLD: > > /* > * ifXTable (1.3.6.1.2.1.31.1.1) > * > * A list of interface entries. The number of entries is > * given by the value of ifNumber. This table contains > * additional objects for the interface table. > */ > > NEW: > > smiv2:alias ifXTable { > smiv2:oid "1.3.6.1.2.1.31.1.1"; > description > "A list of interface entries. The number of entries is > given by the value of ifNumber. This table contains > additional objects for the interface table."; > } Will likely be done, David asked for this as well. > s/""/"/g fixed > Section 9. > > The SMIv2 uses invocations of the OBJECT-IDENTITY macro to define > information about an OBJECT IDENTIFIER assignment. Invocations of > the OBJECT-IDENTITY macro MUST be translated into YANG identity > statements as detailed below. > > Ok, but in this case, from the MALLOC-MIB, this will be somewhat > odd... > > madcapConfig OBJECT-IDENTITY > STATUS current > DESCRIPTION > "Group of objects that count various MADCAP events." > ::= { madcap 1 } I do not think something can be done about this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Nov 14 00:10:14 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C7721F8B81 for ; Mon, 14 Nov 2011 00:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.175 X-Spam-Level: X-Spam-Status: No, score=-103.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 zB3mCx1eH5Tm for ; Mon, 14 Nov 2011 00:10:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D31C221F8B50 for ; Mon, 14 Nov 2011 00:10:11 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2A3F20C5D; Mon, 14 Nov 2011 09:10:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dCGdqrdhs3Ej; Mon, 14 Nov 2011 09:10:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FD0420C54; Mon, 14 Nov 2011 09:10:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A88911BB33F7; Mon, 14 Nov 2011 09:09:50 +0100 (CET) Date: Mon, 14 Nov 2011 09:09:50 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111114080950.GB16717@elstar.local> Mail-Followup-To: David Reid , NETMOD Working Group References: <4E2EDA14.9090605@andybierman.com> <201110112051.QAA12699@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201110112051.QAA12699@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETMOD Working Group Subject: Re: [netmod] comments on draft-ietf-netmod-smi-01 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 08:10:14 -0000 On Tue, Oct 11, 2011 at 04:51:12PM -0400, David Reid wrote: > > Andy Bierman wrote: > > > > sec 2: > > > > Implementations are encouraged to provide > > options to handle situations where DISPLAY-HINTs are added during a > > revision of a module and backwards compatibility must be preserved. > > > > What are the options they are encouraged to provide? > > I agree that this needs more work. I don't have a good solution at this point. > The idea was to express that implementation should have implementation specific options that can resolve this situation if a DISPLAY-HINT is added during a revision. I know, its weak - but better than pretending this problem does not exist. > > > > sec 3: > > > > The order modules are processed by a translator will affect the > > prefix algorithm, wrt/ detecting conflicts. It seems this algorithm is > > ad-hoc, and there is no way to determine if the shortest unique > > prefix is really found. IMO it would be better to allow a translator > > to use the entire converted module name to be sure the prefix is unique. > > I agree with Andy about using the entire name for the prefix. I think the full > name makes the document more clear to the reader. In most cases, the algorithm > either does not shorten the name or only shortens it slightly. Not using the > prefix algorithm can make for some long path statements in a few cases. But I > still think the clarity of the full name outweighs the brevity of the shortened > names. There are a few cases in standard MIBs where using the prefix > algorithm results in different modules using the same prefix to refer to > different modules or different prefixes to refer to the same module. That's > perfectly legal yang, but I find it a bit confusing. The MIBs defined in > RFC 5324 provide good examples that could support either side of this debate. > That is, the prefix algorithm results in significantly shorter names, but > could be confusing. The reason for having prefixes is to have something shorter than the full module name. Leafref paths really really get ugly if you have long module names as a prefix (for my level of uglyness I am used to ;-). Anyway, I have marked this as an open issue now. > > sec. 4: > > > > SMIv2 modules are mapped to corresponding YANG modules. The YANG > > module name MUST be the same as the SMIv2 module name. > > > > Do you mean the converted module name, according to the algorithm in sec. 3? > > No. I see further down this is not the case. I suggest a new section > > called Mapping of the Module Name to make this more clear. > > I didn't think this was unclear. Would it be more clear if the module name > translation and imports translation were in different sections instead of > the same? I do not see the problem. Section4 starts with: SMIv2 modules are mapped to corresponding YANG modules. The YANG module name MUST be the same as the SMIv2 module name. This is pretty clear I think. > > sec 6.1: > > > > SMIv2 INTEGER enumerations and SMIv2 BITS are mapped to YANG enum > > / value and bit / position statements. > > > > Are these forward slashes typos? (also sec. 8.1) > > I don't think they are typos, but I also found it confusing when I first > read it. Would this be more clear: > > SMIv2 INTEGER enumerations are mapped to YANG enum/value statements. > SMIv2 BITS are mapped to YANG bit/position statements. fixed > > sec. 8.3: > > > > YANG leaf statements of type leafref pointing to the > > referenced definition are created. > > > > then later in 8.5: > > > > leaf ifIndex { > > type leafref { > > path "/if-mib:ifMIB/if-mib:ifTable" + > > "/if-mib:ifEntry/if-mib:ifIndex"; > > } > > description > > "[Automatically generated leaf for a foreign index.]"; > > } > > > > The text does not mention this automatic description-stmt. > > Should the text say this string SHOULD (or MAY) be used? > > I would suggest removing description from the example. I have removed the description statements. Perhaps they should have been comments. > Also, if I understand the rules correctly, the path statement in this and > several other examples is wrong. I thought the ifMIB container went around > the scalars but not the tables. > > I actually don't like putting a container around the scalars for a couple of > reasons. The first reason is that it gets things out of order from the MIB. > In a lot of MIBs, there are several groups which each have several scalars > and one or more tables that logically go together. IF-MIB and DISMAN-EVENT-MIB > are two good examples. Putting all the scalars together under one container > looses that logical ordering. A second reason that an SMIv1 module converted > to SMIv2 might have the same module name but a MODULE-IDENTITY added in the > SMIv2 version. HOST-RESOURCES-MIB is a good example (rfcs 1514 and 2790). The > version without the MODULE-IDENTITY would produce a different path that the > version with the MODULE-IDENTITY. Section 5.1 mentions the possibility of a > module not having a MODULE-IDENTITY, but does not suggest what to do about > the top level container if MODULE-IDENTITY is missing. > We already have an open issue since the MODULE-IDENTITY descriptor is not always available. The obvious solution is to use the module name instead for the toplevel container. Concerning the scalars, there is an open issues because putting them next to the tables makes scoped retrieval a bit complicated. /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 Nov 14 00:23:51 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C1B11E80E3 for ; Mon, 14 Nov 2011 00:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZOUL3RVldew for ; Mon, 14 Nov 2011 00:23:51 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9E36311E80B7 for ; Mon, 14 Nov 2011 00:23:50 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 17E8912008E8 for ; Mon, 14 Nov 2011 09:23:49 +0100 (CET) Date: Mon, 14 Nov 2011 09:23:48 +0100 (CET) Message-Id: <20111114.092348.1957965659644075140.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20111110.101401.1354142776762462090.mbj@tail-f.com> References: <20111109152445.GG263@elstar.local> <201111091745.MAA07192@adminfs.snmp.com> <20111110.101401.1354142776762462090.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: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 08:23:51 -0000 Hi, Martin Bjorklund wrote: > This makes me wonder what the 2119 language tries to convey in this > document. What does interoperability mean for this spec? The text > says that it is used for: > > enabling read-only access to data objects defined in SMIv2 MIB > modules via NETCONF The document says that all nodes MUST be config false, which is natural since the interoperability goal is read-only access. But I think we should allow implementations to mark nodes as config true, in an implementation dependent manner. This would not affect our read-only interoperability goal. We already know from this ML that some vendors (including myself) will provide config true access to parts of the MIBs. (We're using a bunch of directives to the compiler to control which parts). As the document is written today, the output from my tool is non-compliant, but I do not think this is necessary. /martin From mbj@tail-f.com Mon Nov 14 00:36:03 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CEA21F8DB0 for ; Mon, 14 Nov 2011 00:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JC8nZj4qquR for ; Mon, 14 Nov 2011 00:36:03 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0E19F21F8DAF for ; Mon, 14 Nov 2011 00:36:02 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 42C5B12008E8 for ; Mon, 14 Nov 2011 09:36:02 +0100 (CET) Date: Mon, 14 Nov 2011 09:36:01 +0100 (CET) Message-Id: <20111114.093601.320467224258500807.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] ipv6 config parameters 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, 14 Nov 2011 08:36:03 -0000 Hi, Here are two issues for the draft-ietf-netmod-ip-cfg document. RFC 4862 (IPv6 Stateless Address Autoconfiguration) states: A node MUST allow the following autoconfiguration-related variable to be configured by system management for each multicast-capable interface: DupAddrDetectTransmits Should we add this leaf to our data model? RFC 4861 (Neighbor Discovery in IPv6) states: A router MUST allow for the following conceptual variables to be configured by system management. Should we add these variables to our data model, conditional on an if-feature? They are present in the IP-MIB. /martin From lhotka@cesnet.cz Mon Nov 14 01:04:52 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5E521F8F24 for ; Mon, 14 Nov 2011 01:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 YIRmyXakIgP3 for ; Mon, 14 Nov 2011 01:04:20 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id B276A21F8F1C for ; Mon, 14 Nov 2011 01:04:15 -0800 (PST) Received: from dhcp-9227.meeting.ietf.org (dhcp-9227.meeting.ietf.org [130.129.10.39]) by office2.cesnet.cz (Postfix) with ESMTPSA id 55D952CDE058; Mon, 14 Nov 2011 10:04:08 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_B7ABDD63-2A2C-4D1C-931B-45FCC3188B0D"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111114.093601.320467224258500807.mbj@tail-f.com> Date: Mon, 14 Nov 2011 17:04:03 +0800 Message-Id: References: <20111114.093601.320467224258500807.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 config parameters 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, 14 Nov 2011 09:05:06 -0000 --Apple-Mail=_B7ABDD63-2A2C-4D1C-931B-45FCC3188B0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 14, 2011, at 4:36 PM, Martin Bjorklund wrote: > Hi, >=20 > Here are two issues for the draft-ietf-netmod-ip-cfg document. >=20 >=20 > RFC 4862 (IPv6 Stateless Address Autoconfiguration) states: >=20 > A node MUST allow the following autoconfiguration-related variable = to > be configured by system management for each multicast-capable > interface: >=20 > DupAddrDetectTransmits >=20 > Should we add this leaf to our data model? I'd say yes as every node is required to implement it. >=20 >=20 > RFC 4861 (Neighbor Discovery in IPv6) states: >=20 > A router MUST allow for the following conceptual variables to be > configured by system management. >=20 > >=20 > Should we add these variables to our data model, conditional on an > if-feature? They are present in the IP-MIB. IMO this could go to the ietf-ipv6-unicast-routing module. It doesn't = exist yet, my idea was that am IPv6-related WG (6man) would develop it. = These variables could augment the /rt:routing/rt:router container. Lada >=20 >=20 > /martin >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_B7ABDD63-2A2C-4D1C-931B-45FCC3188B0D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE0MDkwNDA0WjAjBgkqhkiG9w0BCQQxFgQUnrXYM8x1xcR7OMQQGO8Ktc93RV8wXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQAslUHbbj6wYjE9Kvwmzrb6k62J /oKRqQKZP6yiL0o0Rd7V7MQ/RbA8zCWW5LkRGeTMIcLVOdZnehOpitA279yqnQp/WsdoErSNLe0f bNrNB+i8b8vcgQadwJc2CEBDWGAnyqGGkx270OPaOZnwA4p88UReRAQk9TbeZZUWw33AzuQMwDqB rVv7Ex8csPf/IAgU5DBsbDwEB8XZ2KYArcCBd3lbPVndi3ulgFYtbYCaWZ++HWEH34BnCE9+YxHQ qsKhRVDr8NiR4EQXaOq3a+TFhYLttwFKKH0RS53pqUTzjdqTVYjRx4tQshXa/vlk+CDZkouoVD5a E3+zISN+vwX6AAAAAAAA --Apple-Mail=_B7ABDD63-2A2C-4D1C-931B-45FCC3188B0D-- From j.schoenwaelder@jacobs-university.de Mon Nov 14 01:17:44 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FB321F84D8 for ; Mon, 14 Nov 2011 01:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.176 X-Spam-Level: X-Spam-Status: No, score=-103.176 tagged_above=-999 required=5 tests=[AWL=0.073, 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 g4y-OShAn82r for ; Mon, 14 Nov 2011 01:17:39 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8E16021F8F54 for ; Mon, 14 Nov 2011 01:16:23 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C465720CF5; Mon, 14 Nov 2011 10:14:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6TobVcWTJ_cp; Mon, 14 Nov 2011 10:14:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 76A3120CF3; Mon, 14 Nov 2011 10:14:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3A1A51BB3587; Mon, 14 Nov 2011 10:14:34 +0100 (CET) Date: Mon, 14 Nov 2011 10:14:34 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111114091433.GA17181@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20111114.093601.320467224258500807.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114.093601.320467224258500807.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 config parameters 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, 14 Nov 2011 09:17:44 -0000 On Mon, Nov 14, 2011 at 09:36:01AM +0100, Martin Bjorklund wrote: > Hi, > > Here are two issues for the draft-ietf-netmod-ip-cfg document. > > > RFC 4862 (IPv6 Stateless Address Autoconfiguration) states: > > A node MUST allow the following autoconfiguration-related variable to > be configured by system management for each multicast-capable > interface: > > DupAddrDetectTransmits > > Should we add this leaf to our data model? If RFC 4862 says so... > RFC 4861 (Neighbor Discovery in IPv6) states: > > A router MUST allow for the following conceptual variables to be > configured by system management. > > > > Should we add these variables to our data model, conditional on an > if-feature? They are present in the IP-MIB. The question here is what is in scope of this work and what is out of scope. Are we limiting this data model to the configuration of interfaces or do we include things happening on routers, like the configuration of routing advertisements. In fact, if we take a broad definition of the scope, we will have to work through draft-ietf-6man-node-req-bis-11.txt and all the mandatory stuff it references. And also 4941 comes into my mind and there is ongoing work on source address selection and even discussion today how to handle situations where you get potentially conflicting information via RAs and DHCP. Since it is unlikely that we will be successful covering everything configurable in the IP layer, we should in my view have a plan how to put things into manageable pieces. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Nov 14 01:24:30 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB7A21F8B92 for ; Mon, 14 Nov 2011 01:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.178 X-Spam-Level: X-Spam-Status: No, score=-103.178 tagged_above=-999 required=5 tests=[AWL=0.071, 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 WMSJ6vn7GmMZ for ; Mon, 14 Nov 2011 01:24:27 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D798921F8E24 for ; Mon, 14 Nov 2011 01:23:48 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D33A20CED; Mon, 14 Nov 2011 10:22:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XHgT2T1RQy5o; Mon, 14 Nov 2011 10:22:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EF8120C85; Mon, 14 Nov 2011 10:22:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 59C411BB370B; Mon, 14 Nov 2011 10:22:28 +0100 (CET) Date: Mon, 14 Nov 2011 10:22:28 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111114092228.GB17181@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20111109152445.GG263@elstar.local> <201111091745.MAA07192@adminfs.snmp.com> <20111110.101401.1354142776762462090.mbj@tail-f.com> <20111114.092348.1957965659644075140.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114.092348.1957965659644075140.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 09:24:30 -0000 On Mon, Nov 14, 2011 at 09:23:48AM +0100, Martin Bjorklund wrote: > Hi, > > Martin Bjorklund wrote: > > This makes me wonder what the 2119 language tries to convey in this > > document. What does interoperability mean for this spec? The text > > says that it is used for: > > > > enabling read-only access to data objects defined in SMIv2 MIB > > modules via NETCONF > > The document says that all nodes MUST be config false, which is > natural since the interoperability goal is read-only access. But I > think we should allow implementations to mark nodes as config true, in > an implementation dependent manner. This would not affect our > read-only interoperability goal. > > We already know from this ML that some vendors (including myself) will > provide config true access to parts of the MIBs. (We're using a bunch > of directives to the compiler to control which parts). As the > document is written today, the output from my tool is non-compliant, > but I do not think this is necessary. If my tool generates config false but yours does config true, will a YANG manager not be potentially confused? Both will have the same revision timestamp. /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 Nov 14 01:26:53 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504B721F8493 for ; Mon, 14 Nov 2011 01:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdD6QqEyDzzn for ; Mon, 14 Nov 2011 01:26:52 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8C15F21F8F55 for ; Mon, 14 Nov 2011 01:14:00 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B9C3D12008E8; Mon, 14 Nov 2011 10:13:10 +0100 (CET) Date: Mon, 14 Nov 2011 10:13:09 +0100 (CET) Message-Id: <20111114.101309.1774365382168663655.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: References: <20111114.093601.320467224258500807.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] ipv6 config parameters 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, 14 Nov 2011 09:26:53 -0000 Ladislav Lhotka wrote: > > On Nov 14, 2011, at 4:36 PM, Martin Bjorklund wrote: > > RFC 4861 (Neighbor Discovery in IPv6) states: > > > > A router MUST allow for the following conceptual variables to be > > configured by system management. > > > > > > > > Should we add these variables to our data model, conditional on an > > if-feature? They are present in the IP-MIB. > > IMO this could go to the ietf-ipv6-unicast-routing module. It doesn't > exist yet, my idea was that am IPv6-related WG (6man) would develop > it. These variables could augment the /rt:routing/rt:router container. But they are specified in 4861 to be per interface. Also, is v6-unicast really the right place to put it? I think it makes sense to put them in this document, but I would very much welcome input from 6man. /martin From j.schoenwaelder@jacobs-university.de Mon Nov 14 01:33:03 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B864B21F8EF4 for ; Mon, 14 Nov 2011 01:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.179 X-Spam-Level: X-Spam-Status: No, score=-103.179 tagged_above=-999 required=5 tests=[AWL=0.070, 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 AU3--J7wlD-L for ; Mon, 14 Nov 2011 01:32:59 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8F95421F8EEF for ; Mon, 14 Nov 2011 01:32:58 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B964A20CC0; Mon, 14 Nov 2011 10:32:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nnjOot9TS3l7; Mon, 14 Nov 2011 10:32:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7611C20CB0; Mon, 14 Nov 2011 10:32:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AE28D1BB37FC; Mon, 14 Nov 2011 10:32:38 +0100 (CET) Date: Mon, 14 Nov 2011 10:32:38 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111114093238.GA17498@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@cesnet.cz, netmod@ietf.org References: <20111114.093601.320467224258500807.mbj@tail-f.com> <20111114.101309.1774365382168663655.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114.101309.1774365382168663655.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 config parameters 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, 14 Nov 2011 09:33:03 -0000 On Mon, Nov 14, 2011 at 10:13:09AM +0100, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > On Nov 14, 2011, at 4:36 PM, Martin Bjorklund wrote: > > > RFC 4861 (Neighbor Discovery in IPv6) states: > > > > > > A router MUST allow for the following conceptual variables to be > > > configured by system management. > > > > > > > > > > > > Should we add these variables to our data model, conditional on an > > > if-feature? They are present in the IP-MIB. > > > > IMO this could go to the ietf-ipv6-unicast-routing module. It doesn't > > exist yet, my idea was that am IPv6-related WG (6man) would develop > > it. These variables could augment the /rt:routing/rt:router container. > > But they are specified in 4861 to be per interface. Also, is > v6-unicast really the right place to put it? I agree. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Nov 14 01:42:17 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D9C21F8ED6 for ; Mon, 14 Nov 2011 01:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.88 X-Spam-Level: X-Spam-Status: No, score=-102.88 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_36=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 0kH7Bvn2795Y for ; Mon, 14 Nov 2011 01:42:14 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2A39321F8DF4 for ; Mon, 14 Nov 2011 01:41:58 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEA8420CE2 for ; Mon, 14 Nov 2011 10:41:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id A24S4x7uXF7s; Mon, 14 Nov 2011 10:41:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B6FD20CDD; Mon, 14 Nov 2011 10:41:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D41FB1BB3870; Mon, 14 Nov 2011 10:41:32 +0100 (CET) Date: Mon, 14 Nov 2011 10:41:32 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20111114094130.GB17498@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] smiv2 to yang mapping issues 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, 14 Nov 2011 09:42:18 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached please find the issues list I am maintaining for the smiv2 to yang mapping. You can ignore the closed issues (except for those who want to recall history). For some issues, there is a strawman while others are open and looking for a resolution. Lets see what we manage to close tomorrow or during this week (sometimes solutions also evolve around a meeting, in particular since not all implementors happen to be at the meeting). /js PS: Instead of wasting some time generating slides, I am considering to use this plain ASCII (emacs org-mode) issue list for the discussion tomorrow. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="issues.org" * smi2yang-01: ambiguity of OID descriptors (container nesting) [closed] Producing containers of OID value assignments is difficult since multiple descriptors may refer to the same OID value: foo OBJECT IDENTIFIER ::= { baz 1 } bar OBJECT IDENTIFIER ::= { baz 1 } Simple rules like choosing the first defined descriptor do not work either since OID value assignments may be reordered in SMIv2 modules and new ones can be added. ** Solution #01-01: - Drop the idea to represent the OID tree hierarchy by means of nested YANG containers. Instead, do the following: o Generate a top-level container named after the MODULE-IDENTITY node and put _all_ scalars into this container. o Translate all regular tables into top-level container named after the *Table node. The table container contains a list named after the *Entry node. o Translate all augmenting tables, that is the augmenting *Entry nodes, into top-level augment statements (dropping the *Table nodes). - This solution results in a flat schema structure and it avoids using OID descriptors, thus the problem is solved. - If OID tree information is desirable to be captured in the generated YANG module, we could have extension statements to represent the OID structure, e.g.: smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias "interfaces"; } smiv2:oid 1.3.6.1.2.1.2.1 { smiv2:alias "ifNumber"; } This may in particular be useful since OBJECT-IDENTITY macros define constants that are used as values. ** Resolution Adopted solution #01-01, but without changing the smiv2:oid statement, which needs further discussion. Opening smi2yang-08. * smi2yang-02: update ambiguity of named INTEGERs and BITS [closed] SMIv2 allows the descriptors of enumerated INTEGERs and named BITS to change during revisions. YANG does not allow enums to be changed. ** Solution #02-01 Declare this a non-problem since label changes are rare. Hm. ** Solution #02-02 Do generate artificial labels that use the number and add the SMIv2 label via an smiv2 extension statement. This leads to rather ugly instance documents. ** Resolution RFC 4181 already says that labels MUST NOT change and provides a good explanation of the issue. Hence, it seems fair to adopt solution #02-01. * smi2yang-03: OBJECT-IDENTITY containers [closed] OBJECT-IDENTITY macros are translated into YANG identities. They should in addition be translated into containers if the WG decides to keep containers, but note the ambiguities of this (smi2yang-01). ** Resolution By adopting #01-01, this became a mood point. * smi2yang-04: string vs. binary [open] It would be nice to have a reliable mechanism to determine whether an OCTET STRING can be represented as a human readable string or is a binary string. The current ID suggests to use the presence of a DISPLAY-HINT for this purpose. However, the SMIv2 allows to add a DISPLAY-HINT when a MIB module is revised, which can lead to different translations of different versions of a MIB module. ** Solution #04-01 Declare this a non-problem since additions of DISPLAY-HINTs are rare. Suggest that implementations provide options to cast an OCTET STRING into binary to handle situations where a DISPLAY-HINT got added when a module was revised. ** Solution #04-02 Translate strings into unions that allows both a human readable string representation and a binary representation. However, this requires to have some mechanism in place to decide whether a value is a human readable string or a binary string, which means we likely have to mess around with values. ** Solution #04-03 Always translate OCTET STRING types into the YANG binary types. We could list some well-known types as exceptions, like DisplayString, SnmpAdminString, DateAndTime but such a list will always be incomplete and hence some human readable data will be encoded into base64. ** Solution #04-04 Always translate OCTET STRINGS into a choice which contains a binary leaf. Add a second string leaf if there is a DISPLAY-HINT. This would also apply to objects using an OCTET STRING TC, that is in the extreme case (no special rules for well known string types), we get for sysDescr: choice sysDescr-leaf { leaf sysDescr-string { type string; } leaf sysDescr-binary { type binary; } } While this solution is robust wrt. module revisions that add a DISPLAY-HINT, the cost of having to support two formats are significant. * smi2yang-05: accessible-for-notify OBJECT-TYPES [closed] SMIv2 objects can have a MAX-ACCESS of accessible-for-notify and thus can't be accessed via get operations. ** Solution #05-01 Accessible-for-notify objects should be treated specially: - Do not generate schema tree leafs for accessible-for-notify objects. - If such objects are lised in the OBJECTS clause of a NOTIFICATION-TYPE, generate a proper leaf in the notification sub-statements instead of the typical leafref leaf. ** Resolution Adopted solution #05-01. * smi2yang-06: notification containers [closed] For every object listed in the OBJECTS clause, a notification container is generated. This is necessary since multiple leafs may be needed to repesent an object since we have to capture any index information. Right now, the name of this container is: -[-] --n linkDown +--ro linkDown-ifIndex | +--ro ifIndex? leafref +--ro linkDown-ifAdminStatus | +--ro ifIndex? leafref | +--ro ifAdminStatus? leafref +--ro linkDown-ifOperStatus +--ro ifIndex? leafref +--ro ifOperStatus? leafref The choice of - seems arbitrary and the optional disambiguating number may be a surprise. ** Solution #06-01: Always produce a number and call the container object-, that is: --n linkDown +--ro object-1 | +--ro ifIndex? leafref +--ro object-2 | +--ro ifIndex? leafref | +--ro ifAdminStatus? leafref +--ro object-3 +--ro ifIndex? leafref +--ro ifOperStatus? leafref This seems to be closer to SMIv2 and is easier to implement as well. ** Resolution Adopted solution #06-01. * smi2yang-07: augments must be top-level schema tree nodes [closed] The current I-D shows the following translation of an augmenting table: container ifXTable { description "A list of interface entries. The number of entries is given by the value of ifNumber. This table contains additional objects for the interface table." augment "/if-mib:interfaces/if-mib:ifTable" + "/if-mib:ifEntry" { description "An entry containing additional management information applicable to a particular interface."; // ... } This is not legal YANG since the augment-stmt is only allowed as a top-level body statement in YANG. ** Solution #07-01 Move the augments to the top-level. We will loose the description of the table node. State that the table description MAY be translated into comments. Note that this is related to the resolution of smi2yang-01. ** Resolution Adopted solution #07-01. * smi2yang-08: inline vs. outside smiv2:oid mapping [closed] The current translation uses the smiv2:oid to denote the OID of constructs that are mapped to YANG. However, this leaves out any constructs or OID descriptors that are not mapped to YANG. ** Solution #08-01 Do not inline OID definition but instead create a separate "section" at the end of a YANG module that just contains the OID mappings: smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias "interfaces"; } smiv2:oid 1.3.6.1.2.1.2.1 { smiv2:alias "ifNumber"; } This means less "noise" in the YANG definitions and it allows to capture all known OID descriptors within the YANG module. The downside is that in order to find out the OID for say a leaf like ifNumber, one has to do a lookup. ** Solution #08-02 Do inline OID definitions wherever possible, e.g., leaf ifNumber { //.. smiv2:oid "1.3.6.1.2.1.2.1"; } but allow smiv2:oid with nested smiv2:alias statements at other places to capture OIDs that do not map to YANG constructs. ** Solution #08-03 The smiv2:oid can be used inline (where it makes sense) as in leaf ifNumber { //.. smiv2:oid "1.3.6.1.2.1.2.1"; } and in addition at the top-level (with nested smiv2:alias statements) as shown below: smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias interfaces; } smiv2:oid 1.3.6.1.2.1.2.1 { smiv2:alias ifNumber; } smiv2:oid 1.3.6.1.2.1.2.2 { smiv2:alias ifTable; } smiv2:oid 1.3.6.1.2.1.2.2.1 { smiv2:alias ifEntry; } smiv2:oid 1.3.6.1.2.1.2.2.1.1 { smiv2:alias ifIndex; } smiv2:oid 1.3.6.1.2.1.2.2.1.2 { smiv2:alias ifDescr; } For a translator, both are easy to generate and a user gets two reading benefits (and technically the OID now provides the link between the YANG leaf ifNumber and the SMIv2 OID descriptor ifNumber). ** Solution #08-04 The smiv2:oid can be used inline (where it makes sense) as in leaf ifNumber { //.. smiv2:oid "1.3.6.1.2.1.2.1"; } and in addition at the top-level we allow smiv2:alias statements with embedded smiv2:oid statements as shown below: smiv2:alias interfaces { smiv2:oid 1.3.6.1.2.1.2; } smiv2:alias ifNumber { smiv2:oid 1.3.6.1.2.1.2.1; } smiv2:alias ifTable { smiv2:oid 1.3.6.1.2.1.2.2; } smiv2:alias ifEntry { smiv2:oid 1.3.6.1.2.1.2.2.1; } smiv2:alias ifDescr { smiv2:oid 1.3.6.1.2.1.2.2.1.2; } smiv2:alias ifIndex { smiv2:oid 1.3.6.1.2.1.2.2.1.1; } This is essentially solution #08-03 with the nesting of the smiv2:oid and smiv2:alias statements reversed. This solution does not require to change the semantics of smiv2:oid depending on whether it has substatements or not (the OID always "belongs" to the identifier defined by the "parent" statement). ** Resolution Adopted solution #08-04. * smi2yang-09: multiple top-level containers [closed] The current translation creates multiple top-level containers. This is somewhat at odds with a guideline given in RFC 6087: There SHOULD only be one top-level data node defined in each YANG module, if any data nodes are defined at all. I do not recall the precise reasoning behind this SHOULD so it is not clear to me whether this is a problem or not. ** Solution #09-01 Declare that the SHOULD allows to us to have multiple top-level containers. ** Solution #09-02 Create a toplevel container (e.g. named after the module identity node) and register all scalars and non-augmenting tables below that node so we comply to the rule defined in RFC 6087. ** Resolution Adopted solution #09-02. * smi2yang-10: "reference" substatement for "revision" statements [closed] RFC 6087 requires that every revision statement MUST have a reference statement. While this requirement makes sense for newly written modules, it does not make sense for modules derived from SMIv2 modules where this information is usually provided in the description clause. ** Solution #10-01 Declare that this is really a bug in RFC 6087 - the requirement should have been a SHOULD not a MUST to allow for SMIv2 derived modules that do not provide an explicit reference. ** Resolution As Martin pointed out, this really only becomes an issue if the IETF ever publishes YANG modules generated from MIB modules as RFCs. * smi2yang-11: toplevel node for SMIv1 modules [open] SMIv1 modules do not have a MODULE-IDENTITY node that can be used as the top-level node. The specification does not detail what happens in this case. ** Solution #11-01: Use the module name as the top-level node in such cases (this is what libsmi currently does) - but this has an issue if an SMIv1 module gets converted to SMIv2 ** Solution #11-02: Use the shorter prefix generated from the module name - but this has the same issue as #11-01 ** Solution #11-03: Always use the module name at the toplevel node - a bit more verbose but works the same in all cases, regardless whether an input module is in SMIv1 or SMIv2 format. Perhaps the name can be translated to lowercase (eye candy). * smi2yang-12: smi:defval in SMI scope or YANG scope [open] Is the value reported in the smi:defval clause an SMI default value or a YANG default value (e.g. does it include prefixes)? ** Solution #12-01: It is the SMI default value; in particular OBJECT-IDENTITIES are showing up as SMIv2 descriptors and not as prefixed YANG identifiers. * smi2yang-13: import rules cleanup [strawman: adopt #13-02] The current text on imports can be simplified and it can be less specific than it is right now (no need to special case snmpTraps for example). ** Solution #13-01: Describe a simple direct translation and state that implementations MAY prune imports that are not referenced in the translated YANG module. (The details of the pruning of unused imports is thus an implementation detail.) Question: Do we have to have to imports something that is only referenced in an smi:defval statement (assuming it is using SMI scope)? ** Solution #13-02 David Reid wrote good replacement text, see thread "mib to yang conversion: imports". * smi2yang-14: unflatten scalars [open] With the resolution of #01, we ended with having all scalars registered right below the top-level node. This makes retrieving just those scalars (often collections of counters) a bit tricky because the naive approach will also retrieve the tables. ** Solution #14-01 Ignore this and assume people write proper filters. ** Solution #14-02 Move all scalars into an artificially created container, so we end up with: foo-mib +-- scalars | +-- fooScalar1 | +-- fooScalar2 +-- fooTable1 +-- fooTable2 * smi2yang-15: smiv2:implied [strawman: accept #15-01] Add an extension to indicate if an index object is IMPLIED. I believe that with this one addition a tool could get all of the MIB information it needs from the converted yang module. ** Solution #15-01 extension implied { argument "index"; description "If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then the implied statement is present in the yang module and takes as an argument the name of the IMPLIED index object."; reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; } * smi2yang-16: smiv2:oid oid representations [open] Modify the description clause of the oid extension to allow a more user-friendly format. For example, ifEntry could be written as ifTable.1 instead of 1.3.6.1.2.1.2.2.1, or perhaps just .1 as a short hand notation. ** Solution #16-01 extension oid { argument "value"; description "The oid statement takes as an argument the object identifier assigned to an SMIv2 definition. The object identifier value is written in dotted decimal notation. If an oid statement exists for the parent object identifier, then the value may be written in a short hand notation of the form . or just .. For example, the oid value for ifTable from IF-MIB would be '1.3.6.1.2.1.2.2'. The value for ifEntry could be '1.3.6.1.2.1.2.2.1', 'ifTable.1', or simply '.1'. Similarily, ifDescr could be '1.3.6.1.2.1.2.2.1.2', 'ifEntry.2', or '.2'"; reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; } ** Solution #16-02 This seems mostly important for human writers not for machine translations. If more notations are needed, these should be separate aliases so as to allow easy processing of the OID value. Hence, no change needed wrt. smiv2:oid. * smi2yang-17: smiv2:* optional or mandatory? [strawman: accept #17-01] Should the generation of smiv2 statements be optional or part of the normal elements of procedure? ** Solution #17-01 Make the generation of smiv2 statements part of the normal elements of procedure. ** Solution #17-02 Keep the generation of smiv2 statements optional. ** Solution #17-03 Make the generation of smiv2 statements a SHOULD. * smi2yang-18: incomplete well known type mappings [strawman: accept #18-01] Extend the special type mappings as it seems rather incomplete. ** Solution #18-01 Add explicit mapping for ZeroBasedCounter* types. They are listed as having an equivalent type in the YANG world in Table 1 of RFC 6021. Map TruthValue to the YANG boolean. ** Solution #18-02 Remove all special case type mappings. * smi2yang-19: accessible-for-notify objects in INDEXes [closed] If a table index is accessible-for-notify, it is not translated to yang. For example, in MIP-MIB (RFC 2006), the object mipSecViolatorAddress is a table index and has a MAX-ACCESS of accessible-for-notify. According to the current conversion rules (section 8.1), mipSecViolatorAddress will be dropped. But since it is a table index, it must be preserved. ** Solution #19-01 Add the following sentence as the second sentence in section 1.8: Additionally, columnar objects with a MAX-ACCESS of accessible-for-notify are translated to YANG leaf statements if that columnar object is part of the INDEX clause of the table containing that columnar object. ** Resolution Adopted solution #19-01. * smi2yang-20: duplicate objects in INDEXes [strawman: adopt #20-01] RMON2-MIB (RFC 4502) has an INDEX clause in which the same object appears twice. Specifically, alHostEntry's INDEX clause uses protocolDirLocalIndex twice. Following the current conversion rules results in a translated document that violates the YANG rule that a leaf identifier MUST NOT appear more than once in the key. ** Solution #20-01 o The SMIv2 INDEX clause is mapped to the YANG key clause listing the columnar objects forming the key of the YANG list. If the same object appears more than once in the INDEX clause, append '_' to the duplicate object names where '' counts the occurances of the object in the INDEX clause, starting from 2. This would result in key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex " "nlHostAddress protocolDirLocalIndex_2"; * smi2yang-21: prefix generation [open] The I-D proposes an algorithm to generate prefixes from module names. ** Solution #21-01 The current algorithm produces short readable prefixes in most of the cases. The algorithm is not perfect but prefixes are generally shorter than the module name and still readable/meaningful. The length has a great impact on leafref statements for example. ** Solution #21-02 I think the full name as a prefix makes the document more clear to the reader. In most cases, the algorithm either does not shorten the name or only shortens it slightly. Not using the prefix algorithm can make for some long path statements in a few cases. But I still think the clarity of the full name outweighs the brevity of the shortened names. There are a few cases in standard MIBs where using the prefix algorithm results in different modules using the same prefix to refer to different modules or different prefixes to refer to the same module. That's perfectly legal yang, but I find it a bit confusing. The MIBs defined in RFC 5324 provide good examples that could support either side of this debate. That is, the prefix algorithm results in significantly shorter names, but could be confusing. --lrZ03NoBR/3+SXJZ-- From lhotka@cesnet.cz Mon Nov 14 02:01:22 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF11C21F8F84 for ; Mon, 14 Nov 2011 02:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 QKqC6tyQ0I5H for ; Mon, 14 Nov 2011 02:00:36 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id AD29A1F0C71 for ; Mon, 14 Nov 2011 01:51:52 -0800 (PST) Received: from dhcp-9227.meeting.ietf.org (dhcp-9227.meeting.ietf.org [130.129.10.39]) by office2.cesnet.cz (Postfix) with ESMTPSA id 7F39E2CDE058; Mon, 14 Nov 2011 10:51:42 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_8A270591-C8B6-4F51-923D-A9A79517300D"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111114.101309.1774365382168663655.mbj@tail-f.com> Date: Mon, 14 Nov 2011 17:51:37 +0800 Message-Id: <5B3683E1-B869-418E-B3A3-18BE5D3BA3B2@cesnet.cz> References: <20111114.093601.320467224258500807.mbj@tail-f.com> <20111114.101309.1774365382168663655.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 config parameters 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, 14 Nov 2011 10:01:23 -0000 --Apple-Mail=_8A270591-C8B6-4F51-923D-A9A79517300D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 14, 2011, at 5:13 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Nov 14, 2011, at 4:36 PM, Martin Bjorklund wrote: >>> RFC 4861 (Neighbor Discovery in IPv6) states: >>>=20 >>> A router MUST allow for the following conceptual variables to be >>> configured by system management. >>>=20 >>> >>>=20 >>> Should we add these variables to our data model, conditional on an >>> if-feature? They are present in the IP-MIB. >>=20 >> IMO this could go to the ietf-ipv6-unicast-routing module. It doesn't >> exist yet, my idea was that am IPv6-related WG (6man) would develop >> it. These variables could augment the /rt:routing/rt:router = container. >=20 > But they are specified in 4861 to be per interface. Also, is Each "router" entry in the routing-cfg module represents a = self-contained (virtual) router, so configuration of its interfaces has = to be done specifically for each entry, i. e. under = /rt:routing/rt:router, with leafref references to the "interfaces" = subtree. For example, each virtual router may define a different value = for CurHopLimit. > v6-unicast really the right place to put it? As soon as a server advertises the "ipv6-routing" feature, it should = also implement some nodes analogical to what the ipv4-unicast-routing = module provides. >=20 > I think it makes sense to put them in this document, but I would very > much welcome input from 6man. I think it would require more than just implementing these variables. = For example, a neighbor cache (state data) should be implemented, too. My concern is that including v6 neighbor discovery would delay the = publication of the ip-cfg module. Lada >=20 >=20 > /martin >=20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_8A270591-C8B6-4F51-923D-A9A79517300D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE0MDk1MTM3WjAjBgkqhkiG9w0BCQQxFgQU5uWc/B7DV+tuNf3To+BQKgqACc8wXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQB6mTGGBdhERr9L2FutsGCCN+pv UtTuLqgQcMTOH3tSppxHSLjgPG9T8QsWMZ9wHXCov6eCDBw1Sl6OTupZytGPgiQ1Zbo3ILkHdIm2 smgbSzkuh2RVmFNP/f3b/GUzSskDnoIx6miJ6m+xOTgGUbhlQRpc2KTsNFIQxJ5NQvPxoDAJBJN+ bTTbEEvMmskWBa9zegkJ8aHoLU9cwlcRQ7jK+sHKGjiLRQIVthlicGY4W+vVBwZgfloC1WkIZHEH 3grL4CHF6LVDmf5lAuKrl5tC3lvGXFy4r8JTAohN+0LvBAduSS4FIKd5LAbTU6Dti/F/N202rCVs cGzZaMNl2IPuAAAAAAAA --Apple-Mail=_8A270591-C8B6-4F51-923D-A9A79517300D-- From lhotka@cesnet.cz Mon Nov 14 02:15:03 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFCD21F8D74 for ; Mon, 14 Nov 2011 02:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 jSW0tRHWkTn0 for ; Mon, 14 Nov 2011 02:15:02 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id F100421F8D65 for ; Mon, 14 Nov 2011 02:15:01 -0800 (PST) Received: from dhcp-9227.meeting.ietf.org (dhcp-9227.meeting.ietf.org [130.129.10.39]) by office2.cesnet.cz (Postfix) with ESMTPSA id 317D82CDE058; Mon, 14 Nov 2011 11:14:39 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_890AF7AC-425F-46EA-A70B-94F61C3DCEA6"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111114091433.GA17181@elstar.local> Date: Mon, 14 Nov 2011 18:14:32 +0800 Message-Id: References: <20111114.093601.320467224258500807.mbj@tail-f.com> <20111114091433.GA17181@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 config parameters 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, 14 Nov 2011 10:15:04 -0000 --Apple-Mail=_890AF7AC-425F-46EA-A70B-94F61C3DCEA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 14, 2011, at 5:14 PM, Juergen Schoenwaelder wrote: > On Mon, Nov 14, 2011 at 09:36:01AM +0100, Martin Bjorklund wrote: >> Hi, >>=20 >> Here are two issues for the draft-ietf-netmod-ip-cfg document. >>=20 >>=20 >> RFC 4862 (IPv6 Stateless Address Autoconfiguration) states: >>=20 >> A node MUST allow the following autoconfiguration-related variable = to >> be configured by system management for each multicast-capable >> interface: >>=20 >> DupAddrDetectTransmits >>=20 >> Should we add this leaf to our data model? >=20 > If RFC 4862 says so... >=20 >> RFC 4861 (Neighbor Discovery in IPv6) states: >>=20 >> A router MUST allow for the following conceptual variables to be >> configured by system management. >>=20 >> >>=20 >> Should we add these variables to our data model, conditional on an >> if-feature? They are present in the IP-MIB. >=20 > The question here is what is in scope of this work and what is out of > scope. Are we limiting this data model to the configuration of > interfaces or do we include things happening on routers, like the > configuration of routing advertisements. In fact, if we take a broad > definition of the scope, we will have to work through >=20 > draft-ietf-6man-node-req-bis-11.txt >=20 > and all the mandatory stuff it references. And also 4941 comes into my > mind and there is ongoing work on source address selection and even > discussion today how to handle situations where you get potentially > conflicting information via RAs and DHCP. Since it is unlikely that we > will be successful covering everything configurable in the IP layer, > we should in my view have a plan how to put things into manageable > pieces. Yes, that's why I don't want to have an ietf-ipv6-unicast-routing module = as a part of the routing-cfg draft. 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, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_890AF7AC-425F-46EA-A70B-94F61C3DCEA6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE0MTAxNDMyWjAjBgkqhkiG9w0BCQQxFgQUOzL8g+dAlJW6wpTRruiHUsZ4MH8wXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQBI3tqbQS//k5SD/TxmTxo7oS7t fZ38BwLbHD63u2gQXWQ+dWSKLzY7uE3NNGu8So22xcQHq4XqQ+7cN86pq59rFjABXf09TFzevWpF VhC47Tz3VBzY3YWWd/mOPIqITxhyTLWlDVzFsnRy+W6seSYzcJXAgErmNRGScj6TyOCQyfBhz/Af rc6fFEJxog+Teb0oY7ugLL5JKK9CDYY4KRd1R8sP1bSvDm7n/gu+M4gxhDg9w2KVfSwTCX2ZU8wV NQvEWR77Eu2QDiHLlq5Rr5Z2h69YmgnlPyxOVfh7JzkQT+zvhnJHfST6lN+QwfrDqSydSTWFGgEl wULqJDmcaCvUAAAAAAAA --Apple-Mail=_890AF7AC-425F-46EA-A70B-94F61C3DCEA6-- From j.schoenwaelder@jacobs-university.de Mon Nov 14 02:36:51 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C6911E80D9 for ; Mon, 14 Nov 2011 02:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.176 X-Spam-Level: X-Spam-Status: No, score=-103.176 tagged_above=-999 required=5 tests=[AWL=0.073, 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 4q3mpOSd6rUp for ; Mon, 14 Nov 2011 02:36:50 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B198911E80D4 for ; Mon, 14 Nov 2011 02:36:50 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12EB720CF4; Mon, 14 Nov 2011 11:36:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Nfj7Ar_HnDqc; Mon, 14 Nov 2011 11:36:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2246920CF3; Mon, 14 Nov 2011 11:36:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5A9D01BB3A95; Mon, 14 Nov 2011 11:36:31 +0100 (CET) Date: Mon, 14 Nov 2011 11:36:31 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20111114103631.GA17767@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <20111114.093601.320467224258500807.mbj@tail-f.com> <20111114091433.GA17181@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] ipv6 config parameters 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, 14 Nov 2011 10:36:51 -0000 On Mon, Nov 14, 2011 at 06:14:32PM +0800, Ladislav Lhotka wrote: > > On Nov 14, 2011, at 5:14 PM, Juergen Schoenwaelder wrote: > > > On Mon, Nov 14, 2011 at 09:36:01AM +0100, Martin Bjorklund wrote: > >> Hi, > >> > >> Here are two issues for the draft-ietf-netmod-ip-cfg document. > >> > >> > >> RFC 4862 (IPv6 Stateless Address Autoconfiguration) states: > >> > >> A node MUST allow the following autoconfiguration-related variable to > >> be configured by system management for each multicast-capable > >> interface: > >> > >> DupAddrDetectTransmits > >> > >> Should we add this leaf to our data model? > > > > If RFC 4862 says so... > > > >> RFC 4861 (Neighbor Discovery in IPv6) states: > >> > >> A router MUST allow for the following conceptual variables to be > >> configured by system management. > >> > >> > >> > >> Should we add these variables to our data model, conditional on an > >> if-feature? They are present in the IP-MIB. > > > > The question here is what is in scope of this work and what is out of > > scope. Are we limiting this data model to the configuration of > > interfaces or do we include things happening on routers, like the > > configuration of routing advertisements. In fact, if we take a broad > > definition of the scope, we will have to work through > > > > draft-ietf-6man-node-req-bis-11.txt > > > > and all the mandatory stuff it references. And also 4941 comes into my > > mind and there is ongoing work on source address selection and even > > discussion today how to handle situations where you get potentially > > conflicting information via RAs and DHCP. Since it is unlikely that we > > will be successful covering everything configurable in the IP layer, > > we should in my view have a plan how to put things into manageable > > pieces. > > Yes, that's why I don't want to have an ietf-ipv6-unicast-routing > module as a part of the routing-cfg draft. I am not sure I can follow you. What would ietf-ipv6-unicast-routing cover? What do you have in mind? /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@cesnet.cz Mon Nov 14 02:45:30 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5025311E8156 for ; Mon, 14 Nov 2011 02:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 UqvR3yG5uXWP for ; Mon, 14 Nov 2011 02:45:29 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF7D11E818E for ; Mon, 14 Nov 2011 02:45:29 -0800 (PST) Received: from dhcp-9227.meeting.ietf.org (dhcp-9227.meeting.ietf.org [130.129.10.39]) by office2.cesnet.cz (Postfix) with ESMTPSA id 08B482CDE058; Mon, 14 Nov 2011 11:45:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_0DF8477B-E1A7-43A7-A33C-502ADEAD088E"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111114103631.GA17767@elstar.local> Date: Mon, 14 Nov 2011 18:45:20 +0800 Message-Id: <33B7505D-9F75-4FA2-9771-885FBEB60453@cesnet.cz> References: <20111114.093601.320467224258500807.mbj@tail-f.com> <20111114091433.GA17181@elstar.local> <20111114103631.GA17767@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 config parameters 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, 14 Nov 2011 10:45:30 -0000 --Apple-Mail=_0DF8477B-E1A7-43A7-A33C-502ADEAD088E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 14, 2011, at 6:36 PM, Juergen Schoenwaelder wrote: > On Mon, Nov 14, 2011 at 06:14:32PM +0800, Ladislav Lhotka wrote: >>=20 >> On Nov 14, 2011, at 5:14 PM, Juergen Schoenwaelder wrote: >>=20 >>> On Mon, Nov 14, 2011 at 09:36:01AM +0100, Martin Bjorklund wrote: >>>> Hi, >>>>=20 >>>> Here are two issues for the draft-ietf-netmod-ip-cfg document. >>>>=20 >>>>=20 >>>> RFC 4862 (IPv6 Stateless Address Autoconfiguration) states: >>>>=20 >>>> A node MUST allow the following autoconfiguration-related variable = to >>>> be configured by system management for each multicast-capable >>>> interface: >>>>=20 >>>> DupAddrDetectTransmits >>>>=20 >>>> Should we add this leaf to our data model? >>>=20 >>> If RFC 4862 says so... >>>=20 >>>> RFC 4861 (Neighbor Discovery in IPv6) states: >>>>=20 >>>> A router MUST allow for the following conceptual variables to be >>>> configured by system management. >>>>=20 >>>> >>>>=20 >>>> Should we add these variables to our data model, conditional on an >>>> if-feature? They are present in the IP-MIB. >>>=20 >>> The question here is what is in scope of this work and what is out = of >>> scope. Are we limiting this data model to the configuration of >>> interfaces or do we include things happening on routers, like the >>> configuration of routing advertisements. In fact, if we take a broad >>> definition of the scope, we will have to work through >>>=20 >>> draft-ietf-6man-node-req-bis-11.txt >>>=20 >>> and all the mandatory stuff it references. And also 4941 comes into = my >>> mind and there is ongoing work on source address selection and even >>> discussion today how to handle situations where you get potentially >>> conflicting information via RAs and DHCP. Since it is unlikely that = we >>> will be successful covering everything configurable in the IP layer, >>> we should in my view have a plan how to put things into manageable >>> pieces. >>=20 >> Yes, that's why I don't want to have an ietf-ipv6-unicast-routing >> module as a part of the routing-cfg draft. >=20 > I am not sure I can follow you. What would ietf-ipv6-unicast-routing > cover? What do you have in mind? Firstly, it should define analogical things as the ipv4-unicast-routing = module now provides, such as IPv6 route content - in most cases this = part would only require to replace inet:ipv4-{address,prefix} with the = IPv6 counterpart. But beyond that, a whole bunch of other IPv6-specific parameters would = be needed, as you wrote above. 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, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_0DF8477B-E1A7-43A7-A33C-502ADEAD088E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE0MTA0NTIwWjAjBgkqhkiG9w0BCQQxFgQUyYocFKZ/BdLNQMyydpTGKaca7EgwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQAlmcEDLqlGrwOGX5TMrhqG/nwQ Opj+DOjwRkP2BJdpHGLFqIPNTwC8FWKUbMqZbK0IMJa8ZnXc2lGf+QjU7jGXQr1XZ4kBn7S4ctwm lIwdPtPLYgpgw1+t/7fsp9An3gwOUycmZh010nUiT+IQSjPf7v+yY396iL3hK42tGpyh/HeaVCxT ND+GUeiqkY+vA2D3QuQ08rwJf0qDqxqY11DVBr7j56+rA71xx1+I+veGub3I7g++JuwSmgj4XBVX Mae/+a1LJP1r1JO1N4m+744AH6/cDO3s9eAbYZRD+59+FTTxjE6CCgc7P1nIoPal8Nf0Z2hDKb26 hDtH/cHgGCNrAAAAAAAA --Apple-Mail=_0DF8477B-E1A7-43A7-A33C-502ADEAD088E-- From j.schoenwaelder@jacobs-university.de Mon Nov 14 03:04:50 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B3D1F0C43 for ; Mon, 14 Nov 2011 03:04:50 -0800 (PST) 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 rht9JKxLYLa9 for ; Mon, 14 Nov 2011 03:04:49 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 27D581F0C7B for ; Mon, 14 Nov 2011 03:04:48 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23EA320CDC; Mon, 14 Nov 2011 12:04:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QWmZjsxcqztp; Mon, 14 Nov 2011 12:04:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A563620D00; Mon, 14 Nov 2011 12:04:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D93E71BB3BA8; Mon, 14 Nov 2011 12:04:28 +0100 (CET) Date: Mon, 14 Nov 2011 12:04:28 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20111114110428.GA17874@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <20111114.093601.320467224258500807.mbj@tail-f.com> <20111114091433.GA17181@elstar.local> <20111114103631.GA17767@elstar.local> <33B7505D-9F75-4FA2-9771-885FBEB60453@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33B7505D-9F75-4FA2-9771-885FBEB60453@cesnet.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 config parameters 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, 14 Nov 2011 11:04:50 -0000 On Mon, Nov 14, 2011 at 06:45:20PM +0800, Ladislav Lhotka wrote: > > On Nov 14, 2011, at 6:36 PM, Juergen Schoenwaelder wrote: > > > On Mon, Nov 14, 2011 at 06:14:32PM +0800, Ladislav Lhotka wrote: > >> > >> On Nov 14, 2011, at 5:14 PM, Juergen Schoenwaelder wrote: > >> > >>> On Mon, Nov 14, 2011 at 09:36:01AM +0100, Martin Bjorklund wrote: > >>>> Hi, > >>>> > >>>> Here are two issues for the draft-ietf-netmod-ip-cfg document. > >>>> > >>>> > >>>> RFC 4862 (IPv6 Stateless Address Autoconfiguration) states: > >>>> > >>>> A node MUST allow the following autoconfiguration-related variable to > >>>> be configured by system management for each multicast-capable > >>>> interface: > >>>> > >>>> DupAddrDetectTransmits > >>>> > >>>> Should we add this leaf to our data model? > >>> > >>> If RFC 4862 says so... > >>> > >>>> RFC 4861 (Neighbor Discovery in IPv6) states: > >>>> > >>>> A router MUST allow for the following conceptual variables to be > >>>> configured by system management. > >>>> > >>>> > >>>> > >>>> Should we add these variables to our data model, conditional on an > >>>> if-feature? They are present in the IP-MIB. > >>> > >>> The question here is what is in scope of this work and what is out of > >>> scope. Are we limiting this data model to the configuration of > >>> interfaces or do we include things happening on routers, like the > >>> configuration of routing advertisements. In fact, if we take a broad > >>> definition of the scope, we will have to work through > >>> > >>> draft-ietf-6man-node-req-bis-11.txt > >>> > >>> and all the mandatory stuff it references. And also 4941 comes into my > >>> mind and there is ongoing work on source address selection and even > >>> discussion today how to handle situations where you get potentially > >>> conflicting information via RAs and DHCP. Since it is unlikely that we > >>> will be successful covering everything configurable in the IP layer, > >>> we should in my view have a plan how to put things into manageable > >>> pieces. > >> > >> Yes, that's why I don't want to have an ietf-ipv6-unicast-routing > >> module as a part of the routing-cfg draft. > > > > I am not sure I can follow you. What would ietf-ipv6-unicast-routing > > cover? What do you have in mind? > > Firstly, it should define analogical things as the ipv4-unicast-routing module now provides, such as IPv6 route content - in most cases this part would only require to replace inet:ipv4-{address,prefix} with the IPv6 counterpart. > > But beyond that, a whole bunch of other IPv6-specific parameters would be needed, as you wrote above. > OK. I think our disconnect is that I do not consider things like ND parameters or RA config a subject of the routing module while you seem to do. And it might be that the number of IPv4 knobs that do exist out there is not necessarily much smaller than number of IPv6 knobs we know about today. /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 Nov 14 03:17:31 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F5911E80AC for ; Mon, 14 Nov 2011 03:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3nEaT+VgI1V for ; Mon, 14 Nov 2011 03:17:31 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 353F811E80BB for ; Mon, 14 Nov 2011 03:17:31 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 513C912008E8; Mon, 14 Nov 2011 12:17:29 +0100 (CET) Date: Mon, 14 Nov 2011 12:17:29 +0100 (CET) Message-Id: <20111114.121729.815594150126157417.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20111114110428.GA17874@elstar.local> References: <20111114103631.GA17767@elstar.local> <33B7505D-9F75-4FA2-9771-885FBEB60453@cesnet.cz> <20111114110428.GA17874@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] ipv6 config parameters 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, 14 Nov 2011 11:17:31 -0000 Juergen Schoenwaelder wrote: > On Mon, Nov 14, 2011 at 06:45:20PM +0800, Ladislav Lhotka wrote: > > Firstly, it should define analogical things as the > > ipv4-unicast-routing module now provides, such as IPv6 route content > > - in most cases this part would only require to replace > > inet:ipv4-{address,prefix} with the IPv6 counterpart. > > > > But beyond that, a whole bunch of other IPv6-specific parameters > > would be needed, as you wrote above. > > > > OK. I think our disconnect is that I do not consider things like ND > parameters or RA config a subject of the routing module while you seem > to do. Section 12 of draft-ietf-6man-node-req-bis-11 says: This section defines general host considerations for IPv6 nodes that act as routers. Currently, this section does not discuss routing- specific requirements. and then it talks about ND and RA etc. So I believe we should not blur this distinction. /martin From mbj@tail-f.com Mon Nov 14 04:50:20 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77F011E8284 for ; Mon, 14 Nov 2011 04:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-5jaEV+CO9X for ; Mon, 14 Nov 2011 04:50:20 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E07D011E828D for ; Mon, 14 Nov 2011 04:50:18 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id AEF6D12008E8 for ; Mon, 14 Nov 2011 13:50:17 +0100 (CET) Date: Mon, 14 Nov 2011 13:50:17 +0100 (CET) Message-Id: <20111114.135017.268510208816363038.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] comments on draft-ietf-netmod-routing-cfg-01 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, 14 Nov 2011 12:50:21 -0000 Hi, Here are my comments on draft-ietf-netmod-routing-cfg-01: I think this document has improved a lot over -00, with the new structure in ietf-routing. o Table 1. Remove "eth" from this table; it isn't used. I was going to say that you should remove "rip", since it is a bit confusing with having an example module listed in this table. But it is actually used. Maybe it would be more clear to rmeove this table, and show the proper imports / xmlns declarations in the examples that need them. This way each example would be more self-contained. (I think there is actually just one example where this applies). o Section 4: As can be see from Figure 1, the core routing data model introduces several generic components of a routing framework: routers, routing tables containing routes, routing protocols, route filters and RPC operations. I cannot see any RPC operations in figure 1. o Section 4: OLD: Each routing protocol instance, including the "static" and "direct" pseudo-protocols NEW: Each routing protocol instance, including instances of the "static" and "direct" pseudo-protocols In the same sentence, add forward reference to where the "static" and "direct" pseudo-protocols are defined. o Section 4: o Along with the main routing table, which must always be present, an additional routing table is configured. Add forward refrence to where the main routing table is defined. o Section 4.1 s/it it not/it is not/ o Secion 4.2 The way the module is currently written, you should: s/IP/IPv4/ But doesn't it make sense to keep the text and change the module? I.e., let a route have a (generic) ip-address and ip-prefix. o Section 4.3 OLD: Routing tables are lists of routes complemented with administrative data, namely: NEW: Routing tables are lists of routes complemented with administrative data for each route, namely: o Section 4.3 This also includes manipulations via the "static" pseudo-protocol. Add a forward reference to where the "static" pseudo-protocol is explained. o Section 4.3 At least the following two routing tables MUST be configured for each router instance: How is this MUST enforced? How does am operator know which routing table is the fib? Maybe change the routing table to a type union of the two enumerations "fib" and "main", and a string? o Section 4.3 2. Main routing table to which all routing protocol instances are connected by default. What does "connected by default" really mean? There is nothing in the data model about this. o Section 4.3 The naming scheme for routing tables, as well as restrictions on the number and configurability of routing tables are implementation- specific. Could you elaborate a bit on the naming scheme and "configurability" part? Maybe you mean that a routing table name SHOULD be arbitrary, but an implementation MAY impose some restriction on the name? o Section 4.5 The default value for route filter type is the identity "deny-all-route-filter" defined in the "ietf-routing" module, which represents a route filtering policy in which all routes are rejected. Why is this necessary? Is it common to define filters w/o any type and let that mean the deny-all type? I suggest you remove this default, and make the type mandatory instead. o grouping afn-safi leaf address-family { type ianaaf:address-family; default "ipV4"; ... } leaf safi { type ianaaf:subsequent-address-family; default "nlri-unicast"; ... } Should we really have these as defaults? Isn't it more clear to make these mandatory instead? o grouping route-content leaf source-protocol { type string; description "The name of the routing protocol instance from which the route comes. This routing protocol must be configured (automatically or manually) in the device."; } What does "configured automatically" mean? Automatically by whom? o rpc get-route container destination-address { uses afn-safi; description "Second parameter: destination address. AFN/SAFI-specific modules must augment this container with a leaf named 'address'. "; } Why is it important that AFN/SAFI modules choose the name "address"? I suggest something like: AFN/SAFI-specific modules must augment this container with address-specific parameters. o list router Here you use the term "(logical) router". In 4.1. you say "(virtual) router". You may want to use the same term, and define it once. o container connected-routing-tables list connected-routing-table { key "name"; description "List of routing tables to which the routing protocol instance is connected. No more than one routing table may be configured for each AFN/SAFI pair. What does the last sentence mean? Implementation may provide default routing tables for some AFN/SAFI pairs, which are used if the corresponding entry is not configured. I do not understand the last sentence. How does an implementation provide these default routing tables? Where is the "corresponding entry"? o Why don't we have a ipv6-unicast module? /martin From phil@juniper.net Mon Nov 14 05:01:29 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7595511E829E for ; Mon, 14 Nov 2011 05:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 YhF60NXote0z for ; Mon, 14 Nov 2011 05:01:29 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 15D0C11E829B for ; Mon, 14 Nov 2011 05:01:25 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTsERF5OyoyCnndla8AomzbWS8K86HXw1@postini.com; Mon, 14 Nov 2011 05:01:28 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Nov 2011 04:59:55 -0800 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 pAECxqh84881; Mon, 14 Nov 2011 04:59:52 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id pAECVHc4050745; Mon, 14 Nov 2011 12:31:18 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201111141231.pAECVHc4050745@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20111114.092348.1957965659644075140.mbj@tail-f.com> Date: Mon, 14 Nov 2011 07:31:17 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 13:01:29 -0000 Martin Bjorklund writes: >We already know from this ML that some vendors (including myself) will >provide config true access to parts of the MIBs. (We're using a bunch >of directives to the compiler to control which parts). As the >document is written today, the output from my tool is non-compliant, >but I do not think this is necessary. Wouldn't this be a list of deviations that your tool would generate (read-only as required plus a deviation)? Thanks, Phil From lhotka@cesnet.cz Mon Nov 14 06:40:15 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAD311E8170 for ; Mon, 14 Nov 2011 06:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 fFTiOJbtrZ9m for ; Mon, 14 Nov 2011 06:40:14 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 7585411E8090 for ; Mon, 14 Nov 2011 06:40:14 -0800 (PST) Received: from dhcp-403d.meeting.ietf.org (dhcp-403d.meeting.ietf.org [130.129.64.61]) by office2.cesnet.cz (Postfix) with ESMTPSA id 9B1EF2CDE058; Mon, 14 Nov 2011 15:40:11 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_52A0DDD0-1DA8-41D0-A557-5F2A7E8AECA0"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111114.121729.815594150126157417.mbj@tail-f.com> Date: Mon, 14 Nov 2011 22:40:04 +0800 Message-Id: <51727BD7-C77D-4C69-85F6-3EDEAF0798C6@cesnet.cz> References: <20111114103631.GA17767@elstar.local> <33B7505D-9F75-4FA2-9771-885FBEB60453@cesnet.cz> <20111114110428.GA17874@elstar.local> <20111114.121729.815594150126157417.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] ipv6 config parameters 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, 14 Nov 2011 14:40:15 -0000 --Apple-Mail=_52A0DDD0-1DA8-41D0-A557-5F2A7E8AECA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 14, 2011, at 7:17 PM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Mon, Nov 14, 2011 at 06:45:20PM +0800, Ladislav Lhotka wrote: >>> Firstly, it should define analogical things as the >>> ipv4-unicast-routing module now provides, such as IPv6 route content >>> - in most cases this part would only require to replace >>> inet:ipv4-{address,prefix} with the IPv6 counterpart.=20 >>>=20 >>> But beyond that, a whole bunch of other IPv6-specific parameters >>> would be needed, as you wrote above.=20 >>>=20 >>=20 >> OK. I think our disconnect is that I do not consider things like ND >> parameters or RA config a subject of the routing module while you = seem >> to do. >=20 > Section 12 of draft-ietf-6man-node-req-bis-11 says: >=20 > This section defines general host considerations for IPv6 nodes that > act as routers. Currently, this section does not discuss routing- > specific requirements. >=20 > and then it talks about ND and RA etc. So I believe we should not > blur this distinction. I don't mind if we agree on another organization, but I think it should = be done in the same way for IPv4 and IPv6. So probably you should also = define the contents of IPv4 & IPv6 unicast routes in the ip-cfg module. = For IPv4, it is currently done in the ipv4-unicast-routing module. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_52A0DDD0-1DA8-41D0-A557-5F2A7E8AECA0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE0MTQ0MDA1WjAjBgkqhkiG9w0BCQQxFgQUC7TgDU70aVJgYxlX+IPy496bSB0wXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQBOWu1zACtfq0BZRI2SZbvpWRSe NJWOTemC+8wnNgAYFZj/ZAps2rV4GskHpGpremXdayPvGhS8NXRfpuFPSi5haXxdqIxGsNu+f8w4 1V9ayMKFYapujHqMGY3CEWLsHdSQbCkLWHG2Fh+1KtKaccxV22wdL3qxzXCK/FYcebirD51mm4zo xIKsJBmDGP0MUDp71pN6FsDOT/1gfe+wCt1wzfvRQipBlSwYbdO5BLJ5uRAOL08hcufSxVStx+vW 2FpKF3vfz5dCrc4UihcqppJoZoqdkqsABLfBNNd4yMl6l4y67C28s0jCnqWa5nomA8dWaI77fF5O fY7zo3eerzL4AAAAAAAA --Apple-Mail=_52A0DDD0-1DA8-41D0-A557-5F2A7E8AECA0-- From lhotka@cesnet.cz Mon Nov 14 08:14:33 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E13A11F0C9C for ; Mon, 14 Nov 2011 08:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 F41yeAUE-erq for ; Mon, 14 Nov 2011 08:14:33 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8AB1F0CA2 for ; Mon, 14 Nov 2011 08:14:32 -0800 (PST) Received: from dhcp-403d.meeting.ietf.org (dhcp-403d.meeting.ietf.org [130.129.64.61]) by office2.cesnet.cz (Postfix) with ESMTPSA id E5DA72CDE05B; Mon, 14 Nov 2011 17:14:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_6517E8A3-55CE-4E2D-9E49-56EE26D83BB6"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111114.135017.268510208816363038.mbj@tail-f.com> Date: Tue, 15 Nov 2011 00:14:24 +0800 Message-Id: <5CD9D82F-8C16-47EC-9677-3EED4B6C4E00@cesnet.cz> References: <20111114.135017.268510208816363038.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-01 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, 14 Nov 2011 16:14:34 -0000 --Apple-Mail=_6517E8A3-55CE-4E2D-9E49-56EE26D83BB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, thanks for the review. See inline. On Nov 14, 2011, at 8:50 PM, Martin Bjorklund wrote: > Hi, >=20 > Here are my comments on draft-ietf-netmod-routing-cfg-01: >=20 > I think this document has improved a lot over -00, with the new > structure in ietf-routing. >=20 > o Table 1. >=20 > Remove "eth" from this table; it isn't used. OK >=20 > I was going to say that you should remove "rip", since it is a bit > confusing with having an example module listed in this table. But > it is actually used. >=20 > Maybe it would be more clear to rmeove this table, and show the > proper imports / xmlns declarations in the examples that need them. > This way each example would be more self-contained. (I think there > is actually just one example where this applies). I think this is done in the examples, or do you mean something else? On the other hand, I believe it is useful to have all prefixes that are = used anywhere in the draft listed in one place. >=20 >=20 > o Section 4: >=20 > As can be see from Figure 1, the core routing data model introduces > several generic components of a routing framework: routers, routing > tables containing routes, routing protocols, route filters and RPC > operations. >=20 > I cannot see any RPC operations in figure 1. Oh yes, I first had the full output of "pyang -f tree" there but then I = thought the "rpcs:" part was confusing and deleted it. I will probably = use two figures, one with the main data tree and another with the RPC = tree. =20 >=20 >=20 > o Section 4: >=20 > OLD: >=20 > Each routing protocol instance, including the "static" and > "direct" pseudo-protocols >=20 > NEW: >=20 > Each routing protocol instance, including instances of the > "static" and "direct" pseudo-protocols >=20 >=20 > In the same sentence, add forward reference to where the "static" > and "direct" pseudo-protocols are defined.=20 OK >=20 >=20 > o Section 4: >=20 > o Along with the main routing table, which must always be present, > an additional routing table is configured. >=20 > Add forward refrence to where the main routing table is defined.=20 OK >=20 >=20 > o Section 4.1 >=20 > s/it it not/it is not/ OK >=20 >=20 > o Secion 4.2 >=20 > The way the module is currently written, you should: s/IP/IPv4/ Right, although the same will have to be done for IPv6 and potentially = other address families. I'd like to have it generic but I don't think it = is possible in YANG (see also my next comment). >=20 > But doesn't it make sense to keep the text and change the module? > I.e., let a route have a (generic) ip-address and ip-prefix. The problem is that ip-address and ip-prefix only support IPv4 and IPv6, = but this should support other address families as well. >=20 >=20 > o Section 4.3 >=20 > OLD: >=20 > Routing tables are lists of routes complemented with administrative > data, namely: >=20 > NEW: >=20 > Routing tables are lists of routes complemented with administrative > data for each route, namely: OK >=20 >=20 > o Section 4.3 >=20 > This also includes manipulations via the "static" pseudo-protocol. >=20 > Add a forward reference to where the "static" pseudo-protocol is > explained. OK >=20 >=20 > o Section 4.3 >=20 > At least the following two routing tables MUST be configured for = each > router instance: >=20 > How is this MUST enforced? How does am operator know which routing > table is the fib? >=20 > Maybe change the routing table to a type union of the two > enumerations "fib" and "main", and a string? It is similar to RFC 4861: We need a conceptual model of the host, i.e. = conceptual objects that behave like "fib" and "main", but we needn't = enforce any naming scheme. >=20 >=20 > o Section 4.3 >=20 > 2. Main routing table to which all routing protocol instances are > connected by default. >=20 > What does "connected by default" really mean? There is nothing in > the data model about this. Yes, it is exactly because the data model cannot pre-populate the list = of routing tables with the entry for "main", which is however required = to be present. An implementation just has to use the main routing table = if the protocol instance doesn't say otherwise. >=20 >=20 > o Section 4.3 >=20 > The naming scheme for routing tables, as well as restrictions on the > number and configurability of routing tables are implementation- > specific. >=20 > Could you elaborate a bit on the naming scheme and "configurability" > part? Maybe you mean that a routing table name SHOULD be > arbitrary, but an implementation MAY impose some restriction on the > name? Implementation A may call its main routing table "main.v4" while = implementation B calls it "inet.0". Also, some implementations may not = allow the user to configure additional tables. >=20 >=20 > o Section 4.5 >=20 > The default value for route filter type > is the identity "deny-all-route-filter" defined in the = "ietf-routing" > module, which represents a route filtering policy in which all = routes > are rejected. >=20 > Why is this necessary? Is it common to define filters w/o any type > and let that mean the deny-all type? I suggest you remove this > default, and make the type mandatory instead. It is not necessary, but at least you get two extreme filtering options = at this stage, without having any real route-filtering framework: either = you don't define any route filter, which means "permit all", or you = define one, which means "reject all". =20 >=20 >=20 > o grouping afn-safi >=20 > leaf address-family { > type ianaaf:address-family; > default "ipV4"; > ... > } >=20 > leaf safi { > type ianaaf:subsequent-address-family; > default "nlri-unicast"; > ... > } >=20 > Should we really have these as defaults? Isn't it more clear to > make these mandatory instead? Yes, it is probably "politically incorrect", but in practical terms this = default still makes sense for most users. >=20 >=20 > o grouping route-content >=20 > leaf source-protocol { > type string; > description > "The name of the routing protocol instance from which the > route comes. This routing protocol must be configured > (automatically or manually) in the device."; > } >=20 > What does "configured automatically" mean? Automatically by whom? Instances of "static" and "direct" protocols must be pre-configured in = each router instance. So "automatically" means "configured-by-system". =20 >=20 >=20 > o rpc get-route >=20 > container destination-address { > uses afn-safi; > description > "Second parameter: destination address. >=20 > AFN/SAFI-specific modules must augment this container = with > a leaf named 'address'. > "; > } >=20 > Why is it important that AFN/SAFI modules choose the name "address"? > I suggest something like: >=20 > AFN/SAFI-specific modules must augment this container = with > address-specific parameters. I'd prefer that an address be always called "address", be it IPv4, IPv6 = or whatever, in order to achieve some kind of poor man's = object-orientedness. For example, some leafrefs may then refer to this = "address" independently of the address family. >=20 >=20 > o list router >=20 > Here you use the term "(logical) router". In 4.1. you say > "(virtual) router". You may want to use the same term, and define > it once. >=20 OK >=20 > o container connected-routing-tables >=20 > list connected-routing-table { > key "name"; > description > "List of routing tables to which the routing = protocol > instance is connected. No more than one routing > table may be configured for each AFN/SAFI pair. Joel's objection to the previous version was that one instance of a = protocol such as BGP may carry routes for multiple address families. So = the idea here is that, e.g., IPv4 routes go to routing table "inet.0" = and IPv6 routes to "inet6.0". =20 >=20 > What does the last sentence mean? >=20 > Implementation may provide default routing tables > for some AFN/SAFI pairs, which are used if the > corresponding entry is not configured. >=20 > I do not understand the last sentence. How does an implementation > provide these default routing tables? Where is the "corresponding > entry"? The sentence should be deleted. The "main" routing table must be = configured for each supported AFN/SAFI combination and this is the = routing table to which the routing protocol instance is connected by = default, i.e., unless "connected-routing-table" is present. I also have to clarify this in Sec. 4.3: OLD At least the following two routing tables MUST be configured for each = router instance: NEW At least the following two routing tables MUST be configured for each = AFN/SAFI combination supported by the router instance:=20 (Because previously each router instance was limited to one AFN/SAFI). >=20 >=20 > o Why don't we have a ipv6-unicast module? Because it will be more complicated than ipv4-unicast and I thought it = would be better to leave this task to the 6man WG. However, it the light of the discussion in the other thread, we should = probably reconsider the overall organization of the IP-related data and = define an appropriate scope for our WG. Lada >=20 >=20 >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_6517E8A3-55CE-4E2D-9E49-56EE26D83BB6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE0MTYxNDI1WjAjBgkqhkiG9w0BCQQxFgQUlXBvGrUlos8t7H9rteAnKRsV0eUwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQB2u8UyFKbgXlreJtjynk+d0zRU MwPe0+hynYvSK7n/366PWk5g/u/23ca6rv4E3EXRAalHKxCDEu4yJLAWBtFXH+fDYaG1+SvuikVc l99MGk6h0s+ej9YTCLj+vzEAh+gVr/SnPVMzbCFWqznxsszt5SWWZ1WfKvV52nsSY1uQv1+alKAd 0y1MKin4nYNMKtEKfCtNY+lxeYZ6Tf4c2YQ9pdcFEF2WHzwMXLgaaublNunCxFnSBHEbfxs1fcy7 F05YWORxkJJ4oOaHxMiC63AAUVs0vFKkQNfjJEKCirPRLZOWNZxm9+KBUG5drOQOdFtwNRUXgg0C GoLgcD++/orJAAAAAAAA --Apple-Mail=_6517E8A3-55CE-4E2D-9E49-56EE26D83BB6-- From mbj@tail-f.com Mon Nov 14 09:31:02 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AC411E831B for ; Mon, 14 Nov 2011 09:31:02 -0800 (PST) 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.085, 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 cp7RSjTI7Fif for ; Mon, 14 Nov 2011 09:31:01 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 79EBD11E8301 for ; Mon, 14 Nov 2011 09:31:01 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 11CA51200D02; Mon, 14 Nov 2011 18:30:59 +0100 (CET) Date: Mon, 14 Nov 2011 18:30:58 +0100 (CET) Message-Id: <20111114.183058.323999219.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20111114092228.GB17181@elstar.local> References: <20111110.101401.1354142776762462090.mbj@tail-f.com> <20111114.092348.1957965659644075140.mbj@tail-f.com> <20111114092228.GB17181@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:31:02 -0000 Juergen Schoenwaelder wrote: > On Mon, Nov 14, 2011 at 09:23:48AM +0100, Martin Bjorklund wrote: > > We already know from this ML that some vendors (including myself) will > > provide config true access to parts of the MIBs. (We're using a bunch > > of directives to the compiler to control which parts). As the > > document is written today, the output from my tool is non-compliant, > > but I do not think this is necessary. > > If my tool generates config false but yours does config true, will a > YANG manager not be potentially confused? Both will have the same > revision timestamp. A client can only rely on config false for full interoperability, just like today, I don't want to change that. So if a client that knows a module w/ config false gets a capability with the right namespace and revision, it knows how to from the server, regardless of how many config trues that server is using. /martin From mbj@tail-f.com Mon Nov 14 09:31:47 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED1411E831A for ; Mon, 14 Nov 2011 09:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.077, 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 xfcagwuTXg00 for ; Mon, 14 Nov 2011 09:31:46 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC3911E8301 for ; Mon, 14 Nov 2011 09:31:46 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E369D1200D02; Mon, 14 Nov 2011 18:31:45 +0100 (CET) Date: Mon, 14 Nov 2011 18:31:45 +0100 (CET) Message-Id: <20111114.183145.535139023.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201111141231.pAECVHc4050745@idle.juniper.net> References: <20111114.092348.1957965659644075140.mbj@tail-f.com> <201111141231.pAECVHc4050745@idle.juniper.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:31:47 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >We already know from this ML that some vendors (including myself) will > >provide config true access to parts of the MIBs. (We're using a bunch > >of directives to the compiler to control which parts). As the > >document is written today, the output from my tool is non-compliant, > >but I do not think this is necessary. > > Wouldn't this be a list of deviations that your tool would > generate (read-only as required plus a deviation)? I would have to use deviations if I am not compliant. But I would like to be compliant, even if I have a few config trues in there. /martin From reid@snmp.com Mon Nov 14 09:36:27 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B63E11E81B8 for ; Mon, 14 Nov 2011 09:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 BzfWqfgZJ7BC for ; Mon, 14 Nov 2011 09:36:27 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id C98DE11E8151 for ; Mon, 14 Nov 2011 09:36:26 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA27151; Mon, 14 Nov 2011 12:36:20 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA26175; Mon, 14 Nov 2011 12:36:16 -0500 (EST) Message-Id: <201111141736.MAA26175@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Mon, 14 Nov 2011 09:23:48 +0100. <20111114.092348.1957965659644075140.mbj@tail-f.com> Date: Mon, 14 Nov 2011 12:36:15 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 17:36:27 -0000 > Hi, > > Martin Bjorklund wrote: > > This makes me wonder what the 2119 language tries to convey in this > > document. What does interoperability mean for this spec? The text > > says that it is used for: > > > > enabling read-only access to data objects defined in SMIv2 MIB > > modules via NETCONF > > The document says that all nodes MUST be config false, which is > natural since the interoperability goal is read-only access. But I > think we should allow implementations to mark nodes as config true, in > an implementation dependent manner. This would not affect our > read-only interoperability goal. > > We already know from this ML that some vendors (including myself) will > provide config true access to parts of the MIBs. (We're using a bunch > of directives to the compiler to control which parts). As the > document is written today, the output from my tool is non-compliant, > but I do not think this is necessary. > Our tool also allows config true under some conditions. -David Reid From mbj@tail-f.com Mon Nov 14 09:59:42 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106941F0CE5 for ; Mon, 14 Nov 2011 09:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-999 required=5 tests=[AWL=0.071, 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 e649lI2DpGBC for ; Mon, 14 Nov 2011 09:59:41 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1391F0CCE for ; Mon, 14 Nov 2011 09:59:41 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 76C611200A6E; Mon, 14 Nov 2011 18:59:40 +0100 (CET) Date: Mon, 14 Nov 2011 18:59:39 +0100 (CET) Message-Id: <20111114.185939.427496990.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <5CD9D82F-8C16-47EC-9677-3EED4B6C4E00@cesnet.cz> References: <20111114.135017.268510208816363038.mbj@tail-f.com> <5CD9D82F-8C16-47EC-9677-3EED4B6C4E00@cesnet.cz> 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] comments on draft-ietf-netmod-routing-cfg-01 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, 14 Nov 2011 17:59:42 -0000 Ladislav Lhotka wrote: > On Nov 14, 2011, at 8:50 PM, Martin Bjorklund wrote: > > The way the module is currently written, you should: s/IP/IPv4/ > > Right, although the same will have to be done for IPv6 and potentially other > address families. I'd like to have it generic but I don't think it is possible > in YANG (see also my next comment). I think you can have generic ip, and then let other address families augment with their stuff. > > o Section 4.3 > > > > At least the following two routing tables MUST be configured for each > > router instance: > > > > How is this MUST enforced? How does am operator know which routing > > table is the fib? > > > > Maybe change the routing table to a type union of the two > > enumerations "fib" and "main", and a string? > > It is similar to RFC 4861: We need a conceptual model of the host, > i.e. conceptual objects that behave like "fib" and "main", but we needn't > enforce any naming scheme. Then this needs to be explained. And how does an operator know which one is the fib that is REQUIRED? > > o Section 4.3 > > > > 2. Main routing table to which all routing protocol instances are > > connected by default. > > > > What does "connected by default" really mean? There is nothing in > > the data model about this. > > Yes, it is exactly because the data model cannot pre-populate the list of > routing tables with the entry for "main", which is however required to be > present. An implementation just has to use the main routing table if the > protocol instance doesn't say otherwise. I think this needs to be clarified. > > o Section 4.3 > > > > The naming scheme for routing tables, as well as restrictions on the > > number and configurability of routing tables are implementation- > > specific. > > > > Could you elaborate a bit on the naming scheme and "configurability" > > part? Maybe you mean that a routing table name SHOULD be > > arbitrary, but an implementation MAY impose some restriction on the > > name? > > Implementation A may call its main routing table "main.v4" while > implementation B calls it "inet.0". Also, some implementations may not allow > the user to configure additional tables. Ok. This should be clarified. Will this work, from an interoperability pow? > > o Section 4.5 > > > > The default value for route filter type > > is the identity "deny-all-route-filter" defined in the "ietf-routing" > > module, which represents a route filtering policy in which all routes > > are rejected. > > > > Why is this necessary? Is it common to define filters w/o any type > > and let that mean the deny-all type? I suggest you remove this > > default, and make the type mandatory instead. > > It is not necessary, but at least you get two extreme filtering options at > this stage, without having any real route-filtering framework: either you > don't define any route filter, which means "permit all", or you define one, > which means "reject all". But is the latter so common that it is worth it to have a default value with this function? > > o grouping afn-safi > > > > leaf address-family { > > type ianaaf:address-family; > > default "ipV4"; > > ... > > } > > > > leaf safi { > > type ianaaf:subsequent-address-family; > > default "nlri-unicast"; > > ... > > } > > > > Should we really have these as defaults? Isn't it more clear to > > make these mandatory instead? > > Yes, it is probably "politically incorrect", but in practical terms this > default still makes sense for most users. Defaults are good so that users don't have to configure common values every time. Is this really such a case? > > o grouping route-content > > > > leaf source-protocol { > > type string; > > description > > "The name of the routing protocol instance from which the > > route comes. This routing protocol must be configured > > (automatically or manually) in the device."; > > } > > > > What does "configured automatically" mean? Automatically by whom? > > Instances of "static" and "direct" protocols must be pre-configured in each > router instance. So "automatically" means "configured-by-system". This should be clarified in the description for a router. > > o container connected-routing-tables > > > > list connected-routing-table { > > key "name"; > > description > > "List of routing tables to which the routing protocol > > instance is connected. No more than one routing > > table may be configured for each AFN/SAFI pair. > > Joel's objection to the previous version was that one instance of a protocol > such as BGP may carry routes for multiple address families. So the idea here > is that, e.g., IPv4 routes go to routing table "inet.0" and IPv6 routes to > "inet6.0". Ok. I did not understand that you meant the table that this instance refers to. There MUST NOT be two connected tables with the same "address-family" and "safi" values. Or something. > > o Why don't we have a ipv6-unicast module? > > Because it will be more complicated than ipv4-unicast and I thought it would > be better to leave this task to the 6man WG. > > However, it the light of the discussion in the other thread, we should > probably reconsider the overall organization of the IP-related data and define > an appropriate scope for our WG. Ok. /martin From phil@juniper.net Mon Nov 14 10:30:10 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1028B21F8DB5 for ; Mon, 14 Nov 2011 10:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ZvC9Z+D-+-Ze for ; Mon, 14 Nov 2011 10:30:09 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 51CB521F8DB4 for ; Mon, 14 Nov 2011 10:30:07 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTsFeImcYf0xLJClHK/qOa4lTzKLzmqTc@postini.com; Mon, 14 Nov 2011 10:30:09 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Nov 2011 10:27:46 -0800 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 pAEIRjh56304; Mon, 14 Nov 2011 10:27:45 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id pAEHx9vv052754; Mon, 14 Nov 2011 17:59:10 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201111141759.pAEHx9vv052754@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20111114.183145.535139023.mbj@tail-f.com> Date: Mon, 14 Nov 2011 12:59:09 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 18:30:10 -0000 Martin Bjorklund writes: >I would have to use deviations if I am not compliant. But I would >like to be compliant, even if I have a few config trues in there. So you want "config maybe-if-i-feel-like-it"? I think the spec needs to be one way or the other, so you have some consistency. Clients that are open to treating these as config can use your deviations to find that. All this points out the weakness of not having a clear way to bind operational data to configuration data, which is especially important when the set of possible values are distinct and one can't treat them using deviations like this. We really need a mechanism to say "this knob is the config version of that knob". Otherwise only the description tells me where to find the current link speed for an interface when I say "link-speed auto". Thanks, Phil From andy@netconfcentral.org Mon Nov 14 11:12:27 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4CA11E835E for ; Mon, 14 Nov 2011 11:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z59IBGWDqYOC for ; Mon, 14 Nov 2011 11:12:27 -0800 (PST) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 361C911E835F for ; Mon, 14 Nov 2011 11:12:26 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pAEJCOEP016387 for ; Mon, 14 Nov 2011 14:12:26 -0500 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [122.147.240.7] ([122.147.240.7:21055] helo=[172.22.14.161]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 68/D0-04600-61861CE4; Mon, 14 Nov 2011 14:12:23 -0500 Message-ID: <4EC16815.8010300@netconfcentral.org> Date: Mon, 14 Nov 2011 11:12:21 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Phil Shafer References: <201111141759.pAEHx9vv052754@idle.juniper.net> In-Reply-To: <201111141759.pAEHx9vv052754@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 19:12:27 -0000 On 11/14/2011 09:59 AM, Phil Shafer wrote: > Martin Bjorklund writes: >> I would have to use deviations if I am not compliant. But I would >> like to be compliant, even if I have a few config trues in there. > So you want "config maybe-if-i-feel-like-it"? I think the > spec needs to be one way or the other, so you have some > consistency. Clients that are open to treating these as > config can use your deviations to find that. > > All this points out the weakness of not having a clear way to bind > operational data to configuration data, which is especially important > when the set of possible values are distinct and one can't treat > them using deviations like this. We really need a mechanism to say > "this knob is the config version of that knob". Otherwise only the > description tells me where to find the current link speed for an > interface when I say "link-speed auto". > We have description-stmt for this purpose. There are many different semantic relationships possible between data nodes. A special mechanism for the admin-duplex=auto and oper-duplex=N corner-case is too simplistic. Until a formal language definition is developed, ad-hoc text (i.e., description-stmt) is the only reasonable common solution. IMO, a more interesting operational state problem is 'operational config' -- data nodes set only by the server at runtime to some non-constant value, which must persist with the data node across a reboot (e.g.,. UUID assigned by server). (But this is not a thread on operational data, so back to your original topic...) > Thanks, > Phil Andy From mbj@tail-f.com Mon Nov 14 11:25:30 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6C621F8F25 for ; Mon, 14 Nov 2011 11:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.066, 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 yMFv5k8YtYXE for ; Mon, 14 Nov 2011 11:25:29 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id D7B8921F8F1D for ; Mon, 14 Nov 2011 11:25:23 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 1C4FC1200A6E; Mon, 14 Nov 2011 20:25:23 +0100 (CET) Date: Mon, 14 Nov 2011 20:25:21 +0100 (CET) Message-Id: <20111114.202521.439830822.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201111141759.pAEHx9vv052754@idle.juniper.net> References: <20111114.183145.535139023.mbj@tail-f.com> <201111141759.pAEHx9vv052754@idle.juniper.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 19:25:30 -0000 Phil Shafer wrote: > Martin Bjorklund writes: > >I would have to use deviations if I am not compliant. But I would > >like to be compliant, even if I have a few config trues in there. > > So you want "config maybe-if-i-feel-like-it"? Not at all. I want this translation algorithm to allow implementations to treat some nodes as config. > I think the > spec needs to be one way or the other, so you have some > consistency. Clients that are open to treating these as > config can use your deviations to find that. > > All this points out the weakness of not having a clear way to bind > operational data to configuration data I agree with you on the importance of that, but I think that is a different topic. I would love a solution to this problem; it pops up every now and then, and we don't have a good answer. /martin From phil@juniper.net Mon Nov 14 12:35:05 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA9B1F0CB7 for ; Mon, 14 Nov 2011 12:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 QRRcgIlIH0Pu for ; Mon, 14 Nov 2011 12:35:04 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id D3CC01F0C4A for ; Mon, 14 Nov 2011 12:34:57 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTsF7Y+wUsL1aRHXpzQlUbTtCIg8o0/zM@postini.com; Mon, 14 Nov 2011 12:34:59 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Nov 2011 12:31:34 -0800 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 pAEKVWh17283; Mon, 14 Nov 2011 12:31:33 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id pAEK2vnl053538; Mon, 14 Nov 2011 20:02:58 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201111142002.pAEK2vnl053538@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20111114.202521.439830822.mbj@tail-f.com> Date: Mon, 14 Nov 2011 15:02:57 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 20:35:05 -0000 Martin Bjorklund writes: >I want this translation algorithm to allow implementations to treat >some nodes as config. Maybe I'm lost; I thought you wanted the output of the translation algorithm to be standard, meaning there's no room for implementation differences like this. >I agree with you on the importance of that, but I think that is a >different topic. I would love a solution to this problem; it pops up >every now and then, and we don't have a good answer. The only answer that works IMHO is to have one of the leaf pairs point to the other, like: leaf oper-link-speed { config false; ... } leaf link-speed { config true; config-knob-for ../oper-link-speed; } Using the description for this means hand coding the bindings for each pair, which is just bad news. Thanks, Phil From spakes@snmp.com Mon Nov 14 15:16:34 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793AC1F0C74 for ; Mon, 14 Nov 2011 15:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.375, 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 iDm9sUL60r0y for ; Mon, 14 Nov 2011 15:16:33 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED2A1F0C64 for ; Mon, 14 Nov 2011 15:16:33 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id SAA19929; Mon, 14 Nov 2011 18:16:19 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id SAA04831; Mon, 14 Nov 2011 18:16:14 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 14 Nov 2011 18:16:13 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] 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, 14 Nov 2011 23:16:34 -0000 On Mon, 14 Nov 2011, Juergen Schoenwaelder wrote: > * smi2yang-16: smiv2:oid oid representations [open] > > Modify the description clause of the oid extension to allow a more > user-friendly format. For example, ifEntry could be written as > ifTable.1 instead of 1.3.6.1.2.1.2.2.1, or perhaps just .1 as a > short hand notation. > > ** Solution #16-01 > > extension oid { > argument "value"; > description > "The oid statement takes as an argument the object identifier > assigned to an SMIv2 definition. The object identifier value > is written in dotted decimal notation. If an oid statement > exists for the parent object identifier, then the value may > be written in a short hand notation of the form > . or just > .. For example, the oid value for ifTable from > IF-MIB would be '1.3.6.1.2.1.2.2'. The value for ifEntry could be > '1.3.6.1.2.1.2.2.1', 'ifTable.1', or simply '.1'. Similarily, > ifDescr could be '1.3.6.1.2.1.2.2.1.2', 'ifEntry.2', or '.2'"; > reference > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > } > > ** Solution #16-02 > > This seems mostly important for human writers not for machine > translations. If more notations are needed, these should be > separate aliases so as to allow easy processing of the OID value. > Hence, no change needed wrt. smiv2:oid. Juergen, I believe a third solution was discussed on the mailing list but never formalized. I don't have a strong opinion, but I thought it should be on the list for discussion at the working group meeting. ** Solution #16-03 extension subid { argument "value"; description "The subid statement takes as an argument the most significant sub-identifier of the object identifier assigned to an SMIv2 definition. The sub-identifier value is a single positive decimal whole number. The subid statement may not be used as a substatement to any top-level node in a YANG document. The subid substatement may be used only as a substatement to a node having a parent node defined with either a smiv2:oid or smiv2:subid substatement."; reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; } Here is an example showing the placement of smiv2:subid substatements in a converted document. module IF-MIB { ... container ifTable { config false; description "A list of interface entries. The number of entries is given by the value of ifNumber."; smiv2:oid 1.3.6.1.2.1.2.2; list ifEntry { key "ifIndex"; description "An entry containing management information applicable to a particular interface."; smiv2:subid 1; leaf ifIndex { type if-mib:InterfaceIndex; description "A unique value, greater than zero, for each interface. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization."; smiv2:subid 1; } ... } ... } ... } -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From spakes@snmp.com Mon Nov 14 15:43:03 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7E021F8DF4 for ; Mon, 14 Nov 2011 15:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=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 Nk8fJ-wIsLRU for ; Mon, 14 Nov 2011 15:43:03 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id D9A9B21F8DEF for ; Mon, 14 Nov 2011 15:43:02 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id SAA21212; Mon, 14 Nov 2011 18:43:02 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id SAA05528; Mon, 14 Nov 2011 18:42:57 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 14 Nov 2011 18:42:56 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-18: incomplete well known type mappings [strawman: accept #18-01] 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, 14 Nov 2011 23:43:04 -0000 On Mon, 14 Nov 2011, Juergen Schoenwaelder wrote: > * smi2yang-18: incomplete well known type mappings [strawman: accept #18-01] > > Extend the special type mappings as it seems rather incomplete. > > ** Solution #18-01 > > Add explicit mapping for ZeroBasedCounter* types. They are listed > as having an equivalent type in the YANG world in Table 1 of RFC > 6021. > > Map TruthValue to the YANG boolean. > > ** Solution #18-02 > > Remove all special case type mappings. In RFC 6021, there are two tables of SMIv2-YANG type equivalents. Table 1 is for ietf-yang-types, and Table 2 is for ietf-inet-types. It seems reasonable to me that when converting SMIv2 documents to YANG, all of the equivalent types mentioned in both tables in that RFC should have an expliclit mapping in the ietf-netmod-smi-yang document. In my message to the mailing list on November 9, I provided my "working list" of mappings. Some of those are reflected already in Solution #18-01. Some of those are not reflected in Solution #18-01 and I would not argue that they should be. The following mappings (revised) appear in either Table 1 or Table 2 in RFC 6021, and I propose that they should all be included as part of Solution #18-01. SMIv2 YANG Reference ----- ---- --------- TruthValue boolean RFC 2579 Counter32 yang:counter32 RFC 2578 ZeroBasedCounter32 yang:zero-based-counter32 RFC 4502 Counter64 yang:counter64 RFC 2578 ZeroBasedCounter64 yang:zero-based-counter64 RFC 2856 Gauge32 yang:gauge32 RFC 2578 Gauge yang:gauge32 RFC 1155 CounterBasedGauge64 yang:gauge64 RFC 2856 TimeTicks yang:timeticks RFC 2578 TimeStamp yang:timestamp RFC 2579 PhysAddress yang:phys-address RFC 2579 MacAddress yang:mac-address RFC 2579 InetVersion inet:ip-version RFC 4001 Dscp inet:dscp RFC 3289 IPv6FlowLabel inet:ipv6-flow-label RFC 3595 InetPortNumber inet:port-number RFC 4001 InetAutonomousSystemNumber inet:as-number RFC 4001 Uri inet:uri RFC 5017 -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From spakes@snmp.com Mon Nov 14 16:01:39 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C530421F8E31 for ; Mon, 14 Nov 2011 16:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 tWRWqQZQF2+d for ; Mon, 14 Nov 2011 16:01:39 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id CB78D11E8081 for ; Mon, 14 Nov 2011 16:01:38 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id TAA21812; Mon, 14 Nov 2011 19:01:37 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id TAA05884; Mon, 14 Nov 2011 19:01:37 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 14 Nov 2011 19:01:35 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-20: duplicate objects in INDEXes [strawman: adopt #20-01] 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, 15 Nov 2011 00:01:39 -0000 On Mon, 14 Nov 2011, Juergen Schoenwaelder wrote: > * smi2yang-20: duplicate objects in INDEXes [strawman: adopt #20-01] > > RMON2-MIB (RFC 4502) has an INDEX clause in which the same object > appears twice. Specifically, alHostEntry's INDEX clause uses > protocolDirLocalIndex twice. Following the current conversion rules > results in a translated document that violates the YANG rule that a > leaf identifier MUST NOT appear more than once in the key. > > ** Solution #20-01 > > o The SMIv2 INDEX clause is mapped to the YANG key clause listing > the columnar objects forming the key of the YANG list. If the > same object appears more than once in the INDEX clause, append > '_' to the duplicate object names where '' counts the > occurances of the object in the INDEX clause, starting from 2. > > This would result in > > key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex " > "nlHostAddress protocolDirLocalIndex_2"; The text written to describe Solution #20-01 should include a statement that it is normal and expected for the smiv2:oid (or smiv2:subid) statement generated in YANG document for each '_' object to refer to the same object identifier as the object that it duplicates. By example, in this case both protocolDirLocalIndex and and protocolDirLocalIndex_2 would refer to 1.3.6.1.2.1.16.11.2.1.3. leaf protocolDirLocalIndex { type leafref { path "/rmon2-mib:protocolDirTable/rmon2-mib:protocolDirEntry/rmon2-mib:protocolDirLocalIndex"; } smiv2:oid 1.3.6.1.2.1.16.11.2.1.3; } leaf protocolDirLocalIndex_2 { type leafref { path "/rmon2-mib:protocolDirTable/rmon2-mib:protocolDirEntry/rmon2-mib:protocolDirLocalIndex"; } smiv2:oid 1.3.6.1.2.1.16.11.2.1.3; } -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From spakes@snmp.com Mon Nov 14 16:51:07 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24A711E80A6 for ; Mon, 14 Nov 2011 16:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, 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 fpQk2wKjUbDX for ; Mon, 14 Nov 2011 16:51:06 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 41DD021F8E4C for ; Mon, 14 Nov 2011 16:51:06 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id TAA23771; Mon, 14 Nov 2011 19:50:57 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id TAA07216; Mon, 14 Nov 2011 19:50:52 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 14 Nov 2011 19:50:51 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-14: unflatten scalars [open] 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, 15 Nov 2011 00:51:07 -0000 On Mon, 14 Nov 2011, Juergen Schoenwaelder wrote: > Subject: Re: [netmod] Last Call: draft-ietf-netmod-smi-yang-01 (20110704) ... > > Section 8.1 > > > > "All leaf statements for scalar objects are created in the top-level > > container" > > > > OK -- but I just want to point out that this leads to a model where > > you need to be careful with using filters if you don't want to get > > all data for a module. > > yep - created an open issue for it. On Mon, 14 Nov 2011, Juergen Schoenwaelder wrote: > * smi2yang-14: unflatten scalars [open] > > With the resolution of #01, we ended with having all scalars > registered right below the top-level node. This makes retrieving > just those scalars (often collections of counters) a bit tricky > because the naive approach will also retrieve the tables. > > ** Solution #14-01 > > Ignore this and assume people write proper filters. > > ** Solution #14-02 > > Move all scalars into an artificially created container, so we end > up with: > > foo-mib > +-- scalars > | +-- fooScalar1 > | +-- fooScalar2 > +-- fooTable1 > +-- fooTable2 I _strongly_ dislike Solution #14-02 for SMIv2 documents that group scalar objects together in logical collections by placing them into separate branches of the MIB. I would like to propose another solution in which logical collections are preserved by having a separate top-level container for each of those collections. foo-fum-mib +-- fooScalars | +-- fooScalar1 | +-- fooScalar2 +-- fumScalars | +-- fumScalar1 | +-- fumScalar2 +-- fooTable +-- fumTable The name for each of these top-level containers comes from the parent of the scalar objects in the collection. For example: sysDescr, sysObjectID, sysUpTime, sysContact, sysName, sysLocation, and sysServices shared a common parent, system (RFC 1213); so the name of the container for this logical collection of objects would be system. I understand the difficulty of producing containers in the general case since multiple descriptors may refer to the same OID value (issue #01). I would argue, however, that we can treat the parent node of a logical collection of scalar objects in SMIv2 documents in a way different from the general case, because it would be rare that two descriptors would refer to this particular class of node. Here is the full example for RFC 1213 scalars: RFC1213-MIB +-- system | +-- sysDescr | +-- sysObjectID | +-- sysUpTime | +-- sysContact | +-- sysName | +-- sysLocation | +-- sysServices +-- interfaces | +-- ifNumber +-- ip | +-- ipForwarding | +-- ipDefaultTTL | +-- ipInReceives | +-- ipInHdrErrors | +-- ipInAddrErrors | +-- ipForwDatagrams | +-- ipInUnknownProtos | +-- ipInDiscards | +-- ipInDelivers | +-- ipOutRequests | +-- ipOutDiscards | +-- ipOutNoRoutes | +-- ipReasmTimeout | +-- ipReasmReqds | +-- ipReasmOKs | +-- ipReasmFails | +-- ipFragOKs | +-- ipFragFails | +-- ipFragCreates | +-- ipRoutingDiscards +-- icmp | +-- icmpInMsgs | +-- icmpInErrors | +-- icmpInDestUnreachs | +-- icmpInTimeExcds | +-- icmpInParmProbs | +-- icmpInSrcQuenchs | +-- icmpInRedirects | +-- icmpInEchos | +-- icmpInEchoReps | +-- icmpInTimestamps | +-- icmpInTimestampReps | +-- icmpInAddrMasks | +-- icmpInAddrMaskReps | +-- icmpOutMsgs | +-- icmpOutErrors | +-- icmpOutDestUnreachs | +-- icmpOutTimeExcds | +-- icmpOutParmProbs | +-- icmpOutSrcQuenchs | +-- icmpOutRedirects | +-- icmpOutEchos | +-- icmpOutEchoReps | +-- icmpOutTimestamps | +-- icmpOutTimestampReps | +-- icmpOutAddrMasks | +-- icmpOutAddrMaskReps +-- tcp | +-- tcpRtoAlgorithm | +-- tcpRtoMin | +-- tcpRtoMax | +-- tcpMaxConn | +-- tcpActiveOpens | +-- tcpPassiveOpens | +-- tcpAttemptFails | +-- tcpEstabResets | +-- tcpCurrEstab | +-- tcpInSegs | +-- tcpOutSegs | +-- tcpRetransSegs | +-- tcpInErrs | +-- tcpOutRsts +-- udp | +-- udpInDatagrams | +-- udpNoPorts | +-- udpInErrors | +-- udpOutDatagrams +-- egp | +-- egpInMsgs | +-- egpInErrors | +-- egpOutMsgs | +-- egpOutErrors | +-- egpNeighIntervalHello | +-- egpNeighIntervalPoll | +-- egpNeighMode | +-- egpNeighEventTrigger | +-- egpAs +-- ifTable ... I would hate to see any SMIv2 document that contains a lot of scalar objects divided into logical collections be converted in such a way that the collections are lost. With equal emphasis, I don't like the idea that other levels of containment are created that don't exist in the original SMIv2 document. For one reason, this implies a logical collection that isn't explicitly specified by the original SMIv2 document. (If my suggested solution is not accepted by the working group, then I would prefer Solution #14-01 to any other solution.) Note that if an SMIv2 document defines scalar objects at a layer that is immediately below the MODULE-IDENTITY macro, then the container for this logical collection would have the same name as the MODULE-IDENTITY. This would resemble one of the previous iterations of Solution #14-02 for some SMIv2 documents. Note also that if an SMIv1 document defines scalar objects at the top layer of the module, or if an SMIv2 document defines scalar objects at the top layer of the module (not below the MODULE-IDENTITY), then these objects would not be inside a container in the resulting YANG document. They would exist at the top layer of the YANG document. This resembles Solution #14-01 but only because the converted document retains the absense of a logical collection for these objects, same as in the original document. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From lhotka@cesnet.cz Mon Nov 14 17:49:52 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC4A11E8106 for ; Mon, 14 Nov 2011 17:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 3roZYizWR-pJ for ; Mon, 14 Nov 2011 17:49:51 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDF811E80CC for ; Mon, 14 Nov 2011 17:49:50 -0800 (PST) Received: from dhcp-37d6.meeting.ietf.org (dhcp-37d6.meeting.ietf.org [130.129.55.214]) by office2.cesnet.cz (Postfix) with ESMTPSA id 827B12CDE058; Tue, 15 Nov 2011 02:49:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_CA946187-9B99-4C2B-8244-F24A765DE05E"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111114.185939.427496990.mbj@tail-f.com> Date: Tue, 15 Nov 2011 09:49:42 +0800 Message-Id: <57E5CD92-2D04-482E-B53D-2F258D00EADD@cesnet.cz> References: <20111114.135017.268510208816363038.mbj@tail-f.com> <5CD9D82F-8C16-47EC-9677-3EED4B6C4E00@cesnet.cz> <20111114.185939.427496990.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-01 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, 15 Nov 2011 01:49:52 -0000 --Apple-Mail=_CA946187-9B99-4C2B-8244-F24A765DE05E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 15, 2011, at 1:59 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> On Nov 14, 2011, at 8:50 PM, Martin Bjorklund wrote: >>> The way the module is currently written, you should: s/IP/IPv4/ >>=20 >> Right, although the same will have to be done for IPv6 and = potentially other >> address families. I'd like to have it generic but I don't think it is = possible >> in YANG (see also my next comment). >=20 > I think you can have generic ip, and then let other address families > augment with their stuff. It's possible. I wanted to have it symmetric - one "address" node (in = the corresponding namespace) per AFN/SAFI. >=20 >>> o Section 4.3 >>>=20 >>> At least the following two routing tables MUST be configured for = each >>> router instance: >>>=20 >>> How is this MUST enforced? How does am operator know which routing >>> table is the fib? >>>=20 >>> Maybe change the routing table to a type union of the two >>> enumerations "fib" and "main", and a string? >>=20 >> It is similar to RFC 4861: We need a conceptual model of the host, >> i.e. conceptual objects that behave like "fib" and "main", but we = needn't >> enforce any naming scheme. >=20 > Then this needs to be explained. And how does an operator know which > one is the fib that is REQUIRED? As it is done now: you have to find this info in the manual of every = router OS. One way how to make this more explicit would be to define "fib" and = "main" as separate containers and then have a list of = "extra-routing-tables". But this would break leafrefs that are intended = to point to *any* routing table because leafrefs in YANG cannot specify = alternative paths (which is IMO unfortunate). =20 >=20 >>> o Section 4.3 >>>=20 >>> 2. Main routing table to which all routing protocol instances are >>> connected by default. >>>=20 >>> What does "connected by default" really mean? There is nothing in >>> the data model about this. >>=20 >> Yes, it is exactly because the data model cannot pre-populate the = list of >> routing tables with the entry for "main", which is however required = to be >> present. An implementation just has to use the main routing table if = the >> protocol instance doesn't say otherwise. >=20 > I think this needs to be clarified. OK >=20 >>> o Section 4.3 >>>=20 >>> The naming scheme for routing tables, as well as restrictions on = the >>> number and configurability of routing tables are implementation- >>> specific. >>>=20 >>> Could you elaborate a bit on the naming scheme and "configurability" >>> part? Maybe you mean that a routing table name SHOULD be >>> arbitrary, but an implementation MAY impose some restriction on the >>> name? >>=20 >> Implementation A may call its main routing table "main.v4" while >> implementation B calls it "inet.0". Also, some implementations may = not allow >> the user to configure additional tables. >=20 > Ok. This should be clarified. Will this work, from an > interoperability pow? It depends on what you mean by interoperability. A configuration that = works on one platform may not work on another - but I think we can't = avoid this anyway. Perhaps we can introduce a feature for this, e.g. = "user-defined-routing-tables." >=20 >=20 >>> o Section 4.5 >>>=20 >>> The default value for route filter type >>> is the identity "deny-all-route-filter" defined in the = "ietf-routing" >>> module, which represents a route filtering policy in which all = routes >>> are rejected. >>>=20 >>> Why is this necessary? Is it common to define filters w/o any type >>> and let that mean the deny-all type? I suggest you remove this >>> default, and make the type mandatory instead. >>=20 >> It is not necessary, but at least you get two extreme filtering = options at >> this stage, without having any real route-filtering framework: either = you >> don't define any route filter, which means "permit all", or you = define one, >> which means "reject all". >=20 > But is the latter so common that it is worth it to have a default > value with this function? Since the other extreme - "permit all" - is already available, I think = is is useful to provide the "deny all" behavior. And yes, I think it is = quite common - it is actually used in the example in appendix A.2.=20 >=20 >=20 >>> o grouping afn-safi >>>=20 >>> leaf address-family { >>> type ianaaf:address-family; >>> default "ipV4"; >>> ... >>> } >>>=20 >>> leaf safi { >>> type ianaaf:subsequent-address-family; >>> default "nlri-unicast"; >>> ... >>> } >>>=20 >>> Should we really have these as defaults? Isn't it more clear to >>> make these mandatory instead? >>=20 >> Yes, it is probably "politically incorrect", but in practical terms = this >> default still makes sense for most users. >=20 > Defaults are good so that users don't have to configure common values > every time. Is this really such a case? I think so. >=20 >=20 >>> o grouping route-content >>>=20 >>> leaf source-protocol { >>> type string; >>> description >>> "The name of the routing protocol instance from which the >>> route comes. This routing protocol must be configured >>> (automatically or manually) in the device."; >>> } >>>=20 >>> What does "configured automatically" mean? Automatically by whom? >>=20 >> Instances of "static" and "direct" protocols must be pre-configured = in each >> router instance. So "automatically" means "configured-by-system". >=20 > This should be clarified in the description for a router. OK >=20 >>> o container connected-routing-tables >>>=20 >>> list connected-routing-table { >>> key "name"; >>> description >>> "List of routing tables to which the routing = protocol >>> instance is connected. No more than one routing >>> table may be configured for each AFN/SAFI pair. >>=20 >> Joel's objection to the previous version was that one instance of a = protocol >> such as BGP may carry routes for multiple address families. So the = idea here >> is that, e.g., IPv4 routes go to routing table "inet.0" and IPv6 = routes to >> "inet6.0". >=20 > Ok. I did not understand that you meant the table that this instance > refers to. There MUST NOT be two connected tables with the same > "address-family" and "safi" values. Or something. OK, I will try to make it more clear. Lada >=20 >>> o Why don't we have a ipv6-unicast module? >>=20 >> Because it will be more complicated than ipv4-unicast and I thought = it would >> be better to leave this task to the 6man WG. >>=20 >> However, it the light of the discussion in the other thread, we = should >> probably reconsider the overall organization of the IP-related data = and define >> an appropriate scope for our WG. >=20 > Ok. >=20 >=20 > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_CA946187-9B99-4C2B-8244-F24A765DE05E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE1MDE0OTQyWjAjBgkqhkiG9w0BCQQxFgQUaoRf7EOsTpfEXIeZSeHFD2YbpCgwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQCx4qqkydKI9Vw58EME8gRJCSvi 0PVU8rhGFSGOIayZ9qPTjt9OQ/QJAdkaPdDUEc11pbngSeTDVXFVqDMVTANZ3xgfKc/+ZMkMqTeD nb3lh/Yp1k91Y9TEA/4tncai5lVFsIgAMOa2UYRXJR8vd3tFC5BGsbkKdrkmNP4MclPxxC1xuEcF Fctcpw/qfSoaH4InNPd+NtTXs7A6xRKqWUouB9wv2TEpRQ+K1ENezFMrXzm6rVvqBmjbYrwC+/1s tfCBJmgrT/Z7dOu5Anm4bqykuq8SUCBBToVCIcDwZ0ji605N23bLhsuCNutbCm+Th53xyYHG+niU JUFQi/GVgxTGAAAAAAAA --Apple-Mail=_CA946187-9B99-4C2B-8244-F24A765DE05E-- From j.schoenwaelder@jacobs-university.de Mon Nov 14 18:15:36 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010AA11E82F4 for ; Mon, 14 Nov 2011 18:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.182 X-Spam-Level: X-Spam-Status: No, score=-103.182 tagged_above=-999 required=5 tests=[AWL=0.067, 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 j5Fx2QJATqTy for ; Mon, 14 Nov 2011 18:15:35 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4B30511E830F for ; Mon, 14 Nov 2011 18:15:35 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C3C620CE0; Tue, 15 Nov 2011 03:15:34 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4ny6an7SV-P2; Tue, 15 Nov 2011 03:15:33 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 671F320CDB; Tue, 15 Nov 2011 03:15:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A82491BB49CA; Tue, 15 Nov 2011 03:15:16 +0100 (CET) Date: Tue, 15 Nov 2011 03:15:16 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111115021516.GA19821@elstar.local> Mail-Followup-To: Martin Bjorklund , phil@juniper.net, netmod@ietf.org References: <20111114.183145.535139023.mbj@tail-f.com> <201111141759.pAEHx9vv052754@idle.juniper.net> <20111114.202521.439830822.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114.202521.439830822.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-yang-smiv2 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:15:36 -0000 On Mon, Nov 14, 2011 at 08:25:21PM +0100, Martin Bjorklund wrote: > I want this translation algorithm to allow implementations to treat > some nodes as config. Which one? We are talking about an algorithm so there needs to be an algorithmic answer. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Nov 14 18:32:00 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9373111E808E for ; Mon, 14 Nov 2011 18:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.183 X-Spam-Level: X-Spam-Status: No, score=-103.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 VtsOrxojXK2c for ; Mon, 14 Nov 2011 18:32:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D47B611E8082 for ; Mon, 14 Nov 2011 18:31:59 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3582A20D77; Tue, 15 Nov 2011 03:31:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mI3fvozsGDyd; Tue, 15 Nov 2011 03:31:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A612F20D20; Tue, 15 Nov 2011 03:31:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0B4B71BB4ADD; Tue, 15 Nov 2011 03:31:38 +0100 (CET) Date: Tue, 15 Nov 2011 03:31:38 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20111115023138.GA20066@elstar.local> Mail-Followup-To: David Spakes , 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] smi2yang-14: unflatten scalars [open] 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, 15 Nov 2011 02:32:00 -0000 On Mon, Nov 14, 2011 at 07:50:51PM -0500, David Spakes wrote: > I _strongly_ dislike Solution #14-02 for SMIv2 documents that group > scalar objects together in logical collections by placing them into > separate branches of the MIB. > > I would like to propose another solution in which logical collections > are preserved by having a separate top-level container for each of those > collections. > > foo-fum-mib > +-- fooScalars > | +-- fooScalar1 > | +-- fooScalar2 > +-- fumScalars > | +-- fumScalar1 > | +-- fumScalar2 > +-- fooTable > +-- fumTable > > The name for each of these top-level containers comes from the parent > of the scalar objects in the collection. For example: sysDescr, > sysObjectID, sysUpTime, sysContact, sysName, sysLocation, and > sysServices shared a common parent, system (RFC 1213); so the name of > the container for this logical collection of objects would be system. A clarification question. If I have foo OBJECT IDENTIFIER ::= { here 1 } bar OBJECT IDENTIFIER ::= { here 1 } and a OBJECT-TYPE --...--- ::= { foo 1 } b OBJECT-TYPE --...--- ::= { bar 1 } then I would get foo/a bar/b and we would make the assumption that { foo 1 } would never change to { bar 1 }, although I would believe this is a legal change according to the SMIv2 rules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Nov 14 18:41:03 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049F911E8109 for ; Mon, 14 Nov 2011 18:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.184 X-Spam-Level: X-Spam-Status: No, score=-103.184 tagged_above=-999 required=5 tests=[AWL=0.065, 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 oHh2fetwZETf for ; Mon, 14 Nov 2011 18:41:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5A93311E8132 for ; Mon, 14 Nov 2011 18:41:02 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80B8720D77; Tue, 15 Nov 2011 03:41:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YGxHz3HU7AS0; Tue, 15 Nov 2011 03:41:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0462720CA9; Tue, 15 Nov 2011 03:41:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3C7C61BB4C5D; Tue, 15 Nov 2011 03:40:43 +0100 (CET) Date: Tue, 15 Nov 2011 03:40:43 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20111115024043.GB20119@elstar.local> Mail-Followup-To: David Spakes , 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] smi2yang-16: smiv2:oid oid representations [open] 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, 15 Nov 2011 02:41:03 -0000 On Mon, Nov 14, 2011 at 06:16:13PM -0500, David Spakes wrote: > > I believe a third solution was discussed on the mailing list but never > formalized. I don't have a strong opinion, but I thought it should be > on the list for discussion at the working group meeting. > > > ** Solution #16-03 > > extension subid { > argument "value"; > description > "The subid statement takes as an argument the most significant > sub-identifier of the object identifier assigned to an SMIv2 > definition. The sub-identifier value is a single positive > decimal whole number. The subid statement may not be used > as a substatement to any top-level node in a YANG document. > The subid substatement may be used only as a substatement to a > node having a parent node defined with either a smiv2:oid or > smiv2:subid substatement."; > reference > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > } > > > Here is an example showing the placement of smiv2:subid substatements > in a converted document. > > > module IF-MIB { > ... > container ifTable { > config false; > description > "A list of interface entries. The number of entries is > given by the value of ifNumber."; > smiv2:oid 1.3.6.1.2.1.2.2; > > list ifEntry { > key "ifIndex"; > description > "An entry containing management information applicable to a > particular interface."; > smiv2:subid 1; > > leaf ifIndex { > type if-mib:InterfaceIndex; > description > "A unique value, greater than zero, for each interface. It > is recommended that values are assigned contiguously > starting from 1. The value for each interface sub-layer > must remain constant at least from one re-initialization of > the entity's network management system to the next re- > initialization."; > smiv2:subid 1; > } > ... > } > ... > } > ... > } Clarification question: Is a translator allowed / required / ... to produce both smiv2:oid and smiv2:subid statements? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From david.kessens@nsn.com Mon Nov 14 19:57:53 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C389C1F0C69 for ; Mon, 14 Nov 2011 19:57:53 -0800 (PST) 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 XPukZJevINDo for ; Mon, 14 Nov 2011 19:57:53 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 063DD1F0CA6 for ; Mon, 14 Nov 2011 19:57:52 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAF3vpmO010075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 15 Nov 2011 04:57:51 +0100 Received: from localhost.localdomain ([10.138.49.109]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAF3vnTM020435 for ; Tue, 15 Nov 2011 04:57:50 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.14.5/8.14.5) with ESMTP id pAF3vlXd003964 for ; Mon, 14 Nov 2011 19:57:48 -0800 Received: (from david@localhost) by localhost.localdomain (8.14.5/8.14.5/Submit) id pAF3vi04003963 for netmod@ietf.org; Mon, 14 Nov 2011 19:57:44 -0800 Date: Mon, 14 Nov 2011 19:57:43 -0800 From: David Kessens To: netmod@ietf.org Message-ID: <20111115035743.GF2731@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] Snmp configuration charter addition 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, 15 Nov 2011 03:57:53 -0000 After previous meeting, we discussed a potential addition to our charter for a datamodel for SNMP engine configuration. We didn't converge quickly on an appropriate amendment to our charter and the discussion died down over time. I have reviewed the discussion and would like to propose the following text: 5. Data model for configuring SNMP engines. The model must be capable of representing all meaningful SNMP engine configurations possible with the standard SNMPv3 MIB modules. Any differences in functionality and behavior should be documented. Please let the working group think how you feel about this text, and if you don't agree, propose alternative text that addresses your concerns. David Kessens netmod co-chair --- From randy_presuhn@mindspring.com Mon Nov 14 21:39:29 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE84211E82AB for ; Mon, 14 Nov 2011 21:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.463 X-Spam-Level: X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[AWL=-0.277, 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 n8TE0B-aey7n for ; Mon, 14 Nov 2011 21:38:28 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC0D11E8260 for ; Mon, 14 Nov 2011 21:37:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jhAsMeUDlHWzZbkteC7bVaIUq2jbIcJrPupJchCKALkm0JnNkzd1sLrFvmLloAKo; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.55.240] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RQBhI-0003uW-M7 for netmod@ietf.org; Tue, 15 Nov 2011 00:36:40 -0500 Message-ID: <003901cca358$9f6be680$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20111115035743.GF2731@nsn.com> Date: Mon, 14 Nov 2011 21:36:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0ff5bfc5fcd2fe6357c5e8f19f265b50fe350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.55.240 Subject: Re: [netmod] Snmp configuration charter addition 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, 15 Nov 2011 05:39:46 -0000 Hi - > From: "David Kessens" > To: > Sent: Monday, November 14, 2011 7:57 PM > Subject: [netmod] Snmp configuration charter addition ... > I have reviewed the discussion and would like to propose the > following text: > > 5. Data model for configuring SNMP engines. The model must be capable of > representing all meaningful SNMP engine configurations possible with the > standard SNMPv3 MIB modules. Any differences in functionality and > behavior should be documented. > > Please let the working group think how you feel about this text, and if you > don't agree, propose alternative text that addresses your concerns. I'm still worried about "meaningful." As the discussion on the list revealed, it's not always immediately obvious whether a given legal configuration is meaningful. More importantly, one should take care to not dismiss as "meaningless" a configuration whose utility is not immediately obvious. The i-d which was cited as background for the discussion prohibited as meaningless well-formed configurations which have legitimate uses, thus my concern. Delete the word "meaningful" and I'd be happy with the proposed text. Randy From mbj@tail-f.com Mon Nov 14 23:35:34 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D18911E81EF for ; Mon, 14 Nov 2011 23:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.062, 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 63GYNidyLy0r for ; Mon, 14 Nov 2011 23:35:34 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1381B11E81EE for ; Mon, 14 Nov 2011 23:35:34 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 6DACC1200D02 for ; Tue, 15 Nov 2011 08:35:31 +0100 (CET) Date: Tue, 15 Nov 2011 08:35:29 +0100 (CET) Message-Id: <20111115.083529.380486856.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] smi2yang-11: toplevel node for SMIv1 module 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, 15 Nov 2011 07:35:34 -0000 Hi, This issue is described as: SMIv1 modules do not have a MODULE-IDENTITY node that can be used as the top-level node. The specification does not detail what happens in this case. But the document as written defines a mapping from SMIv2. So the problem is SMIv2 modules w/o a MODULE-IDENTITY, right? Can you explain why solution #11-01 doesn't work? /martin From mbj@tail-f.com Mon Nov 14 23:43:27 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0CC11E80AA for ; Mon, 14 Nov 2011 23:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.058, 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 VPv10G6zIc8x for ; Mon, 14 Nov 2011 23:43:26 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1A11811E8096 for ; Mon, 14 Nov 2011 23:43:17 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id B0C481200D02 for ; Tue, 15 Nov 2011 08:43:15 +0100 (CET) Date: Tue, 15 Nov 2011 08:43:13 +0100 (CET) Message-Id: <20111115.084313.294297055.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [netmod] smi2yang-21: prefix generation 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, 15 Nov 2011 07:43:27 -0000 Hi, I really don't see the problem here. Prefixes are local to the module, and have no external meaning. Any implementation should be free to use whatever prefix genereration algorithm it wants. It is ok if the document specifies an optional prefix genereration algorithm that implementations can use. When section 3 is read today, it is not obvious that the algorithm is optional. I suggest the algorithm is moved to an Appendix to emphasize that it is optional. /martin From mbj@tail-f.com Tue Nov 15 00:25:21 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D3F21F8D23 for ; Tue, 15 Nov 2011 00:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.055, 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 c7F25PXc+tzP for ; Tue, 15 Nov 2011 00:25:20 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B2C8121F8D1F for ; Tue, 15 Nov 2011 00:25:20 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E610912008E8; Tue, 15 Nov 2011 09:25:18 +0100 (CET) Date: Tue, 15 Nov 2011 09:25:17 +0100 (CET) Message-Id: <20111115.092517.458608351.mbj@tail-f.com> To: spakes@snmp.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-14: unflatten scalars [open] 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, 15 Nov 2011 08:25:21 -0000 David Spakes wrote: > I _strongly_ dislike Solution #14-02 for SMIv2 documents that group > scalar objects together in logical collections by placing them into > separate branches of the MIB. > > I would like to propose another solution in which logical collections > are preserved by having a separate top-level container for each of those > collections. I like this solution. The logical groupings from the MIBs are kept; the structure gets better and it helps during retrieval (filtering). However, there are some corner cases that we have to handle (even if "handle" means document bad behaviour). For example, what would the result of this be: fooScalar OBJECT-TYPE .... ::= { foo 1 2 } ? And what happens if, in a new revision, this is changed to: bar OBJECT IDENTIFIER ::= { foo 1 } fooScalar OBJECT-TYPE .... ::= { bar 2 } Would you limit this logical grouping to scalars only, or also put tables there? /martin From j.schoenwaelder@jacobs-university.de Tue Nov 15 00:27:53 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74FD21F8D4A for ; Tue, 15 Nov 2011 00:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.185 X-Spam-Level: X-Spam-Status: No, score=-103.185 tagged_above=-999 required=5 tests=[AWL=0.064, 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 BU5or1-p2lsX for ; Tue, 15 Nov 2011 00:27:53 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C9A2B21F8D47 for ; Tue, 15 Nov 2011 00:27:52 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28D1A20CE9; Tue, 15 Nov 2011 09:27:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aS8w4hZOdyOl; Tue, 15 Nov 2011 09:27:44 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABA9E20CDD; Tue, 15 Nov 2011 09:27:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EFCCD1BB52BC; Tue, 15 Nov 2011 09:27:26 +0100 (CET) Date: Tue, 15 Nov 2011 09:27:26 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20111115082726.GB20789@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <20111115035743.GF2731@nsn.com> <003901cca358$9f6be680$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003901cca358$9f6be680$6b01a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition 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, 15 Nov 2011 08:27:53 -0000 On Mon, Nov 14, 2011 at 09:36:44PM -0800, Randy Presuhn wrote: > > I'm still worried about "meaningful." As the discussion on the list > revealed, it's not always immediately obvious whether a given legal > configuration is meaningful. More importantly, one should take care > to not dismiss as "meaningless" a configuration whose utility is not > immediately obvious. The i-d which was cited as background for the > discussion prohibited as meaningless well-formed configurations > which have legitimate uses, thus my concern. Delete the word > "meaningful" and I'd be happy with the proposed text. I like to know your answer to the following two questions. 1 What about SNMPv1 message processing in combination with the USM security model? You can configure this with the SNMPv3 MIB tables - do you think it is necessary to preserve this capability in the YANG data model? 2 We also have other things like the transport endpoints SNMP engines are listening on for which there are no standardized configuration tables - do you think this should hence be excluded from the YANG data model, even though there is operational experience that this is useful/necessary to configure? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Nov 15 00:40:04 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B26421F8F65 for ; Tue, 15 Nov 2011 00:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 ALDyCoL4vFF2 for ; Tue, 15 Nov 2011 00:40:03 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4647921F8F80 for ; Tue, 15 Nov 2011 00:40:03 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9737D20CC7; Tue, 15 Nov 2011 09:40:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SfGubQ1xgux5; Tue, 15 Nov 2011 09:40:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 473CD20CAD; Tue, 15 Nov 2011 09:40:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8B61C1BB5379; Tue, 15 Nov 2011 09:39:44 +0100 (CET) Date: Tue, 15 Nov 2011 09:39:44 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111115083944.GC20789@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20111115.083529.380486856.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111115.083529.380486856.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-11: toplevel node for SMIv1 module 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, 15 Nov 2011 08:40:04 -0000 On Tue, Nov 15, 2011 at 08:35:29AM +0100, Martin Bjorklund wrote: > This issue is described as: > > SMIv1 modules do not have a MODULE-IDENTITY node that can be used as > the top-level node. The specification does not detail what happens > in this case. > > But the document as written defines a mapping from SMIv2. So the > problem is SMIv2 modules w/o a MODULE-IDENTITY, right? > > Can you explain why solution #11-01 doesn't work? ** Solution #11-01: Use the module name as the top-level node in such cases (this is what libsmi currently does) - but this has an issue if an SMIv1 module gets converted to SMIv2 Consider a MIB module that is being converted from SMIv1 to SMIv2. The YANG modules produced before and after the conversion are going to be different, something I though would be good to avoid. Saying we only do SMIv2 conversion does not really help since SMIv2 modules may import from SMIv1 modules (and there is still stuff importing from good old RFC1213-MIB out there). BTW, RFC1213-MIB is a good example. Note that the translations of sysDescr from RFC1213-MIB and sysDescr from SNMPv2-MIB are going to be different in YANG, even though it is the same thing in SNMP land. /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@cesnet.cz Tue Nov 15 00:45:47 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E7021F8FDE for ; Tue, 15 Nov 2011 00:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 iZQyOez+UiLT for ; Tue, 15 Nov 2011 00:45:47 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id E869121F8FDA for ; Tue, 15 Nov 2011 00:45:46 -0800 (PST) Received: from dhcp-37d6.meeting.ietf.org (dhcp-37d6.meeting.ietf.org [130.129.55.214]) by office2.cesnet.cz (Postfix) with ESMTPSA id 8A5AF2CDE058 for ; Tue, 15 Nov 2011 09:45:44 +0100 (CET) From: Ladislav Lhotka Content-Type: multipart/signed; boundary="Apple-Mail=_D086DC12-0059-4367-B676-1CDB39F33779"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 15 Nov 2011 16:45:31 +0800 Message-Id: <1F4C5B5D-CC80-43A1-AE27-9D0EFBEDD7C1@cesnet.cz> To: netmod@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [netmod] ip-cfg and routing-cfg 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, 15 Nov 2011 08:45:48 -0000 --Apple-Mail=_D086DC12-0059-4367-B676-1CDB39F33779 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, perhaps we could organize the IP and routing data so that: - module "ip-common" implements everything that both hosts and routers = need have, - module "ip-host" implements everything that's required from hosts (in = terms of standards and practical=20 implementation), - module "routing" does the same for routers. So hosts would advertise "ip-common" and "ip-host" while routers would = advertise "ip-common", "routing" and then modules for supported address = families, routing protocols etc. The "ip-common" module would implement, among other things, IPv6 ND. The "ip-host" module would implement, among other things, a single = IP-only routing table, which is what every IP host needs. The "routing" module could remain approximately as it is now, i.e. = support multiple address families, multiple logical routers, multiple = routing tables etc. One thing that definitely has to be added to the "routing" module is a = list of interfaces under each "router" instance specifying which logical = interfaces belong to that "router" instance. This also means that = router-specific interface configuration can be done there rather than = under /if:interfaces. This could for example include configuration of = IPv6 RAs. Lada =20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_D086DC12-0059-4367-B676-1CDB39F33779 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE1MDg0NTMxWjAjBgkqhkiG9w0BCQQxFgQUaUdRhIzL6j7pzhy1iadCrdx/vBEwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQB69J2UpvRbC5Wg1fISJrU/4SQp l/hwVW7qg3xGAV96tYnaat73F+5vemh8S1xC24cB668r6kYZBE2OaWR7tN2vZ5atjIcnLbJGsXVw SItYb/q7M/KE6wIqJqakSA0TkME/e/x1jHYro6et1KrsQVQsci6kmfreS0eueqBXDTcdJrVytrFp D0flCIYcToU76OSAldL6DP4CgdrV7WgfsCnZs0LjSsJoNbaoxk2iPNEauJa72bHH9CSKwZ0TDDf9 ZlQsRnHbb2ny5C1swmkvoNZ2A1Vtjd44LlEKfyv9LJ+601zLKJEYvBpxzA9kOz2pXIlU+YzYgCxU kbfkg0YNN6x4AAAAAAAA --Apple-Mail=_D086DC12-0059-4367-B676-1CDB39F33779-- From mbj@tail-f.com Tue Nov 15 00:46:51 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AC621F8FF5 for ; Tue, 15 Nov 2011 00:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.052, 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 L7RupinHjcYc for ; Tue, 15 Nov 2011 00:46:50 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 649BE21F8FF0 for ; Tue, 15 Nov 2011 00:46:50 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E493912008E8; Tue, 15 Nov 2011 09:46:47 +0100 (CET) Date: Tue, 15 Nov 2011 09:46:45 +0100 (CET) Message-Id: <20111115.094645.274154273.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20111115083944.GC20789@elstar.local> References: <20111115.083529.380486856.mbj@tail-f.com> <20111115083944.GC20789@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-11: toplevel node for SMIv1 module 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, 15 Nov 2011 08:46:51 -0000 Juergen Schoenwaelder wrote: > On Tue, Nov 15, 2011 at 08:35:29AM +0100, Martin Bjorklund wrote: > > > This issue is described as: > > > > SMIv1 modules do not have a MODULE-IDENTITY node that can be used as > > the top-level node. The specification does not detail what happens > > in this case. > > > > But the document as written defines a mapping from SMIv2. So the > > problem is SMIv2 modules w/o a MODULE-IDENTITY, right? > > > > Can you explain why solution #11-01 doesn't work? > > ** Solution #11-01: > > Use the module name as the top-level node in such cases (this is > what libsmi currently does) - but this has an issue if an SMIv1 > module gets converted to SMIv2 > > Consider a MIB module that is being converted from SMIv1 to SMIv2. > The YANG modules produced before and after the conversion are going to > be different, something I though would be good to avoid. Do you mean that they would be different b/c a MODULE-IDENTITY is added in the process of converting from SMIv1 to SMIv2? > Saying we only do SMIv2 conversion does not really help since SMIv2 > modules may import from SMIv1 modules (and there is still stuff > importing from good old RFC1213-MIB out there). Don't we need to update the document to explicitly say that it also handles SMIv1? > BTW, RFC1213-MIB is a good example. Note that the translations of > sysDescr from RFC1213-MIB and sysDescr from SNMPv2-MIB are going to be > different in YANG, even though it is the same thing in SNMP land. I'm not sure what this is a good example of...? It seems to be orthogonal to SMIv1 vs. SMIv2 - this can happen also if objects in one SMIv2 module are moved to some other module, right? /martin From j.schoenwaelder@jacobs-university.de Tue Nov 15 00:55:43 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F5521F9015 for ; Tue, 15 Nov 2011 00:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 UVtpfuNLWP0A for ; Tue, 15 Nov 2011 00:55:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0306D21F9014 for ; Tue, 15 Nov 2011 00:55:42 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5439220C96; Tue, 15 Nov 2011 09:55:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id S9otZL4BmlCM; Tue, 15 Nov 2011 09:55:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1B1F20C7D; Tue, 15 Nov 2011 09:55:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9A9B81BB559C; Tue, 15 Nov 2011 09:55:22 +0100 (CET) Date: Tue, 15 Nov 2011 09:55:22 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111115085522.GA21031@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20111115.083529.380486856.mbj@tail-f.com> <20111115083944.GC20789@elstar.local> <20111115.094645.274154273.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111115.094645.274154273.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-11: toplevel node for SMIv1 module 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, 15 Nov 2011 08:55:43 -0000 On Tue, Nov 15, 2011 at 09:46:45AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Nov 15, 2011 at 08:35:29AM +0100, Martin Bjorklund wrote: > > > > > This issue is described as: > > > > > > SMIv1 modules do not have a MODULE-IDENTITY node that can be used as > > > the top-level node. The specification does not detail what happens > > > in this case. > > > > > > But the document as written defines a mapping from SMIv2. So the > > > problem is SMIv2 modules w/o a MODULE-IDENTITY, right? > > > > > > Can you explain why solution #11-01 doesn't work? > > > > ** Solution #11-01: > > > > Use the module name as the top-level node in such cases (this is > > what libsmi currently does) - but this has an issue if an SMIv1 > > module gets converted to SMIv2 > > > > Consider a MIB module that is being converted from SMIv1 to SMIv2. > > The YANG modules produced before and after the conversion are going to > > be different, something I though would be good to avoid. > > Do you mean that they would be different b/c a MODULE-IDENTITY is > added in the process of converting from SMIv1 to SMIv2? Yes. > > Saying we only do SMIv2 conversion does not really help since SMIv2 > > modules may import from SMIv1 modules (and there is still stuff > > importing from good old RFC1213-MIB out there). > > Don't we need to update the document to explicitly say that it also > handles SMIv1? If we do not rely on the MODULE-IDENTITY for the top-level, we are fine with what David recently suggested: SMIv1 modules may be converted to YANG by first following the rules in ^RFC3584^ to convert the SMIv1 module to SMIv2, then following the rules in this document to convert to YANG. > > BTW, RFC1213-MIB is a good example. Note that the translations of > > sysDescr from RFC1213-MIB and sysDescr from SNMPv2-MIB are going to be > > different in YANG, even though it is the same thing in SNMP land. > > I'm not sure what this is a good example of...? It seems to be > orthogonal to SMIv1 vs. SMIv2 - this can happen also if objects in one > SMIv2 module are moved to some other module, right? Yep. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Nov 15 01:03:57 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB8221F8FA8 for ; Tue, 15 Nov 2011 01:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 NK-ylBHwc1uz for ; Tue, 15 Nov 2011 01:03:53 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDE021F8E72 for ; Tue, 15 Nov 2011 01:03:53 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 898A720CB3; Tue, 15 Nov 2011 10:03:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id G6ZFzM3INDat; Tue, 15 Nov 2011 10:03:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 53E2020CB4; Tue, 15 Nov 2011 10:03:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 975C41BB5640; Tue, 15 Nov 2011 10:03:34 +0100 (CET) Date: Tue, 15 Nov 2011 10:03:34 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111115090334.GB21031@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20111115.084313.294297055.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111115.084313.294297055.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-21: prefix generation 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, 15 Nov 2011 09:03:58 -0000 On Tue, Nov 15, 2011 at 08:43:13AM +0100, Martin Bjorklund wrote: > Hi, > > I really don't see the problem here. Prefixes are local to the > module, and have no external meaning. Any implementation should be > free to use whatever prefix genereration algorithm it wants. It is ok > if the document specifies an optional prefix genereration algorithm > that implementations can use. When section 3 is read today, it is not > obvious that the algorithm is optional. I suggest the algorithm is > moved to an Appendix to emphasize that it is optional. > I have added this as Solution #21-03. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From reid@snmp.com Tue Nov 15 09:17:23 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CF511E8083 for ; Tue, 15 Nov 2011 09:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 sc2tIqs1uABH for ; Tue, 15 Nov 2011 09:17:22 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABC511E8082 for ; Tue, 15 Nov 2011 09:17:19 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA12211; Tue, 15 Nov 2011 12:17:11 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA18392; Tue, 15 Nov 2011 12:17:08 -0500 (EST) Message-Id: <201111151717.MAA18392@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Tue, 15 Nov 2011 03:40:43 +0100. <20111115024043.GB20119@elstar.local> Date: Tue, 15 Nov 2011 12:17:08 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 17:17:23 -0000 > On Mon, Nov 14, 2011 at 06:16:13PM -0500, David Spakes wrote: > > > > I believe a third solution was discussed on the mailing list but never > > formalized. I don't have a strong opinion, but I thought it should be > > on the list for discussion at the working group meeting. > > > > > > ** Solution #16-03 > > > > extension subid { > > argument "value"; > > description > > "The subid statement takes as an argument the most significant > > sub-identifier of the object identifier assigned to an SMIv2 > > definition. The sub-identifier value is a single positive > > decimal whole number. The subid statement may not be used > > as a substatement to any top-level node in a YANG document. > > The subid substatement may be used only as a substatement to a > > node having a parent node defined with either a smiv2:oid or > > smiv2:subid substatement."; > > reference > > "RFC2578: Structure of Management Information Version 2 (SMIv2)"; > > } > > > > > > Here is an example showing the placement of smiv2:subid substatements > > in a converted document. > > > > > > module IF-MIB { > > ... > > container ifTable { > > config false; > > description > > "A list of interface entries. The number of entries is > > given by the value of ifNumber."; > > smiv2:oid 1.3.6.1.2.1.2.2; > > > > list ifEntry { > > key "ifIndex"; > > description > > "An entry containing management information applicable to a > > particular interface."; > > smiv2:subid 1; > > > > leaf ifIndex { > > type if-mib:InterfaceIndex; > > description > > "A unique value, greater than zero, for each interface. It > > is recommended that values are assigned contiguously > > starting from 1. The value for each interface sub-layer > > must remain constant at least from one re-initialization of > > the entity's network management system to the next re- > > initialization."; > > smiv2:subid 1; > > } > > ... > > } > > ... > > } > > ... > > } > > Clarification question: Is a translator allowed / required / ... to produce both > smiv2:oid and smiv2:subid statements? The point was to make it easier for the human reader and writer. Requiring both would make it harder, so I don't think that would be the right answer. -David Reid From randy_presuhn@mindspring.com Tue Nov 15 11:18:46 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EE521F8906 for ; Tue, 15 Nov 2011 11:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8qfToSFpHmo for ; Tue, 15 Nov 2011 11:18:45 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 40B0D21F888A for ; Tue, 15 Nov 2011 11:18:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=VeUqb9aSQjQei8v5TX4gaAU8OuPmPBtsv4M9C7bpDuKz4+JoC+TSOhCEDqAVU06h; 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.41.49.97] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RQOWo-0001M3-Cc for netmod@ietf.org; Tue, 15 Nov 2011 14:18:42 -0500 Message-ID: <002c01cca3cb$857f41e0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20111115035743.GF2731@nsn.com> <003901cca358$9f6be680$6b01a8c0@oemcomputer> <20111115082726.GB20789@elstar.local> Date: Tue, 15 Nov 2011 11:19:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f678c6501b66276cc9a87fce9aff4c165350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.97 Subject: Re: [netmod] Snmp configuration charter addition 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, 15 Nov 2011 19:18:46 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, November 15, 2011 12:27 AM > Subject: Re: [netmod] Snmp configuration charter addition > > On Mon, Nov 14, 2011 at 09:36:44PM -0800, Randy Presuhn wrote: > > > > I'm still worried about "meaningful." As the discussion on the list > > revealed, it's not always immediately obvious whether a given legal > > configuration is meaningful. More importantly, one should take care > > to not dismiss as "meaningless" a configuration whose utility is not > > immediately obvious. The i-d which was cited as background for the > > discussion prohibited as meaningless well-formed configurations > > which have legitimate uses, thus my concern. Delete the word > > "meaningful" and I'd be happy with the proposed text. > > I like to know your answer to the following two questions. > > 1 What about SNMPv1 message processing in combination with the USM > security model? You can configure this with the SNMPv3 MIB tables - > do you think it is necessary to preserve this capability in the YANG > data model? Yes, but it's only needed for the products that permit such pathological things. (My concern was that the I-D prohibted things that were not pathological at all, but were in fact well-defined and common operational practice.) Wes has already commented on the (deplorable, in some cases) semantics associated with such pathological configurations, but the reality is that they exist. I think the YANG modelers need to figure out for themselves how/whether they want to account for the differences in what various products allow. If the decision is to exclude certain vendors' products from being supported by the Yang models, it needs to be a conscious decision by the WG. This problem is hardly specific to SNMP engine configuration. The point is that the YANG model needs to permit everything that any product would allow. But I'm less concerned about the philosophical debate than the more fundamental problem that the YANG model in the I-D prohibits things are in fact well-defined and common operational practice. > 2 We also have other things like the transport endpoints SNMP engines > are listening on for which there are no standardized configuration > tables - do you think this should hence be excluded from the YANG > data model, even though there is operational experience that this is > useful/necessary to configure? This is indeed useful stuff. I'd love to have a MIB module for it, too. Having it only accesible via Netconf would just be pathological. Randy From spakes@snmp.com Tue Nov 15 11:53:18 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF5B21F899D for ; Tue, 15 Nov 2011 11:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NefY+V1qjNF for ; Tue, 15 Nov 2011 11:53:14 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 75B4221F88A0 for ; Tue, 15 Nov 2011 11:53:03 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA23774; Tue, 15 Nov 2011 14:52:53 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA21904; Tue, 15 Nov 2011 14:52:52 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Tue, 15 Nov 2011 14:52:52 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] 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, 15 Nov 2011 19:53:19 -0000 On Mon, 14 Nov 2011, David Spakes wrote: > Subject : Re: smi2yang-14: unflatten scalars [open] > > I would like to propose another solution in which logical collections > are preserved by having a separate top-level container for each of those > collections. > > foo-fum-mib > +-- fooScalars > | +-- fooScalar1 > | +-- fooScalar2 > +-- fumScalars > | +-- fumScalar1 > | +-- fumScalar2 > +-- fooTable > +-- fumTable On Tue, 15 Nov 2011, Juergen Schoenwaelder wrote: > Clarification question: Is a translator allowed / required / ... to > produce both smiv2:oid and smiv2:subid statements? > > /js Juergen, If my proposed solution to unflatten scalars (smi2yang-14) is adopted so the logical collections from the MIB are preserved, then here are the usage rules I propose for oid and subid statements. extension oid 1) MUST be used in the first level of containment within the module. For example, in augments, top-level containers, notifications, and alias. 2) SHOULD NOT be used below the first level of containment within a module, except in the following cases: a) to specify the object identifier for leaf objects defined within notifications b) as a substatement to an alias extension subid 1) MUST NOT be used above the second level of containment within a module. 2) MUST be used at every level below the first level of containment within a module to determine the object identifier for every scalar object and columnar object translated from the SMIv2 module, not including objects defined within a notification. I would also change the description of the extension alias as follows. For an example of the new form, take a look at the substatements of the augment statement in the example below. extension alias { argument "descriptor" description "The alias statement introduces an SMIv2 descriptor. If the alias statement appears at the top level within a module, the body of the alias statement is expected to contain an oid statement that provides the numeric OID associated with the descriptor. Otherwise, the numeric OID is determined by the adjacent oid statement or by the adjacent subid statement taken with parental oid/subid statements."; reference "RFC2578: Structure of Management Information Version 2 (SMIv2)"; } This conversion of IF-MIB to YANG demonstrates the oid, subid, and both forms of the alias statement... container interfaces { config false; smiv2:oid "1.3.6.1.2.1.2"; leaf ifNumber { type int32; description "The number of network interfaces (regardless of their current state) present on this system."; smiv2:subid 1; } } container ifMIBObjects { config false; smiv2:oid "1.3.6.1.2.1.31.1"; leaf ifTableLastChange { type yang:timeticks; description "The value of sysUpTime at the time of the last creation or deletion of an entry in the ifTable. If the number of entries has been unchanged since the last re-initialization of the local network management subsystem, then this object contains a zero value."; smiv2:subid 5; } leaf ifStackLastChange { type yang:timeticks; description "The value of sysUpTime at the time of the last change of the (whole) interface stack. A change of the interface stack is defined to be any creation, deletion, or change in value of any instance of ifStackStatus. If the interface stack has been unchanged since the last re-initialization of the local network management subsystem, then this object contains a zero value."; smiv2:subid 6; } } ... container ifTable { config false; description "A list of interface entries. The number of entries is given by the value of ifNumber."; smiv2:oid "1.3.6.1.2.1.2.2"; list ifEntry { key "ifIndex"; description "An entry containing management information applicable to a particular interface."; smiv2:subid 1; leaf ifIndex { type if-mib:InterfaceIndex; description "A unique value, greater than zero, for each interface. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization."; smiv2:subid 1; } ... } } ... smiv2:alias ifXTable { description "A list of interface entries. The number of entries is given by the value of ifNumber. This table contains additional objects for the interface table."; smiv2:oid "1.3.6.1.2.1.31.1.1"; } augment "/if-mib:ifTable/if-mib:ifEntry" { smiv2:alias ifXEntry; description "An entry containing additional management information applicable to a particular interface."; smiv2:oid "1.3.6.1.2.1.31.1.1.1"; leaf ifName { type snmpv2-tc:DisplayString; description "The textual name of the interface. The value of this object should be the name of the interface as assigned by the local device and should be suitable for use in commands entered at the device's `console'. This might be a text name, such as `le0' or a simple port number, such as `1', depending on the interface naming syntax of the device. If several entries in the ifTable together represent a single interface as named by the device, then each will have the same value of ifName. Note that for an agent which responds to SNMP queries concerning an interface on some other (proxied) device, then the value of ifName for such an interface is the proxied device's local name for it. If there is no local name, or this object is otherwise not applicable, then this object contains a zero-length string."; smiv2:subid 1; } ... } ... notification linkDown { smiv2:oid "1.3.6.1.6.3.1.1.5.3"; description "A linkDown trap signifies that the SNMP entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links is about to enter the down state from some other state (but not from the notPresent state). This other state is indicated by the included value of ifOperStatus."; container object-1 { leaf ifIndex { type leafref { path /ifTable/ifEntry/ifIndex; } smiv2:oid "1.3.6.1.2.1.2.2.1.1"; } } container object-2 { leaf ifIndex { type leafref { path /ifTable/ifEntry/ifIndex; } smiv2:oid "1.3.6.1.2.1.2.2.1.1"; } leaf ifAdminStatus { type leafref { path /ifTable/ifEntry/ifAdminStatus; } smiv2:oid "1.3.6.1.2.1.2.2.1.7"; } } container object-3 { leaf ifIndex { type leafref { path /ifTable/ifEntry/ifIndex; } smiv2:oid "1.3.6.1.2.1.2.2.1.1"; } leaf ifOperStatus { type leafref { path /ifTable/ifEntry/ifOperStatus; } smiv2:oid "1.3.6.1.2.1.2.2.1.8"; } } } -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From spakes@snmp.com Tue Nov 15 12:12:41 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A48B21F867F for ; Tue, 15 Nov 2011 12:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 PsGDwXuoq3PP for ; Tue, 15 Nov 2011 12:12:37 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 35C6921F858C for ; Tue, 15 Nov 2011 12:12:37 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA25446; Tue, 15 Nov 2011 15:12:28 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA22486; Tue, 15 Nov 2011 15:12:21 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Tue, 15 Nov 2011 15:12:21 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Martin Bjorklund In-Reply-To: <20111115.092517.458608351.mbj@tail-f.com> Message-ID: References: <20111115.092517.458608351.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-14: unflatten scalars [open] 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, 15 Nov 2011 20:12:41 -0000 On Tue, 15 Nov 2011, Martin Bjorklund wrote: > Would you limit this logical grouping to scalars only, or also put > tables there? Martin, I would keep the tables at the top level. The result is elegant. Everything that appears at the top level except notifications represents a logical collection of objects that is reflected in the object identifiers. 1. container with scalars (a logical collection of scalar objects) The object identifier for each scalar object is equal to the smiv2:oid of the container + "." + smiv2:subid of the object. 2. container with a list (a logical collection of columnar objects) The object identifier for the list is equal to the smiv2:oid of the container + "." + smiv2:subid of the list. The object identifier for each columnar object is equal to the smiv2:oid of the container + "." + smiv2:subid of the list + "." + smiv2:subid of the object. 3. augment (a logical collection of columnar objects) The object identifier for each columnar object is equal to the smiv2:oid of the augment + "." + smiv2:subid of the object. Each notification also has a logical collection of objects, but this collection is not reflected in the object identifiers. Therefore, the object identifier for each object in the collection (whether scalar or tabular) must be specified explicitly using smiv2:oid. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From mbj@tail-f.com Tue Nov 15 12:26:19 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB2D1F0C8B for ; Tue, 15 Nov 2011 12:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.044, 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 hooVMgKt5uoJ for ; Tue, 15 Nov 2011 12:26:18 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 69A2D1F0C79 for ; Tue, 15 Nov 2011 12:26:18 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id DA3C21200D02; Tue, 15 Nov 2011 21:26:16 +0100 (CET) Date: Tue, 15 Nov 2011 21:26:16 +0100 (CET) Message-Id: <20111115.212616.488625234.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <002c01cca3cb$857f41e0$6b01a8c0@oemcomputer> References: <003901cca358$9f6be680$6b01a8c0@oemcomputer> <20111115082726.GB20789@elstar.local> <002c01cca3cb$857f41e0$6b01a8c0@oemcomputer> 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] Snmp configuration charter addition 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, 15 Nov 2011 20:26:19 -0000 Hi, "Randy Presuhn" wrote: > If the decision is to exclude certain > vendors' products from being supported by the Yang models, it > needs to be a conscious decision by the WG. The question is, in this case and in other cases, what we put in the standard module. Vendors can always add to the standard model, if the standard model cannot express everything their product supports. > This problem is hardly specific to SNMP engine configuration. The point > is that the YANG model needs to permit everything that any product > would allow. I disagree (in the general case). The standard YANG model does not have to be (should not be) the union of every conceivable parameter vendors can come up with. > But I'm less concerned about the philosophical debate than the more > fundamental problem that the YANG model in the I-D prohibits things > are in fact well-defined and common operational practice. > > > 2 We also have other things like the transport endpoints SNMP engines > > are listening on for which there are no standardized configuration > > tables - do you think this should hence be excluded from the YANG > > data model, even though there is operational experience that this is > > useful/necessary to configure? > > This is indeed useful stuff. I'd love to have a MIB module for it, too. > Having it only accesible via Netconf would just be pathological. Do you believe this in general? Do you think that for every YANG model we produce, we also need a MIB module for the same thing, otherwise we should not do the YANG model? /martin From spakes@snmp.com Tue Nov 15 12:43:05 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5631F0C42 for ; Tue, 15 Nov 2011 12:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 5MgpcLcwilMn for ; Tue, 15 Nov 2011 12:43:01 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5638C1F0C76 for ; Tue, 15 Nov 2011 12:43:01 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA27450; Tue, 15 Nov 2011 15:42:52 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA23178; Tue, 15 Nov 2011 15:42:47 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Tue, 15 Nov 2011 15:42:47 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Martin Bjorklund In-Reply-To: Message-ID: References: <20111115.092517.458608351.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-14: unflatten scalars [open] 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, 15 Nov 2011 20:43:05 -0000 On Tue, 15 Nov 2011, David Spakes wrote: > Everything that appears at the top level except notifications > represents a logical collection of objects that is reflected in > the object identifiers. As soon as I sent the e-mail, I thought of one exception to my statement above. A table can have an external index, and the object identifier does not reflect its inclusion in the logical collection. For example, in module RMON2-MIB, the list serialConfigEntry has the external index ifIndex, and the object identifier would need to be specified using an smiv2:oid statement... container serialConfigTable { config false; description "A table of serial interface configuration entries. This data will be stored in non-volatile memory and preserved across probe resets or power loss. This table has been deprecated, as it has not had enough independent implementations to demonstrate interoperability to meet the requirements of a Draft Standard."; smiv2:oid "1.3.6.1.2.1.16.19.10"; list serialConfigEntry { key "ifIndex"; status deprecated; description "A set of configuration parameters for a particular serial interface on this device. If the device has no serial interfaces, this table is empty. The index is composed of the ifIndex assigned to this serial line interface."; smiv2:subid 1; leaf ifIndex { type leafref { path "/if-mib:ifTable/if-mib:ifEntry/if-mib:ifIndex"; } smiv2:oid "1.3.6.1.2.1.2.2.1.1"; } ... } } ... So I must revise the usage rules as follows: extension oid 1) MUST be used in the first level of containment within the module. For example, in augments, top-level containers, notifications, and alias. 2) SHOULD NOT be used below the first level of containment within a module, except in the following cases: a) to specify the object identifier for key objects of type leafref defined within lists b) to specify the object identifier for leaf objects defined within notifications c) as a substatement to an alias extension subid 1) MUST NOT be used above the second level of containment within a module. 2) MUST be used at every level below the first level of containment within a module to determine the object identifier for every scalar object and columnar object translated from the SMIv2 module, not including objects defined within a notification and key objects of type leafref defined within a list. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From reid@snmp.com Tue Nov 15 12:43:52 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38AC1F0C9B for ; Tue, 15 Nov 2011 12:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Uns+ypN5kOkW for ; Tue, 15 Nov 2011 12:43:52 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3766F1F0C42 for ; Tue, 15 Nov 2011 12:43:52 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA27748 for ; Tue, 15 Nov 2011 15:43:51 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA23217 for ; Tue, 15 Nov 2011 15:43:51 -0500 (EST) Message-Id: <201111152043.PAA23217@adminfs.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Tue, 15 Nov 2011 08:43:13 +0100. <20111115.084313.294297055.mbj@tail-f.com> Date: Tue, 15 Nov 2011 15:43:50 -0500 Sender: reid@snmp.com Subject: Re: [netmod] smi2yang-21: prefix generation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 20:43:52 -0000 > Hi, > > I really don't see the problem here. Prefixes are local to the > module, and have no external meaning. Any implementation should be > free to use whatever prefix genereration algorithm it wants. It is ok > if the document specifies an optional prefix genereration algorithm > that implementations can use. When section 3 is read today, it is not > obvious that the algorithm is optional. I suggest the algorithm is > moved to an Appendix to emphasize that it is optional. I like Martin's suggestion. -David Reid From randy_presuhn@mindspring.com Tue Nov 15 13:13:49 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090AC1F0C50 for ; Tue, 15 Nov 2011 13:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXwrA1Z6avlr for ; Tue, 15 Nov 2011 13:13:48 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7F321F8ACE for ; Tue, 15 Nov 2011 13:13:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZBIYpVQ/GvdY/CZ+5pTXXhtBvpfc3YGHv/nAf1Lvc36DnDQJbqnju7ejHc6zVDax; 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.41.49.97] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RQQK6-0002HD-4u for netmod@ietf.org; Tue, 15 Nov 2011 16:13:42 -0500 Message-ID: <000c01cca3db$9589c0a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <003901cca358$9f6be680$6b01a8c0@oemcomputer><20111115082726.GB20789@elstar.local><002c01cca3cb$857f41e0$6b01a8c0@oemcomputer> <20111115.212616.488625234.mbj@tail-f.com> Date: Tue, 15 Nov 2011 13:14:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f57083b7f0401d979e034bd7b32acacaa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.49.97 Subject: Re: [netmod] Snmp configuration charter addition 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, 15 Nov 2011 21:13:49 -0000 Hi - > From: "Martin Bjorklund" ... > Do you believe this in general? Do you think that for every YANG > model we produce, we also need a MIB module for the same thing, > otherwise we should not do the YANG model? In the particular context of this discussion on the problem of configuring SNMP engines, to add configuration elements without ensuring that they are also accessible via SNMP seems dysfunctional at best. The ironic deficiences of the MIB models for configuring SNMP engines are tied up in history (a little) and politics (a lot). I don't think it's helpful to try to turn whatever way the group does (or does not) deal with these peculiarities into any sort of general principle. At the risk of going into a discussion that won't bring this thread to a conclusion, I think we need to remember an important distinction: - Using different protocols and / or data models to manage the same information model - Having multiple information models with intersecting semantics, ie., hooks into the same instrumentation This work seems to be being driven in the latter direction. That seems ironic to me, because one of the "selling points" of this work seemed to have been its ability to document / work with whatever models vendors had already implemented, rather than just procrustean MIBs. Randy From lhotka@cesnet.cz Tue Nov 15 18:18:30 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B53921F8E3A for ; Tue, 15 Nov 2011 18:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDVLduzVA8tH for ; Tue, 15 Nov 2011 18:18:29 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 6031621F8E37 for ; Tue, 15 Nov 2011 18:18:29 -0800 (PST) Received: from [IPv6:2001:df8::48:e474:1cf4:54a5:ec9c] (unknown [IPv6:2001:df8:0:48:e474:1cf4:54a5:ec9c]) by office2.cesnet.cz (Postfix) with ESMTPSA id 2F67D2CDE05B for ; Wed, 16 Nov 2011 03:18:26 +0100 (CET) From: Ladislav Lhotka Content-Type: multipart/signed; boundary="Apple-Mail=_1ADB9C2B-D176-49EF-9BC1-CB58877B3DC1"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 16 Nov 2011 10:18:24 +0800 Message-Id: To: netmod@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [netmod] augment 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, 16 Nov 2011 02:18:30 -0000 --Apple-Mail=_1ADB9C2B-D176-49EF-9BC1-CB58877B3DC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, before adding more revision complexity, how can we resolve the following = situation? Module A imports B in revision X and augments some of its nodes. Then, a = server advertises in hello module A and B in revision Y. Does it mean that the augments won't be applied? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_1ADB9C2B-D176-49EF-9BC1-CB58877B3DC1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE2MDIxODI0WjAjBgkqhkiG9w0BCQQxFgQUGqefPbV//Lucmli3lif+mP0IZMgwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQCE5BRsBjYlPMXKDyWD+71bnXb8 2K8QssO2NGFA00h/cQq+hcVldQK4TXun+e3Xq4lCTOqxNxNuF2OVpz1ua/7Fiyn4OQrNSaYHizjs Y9497ACO4JqeJLCEipjkSu2lgU1+l+e8o+Qjg9XT56fLgoltnV33SXweaRK2QUCYZTem+lUg1JbI Cf9CT+V+aQqiseIzkxO4czC/vwBphmmi+2cNTuWOiNeE/t1L+EonjqzKFJbaM3YXVFBy6ICu3/uY cnnY3oMRFkiG1rWtbU+QokqTp1rorv9PzHXh4xbtZr+W5d+v/cgrOrqRHJO1WhQtBzXjofCDk8yC f9XnwJydWKkQAAAAAAAA --Apple-Mail=_1ADB9C2B-D176-49EF-9BC1-CB58877B3DC1-- From mbj@tail-f.com Wed Nov 16 00:38:00 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD5B21F94AF for ; Wed, 16 Nov 2011 00:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuzeoPyCvqhs for ; Wed, 16 Nov 2011 00:38:00 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 22DD421F94AE for ; Wed, 16 Nov 2011 00:37:59 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id F2F541200D46; Wed, 16 Nov 2011 09:37:57 +0100 (CET) Date: Wed, 16 Nov 2011 09:37:56 +0100 (CET) Message-Id: <20111116.093756.937437369800237340.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: References: 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] augment 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, 16 Nov 2011 08:38:00 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > before adding more revision complexity, how can we resolve the > following situation? > > Module A imports B in revision X and augments some of its nodes. Then, > a server advertises in hello module A and B in revision Y. I think this is illegal. The server is supposed to advertise all modules it implements. If it faithfully implements A, it follows that it also implements B in revision X. Thus it must also advertise B in revision X. /martin From lhotka@cesnet.cz Wed Nov 16 00:59:21 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333DF21F94E1 for ; Wed, 16 Nov 2011 00:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 0Uyp+C+U1KmI for ; Wed, 16 Nov 2011 00:59:20 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 5E71321F94D7 for ; Wed, 16 Nov 2011 00:59:20 -0800 (PST) Received: from dhcp-403d.meeting.ietf.org (dhcp-403d.meeting.ietf.org [130.129.64.61]) by office2.cesnet.cz (Postfix) with ESMTPSA id 89DAC2CDE05C; Wed, 16 Nov 2011 09:59:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_F7683BE1-E4AE-4FFA-9DB4-7000BE46E4E6"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111116.093756.937437369800237340.mbj@tail-f.com> Date: Wed, 16 Nov 2011 16:59:08 +0800 Message-Id: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> References: <20111116.093756.937437369800237340.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] augment 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, 16 Nov 2011 08:59:21 -0000 --Apple-Mail=_F7683BE1-E4AE-4FFA-9DB4-7000BE46E4E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 16, 2011, at 4:37 PM, Martin Bjorklund wrote: > Hi, >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> before adding more revision complexity, how can we resolve the >> following situation? >>=20 >> Module A imports B in revision X and augments some of its nodes. = Then, >> a server advertises in hello module A and B in revision Y. >=20 > I think this is illegal. The server is supposed to advertise all > modules it implements. If it faithfully implements A, it follows that > it also implements B in revision X. Thus it must also advertise B in > revision X. Well, but it can happen quite easily: Module A fixes a bug, so a server = developer upgrades to the new version without realizing that module A = also "upgraded" the import of B. If you have several dozen = interconnected modules, this would be pretty difficult to spot. How about the same situation where module A doesn't augment anything, = just uses B's groupings and typedefs.=20 So potentially different revisions of groupings/typedefs are used in A = and in B. Would this be legal? If hello advertised submodules with revisions, we'd have a similar = situation: what if hello advertises a submodule revision that is = different from the revision included by the main module?=20 In all cases, the problem is the same: certain parts of the data model = are specified in two places, so inconsistencies may occur. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_F7683BE1-E4AE-4FFA-9DB4-7000BE46E4E6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE2MDg1OTA5WjAjBgkqhkiG9w0BCQQxFgQUbXpdDiM6Bb7WEl//FItwoh2l6rcwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQBA3+wAfQ7mGKA2SAaSBK1gWPew RoTfEqhh6eCuDc5x9GpVrHKcPaPf6Jb/Trc/gPl9kns2pCIOTPdQ+8QRAF9pOMAfUqfkkcKPA7jG N4HCq/uGEYiIgrkYAy2UWn3bKK0yInktwBv3vQowj3Tp1mhX59NKSX8/CUbTK1tubGaUUhEhIceR imNlyeHZY0qgvWjhNscaeUKJ71lA7f6mvB1YHitKP6zlsaJdBag5jQ7Iwfb1wvCcmTN4lyk0hrS6 WmmTbvhvEORP5azgdyQmrkVzaeH9dOS8/OOLzyonkRawnTz8U3w7uvb3rwKDFaZlthlyPnugNRpQ 4EbTQOEmoDocAAAAAAAA --Apple-Mail=_F7683BE1-E4AE-4FFA-9DB4-7000BE46E4E6-- From mbj@tail-f.com Wed Nov 16 01:10:07 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0AD21F9414 for ; Wed, 16 Nov 2011 01:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AKlxeavbeb4 for ; Wed, 16 Nov 2011 01:10:06 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 344CD21F94FC for ; Wed, 16 Nov 2011 01:09:46 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 5EC1F12008E8; Wed, 16 Nov 2011 10:09:45 +0100 (CET) Date: Wed, 16 Nov 2011 10:09:44 +0100 (CET) Message-Id: <20111116.100944.915335040424530675.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> References: <20111116.093756.937437369800237340.mbj@tail-f.com> <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> 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] augment 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, 16 Nov 2011 09:10:08 -0000 Ladislav Lhotka wrote: > > On Nov 16, 2011, at 4:37 PM, Martin Bjorklund wrote: > > > Hi, > > > > Ladislav Lhotka wrote: > >> Hi, > >> > >> before adding more revision complexity, how can we resolve the > >> following situation? > >> > >> Module A imports B in revision X and augments some of its nodes. Then, > >> a server advertises in hello module A and B in revision Y. > > > > I think this is illegal. The server is supposed to advertise all > > modules it implements. If it faithfully implements A, it follows that > > it also implements B in revision X. Thus it must also advertise B in > > revision X. > > Well, but it can happen quite easily: Module A fixes a bug, so a > server developer upgrades to the new version without realizing that > module A also "upgraded" the import of B. If you have several dozen > interconnected modules, this would be pretty difficult to spot. If it is illegal it is illegal. If you're using a tool like yuma or confd, this can't happen. If you roll your own message you have to make sure you follow the spec. > How about the same situation where module A doesn't augment anything, > just uses B's groupings and typedefs. > So potentially different revisions of groupings/typedefs are used in A > and in B. Would this be legal? Sure. > If hello advertised submodules with revisions, we'd have a similar > situation: what if hello advertises a submodule revision that is > different from the revision included by the main module? I think this should be illegal. In fact, I don't think the server should have to advertise a submodule that is included by revision. /martin From lhotka@cesnet.cz Wed Nov 16 01:43:24 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B9421F8F29 for ; Wed, 16 Nov 2011 01:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 HZRU08IhOCsn for ; Wed, 16 Nov 2011 01:43:24 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 65FC521F95DB for ; Wed, 16 Nov 2011 01:43:23 -0800 (PST) Received: from dhcp-403d.meeting.ietf.org (dhcp-403d.meeting.ietf.org [130.129.64.61]) by office2.cesnet.cz (Postfix) with ESMTPSA id 4A50B2CDE05B; Wed, 16 Nov 2011 10:43:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_2832C985-D8E7-47AC-A711-0BD5E2D4D463"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111116.100944.915335040424530675.mbj@tail-f.com> Date: Wed, 16 Nov 2011 17:43:16 +0800 Message-Id: <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> References: <20111116.093756.937437369800237340.mbj@tail-f.com> <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] augment 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, 16 Nov 2011 09:43:24 -0000 --Apple-Mail=_2832C985-D8E7-47AC-A711-0BD5E2D4D463 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 16, 2011, at 5:09 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Nov 16, 2011, at 4:37 PM, Martin Bjorklund wrote: >>=20 >>> Hi, >>>=20 >>> Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> before adding more revision complexity, how can we resolve the >>>> following situation? >>>>=20 >>>> Module A imports B in revision X and augments some of its nodes. = Then, >>>> a server advertises in hello module A and B in revision Y. >>>=20 >>> I think this is illegal. The server is supposed to advertise all >>> modules it implements. If it faithfully implements A, it follows = that >>> it also implements B in revision X. Thus it must also advertise B = in >>> revision X. >>=20 >> Well, but it can happen quite easily: Module A fixes a bug, so a >> server developer upgrades to the new version without realizing that >> module A also "upgraded" the import of B. If you have several dozen >> interconnected modules, this would be pretty difficult to spot. >=20 > If it is illegal it is illegal. If you're using a tool like yuma or > confd, this can't happen. If you roll your own message you > have to make sure you follow the spec. OK. In fact, my recent extension to pyang allows to submit a hello = message, so it could be checked there, too. But what would you actually = check? It cannot simply be that module A imports a different revision of = B than is the one advertised in hello. >=20 >> How about the same situation where module A doesn't augment anything, >> just uses B's groupings and typedefs. >> So potentially different revisions of groupings/typedefs are used in = A >> and in B. Would this be legal? >=20 > Sure. Hmm, this could lead to really nasty surprises. Imagine that = B=3Dietf-interfaces and its data tree is changed in revision X so that = the path in the definition of "interface-ref" changes. Then this path = must be broken in either A or B/Y, which together form the data model = advertised in hello. >=20 >> If hello advertised submodules with revisions, we'd have a similar >> situation: what if hello advertises a submodule revision that is >> different from the revision included by the main module? >=20 > I think this should be illegal. In fact, I don't think the server > should have to advertise a submodule that is included by revision. Isn't it then simpler to always include by revision? Lada >=20 >=20 > /martin >=20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_2832C985-D8E7-47AC-A711-0BD5E2D4D463 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE2MDk0MzE2WjAjBgkqhkiG9w0BCQQxFgQUUPzvmquQ4l/Kb8gBIWL3/VKTedQwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQC2Baj3j/1TCPLlAFLirJWsGBvf wAOipSm6lSoJEVvxPgXsMUzxlRunCIXiLYwFFzG6nG338r72yIOfHmjsns9Y+dSAfQvX+qp12qDl IExEqat8jdpdWjrGRW8qMaobhFsZtgAYH8TtfPzoL24/cA8sGrTYpoDYzyzbGahaB2gn1SDbu3OT PYNU+fmdGmPcoQ7hwfqZDrEinD3a9FUpqEHVExhavGNEchqUgM8pfSMj+ttrCur6z9Q8x7V1+4g4 JVlw063zI49/FMAyosdMJyiMq2KXheE/cH3AYv1XZFHfmg1HpdwPlr9NfBgVTgdabdY5Y7cKE5hq BQ8nkt8x57GLAAAAAAAA --Apple-Mail=_2832C985-D8E7-47AC-A711-0BD5E2D4D463-- From mbj@tail-f.com Wed Nov 16 01:56:24 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AA421F9629 for ; Wed, 16 Nov 2011 01:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TApHWtKBI6BF for ; Wed, 16 Nov 2011 01:56:24 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E8CC121F9628 for ; Wed, 16 Nov 2011 01:56:23 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 09E2212003C3; Wed, 16 Nov 2011 10:56:23 +0100 (CET) Date: Wed, 16 Nov 2011 10:56:21 +0100 (CET) Message-Id: <20111116.105621.987975290957079602.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> References: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> 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] augment 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, 16 Nov 2011 09:56:24 -0000 Ladislav Lhotka wrote: > >> If hello advertised submodules with revisions, we'd have a similar > >> situation: what if hello advertises a submodule revision that is > >> different from the revision included by the main module? > > > > I think this should be illegal. In fact, I don't think the server > > should have to advertise a submodule that is included by revision. > > Isn't it then simpler to always include by revision? This goes back to my question if advertising submodule revisions is the correct solution. So, the problem we are trying to solve is that you want to have separate pieces of a data model for one namespace, each piece individually versioned. Today, using submodules to solve this won't work, b/c if you use include by revision, you can't mix these pieces in arbitrary ways, and if you don't use include by revision, you don't know which versions the server implements. Also, using modules won't work, since each module is tied to one unique namespace. One solution to this problem is to advertise submodule revisions. Another solution to this problem is what Kent suggested; use modules, which already are versioned and advertised individually, but allow multiple modules to share the same namespace. /martin From andy@netconfcentral.org Wed Nov 16 02:30:06 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC6921F954A for ; Wed, 16 Nov 2011 02:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AQKvahZACxp for ; Wed, 16 Nov 2011 02:30:06 -0800 (PST) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9E89D21F9554 for ; Wed, 16 Nov 2011 02:30:05 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id pAGAU4Zp032587 for ; Wed, 16 Nov 2011 05:30:04 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [130.129.21.221] ([130.129.21.221:42584] helo=[130.129.21.221]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id EE/23-03697-BA093CE4; Wed, 16 Nov 2011 05:30:04 -0500 Message-ID: <4EC390A9.9070304@netconfcentral.org> Date: Wed, 16 Nov 2011 02:30:01 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Martin Bjorklund References: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> <20111116.105621.987975290957079602.mbj@tail-f.com> In-Reply-To: <20111116.105621.987975290957079602.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] augment 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, 16 Nov 2011 10:30:06 -0000 On 11/16/2011 01:56 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>>> If hello advertised submodules with revisions, we'd have a similar >>>> situation: what if hello advertises a submodule revision that is >>>> different from the revision included by the main module? >>> I think this should be illegal. In fact, I don't think the server >>> should have to advertise a submodule that is included by revision. >> Isn't it then simpler to always include by revision? > This goes back to my question if advertising submodule revisions is > the correct solution. > > So, the problem we are trying to solve is that you want to have > separate pieces of a data model for one namespace, each piece > individually versioned. > > Today, using submodules to solve this won't work, b/c if you use > include by revision, you can't mix these pieces in arbitrary ways, and > if you don't use include by revision, you don't know which versions > the server implements. > > Also, using modules won't work, since each module is tied to one > unique namespace. > > > One solution to this problem is to advertise submodule revisions. > > Another solution to this problem is what Kent suggested; use modules, > which already are versioned and advertised individually, but allow > multiple modules to share the same namespace. We don't have any control over what vendors use -- just the IETF. IMO, submodules are not very usable because there is only 1 revision for the entire module. I do not agree that we have a problem with too many XML namespaces. I do not understand why this would make the YANG documents more or less readable. I do not care about people reading raw XML off the wire. That is not an important use-case. It is not difficult to read XML that uses namespaces. I find the current NETMOD ip and snmp-cfg drafts hard to read because there is 5X the boilerplate overhead and I have to jump back and forth between submodules constantly to read them. > > /martin Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From lhotka@cesnet.cz Wed Nov 16 03:01:41 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5597B21F961C for ; Wed, 16 Nov 2011 03:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.018, 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 kR+-gcD5D4fE for ; Wed, 16 Nov 2011 03:01:40 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 8478F21F9618 for ; Wed, 16 Nov 2011 03:01:40 -0800 (PST) Received: from dhcp-403d.meeting.ietf.org (dhcp-403d.meeting.ietf.org [130.129.64.61]) by office2.cesnet.cz (Postfix) with ESMTPSA id 4B3212CDE05B; Wed, 16 Nov 2011 12:01:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_1CB83E33-1A2D-4100-9097-DA100A8D86D6"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111116.105621.987975290957079602.mbj@tail-f.com> Date: Wed, 16 Nov 2011 19:01:25 +0800 Message-Id: <7E6027CB-E160-4CA4-9D28-9D8866DF048C@cesnet.cz> References: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> <20111116.105621.987975290957079602.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] augment 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, 16 Nov 2011 11:01:41 -0000 --Apple-Mail=_1CB83E33-1A2D-4100-9097-DA100A8D86D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 16, 2011, at 5:56 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>>> If hello advertised submodules with revisions, we'd have a similar >>>> situation: what if hello advertises a submodule revision that is >>>> different from the revision included by the main module? >>>=20 >>> I think this should be illegal. In fact, I don't think the server >>> should have to advertise a submodule that is included by revision. >>=20 >> Isn't it then simpler to always include by revision? >=20 > This goes back to my question if advertising submodule revisions is > the correct solution. >=20 > So, the problem we are trying to solve is that you want to have > separate pieces of a data model for one namespace, each piece > individually versioned. >=20 > Today, using submodules to solve this won't work, b/c if you use > include by revision, you can't mix these pieces in arbitrary ways, and > if you don't use include by revision, you don't know which versions > the server implements. >=20 > Also, using modules won't work, since each module is tied to one > unique namespace. In accord with Andy, I don't see the number of namespaces as a threat to = readability. >=20 >=20 > One solution to this problem is to advertise submodule revisions. >=20 > Another solution to this problem is what Kent suggested; use modules, > which already are versioned and advertised individually, but allow > multiple modules to share the same namespace. Both solutions go in the direction of using module names and revisions = as de facto namespace discriminators, which is OK but makes me wonder = why we bother with XML namespaces at all. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_1CB83E33-1A2D-4100-9097-DA100A8D86D6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE2MTEwMTI1WjAjBgkqhkiG9w0BCQQxFgQUi6eNmVCL8j7MYV41Yb+RrxGzf/swXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQAEDJ7LuxVkXtSMUS9bShiQYo3V BRI+33EOW15QB0KprQPNY0UdpEDX5KxWBkDJweFl4t/k01VxhBAWlMZ8pOoSMNwlmjgNFySp/gFY 56nYQ61Idj44lXWkp1HhxRADvT5jxnttAoRbaz0HURNGoiDFDAVs11gYv7I1Gqt36q11wXq6vnzy 9Nd8QfbLxwtIKL//K40vxEGTRsP1Xdbb2iay9D8uhVa2bDETUlz4wk9MgRA6RuH5GgyF//TbwNtd XP8Jn8+EwJFHv4f1+KGVs/ZIDTFvSKFnEcz82Qq4R1D3zBlGMnuZhfkO/oUibMdPOiASZfoByOsq pvHyoE5428QyAAAAAAAA --Apple-Mail=_1CB83E33-1A2D-4100-9097-DA100A8D86D6-- From j.schoenwaelder@jacobs-university.de Wed Nov 16 04:54:37 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BC621F9510 for ; Wed, 16 Nov 2011 04:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, 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 j6oaXyXz9lQa for ; Wed, 16 Nov 2011 04:54:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 76F2521F950D for ; Wed, 16 Nov 2011 04:54:36 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAC3420D53; Wed, 16 Nov 2011 13:54:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vEtNgkhzwMpp; Wed, 16 Nov 2011 13:54:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4A55620D22; Wed, 16 Nov 2011 13:54:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EB8791BB6DC0; Wed, 16 Nov 2011 13:54:16 +0100 (CET) Date: Wed, 16 Nov 2011 13:54:15 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20111116125414.GA23292@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> <20111116.105621.987975290957079602.mbj@tail-f.com> <7E6027CB-E160-4CA4-9D28-9D8866DF048C@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E6027CB-E160-4CA4-9D28-9D8866DF048C@cesnet.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] augment by revision 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, 16 Nov 2011 12:54:37 -0000 On Wed, Nov 16, 2011 at 07:01:25PM +0800, Ladislav Lhotka wrote: > > On Nov 16, 2011, at 5:56 PM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >>>> If hello advertised submodules with revisions, we'd have a similar > >>>> situation: what if hello advertises a submodule revision that is > >>>> different from the revision included by the main module? > >>> > >>> I think this should be illegal. In fact, I don't think the server > >>> should have to advertise a submodule that is included by revision. > >> > >> Isn't it then simpler to always include by revision? > > > > This goes back to my question if advertising submodule revisions is > > the correct solution. > > > > So, the problem we are trying to solve is that you want to have > > separate pieces of a data model for one namespace, each piece > > individually versioned. > > > > Today, using submodules to solve this won't work, b/c if you use > > include by revision, you can't mix these pieces in arbitrary ways, and > > if you don't use include by revision, you don't know which versions > > the server implements. > > > > Also, using modules won't work, since each module is tied to one > > unique namespace. > > In accord with Andy, I don't see the number of namespaces as a threat to readability. > I disagree. Complexity is bad. And if can avoid it, we do make life simpler. And this is in particular true for organizations like the IETF were refactoring is hard to impossible and work is sliced into pieces according to procedural aspects and learning processes. I know, all this is debatable. But the argument "you just have to have the right tools" does not convince given the experience in SNMP where the MIB browser still is a common interface. That said, let me bring up technical arguments. ;-) Here is a simple task: Write an filter that retrieves all NETCONF configuration objects from the various modules we have in the pipeline. Compare that to a filter if everything would be in a shared namespace. I believe there is a big value in being able to retrieve everything beloning to function X with a simple filter without having to know whether the IETF did split this in 10 or 20 separate modules. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Wed Nov 16 05:37:45 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1612121F9682 for ; Wed, 16 Nov 2011 05:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD4PZ6yQ83s4 for ; Wed, 16 Nov 2011 05:37:44 -0800 (PST) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1B61021F9680 for ; Wed, 16 Nov 2011 05:37:44 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id pAGDbcE0026303 for ; Wed, 16 Nov 2011 08:37:40 -0500 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [122.147.240.7] ([122.147.240.7:60092] helo=[172.22.14.161]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 0A/C0-04600-0ACB3CE4; Wed, 16 Nov 2011 08:37:38 -0500 Message-ID: <4EC3BC9F.3020502@netconfcentral.org> Date: Wed, 16 Nov 2011 05:37:35 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> <20111116.105621.987975290957079602.mbj@tail-f.com> <7E6027CB-E160-4CA4-9D28-9D8866DF048C@cesnet.cz> <20111116125414.GA23292@elstar.local> In-Reply-To: <20111116125414.GA23292@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] augment 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, 16 Nov 2011 13:37:45 -0000 On 11/16/2011 04:54 AM, Juergen Schoenwaelder wrote: > On Wed, Nov 16, 2011 at 07:01:25PM +0800, Ladislav Lhotka wrote: >> On Nov 16, 2011, at 5:56 PM, Martin Bjorklund wrote: >> >>> Ladislav Lhotka wrote: >>>>>> If hello advertised submodules with revisions, we'd have a similar >>>>>> situation: what if hello advertises a submodule revision that is >>>>>> different from the revision included by the main module? >>>>> I think this should be illegal. In fact, I don't think the server >>>>> should have to advertise a submodule that is included by revision. >>>> Isn't it then simpler to always include by revision? >>> This goes back to my question if advertising submodule revisions is >>> the correct solution. >>> >>> So, the problem we are trying to solve is that you want to have >>> separate pieces of a data model for one namespace, each piece >>> individually versioned. >>> >>> Today, using submodules to solve this won't work, b/c if you use >>> include by revision, you can't mix these pieces in arbitrary ways, and >>> if you don't use include by revision, you don't know which versions >>> the server implements. >>> >>> Also, using modules won't work, since each module is tied to one >>> unique namespace. >> In accord with Andy, I don't see the number of namespaces as a threat to readability. >> > I disagree. Complexity is bad. And if can avoid it, we do make life > simpler. And this is in particular true for organizations like the > IETF were refactoring is hard to impossible and work is sliced into > pieces according to procedural aspects and learning processes. I know, > all this is debatable. But the argument "you just have to have the > right tools" does not convince given the experience in SNMP where the > MIB browser still is a common interface. > > That said, let me bring up technical arguments. ;-) Here is a simple > task: Write an filter that retrieves all NETCONF > configuration objects from the various modules we have in the > pipeline. Compare that to a filter if everything would be in a shared > namespace. > > I believe there is a big value in being able to retrieve everything > beloning to function X with a simple filter without having to know > whether the IETF did split this in 10 or 20 separate modules. > NETCONF does not have any filtering by a specific XML namespace. RFC 6241 added a subtree wildcard mechanism that matches any namespace. Simply requesting the top-level node will return all descendants, regardless of namespace. In my experience, browsers like firefox have no problem at all displaying XML with namespaces. IMO, submodules increase complexity since they reduce readability and their revisions are not advertised in the . It is also difficult to follow submodules back to their parent revision, since the belongs-to-stmt has no revision-date, and include-by-revision is optional-to-use. > /js > Andy From lhotka@cesnet.cz Wed Nov 16 06:21:17 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F82E21F94B6 for ; Wed, 16 Nov 2011 06:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 j7TOEGSuZYjS for ; Wed, 16 Nov 2011 06:21:16 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 3772721F94B1 for ; Wed, 16 Nov 2011 06:21:16 -0800 (PST) Received: from dhcp-403d.meeting.ietf.org (dhcp-403d.meeting.ietf.org [130.129.64.61]) by office2.cesnet.cz (Postfix) with ESMTPSA id 3E5FD2CDE05B; Wed, 16 Nov 2011 15:21:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_A0752704-68DE-441E-B14D-115900DBD6A3"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111116125414.GA23292@elstar.local> Date: Wed, 16 Nov 2011 22:21:07 +0800 Message-Id: References: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> <20111116.105621.987975290957079602.mbj@tail-f.com> <7E6027CB-E160-4CA4-9D28-9D8866DF048C@cesnet.cz> <20111116125414.GA23292@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] augment 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, 16 Nov 2011 14:21:17 -0000 --Apple-Mail=_A0752704-68DE-441E-B14D-115900DBD6A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 16, 2011, at 8:54 PM, Juergen Schoenwaelder wrote: > On Wed, Nov 16, 2011 at 07:01:25PM +0800, Ladislav Lhotka wrote: >>=20 >> On Nov 16, 2011, at 5:56 PM, Martin Bjorklund wrote: >>=20 >>> Ladislav Lhotka wrote: >>>>>> If hello advertised submodules with revisions, we'd have a = similar >>>>>> situation: what if hello advertises a submodule revision that is >>>>>> different from the revision included by the main module? >>>>>=20 >>>>> I think this should be illegal. In fact, I don't think the server >>>>> should have to advertise a submodule that is included by revision. >>>>=20 >>>> Isn't it then simpler to always include by revision? >>>=20 >>> This goes back to my question if advertising submodule revisions is >>> the correct solution. >>>=20 >>> So, the problem we are trying to solve is that you want to have >>> separate pieces of a data model for one namespace, each piece >>> individually versioned. >>>=20 >>> Today, using submodules to solve this won't work, b/c if you use >>> include by revision, you can't mix these pieces in arbitrary ways, = and >>> if you don't use include by revision, you don't know which versions >>> the server implements. >>>=20 >>> Also, using modules won't work, since each module is tied to one >>> unique namespace. >>=20 >> In accord with Andy, I don't see the number of namespaces as a threat = to readability. >>=20 >=20 > I disagree. Complexity is bad. And if can avoid it, we do make life > simpler. And this is in particular true for organizations like the > IETF were refactoring is hard to impossible and work is sliced into > pieces according to procedural aspects and learning processes. I know, > all this is debatable. But the argument "you just have to have the > right tools" does not convince given the experience in SNMP where the > MIB browser still is a common interface. I don't think XML namespaces by themselves increase complexity, they are = just a general solution to a real problem. Their main drawback is in the = disconnect between the NS URI and the prefix but this doesn't apply to = YANG, because we have the URI and prefix neatly defined in one place and = both are IANA-registered for IETF modules. IMO the complexity stems from the fact that we have several overlapping = parameters that define the meaning of names: - module name - prefix - namespace URI - revision date And also that they may occur both in YANG modules, instance documents = and hello messages. I can imagine a scheme where node names have no XML namespace at all, = for example =85 And something like this would equally well work e.g. in JSON (hence, = JETCONF:-). But it is too late for this. > =20 >=20 > That said, let me bring up technical arguments. ;-) Here is a simple > task: Write an filter that retrieves all NETCONF > configuration objects from the various modules we have in the > pipeline. Compare that to a filter if everything would be in a shared > namespace. >=20 > I believe there is a big value in being able to retrieve everything > beloning to function X with a simple filter without having to know > whether the IETF did split this in 10 or 20 separate modules. This rather suggests that NETCONF subtree filtering is lame and not fit = for its purpose. Such a task is a piece of cake for XPath/XSLT. 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, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_A0752704-68DE-441E-B14D-115900DBD6A3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE2MTQyMTA4WjAjBgkqhkiG9w0BCQQxFgQUEfo5RlndE8Q1OHzm2nerY5pE4OowXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQBxoSXk7nIeZavRmlCsKTHGTlWa iIgSHuf1tkTka4tullOqjIZKT+WJg8wEDFJZ5Y1aC4bOR5Oa0FdGiUYoy7YRPUlpBZwVmBR3j4cV bP3pVM0WCwfrjNFOkpR4XnY6I3i4bEJ0jsLvkp9dS3TboRwUBZi6JlwAhj3Abwz0n3Jm0ltl3s91 lNqNVDIq2vQZsADDNaHJPCffs3Iu8KzASkOc7ztEI1NCgaLsWQHvDnPoHBCNoqGkBPdfLibs//1s iLA9ZGoO+YsebyMzJ4ryw/dEvG/GyRUpDf7vod5aQnSUE6LRXzSzyQjLhKwyLRwHG64Pm3rKk3sS 7lFquE9PtI54AAAAAAAA --Apple-Mail=_A0752704-68DE-441E-B14D-115900DBD6A3-- From j.schoenwaelder@jacobs-university.de Wed Nov 16 06:26:18 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF61421F952C for ; Wed, 16 Nov 2011 06:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 vN+WMkPABhXp for ; Wed, 16 Nov 2011 06:26:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E6CA121F950D for ; Wed, 16 Nov 2011 06:26:17 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 459A220D56; Wed, 16 Nov 2011 15:26:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Sloervgyo0Dd; Wed, 16 Nov 2011 15:26:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD6E920D1A; Wed, 16 Nov 2011 15:26:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 81B9E1BB7095; Wed, 16 Nov 2011 15:25:58 +0100 (CET) Date: Wed, 16 Nov 2011 15:25:57 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20111116142557.GA23589@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org References: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> <20111116.105621.987975290957079602.mbj@tail-f.com> <7E6027CB-E160-4CA4-9D28-9D8866DF048C@cesnet.cz> <20111116125414.GA23292@elstar.local> <4EC3BC9F.3020502@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC3BC9F.3020502@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] augment by revision 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, 16 Nov 2011 14:26:18 -0000 On Wed, Nov 16, 2011 at 05:37:35AM -0800, Andy Bierman wrote: > NETCONF does not have any filtering by a specific XML namespace. > RFC 6241 added a subtree wildcard mechanism that matches any namespace. > Simply requesting the top-level node will return all descendants, regardless > of namespace. Is this also true for xpath expressions? BTW, what is the common toplevel in the case of NETCONF data models? ;-) > In my experience, browsers like firefox have no problem > at all displaying XML with namespaces. Nobody said browsers would be a problem. I am talking about simplicity at the human interface - having to recall or lookup that some feature that got added to protocol X two years later sits in a different namespace is something worth avoiding. > IMO, submodules increase complexity since they reduce readability > and their revisions are not advertised in the . It is also > difficult to follow submodules back to their parent revision, since > the belongs-to-stmt has no revision-date, and include-by-revision is > optional-to-use. Yes, that is what we are discussing here. I have seen the following options so far: a) Declare submodules are broken, do not use them and we assume that users have tools that make it easy for them to deal with hundreds of namespaces. b) We declare that submodules should only be used with include-by-revision, although that limits flexibility. c) We make submodules usable by announcing them including their revisions in the exchange. d) We declare submoduldes are broken and instead accept that multiple modules silently can share the same namespace (and give up the ability to check at module compile time that there are no name clashes). My preference so far is c). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Wed Nov 16 08:36:40 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F05221F94A4 for ; Wed, 16 Nov 2011 08:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 fLCYMKooNjoM for ; Wed, 16 Nov 2011 08:36:39 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9850F21F9475 for ; Wed, 16 Nov 2011 08:36:36 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTsPmhzTeXqb01GjRT79XUCoWshORCNEg@postini.com; Wed, 16 Nov 2011 08:36:39 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 16 Nov 2011 08:33:53 -0800 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 pAGGXqh95495; Wed, 16 Nov 2011 08:33:52 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id pAGG5F4v068836; Wed, 16 Nov 2011 16:05:15 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201111161605.pAGG5F4v068836@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20111116142557.GA23589@elstar.local> Date: Wed, 16 Nov 2011 11:05:15 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] augment 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, 16 Nov 2011 16:36:40 -0000 Juergen Schoenwaelder writes: >a) Declare submodules are broken, do not use them and we assume that > users have tools that make it easy for them to deal with hundreds > of namespaces. >b) We declare that submodules should only be used with > include-by-revision, although that limits flexibility. >c) We make submodules usable by announcing them including their revisions > in the exchange. >d) We declare submoduldes are broken and instead accept that multiple > modules silently can share the same namespace (and give up the > ability to check at module compile time that there are no name clashes). e) allow module owners to force submodules to use import-by-revision, where upon submodule revisions would be announced in the message. I definitely do not want to lose the existing ability to take a single module and divide it into submodules so developers don't all work in the same file. We have >300 submodules with scores of developers and need submodules for organizational sanity. Thanks, Phil From andy@netconfcentral.org Wed Nov 16 11:00:16 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5471F0C54 for ; Wed, 16 Nov 2011 11:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 cauybF7ProsO for ; Wed, 16 Nov 2011 11:00:15 -0800 (PST) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA081F0C4C for ; Wed, 16 Nov 2011 11:00:15 -0800 (PST) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pAGJ0CuJ023255 for ; Wed, 16 Nov 2011 14:00:14 -0500 Authentication-Results: cm-omr11 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [122.147.240.7] ([122.147.240.7:49198] helo=[172.22.14.161]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C7/F0-08733-A3804CE4; Wed, 16 Nov 2011 14:00:11 -0500 Message-ID: <4EC40839.5090209@netconfcentral.org> Date: Wed, 16 Nov 2011 11:00:09 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Phil Shafer References: <201111161605.pAGG5F4v068836@idle.juniper.net> In-Reply-To: <201111161605.pAGG5F4v068836@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] augment 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, 16 Nov 2011 19:00:16 -0000 On 11/16/2011 08:05 AM, Phil Shafer wrote: > Juergen Schoenwaelder writes: >> a) Declare submodules are broken, do not use them and we assume that >> users have tools that make it easy for them to deal with hundreds >> of namespaces. >> b) We declare that submodules should only be used with >> include-by-revision, although that limits flexibility. >> c) We make submodules usable by announcing them including their revisions >> in the exchange. >> d) We declare submoduldes are broken and instead accept that multiple >> modules silently can share the same namespace (and give up the >> ability to check at module compile time that there are no name clashes). > e) allow module owners to force submodules to use import-by-revision, > where upon submodule revisions would be announced in the > message. > > I definitely do not want to lose the existing ability to take a > single module and divide it into submodules so developers don't all > work in the same file. We have>300 submodules with scores of > developers and need submodules for organizational sanity. > You seem to be referring to server developers. I am also concerned about the usability for client application developers. At the interim (way back) when these things were designed, I expressed concern that we we recreating the mistakes of AGENTX. We were promised that sub-agents would be completely transparent to the NMS, but that was not true. In a way, submodules are transparent to the client, because only the parent module name/version is known. We could decide that they are behaving as intended. Submodules are not manageable by the client. There is only 1 name/version for the module, whether it contains a few objects or the whole kitchen sink. Since the main module revision-date is bumped every time any submodule is added or changed, the client won't be able to use the revision-date to determine which submodules may potentially be affected. Then there is the issue of conformance. You can obsolete a submodule. Does that make the entire module obsolete? Can this be easily managed by the client without proper visibility into sub-module lifecycle details? Lada brings up some valid concerns about design complexity we created by the way we use names, prefixes, and namespaces. That is the origin of the true complexity, not XML namespaces themselves. I agree with Phil that our original intent was that submodules be just as usable as modules, but we never really specified what that meant. I suggest before we debate solutions, we agree on the problems first. > Thanks, > Phil > > From randy_presuhn@mindspring.com Wed Nov 16 12:30:50 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B41C21F8FCC for ; Wed, 16 Nov 2011 12:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.742 X-Spam-Level: X-Spam-Status: No, score=-100.742 tagged_above=-999 required=5 tests=[AWL=-0.557, 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 oRZrpLlStox1 for ; Wed, 16 Nov 2011 12:30:49 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id AAF6D21F8FC9 for ; Wed, 16 Nov 2011 12:30:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=P9I53XSgXGx+qaxvsqqbVmSV/ShS2Pq/PqVwcGhUQ0/+idHT7y7cnBBiZ7Uq5vOo; 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.147.184] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RQm86-0007YQ-O2 for netmod@ietf.org; Wed, 16 Nov 2011 15:30:47 -0500 Message-ID: <007a01cca49e$c1f8d540$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <201111161605.pAGG5F4v068836@idle.juniper.net> <4EC40839.5090209@netconfcentral.org> Date: Wed, 16 Nov 2011 12:31:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f77362a2228d6115d9333b5794d5a555d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.38.147.184 Subject: Re: [netmod] augment 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, 16 Nov 2011 20:30:50 -0000 Hi - > From: "Andy Bierman" > To: "Phil Shafer" > Cc: > Sent: Wednesday, November 16, 2011 11:00 AM > Subject: Re: [netmod] augment by revision ... > At the interim (way back) when these things were designed, I expressed > concern that we we recreating the mistakes of AGENTX. We were promised > that sub-agents would be completely transparent to the NMS, but that was not true. Out of curiosity, just how are AgentX subagents not transparent to an NMS in any way that matters? Randy From andy@netconfcentral.org Wed Nov 16 14:07:25 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7724121F91EA for ; Wed, 16 Nov 2011 14:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3Dhy6JOyA1p for ; Wed, 16 Nov 2011 14:07:19 -0800 (PST) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2785A21F91EB for ; Wed, 16 Nov 2011 14:07:18 -0800 (PST) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id pAGM7FfM028803 for ; Wed, 16 Nov 2011 17:07:17 -0500 Authentication-Results: cm-omr3 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [122.147.240.7] ([122.147.240.7:6342] helo=[172.22.14.161]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id ED/5D-04867-21434CE4; Wed, 16 Nov 2011 17:07:15 -0500 Message-ID: <4EC43411.6090405@netconfcentral.org> Date: Wed, 16 Nov 2011 14:07:13 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Randy Presuhn References: <201111161605.pAGG5F4v068836@idle.juniper.net> <4EC40839.5090209@netconfcentral.org> <007a01cca49e$c1f8d540$6b01a8c0@oemcomputer> In-Reply-To: <007a01cca49e$c1f8d540$6b01a8c0@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] augment 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, 16 Nov 2011 22:07:25 -0000 On 11/16/2011 12:31 PM, Randy Presuhn wrote: > Hi - > >> From: "Andy Bierman" >> To: "Phil Shafer" >> Cc: >> Sent: Wednesday, November 16, 2011 11:00 AM >> Subject: Re: [netmod] augment by revision > ... >> At the interim (way back) when these things were designed, I expressed >> concern that we we recreating the mistakes of AGENTX. We were promised >> that sub-agents would be completely transparent to the NMS, but that was not true. > Out of curiosity, just how are AgentX subagents not transparent > to an NMS in any way that matters? Sorry for mentioning SNMP. I don't really want to go off on that tangent. > Randy Andy From lhotka@cesnet.cz Wed Nov 16 18:06:01 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0FA1F0C64 for ; Wed, 16 Nov 2011 18:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 z+avTvl4dHYe for ; Wed, 16 Nov 2011 18:06:01 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id E0E9021F8663 for ; Wed, 16 Nov 2011 18:06:00 -0800 (PST) Received: from dhcp-37d6.meeting.ietf.org (dhcp-37d6.meeting.ietf.org [130.129.55.214]) by office2.cesnet.cz (Postfix) with ESMTPSA id 698342CDE05B; Thu, 17 Nov 2011 03:05:57 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_1C13CE45-1BD0-4023-AFB2-55543F44FC67"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111116142557.GA23589@elstar.local> Date: Thu, 17 Nov 2011 10:05:51 +0800 Message-Id: <7C87CBE3-871E-43D3-8161-5C0D774438EB@cesnet.cz> References: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> <20111116.105621.987975290957079602.mbj@tail-f.com> <7E6027CB-E160-4CA4-9D28-9D8866DF048C@cesnet.cz> <20111116125414.GA23292@elstar.local> <4EC3BC9F.3020502@netconfcentral.org> <20111116142557.GA23589@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] augment 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: Thu, 17 Nov 2011 02:06:01 -0000 --Apple-Mail=_1C13CE45-1BD0-4023-AFB2-55543F44FC67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 16, 2011, at 10:25 PM, Juergen Schoenwaelder wrote: > a) Declare submodules are broken, do not use them and we assume that > users have tools that make it easy for them to deal with hundreds > of namespaces. > b) We declare that submodules should only be used with=20 > include-by-revision, although that limits flexibility. > c) We make submodules usable by announcing them including their = revisions > in the exchange. > d) We declare submoduldes are broken and instead accept that multiple > modules silently can share the same namespace (and give up the > ability to check at module compile time that there are no name = clashes). I prefer b) since it solves the problems and requires no changes to the = specs. I think submodules should be used only within a coordinated group = of developers where it does not really limit flexibility.=20 Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_1C13CE45-1BD0-4023-AFB2-55543F44FC67 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE3MDIwNTUyWjAjBgkqhkiG9w0BCQQxFgQUsBXd3y0U7MTEWolzF/9GyG6t7PQwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQAL/NBGI7oP9g+/3eziMEfRM6mJ usJMjX5N32nSWLadliA9PYYveMtimASAxlbeCSnub+Di10s/2hP/Nf6QDC2HQ+Q0zonhKm4bLpTp dlwcjaibvKXF1H5sIo6KUYev9t7ykOafsi7v8s5V6/GF6SVkSD60a69mRD8dQnLUuNNCQUDUdTJX iTSPUcw0M392z/Ud/vbe0LlxeFhuDAa73wb8Eh+tfrrZPNbIDfK8L1eRX864sTn/R59zgDcx8vh3 R816TFQAU9GdALpHtvXd2pccleYypfWZOGSqJ1GZA1P2ez6l5wfQVJTP5pt1iiRikCP8HWtdQjYj TwIqUqA1TJdCAAAAAAAA --Apple-Mail=_1C13CE45-1BD0-4023-AFB2-55543F44FC67-- From andy@netconfcentral.org Wed Nov 16 18:59:01 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABEB21F916E for ; Wed, 16 Nov 2011 18:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRIgbRsg1SaN for ; Wed, 16 Nov 2011 18:59:00 -0800 (PST) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by ietfa.amsl.com (Postfix) with ESMTP id 53B5821F9153 for ; Wed, 16 Nov 2011 18:58:59 -0800 (PST) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id pAH2wsph027744 for ; Wed, 16 Nov 2011 21:58:56 -0500 Authentication-Results: cm-omr9 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [130.129.21.221] ([130.129.21.221:60659] helo=[130.129.21.221]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id B8/76-04778-C6874CE4; Wed, 16 Nov 2011 21:58:54 -0500 Message-ID: <4EC4786B.2010400@netconfcentral.org> Date: Wed, 16 Nov 2011 18:58:51 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ladislav Lhotka References: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> <20111116.105621.987975290957079602.mbj@tail-f.com> <7E6027CB-E160-4CA4-9D28-9D8866DF048C@cesnet.cz> <20111116125414.GA23292@elstar.local> <4EC3BC9F.3020502@netconfcentral.org> <20111116142557.GA23589@elstar.local> <7C87CBE3-871E-43D3-8161-5C0D774438EB@cesnet.cz> In-Reply-To: <7C87CBE3-871E-43D3-8161-5C0D774438EB@cesnet.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] augment 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: Thu, 17 Nov 2011 02:59:01 -0000 On 11/16/2011 06:05 PM, Ladislav Lhotka wrote: > On Nov 16, 2011, at 10:25 PM, Juergen Schoenwaelder wrote: > >> a) Declare submodules are broken, do not use them and we assume that >> users have tools that make it easy for them to deal with hundreds >> of namespaces. >> b) We declare that submodules should only be used with >> include-by-revision, although that limits flexibility. >> c) We make submodules usable by announcing them including their revisions >> in the exchange. >> d) We declare submoduldes are broken and instead accept that multiple >> modules silently can share the same namespace (and give up the >> ability to check at module compile time that there are no name clashes). > I prefer b) since it solves the problems and requires no changes to the specs. I think submodules should be used only within a coordinated group of developers where it does not really limit flexibility. > But our import/include by revision is close to worthless, so why should we force people to use it? If sec. 10 of RFC 6020 is followed properly, then a client can use most likely use any newer revision. Forcing the inclusion of a specific revision is too fragile. The python world solved this problem correctly (install_requires) install_requires=[ "TurboGears >= 1.0.4.3", "SQLObject>=0.8,<=0.10.0" ], This much more powerful mechanism actually solves the real problems. Usually, a dependency just needs to be the same or newer than a specific version. Let's say something in SQLObject is removed from version 0.11.0 that we were using. For YANG, that would mean a node status was changed to obsolete. In that case, you want to update the 'rule' to say any module revision from 0.8 through 0.10.0 is OK. Andy > Lada > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > > > From lhotka@cesnet.cz Wed Nov 16 19:19:34 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F2711E80DE for ; Wed, 16 Nov 2011 19:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 T3xNy4tRKnRs for ; Wed, 16 Nov 2011 19:19:33 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8B611E80DC for ; Wed, 16 Nov 2011 19:19:33 -0800 (PST) Received: from dhcp-37d6.meeting.ietf.org (dhcp-37d6.meeting.ietf.org [130.129.55.214]) by office2.cesnet.cz (Postfix) with ESMTPSA id D1BE92CDE05C; Thu, 17 Nov 2011 04:19:30 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_AF4DF2C1-C3A3-45C2-ABA6-4ADE8570CA88"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <4EC4786B.2010400@netconfcentral.org> Date: Thu, 17 Nov 2011 11:19:23 +0800 Message-Id: <865A96D9-3067-436F-89E1-03D07DF52352@cesnet.cz> References: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> <20111116.105621.987975290957079602.mbj@tail-f.com> <7E6027CB-E160-4CA4-9D28-9D8866DF048C@cesnet.cz> <20111116125414.GA23292@elstar.local> <4EC3BC9F.3020502@netconfcentral.org> <20111116142557.GA23589@elstar.local> <7C87CBE3-871E-43D3-8161-5C0D774438EB@cesnet.cz> <4EC4786B.2010400@netconfcentral.org> To: Andy Bierman X-Mailer: Apple Mail (2.1251.1) Cc: netmod@ietf.org Subject: Re: [netmod] augment 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: Thu, 17 Nov 2011 03:19:34 -0000 --Apple-Mail=_AF4DF2C1-C3A3-45C2-ABA6-4ADE8570CA88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Nov 17, 2011, at 10:58 AM, Andy Bierman wrote: > On 11/16/2011 06:05 PM, Ladislav Lhotka wrote: >> On Nov 16, 2011, at 10:25 PM, Juergen Schoenwaelder wrote: >>=20 >>> a) Declare submodules are broken, do not use them and we assume that >>> users have tools that make it easy for them to deal with hundreds >>> of namespaces. >>> b) We declare that submodules should only be used with >>> include-by-revision, although that limits flexibility. >>> c) We make submodules usable by announcing them including their = revisions >>> in the exchange. >>> d) We declare submoduldes are broken and instead accept that = multiple >>> modules silently can share the same namespace (and give up the >>> ability to check at module compile time that there are no name = clashes). >> I prefer b) since it solves the problems and requires no changes to = the specs. I think submodules should be used only within a coordinated = group of developers where it does not really limit flexibility. >>=20 >=20 > But our import/include by revision is close to worthless, so why = should we force > people to use it? If sec. 10 of RFC 6020 is followed properly, then a = client > can use most likely use any newer revision. Forcing the inclusion of = a specific How can a client use any newer revision if an exact revision date is = specified?=20 > revision is too fragile. It may be less flexible but I don't get why this is fragile. >=20 > The python world solved this problem correctly (install_requires) >=20 > install_requires=3D[ > "TurboGears >=3D 1.0.4.3", > "SQLObject>=3D0.8,<=3D0.10.0" > ], But these are independent packages with no coordination of versions, so = it is IMO an analogy of YANG modules, not submodules. It would be indeed = useful to have this order relation for "import" but I don't think it is = necessary for "include". I understand submodules as an analogy to e.g. = splitting the C source code into multiple files. Lada =20 >=20 > This much more powerful mechanism actually solves the real problems. > Usually, a dependency just needs to be the same or newer than a = specific version. > Let's say something in SQLObject is removed from version 0.11.0 that = we were using. > For YANG, that would mean a node status was changed to obsolete. > In that case, you want to update the 'rule' to say any module revision = from 0.8 through 0.10.0 is OK. >=20 >=20 > Andy >=20 >=20 >=20 >> Lada >>=20 >> -- >> Ladislav Lhotka, CESNET >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >=20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_AF4DF2C1-C3A3-45C2-ABA6-4ADE8570CA88 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTE3MDMxOTIzWjAjBgkqhkiG9w0BCQQxFgQUHIJgiOziKeg2vtcD68EMcXUja3gwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQA2d1gLsaRQGJVr6KAg1Wv9ZZ/x SCTx3e6OeI2v78gLZp/Td+UQ5zvvBxf22dkGVWEt5OqOCIXhF1PtjR0DjJuAWMBhKzRbbNK70aEV 6nRcz6AjeEZaiIabutUaNRHBr+NIO6WUGAcZ+nLbVJrvIFE3rQDnkuTOCJccD5Ggme1p4FBwQDqF YRQJlziNMnMmekcW66W5lfhovSdBErGNt+QrP2SSumNs3sicIFKRK/FrjgCsQmeYmvNhAlyZapxg z09UpCkrS1OdKmpTQz9GV1DUduwaheUIN1ZxsENVKqLAsYyiQvCyhKIeDf/rOQfRu+PenU/KT2GZ GbPA5uQV9YqrAAAAAAAA --Apple-Mail=_AF4DF2C1-C3A3-45C2-ABA6-4ADE8570CA88-- From andy@netconfcentral.org Wed Nov 16 20:05:09 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E253E11E80E2 for ; Wed, 16 Nov 2011 20:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA00BQdF7tbN for ; Wed, 16 Nov 2011 20:05:09 -0800 (PST) Received: from omr8.networksolutionsemail.com (omr8.networksolutionsemail.com [205.178.146.58]) by ietfa.amsl.com (Postfix) with ESMTP id 2C23311E80B0 for ; Wed, 16 Nov 2011 20:05:09 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr8.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pAH456ii028299 for ; Wed, 16 Nov 2011 23:05:08 -0500 Authentication-Results: cm-omr12 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [130.129.21.221] ([130.129.21.221:45113] helo=[130.129.21.221]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id C2/AB-03697-0F784CE4; Wed, 16 Nov 2011 23:05:06 -0500 Message-ID: <4EC487EF.6080408@netconfcentral.org> Date: Wed, 16 Nov 2011 20:05:03 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ladislav Lhotka References: <1F7C6C3C-DADD-4654-AC39-EB0CA02592DA@cesnet.cz> <20111116.100944.915335040424530675.mbj@tail-f.com> <6F89889B-DF2C-475B-B698-D967AE7E9007@cesnet.cz> <20111116.105621.987975290957079602.mbj@tail-f.com> <7E6027CB-E160-4CA4-9D28-9D8866DF048C@cesnet.cz> <20111116125414.GA23292@elstar.local> <4EC3BC9F.3020502@netconfcentral.org> <20111116142557.GA23589@elstar.local> <7C87CBE3-871E-43D3-8161-5C0D774438EB@cesnet.cz> <4EC4786B.2010400@netconfcentral.org> <865A96D9-3067-436F-89E1-03D07DF52352@cesnet.cz> In-Reply-To: <865A96D9-3067-436F-89E1-03D07DF52352@cesnet.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] augment 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: Thu, 17 Nov 2011 04:05:10 -0000 On 11/16/2011 07:19 PM, Ladislav Lhotka wrote: > On Nov 17, 2011, at 10:58 AM, Andy Bierman wrote: > >> On 11/16/2011 06:05 PM, Ladislav Lhotka wrote: >>> On Nov 16, 2011, at 10:25 PM, Juergen Schoenwaelder wrote: >>> >>>> a) Declare submodules are broken, do not use them and we assume that >>>> users have tools that make it easy for them to deal with hundreds >>>> of namespaces. >>>> b) We declare that submodules should only be used with >>>> include-by-revision, although that limits flexibility. >>>> c) We make submodules usable by announcing them including their revisions >>>> in the exchange. >>>> d) We declare submoduldes are broken and instead accept that multiple >>>> modules silently can share the same namespace (and give up the >>>> ability to check at module compile time that there are no name clashes). >>> I prefer b) since it solves the problems and requires no changes to the specs. I think submodules should be used only within a coordinated group of developers where it does not really limit flexibility. >>> >> But our import/include by revision is close to worthless, so why should we force >> people to use it? If sec. 10 of RFC 6020 is followed properly, then a client >> can use most likely use any newer revision. Forcing the inclusion of a specific > How can a client use any newer revision if an exact revision date is specified? Exactly. It cannot, because of the limitations of YANG. If the module revision rules are followed, then a non-obsolete definition will be usable in any newer revision. The only way to get this robust behavior is to avoid use of import/include by revision. >> revision is too fragile. > It may be less flexible but I don't get why this is fragile. Because an update on the server may not impact the client, but the dependency says it does. If the server updated module X, it will have to keep supporting the old and new revisions, when it is sufficient to just advertise the newer revision. You have to update the module revision just to update the import-by-revision date. This appears as if the feature changed when it may not have changed at all. >> The python world solved this problem correctly (install_requires) >> >> install_requires=[ >> "TurboGears>= 1.0.4.3", >> "SQLObject>=0.8,<=0.10.0" >> ], > But these are independent packages with no coordination of versions, so it is IMO an analogy of YANG modules, not submodules. It would be indeed useful to have this order relation for "import" but I don't think it is necessary for "include". I understand submodules as an analogy to e.g. splitting the C source code into multiple files. Then IMO we don't have any problem with submodules. They work as expected. A client can only manage the life cycle of the entire module. If there is unnecessary churn, then too bad. Our NMS people figured out pretty quickly that one revision for the entire kitchen sink data model was not what they wanted, so we changed all the submodules to modules. > Lada Andy >> This much more powerful mechanism actually solves the real problems. >> Usually, a dependency just needs to be the same or newer than a specific version. >> Let's say something in SQLObject is removed from version 0.11.0 that we were using. >> For YANG, that would mean a node status was changed to obsolete. >> In that case, you want to update the 'rule' to say any module revision from 0.8 through 0.10.0 is OK. >> >> >> Andy >> >> >> >>> Lada >>> >>> -- >>> Ladislav Lhotka, CESNET >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > > > > From andy@netconfcentral.org Wed Nov 16 20:27:58 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9C111E80F5 for ; Wed, 16 Nov 2011 20:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4D5oCEKdbKd4 for ; Wed, 16 Nov 2011 20:27:58 -0800 (PST) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4D52421F94DB for ; Wed, 16 Nov 2011 20:27:58 -0800 (PST) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pAH4RvHm032371 for ; Wed, 16 Nov 2011 23:27:57 -0500 Authentication-Results: cm-omr1 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [130.129.21.221] ([130.129.21.221:45153] helo=[130.129.21.221]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 5D/21-04999-B4D84CE4; Wed, 16 Nov 2011 23:27:57 -0500 Message-ID: <4EC48D49.1020500@netconfcentral.org> Date: Wed, 16 Nov 2011 20:27:53 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Kent Watsen References: <84600D05C20FF943918238042D7670FD3E86E1AF79@EMBX01-HQ.jnpr.net> <4E3865D3.908@andybierman.com> <84600D05C20FF943918238042D7670FD3E86E1AFDB@EMBX01-HQ.jnpr.net> <20110802212353.GC42767@elstar.local> <84600D05C20FF943918238042D7670FD3E86E1B0FF@EMBX01-HQ.jnpr.net> <4E3886E5.3030605@andybierman.com> <84600D05C20FF943918238042D7670FD3E86E1B1FB@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E86E1B1FB@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netmod@ietf.org" Subject: Re: [netmod] must every yang module have a unique namespace? 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, 17 Nov 2011 04:27:59 -0000 On 08/02/2011 04:46 PM, Kent Watsen wrote: > >> If you are going to advertise multiple YANG files per namespace URI, >> then they might as well be sub-modules. Just advertise all the submodules >> and the main module in the. > > Huh? - the arbitrary combinations I mentioned before won't allow it. > > >> I do not agree that deviations are hacky or relevant here. > > I least we agree that deviations are not relevant, albeit for different reasons ;) > > >> Your interpretation of YANG XML namespace usage is not >> supported by the RFC 6020 text. > > 6020 is only unambiguous for standards-based modules (i.e. IETF-defined). Can you source the text, other than what I quoted, that cinches it for non standards-based modules? > I do not agree with this assertion. YANG augment (from 1 module to another) requires distinct XML namespaces so proper XML encoding can be done. There is a basic design assumption that it is OK for a module to augment any other node, without requiring a centralized naming authority, because the extended-names of siblings will be unique, even if the local-names are not unique. This design choice has nothing to do with vendor vs. IETF modules. Andy > > > > From j.schoenwaelder@jacobs-university.de Wed Nov 16 22:58:05 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4F011E80B2 for ; Wed, 16 Nov 2011 22:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 h6KoHfo2YQ8L for ; Wed, 16 Nov 2011 22:58:04 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 85BE311E809B for ; Wed, 16 Nov 2011 22:58:04 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D93DA20E09; Thu, 17 Nov 2011 07:58:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fzP-x4xRTSVR; Thu, 17 Nov 2011 07:58:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5236A20E07; Thu, 17 Nov 2011 07:58:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A65871BB878C; Thu, 17 Nov 2011 07:57:45 +0100 (CET) Date: Thu, 17 Nov 2011 07:57:45 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20111117065745.GD26328@elstar.local> Mail-Followup-To: David Spakes , 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] smi2yang-16: smiv2:oid oid representations [open] 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, 17 Nov 2011 06:58:05 -0000 On Tue, Nov 15, 2011 at 02:52:52PM -0500, David Spakes wrote: > If my proposed solution to unflatten scalars (smi2yang-14) is adopted > so the logical collections from the MIB are preserved, then here are > the usage rules I propose for oid and subid statements. > > extension oid > > 1) MUST be used in the first level of containment within the module. > For example, in augments, top-level containers, notifications, > and alias. > > 2) SHOULD NOT be used below the first level of containment within a > module, except in the following cases: > > a) to specify the object identifier for leaf objects defined > within notifications > > b) as a substatement to an alias > > extension subid > > 1) MUST NOT be used above the second level of containment within a > module. > > 2) MUST be used at every level below the first level of containment > within a module to determine the object identifier for every > scalar object and columnar object translated from the SMIv2 > module, not including objects defined within a notification. Hm, then I do not like it. I like to be able to pick up the full OID from a definition. You want me to go up the containment hierarchy in order to construct the identifier. Since my translator knows the full OID, it is a no brainer to simply print it. It appears to me like we make the file of everyone just more complicated than it needs to be. /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 Nov 16 23:00:19 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7916C1F0C54 for ; Wed, 16 Nov 2011 23:00:19 -0800 (PST) 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 xCRUvIiZt1Ai for ; Wed, 16 Nov 2011 23:00:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AD1E21F0C44 for ; Wed, 16 Nov 2011 23:00:18 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D89320D39; Thu, 17 Nov 2011 08:00:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eHnTIvSfcLj6; Thu, 17 Nov 2011 08:00:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCD7720CCC; Thu, 17 Nov 2011 08:00:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 375291BB87DF; Thu, 17 Nov 2011 08:00:00 +0100 (CET) Date: Thu, 17 Nov 2011 08:00:00 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111117070000.GE26328@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <20111115.084313.294297055.mbj@tail-f.com> <201111152043.PAA23217@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111152043.PAA23217@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-21: prefix generation 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, 17 Nov 2011 07:00:19 -0000 On Tue, Nov 15, 2011 at 03:43:50PM -0500, David Reid wrote: > > Hi, > > > > I really don't see the problem here. Prefixes are local to the > > module, and have no external meaning. Any implementation should be > > free to use whatever prefix genereration algorithm it wants. It is ok > > if the document specifies an optional prefix genereration algorithm > > that implementations can use. When section 3 is read today, it is not > > obvious that the algorithm is optional. I suggest the algorithm is > > moved to an Appendix to emphasize that it is optional. > > I like Martin's suggestion. Good, so I assume this is what we are going to do with this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Nov 16 23:02:48 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2693C11E8083 for ; Wed, 16 Nov 2011 23:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.051, 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 ULmJ7rlGBZEI for ; Wed, 16 Nov 2011 23:02:47 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 806B81F0C8F for ; Wed, 16 Nov 2011 23:02:47 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C13FC20CE8; Thu, 17 Nov 2011 08:02:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jlTGwtT9b7wN; Thu, 17 Nov 2011 08:02:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9452720CCC; Thu, 17 Nov 2011 08:02:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F2DD51BB88AB; Thu, 17 Nov 2011 08:02:28 +0100 (CET) Date: Thu, 17 Nov 2011 08:02:28 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111117070228.GF26328@elstar.local> Mail-Followup-To: David Reid , David Spakes , netmod@ietf.org References: <20111115024043.GB20119@elstar.local> <201111151717.MAA18392@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111151717.MAA18392@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] 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, 17 Nov 2011 07:02:48 -0000 On Tue, Nov 15, 2011 at 12:17:08PM -0500, David Reid wrote: > > > > Clarification question: Is a translator allowed / required / ... to produce both > > smiv2:oid and smiv2:subid statements? > > The point was to make it easier for the human reader and > writer. Requiring both would make it harder, so I don't think that > would be the right answer. Who is the human writer here? The goal of this effort is to translate SMIv2 MIB modules to YANG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Wed Nov 16 23:24:20 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FFB1F0CBE for ; Wed, 16 Nov 2011 23:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpt3x9zj9tDg for ; Wed, 16 Nov 2011 23:24:19 -0800 (PST) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5335B11E812B for ; Wed, 16 Nov 2011 23:24:17 -0800 (PST) Received: from cm-omr8 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pAH7ODba014149 for ; Thu, 17 Nov 2011 02:24:15 -0500 Authentication-Results: cm-omr8 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [130.129.21.221] ([130.129.21.221:41002] helo=[130.129.21.221]) by cm-omr8 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id FE/AA-04746-C96B4CE4; Thu, 17 Nov 2011 02:24:13 -0500 Message-ID: <4EC4B69B.1040409@netconfcentral.org> Date: Wed, 16 Nov 2011 23:24:11 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: David Spakes , netmod@ietf.org References: <20111117065745.GD26328@elstar.local> In-Reply-To: <20111117065745.GD26328@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] 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, 17 Nov 2011 07:24:20 -0000 On 11/16/2011 10:57 PM, Juergen Schoenwaelder wrote: > On Tue, Nov 15, 2011 at 02:52:52PM -0500, David Spakes wrote: > >> If my proposed solution to unflatten scalars (smi2yang-14) is adopted >> so the logical collections from the MIB are preserved, then here are >> the usage rules I propose for oid and subid statements. >> >> extension oid >> >> 1) MUST be used in the first level of containment within the module. >> For example, in augments, top-level containers, notifications, >> and alias. >> >> 2) SHOULD NOT be used below the first level of containment within a >> module, except in the following cases: >> >> a) to specify the object identifier for leaf objects defined >> within notifications >> >> b) as a substatement to an alias >> >> extension subid >> >> 1) MUST NOT be used above the second level of containment within a >> module. >> >> 2) MUST be used at every level below the first level of containment >> within a module to determine the object identifier for every >> scalar object and columnar object translated from the SMIv2 >> module, not including objects defined within a notification. > Hm, then I do not like it. I like to be able to pick up the full OID > from a definition. You want me to go up the containment hierarchy in > order to construct the identifier. Since my translator knows the full > OID, it is a no brainer to simply print it. It appears to me like we > make the file of everyone just more complicated than it needs to be. > IMO, this is more than a nice-to-have. It is mandatory that the smi:oid extension contain exactly one format, which the complete OID string. Any solution that leaves it up to the translator to do anything else is not acceptable. Add additional extensions if you want, and I can (and will) ignore them. Forcing tools to fish around for OID fragments so the actual OID string can be reconstructed is a bad idea. > /js > Andy From j.schoenwaelder@jacobs-university.de Thu Nov 17 00:25:23 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE76A1F0C82 for ; Thu, 17 Nov 2011 00:25:23 -0800 (PST) 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 uv9beRT93hz3 for ; Thu, 17 Nov 2011 00:25:22 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 181741F0CE8 for ; Thu, 17 Nov 2011 00:25:19 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64C7420CDB; Thu, 17 Nov 2011 09:25:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3xNLwKdfR923; Thu, 17 Nov 2011 09:25:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8449C20CD2; Thu, 17 Nov 2011 09:25:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E25851BB8B91; Thu, 17 Nov 2011 09:24:59 +0100 (CET) Date: Thu, 17 Nov 2011 09:24:59 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20111117082459.GA26891@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <20111115035743.GF2731@nsn.com> <003901cca358$9f6be680$6b01a8c0@oemcomputer> <20111115082726.GB20789@elstar.local> <002c01cca3cb$857f41e0$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002c01cca3cb$857f41e0$6b01a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition 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, 17 Nov 2011 08:25:24 -0000 On Tue, Nov 15, 2011 at 11:19:38AM -0800, Randy Presuhn wrote: > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Randy Presuhn" > > Cc: > > Sent: Tuesday, November 15, 2011 12:27 AM > > Subject: Re: [netmod] Snmp configuration charter addition > > > > On Mon, Nov 14, 2011 at 09:36:44PM -0800, Randy Presuhn wrote: > > > > > > I'm still worried about "meaningful." As the discussion on the list > > > revealed, it's not always immediately obvious whether a given legal > > > configuration is meaningful. More importantly, one should take care > > > to not dismiss as "meaningless" a configuration whose utility is not > > > immediately obvious. The i-d which was cited as background for the > > > discussion prohibited as meaningless well-formed configurations > > > which have legitimate uses, thus my concern. Delete the word > > > "meaningful" and I'd be happy with the proposed text. > > > > I like to know your answer to the following two questions. > > > > 1 What about SNMPv1 message processing in combination with the USM > > security model? You can configure this with the SNMPv3 MIB tables - > > do you think it is necessary to preserve this capability in the YANG > > data model? > > Yes, but it's only needed for the products that permit such pathological things. > > (My concern was that the I-D prohibted things that were not pathological at all, > but were in fact well-defined and common operational practice.) I understand what I think your concerns are and I do believe the document is going to change. > Wes has already commented on the (deplorable, in some cases) > semantics associated with such pathological configurations, but the reality > is that they exist. I think the YANG modelers need to figure out for > themselves how/whether they want to account for the differences > in what various products allow. If the decision is to exclude certain > vendors' products from being supported by the Yang models, it > needs to be a conscious decision by the WG. And here is my point: The WG finally needs to reach concensus on the deliverable and then there is the whole process that follows it. By having somewhat fuzzy words in the charter, we express the fact that we trust the WG to come up with something that is reasonable and achieves WG concensus. > This problem is hardly specific to SNMP engine configuration. The point > is that the YANG model needs to permit everything that any product > would allow. > > But I'm less concerned about the philosophical debate than the more > fundamental problem that the YANG model in the I-D prohibits things > are in fact well-defined and common operational practice. If we can agree on 'common operational practice' I am actually fine. Shall we replace 'meaningful' with 'common operational practice'? Both have the same level of vagueness and require the WG to achieve concensus. > > 2 We also have other things like the transport endpoints SNMP engines > > are listening on for which there are no standardized configuration > > tables - do you think this should hence be excluded from the YANG > > data model, even though there is operational experience that this is > > useful/necessary to configure? > > This is indeed useful stuff. I'd love to have a MIB module for it, too. > Having it only accesible via Netconf would just be pathological. I do not mind if there is someone going to write a MIB module for this - this should actually have happened years ago but apparently the SNMP community was fine leaving this to proprietary models. If I read your answer correctly, I hear you saying that you find this pathological from an SNMP point of view but would not object if it would happen. Is that correct? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From reid@snmp.com Thu Nov 17 07:01:55 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842A711E810A for ; Thu, 17 Nov 2011 07:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 WzkXfBE+EnRm for ; Thu, 17 Nov 2011 07:01:55 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id DC59111E8126 for ; Thu, 17 Nov 2011 07:01:54 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA12268; Thu, 17 Nov 2011 10:01:50 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA27049; Thu, 17 Nov 2011 10:01:43 -0500 (EST) Message-Id: <201111171501.KAA27049@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Thu, 17 Nov 2011 08:02:28 +0100. <20111117070228.GF26328@elstar.local> Date: Thu, 17 Nov 2011 10:01:43 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 15:01:55 -0000 > On Tue, Nov 15, 2011 at 12:17:08PM -0500, David Reid wrote: > > > > > > Clarification question: Is a translator allowed / required / ... to produce both > > > smiv2:oid and smiv2:subid statements? > > > > The point was to make it easier for the human reader and > > writer. Requiring both would make it harder, so I don't think that > > would be the right answer. > > Who is the human writer here? I use these extensions in some cases to manually assign OIDs to objects defined in yang modules so that I can access them from SNMP. > The goal of this effort is to translate > SMIv2 MIB modules to YANG. Yes. What I'm doing is really outside the scope of this effort. But to the extent that I can use standard extensions defined in this document rather than create my own proprietary ones, that is helpful, especially if more than one company is doing that. -David Reid From spakes@snmp.com Thu Nov 17 07:24:47 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9391921F9A28 for ; Thu, 17 Nov 2011 07:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 rsBIgsMfEevh for ; Thu, 17 Nov 2011 07:24:47 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id B000421F9A27 for ; Thu, 17 Nov 2011 07:24:45 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA14420; Thu, 17 Nov 2011 10:24:40 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA27659; Thu, 17 Nov 2011 10:24:36 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 17 Nov 2011 10:24:35 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20111117065745.GD26328@elstar.local> Message-ID: References: <20111117065745.GD26328@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] 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, 17 Nov 2011 15:24:47 -0000 On Thu, 17 Nov 2011, Juergen Schoenwaelder wrote: > On Tue, Nov 15, 2011 at 02:52:52PM -0500, David Spakes wrote: > > > If my proposed solution to unflatten scalars (smi2yang-14) is adopted > > so the logical collections from the MIB are preserved, then here are > > the usage rules I propose for oid and subid statements. > > > > extension oid > > > > 1) MUST be used in the first level of containment within the module. > > For example, in augments, top-level containers, notifications, > > and alias. > > > > 2) SHOULD NOT be used below the first level of containment within a > > module, except in the following cases: > > > > a) to specify the object identifier for leaf objects defined > > within notifications > > > > b) as a substatement to an alias > > > > extension subid > > > > 1) MUST NOT be used above the second level of containment within a > > module. > > > > 2) MUST be used at every level below the first level of containment > > within a module to determine the object identifier for every > > scalar object and columnar object translated from the SMIv2 > > module, not including objects defined within a notification. > > Hm, then I do not like it. I like to be able to pick up the full OID > from a definition. You want me to go up the containment hierarchy in > order to construct the identifier. Since my translator knows the full > OID, it is a no brainer to simply print it. It appears to me like we > make the file of everyone just more complicated than it needs to be. Dealing with the subidentifiers was perhaps difficult when the translated document could have an arbitrary depth of containers. But today the hierarchy is collapsed and there are only a few specific cases to handle. If your translator knows the full OID, it should also be a no-brainer to pluck off the last subidentifier (in the case of scalars and auments) or the last two subidentifers (in the case of list) and print them instead. The beauty of the subid approach is that it reflects and compliments the preservation of logical collections of objects. Whether the reader of the translated YANG document is human or machine, a subid statement affirms the logical collection (i.e., the 'normal' case) and an oid statement below the top level screams "pay special attention". -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From reid@snmp.com Thu Nov 17 07:42:19 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD91C1F0C90 for ; Thu, 17 Nov 2011 07:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 lSurWH3vdcsK for ; Thu, 17 Nov 2011 07:42:18 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id A7D901F0C5B for ; Thu, 17 Nov 2011 07:42:17 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA15479; Thu, 17 Nov 2011 10:42:16 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA28189; Thu, 17 Nov 2011 10:42:16 -0500 (EST) Message-Id: <201111171542.KAA28189@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Mon, 14 Nov 2011 10:41:32 +0100. <20111114094130.GB17498@elstar.local> Date: Thu, 17 Nov 2011 10:42:16 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smiv2 to yang mapping issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 15:42:19 -0000 > Hi, > > attached please find the issues list I am maintaining for the smiv2 to > yang mapping. You can ignore the closed issues (except for those who > want to recall history). For some issues, there is a strawman while > others are open and looking for a resolution. Lets see what we manage > to close tomorrow or during this week (sometimes solutions also evolve > around a meeting, in particular since not all implementors happen to > be at the meeting). > > /js For all of the issues that have a strawman listed except for #18, I agree with the strawman. For #18, I like the suggestion from David Spakes to also include the rest of the types in Table 1 and 2 of RFC 6021. -David Reid From reid@snmp.com Thu Nov 17 08:44:46 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA70611E80C5 for ; Thu, 17 Nov 2011 08:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 DYpT55MqiW7o for ; Thu, 17 Nov 2011 08:44:41 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5190721F9651 for ; Thu, 17 Nov 2011 08:44:40 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA20756 for ; Thu, 17 Nov 2011 11:44:13 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA29733 for ; Thu, 17 Nov 2011 11:44:08 -0500 (EST) Message-Id: <201111171644.LAA29733@adminfs.snmp.com> To: netmod@ietf.org Date: Thu, 17 Nov 2011 11:44:08 -0500 From: David Reid Subject: [netmod] smi2yang-04: string vs. binary 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, 17 Nov 2011 16:44:46 -0000 I've never been entirely comfortable with solution #04-01, but I can't come up with anything better. Of the options on the table, I think #04-01 is the best. -David Reid > * smi2yang-04: string vs. binary [open] > > It would be nice to have a reliable mechanism to determine whether > an OCTET STRING can be represented as a human readable string or is > a binary string. The current ID suggests to use the presence of a > DISPLAY-HINT for this purpose. However, the SMIv2 allows to add a > DISPLAY-HINT when a MIB module is revised, which can lead to > different translations of different versions of a MIB module. > > ** Solution #04-01 > > Declare this a non-problem since additions of DISPLAY-HINTs are > rare. Suggest that implementations provide options to cast an > OCTET STRING into binary to handle situations where a DISPLAY-HINT > got added when a module was revised. > > ** Solution #04-02 > > Translate strings into unions that allows both a human readable > string representation and a binary representation. However, this > requires to have some mechanism in place to decide whether a value > is a human readable string or a binary string, which means we > likely have to mess around with values. > > ** Solution #04-03 > > Always translate OCTET STRING types into the YANG binary types. We > could list some well-known types as exceptions, like DisplayString, > SnmpAdminString, DateAndTime but such a list will always be > incomplete and hence some human readable data will be encoded into > base64. > > ** Solution #04-04 > > Always translate OCTET STRINGS into a choice which contains a > binary leaf. Add a second string leaf if there is a DISPLAY-HINT. > This would also apply to objects using an OCTET STRING TC, that is > in the extreme case (no special rules for well known string types), > we get for sysDescr: > > choice sysDescr-leaf { > leaf sysDescr-string { > type string; > } > leaf sysDescr-binary { > type binary; > } > } > > While this solution is robust wrt. module revisions that add a > DISPLAY-HINT, the cost of having to support two formats are > significant. From spakes@snmp.com Thu Nov 17 08:44:47 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1656921F9651 for ; Thu, 17 Nov 2011 08:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 xpYWQFyZEisk for ; Thu, 17 Nov 2011 08:44:40 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA0D21F9606 for ; Thu, 17 Nov 2011 08:44:39 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA20760; Thu, 17 Nov 2011 11:44:38 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA29751; Thu, 17 Nov 2011 11:44:33 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 17 Nov 2011 11:44:33 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Martin Bjorklund In-Reply-To: <20111115.092517.458608351.mbj@tail-f.com> Message-ID: References: <20111115.092517.458608351.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-14: unflatten scalars [open] 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, 17 Nov 2011 16:44:47 -0000 On Wed, 9 Nov 2011, Juergen Schoenwaelder wrote: > ... If you need to > translate them, simply fix the module before running the translator. > The IETF MIB modules that have such problems and are shipped with > smidump have been fixed manually. On Tue, 15 Nov 2011, Martin Bjorklund wrote: > David Spakes wrote: > > I _strongly_ dislike Solution #14-02 for SMIv2 documents that group > > scalar objects together in logical collections by placing them into > > separate branches of the MIB. > > > > I would like to propose another solution in which logical collections > > are preserved by having a separate top-level container for each of those > > collections. > > > I like this solution. The logical groupings from the MIBs are kept; > the structure gets better and it helps during retrieval (filtering). > > However, there are some corner cases that we have to handle (even if > "handle" means document bad behaviour). > > For example, what would the result of this be: > > fooScalar OBJECT-TYPE > .... > ::= { foo 1 2 } > > ? > > And what happens if, in a new revision, this is changed to: > > bar OBJECT IDENTIFIER ::= { foo 1 } > > fooScalar OBJECT-TYPE > .... > ::= { bar 2 } Martin, You asked me three questions on Tuesday. I answered one right away (not quoted above) but took time to ponder the other two (quoted above) before answering. I would have the ietf-yang-smiv2 document specifically mention the above two cases. 1. Let the spec say that an SMIv2 document that defines the OID of an object with an expression like "foo 1 2" can not be translated to YANG unless "foo 1" is resolved elsewhere in the module (or perhaps by an imported module). 2. If there is a later revision of the same module that resolves "foo 1", then the spec should state as a Best Current Practice what Juergen said earlier: simply fix the module before running the translator. Personally, I have seen this "foo 1 2"-type expression used in some SMIv2 documents to identify the series of branches leading down to the MODULE-IDENTITY. But I can't specifically recall a single time seeing it used below the MODULE-IDENTITY. That's the only place where it would matter. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From mbj@tail-f.com Thu Nov 17 09:03:10 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC2321F99A6 for ; Thu, 17 Nov 2011 09:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfnNqxDz42+N for ; Thu, 17 Nov 2011 09:03:10 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 70F4F21F9966 for ; Thu, 17 Nov 2011 09:03:10 -0800 (PST) Received: from localhost (unknown [212.181.100.8]) by mail.tail-f.com (Postfix) with ESMTPSA id E5A3E1200D13; Thu, 17 Nov 2011 18:03:08 +0100 (CET) Date: Thu, 17 Nov 2011 18:03:08 +0100 (CET) Message-Id: <20111117.180308.173991331.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <201111171644.LAA29733@adminfs.snmp.com> References: <201111171644.LAA29733@adminfs.snmp.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-04: string vs. binary 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, 17 Nov 2011 17:03:11 -0000 David Reid wrote: > I've never been entirely comfortable with solution #04-01, but I can't > come up with anything better. Of the options on the table, I think #04-01 > is the best. +1 /martin From reid@snmp.com Thu Nov 17 09:03:12 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A94421F99A6 for ; Thu, 17 Nov 2011 09:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 4d-DbcMKWQHI for ; Thu, 17 Nov 2011 09:03:11 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4A91221F9966 for ; Thu, 17 Nov 2011 09:03:11 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA22272; Thu, 17 Nov 2011 12:03:07 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA00344; Thu, 17 Nov 2011 12:03:06 -0500 (EST) Message-Id: <201111171703.MAA00344@adminfs.snmp.com> To: David Spakes From: David Reid In-reply-to: Your message of Thu, 17 Nov 2011 11:44:33 -0500. Date: Thu, 17 Nov 2011 12:03:06 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-14: unflatten scalars [open] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 17:03:12 -0000 > > I like this solution. The logical groupings from the MIBs are kept; > > the structure gets better and it helps during retrieval (filtering). > > > > However, there are some corner cases that we have to handle (even if > > "handle" means document bad behaviour). > > > > For example, what would the result of this be: > > > > fooScalar OBJECT-TYPE > > .... > > ::= { foo 1 2 } > > > > ? > > > > And what happens if, in a new revision, this is changed to: > > > > bar OBJECT IDENTIFIER ::= { foo 1 } > > > > fooScalar OBJECT-TYPE > > .... > > ::= { bar 2 } > Martin, > > You asked me three questions on Tuesday. I answered one right away > (not quoted above) but took time to ponder the other two (quoted above) > before answering. > > I would have the ietf-yang-smiv2 document specifically mention the > above two cases. > > 1. Let the spec say that an SMIv2 document that defines the OID > of an object with an expression like "foo 1 2" can not be > translated to YANG unless "foo 1" is resolved elsewhere in the > module (or perhaps by an imported module). What if just name the container foo.1 ('.' is legal in a yang identifier). > > 2. If there is a later revision of the same module that resolves > "foo 1", then the spec should state as a Best Current Practice > what Juergen said earlier: simply fix the module before running > the translator. The revised module would have a new container named bar and lose the container named foo.1. That's bad. But this seems unlikely to happen in practice. -David Reid From spakes@snmp.com Thu Nov 17 09:21:39 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2CB1F0C6F for ; Thu, 17 Nov 2011 09:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 v4wopLAd6s7P for ; Thu, 17 Nov 2011 09:21:32 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id BD11C1F0C54 for ; Thu, 17 Nov 2011 09:21:31 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA23826; Thu, 17 Nov 2011 12:21:30 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA00792; Thu, 17 Nov 2011 12:21:29 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Thu, 17 Nov 2011 12:21:29 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: David Reid Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: [netmod] smi2yang-04: string vs. binary 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, 17 Nov 2011 17:21:40 -0000 If the group concensus is solution #04-01, I'd go along. However, I favor solution #04-02. The first character of the value would indicate to the NETCONF protocol receiver which element of the union applies. * If the first character is a double-quote, a string value follows, and the leading double-quote is not part of the value. * If the first character is not a double-quote, the value is binary, and the leading character is part of the encoded value. -dss ---------- Forwarded message ---------- Date: Thu, 17 Nov 2011 11:44:08 -0500 From: David Reid To: netmod@ietf.org Subject: [netmod] smi2yang-04: string vs. binary I've never been entirely comfortable with solution #04-01, but I can't come up with anything better. Of the options on the table, I think #04-01 is the best. -David Reid > * smi2yang-04: string vs. binary [open] > > It would be nice to have a reliable mechanism to determine whether > an OCTET STRING can be represented as a human readable string or is > a binary string. The current ID suggests to use the presence of a > DISPLAY-HINT for this purpose. However, the SMIv2 allows to add a > DISPLAY-HINT when a MIB module is revised, which can lead to > different translations of different versions of a MIB module. > > ** Solution #04-01 > > Declare this a non-problem since additions of DISPLAY-HINTs are > rare. Suggest that implementations provide options to cast an > OCTET STRING into binary to handle situations where a DISPLAY-HINT > got added when a module was revised. > > ** Solution #04-02 > > Translate strings into unions that allows both a human readable > string representation and a binary representation. However, this > requires to have some mechanism in place to decide whether a value > is a human readable string or a binary string, which means we > likely have to mess around with values. > > ** Solution #04-03 > > Always translate OCTET STRING types into the YANG binary types. We > could list some well-known types as exceptions, like DisplayString, > SnmpAdminString, DateAndTime but such a list will always be > incomplete and hence some human readable data will be encoded into > base64. > > ** Solution #04-04 > > Always translate OCTET STRINGS into a choice which contains a > binary leaf. Add a second string leaf if there is a DISPLAY-HINT. > This would also apply to objects using an OCTET STRING TC, that is > in the extreme case (no special rules for well known string types), > we get for sysDescr: > > choice sysDescr-leaf { > leaf sysDescr-string { > type string; > } > leaf sysDescr-binary { > type binary; > } > } > > While this solution is robust wrt. module revisions that add a > DISPLAY-HINT, the cost of having to support two formats are > significant. ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From reid@snmp.com Thu Nov 17 09:38:19 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C94611E80C8 for ; Thu, 17 Nov 2011 09:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_36=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 N4Ni1xfOKXFb for ; Thu, 17 Nov 2011 09:38:13 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 34BF611E8095 for ; Thu, 17 Nov 2011 09:38:13 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA25256 for ; Thu, 17 Nov 2011 12:38:12 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA01195 for ; Thu, 17 Nov 2011 12:38:12 -0500 (EST) Message-Id: <201111171738.MAA01195@adminfs.snmp.com> To: netmod@ietf.org Date: Thu, 17 Nov 2011 12:38:12 -0500 From: David Reid Subject: [netmod] smi2yang-12: smi:defval in SMI scope or YANG scope 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, 17 Nov 2011 17:38:19 -0000 > * smi2yang-12: smi:defval in SMI scope or YANG scope [open] > > Is the value reported in the smi:defval clause an SMI default value > or a YANG default value (e.g. does it include prefixes)? > > ** Solution #12-01: > > It is the SMI default value; in particular OBJECT-IDENTITIES are > showing up as SMIv2 descriptors and not as prefixed YANG > identifiers. My implementation follows solution #12-01 only because I really didn't consider the alternative. I just copy verbatim what is in the DEFVAL clause and put in the smiv2:defval statement. After further consideration, I still think #12-01 is the right solution. A note in the document saying smiv2:defval is in SMI scope would probably be good. -David Reid From randy_presuhn@mindspring.com Thu Nov 17 10:14:05 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAE91F0C65 for ; Thu, 17 Nov 2011 10:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KczrKS5dMEvj for ; Thu, 17 Nov 2011 10:14:04 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 606E91F0C44 for ; Thu, 17 Nov 2011 10:14:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qd77AWok0Qs59aegOeJxPfbKqsNWrEyEh1vWlEH208Y21midGjJN1Kc08bkSF0Yd; 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.55.174.255] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RR6TJ-0007aU-Lo for netmod@ietf.org; Thu, 17 Nov 2011 13:14:01 -0500 Message-ID: <003401cca554$d27c5020$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20111115035743.GF2731@nsn.com> <003901cca358$9f6be680$6b01a8c0@oemcomputer> <20111115082726.GB20789@elstar.local> <002c01cca3cb$857f41e0$6b01a8c0@oemcomputer> <20111117082459.GA26891@elstar.local> Date: Thu, 17 Nov 2011 10:14:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f1488cce7505b79f6a57902de00b1f1b2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.174.255 Subject: Re: [netmod] Snmp configuration charter addition 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, 17 Nov 2011 18:14:05 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Thursday, November 17, 2011 12:24 AM > Subject: Re: [netmod] Snmp configuration charter addition .... > If we can agree on 'common operational practice' I am actually fine. > Shall we replace 'meaningful' with 'common operational practice'? > Both have the same level of vagueness and require the WG to achieve > concensus. I could live with "common operational practice". ... > I do not mind if there is someone going to write a MIB module for this > - this should actually have happened years ago but apparently the SNMP > community was fine leaving this to proprietary models. The issue was hotly debated and rather politicized at least as far back as the SNMPv2 meltdown. > If I read your answer correctly, I hear you saying that you find this > pathological from an SNMP point of view but would not object if it > would happen. Is that correct? It's not merely pathological from an SNMP point of view. It's pathological from both a systems and a network management perspective. It's probably not the job of this particular WG to fix it, but it is a symptom of a larger IETF dysfunction. As a *modeling* issue, this gets back to the question of whether the goal is to provide access to a common underlying information model. Since some of the netmod work seems to be an attempt to maintain the useful fiction of common information models, an approach to consider might be to put the "additions" like port / interface configuration into a module of their own, or otherwise formally represent that they represent an additional package of functionality. Randy From j.schoenwaelder@jacobs-university.de Thu Nov 17 18:41:34 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112271F0C60 for ; Thu, 17 Nov 2011 18:41:34 -0800 (PST) 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 fTU-Op8C+O7r for ; Thu, 17 Nov 2011 18:41:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 408BF1F0C5E for ; Thu, 17 Nov 2011 18:41:33 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34DD220D04; Fri, 18 Nov 2011 03:41:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 25-iRx-qcHS3; Fri, 18 Nov 2011 03:41:31 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6309320D03; Fri, 18 Nov 2011 03:41:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C1D6A1BB96E6; Fri, 18 Nov 2011 03:41:12 +0100 (CET) Date: Fri, 18 Nov 2011 03:41:11 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111118024110.GA28286@elstar.local> Mail-Followup-To: David Reid , David Spakes , netmod@ietf.org References: <20111117070228.GF26328@elstar.local> <201111171501.KAA27049@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111171501.KAA27049@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] 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, 18 Nov 2011 02:41:34 -0000 On Thu, Nov 17, 2011 at 10:01:43AM -0500, David Reid wrote: > > On Tue, Nov 15, 2011 at 12:17:08PM -0500, David Reid wrote: > > > > > > > > Clarification question: Is a translator allowed / required / ... to produce both > > > > smiv2:oid and smiv2:subid statements? > > > > > > The point was to make it easier for the human reader and > > > writer. Requiring both would make it harder, so I don't think that > > > would be the right answer. > > > > Who is the human writer here? > > I use these extensions in some cases to manually assign OIDs to objects > defined in yang modules so that I can access them from SNMP. > > > The goal of this effort is to translate > > SMIv2 MIB modules to YANG. > > Yes. What I'm doing is really outside the scope of this effort. But to the > extent that I can use standard extensions defined in this document rather > than create my own proprietary ones, that is helpful, especially if more than > one company is doing that. But since we are specifying a translation algorithm, I think it is fine to have a translator generate the full OID, no? If you want to use the extension for other purposes, fine. It is then your choice whether you used smiv2:oid or smiv2:subid. /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 Nov 17 19:04:08 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9A91F0C61 for ; Thu, 17 Nov 2011 19:04:08 -0800 (PST) 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 U-pFiFw87zw3 for ; Thu, 17 Nov 2011 19:04:07 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5E03B1F0C34 for ; Thu, 17 Nov 2011 19:04:05 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A992E20D86; Fri, 18 Nov 2011 04:04:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4TeSfrYmr36T; Fri, 18 Nov 2011 04:04:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D885D20D94; Fri, 18 Nov 2011 04:04:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F1B301BB9B92; Fri, 18 Nov 2011 04:03:45 +0100 (CET) Date: Fri, 18 Nov 2011 04:03:45 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20111118030345.GC28368@elstar.local> Mail-Followup-To: David Spakes , netmod@ietf.org References: <20111117065745.GD26328@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] smi2yang-16: smiv2:oid oid representations [open] 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, 18 Nov 2011 03:04:08 -0000 On Thu, Nov 17, 2011 at 10:24:35AM -0500, David Spakes wrote: > On Thu, 17 Nov 2011, Juergen Schoenwaelder wrote: > > > On Tue, Nov 15, 2011 at 02:52:52PM -0500, David Spakes wrote: > > > > > If my proposed solution to unflatten scalars (smi2yang-14) is adopted > > > so the logical collections from the MIB are preserved, then here are > > > the usage rules I propose for oid and subid statements. > > > > > > extension oid > > > > > > 1) MUST be used in the first level of containment within the module. > > > For example, in augments, top-level containers, notifications, > > > and alias. > > > > > > 2) SHOULD NOT be used below the first level of containment within a > > > module, except in the following cases: > > > > > > a) to specify the object identifier for leaf objects defined > > > within notifications > > > > > > b) as a substatement to an alias > > > > > > extension subid > > > > > > 1) MUST NOT be used above the second level of containment within a > > > module. > > > > > > 2) MUST be used at every level below the first level of containment > > > within a module to determine the object identifier for every > > > scalar object and columnar object translated from the SMIv2 > > > module, not including objects defined within a notification. > > > > Hm, then I do not like it. I like to be able to pick up the full OID > > from a definition. You want me to go up the containment hierarchy in > > order to construct the identifier. Since my translator knows the full > > OID, it is a no brainer to simply print it. It appears to me like we > > make the file of everyone just more complicated than it needs to be. > > > Dealing with the subidentifiers was perhaps difficult when the translated > document could have an arbitrary depth of containers. But today the > hierarchy is collapsed and there are only a few specific cases to handle. > > If your translator knows the full OID, it should also be a no-brainer to > pluck off the last subidentifier (in the case of scalars and auments) or > the last two subidentifers (in the case of list) and print them instead. > > The beauty of the subid approach is that it reflects and compliments the > preservation of logical collections of objects. Whether the reader of the > translated YANG document is human or machine, a subid statement affirms > the logical collection (i.e., the 'normal' case) and an oid statement > below the top level screams "pay special attention". I do not care about the implementation aspects in the translator. I care about making postprocessing of YANG modules harder than it needs to be. /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 Nov 17 19:06:36 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC4D1F0C86 for ; Thu, 17 Nov 2011 19:06:36 -0800 (PST) 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 flUpCX58B0g5 for ; Thu, 17 Nov 2011 19:06:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 00B341F0C85 for ; Thu, 17 Nov 2011 19:06:35 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 546FD20D86; Fri, 18 Nov 2011 04:06:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KBUTqkSarQsT; Fri, 18 Nov 2011 04:06:34 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21DD420D82; Fri, 18 Nov 2011 04:06:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8ADFE1BB9BE7; Fri, 18 Nov 2011 04:06:17 +0100 (CET) Date: Fri, 18 Nov 2011 04:06:17 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111118030617.GD28368@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <20111114094130.GB17498@elstar.local> <201111171542.KAA28189@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111171542.KAA28189@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smiv2 to yang mapping issues 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, 18 Nov 2011 03:06:36 -0000 On Thu, Nov 17, 2011 at 10:42:16AM -0500, David Reid wrote: > > Hi, > > > > attached please find the issues list I am maintaining for the smiv2 to > > yang mapping. You can ignore the closed issues (except for those who > > want to recall history). For some issues, there is a strawman while > > others are open and looking for a resolution. Lets see what we manage > > to close tomorrow or during this week (sometimes solutions also evolve > > around a meeting, in particular since not all implementors happen to > > be at the meeting). > > > > /js > > For all of the issues that have a strawman listed except for #18, I agree > with the strawman. For #18, I like the suggestion from David Spakes to > also include the rest of the types in Table 1 and 2 of RFC 6021. OK. I have added Table 2 to 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 j.schoenwaelder@jacobs-university.de Thu Nov 17 19:10:15 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F58521F847C for ; Thu, 17 Nov 2011 19:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_36=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 MWllpBnlr3WH for ; Thu, 17 Nov 2011 19:10:14 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01D21F8472 for ; Thu, 17 Nov 2011 19:10:14 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 06A0B20D86; Fri, 18 Nov 2011 04:10:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FmaY_oBxxyfX; Fri, 18 Nov 2011 04:10:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A12D520D82; Fri, 18 Nov 2011 04:10:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 15CE21BB9C7B; Fri, 18 Nov 2011 04:09:55 +0100 (CET) Date: Fri, 18 Nov 2011 04:09:55 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111118030954.GE28368@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <201111171738.MAA01195@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111171738.MAA01195@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-12: smi:defval in SMI scope or YANG scope 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, 18 Nov 2011 03:10:15 -0000 X-List-Received-Date: Fri, 18 Nov 2011 03:10:15 -0000 On Thu, Nov 17, 2011 at 12:38:12PM -0500, David Reid wrote: > > * smi2yang-12: smi:defval in SMI scope or YANG scope [open] > > > > Is the value reported in the smi:defval clause an SMI default value > > or a YANG default value (e.g. does it include prefixes)? > > > > ** Solution #12-01: > > > > It is the SMI default value; in particular OBJECT-IDENTITIES are > > showing up as SMIv2 descriptors and not as prefixed YANG > > identifiers. > > My implementation follows solution #12-01 only because I really didn't > consider the alternative. I just copy verbatim what is in the DEFVAL > clause and put in the smiv2:defval statement. After further consideration, > I still think #12-01 is the right solution. A note in the document saying > smiv2:defval is in SMI scope would probably be good. I agree. I made a note to add text discussing this and I moved this issues from open to strawman: accept #12-01. /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 Nov 17 21:49:17 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E647F21F9485 for ; Thu, 17 Nov 2011 21:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.051, 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 65iVhpt0e147 for ; Thu, 17 Nov 2011 21:49:16 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D7C0A21F9017 for ; Thu, 17 Nov 2011 21:49:15 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 31F1120D89; Fri, 18 Nov 2011 06:49:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iKlSyWLBWge4; Fri, 18 Nov 2011 06:49:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CBBBB20D8B; Fri, 18 Nov 2011 06:49:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5FB111BBA380; Fri, 18 Nov 2011 06:48:55 +0100 (CET) Date: Fri, 18 Nov 2011 06:48:55 +0100 From: Juergen Schoenwaelder To: David Kessens Message-ID: <20111118054853.GA29390@elstar.local> Mail-Followup-To: David Kessens , netmod@ietf.org References: <20111115035743.GF2731@nsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111115035743.GF2731@nsn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition 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, 18 Nov 2011 05:49:17 -0000 On Mon, Nov 14, 2011 at 07:57:43PM -0800, David Kessens wrote: > I have reviewed the discussion and would like to propose the > following text: > > 5. Data model for configuring SNMP engines. The model must be capable of > representing all meaningful SNMP engine configurations possible with the > standard SNMPv3 MIB modules. Any differences in functionality and > behavior should be documented. > > Please let the working group think how you feel about this text, and if you > don't agree, propose alternative text that addresses your concerns. Taking the recent discussion into account, here is a revised version of the new charter text: 5. Data model for configuring SNMP engines. The model must be capable of representing all SNMP engine configurations possible with the standard SNMPv3 MIB modules that are common operational practice. Any differences in functionality and behavior should be documented. Please let the working group know how you feel about this text, and if you don't agree, propose alternative text that addresses your concerns. Since we like to move forward with this (we have been stuck on this for a while now), please raise any concerns by November 28. /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 Nov 17 22:34:54 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318AB21F950F for ; Thu, 17 Nov 2011 22:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.921 X-Spam-Level: X-Spam-Status: No, score=-101.921 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, FRT_BIGGERMEM1=2.555, 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 PzoorK3Bv+03 for ; Thu, 17 Nov 2011 22:34:53 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 667C021F950D for ; Thu, 17 Nov 2011 22:34:53 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BA0F020D8D; Fri, 18 Nov 2011 07:34:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BFJOg6qJbOnX; Fri, 18 Nov 2011 07:34:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E1E620D8B; Fri, 18 Nov 2011 07:34:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0268C1BBA4DD; Fri, 18 Nov 2011 07:34:33 +0100 (CET) Date: Fri, 18 Nov 2011 07:34:33 +0100 From: Juergen Schoenwaelder To: Dan Romascanu Message-ID: <20111118063433.GA29643@elstar.local> Mail-Followup-To: Dan Romascanu , netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: [netmod] Summary of the NETMOD Session at the 82nd IETF in Taipei 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, 18 Nov 2011 06:34:54 -0000 The NETMOD working group has met for two hours on Tuesday during the 82st IETF meeting. The meeting was attended by about 20 people in room with a few additional remote participants (including some key contributors). - was discussed and there are a few changes to be made. The next revision of the draft will appear as a WG document. - and the related IANA document are in WG last call and so far no major issues have been raised. The discussion focused more on where it is not clear cut what needs to be included and how model elements are split between this draft and . This will require more discussion on the mailing list. - has been discussed and received some positive support from some routing people in the room. The revision of this document is likely soon going to WG last call to encourage more reviews. The only bigger open issue seems to be whether the IP forwarding tables should be moved into the IP configuration draft. This will require more discussion on the mailing list. - Several issues concerning have been recently brought up on the mailing list. Several have been resolved during the IETF meeting (mostly on the mailing list) and an updated draft is expected shortly after the meeting. - A new attempt has been started to find agreement on an charter addition to cover work on a data model for configuring SNMP. There was no specific input at the meeting. It seems only one contributor had an issue with the originally proposed text and we will have to see whether the new text finds consensus. /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 Nov 17 23:53:51 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811DB21F9466 for ; Thu, 17 Nov 2011 23:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+mNRtU6FZvY for ; Thu, 17 Nov 2011 23:53:51 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E235821F93D1 for ; Thu, 17 Nov 2011 23:53:50 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 512F51200AD8; Fri, 18 Nov 2011 08:53:48 +0100 (CET) Date: Fri, 18 Nov 2011 08:53:48 +0100 (CET) Message-Id: <20111118.085348.2121437773207982249.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20111118030617.GD28368@elstar.local> References: <20111114094130.GB17498@elstar.local> <201111171542.KAA28189@adminfs.snmp.com> <20111118030617.GD28368@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] smiv2 to yang mapping issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 07:53:51 -0000 Hi, There is one more corner case in the type mapping algorithm. Currently, both OCTET STRING (w/o DISPLAY-HINT) and Opaque maps to the YANG type binary. But these are different types on-the-wire in SNMP, so an implementation that works off the generated YANG module does not have enough information (e.g., the proxy use case I mentioned earlier). It just sees a binary and doesn't now how to encode it in the PDU. This can easily be solved by adding a typedef to ietf-yang-smiv2: typedef opaque { type binary; description "The opaque type represents SMIv2 Opaque values."; reference "RFC 2578 ..."; } and update the mapping table accordingly. /martin From spakes@snmp.com Fri Nov 18 08:49:40 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133E01F0C34 for ; Fri, 18 Nov 2011 08:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 FurVjbbn2hUY for ; Fri, 18 Nov 2011 08:49:36 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id BBD6221F8AFC for ; Fri, 18 Nov 2011 08:49:35 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA11615; Fri, 18 Nov 2011 11:49:25 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA17497; Fri, 18 Nov 2011 11:49:10 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 18 Nov 2011 11:49:10 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20111118030345.GC28368@elstar.local> Message-ID: References: <20111117065745.GD26328@elstar.local> <20111118030345.GC28368@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] 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, 18 Nov 2011 16:49:40 -0000 On Fri, 18 Nov 2011, Juergen Schoenwaelder wrote: > > The beauty of the subid approach is that it reflects and compliments the > > preservation of logical collections of objects. Whether the reader of the > > translated YANG document is human or machine, a subid statement affirms > > the logical collection (i.e., the 'normal' case) and an oid statement > > below the top level screams "pay special attention". > > I do not care about the implementation aspects in the translator. I > care about making postprocessing of YANG modules harder than it needs > to be. About which are you mainly concerned? Postprocessing by an application that knows about/cares about SNMP? Postprocessing by an application does doesn't know about/care about SNMP? -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From spakes@snmp.com Fri Nov 18 08:54:12 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FAA1F0C34 for ; Fri, 18 Nov 2011 08:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 j+mJeXj34gaL for ; Fri, 18 Nov 2011 08:54:12 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id CCCBD21F8AFF for ; Fri, 18 Nov 2011 08:54:11 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA11976; Fri, 18 Nov 2011 11:54:05 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA17638; Fri, 18 Nov 2011 11:54:01 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 18 Nov 2011 11:54:00 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20111118054853.GA29390@elstar.local> Message-ID: References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition 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, 18 Nov 2011 16:54:12 -0000 On Fri, 18 Nov 2011, Juergen Schoenwaelder wrote: > 5. Data model for configuring SNMP engines. The model must be capable > of representing all SNMP engine configurations possible with the > standard SNMPv3 MIB modules that are common operational practice. > Any differences in functionality and behavior should be documented. > > Please let the working group know how you feel about this text, and if > you don't agree, propose alternative text that addresses your > concerns. Since we like to move forward with this (we have been stuck > on this for a while now), please raise any concerns by November 28. Why not just stop the sentence after "modules"? i.e., 5. Data model for configuring SNMP engines. The model must be capable of representing all SNMP engine configurations possible with the standard SNMPv3 MIB modules. Any differences in functionality and behavior should be documented. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From phil@juniper.net Fri Nov 18 09:34:29 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC87A11E808A for ; Fri, 18 Nov 2011 09:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 LReqUkgY4Hbq for ; Fri, 18 Nov 2011 09:34:29 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 0A68A11E8083 for ; Fri, 18 Nov 2011 09:34:14 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTsaXDqQo5m6G8HA8VlS697Yc2kVqS9nM@postini.com; Fri, 18 Nov 2011 09:34:29 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 18 Nov 2011 09:32:19 -0800 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 pAIHWGh50855; Fri, 18 Nov 2011 09:32:16 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id pAIH3bm5086449; Fri, 18 Nov 2011 17:03:38 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201111181703.pAIH3bm5086449@idle.juniper.net> To: David Spakes In-Reply-To: Date: Fri, 18 Nov 2011 12:03:37 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition 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, 18 Nov 2011 17:34:30 -0000 David Spakes writes: >Why not just stop the sentence after "modules"? i.e., > > 5. Data model for configuring SNMP engines. The model must be capable > of representing all SNMP engine configurations possible with the > standard SNMPv3 MIB modules. Any differences in functionality and > behavior should be documented. To keep folks from coming up with "use cases" that are neither common nor reasonable. Saying "all" without qualifiers is asking for trouble. I was happier with the first wording, which actually used the word "reasonable". Thanks, Phil From randy_presuhn@mindspring.com Fri Nov 18 10:00:49 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2921F8A67 for ; Fri, 18 Nov 2011 10:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.634 X-Spam-Level: X-Spam-Status: No, score=-102.634 tagged_above=-999 required=5 tests=[AWL=-0.035, 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 KOF+Bvw7-oJk for ; Fri, 18 Nov 2011 10:00:49 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 14DF521F89BA for ; Fri, 18 Nov 2011 10:00:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=cPTtou9YpzKHC7gr4L3UGlMS+iEaJGfVoFDD+yXoEPcnqFRerLJzVHBA8AvcRPvz; 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.33.92.225] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RRSjZ-0003ec-Ct for netmod@ietf.org; Fri, 18 Nov 2011 13:00:17 -0500 Message-ID: <000a01cca61c$12d759e0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20111115035743.GF2731@nsn.com><20111118054853.GA29390@elstar.local> Date: Fri, 18 Nov 2011 10:01:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f8ddffb709b00070c5b975860f99a21d0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.92.225 Subject: Re: [netmod] Snmp configuration charter addition 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, 18 Nov 2011 18:00:49 -0000 Hi - > From: "David Spakes" > To: "Juergen Schoenwaelder" > Cc: > Sent: Friday, November 18, 2011 8:54 AM > Subject: Re: [netmod] Snmp configuration charter addition ... > Why not just stop the sentence after "modules"? i.e., > > 5. Data model for configuring SNMP engines. The model must be capable > of representing all SNMP engine configurations possible with the > standard SNMPv3 MIB modules. Any differences in functionality and > behavior should be documented. That would be fine with me, but I think we're trying to reach a compromise here that would allow the WG to introduce incompatibilities when they are found necessary. The sticking point is deciding which sorts of incompatibilities would be tolerable. Earlier versions set the threshold at "meaningful", the version proposed uses "operational practice". I find it quite ironic that "operational practice" appears to be a higher bar than "meaningful", at least as used in this discussion. Randy From reid@snmp.com Fri Nov 18 11:09:07 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436BE21F8B77 for ; Fri, 18 Nov 2011 11:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 PrFZIoyi2K3J for ; Fri, 18 Nov 2011 11:09:06 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 30EAA21F8B76 for ; Fri, 18 Nov 2011 11:09:06 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA19913; Fri, 18 Nov 2011 14:09:05 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA23184; Fri, 18 Nov 2011 14:09:00 -0500 (EST) Message-Id: <201111181909.OAA23184@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Fri, 18 Nov 2011 08:53:48 +0100. <20111118.085348.2121437773207982249.mbj@tail-f.com> Date: Fri, 18 Nov 2011 14:09:00 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smiv2 to yang mapping issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 19:09:07 -0000 > Hi, > > There is one more corner case in the type mapping algorithm. > Currently, both OCTET STRING (w/o DISPLAY-HINT) and Opaque maps to the > YANG type binary. But these are different types on-the-wire in SNMP, > so an implementation that works off the generated YANG module does not > have enough information (e.g., the proxy use case I mentioned > earlier). It just sees a binary and doesn't now how to encode it in > the PDU. > > This can easily be solved by adding a typedef to ietf-yang-smiv2: > > typedef opaque { > type binary; > description > "The opaque type represents SMIv2 Opaque values."; > reference > "RFC 2578 ..."; > } > > and update the mapping table accordingly. > > > /martin That seems reasonable. I had not considered the Opaque case (we discourage the use of Opaque). -David Reid From reid@snmp.com Fri Nov 18 11:37:02 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBC31F0C47 for ; Fri, 18 Nov 2011 11:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 c7a88pxKbS0q for ; Fri, 18 Nov 2011 11:37:01 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEB71F0C42 for ; Fri, 18 Nov 2011 11:37:01 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA21445; Fri, 18 Nov 2011 14:37:00 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA23761; Fri, 18 Nov 2011 14:36:54 -0500 (EST) Message-Id: <201111181936.OAA23761@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Fri, 18 Nov 2011 06:48:55 +0100. <20111118054853.GA29390@elstar.local> Date: Fri, 18 Nov 2011 14:36:53 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 19:37:02 -0000 > Taking the recent discussion into account, here is a revised version > of the new charter text: > > 5. Data model for configuring SNMP engines. The model must be capable > of representing all SNMP engine configurations possible with the > standard SNMPv3 MIB modules that are common operational practice. > Any differences in functionality and behavior should be documented. > > Please let the working group know how you feel about this text, and if > you don't agree, propose alternative text that addresses your > concerns. Since we like to move forward with this (we have been stuck > on this for a while now), please raise any concerns by November 28. I agree with this proposed text. -David Reid From spakes@snmp.com Fri Nov 18 11:38:31 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BCF1F0C4A for ; Fri, 18 Nov 2011 11:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ZD6yUhV0+KT1 for ; Fri, 18 Nov 2011 11:38:30 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 651191F0C42 for ; Fri, 18 Nov 2011 11:38:30 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA21757; Fri, 18 Nov 2011 14:38:29 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id OAA23828; Fri, 18 Nov 2011 14:38:24 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Fri, 18 Nov 2011 14:38:23 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Randy Presuhn In-Reply-To: <000a01cca61c$12d759e0$6b01a8c0@oemcomputer> Message-ID: References: <20111115035743.GF2731@nsn.com><20111118054853.GA29390@elstar.local> <000a01cca61c$12d759e0$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] Snmp configuration charter addition 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, 18 Nov 2011 19:38:31 -0000 I see. Yes, it's a difficult definition to nail down. What is meaningful to one deployment may not be meaningful to another deployment. Current common operational practice, for example, would include the configuring of USM users that are not members of any VACM group. Why? Because they are used for cloning purposes only (RFC 3414, page 40). Some configurations I have seen are meaningful but only to the deployments that make special use of them. For example, I know of one large company that configures VACM views that are not connected to any VACM group. Why? Because they connect the views in a proprietary way to RFC 3413 snmpProxyTable entries, allowing them to conditionally forward SNMP packets based on the payload. Packets carrying sensitive data that is not contained within the authorized view aren't forwarded...it's a nice little security enhancement. -dss On Fri, 18 Nov 2011, Randy Presuhn wrote: > Hi - > > > From: "David Spakes" > > To: "Juergen Schoenwaelder" > > Cc: > > Sent: Friday, November 18, 2011 8:54 AM > > Subject: Re: [netmod] Snmp configuration charter addition > ... > > Why not just stop the sentence after "modules"? i.e., > > > > 5. Data model for configuring SNMP engines. The model must be capable > > of representing all SNMP engine configurations possible with the > > standard SNMPv3 MIB modules. Any differences in functionality and > > behavior should be documented. > > That would be fine with me, but I think we're trying to reach a compromise > here that would allow the WG to introduce incompatibilities when they > are found necessary. The sticking point is deciding which sorts of > incompatibilities would be tolerable. Earlier versions set the threshold > at "meaningful", the version proposed uses "operational practice". > I find it quite ironic that "operational practice" appears to be a higher > bar than "meaningful", at least as used in this discussion. > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From reid@snmp.com Fri Nov 18 12:08:33 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093D41F0C73 for ; Fri, 18 Nov 2011 12:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 cfzVWXSRWyDA for ; Fri, 18 Nov 2011 12:08:32 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 549371F0C40 for ; Fri, 18 Nov 2011 12:08:31 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA23585; Fri, 18 Nov 2011 15:08:22 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA24743; Fri, 18 Nov 2011 15:08:18 -0500 (EST) Message-Id: <201111182008.PAA24743@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Fri, 18 Nov 2011 03:41:11 +0100. <20111118024110.GA28286@elstar.local> Date: Fri, 18 Nov 2011 15:08:17 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 20:08:33 -0000 > On Thu, Nov 17, 2011 at 10:01:43AM -0500, David Reid wrote: > > > On Tue, Nov 15, 2011 at 12:17:08PM -0500, David Reid wrote: > > > > > > > > > > Clarification question: Is a translator allowed / required / ... to produce both > > > > > smiv2:oid and smiv2:subid statements? > > > > > > > > The point was to make it easier for the human reader and > > > > writer. Requiring both would make it harder, so I don't think that > > > > would be the right answer. > > > > > > Who is the human writer here? > > > > I use these extensions in some cases to manually assign OIDs to objects > > defined in yang modules so that I can access them from SNMP. > > > > > The goal of this effort is to translate > > > SMIv2 MIB modules to YANG. > > > > Yes. What I'm doing is really outside the scope of this effort. But to the > > extent that I can use standard extensions defined in this document rather > > than create my own proprietary ones, that is helpful, especially if more than > > one company is doing that. > > But since we are specifying a translation algorithm, I think it is > fine to have a translator generate the full OID, no? Yes, that's fine. I know that some of what I'm doing is outside the scope of this document. > If you want to > use the extension for other purposes, fine. It is then your choice > whether you used smiv2:oid or smiv2:subid. > I can't really use smiv2:oid if the description says it has to be the full OID. I could use smiv2:subid if we added such a thing. Or I could use a proprietary extension. > /js -David Reid From randy_presuhn@mindspring.com Fri Nov 18 12:17:11 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1B521F8AE9 for ; Fri, 18 Nov 2011 12:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffD2D413dABd for ; Fri, 18 Nov 2011 12:17:10 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7701421F8AE6 for ; Fri, 18 Nov 2011 12:17:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=J/KPx7tTYq0pAmQu7QRuEPyY/IGAR0Ht0/240xhW0DZuBkDM44+TObTNwWn1+TWx; 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.35.225.219] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RRUrz-0005Qr-Ul for netmod@ietf.org; Fri, 18 Nov 2011 15:17:08 -0500 Message-ID: <000601cca62f$31423cc0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20111115035743.GF2731@nsn.com><20111118054853.GA29390@elstar.local> <000a01cca61c$12d759e0$6b01a8c0@oemcomputer> Date: Fri, 18 Nov 2011 12:18:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f38d0123c59ef941e46967a7bf51c89fa350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.225.219 Subject: Re: [netmod] Snmp configuration charter addition 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, 18 Nov 2011 20:17:11 -0000 Hi - > From: "David Spakes" > To: "Randy Presuhn" > Cc: "David Spakes" ; > Sent: Friday, November 18, 2011 11:38 AM > Subject: Re: [netmod] Snmp configuration charter addition > > I see. Yes, it's a difficult definition to nail down. What is meaningful > to one deployment may not be meaningful to another deployment. > > Current common operational practice, for example, would include the > configuring of USM users that are not members of any VACM group. Why? > Because they are used for cloning purposes only (RFC 3414, page 40). > > Some configurations I have seen are meaningful but only to the deployments > that make special use of them. For example, I know of one large company > that configures VACM views that are not connected to any VACM group. > Why? Because they connect the views in a proprietary way to RFC 3413 > snmpProxyTable entries, allowing them to conditionally forward SNMP > packets based on the payload. Packets carrying sensitive data that is > not contained within the authorized view aren't forwarded...it's a nice > little security enhancement. ... Excellent points. Any divergence from what the existing MIBs allow should be undertaken only with extreme caution. The language Juergen proposed seems good enough for compromise purposes, but will require folks like you, Shawn, Wes, and so on to monitor this work closely. As your examples demonstrate, the repercussions of a change won't always be immediately obvious to those not intimately familiar with SNMP engines and how they are actually used. Randy From mbj@tail-f.com Fri Nov 18 12:45:12 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43A311E80DD for ; Fri, 18 Nov 2011 12:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.042, 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 g3CU6BdRZK1h for ; Fri, 18 Nov 2011 12:45:12 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4306711E80C3 for ; Fri, 18 Nov 2011 12:45:12 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id BAD5D1200D46; Fri, 18 Nov 2011 21:45:09 +0100 (CET) Date: Fri, 18 Nov 2011 21:45:08 +0100 (CET) Message-Id: <20111118.214508.484057345.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20111118054853.GA29390@elstar.local> References: <20111115035743.GF2731@nsn.com> <20111118054853.GA29390@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] Snmp configuration charter addition 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, 18 Nov 2011 20:45:12 -0000 Juergen Schoenwaelder wrote: > On Mon, Nov 14, 2011 at 07:57:43PM -0800, David Kessens wrote: > > > I have reviewed the discussion and would like to propose the > > following text: > > > > 5. Data model for configuring SNMP engines. The model must be capable of > > representing all meaningful SNMP engine configurations possible with the > > standard SNMPv3 MIB modules. Any differences in functionality and > > behavior should be documented. > > > > Please let the working group think how you feel about this text, and if you > > don't agree, propose alternative text that addresses your concerns. > > Taking the recent discussion into account, here is a revised version > of the new charter text: > > 5. Data model for configuring SNMP engines. The model must be capable > of representing all SNMP engine configurations possible with the > standard SNMPv3 MIB modules that are common operational practice. > Any differences in functionality and behavior should be documented. > > Please let the working group know how you feel about this text, and if > you don't agree, propose alternative text that addresses your > concerns. Since we like to move forward with this (we have been stuck > on this for a while now), please raise any concerns by November 28. This text is ok for me. /martin From mbj@tail-f.com Fri Nov 18 12:46:43 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B727D11E80DD for ; Fri, 18 Nov 2011 12:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.040, 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 vI3EsanHEeIk for ; Fri, 18 Nov 2011 12:46:43 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3435011E80DE for ; Fri, 18 Nov 2011 12:46:43 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 44AE11200D46; Fri, 18 Nov 2011 21:46:42 +0100 (CET) Date: Fri, 18 Nov 2011 21:46:41 +0100 (CET) Message-Id: <20111118.214641.463198242.mbj@tail-f.com> To: spakes@snmp.com From: Martin Bjorklund In-Reply-To: References: <000a01cca61c$12d759e0$6b01a8c0@oemcomputer> 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] Snmp configuration charter addition 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, 18 Nov 2011 20:46:43 -0000 Hi, David Spakes wrote: > I see. Yes, it's a difficult definition to nail down. What is meaningful > to one deployment may not be meaningful to another deployment. > > Current common operational practice, for example, would include the > configuring of USM users that are not members of any VACM group. Why? > Because they are used for cloning purposes only (RFC 3414, page 40). > > Some configurations I have seen are meaningful but only to the deployments > that make special use of them. For example, I know of one large company > that configures VACM views that are not connected to any VACM group. > Why? Because they connect the views in a proprietary way to RFC 3413 > snmpProxyTable entries, allowing them to conditionally forward SNMP > packets based on the payload. Packets carrying sensitive data that is > not contained within the authorized view aren't forwarded...it's a nice > little security enhancement. FWIW, the current document supports both these use cases. /martin From j.schoenwaelder@jacobs-university.de Sat Nov 19 04:00:37 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA9E21F8540 for ; Sat, 19 Nov 2011 04:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 ZyZYTRQI-zXT for ; Sat, 19 Nov 2011 04:00:37 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D263121F84F8 for ; Sat, 19 Nov 2011 04:00:36 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33D8120D71; Sat, 19 Nov 2011 13:00:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yv4W6WXmhWkm; Sat, 19 Nov 2011 13:00:35 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6FFE20D50; Sat, 19 Nov 2011 13:00:34 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 29D531BBB360; Sat, 19 Nov 2011 13:00:18 +0100 (CET) Date: Sat, 19 Nov 2011 13:00:18 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20111119120018.GA31698@elstar.local> Mail-Followup-To: David Spakes , netmod@ietf.org References: <20111117065745.GD26328@elstar.local> <20111118030345.GC28368@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] smi2yang-16: smiv2:oid oid representations [open] 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: Sat, 19 Nov 2011 12:00:37 -0000 On Fri, Nov 18, 2011 at 11:49:10AM -0500, David Spakes wrote: > On Fri, 18 Nov 2011, Juergen Schoenwaelder wrote: > > > > The beauty of the subid approach is that it reflects and compliments the > > > preservation of logical collections of objects. Whether the reader of the > > > translated YANG document is human or machine, a subid statement affirms > > > the logical collection (i.e., the 'normal' case) and an oid statement > > > below the top level screams "pay special attention". > > > > I do not care about the implementation aspects in the translator. I > > care about making postprocessing of YANG modules harder than it needs > > to be. > > About which are you mainly concerned? > Postprocessing by an application that knows about/cares about SNMP? > Postprocessing by an application does doesn't know about/care about SNMP? Making the OID accessible as an OID seems really simple to me. /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 Sat Nov 19 04:10:07 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E601B21F8876 for ; Sat, 19 Nov 2011 04:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=0.063, 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 nqHvqyUYHjTh for ; Sat, 19 Nov 2011 04:10:07 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2010121F886A for ; Sat, 19 Nov 2011 04:10:07 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7600520D88; Sat, 19 Nov 2011 13:10:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sRDyyLkJwiba; Sat, 19 Nov 2011 13:10:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14DFF20D7D; Sat, 19 Nov 2011 13:10:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8B8F81BBB428; Sat, 19 Nov 2011 13:09:48 +0100 (CET) Date: Sat, 19 Nov 2011 13:09:48 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111119120948.GC31698@elstar.local> Mail-Followup-To: Martin Bjorklund , reid@snmp.com, netmod@ietf.org References: <20111114094130.GB17498@elstar.local> <201111171542.KAA28189@adminfs.snmp.com> <20111118030617.GD28368@elstar.local> <20111118.085348.2121437773207982249.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111118.085348.2121437773207982249.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smiv2 to yang mapping issues 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: Sat, 19 Nov 2011 12:10:08 -0000 On Fri, Nov 18, 2011 at 08:53:48AM +0100, Martin Bjorklund wrote: > Hi, > > There is one more corner case in the type mapping algorithm. > Currently, both OCTET STRING (w/o DISPLAY-HINT) and Opaque maps to the > YANG type binary. But these are different types on-the-wire in SNMP, > so an implementation that works off the generated YANG module does not > have enough information (e.g., the proxy use case I mentioned > earlier). It just sees a binary and doesn't now how to encode it in > the PDU. > > This can easily be solved by adding a typedef to ietf-yang-smiv2: > > typedef opaque { > type binary; > description > "The opaque type represents SMIv2 Opaque values."; > reference > "RFC 2578 ..."; > } > > and update the mapping table accordingly. Makes sense. Since Opaque is officially not to be used I think it is fine to have a matching type defined in the ietf-yang-smiv2 module. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Sat Nov 19 05:36:30 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E18E21F899D for ; Sat, 19 Nov 2011 05:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.039, 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 2HEOmfdbo6qG for ; Sat, 19 Nov 2011 05:36:30 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E4AA221F891D for ; Sat, 19 Nov 2011 05:36:27 -0800 (PST) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 0BFE31200D22; Sat, 19 Nov 2011 14:36:25 +0100 (CET) Date: Sat, 19 Nov 2011 14:36:23 +0100 (CET) Message-Id: <20111119.143623.360324429.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <201111181909.OAA23184@adminfs.snmp.com> References: <20111118.085348.2121437773207982249.mbj@tail-f.com> <201111181909.OAA23184@adminfs.snmp.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smiv2 to yang mapping 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: Sat, 19 Nov 2011 13:36:30 -0000 David Reid wrote: > > Hi, > > > > There is one more corner case in the type mapping algorithm. > > Currently, both OCTET STRING (w/o DISPLAY-HINT) and Opaque maps to the > > YANG type binary. But these are different types on-the-wire in SNMP, > > so an implementation that works off the generated YANG module does not > > have enough information (e.g., the proxy use case I mentioned > > earlier). It just sees a binary and doesn't now how to encode it in > > the PDU. > > > > This can easily be solved by adding a typedef to ietf-yang-smiv2: > > > > typedef opaque { > > type binary; > > description > > "The opaque type represents SMIv2 Opaque values."; > > reference > > "RFC 2578 ..."; > > } > > > > and update the mapping table accordingly. > > > > > > /martin > > That seems reasonable. I had not considered the Opaque case (we discourage > the use of Opaque). Yes it is not normally used, but there are some std mibs that actually use it (ALARM-MIB for example) so we should support it. /martin From reid@snmp.com Sat Nov 19 06:34:46 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B6C21F8551 for ; Sat, 19 Nov 2011 06:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 UHgA9BxwEQkV for ; Sat, 19 Nov 2011 06:34:46 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id B138521F854D for ; Sat, 19 Nov 2011 06:34:45 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA29408; Sat, 19 Nov 2011 09:34:39 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id JAA05153; Sat, 19 Nov 2011 09:34:34 -0500 (EST) Message-Id: <201111191434.JAA05153@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Sat, 19 Nov 2011 14:36:23 +0100. <20111119.143623.360324429.mbj@tail-f.com> Date: Sat, 19 Nov 2011 09:34:34 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smiv2 to yang mapping issues X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 14:34:46 -0000 > David Reid wrote: > > > Hi, > > > > > > There is one more corner case in the type mapping algorithm. > > > Currently, both OCTET STRING (w/o DISPLAY-HINT) and Opaque maps to the > > > YANG type binary. But these are different types on-the-wire in SNMP, > > > so an implementation that works off the generated YANG module does not > > > have enough information (e.g., the proxy use case I mentioned > > > earlier). It just sees a binary and doesn't now how to encode it in > > > the PDU. > > > > > > This can easily be solved by adding a typedef to ietf-yang-smiv2: > > > > > > typedef opaque { > > > type binary; > > > description > > > "The opaque type represents SMIv2 Opaque values."; > > > reference > > > "RFC 2578 ..."; > > > } > > > > > > and update the mapping table accordingly. > > > > > > > > > /martin > > > > That seems reasonable. I had not considered the Opaque case (we discourage > > the use of Opaque). > > Yes it is not normally used, but there are some std mibs that actually > use it (ALARM-MIB for example) so we should support it. > > > /martin I agree. -David Reid From andy@netconfcentral.org Sun Nov 20 13:12:17 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D9021F8678 for ; Sun, 20 Nov 2011 13:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, 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 6U3R83pVyQtb for ; Sun, 20 Nov 2011 13:12:17 -0800 (PST) Received: from omr12.networksolutionsemail.com (omr12.networksolutionsemail.com [205.178.146.62]) by ietfa.amsl.com (Postfix) with ESMTP id E742821F8663 for ; Sun, 20 Nov 2011 13:12:16 -0800 (PST) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr12.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pAKLCEGv014757 for ; Sun, 20 Nov 2011 16:12:16 -0500 Authentication-Results: cm-omr4 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:54840] helo=[192.168.0.9]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id F1/C5-04877-D2D69CE4; Sun, 20 Nov 2011 16:12:14 -0500 Message-ID: <4EC96D2D.3040507@netconfcentral.org> Date: Sun, 20 Nov 2011 13:12:13 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Kent Watsen References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" , NETMOD Working Group Subject: Re: [netmod] [Netconf] netconf yang module namespaces 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: Sun, 20 Nov 2011 21:12:17 -0000 On 10/24/2011 04:39 PM, Kent Watsen wrote: .... > Concrete example, we originally defined modules like this: > > > module hardware { > namespace "http://xml.juniper.net/dmi";<--- same namespace > prefix "dmi"; > revision "2008-11-05" { > ... > } > ... > } > module software { > namespace "http://xml.juniper.net/dmi";<--- same namespace > prefix "dmi"; > revision "2008-11-05" { > ... > } > ... > } > module license { > namespace "http://xml.juniper.net/dmi";<--- same namespace > prefix "dmi"; > revision "2008-11-05" { > ... > } > ... > } > Guess what? I had way too much time to think about stuff like this on my flight home, and I realized that what you are trying to do fits the current software world view wrt/ namespaces and solves the 'std' namespace update churn problem without the need to keep adding 'include-stmts' to a master container module. You are the centralized naming authority for xml.juniper.net. It should be perfectly valid for you to reuse the same namespace for multiple modules. (Makes the capability list in the hello really important). It assumes you know the difference between a cut-and-paste error and intended namespace sharing. Tools like yuma don't support this yet, but it wouldn't be that hard to support 1:N instead of 1:1 mappings. It means that submodules are seriously redundant and we should get rid of them. They don't work exactly the same as imported modules, just different enough to confuse people. It would require a new version of YANG (IMO) to allow this change. > Thanks, > Kent > Andy From j.schoenwaelder@jacobs-university.de Sun Nov 20 13:22:57 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21CE21F84A7; Sun, 20 Nov 2011 13:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.062, 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 Si7eLKxgmP57; Sun, 20 Nov 2011 13:22:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AC4D921F849C; Sun, 20 Nov 2011 13:22:56 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81A3620C70; Sun, 20 Nov 2011 22:22:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id x3B0dfp3r5z7; Sun, 20 Nov 2011 22:22:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1CCB20C6E; Sun, 20 Nov 2011 22:22:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E64561BBDE4F; Sun, 20 Nov 2011 22:22:36 +0100 (CET) Date: Sun, 20 Nov 2011 22:22:36 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20111120212236.GA37392@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , "netconf@ietf.org" , NETMOD Working Group References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> <4EC96D2D.3040507@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC96D2D.3040507@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" , NETMOD Working Group Subject: Re: [netmod] [Netconf] netconf yang module namespaces 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, 20 Nov 2011 21:22:57 -0000 On Sun, Nov 20, 2011 at 01:12:13PM -0800, Andy Bierman wrote: > On 10/24/2011 04:39 PM, Kent Watsen wrote: > .... > >Concrete example, we originally defined modules like this: > > > > > > module hardware { > > namespace "http://xml.juniper.net/dmi";<--- same namespace > > prefix "dmi"; > > revision "2008-11-05" { > > ... > > } > > ... > > } > > module software { > > namespace "http://xml.juniper.net/dmi";<--- same namespace > > prefix "dmi"; > > revision "2008-11-05" { > > ... > > } > > ... > > } > > module license { > > namespace "http://xml.juniper.net/dmi";<--- same namespace > > prefix "dmi"; > > revision "2008-11-05" { > > ... > > } > > ... > > } > > > > Guess what? > I had way too much time to think about stuff like this on my flight home, > and I realized that what you are trying to do fits the current software world view > wrt/ namespaces and solves the 'std' namespace update churn problem without > the need to keep adding 'include-stmts' to a master container module. > > You are the centralized naming authority for xml.juniper.net. > It should be perfectly valid for you to reuse the same namespace for multiple modules. > (Makes the capability list in the hello really important). It assumes > you know the difference between a cut-and-paste error and intended namespace sharing. > Tools like yuma don't support this yet, but it wouldn't be that hard > to support 1:N instead of 1:1 mappings. > > It means that submodules are seriously redundant and we should get rid of them. > They don't work exactly the same as imported modules, just different enough > to confuse people. > > It would require a new version of YANG (IMO) to allow this change. So what is the benefit of this compared to a solution in which submodules are announced in the exchange? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Sun Nov 20 13:49:18 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB181F0C34 for ; Sun, 20 Nov 2011 13:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 K6wB9+d7sYVb for ; Sun, 20 Nov 2011 13:49:17 -0800 (PST) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 741B01F0C44 for ; Sun, 20 Nov 2011 13:49:17 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pAKLnE9r019376 for ; Sun, 20 Nov 2011 16:49:16 -0500 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:54859] helo=[192.168.0.9]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 5C/1C-04600-9D579CE4; Sun, 20 Nov 2011 16:49:14 -0500 Message-ID: <4EC975D9.4040006@netconfcentral.org> Date: Sun, 20 Nov 2011 13:49:13 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Kent Watsen , "netconf@ietf.org" , NETMOD Working Group References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> <4EC96D2D.3040507@netconfcentral.org> <20111120212236.GA37392@elstar.local> In-Reply-To: <20111120212236.GA37392@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Netconf] netconf yang module namespaces 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: Sun, 20 Nov 2011 21:49:18 -0000 On 11/20/2011 01:22 PM, Juergen Schoenwaelder wrote: > On Sun, Nov 20, 2011 at 01:12:13PM -0800, Andy Bierman wrote: >> On 10/24/2011 04:39 PM, Kent Watsen wrote: >> .... >>> Concrete example, we originally defined modules like this: >>> >>> >>> module hardware { >>> namespace "http://xml.juniper.net/dmi";<--- same namespace >>> prefix "dmi"; >>> revision "2008-11-05" { >>> ... >>> } >>> ... >>> } >>> module software { >>> namespace "http://xml.juniper.net/dmi";<--- same namespace >>> prefix "dmi"; >>> revision "2008-11-05" { >>> ... >>> } >>> ... >>> } >>> module license { >>> namespace "http://xml.juniper.net/dmi";<--- same namespace >>> prefix "dmi"; >>> revision "2008-11-05" { >>> ... >>> } >>> ... >>> } >>> >> Guess what? >> I had way too much time to think about stuff like this on my flight home, >> and I realized that what you are trying to do fits the current software world view >> wrt/ namespaces and solves the 'std' namespace update churn problem without >> the need to keep adding 'include-stmts' to a master container module. >> >> You are the centralized naming authority for xml.juniper.net. >> It should be perfectly valid for you to reuse the same namespace for multiple modules. >> (Makes the capability list in the hello really important). It assumes >> you know the difference between a cut-and-paste error and intended namespace sharing. >> Tools like yuma don't support this yet, but it wouldn't be that hard >> to support 1:N instead of 1:1 mappings. >> >> It means that submodules are seriously redundant and we should get rid of them. >> They don't work exactly the same as imported modules, just different enough >> to confuse people. >> >> It would require a new version of YANG (IMO) to allow this change. > So what is the benefit of this compared to a solution in which > submodules are announced in the exchange? > > 1) simpler for readers/writers * just import, no include * submodules are flat, not nested like modules, which is confusing 2) no need to keep updating a main module with include-stmts 3) no changes to NETCONF needed at all 4) YANG version may not need to be updated if submodules retained and maybe extensions used An online registry of modules for each namespace could be maintained. Either way, the server must send a complete module capability list in the , and it is already outside the scope of the standard how YANG file locations are mapped to the URIs. IMO, it matches how Python and C++ treat namespaces and modules. They have no need or notion of submodules. > /js > Andy From j.schoenwaelder@jacobs-university.de Mon Nov 21 02:29:02 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C03021F8B64 for ; Mon, 21 Nov 2011 02:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.188 X-Spam-Level: X-Spam-Status: No, score=-103.188 tagged_above=-999 required=5 tests=[AWL=0.061, 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 MI3pQghGxOD6 for ; Mon, 21 Nov 2011 02:28:58 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D13B421F8B62 for ; Mon, 21 Nov 2011 02:28:57 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id F35B320C8F; Mon, 21 Nov 2011 11:28:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Sih28jTdYjsW; Mon, 21 Nov 2011 11:28:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4E8A20C83; Mon, 21 Nov 2011 11:28:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CD39F1BBE56D; Mon, 21 Nov 2011 11:28:37 +0100 (CET) Date: Mon, 21 Nov 2011 11:28:37 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20111121102837.GB38525@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , NETMOD Working Group References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> <4EC96D2D.3040507@netconfcentral.org> <20111120212236.GA37392@elstar.local> <4EC975D9.4040006@netconfcentral.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC975D9.4040006@netconfcentral.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: NETMOD Working Group Subject: Re: [netmod] [Netconf] netconf yang module namespaces 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, 21 Nov 2011 10:29:02 -0000 On Sun, Nov 20, 2011 at 01:49:13PM -0800, Andy Bierman wrote: [...] > >So what is the benefit of this compared to a solution in which > >submodules are announced in the exchange? > > 1) simpler for readers/writers > * just import, no include > * submodules are flat, not nested like modules, which is confusing I am not sure what "flat" means here - so I am confused. ;-) > 2) no need to keep updating a main module with include-stmts > 3) no changes to NETCONF needed at all Did we not agreed that neither solution requires changes to NETCONF? > 4) YANG version may not need to be updated if submodules retained > and maybe extensions used > > An online registry of modules for each namespace could be maintained. But then this online registry almost mimics the main module with include-stmts, no? > Either way, the server must send a complete module capability list > in the , and it is already outside the scope of the standard > how YANG file locations are mapped to the URIs. Submodules allow a compiler to check what is in a namespace and in particular that the namespace is collision free. My understanding is that this feature would be lost. Submodules require you to be specific about what is in your namespace. > IMO, it matches how Python and C++ treat namespaces and modules. > They have no need or notion of submodules. [... JS is not sure this is correct but long discussion removed ...] The question for me is whether we want YANG compilers to be able to detect any collisions in the module namespaces at module compile time or not. YANG was originally designed to be able to do that. -- break -- Let me see the difference by walking through an example (perhaps this helps others as well). Suppose we have two modules A and B, both implementing the namespace http://example.com/foo. Then the would look like this: http://example.com/foo?module=A&revision=2008-04-01 http://example.com/foo?module=B&revision=2009-04-01 If both A and B contain a typedef for 't', YANG compilers would not catch this. If I understand correctly, the alternative would be to extend YANG such that submodules are announced as well in the . Then we would get (assuming M is a module importing submodules A and B): http://example.com/foo?module=M&revision=2010-04-01 http://example.com/foo?submodule=A&revision=2008-04-01 http://example.com/foo?submodule=B&revision=2009-04-01 If both A and B contain a typedef for 't', a YANG compiler will detect this when compiling M. Of course, there are additional questions like can I announce submodule specific features or deviations that would need to be answered and what happens if I announce submodules that are inconsistent with the module definition or what happens if the same namespace is announced with multiple modules. But some of these questions are orthogonal to the question whether we go down the road of ad-hoc shared namespaces or controlled sharing of namespaces using submodules. /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@cesnet.cz Mon Nov 21 04:43:59 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33D921F8C16 for ; Mon, 21 Nov 2011 04:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxtZ2eR0HSyf for ; Mon, 21 Nov 2011 04:43:46 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id CE0D221F8C18 for ; Mon, 21 Nov 2011 04:43:44 -0800 (PST) Received: from ws-eduroam-57.cesnet.cz (ws-eduroam-57.cesnet.cz [195.113.238.57]) by office2.cesnet.cz (Postfix) with ESMTPSA id 7C8A82CDE05B; Mon, 21 Nov 2011 13:43:40 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_8DAA1049-0819-4AF8-9461-2D51BFA4462F"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111121102837.GB38525@elstar.local> Date: Mon, 21 Nov 2011 13:43:39 +0100 Message-Id: References: <4EA48278.30001@andybierman.com> <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> <4EC96D2D.3040507@netconfcentral.org> <20111120212236.GA37392@elstar.local> <4EC975D9.4040006@netconfcentral.org> <20111121102837.GB38525@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1251.1) Cc: NETMOD Working Group Subject: Re: [netmod] [Netconf] netconf yang module namespaces 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, 21 Nov 2011 12:43:59 -0000 --Apple-Mail=_8DAA1049-0819-4AF8-9461-2D51BFA4462F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I am using YANG submodules in my non-IETF work and they work fine for = me. So I have to ask again: What is the problem that any of the proposed = changes are supposed to solve? If the only argument is that many namespaces are difficult to read, then = it is merely a marginal optimization and I am against it. We have more = serious problems to discuss. The charter says that the WG will not work on another version of YANG = and IMO we should stick to this promise, unless we run at a real = showstopper. Let's first finish the work we have on the table.=20 Lada On Nov 21, 2011, at 11:28 AM, Juergen Schoenwaelder wrote: > On Sun, Nov 20, 2011 at 01:49:13PM -0800, Andy Bierman wrote: >=20 > [...] >=20 >>> So what is the benefit of this compared to a solution in which >>> submodules are announced in the exchange? >>=20 >> 1) simpler for readers/writers >> * just import, no include >> * submodules are flat, not nested like modules, which is confusing >=20 > I am not sure what "flat" means here - so I am confused. ;-) >=20 >> 2) no need to keep updating a main module with include-stmts >> 3) no changes to NETCONF needed at all >=20 > Did we not agreed that neither solution requires changes to NETCONF? >=20 >> 4) YANG version may not need to be updated if submodules retained >> and maybe extensions used >>=20 >> An online registry of modules for each namespace could be maintained. >=20 > But then this online registry almost mimics the main module with > include-stmts, no? >=20 >> Either way, the server must send a complete module capability list >> in the , and it is already outside the scope of the standard >> how YANG file locations are mapped to the URIs. >=20 > Submodules allow a compiler to check what is in a namespace and in > particular that the namespace is collision free. My understanding is > that this feature would be lost. Submodules require you to be specific > about what is in your namespace. >=20 >> IMO, it matches how Python and C++ treat namespaces and modules. >> They have no need or notion of submodules. >=20 > [... JS is not sure this is correct but long discussion removed ...] >=20 > The question for me is whether we want YANG compilers to be able to > detect any collisions in the module namespaces at module compile time > or not. YANG was originally designed to be able to do that. >=20 > -- break -- >=20 > Let me see the difference by walking through an example (perhaps this > helps others as well). Suppose we have two modules A and B, both > implementing the namespace http://example.com/foo. Then the > would look like this: >=20 > > > http://example.com/foo?module=3DA&revision=3D2008-04-01 > > > http://example.com/foo?module=3DB&revision=3D2009-04-01 > > >=20 > If both A and B contain a typedef for 't', YANG compilers would not > catch this. >=20 > If I understand correctly, the alternative would be to extend YANG > such that submodules are announced as well in the . Then we > would get (assuming M is a module importing submodules A and B): >=20 > > > http://example.com/foo?module=3DM&revision=3D2010-04-01 > > > http://example.com/foo?submodule=3DA&revision=3D2008-04-01 > > > http://example.com/foo?submodule=3DB&revision=3D2009-04-01 > > >=20 > If both A and B contain a typedef for 't', a YANG compiler will > detect this when compiling M. >=20 > Of course, there are additional questions like can I announce > submodule specific features or deviations that would need to be > answered and what happens if I announce submodules that are > inconsistent with the module definition or what happens if the same > namespace is announced with multiple modules. But some of these > questions are orthogonal to the question whether we go down the road > of ad-hoc shared namespaces or controlled sharing of namespaces using > submodules. >=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, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_8DAA1049-0819-4AF8-9461-2D51BFA4462F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTIxMTI0MzQwWjAjBgkqhkiG9w0BCQQxFgQUzGbZFHs6wO/AonCxmLlLChHdyywwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQBjgkXKSfwCNoFMwgocLTq8vocj PlEldPMu/nkFoeowu+0TV4X4EShOB+PjrgiA2qC+gpRKtI6BjwpFdx8csUlHW2nY3LE9altXkk7M D8NW7YKVejvK9hRPFBY2oX/sRB5X+RyeLIFaFgycvx0PZzbwEmLJAr27ow+kY/dzwruBbcXO738F agzHCY+PoXchasoB461zH02fyKlAtUlIvajylIHk43DnxHAf09S+OBhNjnmC7uAGcG8hFqfujPHV A94xZRQ04brM7SlxDzS3KYIQiM7582fDeaEEdpcU6paToeHMJez70UDu4/aSGFHtZ6dJO/r3pVAY DOptAig71RLLAAAAAAAA --Apple-Mail=_8DAA1049-0819-4AF8-9461-2D51BFA4462F-- From j.schoenwaelder@jacobs-university.de Mon Nov 21 05:51:22 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73CE21F8B1A for ; Mon, 21 Nov 2011 05:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 5lpTp51QT3Q3 for ; Mon, 21 Nov 2011 05:51:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8847711E80A1 for ; Mon, 21 Nov 2011 05:51:18 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAAD920C97; Mon, 21 Nov 2011 14:51:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id t_gL6tWhwaYt; Mon, 21 Nov 2011 14:51:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB49C20C82; Mon, 21 Nov 2011 14:51:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E8C071BBEEDD; Mon, 21 Nov 2011 14:50:53 +0100 (CET) Date: Mon, 21 Nov 2011 14:50:53 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20111121135051.GB39529@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , NETMOD Working Group References: <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> <4EC96D2D.3040507@netconfcentral.org> <20111120212236.GA37392@elstar.local> <4EC975D9.4040006@netconfcentral.org> <20111121102837.GB38525@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 Working Group Subject: Re: [netmod] [Netconf] netconf yang module namespaces 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, 21 Nov 2011 13:51:23 -0000 On Mon, Nov 21, 2011 at 01:43:39PM +0100, Ladislav Lhotka wrote: > Hi, > > I am using YANG submodules in my non-IETF work and they work fine > for me. So I have to ask again: What is the problem that any of the > proposed changes are supposed to solve? > > If the only argument is that many namespaces are difficult to read, > then it is merely a marginal optimization and I am against it. We > have more serious problems to discuss. I personally do believe that dealing with too many namespaces scales badly. Think where we are in 10-15 years. You might nor might not agree. And what we have produced so far as YANG modules for NETCONF is rather unorganized in terms of namespaces and common roots, which also has implications on usability. For me it is a rather fundamental question how we plan to structure our data models and to what extend we expose the procedural reality of IETF processes to people who's main task is to write applications. Anyway, my concern how we organize things triggered the question whether submodules help. After all, they were designed to provide modularity within a single namespace. Apparently, there are concerns with submodules since they are "invisible", that is they are not announced (with version information) during the exchange. I am trying to understand whether this is a major problem (Andy clearly said yes, apparently based on practical experience) and if so what to do about this. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@netconfcentral.org Mon Nov 21 06:55:41 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FDF1F0C57 for ; Mon, 21 Nov 2011 06:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, 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 OUYxldWrnSAL for ; Mon, 21 Nov 2011 06:55:41 -0800 (PST) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id AF0761F0C4F for ; Mon, 21 Nov 2011 06:55:40 -0800 (PST) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id pALEtb0r023581 for ; Mon, 21 Nov 2011 09:55:39 -0500 Authentication-Results: cm-omr10 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:56598] helo=[192.168.0.9]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 89/8C-04600-8666ACE4; Mon, 21 Nov 2011 09:55:37 -0500 Message-ID: <4ECA6668.4010006@netconfcentral.org> Date: Mon, 21 Nov 2011 06:55:36 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Ladislav Lhotka , NETMOD Working Group References: <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> <4EC96D2D.3040507@netconfcentral.org> <20111120212236.GA37392@elstar.local> <4EC975D9.4040006@netconfcentral.org> <20111121102837.GB38525@elstar.local> <20111121135051.GB39529@elstar.local> In-Reply-To: <20111121135051.GB39529@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] [Netconf] netconf yang module namespaces 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, 21 Nov 2011 14:55:41 -0000 On 11/21/2011 05:50 AM, Juergen Schoenwaelder wrote: > On Mon, Nov 21, 2011 at 01:43:39PM +0100, Ladislav Lhotka wrote: >> Hi, >> >> I am using YANG submodules in my non-IETF work and they work fine >> for me. So I have to ask again: What is the problem that any of the >> proposed changes are supposed to solve? >> >> If the only argument is that many namespaces are difficult to read, >> then it is merely a marginal optimization and I am against it. We >> have more serious problems to discuss. > I personally do believe that dealing with too many namespaces scales > badly. Think where we are in 10-15 years. You might nor might not > agree. And what we have produced so far as YANG modules for NETCONF is > rather unorganized in terms of namespaces and common roots, which also > has implications on usability. For me it is a rather fundamental > question how we plan to structure our data models and to what extend > we expose the procedural reality of IETF processes to people who's > main task is to write applications. > > Anyway, my concern how we organize things triggered the question > whether submodules help. After all, they were designed to provide > modularity within a single namespace. Apparently, there are concerns > with submodules since they are "invisible", that is they are not > announced (with version information) during the exchange. I am > trying to understand whether this is a major problem (Andy clearly > said yes, apparently based on practical experience) and if so what to > do about this. > There is a big difference between the NETMOD WG putting 4 or 5 submodules in an RFC, and a vendor putting 150 submodules in a kitchen sink data model. I do not see any problem at all with the way the NETMOD WG is using submodules. > /js > Andy From lhotka@cesnet.cz Mon Nov 21 08:33:11 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFD311E80BD for ; Mon, 21 Nov 2011 08:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE937AlSl0FB for ; Mon, 21 Nov 2011 08:33:06 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by ietfa.amsl.com (Postfix) with ESMTP id 3B08811E809F for ; Mon, 21 Nov 2011 08:33:06 -0800 (PST) Received: from ws-eduroam-57.cesnet.cz (ws-eduroam-57.cesnet.cz [195.113.238.57]) by office2.cesnet.cz (Postfix) with ESMTPSA id 006D32CDE05C; Mon, 21 Nov 2011 17:33:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_34AF4911-505B-4FD1-84AC-D62C571532A1"; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka In-Reply-To: <20111121135051.GB39529@elstar.local> Date: Mon, 21 Nov 2011 17:33:03 +0100 Message-Id: References: <4EA522CC.8080202@cesnet.cz> <84600D05C20FF943918238042D7670FD41BEF21B8E@EMBX01-HQ.jnpr.net> <20111024.232811.169019089.mbj@tail-f.com> <4EA5E080.4010703@andybierman.com> <84600D05C20FF943918238042D7670FD41BEF21DC1@EMBX01-HQ.jnpr.net> <4EC96D2D.3040507@netconfcentral.org> <20111120212236.GA37392@elstar.local> <4EC975D9.4040006@netconfcentral.org> <20111121102837.GB38525@elstar.local> <20111121135051.GB39529@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1251.1) Cc: NETMOD Working Group Subject: Re: [netmod] [Netconf] netconf yang module namespaces 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, 21 Nov 2011 16:33:12 -0000 --Apple-Mail=_34AF4911-505B-4FD1-84AC-D62C571532A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 21, 2011, at 2:50 PM, Juergen Schoenwaelder wrote: > On Mon, Nov 21, 2011 at 01:43:39PM +0100, Ladislav Lhotka wrote: >> Hi, >>=20 >> I am using YANG submodules in my non-IETF work and they work fine >> for me. So I have to ask again: What is the problem that any of the >> proposed changes are supposed to solve? >>=20 >> If the only argument is that many namespaces are difficult to read, >> then it is merely a marginal optimization and I am against it. We >> have more serious problems to discuss. >=20 > I personally do believe that dealing with too many namespaces scales > badly. Think where we are in 10-15 years. You might nor might not > agree. And what we have produced so far as YANG modules for NETCONF is > rather unorganized in terms of namespaces and common roots, which also Why? All start with "urn:ietf:params:xml:ns:yang" and differ only in = their suffix, which is the module name. For the time being, we can quite = easily cope with the existing situation. And in 10-15 years? I think it will be necessary anyway to revise YANG = in more aspects than just this - and few of them have already been = identified (e.g. XPath functions). So let's postpone changes to = modules/submodules/namespaces to YANG 2.0, and then do the right thing - = hopefully we will know what it is by that time.=20 > has implications on usability. For me it is a rather fundamental > question how we plan to structure our data models and to what extend > we expose the procedural reality of IETF processes to people who's > main task is to write applications. >=20 > Anyway, my concern how we organize things triggered the question > whether submodules help. After all, they were designed to provide > modularity within a single namespace. Apparently, there are concerns > with submodules since they are "invisible", that is they are not This is an issue only if the main module revision cannot be changed with = each change in submodules. But if it is the case, I'd suggest NOT to = use submodules and use separate modules. Lada > announced (with version information) during the exchange. I am > trying to understand whether this is a major problem (Andy clearly > said yes, apparently based on practical experience) and if so what to > do about this. >=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, CESNET PGP Key ID: E74E8C0C --Apple-Mail=_34AF4911-505B-4FD1-84AC-D62C571532A1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISXzCCBGYw ggNOoAMCAQICEFEmCpMc4n+cw6VfeeByroIwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMRswGQYDVQQD ExJVVE4gLSBEQVRBQ29ycCBTR0MwHhcNMDUwNjA3MDgwOTEwWhcNMTkwNjI0MTkwNjMwWjBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVy bmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt/caM+byAAQtOeBOW+0fvGwPzbX6I7bO3psRM5ek KUx9k5+9SryT7QMa44/P5W1QWtaXKZRagLBJetsulf24yr83OC0ePpFBrXBWx/BPP+gynnTKyJBU 6cZfD3idmkA8Dqxhql4Uj56HoWpQ3NeaTq8Fs6ZxlJxxs1BgCscTnTgHhgKo6ahpJhiQq0ywTyOr Ok+E2N/On+Fpb7vXQtdrROTHre5tQV9yWnEIN7N5ZaRZoJQ39wAvDcKSctrQOHLbFKhFxF0qfbe0 1sTurM0TRLfJK91DACX6YblpalgjEbenM49WdVn1zSnXRrcKK2W200JvFbK4e/vv6V1T1TRaJwID AQABo4HYMIHVMB8GA1UdIwQYMBaAFFMy0bPPf/rg8aBdhU6S0p5FHbRPMB0GA1UdDgQWBBStvZh6 NLQm9/rEJlTvA73gJMtUGjAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zARBglghkgB hvhCAQEEBAMCAQIwIAYDVR0lBBkwFwYKKwYBBAGCNwoDAwYJYIZIAYb4QgQBMD0GA1UdHwQ2MDQw MqAwoC6GLGh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VVE4tREFUQUNvcnBTR0MuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQDG7lMXaBSyUSIekFgNlP298XDlhi3DNjGPVEhG5y0IN7xsCmDhDq1RNOAS k+m+uKu4JrTplj0oj65kB/7gAezF45HrGKDxdX7bCuafkduvrnXfI5Fo3RcAWkv/ZGxw6wEa0JDZ x6bWbfYT5P+1ydIeKsuxJUMmeNkwm04NHr5p79/q/i2zzPmw3bUUypHUsrWl+wEZo0d5n52MlYc0 +B84kto2phH6a+tr6dxFeBU5BtdNQeQhyNwvh9G3v0hgdaViyyTeO2GgKSCmvsVsnMTpCmki75E6 +iav0VtBpzri+DgHQqvBW/jObboPBD8yNKzcBCjXcDAUJgbE5JuY1c94MIIEijCCA3KgAwIBAgIQ J/TqEfR6hsRunbtuqRcHBzANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEUMBIGA1UEChML QWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYD VQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTA1MDYwNzA4MDkxMFoXDTIwMDUzMDEw NDgzOFowga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENp dHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51 c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgRW1haWwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyOYWk8n2rQTtiRjeu zcFgdbw5ZflKGkeiucxIzGqY1U01GbmkQuXOSeKKLx580jEHx060g2SdLinVomTEhb2FUTV5pE5o kHsceqSSqBfymBXyk8zJpDKVuwxPML2YoAuL5W4bokb6eLyib6tZXqUvz8rabaov66yhs2qqty5n NYt54R5piOLmRs2gpeq+C852OnoOm+r82idbPXMfIuZIYcZM82mxqC4bttQxICy8goqOpA6l14lD /BZarx1x1xFZ2rqHDa/68+HC8KTFZ4zW1lQ63gqkugN3s2XI/R7TdGKqGMpokx6hhX71R2XL+E1X KHTSNP8wtu72YjAUjCzrAgMBAAGjgeEwgd4wHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTL VBowHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMB Af8EBTADAQH/MHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FkZFRy dXN0RXh0ZXJuYWxDQVJvb3QuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwDQYJKoZIhvcNAQEFBQADggEBABnYiRFvKKymAKLnh8GbkAPb fqES/R7z4vABqZRUQmuaCcSgbdeQkgQDZnlDcfz4b6/bdkXiNxo93eRZBHisHPSDRvN6z1uEci3l RsG6GBEp88tJeYc8um0FnaRtaE+tchQ2qLmx/b/Pf/CkapQ1UI/PgW1Vsd1ZMErfbaCcZB9JfO82 u/TjafT4OY9arUuFOrcO7dPPDUSi+wS/5C9wjiX7WlQGs9DEvG2N+3MyLOmbhCQt1n+RemgCUB8O P03pzPW7Z+jcHC47/E7N/gKO46gTCqUmRGXpEPJNUqeu3D7KazJcQWz+9V2g6v/R+puGWG09lkfl /i6VBMIAzI6h8rswggScMIIDhKADAgECAhAGWegDYUvwJqZxSZQoL0N/MA0GCSqGSIb3DQEBBQUA MDsxCzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25h bCBDQTAeFw0xMTAxMTAwMDAwMDBaFw0xNDAxMDkyMzU5NTlaME0xCzAJBgNVBAYTAkNaMQ8wDQYD VQQKEwZDRVNORVQxGDAWBgNVBAMTD0xhZGlzbGF2IExob3RrYTETMBEGCSqGSIb3DQEJAhYENjA3 MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALy8tGCj6JnwiA2jiXYcaJpVkO1rIC3L eTeoYUY+HXTlPuR6OhdzWgSe96rIeCh0K7ueDmwkpU58OrusOcoeN5QrA+qhsuH8JHzlA3LQY5ON kGG2mF9f0SkxpFrmMEJbGRg/izByz1c9mSJEXXaqxLRtl+ZMVikv6jfMSapxbOnT2H/YIjFppJkv kcA5pVqhL27iOS/LXMgzepC2DkNWTPdrUC7djpRrPQcljecuLjQRxG96T4k55k/Rwc7SJmSKMOXy /b0apiifvP+PGPwYuqkMLr0/8NQoNLSqDMYNAuPdLK/J3a0iE/qT/dBzPYNcRVBFvx4upaWm7sgf EA93zfkCAwEAAaOCAYgwggGEMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2amMB0GA1Ud DgQWBBSZlGX/1YyEVy8ng8x3qaN2wWPHMzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAd BgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQICHTA/ BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3JnL1RFUkVOQVBlcnNvbmFs Q0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0cDovL2NydC50Y3MudGVyZW5h Lm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcwAYYaaHR0cDovL29jc3AudGNzLnRl cmVuYS5vcmcwNgYDVR0RBC8wLYEZbGFkaXNsYXYubGhvdGthQGNlc25ldC5jeoEQbGhvdGthQGNl c25ldC5jejANBgkqhkiG9w0BAQUFAAOCAQEAPdmMs3Mi+c/spD5WGxo+6SleqNCpbs8iLhwuH4ut ki+St6yvFgbaDKFdShGb1FhBoQ7PZ2npHhGnEF2x8sb4/poT21G7o/I23EW8VBdpyygN9mmJHKCz ZDn08thGH6jt5nEcYje18t7sPfXO3zcTy1koZw1XTAeM7l5yCzV2sx02CY1iDNRU/Bx/3zKjVdTZ xJnnFB2hnAmn1E9RwZPgG/0ms3SDefibbrtLdkW+IQtrs56FsqkFu1D0sDQvx3p04FltpmLe1QQl 5Mx2xZW6U6AtQGuiHHLQeoTc/AWYESO26iUjnyup/OtBzpDcLxFD36WefSEYo8x16mYgbvvylzCC BMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYT AlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYD VQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkw NTE4MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDIFdn1M2ojoZANz7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/Q JUU1+erLSvr72tPtRYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECG KD+/VgjiSumDouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51W JFuTuykuQ+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSb A/B/9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYwDgYD VR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEEAbIxAQIC HTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJz dC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcBAQRjMGEwOAYIKwYB BQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGllbnRfQ0EuY3J0MCUGCCsG AQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAGK6lT LxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+ZjKr+oBl2PpkDMvp1gziKu2uapQwT stQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+p AMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3Q yxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1JZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWher qQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9oMYICmTCCApUCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0G A1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgv Q38wCQYFKw4DAhoFAKCCAR8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTExMTIxMTYzMzA0WjAjBgkqhkiG9w0BCQQxFgQUTLNat+jwLEvTV3wMUkmrMbZhpUEwXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQBWfHurynA6NCDGX4po2f8CojcE FN2knhv5ki49lBRSXdJB6jKYvTs1RnMs1FJAp//0GvOFn8apY9zkBADJoCcgPBgyu5IaoWTafwkZ zLeQnpWHVVUqFh5bTmgyxJljM/EpvxkQiAJj7GvVt2FIDeJ9OZGcRpXwEfEj9GMvo5XSXlgZHPtM X5YkKvEuOWoA1yyujfDiubcVXSMjFlJR7BWfEgDpP+KtZ+Ydh3wXUiJ75rRAQPlnTyT+DTiqqqLh ZjdVjJdF8UJbvZopGf5O+K5N3qb12Sm/J+I6YxXDxbcGRPQkWG6k9atMuEzz2sWIOCJYWHgGkeTk rccGAoSGY94/AAAAAAAA --Apple-Mail=_34AF4911-505B-4FD1-84AC-D62C571532A1-- From j.schoenwaelder@jacobs-university.de Mon Nov 21 12:45:58 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9884111E80E1 for ; Mon, 21 Nov 2011 12:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=0.060, 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 TPHI0bkIWogj for ; Mon, 21 Nov 2011 12:45:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1889311E80DF for ; Mon, 21 Nov 2011 12:45:54 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4040E20D22 for ; Mon, 21 Nov 2011 21:45:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id A-rmo0sRXc2M; Mon, 21 Nov 2011 21:45:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFB9A20D03; Mon, 21 Nov 2011 21:45:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 37A181BD841F; Mon, 21 Nov 2011 21:45:29 +0100 (CET) Date: Mon, 21 Nov 2011 21:45:29 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20111121204529.GA89563@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] minutes of the Taipei meeting 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, 21 Nov 2011 20:45:58 -0000 Hi, I have uploaded draft minutes of the Taipei meeting: http://www.ietf.org/proceedings/82/minutes/netmod.txt Thanks to Giles Heron for taking detailed notes. Please send any necessary corrections to me or 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 j.schoenwaelder@jacobs-university.de Tue Nov 22 02:32:59 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684CD21F8D25 for ; Tue, 22 Nov 2011 02:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.059, 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 DL42yq3C9mkn for ; Tue, 22 Nov 2011 02:32:55 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 18D2421F8C46 for ; Tue, 22 Nov 2011 02:32:55 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0666E20EB4; Tue, 22 Nov 2011 11:32:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gifC6pzR5sSk; Tue, 22 Nov 2011 11:32:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F67920C8E; Tue, 22 Nov 2011 11:32:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C4EA21BD916B; Tue, 22 Nov 2011 11:32:34 +0100 (CET) Date: Tue, 22 Nov 2011 11:32:34 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20111122103234.GA94036@elstar.local> Mail-Followup-To: David Spakes , David Reid , 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] smi2yang-04: string vs. binary 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, 22 Nov 2011 10:32:59 -0000 On Thu, Nov 17, 2011 at 12:21:29PM -0500, David Spakes wrote: > If the group concensus is solution #04-01, I'd go along. However, I > favor solution #04-02. The first character of the value would indicate > to the NETCONF protocol receiver which element of the union applies. > > * If the first character is a double-quote, a string value follows, > and the leading double-quote is not part of the value. > > * If the first character is not a double-quote, the value is binary, > and the leading character is part of the encoded value. A native NETCONF implementation will not do this and it is out of scope for us to change NETCONF behaviour. I am closing this now in favour of solution #04-01. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Nov 22 14:22:15 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CA711E80E6 for ; Tue, 22 Nov 2011 14:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 RJw7JBvguENL for ; Tue, 22 Nov 2011 14:22:14 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5593E11E80EE for ; Tue, 22 Nov 2011 14:22:13 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 928FB20C9B; Tue, 22 Nov 2011 23:22:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nuy39E8_0YIw; Tue, 22 Nov 2011 23:22:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B93EB20C97; Tue, 22 Nov 2011 23:22:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 47E781BDA46D; Tue, 22 Nov 2011 23:21:54 +0100 (CET) Date: Tue, 22 Nov 2011 23:21:54 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111122222154.GB96457@elstar.local> Mail-Followup-To: David Reid , David Spakes , netmod@ietf.org References: <201111171703.MAA00344@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111171703.MAA00344@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-14: unflatten scalars [open] 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, 22 Nov 2011 22:22:15 -0000 On Thu, Nov 17, 2011 at 12:03:06PM -0500, David Reid wrote: [...] I am having some hard time to follow the discussion. It seems we mix up issues - the way we write down OIDs really has nothing to do with the question how many containers we generate and how we name them. And from previous discussions, we know that finding names is brittle since legal SMIv2 updates can cause incompatible results. This is why we dropped all the containers several months ago - for the sake of robustness. To resolve ambiguities (if a parent of object foo has two descriptors), I thought looking at the definition of foo might be a good heuristic. But, it is still a heuristic. And it turns out implementing it may not be that easy - I looked at the libsmi code and it does not maintain knowledge how an OID was defined. So to implement this solution, the frontend parser needs to be extended... This is not impossible to do but raises the bar quite a bit. While it is true that OID value expressions for OBJECT-TYPES that are not of the form { } are rare, other forms do for sure exist for notifications and MODULE-IDENTITY OIDs, even in IETF modules. I guess I am not so much concerned about IETF modules but more about the large number of enterprise modules - some of them I know look really creative. So where are we with this discussion? Is this a fair summary? 1) The toplevel container is named after the module. 2) All tables are directly below the toplevel container. 3) Augments must anyway be below the toplevel container, says YANG. 4) Scalars are moved into containers that are their parent. The name of that parent is identified in the following way: a) If the parent in the OID tree of the object has only a single descriptor, this name is used. b) Otherwise, if the OID of the object is defined in the form { } or { () }, then the parent is called . We assume that people do not make random changes while revising MIB modules - if they do we fail producing always the same YANG translation. c) Otherwise, if the parent does not have a descriptor or there are multiple descriptors left to choose from, the translation is aborted with a suitable explanation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From spakes@snmp.com Tue Nov 22 14:59:07 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976B91F0C62 for ; Tue, 22 Nov 2011 14:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 OAKTZPuZiSzg for ; Tue, 22 Nov 2011 14:59:06 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7636A1F0C47 for ; Tue, 22 Nov 2011 14:59:06 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA05400; Tue, 22 Nov 2011 17:59:04 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA28705; Tue, 22 Nov 2011 17:59:03 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Tue, 22 Nov 2011 17:59:02 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20111122222154.GB96457@elstar.local> Message-ID: References: <201111171703.MAA00344@adminfs.snmp.com> <20111122222154.GB96457@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-14: unflatten scalars [open] 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, 22 Nov 2011 22:59:07 -0000 On Tue, 22 Nov 2011, Juergen Schoenwaelder wrote: > On Thu, Nov 17, 2011 at 12:03:06PM -0500, David Reid wrote: > > [...] > > I am having some hard time to follow the discussion. It seems we mix > up issues - the way we write down OIDs really has nothing to do with > the question how many containers we generate and how we name them. And > from previous discussions, we know that finding names is brittle since > legal SMIv2 updates can cause incompatible results. This is why we > dropped all the containers several months ago - for the sake of > robustness. > > To resolve ambiguities (if a parent of object foo has two > descriptors), I thought looking at the definition of foo might be a > good heuristic. But, it is still a heuristic. And it turns out > implementing it may not be that easy - I looked at the libsmi code and > it does not maintain knowledge how an OID was defined. So to implement > this solution, the frontend parser needs to be extended... This is not > impossible to do but raises the bar quite a bit. > > While it is true that OID value expressions for OBJECT-TYPES that are > not of the form { } are rare, other forms do for > sure exist for notifications I don't think this issue applies to notifications. We aren't trying to preserve logical collections of notifications by putting them inside a container. As I understood, the smi2yang process as it stands now would result in notifications all being at the top layer. The objects delivered by a notification would be contained by the notification. > and MODULE-IDENTITY OIDs, I'm not sure how this applies to smi2yang-14. It is possible that the immediate parent of some scalar objects could be the MODULE-IDENTITY, but, and you do have the name of the MODULE-IDENTITY which can be used as the name of the container for those scalars. I can't think of a case where the translator would need to know the name of the parent of a MODULE-IDENTITY. > even in IETF > modules. I guess I am not so much concerned about IETF modules but > more about the large number of enterprise modules - some of them I > know look really creative. > > So where are we with this discussion? Is this a fair summary? > > 1) The toplevel container is named after the module. I saw that discussed in the minutes, etc. If I had been there, I would have been in agreement. > 2) All tables are directly below the toplevel container. The last sample translation I saw put the list inside a container; e.g., container ifTable { list ifEntry { } } > 3) Augments must anyway be below the toplevel container, says YANG. Yes, and the name of the table and entry are only preserved through an alias statement; i.e., augment "path" { leaf ifName { } ... leaf Alias { } } alias ifXTable { ... } alias ifXEntry { ... } > 4) Scalars are moved into containers that are their parent. The name > of that parent is identified in the following way: > > a) If the parent in the OID tree of the object has only a single > descriptor, this name is used. Yes; e.g., container system { leaf sysDescr { } ... leaf sysServices { } } > b) Otherwise, if the OID of the object is defined in the form { > } or { () > }, then the parent is called . We assume > that people do not make random changes while revising MIB > modules - if they do we fail producing always the same YANG > translation. The minutes weren't very clear to me if this was discussed at the meeting. If you have .. and try to collapse this into container { leaf { } } then you may be losing some logical collections in translation if there is more than one . David Reid suggested container _ { leaf { } } but the danger there is different revisions of the document would likely have the leaf objects in different containers. IMHO, we should drop b) from consideration and go straigt from a) to c). > c) Otherwise, if the parent does not have a descriptor or there are > multiple descriptors left to choose from, the translation is > aborted with a suitable explanation. Yes. -dss > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From j.schoenwaelder@jacobs-university.de Tue Nov 22 15:18:21 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789C411E80DA for ; Tue, 22 Nov 2011 15:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 g8-5DrUuYX9K for ; Tue, 22 Nov 2011 15:18:20 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD5011E80D6 for ; Tue, 22 Nov 2011 15:18:20 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C51D20C93; Wed, 23 Nov 2011 00:18:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DI6kEFzfx6cl; Wed, 23 Nov 2011 00:18:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE0EE20CB9; Wed, 23 Nov 2011 00:18:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5A69A1BDA52C; Wed, 23 Nov 2011 00:17:59 +0100 (CET) Date: Wed, 23 Nov 2011 00:17:58 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20111122231756.GA96785@elstar.local> Mail-Followup-To: David Spakes , David Reid , netmod@ietf.org References: <201111171703.MAA00344@adminfs.snmp.com> <20111122222154.GB96457@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] smi2yang-14: unflatten scalars [open] 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, 22 Nov 2011 23:18:21 -0000 On Tue, Nov 22, 2011 at 05:59:02PM -0500, David Spakes wrote: > > So where are we with this discussion? Is this a fair summary? > > > > 1) The toplevel container is named after the module. > > I saw that discussed in the minutes, etc. If I had been there, I would > have been in agreement. Good. > > 2) All tables are directly below the toplevel container. > > The last sample translation I saw put the list inside a container; e.g., > > container ifTable { > list ifEntry { > } > } Thats correct - the container represents the table, the list represents the 'row'. You agree to keep it this way? > > 3) Augments must anyway be below the toplevel container, says YANG. > > Yes, and the name of the table and entry are only preserved through > an alias statement; i.e., > > augment "path" { > leaf ifName { > } > ... > leaf Alias { > } > } > alias ifXTable { ... } > alias ifXEntry { ... } Yes. > > 4) Scalars are moved into containers that are their parent. The name > > of that parent is identified in the following way: > > > > a) If the parent in the OID tree of the object has only a single > > descriptor, this name is used. > > Yes; e.g., > > container system { > leaf sysDescr { > } > ... > leaf sysServices { > } > } If system is the only name known for sysDescr etc. > > b) Otherwise, if the OID of the object is defined in the form { > > } or { () > > }, then the parent is called . We assume > > that people do not make random changes while revising MIB > > modules - if they do we fail producing always the same YANG > > translation. > > The minutes weren't very clear to me if this was discussed at the > meeting. > > If you have .. and try to collapse > this into > > container { > leaf { > } > } > > then you may be losing some logical collections in translation if > there is more than one . No, the situation here is you have a OBJECT IDENTIFIER ::= { somewhere 1 } b OBJECT IDENTIFIER ::= { somewhere 1 } foo OBJECT-TYPE --...-- ::= { a 1 } and you choose 'a' as the name of the parent. Similarily, if you have bar OBJECT-TYPE --...-- ::= { somewhere c(1) 2 } you put bar under 'c'. > David Reid suggested > > container _ { > leaf { > } > } > > but the danger there is different revisions of the document would likely > have the leaf objects in different containers. This would have been case c) in my description. > IMHO, we should drop b) from consideration and go straigt from a) to c). > > > > c) Otherwise, if the parent does not have a descriptor or there are > > multiple descriptors left to choose from, the translation is > > aborted with a suitable explanation. > > Yes. Anyway, if people arbitrarily rename OID descriptors, then we lost because we can't detect this. That is, if someone changes a OBJECT IDENTIFIER ::= { somewhere 1 } foo OBJECT-TYPE --...-- ::= { a 1 } to b OBJECT IDENTIFIER ::= { somewhere 1 } foo OBJECT-TYPE --...-- ::= { b 1 } then we will create different YANG modules. Such changes sometimes happen if company a buys company b and someone is tasked to apply the name change blindly. But then likely they also rename the module, in which case we are fine again - kind of. I guess we just document these limitations / assumptions we make. /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 Nov 23 00:29:25 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C8021F8B85 for ; Wed, 23 Nov 2011 00:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIoeGswwR9mD for ; Wed, 23 Nov 2011 00:29:24 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 980C221F8B2D for ; Wed, 23 Nov 2011 00:29:24 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E3ED11200D02; Wed, 23 Nov 2011 09:29:22 +0100 (CET) Date: Wed, 23 Nov 2011 09:29:22 +0100 (CET) Message-Id: <20111123.092922.1036425091247273894.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20111122231756.GA96785@elstar.local> References: <20111122222154.GB96457@elstar.local> <20111122231756.GA96785@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-14: unflatten scalars [open] 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, 23 Nov 2011 08:29:25 -0000 Juergen Schoenwaelder wrote: > Anyway, if people arbitrarily rename OID descriptors, then we lost > because we can't detect this. That is, if someone changes > > a OBJECT IDENTIFIER ::= { somewhere 1 } > foo OBJECT-TYPE --...-- ::= { a 1 } > > to > > b OBJECT IDENTIFIER ::= { somewhere 1 } > foo OBJECT-TYPE --...-- ::= { b 1 } But this is illegal in SMIv2: Note that changing the descriptor associated with an existing object is considered a semantic change, as these strings may be used in an IMPORTS statement. (this is also mentioned in 3.6 of 2578) and we don't have to cover illegal changes. [Didn't we discuss this before...? I forgot the outcome...] However, going from a OBJECT IDENTIFIER ::= { somewhere 1 } foo OBJECT-TYPE --...-- ::= { a 1 } to b OBJECT IDENTIFIER ::= { somewhere 1 } a OBJECT IDENTIFIER ::= { somewhere 1 } foo OBJECT-TYPE --...-- ::= { b 1 } is legal, and in this case the YANG will be different. But IMO, documenting this is good enough. /martin From j.schoenwaelder@jacobs-university.de Wed Nov 23 02:32:45 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2188C21F8C42 for ; Wed, 23 Nov 2011 02:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 NKEjgkFsirne for ; Wed, 23 Nov 2011 02:32:44 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5317E21F8C2F for ; Wed, 23 Nov 2011 02:32:44 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DAFE20CC6; Wed, 23 Nov 2011 11:32:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4b_2t7a14KBp; Wed, 23 Nov 2011 11:32:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF10820C97; Wed, 23 Nov 2011 11:32:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 587041BDB01E; Wed, 23 Nov 2011 11:32:23 +0100 (CET) Date: Wed, 23 Nov 2011 11:32:23 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111123103223.GC98032@elstar.local> Mail-Followup-To: Martin Bjorklund , spakes@snmp.com, netmod@ietf.org References: <20111122222154.GB96457@elstar.local> <20111122231756.GA96785@elstar.local> <20111123.092922.1036425091247273894.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111123.092922.1036425091247273894.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-14: unflatten scalars [open] 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, 23 Nov 2011 10:32:45 -0000 On Wed, Nov 23, 2011 at 09:29:22AM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > Anyway, if people arbitrarily rename OID descriptors, then we lost > > because we can't detect this. That is, if someone changes > > > > a OBJECT IDENTIFIER ::= { somewhere 1 } > > foo OBJECT-TYPE --...-- ::= { a 1 } > > > > to > > > > b OBJECT IDENTIFIER ::= { somewhere 1 } > > foo OBJECT-TYPE --...-- ::= { b 1 } > > But this is illegal in SMIv2: > > Note that changing the descriptor associated with an existing object > is considered a semantic change, as these strings may be used in an > IMPORTS statement. > > (this is also mentioned in 3.6 of 2578) > > and we don't have to cover illegal changes. > > [Didn't we discuss this before...? I forgot the outcome...] If RFC 2578 would have been that clear. The question is whether an ASN.1 value assignment is an "object". Unfortunately, RFC 2578 does not say "anything that might be used in an IMPORT must never change" even though that is technically what is needed. But yes, this is a corner case we can likely ignore. > However, going from > > a OBJECT IDENTIFIER ::= { somewhere 1 } > foo OBJECT-TYPE --...-- ::= { a 1 } > > to > > b OBJECT IDENTIFIER ::= { somewhere 1 } > a OBJECT IDENTIFIER ::= { somewhere 1 } > foo OBJECT-TYPE --...-- ::= { b 1 } > > is legal, and in this case the YANG will be different. > > But IMO, documenting this is good enough. OK /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 Nov 23 04:57:44 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2DF21F8C4F for ; Wed, 23 Nov 2011 04:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.193 X-Spam-Level: X-Spam-Status: No, score=-103.193 tagged_above=-999 required=5 tests=[AWL=0.056, 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 LocroXzZsqW5 for ; Wed, 23 Nov 2011 04:57:44 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C65B121F8C59 for ; Wed, 23 Nov 2011 04:57:43 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D902A20D0E for ; Wed, 23 Nov 2011 13:57:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TzacXZkQueGg; Wed, 23 Nov 2011 13:57:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B68B20D0D; Wed, 23 Nov 2011 13:57:39 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6CFA01BDB673; Wed, 23 Nov 2011 13:57:21 +0100 (CET) Date: Wed, 23 Nov 2011 13:57:21 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20111123125720.GC98340@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20111117065745.GD26328@elstar.local> <20111118030345.GC28368@elstar.local> <20111119120018.GA31698@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111119120018.GA31698@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] 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, 23 Nov 2011 12:57:44 -0000 We need to come to a resolution of this issue. Here is an attempt to formulate a way forward. a) The smiv2:oid statement contains a full OID in dotted number format and nothing else. Rationale: This is easiest to post process for example by xslt transforms processing YIN format since it is not required to move around in the tree to obtain a full OID. Extracting the last number, the subid, usually is simple. b) A translator always generates smiv2:oid statements. Rationale: This is simple and straight-forward to do and supports the rationale for a). c) We add an extension to the ietf-yang-smiv2.yang module defining a subid statement. There is not requirement for a translator to generate such statements; we merely provide this statement for convenience in situations where hand written annotations of YANG modules are created. In other words, we provide means for a different notation so that tools can be prepared to understand it but we do not mandate the use of this different notation _by_a_translator_. Does that 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 mbj@tail-f.com Wed Nov 23 05:19:41 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF4C21F8C8D for ; Wed, 23 Nov 2011 05:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdrHIYgBAzCq for ; Wed, 23 Nov 2011 05:19:41 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1462021F85AE for ; Wed, 23 Nov 2011 05:19:41 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 22DE31200D57; Wed, 23 Nov 2011 14:19:40 +0100 (CET) Date: Wed, 23 Nov 2011 14:19:38 +0100 (CET) Message-Id: <20111123.141938.1616654066669304559.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20111123125720.GC98340@elstar.local> References: <20111119120018.GA31698@elstar.local> <20111123125720.GC98340@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] 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, 23 Nov 2011 13:19:42 -0000 Juergen Schoenwaelder wrote: > We need to come to a resolution of this issue. Here is an attempt > to formulate a way forward. > > a) The smiv2:oid statement contains a full OID in dotted number format > and nothing else. Rationale: This is easiest to post process for > example by xslt transforms processing YIN format since it is not > required to move around in the tree to obtain a full OID. > Extracting the last number, the subid, usually is simple. > > b) A translator always generates smiv2:oid statements. Rationale: This > is simple and straight-forward to do and supports the rationale for > a). > > c) We add an extension to the ietf-yang-smiv2.yang module defining a > subid statement. There is not requirement for a translator to > generate such statements; we merely provide this statement for > convenience in situations where hand written annotations of YANG > modules are created. > > In other words, we provide means for a different notation so that > tools can be prepared to understand it but we do not mandate the use > of this different notation _by_a_translator_. > > Does that work? This works for me, although the logic is a bit weird - the rationale in (a) seems to indicate that subid should not exist at all. But remove the rationale in (a), and I'm happy ;) /martin From reid@snmp.com Wed Nov 23 06:12:52 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C28721F8541 for ; Wed, 23 Nov 2011 06:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 wcQMccGBQypw for ; Wed, 23 Nov 2011 06:12:51 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 47B7421F8C8E for ; Wed, 23 Nov 2011 06:12:50 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id JAA19012; Wed, 23 Nov 2011 09:12:35 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id JAA18150; Wed, 23 Nov 2011 09:12:30 -0500 (EST) Message-Id: <201111231412.JAA18150@adminfs.snmp.com> To: Martin Bjorklund From: David Reid In-reply-to: Your message of Wed, 23 Nov 2011 14:19:38 +0100. <20111123.141938.1616654066669304559.mbj@tail-f.com> Date: Wed, 23 Nov 2011 09:12:30 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 14:12:52 -0000 > Juergen Schoenwaelder wrote: > > We need to come to a resolution of this issue. Here is an attempt > > to formulate a way forward. > > > > a) The smiv2:oid statement contains a full OID in dotted number format > > and nothing else. Rationale: This is easiest to post process for > > example by xslt transforms processing YIN format since it is not > > required to move around in the tree to obtain a full OID. > > Extracting the last number, the subid, usually is simple. > > > > b) A translator always generates smiv2:oid statements. Rationale: This > > is simple and straight-forward to do and supports the rationale for > > a). > > > > c) We add an extension to the ietf-yang-smiv2.yang module defining a > > subid statement. There is not requirement for a translator to > > generate such statements; we merely provide this statement for > > convenience in situations where hand written annotations of YANG > > modules are created. > > > > In other words, we provide means for a different notation so that > > tools can be prepared to understand it but we do not mandate the use > > of this different notation _by_a_translator_. > > > > Does that work? > > This works for me, although the logic is a bit weird - the rationale > in (a) seems to indicate that subid should not exist at all. But > remove the rationale in (a), and I'm happy ;) I'm happy with this solution. -David Reid From spakes@snmp.com Wed Nov 23 12:42:04 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C1011E809F for ; Wed, 23 Nov 2011 12:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 YhEM9tSPzm1s for ; Wed, 23 Nov 2011 12:42:03 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8751F11E8094 for ; Wed, 23 Nov 2011 12:42:02 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA15432; Wed, 23 Nov 2011 15:41:49 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA02319; Wed, 23 Nov 2011 15:41:40 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 23 Nov 2011 15:41:40 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20111123125720.GC98340@elstar.local> Message-ID: References: <20111117065745.GD26328@elstar.local> <20111118030345.GC28368@elstar.local> <20111119120018.GA31698@elstar.local> <20111123125720.GC98340@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-16: smiv2:oid oid representations [open] 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, 23 Nov 2011 20:42:04 -0000 On Wed, 23 Nov 2011, Juergen Schoenwaelder wrote: > We need to come to a resolution of this issue. Here is an attempt > to formulate a way forward. > > a) The smiv2:oid statement contains a full OID in dotted number format > and nothing else. Rationale: This is easiest to post process for > example by xslt transforms processing YIN format since it is not > required to move around in the tree to obtain a full OID. > Extracting the last number, the subid, usually is simple. > > b) A translator always generates smiv2:oid statements. Rationale: This > is simple and straight-forward to do and supports the rationale for > a). > > c) We add an extension to the ietf-yang-smiv2.yang module defining a > subid statement. There is not requirement for a translator to > generate such statements; we merely provide this statement for > convenience in situations where hand written annotations of YANG > modules are created. > > In other words, we provide means for a different notation so that > tools can be prepared to understand it but we do not mandate the use > of this different notation _by_a_translator_. > > Does that work? > > /js Yes, that seems fine. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From spakes@snmp.com Wed Nov 23 12:42:29 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC8B11E8094 for ; Wed, 23 Nov 2011 12:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 TAbk7PVAwiSW for ; Wed, 23 Nov 2011 12:42:29 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0D61111E80A0 for ; Wed, 23 Nov 2011 12:42:28 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA15461; Wed, 23 Nov 2011 15:42:28 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA02352; Wed, 23 Nov 2011 15:42:27 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Wed, 23 Nov 2011 15:42:27 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20111122231756.GA96785@elstar.local> Message-ID: References: <201111171703.MAA00344@adminfs.snmp.com> <20111122222154.GB96457@elstar.local> <20111122231756.GA96785@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-14: unflatten scalars [open] 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, 23 Nov 2011 20:42:29 -0000 On Wed, 23 Nov 2011, Juergen Schoenwaelder wrote: > > container ifTable { > > list ifEntry { > > } > > } > > Thats correct - the container represents the table, the list > represents the 'row'. You agree to keep it this way? Yes, that seems fine. -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From internet-drafts@ietf.org Fri Nov 25 03:26:31 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794DB21F8BE5; Fri, 25 Nov 2011 03:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 70ZtRI34RkCw; Fri, 25 Nov 2011 03:26:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3F621F8B98; Fri, 25 Nov 2011 03:26:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111125112631.7778.52792.idtracker@ietfa.amsl.com> Date: Fri, 25 Nov 2011 03:26:31 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-smi-yang-02.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, 25 Nov 2011 11:26:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Workin= g Group of the IETF. Title : Translation of SMIv2 MIB Modules to YANG Modules Author(s) : Juergen Schoenwaelder Filename : draft-ietf-netmod-smi-yang-02.txt Pages : 41 Date : 2011-11-25 YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the SNMP protocol. This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only access to data objects defined in SMIv2 MIB modules via NETCONF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-smi-yang-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-netmod-smi-yang-02.txt From j.schoenwaelder@jacobs-university.de Fri Nov 25 03:30:55 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB5F21F8C07 for ; Fri, 25 Nov 2011 03:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=0.055, 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 1Rf-VZJP7md2 for ; Fri, 25 Nov 2011 03:30:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 11E2F21F8BD7 for ; Fri, 25 Nov 2011 03:30:54 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB13620CA1 for ; Fri, 25 Nov 2011 12:30:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OyYaEkLBiYqC; Fri, 25 Nov 2011 12:30:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9230720C9E; Fri, 25 Nov 2011 12:30:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8A6BD1BE3EFD; Fri, 25 Nov 2011 12:30:34 +0100 (CET) Date: Fri, 25 Nov 2011 12:30:33 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20111125113033.GA15207@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20111125112631.7778.52792.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111125112631.7778.52792.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] I-D Action: draft-ietf-netmod-smi-yang-02.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: Fri, 25 Nov 2011 11:30:55 -0000 On Fri, Nov 25, 2011 at 03:26:31AM -0800, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. > > Title : Translation of SMIv2 MIB Modules to YANG Modules > Author(s) : Juergen Schoenwaelder > Filename : draft-ietf-netmod-smi-yang-02.txt > Pages : 41 > Date : 2011-11-25 > Please review the changes and let me know in case I messed something up. This revision closes all open issues again and in case I did not mess things up badly, I hope we can continue with the process. /js PS: The SVN version of libsmi follows this revision except the import generation part - perhaps I can get that implemented in the coming days as well. -- 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 Nov 28 03:19:21 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7845821F8CBD for ; Mon, 28 Nov 2011 03:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 gZD9Q+VTptw6 for ; Mon, 28 Nov 2011 03:19:21 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A4B0C21F8C84 for ; Mon, 28 Nov 2011 03:19:20 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 156B81200045; Mon, 28 Nov 2011 12:19:19 +0100 (CET) Date: Mon, 28 Nov 2011 12:19:18 +0100 (CET) Message-Id: <20111128.121918.2024020526555917180.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20111125113033.GA15207@elstar.local> References: <20111125112631.7778.52792.idtracker@ietfa.amsl.com> <20111125113033.GA15207@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] I-D Action: draft-ietf-netmod-smi-yang-02.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, 28 Nov 2011 11:19:21 -0000 Hi, Juergen Schoenwaelder wrote: > Please review the changes o Since you added an example from RMON2-MIB, you may want to list it in the Introduction, where you list IF-MIB and DIFFSERVER-MIB. o Section 2 The mappings shown in Appendix A may impact the imports of the generated YANG module since some SMIv2 types and textual-conventions map to YANG types defined in the ietf-yang-types and ietf-inet-types YANG modules [RFC6021]. Add ietf-yang-smiv2 to this list (for the Opaque type). Ok, if extensions are generated it will be added anyway... o With the new mapping of well-known TCs, it is a bit confusing what happens when the SMIv2 MIB module with the TC is translated. For example, when a TruthValue is used, it is translated to a YANG boolean, but when SNMPv2-TC is translated, you will get a typedef: typedef TruthValue { type enumeration { enum "true" { value "1"; } enum "false" { value "2"; } } description "Represents a boolean value."; } There is no technical problem with this; it is just a bit confusing. An alternative could be to do the static mapping in the translation of the TC itself. So a TruthValue object would be translated to SNMPv2-TC:TruthValue, but the TC would be translated to: typedef TruthValue { type yang:boolean; description "Represents a boolean value."; } o Last bullet in section 3: o Generate an import statement for the yang module ietf-yang-smiv2 with the prefix smiv2 if extensions from ietf-yang-smiv2 will be used in the translated yang module. The "if" part should be removed, since the extensions are mandatory to generate. o Section 4.1 o The name of the SMIv2 module is used to generate a top-level container statement. This container MUST be config false. I suggest this container is not generated if there are no objects in the SMIv2 module. (For example, running smidump on SNMPv2-TC gives: container SNMPv2-TC { config false; } this looks odd, and is not needed) Also, the idea is that the container name is the same as the SMIv2 module name; this should be stated explicitly. o Section 7.1 Leaf statements for scalar objects are created in a container representing the scalar's parent node in the OID tree. This container is is named after the scalar's parent node in the OID tree and placed in the top-level container representing the SMIv2 module, see Section 4.1. s/is is/is/ In the rare case that the scalar's parent node has multiple names, the automatic translation MUST fail with an error and the name clash needs to be investigated and fixed manually. Are there any rules for how to fix this manually, or can it be "fixed" differently by different persons? The rules could be that if there exists a previous revision of the module, the same node as used in the previous revision must be used. Otherwise (no previous revision), the first name must be used. o Section 7.6 The YANG snippet has strings w/o the concatenation operator, and an erroneous double quote: path "/rmon2-mib:RMON2-MIB/" "rmon2-mib:protocolDirTable/" "rmon2-mib:"protocolDirEntryf/" "rmon2-mib:protocolDirLocalIndex"; } should be path "/rmon2-mib:RMON2-MIB/" + "rmon2-mib:protocolDirTable/" + "rmon2-mib:protocolDirEntryf/" + "rmon2-mib:protocolDirLocalIndex"; } o Appendix A s/Yang/YANG/g /martin From j.schoenwaelder@jacobs-university.de Mon Nov 28 05:58:23 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D351221F87FA for ; Mon, 28 Nov 2011 05:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.39 X-Spam-Level: X-Spam-Status: No, score=-101.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 H5Rsxs4jUD1i for ; Mon, 28 Nov 2011 05:58:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5A13621F8B14 for ; Mon, 28 Nov 2011 05:58:18 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5868920CA4; Mon, 28 Nov 2011 14:58:17 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id K9z8t9-eYW2K; Mon, 28 Nov 2011 14:58:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A42C620A1C; Mon, 28 Nov 2011 14:58:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6B6AA1BE6B0F; Mon, 28 Nov 2011 14:57:57 +0100 (CET) Date: Mon, 28 Nov 2011 14:57:56 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20111128135756.GA22835@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20111125112631.7778.52792.idtracker@ietfa.amsl.com> <20111125113033.GA15207@elstar.local> <20111128.121918.2024020526555917180.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111128.121918.2024020526555917180.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-smi-yang-02.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: Mon, 28 Nov 2011 13:58:23 -0000 On Mon, Nov 28, 2011 at 12:19:18PM +0100, Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: > > Please review the changes > > o Since you added an example from RMON2-MIB, you may want to list it > in the Introduction, where you list IF-MIB and DIFFSERVER-MIB. fixed > o Section 2 > > The mappings shown in Appendix A may impact the imports of the > generated YANG module since some SMIv2 types and > textual-conventions map to YANG types defined in the > ietf-yang-types and ietf-inet-types YANG modules [RFC6021]. > > Add ietf-yang-smiv2 to this list (for the Opaque type). Ok, if > extensions are generated it will be added anyway... fixed > o With the new mapping of well-known TCs, it is a bit confusing what > happens when the SMIv2 MIB module with the TC is translated. For > example, when a TruthValue is used, it is translated to a YANG > boolean, but when SNMPv2-TC is translated, you will get a typedef: > > typedef TruthValue { > type enumeration { > enum "true" { value "1"; } > enum "false" { value "2"; } > } > description > "Represents a boolean value."; > } > > There is no technical problem with this; it is just a bit > confusing. > > An alternative could be to do the static mapping in the translation > of the TC itself. So a TruthValue object would be translated to > SNMPv2-TC:TruthValue, but the TC would be translated to: > > typedef TruthValue { > type yang:boolean; > description > "Represents a boolean value."; > } Since there is no technical problem I prefer to leave this as it is. > o Last bullet in section 3: > > o Generate an import statement for the yang module ietf-yang-smiv2 > with the prefix smiv2 if extensions from ietf-yang-smiv2 will be > used in the translated yang module. > > The "if" part should be removed, since the extensions are > mandatory to generate. fixed > o Section 4.1 > > o The name of the SMIv2 module is used to generate a top-level > container statement. This container MUST be config false. > > I suggest this container is not generated if there are no objects > in the SMIv2 module. (For example, running smidump on SNMPv2-TC > gives: > > container SNMPv2-TC { > config false; > } > > this looks odd, and is not needed) > > Also, the idea is that the container name is the same as the SMIv2 > module name; this should be stated explicitly. While sometimes the generation of the container can be skipped, it is not wrong to generate one. If you want to prune the container, what about a module defining only and a table augmentation? You also would prune, right? I think we should make this a MAY. What about this text: - A top-level YANG container is generated. The container's name is the SMIv2 module name and the container MUST be config false. The generation of the top-level container MAY be skipped if the SMIv2 module does not define any objects that go into the top-level container (e.g., an SMIv2 module only defining textual conventions). > o Section 7.1 > > Leaf statements for scalar objects are created in a container > representing the scalar's parent node in the OID tree. This > container is is named after the scalar's parent node in the OID > tree and placed in the top-level container representing the SMIv2 > module, see Section 4.1. > > s/is is/is/ fixed > In the rare case that the scalar's parent node has multiple > names, the automatic translation MUST fail with an error and the > name clash needs to be investigated and fixed manually. > > Are there any rules for how to fix this manually, or can it be > "fixed" differently by different persons? The rules could be that > if there exists a previous revision of the module, the same node as > used in the previous revision must be used. Otherwise (no previous > revision), the first name must be used. well, hopefully the human is smart ;-) I added this: In case a previous revision of the SMIv2 module did not have an ambiguity, then the name used by the previous revision MUST be used. > o Section 7.6 > > The YANG snippet has strings w/o the concatenation operator, and > an erroneous double quote: > > path "/rmon2-mib:RMON2-MIB/" > "rmon2-mib:protocolDirTable/" > "rmon2-mib:"protocolDirEntryf/" > "rmon2-mib:protocolDirLocalIndex"; > } > > should be > > path "/rmon2-mib:RMON2-MIB/" > + "rmon2-mib:protocolDirTable/" > + "rmon2-mib:protocolDirEntryf/" > + "rmon2-mib:protocolDirLocalIndex"; > } fixed (I hope ;-) > o Appendix A > > s/Yang/YANG/g fixed /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From spakes@snmp.com Mon Nov 28 08:00:40 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AFC21F8CD4 for ; Mon, 28 Nov 2011 08:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C7n0s71GEIp for ; Mon, 28 Nov 2011 08:00:40 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0715221F8CBF for ; Mon, 28 Nov 2011 08:00:39 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA08684; Mon, 28 Nov 2011 11:00:38 -0500 (EST) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA10239; Mon, 28 Nov 2011 11:00:38 -0500 (EST) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 28 Nov 2011 11:00:38 -0500 (EST) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20111125113033.GA15207@elstar.local> Message-ID: References: <20111125112631.7778.52792.idtracker@ietfa.amsl.com> <20111125113033.GA15207@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-smi-yang-02.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, 28 Nov 2011 16:00:40 -0000 On Fri, 25 Nov 2011, Juergen Schoenwaelder wrote: > Please review the changes and let me know in case I messed something > up. This revision closes all open issues again and in case I did not > mess things up badly, I hope we can continue with the process. On page 23, the type of leaf ifName is snmpv2-tc:DisplayString, but that does not match Section 3.1. Prefix smiv2-tc seems to be left over from an earlier revision. s/smiv2-tc/snmpv2-tc/ -dss ------------------------------------------------------------- David Spakes email: spakes@snmp.com SNMP Research voice: +1 865 573 1434 3001 Kimberlin Heights Road fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com ------------------------------------------------------------- From j.schoenwaelder@jacobs-university.de Mon Nov 28 08:08:50 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880C221F8CE6 for ; Mon, 28 Nov 2011 08:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.765, 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 2oQhOcQ31Kso for ; Mon, 28 Nov 2011 08:08:50 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C2CDF21F8CB1 for ; Mon, 28 Nov 2011 08:08:49 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6AB620CCC; Mon, 28 Nov 2011 17:08:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ThMVtH_y-t7F; Mon, 28 Nov 2011 17:08:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A486320CC8; Mon, 28 Nov 2011 17:08:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7CF6E1BE72A4; Mon, 28 Nov 2011 17:08:31 +0100 (CET) Date: Mon, 28 Nov 2011 17:08:31 +0100 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20111128160831.GB26191@elstar.local> Mail-Followup-To: David Spakes , netmod@ietf.org References: <20111125112631.7778.52792.idtracker@ietfa.amsl.com> <20111125113033.GA15207@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-ietf-netmod-smi-yang-02.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: Mon, 28 Nov 2011 16:08:50 -0000 On Mon, Nov 28, 2011 at 11:00:38AM -0500, David Spakes wrote: > On Fri, 25 Nov 2011, Juergen Schoenwaelder wrote: > > > Please review the changes and let me know in case I messed something > > up. This revision closes all open issues again and in case I did not > > mess things up badly, I hope we can continue with the process. > > > On page 23, the type of leaf ifName is snmpv2-tc:DisplayString, but > that does not match Section 3.1. Prefix smiv2-tc seems to be left > over from an earlier revision. > > s/smiv2-tc/snmpv2-tc/ > Thanks, fixed. /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@cesnet.cz Tue Nov 29 05:27:44 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D66521F8511 for ; Tue, 29 Nov 2011 05:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBhulae40cfz for ; Tue, 29 Nov 2011 05:27:44 -0800 (PST) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by ietfa.amsl.com (Postfix) with ESMTP id 1303821F850E for ; Tue, 29 Nov 2011 05:27:44 -0800 (PST) Received: from localhost (jaromir.lhotkovi.cz [172.29.2.205]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id 21DE9DC005B; Tue, 29 Nov 2011 14:27:45 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , netmod@ietf.org In-Reply-To: <20111114.135017.268510208816363038.mbj@tail-f.com> References: <20111114.135017.268510208816363038.mbj@tail-f.com> User-Agent: Notmuch/0.9 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Mail-Followup-To: Martin Bjorklund , netmod@ietf.org Date: Tue, 29 Nov 2011 14:27:40 +0100 Message-ID: <87borvcb3n.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-01 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, 29 Nov 2011 13:27:44 -0000 Hi, On Mon, 14 Nov 2011 13:50:17 +0100 (CET), Martin Bjorklund wrote: > > o Why don't we have a ipv6-unicast module? > I'd like to write the "ietf-ipv6-unicast-routing" module but first we need to agree on the distribution of IPv6 parameters between this module and "ietf-ip". In the next revision of the "ietf-routing" module, I plan to add a list of interfaces under /rt:routing/rt:router with key being a leafref pointing to a configured logical interface. This is necessary in order to be able to specify the logical interfaces that belong to each logical router. As a side effect, interface parameters that are only relevant for routers, such as RA configuration, can be put here rather than under /if:interfaces. Any opinions or suggestions? Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From reid@snmp.com Tue Nov 29 14:10:42 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B40B21F8BBA for ; Tue, 29 Nov 2011 14:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 iyOqYOydV58h for ; Tue, 29 Nov 2011 14:10:42 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id C827521F8BB5 for ; Tue, 29 Nov 2011 14:10:41 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA27804; Tue, 29 Nov 2011 17:10:36 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA19587; Tue, 29 Nov 2011 17:10:27 -0500 (EST) Message-Id: <201111292210.RAA19587@adminfs.snmp.com> To: Juergen Schoenwaelder From: David Reid In-reply-to: Your message of Fri, 25 Nov 2011 12:30:33 +0100. <20111125113033.GA15207@elstar.local> Date: Tue, 29 Nov 2011 17:10:27 -0500 Sender: reid@snmp.com Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-smi-yang-02.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 22:10:42 -0000 > Please review the changes and let me know in case I messed something > up. This revision closes all open issues again and in case I did not > mess things up badly, I hope we can continue with the process. 4.1. MODULE-IDENTITY Translation Rules ... o The object identifier value of the invocation of the SMIv2 MODULE- IDENTITY is translated into an smiv2:oid statement contained in the container representing the MODULE-IDENTITY macro invocation. Refer to the YANG extension defined in Section 10. Since we are not translating the MODULE-IDENTITY to a container, should it be translated to an smiv2:alias statement with an embedded smiv2:oid statement? -David Reid From j.schoenwaelder@jacobs-university.de Tue Nov 29 23:37:46 2011 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DD321F84A2 for ; Tue, 29 Nov 2011 23:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.306, 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 LR7-xIsf4I67 for ; Tue, 29 Nov 2011 23:37:44 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E77FA21F84A0 for ; Tue, 29 Nov 2011 23:37:43 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFB7F20C85; Wed, 30 Nov 2011 08:37:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8GsjPxUPB18s; Wed, 30 Nov 2011 08:37:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8EB5D20C83; Wed, 30 Nov 2011 08:37:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 67B531BEAA9B; Wed, 30 Nov 2011 08:37:24 +0100 (CET) Date: Wed, 30 Nov 2011 08:37:24 +0100 From: Juergen Schoenwaelder To: David Reid Message-ID: <20111130073724.GA33585@elstar.local> Mail-Followup-To: David Reid , netmod@ietf.org References: <20111125113033.GA15207@elstar.local> <201111292210.RAA19587@adminfs.snmp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111292210.RAA19587@adminfs.snmp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-smi-yang-02.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: Wed, 30 Nov 2011 07:37:46 -0000 On Tue, Nov 29, 2011 at 05:10:27PM -0500, David Reid wrote: > > Please review the changes and let me know in case I messed something > > up. This revision closes all open issues again and in case I did not > > mess things up badly, I hope we can continue with the process. > > > 4.1. MODULE-IDENTITY Translation Rules > > ... > > o The object identifier value of the invocation of the SMIv2 MODULE- > IDENTITY is translated into an smiv2:oid statement contained in > the container representing the MODULE-IDENTITY macro invocation. > Refer to the YANG extension defined in Section 10. > > Since we are not translating the MODULE-IDENTITY to a container, should it > be translated to an smiv2:alias statement with an embedded smiv2:oid > statement? Yes. Changed this to: o The object identifier value of the invocation of the SMIv2 MODULE- IDENTITY is translated into an smiv2:oid statement contained in an smiv2:alias statement representing the MODULE-IDENTITY macro invocation. Refer to the YANG extension defined in Section 10. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103