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). > 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 _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
