[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FW: [802.1] P802.1b/D0



Comments inline.

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Monday, December 23, 2002 11:15 AM
> To: Harrington, David; MIB Doctors (E-mail)
> Cc: Dan Romascanu (Dan) (E-mail); Les Bell (E-mail)
> Subject: Re: FW: [802.1] P802.1b/D0
> 
> 
> HI,
> 
> Thanks for bring this to our attention.
> 
> First, labeling restrictions as "crappy little rules" is really
> not productive.

Having lots of CLRs is really not productive, but it hasn't stopped us from having them. There are many things that are now CLRs that once were reasonable "restrictions", such as 32-character limits on descriptors. One man's trash is often another man's treasure. I used the CLR term within a community of mib experts, who understand about the relationship between CLRs and restrictions. I'm sorry if my use of the term offended you.

> 
> Secondly, I'm confused with the description of the problem situation.
> Is it
> 1) several different OID values being associated with the same
>    object type (notification type, etc)
> 2) the same ASN.1 identifier (in different modules) being used
>    for different object types (notification types, etc)
> 
> If it is the first, then there is a big problem. 

If you read the section on migration, they discuss assigning new OIDs for the same identified "thing" for tidyness. Since they use OIDs primarily for OBJECT-TYPE assignments in MIB modules, I take that to mean they think it might be tidy to reassign the OIDs for object types and/or notification-types. They state that there is no requirement to remove the old assignment; to quote "it is possible to add a second Object Identifier value to identify the same object." I think that is inconsistent with commonly accepted restrictions (that some might consider a CLR) used in the SNMP community.

> If it is the
> second, then it is not a problem (except for certain vendor
> tool-kits and applications). The second is not a problem
> because it can "occur naturally" in the wild, and is not
> illegal in the SMI when it occurs when the modules are
> developed by different enterprises.

I don't think I said anything about anything being illegal. I suggested that we make recommendations to them about some of the restrictions/CLRs/conventions used in the SNMP community. This would include conventions for creating unique descriptor names. I was thinking of some of those CLRs such as starting all object descriptors with a prefix that is consistent for all objects in the mib module.

My primary concern is that the IEEE doesn't standardize mib module practices that break IETF-compliant SNMP applications.

dbh

> 
> At 10:48 AM 12/23/2002 -0500, Harrington, David wrote:
> 
> >FYI.
> >
> >This is is the IEEE 802.1b proposal for allocating OIDs for 
> their future standards.
> >http://www.ieee802.org/1/mirror/8021/802-b-drafts/d0/802b-d0.pdf
> >
> >It is scheduled for discussion at the January IEEE 802.1b interim.
> >
> >The primary use of IEEE OIDs appears to be for MIBs, so I 
> thought it prudent to ask this group to take a look at their 
> proposal and make recommendations.
> >
> >I note that in their section on migrating OIDs, they do not 
> discuss SMI rules, and since mibs are being developed, it 
> would be good if some of the CLRs we use are noted, such as 
> not having multiple OIDs for the same mib descriptor, and 
> conventions for creating unique descriptor names.
> >
> >Dan Romascanu and Les Bell have been acting as (unofficial?) 
> liaisons between 802.3 and 802.1 groups and the corresponding 
> IETF working groups. It would probably be good practice to 
> work through them if they are willing to provide that coordination.
> >
> >dbh
> Regards,
> /david t. perkins 
> 
>