Some relevant e-mail on the topic. http://www.ietf.org/mail-archive/web/ospf/current/msg05876.html
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Acee Lindem Sent: Wednesday, July 25, 2012 9:34 AM To: Fred Baker (fred) Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292) 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. 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 > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
