Subject: (ION) IPOA-MIB and transmission sub-numbering policy

From: Gary Hanson <[email-masked]>
Date: Tue, 14 Apr 1998 10:37:40 -0700 (PDT)

I am happy to see that RFC 2225 and RFC 2320 were published yesterday.
That is real good news!

I am curious, however, about the policy used to number objects under
the "transmission" sub-hierarchy.  How did the "ipoaMIB" object come to
be defined as "{ transmission 46 }" instead of "{ transmission 114 }"?

I do not want to imply that I think that a mistake has been made, but
given the two definitions of "hssi(46)" and "ipoaOverAtm(114)" in the
"IANAifType" TEXTUAL-CONVENTION, I would have expected "ipoaMIB" to be
defined as "{ transmission 114 }" instead of "{ transmission 46 }", or
else as "{ mib-2 <something> }".

I had always thought that a MIB representing the control and reporting
capabilities of an interface with an "IANAifType" value of X would have
its object hierarchy (and possibly its MODULE-IDENTITY as well) defined
under "{ transmission X }".  This seems to have been true for a number
of other MIBs thus far.  For example:
- dot3(7) in EtherLike-MIB  (RFC 1643)
- ds0(81) in DS0-MIB  (<draft-ietf-trunkmib-ds0-mib-05.txt>)
- ds0Bundle(82) in DS0BUNDLE-MIB  (<draft-ietf-trunkmib-ds0-mib-05.txt>)
- ds1(18) in DS1-MIB  (RFC 1406, <draft-ietf-trunkmib-ds1-mib-08.txt>)
- ds3(30) in DS3-MIB  (RFC 1407, <draft-ietf-trunkmib-ds3-mib-08.txt>)
- fddi(15) in FDDI-SMT73-MIB  (RFC 1512)
- frameRelayDTE(32) in FRAME-RELAY-DTE-MIB  (RFC 2115)
- frnetservMIB(44) in FRNETSERV-MIB  (RFC 1604)
- lapb(16) in RFC1381-MIB  (RFC 1381)
- miox(38) in MIOX25-MIB  (RFC 1461)
- para(34) in PARALLEL-MIB  (RFC 1660)
- ppp(23) in PPP-LCP-MIB  (RFC 1471)
- rs232(33) in RS-232-MIB  (RFC 1659)
- sip(31) in RFC1304-MIB  (RFC 1304)
- sonetMIB(39) in SONET-MIB  (RFC 1595,
  <draft-ietf-atommib-sonetng-02.txt>)
- x25(5) in RFC1382-MIB  (RFC 1382)

In some cases, the MODULE-IDENTITY has been defined under "mib-2", while
the object hierarchy has remained under "{ transmission X }".  (Often
this happened when upgrading the MIB from SMIv1 to SMIv2.)  For example:
- dot3(7) and etherMIB(35) in EtherLike-MIB  (RFC 1650)
- sip(31) and sipMIB(36) in SIP-MIB  (RFC 1694)

Finally, at least one interface-related MIB seems to have been defined
completely under "mib-2", for unknown reasons.  I am not sure if there
are any others.  For example:
- atmMIB(37) in ATM-MIB  (RFC 1695)

Note that in this last case, the value under "mib-2" (i.e., 37) is the
same as the value that WOULD likely have been used if it had just been
defined under "transmission".  I assume that that was simply a happy
coincidence at the time the numbers were being assigned for that MIB.

Again, I expect that the numbering of "ipoaMIB" as "{ transmission 46 }"
is per plan and is perfectly ok, and that it does not conflict in any way
with the definition of "hssi(46)" in the "IANAifType"; I am just curious
what the numbering plan actually is.  Thanks in advance for shedding
light on this for those of us who are curious about such things.

Regards,
Gary

P.S.  Perhaps now that RFC 2320 has been published, it is appropriate
to repair the comment in the IANAifType-MIB for ipOverAtm(114), which
currently says "IBM ipOverAtm", but which should probably say something
like "Classical IP and ARP over ATM".  (Hint, hint.... :-)

 ______
| ///  |       TM   Gary Hanson                [email-masked]
|   ADC|Kentrox     14375 NW Science Park Dr.  503-641-3321 (FAX)
|______|            Portland, Oregon  97229    800-733-5511 x6333

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Gary Hanson <[email-masked]>
Date: Tue, 14 Apr 1998 13:00:37 -0700 (PDT)

Ken,

Thanks for the explanation.  From what you've written, it sounds like
the numbering policy in these cases involves a collaborative effort
between the RFC editor and the internet-draft editor.  I assume that
the RFC editor represents the IANA and checks that the requested OID
value is neither already assigned nor needed for another purpose.

Although I guess it really doesn't matter, I still don't see how the
value 46 in "{ transmission 46 }" was arrived at, unless it was simply
an unused value that seemed like a good one to dispense next, given
that are were no plans on the IETF horizon to create a standards-track
HSSI-MIB.

However, since one OID value is as good as another, I don't anticipate
any real problem, unless the IETF wants to create a standard HSSI-MIB
at some point in the future.  In that case, the OID value that might
normally have been assigned will simply already have been assigned to
this MIB.  Works for me, too.

Regards,
Gary

On Tue, 14 Apr 1998 [email-masked] wrote:

> Gary,
> Me too.
> The RFC editor sent me a note asking where I thought the MIB should
> be registered. I thought that using { transmission x } was better
> than { mib-2 x } due to the nature of the MIB. Use of the ipOverAtm(114)
> ifType is optional. I would expect to see lots of use of the
> aal5 layer (ifType of 49) as well as a virtual IP layer as the
> attachment point. Therefore, I didn't see the MIB OID having to be
> the same as ipOverAtm(114). To be honest I didn't realize that
> some MIBs even had this relationship! If a mistake was made then
> it was mine for not making a better recommendation. In any case the
> current assignment works for me.
> 
> Ken
>