FW: IANAifType-MIB issue

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I'd like feedback from the MIB doctors on this as well.
So, just in case you are not subscribed to if-mib list,
here it is.

Thanks,
Bert 

-----Original Message-----
From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
Sent: vrijdag 5 december 2003 0:05
To: ifmib@ietf.org; Iana@iana.org
Cc: Wijnen, Bert (Bert)
Subject: IANAifType-MIB issue



Current state of affairs:
1) the IANAifType-MIB contains the IANAifType TC which has
(at least from my understanding) a first-come-first-serve
assignment policy.
2) the TUNNEL-MIB (RFC 2667) uses ifType = tunnel(131)
and defines a tunnel subtype enum (which was not a TC)
to "point" to specific tunnel types in the same way that
ifType points to specific interface types.  The intent was
that all tunnels over IP use ifType = tunnel(131) and
then use different tunnel subtypes.

As a result, there have been at least one, probably multiple 
cases where IANA has (correctly, as there was no alternative)
assigned ifType values to new tunnel types, and hence some 
of the benefit of the Tunnel MIB is lost.

The Tunnel MIB is now being updated, and we have the opportunity
to fix this, or at least avoid new occurrences of assigning
an ifType where a tunnel subtype is more appropriate.

Looking at the ifType values in question:

1: sixToFour (215), -- 6to4 interface

   Previously the Tunnel MIB only mentioned point-to-point
   tunnels, whereas this is a Non-Broadcast Multi-Access (NBMA)
   tunnel.  In the updated tunnel MIB, the DESCRIPTION clauses
   are updated to clarify how such tunnels are represented.

2: gtp (216), -- GTP (GPRS Tunneling Protocol)

   I'm not that familiar with GTP but it appears to be a normal
   point-to-point tunnel over UDP/IP consistent with the
   Tunnel MIB in RFC 2667.

3: mplsTunnel (150),   -- MPLS Tunnel Virtual Interface

   This one was assigned to draft-ietf-mpls-te-mib-14.txt. It's
   not clear to me whether this is actually a tunnel over IP
   though, so I'm not sure whether it's another example or not.

In summary, the problem was that the tunnel subtypes were not
an IANA registry, and so the natural incentive for folks
creating new tunnel types is to get an ifType value instead
of a tunnel subtype value, since the latter required rev'ing
the RFC.

To fix this, the Tunnel MIB update creates a TC and delegates 
it to IANA.  This is straightforward.

However, to completely fix the incentive problem, it needs to be
exactly as easy/difficult to get a tunnel subtype as it is to 
get an ifType.  Simply creating another IANA registry won't
necessarily cause folks to notice it, and/or request one
instead of an ifType where a tunnel subtype is more appropriate.

A proposal in the appendix of draft-thaler-inet-tunnel-mib-00.txt
is to add the IANAtunnelType TC *into the IANAifType-MIB itself* 
alongside the IANAifType TC.  The rationale behind this is that
it makes it easy to find both (you can't claim you didn't know
tunnelType existed when you apply for an ifType) and means a
paragraph of guidelines for when to ask for ifType vs tunnelType
is in one place rather that two separate places with 
cross-references, etc.

I'd like to get feedback on this proposal from IANA and/or the
IF-MIB WG.  This is the only open issue on the document, and
I expect the document to be able to go to last call after this
question is resolved.

-Dave