Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292)

[Acee Lindem <[e-mail]>]

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:[e-mail]]
>>>>>> Sent: 24 July 2012 15:51
>>>>>> To: Joan Cucchiara
>>>>>> Cc: [e-mail]; [e-mail]; [e-mail];
>>>>>> [e-mail]; [e-mail]; [e-mail]; [e-mail];
>>>>>> [e-mail]; [e-mail]
>>>>>> 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 <[e-mail]>
>>>>>>> 
>>>>>>> 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
>