From ietfc@btconnect.com Thu Jun 2 06:22: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 ACE6EE06F7 for ; Thu, 2 Jun 2011 06:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkpwzqAyGJDf for ; Thu, 2 Jun 2011 06:22:55 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr06.btconnect.com [213.123.26.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2E67FE06EC for ; Thu, 2 Jun 2011 06:22:54 -0700 (PDT) Received: from host217-43-155-221.range217-43.btcentralplus.com (HELO pc6) ([217.43.155.221]) by c2beaomr06.btconnect.com with SMTP id DGV40193; Thu, 02 Jun 2011 14:22:43 +0100 (BST) Message-ID: <003e01cc211f$834769e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Joel M. Halpern" References: <4DDBC170.6060309@joelhalpern.com><03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz> <4DDC503C.7020406@joelhalpern.com> <00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> <4DDEFC91.4060405@joelhalpern.com> Date: Thu, 2 Jun 2011 14:19:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4DE78EA3.0009, actions=TAG X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.2.123918:17:7.586, ip=217.43.155.221, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __FRAUD_REFNUM, __STOCK_PHRASE_24, __SUBJECT_ENDING_IN_LATIN_OR_NUMERALS, __STOCK_SYMBOL1, BODY_SIZE_10000_PLUS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, RDNS_SUSP_GENERIC, __STOCK_SYMBOL_X1, __OUTLOOK_MUA, RDNS_SUSP X-Junkmail-Status: score=10/50, host=c2beaomr06.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0202.4DE78EA6.00D8,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Cc: NETMOD Working Group Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 13:22:56 -0000 I said that I had a different terminology for routers (as well as a classification by size). I was reminded of a post to the IDR list which asked if there could be more than one BGP process in a router, to which the answer was that IDR was not a suitable forum for that discusion; but it did prompt me to investigate and I could not find a router that had this capability, whereas it is a commonplace for OSPF (I did not look at IGRP or EIGRP). So a router is an engine with multiple processes running routing protocols - BGP, OSPFs, EIRGP, RIP, ... - with, crucially, the ability to bring together information from different sources - routing protocols, configuration - to form a single, coherent table which is used for forwarding packets. For me, each routing protocol instance has a RIB, the form of which is routing protocol dependent, so that the RIP RIB and the OSPF RIB have nothing in common. The single table I call a FIB (whereas Joel seems to be using RIB2 for this). If the information cannot be brought together, then I call that multiple routers, perhaps virtual routers sharing the hardware platform. But as I said before, at the top end they become (MPLS) switches and stop being routers at all. I see a lot of activity in MPLS and CCAMP (GMPLS) on MIB modules, but not the same support for an updated BGP MIB module. Which is why I wonder if the most useful netmod router module would be targetted at Windows and CPE routers, ie entry level. I am also surprised that this I-D does not have RFC4292 as a normative reference; that for me would be a starting point. Tom Petch ----- Original Message ----- From: "Joel M. Halpern" To: "t.petch" Cc: "Ladislav Lhotka" ; "NETMOD Working Group" Sent: Friday, May 27, 2011 3:21 AM Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt > It would be hard for the discussion to be premature. Waiting until the > working group finished with the document, and then raising these issues, > when I noticed them early, would be rather rude of me. > As for whether it is the right list, this working group is working on > the document. Unless the chairs and ADs decide to move it, this is the > place to discuss it. (Yes, normally, MIB and other kinds of modeling is > done in the subject matter working group. The RTGWG does not have the > time to take this as its primary work item :-) > > As for the view of modeling, I can well believe that there is a better > model. Lada reasonably asked me to put a starting alternative on the > table. That seemed a fair request, and putting the alternative forward > might help folks understand my objection to the WG document. So I > sketched something. I tried to make it match the range of routers, > routing protocols, and protocol implementations I have worked with over > the years. A cleaner model than I suggested would be very helpful. > > Yours, > Joel > > On 5/26/2011 12:09 PM, t.petch wrote: > > Joel > > > > I think that this discussion is premature and on the wrong list:-( > > > > I would like to see a routing list, eg routing area WG, discuss > > what the model of a router should be, and then have this list turn that > > into Yang (or whatever). I think that the experience of people like > > Curtis is needed to come up with something that lasts. RFC1213 > > has not stood the test of time and I would not expect this to. > > > > In passing, I do not share your view of routers and routing terminology, and > > nor do I share Lada's, but do not know if any of us are right. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Joel M. Halpern" > > To: "Ladislav Lhotka" > > Cc: "NETMOD Working Group" > > Sent: Wednesday, May 25, 2011 2:41 AM > > Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt > > > > > >> Two comments, brought to the front for clarity. I have retained the > >> whole note for context, although we should probably trim it soon. > >> > >> 1) The difference between virtual router, virtual routing protocol, > >> routing process or routing protocol instance as you intended it is not a > >> big deal. However, you should understand that vendors have used those > >> terms in different ways to represent very different things. > >> > >> 1') More importantly, if you are talking about configuring a routing > >> protocol, you have to get teh granularity right. It is not possible, in > >> BGP, to have different hold times for different address families. The > >> different address families are all using the same TCP exchange over the > >> same ports, managed by the same protocol machinery. So when one tries > >> to configure a routing protocol, if you define that to be a single > >> address family, and to be separate for unicast and multicast, you make > >> it MORE complicated to represent the realities. > >> > >> With regard to the RIBs, what I would recommend is NOT to try to model > >> the per-protocol RIB. Rather, model > >> 1) The central, protocol independent, RIB, ala RIB2 > >> 2) The policies and priorities by which things get into the RIB, which > >> can be configured. > >> 3) The individual routing instances. This model should allow for > >> multiple instances of different protocols, but not require it > >> 3a) For each routing protocol instance, the policies by which it > >> extracts information from the common RIB, and the policies by which it > >> adds information to the common RIB > >> 3b) The routing data structure specific to the protocol. For most > >> protocols, these are NOT modifiable. Modification is generally done by > >> policies, not by manipulating the data. For IS-IS and OSPF, we would > >> want to model the link state database. For BGP, we would want to > >> advertise the RIB-IN, the BGP decision RIB, and the RIB out. The BGP > >> structure needs to include the BGP attributes, like the path, and has to > >> be organized in terms of the NLRI. It has to represent the fact that > >> several NLRI can share the same properties. (This may change in the > >> future, but is currently the case.) I would NOT recommend trying to > >> represent the IS-IS Link State Database using the same parent structure > >> as the BGP RIB. (It is probably not even worth trying to create a > >> common parent for the OSPF and IS-IS LSDB.) And I would not use the > >> same structure for the BGP RIB as for the central RIB. > >> > >> Yours, > >> Joel > >> > >> On 5/24/2011 12:27 PM, Ladislav Lhotka wrote: > >>> Joel, > >>> > >>> I have to apologize, you didn't miss anything. Your comments are quite > > far-reaching, so I had no quick answer and then had to work on other things. > >>> > >>> On May 24, 2011, at 4:32 PM, Joel M. Halpern wrote: > >>> > >>>> I sent a question about this several weeks ago. I apologize if there was a > > clear answer which I missed. > >>>> > >>>> The document seems to have a major problem of mixing the notions of RIB and > > routing process. The reality is quite different from the document in several > > regards. Conceptually, RIB and Routing Process are orthogonal concepts. A > > routing process may maintain several RIBs. it may manitain only one. It also > > may pull information from > >>> > >>> There may be a terminological confusion, as Phil already pointed out. A > > routing process is essentially a "virtual router", so, by definition, its > > routing information is not shared with other virtual routers. I think that what > > you call "routing process" is a "routing-protocol-instance" in my terminology. > >>> > >>> On the other hand, each routing-process (= virtual router) is limited to a > > single address family (AFI+SAFI), in order to make the data model extensible and > > manageable. From a practical point of view, is it a serious limitation? > >>> > >>>> RIBs beyond the one or ones it maintains. It may work with one address > > family, or several. It may handle only unicast, only multicast, or both. > >>>> And, conversely, some routing protocols do not operate in terms of > > maintaining a RIB (although they still have to interact with one or more RIBs at > > the edge. > >>>> > >>>> I get further confused by the placement of operations like one for deleting > > routes in the routing protocols. If a routing protocol learns a route, you > > generally MUST NOT delete it. Depending upon the routing protocol, you may or > > may not have knobs to > >>> > >>> I think this "MUST NOT" only applies to link-state protocols, otherwise > > routes learned by other routing protocols can be filtered before they are > > imported to a routing table. > >>> > >>> In any case, the "delete-route" operation can be removed and other > > operations/knobs added, this area is open to further discussion. I just wanted > > to include at least one rpc statement in the module to make people that are not > > very familiar with YANG aware of the possibility to define new operations. > >>> > >>>> control whether it is used. > >>>> (And there may be separate knobs affecting the way the system uses the RIB > > output from the routing protocol, but that is a different matter.) > >>>> > >>>> Normally, modeling has concentrated on the central RIB, with its policy and > > data. Routing protocol configuration has focussed on the individual knobs for > > the routing protocols. And instances are handled on a case by case basis. > >>>> Better commonality is good. > >>>> Mixing the concepts of RIB and Routing protocol instance is at best VERY > > confusing, and possibly worse. > >>> > >>> Could you sketch how the data model should be organized? I am not sure that > > the concept of a central RIB fits existing implementations with policy routing, > > where sets of routes can be filtered, manipulated and redistributed between > > routing protocols in many different ways. > >>> > >>> Thanks, Lada > >>> > >>>> > >>>> Yours, > >>>> Joel M. Halpern > >>>> _______________________________________________ > >>>> netmod mailing list > >>>> netmod@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >>> -- > >>> Ladislav Lhotka, CESNET > >>> PGP Key ID: E74E8C0C > > > > From lhotka@cesnet.cz Thu Jun 2 07:25: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 0A87DE0786 for ; Thu, 2 Jun 2011 07:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgQXy8hsVxPg for ; Thu, 2 Jun 2011 07:25:23 -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 9053EE07A1 for ; Thu, 2 Jun 2011 07:25:21 -0700 (PDT) Received: from stardust.lhotka.cesnet.cz (stardust.lhotka.cesnet.cz [IPv6:2001:718:1a02:7:c62c:3ff:fe09:d0bc]) by office2.cesnet.cz (Postfix) with ESMTPSA id EA8ED2CDE05E; Thu, 2 Jun 2011 16:25:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-9-152520700; protocol="application/pkcs7-signature"; micalg=sha1 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <003e01cc211f$834769e0$4001a8c0@gateway.2wire.net> Date: Thu, 2 Jun 2011 16:25:18 +0200 Message-Id: References: <4DDBC170.6060309@joelhalpern.com><03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz> <4DDC503C.7020406@joelhalpern.com> <00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> <4DDEFC91.4060405@joelhalpern.com> <003e01cc211f$834769e0$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1084) Cc: NETMOD Working Group Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 14:25:24 -0000 --Apple-Mail-9-152520700 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 2, 2011, at 2:19 PM, t.petch wrote: > I said that I had a different terminology for routers (as well as a > classification by size). I was reminded of a post to the IDR list = which asked > if there could be more than one BGP process in a router, to which the = answer was > that IDR was not a suitable forum for that discusion; but it did = prompt me to > investigate and I could not find a router that had this capability, = whereas it > is a commonplace for OSPF (I did not look at IGRP or EIGRP). In JUNOS documentation I found this: "You can create multiple instances of BGP, IS-IS, LDP, Multicast Source = Discovery Protocol (MSDP), OSPF version 2 (usually referred to simply as = OSPF) ..." >=20 > So a router is an engine with multiple processes running routing = protocols - > BGP, OSPFs, EIRGP, RIP, ... - with, crucially, the ability to bring = together > information from different sources - routing protocols, configuration = - to form > a single, coherent table which is used for forwarding packets. For = me, each Some implementations allow for creating additional routing tables, and = their connections to routing protocols, as well as the exchange of = information between routing tables, are configurable. This is what the = I-D tries to emulate. > routing protocol instance has a RIB, the form of which is routing = protocol > dependent, so that the RIP RIB and the OSPF RIB have nothing in = common. The > single table I call a FIB (whereas Joel seems to be using RIB2 for = this). If > the information cannot be brought together, then I call that multiple = routers, > perhaps virtual routers sharing the hardware platform. >=20 > But as I said before, at the top end they become (MPLS) switches and = stop being > routers at all. >=20 > I see a lot of activity in MPLS and CCAMP (GMPLS) on MIB modules, but = not the > same support for an updated BGP MIB module. Which is why I wonder if = the most > useful netmod router module would be targetted at Windows and CPE = routers, ie > entry level. >=20 > I am also surprised that this I-D does not have RFC4292 as a normative > reference; that for me would be a starting point. I think it's much more important that the YANG framework for routing be = an acceptable common ground, or lingua franca, for the existing popular = router configuration languages (CLIs). My preliminary research involved = three of them. Lada >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Joel M. Halpern" > To: "t.petch" > Cc: "Ladislav Lhotka" ; "NETMOD Working Group" > > Sent: Friday, May 27, 2011 3:21 AM > Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt >=20 >=20 >> It would be hard for the discussion to be premature. Waiting until = the >> working group finished with the document, and then raising these = issues, >> when I noticed them early, would be rather rude of me. >> As for whether it is the right list, this working group is working on >> the document. Unless the chairs and ADs decide to move it, this is = the >> place to discuss it. (Yes, normally, MIB and other kinds of modeling = is >> done in the subject matter working group. The RTGWG does not have = the >> time to take this as its primary work item :-) >>=20 >> As for the view of modeling, I can well believe that there is a = better >> model. Lada reasonably asked me to put a starting alternative on the >> table. That seemed a fair request, and putting the alternative = forward >> might help folks understand my objection to the WG document. So I >> sketched something. I tried to make it match the range of routers, >> routing protocols, and protocol implementations I have worked with = over >> the years. A cleaner model than I suggested would be very helpful. >>=20 >> Yours, >> Joel >>=20 >> On 5/26/2011 12:09 PM, t.petch wrote: >>> Joel >>>=20 >>> I think that this discussion is premature and on the wrong list:-( >>>=20 >>> I would like to see a routing list, eg routing area WG, discuss >>> what the model of a router should be, and then have this list turn = that >>> into Yang (or whatever). I think that the experience of people like >>> Curtis is needed to come up with something that lasts. RFC1213 >>> has not stood the test of time and I would not expect this to. >>>=20 >>> In passing, I do not share your view of routers and routing = terminology, and >>> nor do I share Lada's, but do not know if any of us are right. >>>=20 >>> Tom Petch >>>=20 >>> ----- Original Message ----- >>> From: "Joel M. Halpern" >>> To: "Ladislav Lhotka" >>> Cc: "NETMOD Working Group" >>> Sent: Wednesday, May 25, 2011 2:41 AM >>> Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt >>>=20 >>>=20 >>>> Two comments, brought to the front for clarity. I have retained = the >>>> whole note for context, although we should probably trim it soon. >>>>=20 >>>> 1) The difference between virtual router, virtual routing protocol, >>>> routing process or routing protocol instance as you intended it is = not a >>>> big deal. However, you should understand that vendors have used = those >>>> terms in different ways to represent very different things. >>>>=20 >>>> 1') More importantly, if you are talking about configuring a = routing >>>> protocol, you have to get teh granularity right. It is not = possible, in >>>> BGP, to have different hold times for different address families. = The >>>> different address families are all using the same TCP exchange over = the >>>> same ports, managed by the same protocol machinery. So when one = tries >>>> to configure a routing protocol, if you define that to be a single >>>> address family, and to be separate for unicast and multicast, you = make >>>> it MORE complicated to represent the realities. >>>>=20 >>>> With regard to the RIBs, what I would recommend is NOT to try to = model >>>> the per-protocol RIB. Rather, model >>>> 1) The central, protocol independent, RIB, ala RIB2 >>>> 2) The policies and priorities by which things get into the RIB, = which >>>> can be configured. >>>> 3) The individual routing instances. This model should allow for >>>> multiple instances of different protocols, but not require it >>>> 3a) For each routing protocol instance, the policies by which it >>>> extracts information from the common RIB, and the policies by which = it >>>> adds information to the common RIB >>>> 3b) The routing data structure specific to the protocol. For most >>>> protocols, these are NOT modifiable. Modification is generally = done by >>>> policies, not by manipulating the data. For IS-IS and OSPF, we = would >>>> want to model the link state database. For BGP, we would want to >>>> advertise the RIB-IN, the BGP decision RIB, and the RIB out. The = BGP >>>> structure needs to include the BGP attributes, like the path, and = has to >>>> be organized in terms of the NLRI. It has to represent the fact = that >>>> several NLRI can share the same properties. (This may change in = the >>>> future, but is currently the case.) I would NOT recommend trying = to >>>> represent the IS-IS Link State Database using the same parent = structure >>>> as the BGP RIB. (It is probably not even worth trying to create a >>>> common parent for the OSPF and IS-IS LSDB.) And I would not use = the >>>> same structure for the BGP RIB as for the central RIB. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 5/24/2011 12:27 PM, Ladislav Lhotka wrote: >>>>> Joel, >>>>>=20 >>>>> I have to apologize, you didn't miss anything. Your comments are = quite >>> far-reaching, so I had no quick answer and then had to work on other = things. >>>>>=20 >>>>> On May 24, 2011, at 4:32 PM, Joel M. Halpern wrote: >>>>>=20 >>>>>> I sent a question about this several weeks ago. I apologize if = there was > a >>> clear answer which I missed. >>>>>>=20 >>>>>> The document seems to have a major problem of mixing the notions = of RIB > and >>> routing process. The reality is quite different from the document = in > several >>> regards. Conceptually, RIB and Routing Process are orthogonal = concepts. A >>> routing process may maintain several RIBs. it may manitain only = one. It > also >>> may pull information from >>>>>=20 >>>>> There may be a terminological confusion, as Phil already pointed = out. A >>> routing process is essentially a "virtual router", so, by = definition, its >>> routing information is not shared with other virtual routers. I = think that > what >>> you call "routing process" is a "routing-protocol-instance" in my > terminology. >>>>>=20 >>>>> On the other hand, each routing-process (=3D virtual router) is = limited to a >>> single address family (AFI+SAFI), in order to make the data model = extensible > and >>> manageable. =46rom a practical point of view, is it a serious = limitation? >>>>>=20 >>>>>> RIBs beyond the one or ones it maintains. It may work with one = address >>> family, or several. It may handle only unicast, only multicast, or = both. >>>>>> And, conversely, some routing protocols do not operate in terms = of >>> maintaining a RIB (although they still have to interact with one or = more > RIBs at >>> the edge. >>>>>>=20 >>>>>> I get further confused by the placement of operations like one = for > deleting >>> routes in the routing protocols. If a routing protocol learns a = route, you >>> generally MUST NOT delete it. Depending upon the routing protocol, = you may > or >>> may not have knobs to >>>>>=20 >>>>> I think this "MUST NOT" only applies to link-state protocols, = otherwise >>> routes learned by other routing protocols can be filtered before = they are >>> imported to a routing table. >>>>>=20 >>>>> In any case, the "delete-route" operation can be removed and other >>> operations/knobs added, this area is open to further discussion. I = just > wanted >>> to include at least one rpc statement in the module to make people = that are > not >>> very familiar with YANG aware of the possibility to define new = operations. >>>>>=20 >>>>>> control whether it is used. >>>>>> (And there may be separate knobs affecting the way the system = uses the > RIB >>> output from the routing protocol, but that is a different matter.) >>>>>>=20 >>>>>> Normally, modeling has concentrated on the central RIB, with its = policy > and >>> data. Routing protocol configuration has focussed on the individual = knobs > for >>> the routing protocols. And instances are handled on a case by case = basis. >>>>>> Better commonality is good. >>>>>> Mixing the concepts of RIB and Routing protocol instance is at = best VERY >>> confusing, and possibly worse. >>>>>=20 >>>>> Could you sketch how the data model should be organized? I am not = sure > that >>> the concept of a central RIB fits existing implementations with = policy > routing, >>> where sets of routes can be filtered, manipulated and redistributed = between >>> routing protocols in many different ways. >>>>>=20 >>>>> Thanks, Lada >>>>>=20 >>>>>>=20 >>>>>> Yours, >>>>>> Joel M. Halpern >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>=20 >>>>> -- >>>>> Ladislav Lhotka, CESNET >>>>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >=20 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C --Apple-Mail-9-152520700 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 DxcNMTEwNjAyMTQyNTE5WjAjBgkqhkiG9w0BCQQxFgQUgbI8Y39TL1jgI8gsTN2froYltoswXgYJ KwYBBAGCNxAEMVEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJU RVJFTkEgUGVyc29uYWwgQ0ECEAZZ6ANhS/AmpnFJlCgvQ38wYAYLKoZIhvcNAQkQAgsxUaBPMDsx CzAJBgNVBAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBD QQIQBlnoA2FL8CamcUmUKC9DfzANBgkqhkiG9w0BAQEFAASCAQBcoxB6lytpcwDMUkJ9PSB+DFTV rn33HuGezVHIRZrdhnKCcfRbkBuy2O2uTehX8mfszefNHMJNZvpoDJjLSqDFEQK2/aSi6phVLsFW xen2AO/mer1SUcQTIn8ZqKSpveqymD/o6YlEKj0/Yxln0cA1ruWZkL+3PWzklKPsG448rxHHVQgS CoMZnHocJaiXevCrk2j7jxBhW/0X8Yc6/V/BJsOiN2Qy1qIEqipvknlL5HVNMyrHvTfxe/4IT1Kd jkh/C+hCWWT9ZmxPf24AMG+8Gz0/r3dXugoyzu08HiDNFv4tx3gQBePe/fEDLlagk+GKxQJuCD75 1n5/FCXobTg8AAAAAAAA --Apple-Mail-9-152520700-- From jmh@joelhalpern.com Thu Jun 2 08:40: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 607DAE07CA for ; Thu, 2 Jun 2011 08:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.916 X-Spam-Level: X-Spam-Status: No, score=-100.916 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUhwtLgztaxj for ; Thu, 2 Jun 2011 08:40:11 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 74081E06AF for ; Thu, 2 Jun 2011 08:40:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 37C894300F7; Thu, 2 Jun 2011 08:40:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.20.30.80] (static-98-141-237-178.dsl.cavtel.net [98.141.237.178]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 740FF4300EF; Thu, 2 Jun 2011 08:40:10 -0700 (PDT) Message-ID: <4DE7AED6.7030502@joelhalpern.com> Date: Thu, 02 Jun 2011 11:40:06 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "t.petch" References: <4DDBC170.6060309@joelhalpern.com><03718A69-D004-4322-B9C0-3F7120C564B0@cesnet.cz> <4DDC503C.7020406@joelhalpern.com> <00ed01cc1bbf$5631a7a0$4001a8c0@gateway.2wire.net> <4DDEFC91.4060405@joelhalpern.com> <003e01cc211f$834769e0$4001a8c0@gateway.2wire.net> In-Reply-To: <003e01cc211f$834769e0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: NETMOD Working Group Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 15:40:12 -0000 I think we mostly agree Tom. The reason I use RIB2 rather than FIB is that the structure that brings the information together is often organized so as to allow conflicts, which the central process resolves in building the actual FIBs which are sent to / used by the individual line/forwarding cards. (Trying to cover all the archtiectures in a single sentence produces awkwardness. Sorry.) Yours, Joel On 6/2/2011 8:19 AM, t.petch wrote: > I said that I had a different terminology for routers (as well as a > classification by size). I was reminded of a post to the IDR list which asked > if there could be more than one BGP process in a router, to which the answer was > that IDR was not a suitable forum for that discusion; but it did prompt me to > investigate and I could not find a router that had this capability, whereas it > is a commonplace for OSPF (I did not look at IGRP or EIGRP). > > So a router is an engine with multiple processes running routing protocols - > BGP, OSPFs, EIRGP, RIP, ... - with, crucially, the ability to bring together > information from different sources - routing protocols, configuration - to form > a single, coherent table which is used for forwarding packets. For me, each > routing protocol instance has a RIB, the form of which is routing protocol > dependent, so that the RIP RIB and the OSPF RIB have nothing in common. The > single table I call a FIB (whereas Joel seems to be using RIB2 for this). If > the information cannot be brought together, then I call that multiple routers, > perhaps virtual routers sharing the hardware platform. > > But as I said before, at the top end they become (MPLS) switches and stop being > routers at all. > > I see a lot of activity in MPLS and CCAMP (GMPLS) on MIB modules, but not the > same support for an updated BGP MIB module. Which is why I wonder if the most > useful netmod router module would be targetted at Windows and CPE routers, ie > entry level. > > I am also surprised that this I-D does not have RFC4292 as a normative > reference; that for me would be a starting point. > > Tom Petch > > ----- Original Message ----- > From: "Joel M. Halpern" > To: "t.petch" > Cc: "Ladislav Lhotka"; "NETMOD Working Group" > > Sent: Friday, May 27, 2011 3:21 AM > Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt > > >> It would be hard for the discussion to be premature. Waiting until the >> working group finished with the document, and then raising these issues, >> when I noticed them early, would be rather rude of me. >> As for whether it is the right list, this working group is working on >> the document. Unless the chairs and ADs decide to move it, this is the >> place to discuss it. (Yes, normally, MIB and other kinds of modeling is >> done in the subject matter working group. The RTGWG does not have the >> time to take this as its primary work item :-) >> >> As for the view of modeling, I can well believe that there is a better >> model. Lada reasonably asked me to put a starting alternative on the >> table. That seemed a fair request, and putting the alternative forward >> might help folks understand my objection to the WG document. So I >> sketched something. I tried to make it match the range of routers, >> routing protocols, and protocol implementations I have worked with over >> the years. A cleaner model than I suggested would be very helpful. >> >> Yours, >> Joel >> >> On 5/26/2011 12:09 PM, t.petch wrote: >>> Joel >>> >>> I think that this discussion is premature and on the wrong list:-( >>> >>> I would like to see a routing list, eg routing area WG, discuss >>> what the model of a router should be, and then have this list turn that >>> into Yang (or whatever). I think that the experience of people like >>> Curtis is needed to come up with something that lasts. RFC1213 >>> has not stood the test of time and I would not expect this to. >>> >>> In passing, I do not share your view of routers and routing terminology, and >>> nor do I share Lada's, but do not know if any of us are right. >>> >>> Tom Petch >>> >>> ----- Original Message ----- >>> From: "Joel M. Halpern" >>> To: "Ladislav Lhotka" >>> Cc: "NETMOD Working Group" >>> Sent: Wednesday, May 25, 2011 2:41 AM >>> Subject: Re: [netmod] Regarding draft-ietf-netmod-routing-cfg-00.txt >>> >>> >>>> Two comments, brought to the front for clarity. I have retained the >>>> whole note for context, although we should probably trim it soon. >>>> >>>> 1) The difference between virtual router, virtual routing protocol, >>>> routing process or routing protocol instance as you intended it is not a >>>> big deal. However, you should understand that vendors have used those >>>> terms in different ways to represent very different things. >>>> >>>> 1') More importantly, if you are talking about configuring a routing >>>> protocol, you have to get teh granularity right. It is not possible, in >>>> BGP, to have different hold times for different address families. The >>>> different address families are all using the same TCP exchange over the >>>> same ports, managed by the same protocol machinery. So when one tries >>>> to configure a routing protocol, if you define that to be a single >>>> address family, and to be separate for unicast and multicast, you make >>>> it MORE complicated to represent the realities. >>>> >>>> With regard to the RIBs, what I would recommend is NOT to try to model >>>> the per-protocol RIB. Rather, model >>>> 1) The central, protocol independent, RIB, ala RIB2 >>>> 2) The policies and priorities by which things get into the RIB, which >>>> can be configured. >>>> 3) The individual routing instances. This model should allow for >>>> multiple instances of different protocols, but not require it >>>> 3a) For each routing protocol instance, the policies by which it >>>> extracts information from the common RIB, and the policies by which it >>>> adds information to the common RIB >>>> 3b) The routing data structure specific to the protocol. For most >>>> protocols, these are NOT modifiable. Modification is generally done by >>>> policies, not by manipulating the data. For IS-IS and OSPF, we would >>>> want to model the link state database. For BGP, we would want to >>>> advertise the RIB-IN, the BGP decision RIB, and the RIB out. The BGP >>>> structure needs to include the BGP attributes, like the path, and has to >>>> be organized in terms of the NLRI. It has to represent the fact that >>>> several NLRI can share the same properties. (This may change in the >>>> future, but is currently the case.) I would NOT recommend trying to >>>> represent the IS-IS Link State Database using the same parent structure >>>> as the BGP RIB. (It is probably not even worth trying to create a >>>> common parent for the OSPF and IS-IS LSDB.) And I would not use the >>>> same structure for the BGP RIB as for the central RIB. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/24/2011 12:27 PM, Ladislav Lhotka wrote: >>>>> Joel, >>>>> >>>>> I have to apologize, you didn't miss anything. Your comments are quite >>> far-reaching, so I had no quick answer and then had to work on other things. >>>>> >>>>> On May 24, 2011, at 4:32 PM, Joel M. Halpern wrote: >>>>> >>>>>> I sent a question about this several weeks ago. I apologize if there was > a >>> clear answer which I missed. >>>>>> >>>>>> The document seems to have a major problem of mixing the notions of RIB > and >>> routing process. The reality is quite different from the document in > several >>> regards. Conceptually, RIB and Routing Process are orthogonal concepts. A >>> routing process may maintain several RIBs. it may manitain only one. It > also >>> may pull information from >>>>> >>>>> There may be a terminological confusion, as Phil already pointed out. A >>> routing process is essentially a "virtual router", so, by definition, its >>> routing information is not shared with other virtual routers. I think that > what >>> you call "routing process" is a "routing-protocol-instance" in my > terminology. >>>>> >>>>> On the other hand, each routing-process (= virtual router) is limited to a >>> single address family (AFI+SAFI), in order to make the data model extensible > and >>> manageable. From a practical point of view, is it a serious limitation? >>>>> >>>>>> RIBs beyond the one or ones it maintains. It may work with one address >>> family, or several. It may handle only unicast, only multicast, or both. >>>>>> And, conversely, some routing protocols do not operate in terms of >>> maintaining a RIB (although they still have to interact with one or more > RIBs at >>> the edge. >>>>>> >>>>>> I get further confused by the placement of operations like one for > deleting >>> routes in the routing protocols. If a routing protocol learns a route, you >>> generally MUST NOT delete it. Depending upon the routing protocol, you may > or >>> may not have knobs to >>>>> >>>>> I think this "MUST NOT" only applies to link-state protocols, otherwise >>> routes learned by other routing protocols can be filtered before they are >>> imported to a routing table. >>>>> >>>>> In any case, the "delete-route" operation can be removed and other >>> operations/knobs added, this area is open to further discussion. I just > wanted >>> to include at least one rpc statement in the module to make people that are > not >>> very familiar with YANG aware of the possibility to define new operations. >>>>> >>>>>> control whether it is used. >>>>>> (And there may be separate knobs affecting the way the system uses the > RIB >>> output from the routing protocol, but that is a different matter.) >>>>>> >>>>>> Normally, modeling has concentrated on the central RIB, with its policy > and >>> data. Routing protocol configuration has focussed on the individual knobs > for >>> the routing protocols. And instances are handled on a case by case basis. >>>>>> Better commonality is good. >>>>>> Mixing the concepts of RIB and Routing protocol instance is at best VERY >>> confusing, and possibly worse. >>>>> >>>>> Could you sketch how the data model should be organized? I am not sure > that >>> the concept of a central RIB fits existing implementations with policy > routing, >>> where sets of routes can be filtered, manipulated and redistributed between >>> routing protocols in many different ways. >>>>> >>>>> Thanks, Lada >>>>> >>>>>> >>>>>> Yours, >>>>>> Joel M. Halpern >>>>>> _______________________________________________ >>>>>> netmod mailing list >>>>>> netmod@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>>> -- >>>>> Ladislav Lhotka, CESNET >>>>> PGP Key ID: E74E8C0C >>> >>> > > From biermana@Brocade.com Thu Jun 2 15:43: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 27E4DE06BC for ; Thu, 2 Jun 2011 15:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJbZ9scC1LSR for ; Thu, 2 Jun 2011 15:43:46 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 8031EE0688 for ; Thu, 2 Jun 2011 15:43:46 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.4/8.14.4) with SMTP id p52MhOA5010729 for ; Thu, 2 Jun 2011 15:43:45 -0700 Received: from hq1-exedge.brocade.com (hq1-exedge.brocade.com [144.49.140.11]) by mx0b-000f0801.pphosted.com with ESMTP id wpek60612-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 02 Jun 2011 15:43:45 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXEDGE01.corp.brocade.com (144.49.140.11) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 2 Jun 2011 15:47:30 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Thu, 2 Jun 2011 15:43:43 -0700 From: Andy Bierman To: "netmod@ietf.org" Date: Thu, 2 Jun 2011 15:43:41 -0700 Thread-Topic: New Version Notification for draft-bierman-netmod-system-mgmt-00.txt Thread-Index: AcwhcWZig1n1FF+oSnGGBEctL/XmCAABHFGQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.148, 0.0.0000 definitions=2011-06-02_08:2011-06-02, 2011-06-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1106020167 Subject: [netmod] FW: New Version Notification for draft-bierman-netmod-system-mgmt-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 22:43:47 -0000 RllJLA0KDQpSZW1lbWJlciB3YXkgYmFjayB3aGVuLCB0aGUgTkVUQ09ORiBXRyBkZWNpZGVkIHRv IHNwbGl0IHRoZSBzeXN0ZW0gbW9kdWxlDQppbnRvIGJhc2Ugbm90aWZpY2F0aW9ucyBhbmQgc3lz dGVtIG9iamVjdHM/ICBUaGlzIGRyYWZ0IGF0dGVtcHRzIHRvDQpkZWZpbmUgYSBzdGFydGluZyBw b2ludCBmb3IgYSBZQU5HIHN5c3RlbSBtYW5hZ2VtZW50IG1vZHVsZS4NCg0KaHR0cDovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC1iaWVybWFuLW5ldG1vZC1zeXN0ZW0tbWdtdC0wMC50eHQNCg0KDQpB bmR5ICAoYW5kIE1hcnRpbikNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10g DQpTZW50OiBUaHVyc2RheSwgSnVuZSAwMiwgMjAxMSAzOjA3IFBNDQpUbzogQW5keSBCaWVybWFu DQpDYzogbWJqQHRhaWwtZi5jb207IEFuZHkgQmllcm1hbg0KU3ViamVjdDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvciBkcmFmdC1iaWVybWFuLW5ldG1vZC1zeXN0ZW0tbWdtdC0wMC50eHQN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJpZXJtYW4tbmV0bW9kLXN5c3RlbS1tZ210 LTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFuZHkgQmllcm1hbiBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtYmll cm1hbi1uZXRtb2Qtc3lzdGVtLW1nbXQNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIFlBTkcgRGF0 YSBNb2RlbCBmb3IgU3lzdGVtIE1hbmFnZW1lbnQNCkNyZWF0aW9uIGRhdGU6CSAyMDExLTA2LTAy DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMjMNCg0K QWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEgbW9kZWwgZm9y IHRoZSBjb25maWd1cmF0aW9uIGFuZA0KICAgaWRlbnRpZmljYXRpb24gb2YgdGhlIG1hbmFnZW1l bnQgc3lzdGVtIG9mIGEgZGV2aWNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From j.schoenwaelder@jacobs-university.de Sun Jun 5 05:42: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 83C0E21F8498 for ; Sun, 5 Jun 2011 05:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.649 X-Spam-Level: X-Spam-Status: No, score=-100.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0WtjdAztDhB for ; Sun, 5 Jun 2011 05:42:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8C71E21F8496 for ; Sun, 5 Jun 2011 05:42:35 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C17E20BF1 for ; Sun, 5 Jun 2011 14:42:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11GfrUw4rf3V; Sun, 5 Jun 2011 14:42:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92FCA20BEF; Sun, 5 Jun 2011 14:42:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 03DF218DE635; Sun, 5 Jun 2011 14:42:29 +0200 (CEST) Date: Sun, 5 Jun 2011 14:42:29 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110605124229.GA21916@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] smi2yang-04: string vs. binary [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: Sun, 05 Jun 2011 12:42:36 -0000 Hi, I like to close this open issue. Please comment on the options provided below. * 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. ** 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. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Jun 5 05:44: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 1A82B21F8497 for ; Sun, 5 Jun 2011 05:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJXVkwigwlwh for ; Sun, 5 Jun 2011 05:44:01 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 92BEC21F8496 for ; Sun, 5 Jun 2011 05:44:01 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE91420BF1 for ; Sun, 5 Jun 2011 14:44:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dKhASFYOoEcd; Sun, 5 Jun 2011 14:44:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C70820BEF; Sun, 5 Jun 2011 14:44:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8C49418DE670; Sun, 5 Jun 2011 14:43:56 +0200 (CEST) Date: Sun, 5 Jun 2011 14:43:56 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110605124356.GB21916@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] smi2yang-08: inline vs. outside smiv2:oid mapping [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: Sun, 05 Jun 2011 12:44:02 -0000 Hi, I like to close this open issue. Please comment on the options provided below. * smi2yang-08: inline vs. outside smiv2:oid mapping [open] 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. /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 Jun 6 07:40: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 5E41011E814D for ; Mon, 6 Jun 2011 07:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBP5hxE0rkYV for ; Mon, 6 Jun 2011 07:40:46 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB3B11E8145 for ; Mon, 6 Jun 2011 07:40:46 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA18252; Mon, 6 Jun 2011 10:40:38 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id KAA14329; Mon, 6 Jun 2011 10:40:37 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 6 Jun 2011 10:40:37 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20110605124229.GA21916@elstar.local> Message-ID: References: <20110605124229.GA21916@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-04: string vs. binary [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, 06 Jun 2011 14:40:47 -0000 Juergen, I think solution 04-04 is best, but in my opinion the cost would be less if every OCTET STRING object was treated the same way all the time. In other words, the choice should have a sysDescr-string leaf even if there is no DISPLAY-HINT. -dss On Sun, 5 Jun 2011, Juergen Schoenwaelder wrote: > ** 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 j.schoenwaelder@jacobs-university.de Mon Jun 6 07:58: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 AF37D11E8161 for ; Mon, 6 Jun 2011 07:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.816 X-Spam-Level: X-Spam-Status: No, score=-102.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuSznZs6k-YR for ; Mon, 6 Jun 2011 07:58:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 28EC911E8145 for ; Mon, 6 Jun 2011 07:58:36 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F3AD20BD5; Mon, 6 Jun 2011 16:58:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SYv4CWbqJNEW; Mon, 6 Jun 2011 16:58:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1AFF20A01; Mon, 6 Jun 2011 16:58:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7968318E06D2; Mon, 6 Jun 2011 16:58:31 +0200 (CEST) Date: Mon, 6 Jun 2011 16:58:31 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20110606145830.GA25828@elstar.local> Mail-Followup-To: David Spakes , netmod@ietf.org References: <20110605124229.GA21916@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-04: string vs. binary [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: Mon, 06 Jun 2011 14:58:36 -0000 On Mon, Jun 06, 2011 at 10:40:37AM -0400, David Spakes wrote: > Juergen, > > I think solution 04-04 is best, but in my opinion the cost would be > less if every OCTET STRING object was treated the same way all the > time. In other words, the choice should have a sysDescr-string leaf > even if there is no DISPLAY-HINT. I assume sysDescr is not a good example since it has a DISPLAY-HINT. If we take something that does not have a DISPLAY-HINT, then it is rather unclear to me what the string representation is unless we define one for strings that do not have a DISPLAY-HINT. But if we do that and later a MIB module gets revised and a DISPLAY-HINT is added, we are back to where we started since what is being added might conflict with what was used before. So I am not convinced having a -string version always is going to work well. There are costs associated with solution 04-04, not on the server side but on the client side. Perhaps some guidance should be given that servers really should generate the stringified format if there is one so as to encourage the usage of stringified representations. /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 Jun 6 08:09: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 1C3BE11E8169 for ; Mon, 6 Jun 2011 08:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwvJJXOLYfNn for ; Mon, 6 Jun 2011 08:09:24 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id E7BF911E80FE for ; Mon, 6 Jun 2011 08:09:23 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA20760; Mon, 6 Jun 2011 11:09:17 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA15032; Mon, 6 Jun 2011 11:09:17 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 6 Jun 2011 11:09:17 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20110605124356.GB21916@elstar.local> Message-ID: References: <20110605124356.GB21916@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping [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, 06 Jun 2011 15:09:25 -0000 Juergen, My opinion on this issue is that the OID mapping statement format in 08-01 should be adopted, but don't require that all mappings should appear at the end of the YANG module. Basically, allow them to be anywhere. For example, this should be allowed: leaf ifNumber { type int32; config false; description "The number of network interfaces (regardless of their current state) present on this system."; smiv2:oid 1.3.6.1.2.1.2.1 smiv2:alias "ifNumber"; } } The smiv2:alias substatement should be optional for the inline situation, in which case the alias name would be equal to the name of the parent. This following would be equivalent to the above (and I think it is very readable, not noisy): leaf ifNumber { type int32; config false; description "The number of network interfaces (regardless of their current state) present on this system."; smiv2:oid 1.3.6.1.2.1.2.1; } If smiv2:oid statements can appear anywhere in the document, then this would also be legal, although arguably more readable or less readable, depending on your biases: leaf ifNumber { type int32; config false; description "The number of network interfaces (regardless of their current state) present on this system."; smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias "interfaces"; } smiv2:oid 1.3.6.1.2.1.2.1; } Can we define in this document that smiv2:oid substatements (and other types of smiv2: substatements) can be added to a YANG document in a later revision, like new leaf nodes can be added within a choice? I think that would be greatly beneficial. -dss On Sun, 5 Jun 2011, Juergen Schoenwaelder wrote: > Hi, > > I like to close this open issue. Please comment on the options > provided below. > > * smi2yang-08: inline vs. outside smiv2:oid mapping [open] > > 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. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > ------------------------------------------------------------- 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 Jun 6 08:16: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 85D8611E8166 for ; Mon, 6 Jun 2011 08:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO52zPVHCJN5 for ; Mon, 6 Jun 2011 08:16:43 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id E193611E815C for ; Mon, 6 Jun 2011 08:16:42 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA21713; Mon, 6 Jun 2011 11:16:41 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id LAA15198; Mon, 6 Jun 2011 11:16:40 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 6 Jun 2011 11:16:40 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: Message-ID: References: <20110605124356.GB21916@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping [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, 06 Jun 2011 15:16:43 -0000 Oops. I forgot to type the open brace. -dss On Mon, 6 Jun 2011, David Spakes wrote: > example, this should be allowed: > > leaf ifNumber { > type int32; > config false; > description > "The number of network interfaces (regardless of their > current state) present on this system."; > smiv2:oid 1.3.6.1.2.1.2.1 { ..................................^ > smiv2:alias "ifNumber"; > } > } ------------------------------------------------------------- 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 ietf@andybierman.com Mon Jun 6 08:28: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 25D0F21F843E for ; Mon, 6 Jun 2011 08:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZnUQM9DXHZq for ; Mon, 6 Jun 2011 08:28:39 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 5962C21F843D for ; Mon, 6 Jun 2011 08:28:37 -0700 (PDT) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p56FSauH027911 for ; Mon, 6 Jun 2011 11:28:36 -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:38235] helo=[192.168.0.22]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E6/2E-02642-222FCED4; Mon, 06 Jun 2011 11:28:36 -0400 Message-ID: <4DECF238.3030703@andybierman.com> Date: Mon, 06 Jun 2011 08:28:56 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: David Spakes References: <20110605124356.GB21916@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping [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, 06 Jun 2011 15:28:40 -0000 On 06/06/2011 08:09 AM, David Spakes wrote: > Juergen, > > My opinion on this issue is that the OID mapping statement format in 08-01 > should be adopted, but don't require that all mappings should appear at > the end of the YANG module. Basically, allow them to be anywhere. For > example, this should be allowed: > > leaf ifNumber { > type int32; > config false; > description > "The number of network interfaces (regardless of their > current state) present on this system."; > smiv2:oid 1.3.6.1.2.1.2.1 > smiv2:alias "ifNumber"; > } > } > This would be simpler if smiv2:alias was not nested inside smiv2:oid. leaf ifNumber { type int32; config false; description "The number of network interfaces (regardless of their current state) present on this system."; smiv2:oid 1.3.6.1.2.1.2.1; smiv2:alias "ifNumber"; } The 'alias' statement seems redundant if the node name is the same value. Andy > The smiv2:alias substatement should be optional for the inline situation, > in which case the alias name would be equal to the name of the parent. > This following would be equivalent to the above (and I think it is very > readable, not noisy): > > leaf ifNumber { > type int32; > config false; > description > "The number of network interfaces (regardless of their > current state) present on this system."; > smiv2:oid 1.3.6.1.2.1.2.1; > } > > If smiv2:oid statements can appear anywhere in the document, then this > would also be legal, although arguably more readable or less readable, > depending on your biases: > > leaf ifNumber { > type int32; > config false; > description > "The number of network interfaces (regardless of their > current state) present on this system."; > smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias "interfaces"; } > smiv2:oid 1.3.6.1.2.1.2.1; > } > > Can we define in this document that smiv2:oid substatements (and other > types of smiv2: substatements) can be added to a YANG document in a later > revision, like new leaf nodes can be added within a choice? I think that > would be greatly beneficial. > > -dss > > > > On Sun, 5 Jun 2011, Juergen Schoenwaelder wrote: > >> Hi, >> >> I like to close this open issue. Please comment on the options >> provided below. >> >> * smi2yang-08: inline vs. outside smiv2:oid mapping [open] >> >> 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. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > ------------------------------------------------------------- > 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 > ------------------------------------------------------------- > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From j.schoenwaelder@jacobs-university.de Mon Jun 6 09:23: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 8BDC911E8195 for ; Mon, 6 Jun 2011 09:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKC+RevGHyjX for ; Mon, 6 Jun 2011 09:23:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C6AE611E8186 for ; Mon, 6 Jun 2011 09:23:51 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2AE3520A1C; Mon, 6 Jun 2011 18:23:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Bzn8f7Knl6Op; Mon, 6 Jun 2011 18:23:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C8FF20968; Mon, 6 Jun 2011 18:23:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8C9DA18E095D; Mon, 6 Jun 2011 18:23:47 +0200 (CEST) Date: Mon, 6 Jun 2011 18:23:47 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20110606162347.GB26074@elstar.local> Mail-Followup-To: David Spakes , netmod@ietf.org References: <20110605124356.GB21916@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-08: inline vs. outside smiv2:oid mapping [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: Mon, 06 Jun 2011 16:23:52 -0000 On Mon, Jun 06, 2011 at 11:09:17AM -0400, David Spakes wrote: > My opinion on this issue is that the OID mapping statement format in 08-01 > should be adopted, but don't require that all mappings should appear at > the end of the YANG module. Basically, allow them to be anywhere. For > example, this should be allowed: > > leaf ifNumber { > type int32; > config false; > description > "The number of network interfaces (regardless of their > current state) present on this system."; > smiv2:oid 1.3.6.1.2.1.2.1 > smiv2:alias "ifNumber"; > } > } > > The smiv2:alias substatement should be optional for the inline situation, > in which case the alias name would be equal to the name of the parent. > This following would be equivalent to the above (and I think it is very > readable, not noisy): > > leaf ifNumber { > type int32; > config false; > description > "The number of network interfaces (regardless of their > current state) present on this system."; > smiv2:oid 1.3.6.1.2.1.2.1; > } > > If smiv2:oid statements can appear anywhere in the document, then this > would also be legal, although arguably more readable or less readable, > depending on your biases: > > leaf ifNumber { > type int32; > config false; > description > "The number of network interfaces (regardless of their > current state) present on this system."; > smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias "interfaces"; } > smiv2:oid 1.3.6.1.2.1.2.1; > } So you are saying we leave it to implementations how they do this? Or can we find agreement on a common way of doing this? > Can we define in this document that smiv2:oid substatements (and other > types of smiv2: substatements) can be added to a YANG document in a later > revision, like new leaf nodes can be added within a choice? I think that > would be greatly beneficial. Not sure how to read this or how to do this. I mean, the translator is either generating those statements or it does not. There is no new revision of the YANG module being generated. I somehow prefer a solution where it is clear what can be expected to be generated from a translator. /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 Mon Jun 6 09:46: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 4F5FA11E8137 for ; Mon, 6 Jun 2011 09:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsPMC79m13-b for ; Mon, 6 Jun 2011 09:46:03 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 59DFE11E808E for ; Mon, 6 Jun 2011 09:46:01 -0700 (PDT) Received: from cm-omr5 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p56Gjwlf014997 for ; Mon, 6 Jun 2011 12:45:58 -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:60706] helo=[192.168.0.22]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 77/0E-32325-6440DED4; Mon, 06 Jun 2011 12:45:58 -0400 Message-ID: <4DED045C.2020701@andybierman.com> Date: Mon, 06 Jun 2011 09:46:20 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: David Spakes , netmod@ietf.org References: <20110605124356.GB21916@elstar.local> <20110606162347.GB26074@elstar.local> In-Reply-To: <20110606162347.GB26074@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping [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, 06 Jun 2011 16:46:04 -0000 On 06/06/2011 09:23 AM, Juergen Schoenwaelder wrote: > On Mon, Jun 06, 2011 at 11:09:17AM -0400, David Spakes wrote: > >> My opinion on this issue is that the OID mapping statement format in 08-01 >> should be adopted, but don't require that all mappings should appear at >> the end of the YANG module. Basically, allow them to be anywhere. For >> example, this should be allowed: >> >> leaf ifNumber { >> type int32; >> config false; >> description >> "The number of network interfaces (regardless of their >> current state) present on this system."; >> smiv2:oid 1.3.6.1.2.1.2.1 >> smiv2:alias "ifNumber"; >> } >> } >> >> The smiv2:alias substatement should be optional for the inline situation, >> in which case the alias name would be equal to the name of the parent. >> This following would be equivalent to the above (and I think it is very >> readable, not noisy): >> >> leaf ifNumber { >> type int32; >> config false; >> description >> "The number of network interfaces (regardless of their >> current state) present on this system."; >> smiv2:oid 1.3.6.1.2.1.2.1; >> } >> >> If smiv2:oid statements can appear anywhere in the document, then this >> would also be legal, although arguably more readable or less readable, >> depending on your biases: >> >> leaf ifNumber { >> type int32; >> config false; >> description >> "The number of network interfaces (regardless of their >> current state) present on this system."; >> smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias "interfaces"; } >> smiv2:oid 1.3.6.1.2.1.2.1; >> } > > So you are saying we leave it to implementations how they do this? Or > can we find agreement on a common way of doing this? No -- why can't the 2nd smiv2:oid be defined in the parent of 'ifNumber'? IMO the complexity is too high if arbitrary 'smiv2' extensions can appear in any node. I prefer that any extension only refer to the immediate containment node, in this case 'ifNumber'. Perhaps arbitrary statements can be contained within the module itself, but not within unrelated data nodes. > >> Can we define in this document that smiv2:oid substatements (and other >> types of smiv2: substatements) can be added to a YANG document in a later >> revision, like new leaf nodes can be added within a choice? I think that >> would be greatly beneficial. > > Not sure how to read this or how to do this. I mean, the translator is > either generating those statements or it does not. There is no new > revision of the YANG module being generated. I somehow prefer a > solution where it is clear what can be expected to be generated from a > translator. agreed. > > /js > Andy From j.schoenwaelder@jacobs-university.de Mon Jun 6 10:00:35 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 85FF611E81AD for ; Mon, 6 Jun 2011 10:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.989 X-Spam-Level: X-Spam-Status: No, score=-102.989 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONs99HCP8mcv for ; Mon, 6 Jun 2011 10:00:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AE9C011E81B7 for ; Mon, 6 Jun 2011 10:00:06 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D9C120BD5; Mon, 6 Jun 2011 19:00:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id asIY4HfmK-Fr; Mon, 6 Jun 2011 19:00:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1F2320A1C; Mon, 6 Jun 2011 19:00:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AB7E718E0A95; Mon, 6 Jun 2011 19:00:01 +0200 (CEST) Date: Mon, 6 Jun 2011 19:00:01 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20110606170001.GE26074@elstar.local> Mail-Followup-To: Andy Bierman , David Spakes , netmod@ietf.org References: <20110605124356.GB21916@elstar.local> <20110606162347.GB26074@elstar.local> <4DED045C.2020701@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DED045C.2020701@andybierman.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping [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: Mon, 06 Jun 2011 17:00:35 -0000 On Mon, Jun 06, 2011 at 09:46:20AM -0700, Andy Bierman wrote: > >>If smiv2:oid statements can appear anywhere in the document, then this > >>would also be legal, although arguably more readable or less readable, > >>depending on your biases: > >> > >> leaf ifNumber { > >> type int32; > >> config false; > >> description > >> "The number of network interfaces (regardless of their > >> current state) present on this system."; > >> smiv2:oid 1.3.6.1.2.1.2 { smiv2:alias "interfaces"; } > >> smiv2:oid 1.3.6.1.2.1.2.1; > >> } > > > >So you are saying we leave it to implementations how they do this? Or > >can we find agreement on a common way of doing this? > > No -- why can't the 2nd smiv2:oid be defined in the parent of > 'ifNumber'? IMO the complexity is too high if arbitrary 'smiv2' > extensions can appear in any node. I prefer that any extension only > refer to the immediate containment node, in this case 'ifNumber'. > Perhaps arbitrary statements can be contained within the module > itself, but not within unrelated data nodes. As settled before, in order to avoid ambiguities, not all SMIv2 "nodes" translate to YANG "nodes". Hence, if we want to capture all OIDs, some can't be inline and hence the proposal was made to make none of them inline. David seems to propose a new solution where those which can be inline are inline and the others are at "random" (means implementation specific) places. I will call this ** 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. /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 Jun 6 12:23: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 9929F1F0C46 for ; Mon, 6 Jun 2011 12:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew826LQQlrtx for ; Mon, 6 Jun 2011 12:23:44 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id ACBA31F0C3E for ; Mon, 6 Jun 2011 12:23:43 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA10945; Mon, 6 Jun 2011 15:23:37 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA21399; Mon, 6 Jun 2011 15:23:35 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 6 Jun 2011 15:23:35 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20110606170001.GE26074@elstar.local> Message-ID: References: <20110605124356.GB21916@elstar.local> <20110606162347.GB26074@elstar.local> <4DED045C.2020701@andybierman.com> <20110606170001.GE26074@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping [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, 06 Jun 2011 19:23:44 -0000 YANG compilers that don't know or don't care about the smiv2:oid extensions will simply ignore them. So, they could be thought of as structured comments. My thought is, What does it matter if they appear inline, appear at the bottom, are repeated, etc.? Since the MIB tree is no longer represented by the structure of containers, an application that does care about the OIDs is going to build a map regardless where the statements appear in the document. Allowing them to be inline verses clumped together at the bottom is simply a matter of readability, convenience, and user preference. I'm not even certain if or why it would be necessary to have a different revision of the YANG document if these extensions are present versus not present. Think: comments. -dss On Mon, 6 Jun 2011, Juergen Schoenwaelder wrote: > David seems to propose a new solution where those which can be inline > are inline and the others are at "random" (means implementation > specific) places. I will call this > > ** 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. > > /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 Mon Jun 6 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 2DC1A1F0C51 for ; Mon, 6 Jun 2011 12:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.032 X-Spam-Level: X-Spam-Status: No, score=-103.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F6sfb9DQHrA for ; Mon, 6 Jun 2011 12:45:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 342391F0C44 for ; Mon, 6 Jun 2011 12:45:11 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3460A20BFC; Mon, 6 Jun 2011 21:45:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2Thhu-B+5ICl; Mon, 6 Jun 2011 21:45:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E3B720BFB; Mon, 6 Jun 2011 21:45:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8A96E18E0FE0; Mon, 6 Jun 2011 21:45:06 +0200 (CEST) Date: Mon, 6 Jun 2011 21:45:06 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20110606194506.GC26728@elstar.local> Mail-Followup-To: David Spakes , Andy Bierman , netmod@ietf.org References: <20110605124356.GB21916@elstar.local> <20110606162347.GB26074@elstar.local> <4DED045C.2020701@andybierman.com> <20110606170001.GE26074@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-08: inline vs. outside smiv2:oid mapping [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: Mon, 06 Jun 2011 19:45:12 -0000 On Mon, Jun 06, 2011 at 03:23:35PM -0400, David Spakes wrote: > YANG compilers that don't know or don't care about the smiv2:oid > extensions will simply ignore them. Correct. > So, they could be thought of as structured comments. My thought is, > What does it matter if they appear inline, appear at the bottom, are > repeated, etc.? Since the MIB tree is no longer represented by the > structure of containers, an application that does care about the > OIDs is going to build a map regardless where the statements appear > in the document. Allowing them to be inline verses clumped together > at the bottom is simply a matter of readability, convenience, and > user preference. Since I am coding a translator, I need to decide where to generate the smiv2:oid statements. I can see the point of putting them inline for SMIv2 constructs that are translated into separate YANG constructs. However, having all smiv2:oid definitions in one place allows to more easily to see the structure of the OID tree. So here is a another proposal: ** 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). > I'm not even certain if or why it would be necessary to have a > different revision of the YANG document if these extensions are > present versus not present. Think: comments. Yes, we (you, Andy, me) seem to be in agreement here. I start to like #08-03. Comments? /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 Jun 6 13:27: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 C3D0B11E816A for ; Mon, 6 Jun 2011 13:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXtRI8OCQcf0 for ; Mon, 6 Jun 2011 13:27:05 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9178311E8071 for ; Mon, 6 Jun 2011 13:27:04 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA15189; Mon, 6 Jun 2011 16:26:51 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA23066; Mon, 6 Jun 2011 16:26:51 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 6 Jun 2011 16:26:51 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20110606194506.GC26728@elstar.local> Message-ID: References: <20110605124356.GB21916@elstar.local> <20110606162347.GB26074@elstar.local> <4DED045C.2020701@andybierman.com> <20110606170001.GE26074@elstar.local> <20110606194506.GC26728@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping [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, 06 Jun 2011 20:27:07 -0000 The statement "where it makes sense" needs to be clarified. Consider the following. 1. The translator should be able to use smiv2:alias if the inline invocation needs to supply an identifier that is different from the name of the parent node. choice sysDescr-leaf { config false; leaf sysDescr-string { type string; } leaf sysDescr-binary { type binary; } smiv2:oid 1.3.6.1.2.1.1.1 { smiv2:alias sysDescr; } description "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software."; } 2. In the above example, does the OID have multiple descriptors? One that is explicitly specified, "sysDescr", and another that is inherted from the parent, "sysDescr-leaf"? -dss On Fri, 6 May 2011, Juergen Schoenwaelder wrote: > You understand the collapsing correctly. The reason is that > descriptors can change and you have have multiple descriptors for the > same OID, hence it is ambiguous which one to choose. ... > Right now, the smiv2:oid statements are inline with the translated > SMIv2 macros. This means and this means not all OID descriptors are > captured. If the proposal is accepted to change the smiv2:oid > statement, I would prefer > > smiv2:oid 1.3.6.1.4.1.xxxxx.1.1.1 { > smiv2:alias "statsGroupA"; > smiv2:alias "oldStatsGroupA"; > } On Mon, 6 Jun 2011, Juergen Schoenwaelder wrote: > Since I am coding a translator, I need to decide where to generate the > smiv2:oid statements. I can see the point of putting them inline for > SMIv2 constructs that are translated into separate YANG constructs. > However, having all smiv2:oid definitions in one place allows to more > easily to see the structure of the OID tree. So here is a another > proposal: > > ** 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). > > > I'm not even certain if or why it would be necessary to have a > > different revision of the YANG document if these extensions are > > present versus not present. Think: comments. > > Yes, we (you, Andy, me) seem to be in agreement here. > > I start to like #08-03. Comments? > > /js On Sun, 5 Jun 2011, Juergen Schoenwaelder wrote: > ** 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 j.schoenwaelder@jacobs-university.de Mon Jun 6 13:43: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 DC8CB11E81A1 for ; Mon, 6 Jun 2011 13:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARGZauYWlgfi for ; Mon, 6 Jun 2011 13:43:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ADF5311E8191 for ; Mon, 6 Jun 2011 13:43:41 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E8EB20BFC; Mon, 6 Jun 2011 22:43:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UnYEC4tXlcAV; Mon, 6 Jun 2011 22:43:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BB442096B; Mon, 6 Jun 2011 22:43:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AAF6C18E10F5; Mon, 6 Jun 2011 22:43:37 +0200 (CEST) Date: Mon, 6 Jun 2011 22:43:37 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20110606204337.GA27208@elstar.local> Mail-Followup-To: David Spakes , Andy Bierman , netmod@ietf.org References: <20110605124356.GB21916@elstar.local> <20110606162347.GB26074@elstar.local> <4DED045C.2020701@andybierman.com> <20110606170001.GE26074@elstar.local> <20110606194506.GC26728@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-08: inline vs. outside smiv2:oid mapping [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: Mon, 06 Jun 2011 20:43:43 -0000 On Mon, Jun 06, 2011 at 04:26:51PM -0400, David Spakes wrote: > The statement "where it makes sense" needs to be clarified. Consider the > following. > > 1. The translator should be able to use smiv2:alias if the inline > invocation needs to supply an identifier that is different from the name > of the parent node. > > choice sysDescr-leaf { > config false; > leaf sysDescr-string { > type string; > } > leaf sysDescr-binary { > type binary; > } > smiv2:oid 1.3.6.1.2.1.1.1 { > smiv2:alias sysDescr; > } > description > "A textual description of the entity. This value should > include the full name and version identification of > the system's hardware type, software operating-system, > and networking software."; > } > > > 2. In the above example, does the OID have multiple descriptors? One > that is explicitly specified, "sysDescr", and another that is inherted > from the parent, "sysDescr-leaf"? Your question assumes we adopt Solution #04-04, not sure yet this is what we end up with (note that DISPLAY-HINTs only exist in TC definitions and so we would have to unroll them for the choice solution or we would have to try with groupings). Anyway, back to the topic at hand, 'sysDescr-leaf' does not exist in the SMIv2 namespace so claiming it does would be wrong. What about this: choice _sysDescr { config false; leaf sysDescr { type string; } leaf sysDescr-binary { type binary; } description "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software."; smiv2:max-access "read-only"; smiv2:oid "1.3.6.1.2.1.1.1"; } smiv2:oid 1.3.6.1.2.1.1.1 { smiv2:alias sysDescr; } In other words, the inline smiv2:oid value really just tags an OID to a YANG definition. You get the associated SMIv2 descriptors by looking for an smiv2:oid statement with smiv2:alias substatements. /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 Jun 6 13:56: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 C296111E819C for ; Mon, 6 Jun 2011 13:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZTdvDEA2sqx for ; Mon, 6 Jun 2011 13:56:57 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 323AB11E811A for ; Mon, 6 Jun 2011 13:56:57 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA17780; Mon, 6 Jun 2011 16:56:52 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id QAA23804; Mon, 6 Jun 2011 16:56:52 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Mon, 6 Jun 2011 16:56:51 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20110606204337.GA27208@elstar.local> Message-ID: References: <20110605124356.GB21916@elstar.local> <20110606162347.GB26074@elstar.local> <4DED045C.2020701@andybierman.com> <20110606170001.GE26074@elstar.local> <20110606194506.GC26728@elstar.local> <20110606204337.GA27208@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping [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, 06 Jun 2011 20:56:58 -0000 On Mon, 6 Jun 2011, Juergen Schoenwaelder wrote: > Anyway, back to the topic at hand, 'sysDescr-leaf' does not exist in > the SMIv2 namespace so claiming it does would be wrong Agreed. > What about this: ... > In other words, the inline smiv2:oid value really just tags an OID to > a YANG definition. You get the associated SMIv2 descriptors by looking > for an smiv2:oid statement with smiv2:alias substatements. I don't really like requiring that the numeric OID appear twice in the document. What about this: If an inline invocation does not have an smiv2:alias substatement, then the descriptor automatically becomes the name of the parent node. If an inline invocation does have an smiv2:alias, then the name of the parent node name is not used. An inline invocation may not specify more than one descriptor. Further, an inline invocation may not be changed by a subsequent revision of the document. choice _sysDescr { config false; leaf sysDescr { type string; } leaf sysDescr-binary { type binary; } description "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software."; smiv2:max-access "read-only"; smiv2:oid "1.3.6.1.2.1.1.1" { smiv2:alias sysDescr; } } An invocation that is not inline MUST have an smiv2:alias substatement since there is no parent node to contain it. Further, smiv2:oid statements may be added to the YANG document at the bottom without creating a new revision of the document (since these are essentially comments). smiv2:oid 1.3.6.1.2.1.1.1 { smiv2:alias sysDescr; } -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 Tue Jun 7 12:09: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 116C621F8517 for ; Tue, 7 Jun 2011 12:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.087 X-Spam-Level: X-Spam-Status: No, score=-103.087 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hx5S8FdqyJmZ for ; Tue, 7 Jun 2011 12:09:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7F021F84EF for ; Tue, 7 Jun 2011 12:09:46 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6022321549; Tue, 7 Jun 2011 21:09:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id aR3KiaBYyUVE; Tue, 7 Jun 2011 21:09:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 754E621542; Tue, 7 Jun 2011 21:09:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2594318E206F; Tue, 7 Jun 2011 21:09:39 +0200 (CEST) Date: Tue, 7 Jun 2011 21:09:39 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20110607190939.GA29248@elstar.local> Mail-Followup-To: David Spakes , Andy Bierman , netmod@ietf.org References: <20110605124356.GB21916@elstar.local> <20110606162347.GB26074@elstar.local> <4DED045C.2020701@andybierman.com> <20110606170001.GE26074@elstar.local> <20110606194506.GC26728@elstar.local> <20110606204337.GA27208@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-08: inline vs. outside smiv2:oid mapping [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, 07 Jun 2011 19:09:54 -0000 On Mon, Jun 06, 2011 at 04:56:51PM -0400, David Spakes wrote: > I don't really like requiring that the numeric OID appear twice in > the document. > > What about this: If an inline invocation does not have an smiv2:alias > substatement, then the descriptor automatically becomes the name of the > parent node. If an inline invocation does have an smiv2:alias, then the > name of the parent node name is not used. An inline invocation may not > specify more than one descriptor. Further, an inline invocation may not > be changed by a subsequent revision of the document. A translation is never a revision. I do not understand your revision concerns. And why is an inline invocation limited to exactly one descriptor? An arbitrary rule to complicate matters? > choice _sysDescr { > config false; > leaf sysDescr { > type string; > } > leaf sysDescr-binary { > type binary; > } > description > "A textual description of the entity. This value should > include the full name and version identification of > the system's hardware type, software operating-system, > and networking software."; > smiv2:max-access "read-only"; > smiv2:oid "1.3.6.1.2.1.1.1" { > smiv2:alias sysDescr; > } > } > > An invocation that is not inline MUST have an smiv2:alias substatement > since there is no parent node to contain it. > > Further, smiv2:oid statements may be added to the YANG document at the > bottom without creating a new revision of the document (since these are > essentially comments). > > smiv2:oid 1.3.6.1.2.1.1.1 { smiv2:alias sysDescr; } I still like the readability of having all OIDs listed together instead of just a subset. As long as it is not made illegal to do this, I am fine. (Redundancy is not really an issue since all this is machine generated and unless the translator is buggy, things will be consistent.) And as noted before, a translation never generates a new revision. /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 Jun 7 12: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 246C211E81C5 for ; Tue, 7 Jun 2011 12:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es8zc3euUa30 for ; Tue, 7 Jun 2011 12:25:53 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 80A1511E810C for ; Tue, 7 Jun 2011 12:25:53 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA00849; Tue, 7 Jun 2011 15:25:51 -0400 (EDT) Received: from localhost (spakes@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA03162; Tue, 7 Jun 2011 15:25:51 -0400 (EDT) X-Authentication-Warning: adminfs.snmp.com: spakes owned process doing -bs Date: Tue, 7 Jun 2011 15:25:51 -0400 (EDT) From: David Spakes X-X-Sender: spakes@adminfs To: Juergen Schoenwaelder In-Reply-To: <20110607190939.GA29248@elstar.local> Message-ID: References: <20110605124356.GB21916@elstar.local> <20110606162347.GB26074@elstar.local> <4DED045C.2020701@andybierman.com> <20110606170001.GE26074@elstar.local> <20110606194506.GC26728@elstar.local> <20110606204337.GA27208@elstar.local> <20110607190939.GA29248@elstar.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping [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, 07 Jun 2011 19:25:55 -0000 On Tue, 7 Jun 2011, Juergen Schoenwaelder wrote: > And why is an inline invocation limited to exactly one > descriptor? An arbitrary rule to complicate matters? If this implies a mapping of 1.3.6.1.2.1.2.1 to ifNumber, leaf ifNumber { //.. smiv2:oid "1.3.6.1.2.1.2.1"; } and if this means "map 1.3.6.1.2.1.2.1 to the supplied descriptor, foo, not the parent, ifNumber" (as in would need to in the case of choice _sysDescr), leaf ifNumber { //.. smiv2:oid "1.3.6.1.2.1.2.1" { smiv2:alias foo; } } then if your translator produces this, leaf ifNumber { //.. smiv2:oid "1.3.6.1.2.1.2.1"; } what happens if somebody makes another module that does this? import IF-MIB { prefix "if"; } augment "/if:ifNumber" { smiv2:oid "1.3.6.1.2.1.2.1" { smiv2:alias foo; } } -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 Tue Jun 7 13:48: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 CD5AB11E8233 for ; Tue, 7 Jun 2011 13:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.105 X-Spam-Level: X-Spam-Status: No, score=-103.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJI+IWqMLwPn for ; Tue, 7 Jun 2011 13:48:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CF15911E8238 for ; Tue, 7 Jun 2011 13:48:40 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2EAF421D22; Tue, 7 Jun 2011 22:48:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9ar4tDOp6Hqi; Tue, 7 Jun 2011 22:48:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11E0221D1B; Tue, 7 Jun 2011 22:48:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C020B18E243B; Tue, 7 Jun 2011 22:48:34 +0200 (CEST) Date: Tue, 7 Jun 2011 22:48:34 +0200 From: Juergen Schoenwaelder To: David Spakes Message-ID: <20110607204832.GC29359@elstar.local> Mail-Followup-To: David Spakes , Andy Bierman , netmod@ietf.org References: <20110606162347.GB26074@elstar.local> <4DED045C.2020701@andybierman.com> <20110606170001.GE26074@elstar.local> <20110606194506.GC26728@elstar.local> <20110606204337.GA27208@elstar.local> <20110607190939.GA29248@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-08: inline vs. outside smiv2:oid mapping [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, 07 Jun 2011 20:48:41 -0000 On Tue, Jun 07, 2011 at 03:25:51PM -0400, David Spakes wrote: > On Tue, 7 Jun 2011, Juergen Schoenwaelder wrote: > > > And why is an inline invocation limited to exactly one > > descriptor? An arbitrary rule to complicate matters? > > If this implies a mapping of 1.3.6.1.2.1.2.1 to ifNumber, > > leaf ifNumber { > //.. > smiv2:oid "1.3.6.1.2.1.2.1"; > } > > and if this means "map 1.3.6.1.2.1.2.1 to the supplied descriptor, > foo, not the parent, ifNumber" (as in would need to in the case of > choice _sysDescr), > > leaf ifNumber { > //.. > smiv2:oid "1.3.6.1.2.1.2.1" { > smiv2:alias foo; > } > } > > then if your translator produces this, > > leaf ifNumber { > //.. > smiv2:oid "1.3.6.1.2.1.2.1"; > } > > what happens if somebody makes another module that does this? > > import IF-MIB { > prefix "if"; > } > augment "/if:ifNumber" { > smiv2:oid "1.3.6.1.2.1.2.1" { > smiv2:alias foo; > } > } I guess I do not understand where the catch is. You seem to assume that humans write manually smiv2:oid statements while I assume that they are generated by an automated translator. Or are you trying to make an argument why allowing smiv2:alias statements in inlined smiv2:oid statements is a bad idea? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Jun 8 03:31: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 F3A4321F8498 for ; Wed, 8 Jun 2011 03:31:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdLD16qq5zKi for ; Wed, 8 Jun 2011 03:31:26 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id BEE8421F8454 for ; Wed, 8 Jun 2011 03:31:25 -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 12B8276C4E6 for ; Wed, 8 Jun 2011 12:31:24 +0200 (CEST) Date: Wed, 08 Jun 2011 12:31:22 +0200 (CEST) Message-Id: <20110608.123122.2004591181866101810.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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 Subject: [netmod] notification mapping in draft-ietf-netmod-smi-yang-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 10:31:27 -0000 Hi, The mapping algorithm for notification objects describe how each object is mapped to a container with N+1 leafs, where N is the number of indexes: If the current object belongs to a conceptual table, then a sequence of leaf statements is generated for each INDEX object of the conceptual table. These leafs are named after the INDEX objects and of type leafref. Finally, a leaf statement is generated named after the current object. If the current object has a MAX-ACCESS of "read-only", "read-write" or ""read-create", then the generated leaf is of type leafref. And an example: container object-2 { leaf ifIndex { type leafref { path "/if-mib:ifTable/if-mib:ifEntry/if-mib:ifIndex"; } description "[Automatically generated leaf for a notification object index.]"; } leaf ifAdminStatus { type leafref { path "/if-mib:ifTable/if-mib:ifEntry/if-mib:ifAdminStatus"; } description "[Automatically generated leaf for a notification object.]"; } } But this mapping fails to connect the leafrefs in the container with each other. The idea is that the value of ifIndex in the example above is the value for the corresponding ifAdminStatus. I think it should be: leaf ifAdminStatus { type leafref { path "/if-mib:ifTable/if-mib:ifEntry" + "[if-mib:ifIndex = current()/../ifIndex]" + "/if-mib:ifAdminStatus"; } /martin From j.schoenwaelder@jacobs-university.de Thu Jun 9 07:22: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 D0C7411E80B7 for ; Thu, 9 Jun 2011 07:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.119 X-Spam-Level: X-Spam-Status: No, score=-103.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5juX1REEQIZ4 for ; Thu, 9 Jun 2011 07:22:37 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2108411E808B for ; Thu, 9 Jun 2011 07:22:37 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4340D20C5B; Thu, 9 Jun 2011 16:22:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id R87pePLPzH2b; Thu, 9 Jun 2011 16:22:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B20020C67; Thu, 9 Jun 2011 16:22:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7781C18EADCB; Thu, 9 Jun 2011 16:22:34 +0200 (CEST) Date: Thu, 9 Jun 2011 16:22:33 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110609142233.GA1063@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20110608.123122.2004591181866101810.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110608.123122.2004591181866101810.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] notification mapping in draft-ietf-netmod-smi-yang-00 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, 09 Jun 2011 14:22:39 -0000 On Wed, Jun 08, 2011 at 12:31:22PM +0200, Martin Bjorklund wrote: [...] > But this mapping fails to connect the leafrefs in the container with > each other. The idea is that the value of ifIndex in the example > above is the value for the corresponding ifAdminStatus. > > I think it should be: > > leaf ifAdminStatus { > type leafref { > path "/if-mib:ifTable/if-mib:ifEntry" > + "[if-mib:ifIndex = current()/../ifIndex]" > + "/if-mib:ifAdminStatus"; > } While I see what you want to achieve, I am not sure YANG really allows to do this or it may not be very clear from my reading of RFC 6020. The issue is that ifAdminStatus is part of the notification definition while section 9.9.2 says: See also the definition of context node in 9.9.2: o The context node is the node in the data tree for which the "path" statement is defined. Here is the definition of data tree: data tree: The instantiated tree of configuration and state data on a device. Furthermore, section 9.9.2 says: The predicates are only used when more than one key reference is needed to uniquely identify a leaf instance. This occurs if a list has multiple keys, or a reference to a leaf other than the key in a list is needed. In these cases, multiple leafrefs are typically specified, and predicates are used to tie them together. In your example, the list has only a single key... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Jun 9 07:30: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 5356011E80DB for ; Thu, 9 Jun 2011 07:30:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASqj0JCbeowg for ; Thu, 9 Jun 2011 07:30:58 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id C404A11E808B for ; Thu, 9 Jun 2011 07:30:52 -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 ED42B616002; Thu, 9 Jun 2011 16:30:50 +0200 (CEST) Date: Thu, 09 Jun 2011 16:30:49 +0200 (CEST) Message-Id: <20110609.163049.606529029089230976.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110609142233.GA1063@elstar.local> References: <20110608.123122.2004591181866101810.mbj@tail-f.com> <20110609142233.GA1063@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] notification mapping in draft-ietf-netmod-smi-yang-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:30:59 -0000 Juergen Schoenwaelder wrote: > On Wed, Jun 08, 2011 at 12:31:22PM +0200, Martin Bjorklund wrote: > > [...] > > > But this mapping fails to connect the leafrefs in the container with > > each other. The idea is that the value of ifIndex in the example > > above is the value for the corresponding ifAdminStatus. > > > > I think it should be: > > > > leaf ifAdminStatus { > > type leafref { > > path "/if-mib:ifTable/if-mib:ifEntry" > > + "[if-mib:ifIndex = current()/../ifIndex]" > > + "/if-mib:ifAdminStatus"; > > } > > While I see what you want to achieve, I am not sure YANG really allows > to do this or it may not be very clear from my reading of RFC > 6020. Are you saying that you think YANG, in notifications, allows leafrefs w/o predicates but not w/ predicates? Or that leafrefs cannot be used in notifications at all? Or something else? > The issue is that ifAdminStatus is part of the notification > definition while section 9.9.2 says: > > See also the definition of context node in 9.9.2: > > o The context node is the node in the data tree for which the "path" > statement is defined. > > Here is the definition of data tree: > > data tree: The instantiated tree of configuration and state data > on a device. > > Furthermore, section 9.9.2 says: > > The predicates are only used when more than one key reference is > needed to uniquely identify a leaf instance. This occurs if a list > has multiple keys, or a reference to a leaf other than the key in a > list is needed. In these cases, multiple leafrefs are typically > specified, and predicates are used to tie them together. > > In your example, the list has only a single key... With multiple keys, you get multiple predicates. /martin From mbj@tail-f.com Thu Jun 9 07:40: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 082FC21F8478 for ; Thu, 9 Jun 2011 07:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtNq+q2o6uwS for ; Thu, 9 Jun 2011 07:40:55 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id 9213E21F8477 for ; Thu, 9 Jun 2011 07:40:55 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id C5B3F616002; Thu, 9 Jun 2011 16:40:54 +0200 (CEST) Date: Thu, 09 Jun 2011 16:40:53 +0200 (CEST) Message-Id: <20110609.164053.2177450875233704976.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110609.163049.606529029089230976.mbj@tail-f.com> References: <20110608.123122.2004591181866101810.mbj@tail-f.com> <20110609142233.GA1063@elstar.local> <20110609.163049.606529029089230976.mbj@tail-f.com> X-Mailer: Mew version 6.3.50 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] notification mapping in draft-ietf-netmod-smi-yang-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:40:57 -0000 Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Jun 08, 2011 at 12:31:22PM +0200, Martin Bjorklund wrote: > > > > [...] > > > > > But this mapping fails to connect the leafrefs in the container with > > > each other. The idea is that the value of ifIndex in the example > > > above is the value for the corresponding ifAdminStatus. > > > > > > I think it should be: > > > > > > leaf ifAdminStatus { > > > type leafref { > > > path "/if-mib:ifTable/if-mib:ifEntry" > > > + "[if-mib:ifIndex = current()/../ifIndex]" > > > + "/if-mib:ifAdminStatus"; > > > } > > > > While I see what you want to achieve, I am not sure YANG really allows > > to do this or it may not be very clear from my reading of RFC > > 6020. > > Are you saying that you think YANG, in notifications, allows leafrefs > w/o predicates but not w/ predicates? Or that leafrefs cannot be used > in notifications at all? Or something else? Sorry, I was too quick. I understand your concern. The problem is in 9.9.2: The accessible tree depends on the context node: o If the context node represents configuration data, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children. o Otherwise, the tree is all state data on the device, and the datastore. The XPath root node has all top-level data nodes in all modules as children. And it doesn't work to say that for notifs, the tree is made up of all state + running + the notification instance, since the notif might have the same name as a data node... /martin From j.schoenwaelder@jacobs-university.de Thu Jun 9 12:49: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 5366211E80E2 for ; Thu, 9 Jun 2011 12:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.131 X-Spam-Level: X-Spam-Status: No, score=-103.131 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwgjdcQ6Cbrm for ; Thu, 9 Jun 2011 12:49:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ED81011E813A for ; Thu, 9 Jun 2011 12:49:10 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7DEC20C32; Thu, 9 Jun 2011 21:49:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pqJAd0fLkcdq; Thu, 9 Jun 2011 21:49:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 194D120C2A; Thu, 9 Jun 2011 21:49:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8871A18EB218; Thu, 9 Jun 2011 21:49:08 +0200 (CEST) Date: Thu, 9 Jun 2011 21:49:08 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110609194908.GA351@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20110608.123122.2004591181866101810.mbj@tail-f.com> <20110609142233.GA1063@elstar.local> <20110609.163049.606529029089230976.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110609.163049.606529029089230976.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] notification mapping in draft-ietf-netmod-smi-yang-00 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, 09 Jun 2011 19:49:12 -0000 On Thu, Jun 09, 2011 at 04:30:49PM +0200, Martin Bjorklund wrote: > Are you saying that you think YANG, in notifications, allows leafrefs > w/o predicates but not w/ predicates? Or that leafrefs cannot be used > in notifications at all? Or something else? I got the impression that a notification leafref path xpath expression can only refer to data tree nodes, not to nodes in the notification itself. I assume there are namespace reasons behind the rule, that is there is a technical reason for this rule. > > Furthermore, section 9.9.2 says: > > > > The predicates are only used when more than one key reference is > > needed to uniquely identify a leaf instance. This occurs if a list > > has multiple keys, or a reference to a leaf other than the key in a > > list is needed. In these cases, multiple leafrefs are typically > > specified, and predicates are used to tie them together. > > > > In your example, the list has only a single key... > > With multiple keys, you get multiple predicates. Yes, but my reading of this text is that it is not allowed to use predicates if you only have a single simple key. I assume this rule is a case of an overspecification and should likely not have been here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Jun 9 12:56: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 366B711E81A3 for ; Thu, 9 Jun 2011 12:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFKMsyFRYhn5 for ; Thu, 9 Jun 2011 12:56:20 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3F111E80E2 for ; Thu, 9 Jun 2011 12:56:20 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id B8290616002; Thu, 9 Jun 2011 21:56:18 +0200 (CEST) Date: Thu, 09 Jun 2011 21:56:16 +0200 (CEST) Message-Id: <20110609.215616.362842345.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110609194908.GA351@elstar.local> References: <20110609142233.GA1063@elstar.local> <20110609.163049.606529029089230976.mbj@tail-f.com> <20110609194908.GA351@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] notification mapping in draft-ietf-netmod-smi-yang-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 19:56:21 -0000 Juergen Schoenwaelder wrote: > > > Furthermore, section 9.9.2 says: > > > > > > The predicates are only used when more than one key reference is > > > needed to uniquely identify a leaf instance. This occurs if a list > > > has multiple keys, or a reference to a leaf other than the key in a > > > list is needed. In these cases, multiple leafrefs are typically > > > specified, and predicates are used to tie them together. > > > > > > In your example, the list has only a single key... > > > > With multiple keys, you get multiple predicates. > > Yes, but my reading of this text is that it is not allowed to use > predicates if you only have a single simple key. I assume this rule is > a case of an overspecification and should likely not have been here. This text is probably a left over from when we had keyrefs only; slightly updated, but not completely correct. The second sentence is correct, it mentions that predicates are used if a reference to a non-key leaf is used. /martin From j.schoenwaelder@jacobs-university.de Thu Jun 9 13:07:35 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 43DC511E8192 for ; Thu, 9 Jun 2011 13:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.141 X-Spam-Level: X-Spam-Status: No, score=-103.141 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQOxZqrNhM06 for ; Thu, 9 Jun 2011 13:07:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DC9B911E8165 for ; Thu, 9 Jun 2011 13:07:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40E3020C32; Thu, 9 Jun 2011 22:07:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ycecEZJWDUDt; Thu, 9 Jun 2011 22:07:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A303F20C2A; Thu, 9 Jun 2011 22:07:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 27AD018EB2B3; Thu, 9 Jun 2011 22:07:31 +0200 (CEST) Date: Thu, 9 Jun 2011 22:07:31 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110609200731.GA414@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20110609142233.GA1063@elstar.local> <20110609.163049.606529029089230976.mbj@tail-f.com> <20110609194908.GA351@elstar.local> <20110609.215616.362842345.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110609.215616.362842345.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] notification mapping in draft-ietf-netmod-smi-yang-00 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, 09 Jun 2011 20:07:35 -0000 On Thu, Jun 09, 2011 at 09:56:16PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > > > Furthermore, section 9.9.2 says: > > > > > > > > The predicates are only used when more than one key reference is > > > > needed to uniquely identify a leaf instance. This occurs if a list > > > > has multiple keys, or a reference to a leaf other than the key in a > > > > list is needed. In these cases, multiple leafrefs are typically > > > > specified, and predicates are used to tie them together. > > > > > > > > In your example, the list has only a single key... > > > > > > With multiple keys, you get multiple predicates. > > > > Yes, but my reading of this text is that it is not allowed to use > > predicates if you only have a single simple key. I assume this rule is > > a case of an overspecification and should likely not have been here. > > This text is probably a left over from when we had keyrefs only; > slightly updated, but not completely correct. The second sentence is > correct, it mentions that predicates are used if a reference to a > non-key leaf is used. What about working out replacement text and filing an errata? This way we can be sure we won't forget this detail when RFC 6020 is revised. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Fri Jun 10 00:20: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 CD8D811E808E for ; Fri, 10 Jun 2011 00:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sslicWEj59Ml for ; Fri, 10 Jun 2011 00:20:53 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8F011E808A for ; Fri, 10 Jun 2011 00:20:53 -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 2270176C423; Fri, 10 Jun 2011 09:20:51 +0200 (CEST) Date: Fri, 10 Jun 2011 09:20:49 +0200 (CEST) Message-Id: <20110610.092049.2082455193220404034.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110606145830.GA25828@elstar.local> References: <20110605124229.GA21916@elstar.local> <20110606145830.GA25828@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] smi2yang-04: string vs. binary [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, 10 Jun 2011 07:20:54 -0000 Juergen Schoenwaelder wrote: > On Mon, Jun 06, 2011 at 10:40:37AM -0400, David Spakes wrote: > > Juergen, > > > > I think solution 04-04 is best, but in my opinion the cost would be > > less if every OCTET STRING object was treated the same way all the > > time. In other words, the choice should have a sysDescr-string leaf > > even if there is no DISPLAY-HINT. > > I assume sysDescr is not a good example since it has a DISPLAY-HINT. > If we take something that does not have a DISPLAY-HINT, then it is > rather unclear to me what the string representation is unless we > define one for strings that do not have a DISPLAY-HINT. But if we do > that and later a MIB module gets revised and a DISPLAY-HINT is added, > we are back to where we started since what is being added might > conflict with what was used before. This will be a problem in other cases as well, since SMIv2 allows the DISPLAY-HINT to be updated in new revisions. Besides, the DISPLAY-HINT is on the TEXTUAL-CONVENTION, and the choice would be for the leafs that use the TEXTUAL-CONVENTION. This means that if the TEXTUAL-CONVENTION is updated, all modules importing the TEXTUAL-CONVENTION would have to be re-translated. So I don't think this solution would work. So I think solution #04-01 is best. /martin From mbj@tail-f.com Fri Jun 10 00:40: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 3CB2211E80A9 for ; Fri, 10 Jun 2011 00:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6IlTarEu39Z for ; Fri, 10 Jun 2011 00:40:18 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id C275B11E8081 for ; Fri, 10 Jun 2011 00:40:18 -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 2F80476C2F3; Fri, 10 Jun 2011 09:40:18 +0200 (CEST) Date: Fri, 10 Jun 2011 09:40:16 +0200 (CEST) Message-Id: <20110610.094016.434708808347298122.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110607190939.GA29248@elstar.local> References: <20110606204337.GA27208@elstar.local> <20110607190939.GA29248@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] smi2yang-08: inline vs. outside smiv2:oid mapping [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, 10 Jun 2011 07:40:19 -0000 Juergen Schoenwaelder wrote: > I still like the readability of having all OIDs listed together > instead of just a subset. I'm note sure why this is important, it isn't possible in MIBs, so it is not clear why it is required here. Anyway, I think I mentioned another alternative at some point: Use inline smiv2:oid, and introduce smiv2:alias to be used at the top-level, with smiv2:oid as a substatement: smiv2:alias interfaces { smiv2:oid 1.3.6.1.2.1.2; } I like this better b/c the meaning of smiv2:oid doesn't change depending on if it has a substatement or not. /martin From j.schoenwaelder@jacobs-university.de Fri Jun 10 08:35: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 3268D11E8090 for ; Fri, 10 Jun 2011 08:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.149 X-Spam-Level: X-Spam-Status: No, score=-103.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IvS2TvRX+go for ; Fri, 10 Jun 2011 08:35:44 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFF711E81C3 for ; Fri, 10 Jun 2011 08:35:44 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E19F320C2A; Fri, 10 Jun 2011 17:35:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2rDdGnPB6IiT; Fri, 10 Jun 2011 17:35:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C05A20C32; Fri, 10 Jun 2011 17:35:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 979B818EBF35; Fri, 10 Jun 2011 17:35:41 +0200 (CEST) Date: Fri, 10 Jun 2011 17:35:41 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110610153541.GA1542@elstar.local> Mail-Followup-To: Martin Bjorklund , spakes@snmp.com, netmod@ietf.org References: <20110605124229.GA21916@elstar.local> <20110606145830.GA25828@elstar.local> <20110610.092049.2082455193220404034.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110610.092049.2082455193220404034.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-04: string vs. binary [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, 10 Jun 2011 15:35:45 -0000 On Fri, Jun 10, 2011 at 09:20:49AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Jun 06, 2011 at 10:40:37AM -0400, David Spakes wrote: > > > Juergen, > > > > > > I think solution 04-04 is best, but in my opinion the cost would be > > > less if every OCTET STRING object was treated the same way all the > > > time. In other words, the choice should have a sysDescr-string leaf > > > even if there is no DISPLAY-HINT. > > > > I assume sysDescr is not a good example since it has a DISPLAY-HINT. > > If we take something that does not have a DISPLAY-HINT, then it is > > rather unclear to me what the string representation is unless we > > define one for strings that do not have a DISPLAY-HINT. But if we do > > that and later a MIB module gets revised and a DISPLAY-HINT is added, > > we are back to where we started since what is being added might > > conflict with what was used before. > > This will be a problem in other cases as well, since SMIv2 allows the > DISPLAY-HINT to be updated in new revisions. > > Besides, the DISPLAY-HINT is on the TEXTUAL-CONVENTION, and the choice > would be for the leafs that use the TEXTUAL-CONVENTION. This means > that if the TEXTUAL-CONVENTION is updated, all modules importing the > TEXTUAL-CONVENTION would have to be re-translated. So I don't think > this solution would work. Yes, we would essentially have to create a choice for at least every OCTET STRING object. (I don't think the current translator every looks at DISPLAY-HINTs for INTEGER types.) > So I think solution #04-01 is best. It is the one currenty implemented. ;-) Perhaps we could explain that implementations may want to provie a mechanism to ignore DISPLAY-HINTs for certain types/objects so that in cases where a DISPLAY-HINT is added one can tweak the translation run via those mechanisms (e.g. command line options). This is how one would likely address this corner case in running code. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Sun Jun 12 08:15: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 6213B11E80A1; Sun, 12 Jun 2011 08:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.761 X-Spam-Level: X-Spam-Status: No, score=-101.761 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drVbOER2x9iw; Sun, 12 Jun 2011 08:15:20 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id BB6F211E8093; Sun, 12 Jun 2011 08:15:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKDW9E2HCzI1/2dsb2JhbABSpk53rXECmi2GJASWIIpz X-IronPort-AV: E=Sophos;i="4.65,355,1304308800"; d="scan'208";a="284589742" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Jun 2011 11:15:19 -0400 X-IronPort-AV: E=Sophos;i="4.65,355,1304308800"; d="scan'208";a="664313298" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 12 Jun 2011 11:15:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Jun 2011 17:15:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Closing down the NGO mail list Thread-Index: AcwpE4mUlWFMmxeeQV6Z8d3EZ4Kwag== From: "Romascanu, Dan (Dan)" To: "NETMOD Working Group" , "netconf" Subject: [netmod] Closing down the NGO mail list X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Jun 2011 15:15:21 -0000 Hi,=20 I asked the IESG secretary to close down the ngo@ietf.org mail list. NGO (NETCONF Goes on) was formed in 2006 and discussed the continuation of the NETCONF work. Discussions on that list contributed to the creation of the NETMOD WG, YANG and other NETCONF related lists. No useful traffic happened on that list for the last three years, and I actually thought that we had closed it until a spam mail last week reminded me about it.=20 Thanks and Regards, Dan=20 From j.schoenwaelder@jacobs-university.de Wed Jun 15 14:10: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 B827211E812B for ; Wed, 15 Jun 2011 14:10:53 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZRES2diVJuJ for ; Wed, 15 Jun 2011 14:10:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0402A11E80EB for ; Wed, 15 Jun 2011 14:10:51 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0203120C30 for ; Wed, 15 Jun 2011 23:10:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TKS19tjbb7Ag; Wed, 15 Jun 2011 23:10:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C450D20C2A; Wed, 15 Jun 2011 23:10:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C8EB5190ADAE; Wed, 15 Jun 2011 23:10:46 +0200 (CEST) Date: Wed, 15 Jun 2011 23:10:46 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110615211044.GD38540@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] document reviews 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, 15 Jun 2011 21:10:53 -0000 Hi, we have some fairly new WG documents and I would like to see more reviews posted to the list. Please do not wait for the next IETF meeting - work should be done also between the meetings. Here are the WG documents (see also ) waiting for your reviews: draft-ietf-netmod-iana-if-type-00 2011-04-11 (37 pages) draft-ietf-netmod-interfaces-cfg-01 2011-05-20 (23 pages) draft-ietf-netmod-routing-cfg-00 2011-04-27 (44 pages) draft-ietf-netmod-smi-yang-00 2011-04-13 (32 pages) And then there is a recent individual document addressing a chartered work item: draft-bierman-netmod-system-mgmt-00 2011-06-02 (23 pages) As you can see, most documents are fairly short (if you remove boilerplate text etc.) - so please review and let us know your comments. /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 Jun 18 06:54: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 7CCA311E80B0 for ; Sat, 18 Jun 2011 06:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.173 X-Spam-Level: X-Spam-Status: No, score=-103.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSNUpAtx5sdg for ; Sat, 18 Jun 2011 06:54:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B679011E80A8 for ; Sat, 18 Jun 2011 06:54:07 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF6AC20C29; Sat, 18 Jun 2011 15:54:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ApRKXayB3e-e; Sat, 18 Jun 2011 15:54:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1ADD820C1B; Sat, 18 Jun 2011 15:54:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AE344191DD48; Sat, 18 Jun 2011 15:54:04 +0200 (CEST) Date: Sat, 18 Jun 2011 15:54:04 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20110618135404.GA46751@elstar.local> Mail-Followup-To: Martin Bjorklund , spakes@snmp.com, netmod@ietf.org References: <20110606204337.GA27208@elstar.local> <20110607190939.GA29248@elstar.local> <20110610.094016.434708808347298122.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110610.094016.434708808347298122.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] smi2yang-08: inline vs. outside smiv2:oid mapping [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, 18 Jun 2011 13:54:08 -0000 On Fri, Jun 10, 2011 at 09:40:16AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > I still like the readability of having all OIDs listed together > > instead of just a subset. > > I'm note sure why this is important, it isn't possible in MIBs, so it > is not clear why it is required here. > > Anyway, I think I mentioned another alternative at some point: > > Use inline smiv2:oid, and introduce smiv2:alias to be used at the > top-level, with smiv2:oid as a substatement: > > smiv2:alias interfaces { > smiv2:oid 1.3.6.1.2.1.2; > } > > I like this better b/c the meaning of smiv2:oid doesn't change > depending on if it has a substatement or not. Martin, is this a proper writeup of your proposal? ** 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). /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 Sun Jun 19 13:41: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 1DA9911E80E3 for ; Sun, 19 Jun 2011 13:41:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE2-BItzc0hf for ; Sun, 19 Jun 2011 13:41:41 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by ietfa.amsl.com (Postfix) with ESMTP id 62B7211E8077 for ; Sun, 19 Jun 2011 13:41:41 -0700 (PDT) Received: from localhost (c213-100-166-57.swipnet.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A87CC616002; Sun, 19 Jun 2011 22:41:37 +0200 (CEST) Date: Sun, 19 Jun 2011 22:41:33 +0200 (CEST) Message-Id: <20110619.224133.427008247.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20110618135404.GA46751@elstar.local> References: <20110607190939.GA29248@elstar.local> <20110610.094016.434708808347298122.mbj@tail-f.com> <20110618135404.GA46751@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] smi2yang-08: inline vs. outside smiv2:oid mapping [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: Sun, 19 Jun 2011 20:41:42 -0000 Juergen Schoenwaelder wrote: > Martin, > > is this a proper writeup of your proposal? Yes. /martin > > ** 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). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From j.schoenwaelder@jacobs-university.de Wed Jun 22 08:11: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 A4F4A11E80A9 for ; Wed, 22 Jun 2011 08:11:41 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cHHfJ6P3iBg for ; Wed, 22 Jun 2011 08:11:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C89EF11E80A3 for ; Wed, 22 Jun 2011 08:11:40 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B72CB210A6 for ; Wed, 22 Jun 2011 17:11:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9q6mdcjxbiAZ; Wed, 22 Jun 2011 17:11:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E7F020F1B; Wed, 22 Jun 2011 17:11:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F3FB51921B2F; Wed, 22 Jun 2011 17:11:27 +0200 (CEST) Date: Wed, 22 Jun 2011 17:11:27 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110622151127.GC56225@elstar.local> Mail-Followup-To: netmod@ietf.org References: <20110615211044.GD38540@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110615211044.GD38540@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [netmod] document reviews 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, 22 Jun 2011 15:11:41 -0000 On Wed, Jun 15, 2011 at 11:10:46PM +0200, Juergen Schoenwaelder wrote: > Hi, > > we have some fairly new WG documents and I would like to see more > reviews posted to the list. Please do not wait for the next IETF > meeting - work should be done also between the meetings. Here are the > WG documents (see also ) waiting > for your reviews: > > draft-ietf-netmod-iana-if-type-00 2011-04-11 (37 pages) > draft-ietf-netmod-interfaces-cfg-01 2011-05-20 (23 pages) > draft-ietf-netmod-routing-cfg-00 2011-04-27 (44 pages) > draft-ietf-netmod-smi-yang-00 2011-04-13 (32 pages) > > And then there is a recent individual document addressing a chartered > work item: > > draft-bierman-netmod-system-mgmt-00 2011-06-02 (23 pages) > > As you can see, most documents are fairly short (if you remove > boilerplate text etc.) - so please review and let us know your > comments. One week has passed, not a single response. Shall the chairs consider the option to close down some work items due to a lack of WG interest? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Sun Jun 26 09:22: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 B1A2B1F0C36 for ; Sun, 26 Jun 2011 09:22:44 -0700 (PDT) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K00O0mBIMo5M for ; Sun, 26 Jun 2011 09:22:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 816751F0C40 for ; Sun, 26 Jun 2011 09:22:42 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D02A020EFE for ; Sun, 26 Jun 2011 18:22:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Kmc5ngAqkN20; Sun, 26 Jun 2011 18:22:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A0BA320EFC; Sun, 26 Jun 2011 18:22:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 529211971496; Sun, 26 Jun 2011 18:22:39 +0200 (CEST) Date: Sun, 26 Jun 2011 18:22:39 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20110626162239.GB99054@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] NOMCOM volunteers needed 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, 26 Jun 2011 16:22:44 -0000 Hi, this is the usual NOMCOM reminder requested by our AD. Consider volunteering so you can help selecting the best people for the leadership. /js ----- Forwarded message from "Romascanu, Dan (Dan)" ----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Suresh Krishnan Sent: Friday, June 24, 2011 9:13 PM To: IETF Discussion Subject: Nomcom 2011-2012: Second Call for Volunteers This is the Second call for Volunteers for the 2011-12 Nomcom. We are just about halfway through the volunteer period so if you are considering volunteering, please do so very soon. We have had a very good response to the initial call for volunteers and I am pleased to report that we have 50 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. You have until 11:59 pm EDT July 10, 2011 to volunteer for Nomcom but it would be much better if you can volunteer as early as possible. If you volunteered before 21:00 EDT on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! Details about the process for volunteering for the Nomcom and the list of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 50 volunteers who have thus far been qualified by the secretariat are: Alia Atlas , Juniper Networks Lixia Zhang , UCLA Wassim Haddad , Ericsson Glen Zorn , Network Zen Richard Barnes , BBN Technologies Stephen Kent , BBN Technologies Scott Mansfield , Ericsson Tina TSOU , FutureWei Technologies Fernando Gont , UTN/FRH Karen Seo , BBN Technologies Jie Dong , Huawei Technologies Mach Chen , Huawei Technologies Co. Sheng Jiang , Huawei Technologies Co. Ltd. Dimitri Papadimitriou , Alcatel-Lucent Thomas D. Nadeau , CA Technologies David Meyer , Cisco Systems/University of Oregon Wesley George , Time Warner Cable Cullen Jennings , Cisco Stephen Hanna , Juniper Networks Stephan Wenger , Bidyo Keyur Patel , Cisco Systems Michael Hamilton , BreakingPoint Systems Behcet Sarikaya , Huawei USA Mark Townsley , Cisco Systems Fred Baker , Cisco Systems Brian Trammell , ETH Zurich Sam Hartman , Painless Security Chris Griffiths , Comcast George Michaelson , APNIC Jiankang Yao , CNNIC Sohel Khan , Comcast Dacheng Zhang , Huawei Lianshu Zheng , Huawei Technologies Hui Deng , China Mobile Gang Chen , China Mobile Mirja Kuhlewind , University of Stuttgart John E Drake , Juniper Networks Matt Lepinski , BBN Technologies Subir Das , Telcordia Technologies Inc Yi Zhao , Huawei John Scudder , Juniper Networks Christer Holmberg , LM Ericsson Teemu Savolainen , Nokia Samita Chakrabarti , Ericsson Jaap Akkerhuis , NLnet labs Jason Weil , Time Warner Cable Randy Bush , Internet Initiative Japan Christian Schmidt , Nokia Siemens Networks Sean Shen , CNNIC Lou Berger , LabN Consulting The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email to me before 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that Nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the Nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ----- End forwarded message ----- From wwwrun@rfc-editor.org Thu Jun 30 12:46: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 03E0111E80D6; Thu, 30 Jun 2011 12:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.815 X-Spam-Level: X-Spam-Status: No, score=-105.815 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iLATE-llJDP; Thu, 30 Jun 2011 12:46:21 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id 35D5C11E8079; Thu, 30 Jun 2011 12:46:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 262A798C530; Thu, 30 Jun 2011 12:46:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110630194621.262A798C530@rfc-editor.org> Date: Thu, 30 Jun 2011 12:46:21 -0700 (PDT) Cc: netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] RFC 6244 on An Architecture for Network Management Using NETCONF and YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Jun 2011 19:46:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6244 Title: An Architecture for Network Management Using NETCONF and YANG Author: P. Shafer Status: Informational Stream: IETF Date: June 2011 Mailbox: phil@juniper.net Pages: 30 Characters: 63276 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netmod-arch-10.txt URL: http://www.rfc-editor.org/rfc/rfc6244.txt The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities. This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the NETCONF Data Modeling Language Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From kwatsen@juniper.net Thu Jun 30 15:28: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 B4F0711E8101 for ; Thu, 30 Jun 2011 15:28:08 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J123IHbb-Ouo for ; Thu, 30 Jun 2011 15:28:08 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id A955011E80B6 for ; Thu, 30 Jun 2011 15:28:07 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTgz4dAYyO9L6y9w2A6sCaUXKeoXbUuKO@postini.com; Thu, 30 Jun 2011 15:28:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 30 Jun 2011 15:25:59 -0700 From: Kent Watsen To: "Ersue, Mehmet (NSN - DE/Munich)" , "bernd.linowski.ext@nsn.com" Date: Thu, 30 Jun 2011 15:25:57 -0700 Thread-Topic: [netmod] RFC 6095 on Extending YANG with Language Abstractions Thread-Index: Acvt9WS6YcCc+/pLQSef45CqmmzfxgAFYacAEll0NVA= Message-ID: <84600D05C20FF943918238042D7670FD3E837E792B@EMBX01-HQ.jnpr.net> References: <20110329094034.GA27275@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401DAA8E8@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6401DAA8E8@DEMUEXC006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netmod@ietf.org" Subject: Re: [netmod] RFC 6095 on Extending YANG with Language Abstractions X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Jun 2011 22:28:08 -0000 > We would be happy to hear from folks who plan to use the language extensi= ons > in RFC 6095 for modeling. Please send Bernd and myself a note if you woul= d > like to have support for such a modeling effort. I have the need to define a hierarchal data structure now...so count me in = for giving it a whirl =20 > There is an open source validation tool for YANG Complex Types and Typed= =20 > Instance Identifiers available at http://code.google.com/p/pyang-ct/.=20 Is this being maintained? - last pyang-ct check-in was over a year ago, but= pyang has been updated since... BTW, I never understood why this statement in section 7.11:=20 "A grouping MUST NOT reference itself, neither directly nor indirectly through a chain of other groupings." Can anybody recall? Thanks, Kent From ietf@andybierman.com Thu Jun 30 15:50: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 EEBDD21F8842 for ; Thu, 30 Jun 2011 15:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrnyGWpeuS6K for ; Thu, 30 Jun 2011 15:50:55 -0700 (PDT) Received: from omr14.networksolutionsemail.com (omr14.networksolutionsemail.com [205.178.146.64]) by ietfa.amsl.com (Postfix) with ESMTP id 36BDB21F8496 for ; Thu, 30 Jun 2011 15:50:55 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr14.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p5UMosH3017209 for ; Thu, 30 Jun 2011 18:50:54 -0400 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:49720] helo=[192.168.0.22]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 6F/14-07512-DCDFC0E4; Thu, 30 Jun 2011 18:50:54 -0400 Message-ID: <4E0CFDC6.6030009@andybierman.com> Date: Thu, 30 Jun 2011 15:50:46 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kent Watsen References: <20110329094034.GA27275@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A6401DAA8E8@DEMUEXC006.nsn-intra.net> <84600D05C20FF943918238042D7670FD3E837E792B@EMBX01-HQ.jnpr.net> In-Reply-To: <84600D05C20FF943918238042D7670FD3E837E792B@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "bernd.linowski.ext@nsn.com" , "netmod@ietf.org" Subject: Re: [netmod] RFC 6095 on Extending YANG with Language Abstractions X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 30 Jun 2011 22:50:56 -0000 On 06/30/2011 03:25 PM, Kent Watsen wrote: >> We would be happy to hear from folks who plan to use the language extensions >> in RFC 6095 for modeling. Please send Bernd and myself a note if you would >> like to have support for such a modeling effort. > > I have the need to define a hierarchal data structure now...so count me in for giving it a whirl > > > >> There is an open source validation tool for YANG Complex Types and Typed >> Instance Identifiers available at http://code.google.com/p/pyang-ct/. > > Is this being maintained? - last pyang-ct check-in was over a year ago, but pyang has been updated since... > > > > BTW, I never understood why this statement in section 7.11: > > "A grouping MUST NOT reference itself, neither directly nor > indirectly through a chain of other groupings." > > Can anybody recall? > > There is no end condition to stop the recursion. The WG wanted to keep things reasonably simple to implement. > > Thanks, > Kent Andy