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

From: RFC Errata System <[email-masked]>
Date: Mon, 23 Jul 2012 02:21:02 -0700 (PDT)

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-masked]>

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

---

From: Acee Lindem <[email-masked]>
Date: Tue, 24 Jul 2012 10:50:40 -0400

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Jul 2012 18:59:44 +0100

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?
- 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-masked]]
> Sent: 24 July 2012 15:51
> To: Joan Cucchiara
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Editorial Errata Reported] RFC4750 (3292)
> 
> Hi Joan,
>   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
> 
> > 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):
> >
> > 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:
> > -------------
> > Author(s)           : D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed., R.
Coltun, F.
> Baker

---

From: Acee Lindem <[email-masked]>
Date: Tue, 24 Jul 2012 14:11:09 -0400

Hi Adrian,

> - 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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 24 Jul 2012 18:51:27 +0000

> 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).

>>>> Source              : Open Shortest Path First IGP

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan

---

From: Acee Lindem <[email-masked]>
Date: Wed, 25 Jul 2012 09:33:42 -0400

Hi Fred,

> 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

---

From: "Joyal, Daniel R (Dan)" <[email-masked]>
Date: Wed, 25 Jul 2012 11:17:37 -0400

Some relevant e-mail on the topic.

http://www.ietf.org/mail-archive/web/ospf/current/msg05876.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Acee Lindem
Sent: Wednesday, July 25, 2012 9:34 AM
To: Fred Baker (fred)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OSPF] [Editorial Errata Reported] RFC4750 (3292)

Hi Fred,

On Jul 24, 2012, at 2:51 PM, Fred Baker (fred) wrote:

>>> The trouble is that it changes the compilable content of the module, 
>>> if not the key parts.
>>> 

Thanks,
Acee 

>>>> Cc: [email-masked]; [email-masked]; 
>>>> [email-masked]; [email-masked]; [email-masked]; 
>>>> [email-masked]; [email-masked]; [email-masked]; 
>>>> [email-masked]
>>>>> The following errata report has been submitted for RFC4750, "OSPF 
>>>>> Version 2 Management Information Base".
>>>>> 
>>>> a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2 
>>>> (brackets added to indicate pertinent rule):
>>>>> 
>>>>> also be used to name unconditionally optional groups.  [A group 
>>>>> named in a GROUP clause must be absent from the correspondent 
>>>>> MANDATORY- GROUPS clause.]"
>>>>> 
>>>> 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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 25 Jul 2012 18:59:34 +0000

> 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?

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).

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.

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.

---

From: t.petch <[email-masked]>
Date: Thu, 26 Jul 2012 17:57:20 +0100

Fred

RFC2578 s10.2 would allow a SYNTAX to be replaced by a textual
convention, but not vice versa.  I am trying to see the lurking dragon
but have yet to do so.

I agree that spinning a MIB module is a lot of work and on the evidence
to date, the benefits seem limited.

Tom Petch

----- Original Message -----
From: "Fred Baker (fred)" <[email-masked]>
To: "Acee Lindem" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, July 25, 2012 7:59 PM
> >>> 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.
> >> 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?
>
> 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).
>
> Looking on the web, I found at least two implementations, one of which
is read-only and doesn't implement 26 of the objects.
> 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/co
nfiguration/guide/b_routing_cg42crs_chapter_0100.html#concept_0B3C41DB4B
9C4BA39FB2B1BDA0A777CD
http://www.juniper.net/techpubs/en_US/junos/topics/reference/standards/s
nmp-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.
>
>
> 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.
> >>>>> Cc: [email-masked]; [email-masked];
[email-masked];
> >>>>> a GROUP clause. Per RFC 2580, Conformance Statements for SMIv2
(brackets
> >>>>>> also be used to name unconditionally optional groups.  [A group
named
> >>>>> STATUS current in RFC 1850 and STATUS obsolete in 4750; however,
obsolete or
> >>>>> not, it is not legal according to SMI rules.
please