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. 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 > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
