Hi Fred, On Jul 25, 2012, at 2:59 PM, Fred Baker (fred) wrote:
> > On Jul 25, 2012, at 6:33 AM, Acee Lindem wrote: > >> Hi Fred, >> >> On Jul 24, 2012, at 2:51 PM, Fred Baker (fred) wrote: >> >>> >>> On Jul 24, 2012, at 11:11 AM, Acee Lindem wrote: >>> >>>> Hi Adrian, >>>> >>>> On Jul 24, 2012, at 1:59 PM, Adrian Farrel wrote: >>>> >>>>> Hi, >>>>> >>>>> This sort of erratum in a MIB module bothers me. >>>>> The trouble is that it changes the compilable content of the module, if >>>>> not the >>>>> key parts. >>>>> >>>>> So, the order of process is: >>>>> - Is the erratum correct? >>>>> - Is a fix *required* (i.e., is the module unusable without it?) >>>>> - Can the erratum be held for a revision of the module? >>>>> - How urgent is such a revision? >>>> >>>> Given that RFC 1850 has been around for over 17 years and there are many >>>> existing implementations, I would suffice it to say that this correction >>>> would not in and of itself warrant a revision. >>>> OTOH, there are problems with the OSPFv3 MIB ranges that should be >>>> corrected with a revision. >>> >>> Can we identify that set of issues? If we can list them along with >>> appropriate modifications, the paperwork exercise isn't all that hard >>> (apart from dealing with the MIB Doctors). >> >> At a minimum, we need to fix the fact that ospfv3RestartAge and >> ospfv3NbrRestartHelperAge are defined as Ospfv3UpToRefreshIntervalTC which >> is Unsigned32 (1..1800). This poses a problem of what to return when these >> MIB variables are not applicable since 0 is invalid. >> We may find some other additions and corrections now that we have some >> implementation experience. Speaking as OSPF WG co-chair, we'd be happy if >> you would be willing to take on this task. > > If the object is inapplicable, why would it not be treated as if it didn't > exist in the scenario? On a GET, return noSuchObject, and on a GET-NEXT or > GET-BULK, skip it? Both objects are read-only. Do we have an erratum on these? This is not an option since these are mandatory objects in the MIB compliance. > > If you want to return a magic value such as zero, that's a change to the TC > plus some text to the effect that "zero is only used in" this case. There are > a number of other objects that use the TC; if you don't see a need to change > them (and you probably really don't want to be able to configure, to name > one, ospfv3IfRetransInterval to zero), we're better off simply redefining the > two objects as Integer32(0..1800) or defining a new TC and changing the > object definitions to that. This suggestion might make the MIB Doctors crazy; > as I understand it, the data on the wire will be Integer32(0..1800) no matter > what, so the TC change is cosmetic. I would assume "there be dragons here" > until someone from MIB-land tells me otherwise. > > Spinning a MIB triggers a lot of reviews; it would be good to know who has > implemented this and what their experience has been, from the perspective of > taking RFC 5643 to Draft Standard > (https://tools.ietf.org/html/rfc2026#section-4.1.2) or Internet Standard (RFC > 6410). I agree but this change cannot be fixed with an errata. > > Looking on the web, I found at least two implementations, one of which is > read-only and doesn't implement 26 of the objects. > > ospfv3HostAddressType > ospfv3HostAddress > ospfv3HostMetric > ospfv3HostRowStatus > ospfv3HostAreaID > ospfv3CfgNbrTable > ospfv3ExitOverflowInterval > ospfv3ReferenceBandwidth > ospfv3RestartSupport > ospfv3RestartInterval > ospfv3RestartStrictLsaChecking > ospfv3RestartStatus > ospfv3RestartAge > ospfv3RestartExitReason > ospfv3NotificationEnable > ospfv3StubRouterSupport > ospfv3StubRouterAdvertisement > ospfv3DiscontinuityTime > ospfv3RestartTime > ospfv3AreaNssaTranslatorRole > ospfv3AreaNssaTranslatorState > ospfv3AreaNssaTranslatorStabInterval > ospfv3AreaNssaTranslatorEvents > ospfv3AreaTEEnabled > ospfv3IfMetricValue > ospfv3IfDemandNbrProbe > > As I understand it, going to Draft Standard or Internet Standard (are we on > the 2026 or 6410 model?) means removal/deprecation of anything we can't show > multiple interoperable implementation of. Really? > > > What I found: > http://www.cisco.com/en/US/docs/routers/crs/software/crs_r4.2/routing/configuration/guide/b_routing_cg42crs_chapter_0100.html#concept_0B3C41DB4B9C4BA39FB2B1BDA0A777CD > > http://www.juniper.net/techpubs/en_US/junos/topics/reference/standards/snmp-std-mibs-junos-nm.html > (search for "5643"). > > I'm not sure about Quagga's status. Google.com reports mostly that Quagga > doesn't implement the MIB, but I found a reference at code.google.com to the > effect that Google has developed an open source implementation; the code the > link takes me to is for GNU Zebra. > > I think we would need to know who else has implemented it and what they have > done with it. And to be honest, I personally would like to hear a little more > "use in anger" before getting all revved up on this. I can poll the implementation that reported the problem. I suspect it was just a matter of supplanting their MIB tools to allow 0 to be returned. > > > My suggestion: At this particular meeting, while I have a topic I would like > to kick around with Jari and others on the zospf-redux model he's working on, > I am scheduled into opsawg at the same time as ospf at IETF 84, and I don't > think the MIB is ready to have a f2f discussion on. It's suggest that we kick > it around on the mailing list with a view to f2f discussion at IETF 85 or 86. We can start another thread. However, I believe we'll end up with the same answer. Thanks, Acee > >> Thanks, >> Acee >> >> >>> >>>> Thanks, >>>> Acee >>>> >>>> >>>>> - Do we have candidates to revise the document? >>>>> >>>>> Cheers, >>>>> Adrian (speaking as an AD who does MIB modules a bit, but not the AD for >>>>> OSPF) >>>>> >>>>>> -----Original Message----- >>>>>> From: Acee Lindem [mailto:[email protected]] >>>>>> Sent: 24 July 2012 15:51 >>>>>> To: Joan Cucchiara >>>>>> Cc: [email protected]; [email protected]; [email protected]; >>>>>> [email protected]; [email protected]; [email protected]; [email protected]; >>>>>> [email protected]; [email protected] >>>>>> Subject: Re: [Editorial Errata Reported] RFC4750 (3292) >>>>>> >>>>>> Hi Joan, >>>>>> If you have a minute could you comment as to: >>>>>> 1. Is the subject Errata correct? >>>>>> 2. If so, does it have any consequence other than editorial content? It >>>>> doesn't >>>>>> appear to me that any MIB tools have complained about it. >>>>>> >>>>>> Thanks, >>>>>> Acee >>>>>> >>>>>> On Jul 23, 2012, at 5:21 AM, RFC Errata System wrote: >>>>>> >>>>>>> >>>>>>> The following errata report has been submitted for RFC4750, >>>>>>> "OSPF Version 2 Management Information Base". >>>>>>> >>>>>>> -------------------------------------- >>>>>>> You may review the report below and at: >>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=4750&eid=3292 >>>>>>> >>>>>>> -------------------------------------- >>>>>>> Type: Editorial >>>>>>> Reported by: Michael Kirkham <[email protected]> >>>>>>> >>>>>>> Section: 5 >>>>>>> >>>>>>> Original Text >>>>>>> ------------- >>>>>>> ospfTrapCompliance MODULE-COMPLIANCE >>>>>>> STATUS obsolete >>>>>>> DESCRIPTION >>>>>>> "The compliance statement." >>>>>>> MODULE -- this module >>>>>>> MANDATORY-GROUPS { ospfTrapControlGroup } >>>>>>> >>>>>>> GROUP ospfTrapControlGroup >>>>>>> DESCRIPTION >>>>>>> "This group is optional but recommended for all >>>>>>> OSPF systems." >>>>>>> ::= { ospfTrapCompliances 1 } >>>>>>> >>>>>>> Corrected Text >>>>>>> -------------- >>>>>>> ospfTrapCompliance MODULE-COMPLIANCE >>>>>>> STATUS obsolete >>>>>>> DESCRIPTION >>>>>>> "The compliance statement." >>>>>>> MODULE -- this module >>>>>>> GROUP ospfTrapControlGroup >>>>>>> DESCRIPTION >>>>>>> "This group is optional but recommended for all >>>>>>> OSPF systems." >>>>>>> ::= { ospfTrapCompliances 1 } >>>>>>> >>>>>>> Notes >>>>>>> ----- >>>>>>> ospfTrapControlGroup is listed both in the MANDATORY-GROUPS clause and >>>>>>> in >>>>>> a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2 (brackets >>>>>> added to indicate pertinent rule): >>>>>>> >>>>>>> "5.4.2. Mapping of the GROUP clause >>>>>>> >>>>>>> The GROUP clause, which need not be present, is repeatedly used to >>>>>>> name each object and notification group which is conditionally >>>>>>> mandatory for compliance to the MIB module. The GROUP clause can >>>>>>> also be used to name unconditionally optional groups. [A group named >>>>>>> in a GROUP clause must be absent from the correspondent MANDATORY- >>>>>>> GROUPS clause.]" >>>>>>> >>>>>>> It is listed in both clauses in RFC 1850 as well (which RFC 4750 >>>>>>> obsoletes). >>>>> It is >>>>>> STATUS current in RFC 1850 and STATUS obsolete in 4750; however, >>>>>> obsolete or >>>>>> not, it is not legal according to SMI rules. >>>>>>> >>>>>>> Instructions: >>>>>>> ------------- >>>>>>> This errata is currently posted as "Reported". If necessary, please >>>>>>> use "Reply All" to discuss whether it should be verified or >>>>>>> rejected. When a decision is reached, the verifying party (IESG) >>>>>>> can log in to change the status and edit the report, if necessary. >>>>>>> >>>>>>> -------------------------------------- >>>>>>> RFC4750 (draft-ietf-ospf-mib-update-11) >>>>>>> -------------------------------------- >>>>>>> Title : OSPF Version 2 Management Information Base >>>>>>> Publication Date : December 2006 >>>>>>> Author(s) : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, >>>>>>> Ed., R. >>>>> Coltun, F. >>>>>> Baker >>>>>>> Category : PROPOSED STANDARD >>>>>>> Source : Open Shortest Path First IGP >>>>>>> Area : Routing >>>>>>> Stream : IETF >>>>>>> Verifying Party : IESG >>>>> >>>>> >>>> >>> >>> ---------------------------------------------------- >>> The ignorance of how to use new knowledge stockpiles exponentially. >>> - Marshall McLuhan >>> >> > > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially. > - Marshall McLuhan >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
