[Idr] RFC 1657 MIB errors/corrections

[Jeffrey Haas <[e-mail]>]

Joan,

I'm forking this particular thread regarding issues propagated from 
RFC 1657 so we can track it separately.

If someone could get Bert Wijnen and Sharon Chisholm's attention for
this thread it will help drive it to completion quicker.

Please excuse the long quoted sections ahead.

On Fri, Jul 04, 2008 at 08:52:24PM -0400, Joan Cucchiara wrote:
>>>>> W: f(BGP4-MIB), (2689,5) Table "bgpRcvdPathAttrTable" and
>>>>> Row "bgpPathAttrEntry" should have same name prefix
>>>>
>>>> This issue was previously existing for earlier versions of this MIB and
>>>> cannot be changed.
>>>>
>>>
>>> I would encourage the working group to fix these sorts of obvious 
>>> mistakes
>>> rather than carry them forward for a few reasons:
>>>
>>> 1) A great deal of this MIB is changing already so the working group may
>>> want
>>> to reconsider fixing this mistake,
>>> 2) MIB tools which generate code "might" find errors here and so 
>>> developers
>>> are left dealing with fixing these sorts of bugs by going in and editing
>>> files that are generated (usually not what we want to do).
>>> 3)  If the intention is to make this MIB one that is the basis for other
>>> BGP
>>> MIBs then having a solid foundation to build upon is important IMHO, so
>>> again
>>> would request that the working group consider this.  Certainly, I will
>>> abide
>>> by their decision.
>>
>> This portion of the MIB is widely deployed.  I'm going to recommend
>> against changing this.  If you feel strongly otherwise, let's grab Bert
>> and/or the relevant ops-nm folk and go offlist for the discussion.
>
> I think it's best to keep these sorts of discussions on
> the list since (as you point out) the previous version(s) of
> this MIB are widely deployed.  If folks have an opinion
> about this issue or other parts of the MIB draft,
> this is an opportunity for them to give it.
>
> Speaking more broadly than just this issue for a moment:
> I think there is some misunderstandings here with what
> typically happens when MIBs
> are revised.  Vendors support both (or even several)
> versions of a MIB, leaving it to the customer to decide
> what they want to deploy.  Sometimes customers have supported
> different versions of the same MIB, and when customers
> do (eventually) upgrade to the latest and greatest
> MIB, this process is done with much testing and usually
> involves testing the entirety of the MIB (not just parts that changed).
> While there are benefits to keeping parts of the MIB the same,
> those benefits are more limited than one might think.
>
> According to http://www.ietf.org/ID-nits.html
>  All MIB modules SHOULD have correct SYNTAX, so they should compile cleanly 
> using:
>     smilint -m -s -l 6 -i namelength-32 <module>
>
> (disregarding only those warnings pertaining to names longer than 32
> characters)
>
> Getting back to this specific SMI mistake, you state that the MIB
> is widely deployed, but since this is an SMI mistake, and
> since many folks probably fix this so that the MIB can
> be downloaded and/or compiled by MIB tools, what exactly
> is being deployed?  Is it the fixed syntax, or is it this MIB as written?

The syntax of the portions of the MIB propagated from RFC 1657 that
generate errors fall into three classes:

 - Violations of variable naming conventions.
 - INDEX objects that are read-only instead of not-accessible.
 - Inclusion of those INDEX objects in Notifications.

Naming convention violations:

As best I am able to tell, while the violation of the naming convention
is not completely at odds with SMIv2 (RFC 2578).  Even smilint considers
this only a warning.

When this issue was raised during the work on RFC 4273, the consensus
within the OPS group review was that it was better to leave these
entries alone since they had been long deployed and renaming them
wouldn't provide sufficient benefit.

Could you please bounce this issue to OPS and request additional
feedback, especially among those involved at the time?  

INDEX MAX-ACCESS issues:

I was similarly recommended to leave this alone.  This fell under the
following from RFC 2578:

:    Objects which are both specified in the INDEX clause of a conceptual
:    row and also columnar objects of the same conceptual row are termed
:    auxiliary objects.  The MAX-ACCESS clause for auxiliary objects is
:    "not-accessible", except in the following circumstances:
: 
: (1)  within a MIB module originally written to conform to SMIv1, and
:      later converted to conform to SMIv2; or

Inclusion of INDEX object in Notifications:

This is similarly a warning and shouldn't result in an on-the-wire
error.  The restriction in SMIv2 (RFC 2578, Section 8.1) is:

: 8.1. Mapping of the OBJECTS clause
: 
: [...]
: 
: An object type specified in this clause must not have an MAX-ACCESS
: clause of "not-accessible".

The notifications generating the error, bgpEstablishNotification and
bgpBackwardTransNotification, were specifically made to address issues
with bgpEstablished and bgpBackwardTransition while providing parity
with their OBJECTS clauses.  

The consensus at the time of last call was that this was not an ideal
"fix" but was the best available one at the time.  

All new objects in the BGP MIBv2 based off the Af tables do the Right
Thing while at the same time deprecating the older objects that are at
issue.

-----

Most of the above was based off of a desire to minimally disrupt a
widely deployed MIB.  Additionally this represents OPS WG consensus 
for dealing with these conversion errors.  If you can get OPS WG
consensus on making your desired changes, I'm happy to put them in the
MIB.

-- Jeff
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr