Subject: [MIB-DOCTORS] our IfTypeReferences project - ifType 5 inconsistencies

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 2 Aug 2006 18:57:03 +0200

Keith and others. Thanks for all the input sofar.

We need consistency and make a decision. 
We found the following (sofar):

  label(value()    where:
  ---------------- --------------------------------
  rfc877x25(5)     http://www.iana.org/assignments/ianaiftype-mib 
  rfc877-x25(5)    RFC1213
  rfc887-x25(5)    RFC1392
  rfc877x25(5)     RFC1573 (the initial IANAifType-MIB)
  x25(5)           RFC1700

I understand that RFC 1700 has been obsoleted. 
So maybe we need/should not worry about that.

It seems that the original label was rfc877-x25. I guess we (IETF IFMIB WG)
changed it to comply with the CLR "no hyphens in a label" ??

In any event, I am inclined to put in our table:
               
    http://www.ops.ietf.org/IfTypeReferences02.html     

(and comments about this new format is welcome too.
 I am using cml2rfc with texttable element, which looks as follows:
  <texttable anchor='table_IfTypeReferences'>
    <ttcol align='left'>label</ttcol>
    <ttcol align='center'>ifType</ttcol>
    <ttcol align='left'>MIB oid</ttcol>
    <ttcol align='center'>Reference</ttcol>
    <ttcol align='center'>MIB module</ttcol>
    <ttcol align='left'>(IANA) comments</ttcol>

      <!--label-->     <c>other</c>
      <!--ifType-->    <c>1</c>
      <!--MIBoid-->    <c>n.a.</c>
      <!--Reference--> <c><xref target='RFC1213'/></c>
      <!--MIBmodule--> <c>n.a.</c>
      <!--comment-->   <c>none of the following</c>

 I find that much easier to maintain than the format I received from
 Dave Thaler... not complaining Dave. Your format seemed impossible
 to maintain manually, but I am sure you have/had nice tools)

The MIB module is (as per RFC1382):
  x25(transmission.5)  http://www.iana.org/assignments/smi-numbers 
          under: Prefix: iso.org.dod.internet.mgmt.mib-2.transmission   

If I understand RFC1382 correctly, then that MIB module is also used
for ddn-x25(4), as per sect 3.3 of RFC1382. 

   3.3.  Structure of MIB

   Instances of the objects defined below represent attributes of an
   X.25 Packet Layer interface.  At present these interfaces are
   identified by an ifType object in the Internet-standard MIB-II [5]
   of:

                 ddn-x25(4), and
                 rfc887-x25(5).

   For these interfaces, the value of the ifSpecific variable in the
   MIB-II [5] has the OBJECT IDENTIFIER value:

                 x25    OBJECT IDENTIFIER ::= { transmission 5 }

Note that also for ddn-x25, we have changed it to ddnX25 in the IANAifType-MIB
since RFC1573! So I am also using the ddnX25 in our table.

Bert

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 3 Aug 2006 09:13:36 +0200

Inline

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]]
> Sent: Wednesday, August 02, 2006 19:27
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: our IfTypeReferences project - ifType 5 inconsistencies
> 
> 
> Ok by me.
> You have two typos (three if one counts "Pls") in the intro text:
> 
>    Thanks to Dave Thaler for providing the first cut. MIB doctors, Pls
>    check for correctness. This should also align with the
>    'ANAifType-MIB. If it does not, then the IANA registry us the
>    authoritative source.
> 

Thanks Keith... fixed (not online yet though). 

> It seems to be that "MIB oid" and "MIB module" are 
> inter-dependent columns and would be better as adjacent columns. 
> 
Makes sense to me. WIll re-arragen. That is exactly one of the
reason why I wanted a (quick) check again before I have all entries
converted in the new format.

> Also, I think "none known" would be more informative than "?" in the
> "MIB module" column for the xxx1822 rows.
> 

Can and will do that (unless I hear objections).

> OK.

So the one thing we can still wonder is:

   should we record errata against the RFCs in error. 
   Not that it matters that much probably, but it does record that
   we have seen these and that there is (consensus, at least in MIB
   doctors land) as to what the correct values are.

Bert
> Keith.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 3 Aug 2006 16:30:47 +0200

Keith wrote:
> It would be beneficial if you have the time to do so. 
> 

Time is always a problem. But I will try.
FOr each errata mesage I will give MIB doctors a few days to
comment on my draft text to RFC-Editor.

So I will not send any for obsoleted or historic RFCs.

  RFC1382 is PS, so I will prepare an errata message
  RFC1700 is historic, so no errata

  RFC1213 is STD and updated by (2011, 2012, 2013).
          I guess we could ask to add that it is also updated
          by RFC1573 (for iftable) and by RFC3418 (for the snmp
          branch)

Maybe we could ask to update the index for some RFCs

OLD:
  1213 Management Information Base for Network Management of
     TCP/IP-based internets:MIB-II. K. McCloghrie, M. Rose. March 1991.
     (Format: TXT=142158 bytes) (Obsoletes RFC1158) (Updated by RFC2011,
     RFC2012, RFC2013) (Also STD0017) (Status: STANDARD)

NEW:
  1213 Management Information Base for Network Management of
     TCP/IP-based internets:MIB-II. K. McCloghrie, M. Rose. March 1991.
     (Format: TXT=142158 bytes) (Obsoletes RFC1158) (Updated by RFC2011,
     RFC2012, RFC2013, rfc1573, rfc3418) (Also STD0017) (Status: STANDARD)

Just thinking aloud here

Bert