Subject: [ifmib] IANAifType-MIB issue

From: "Dave Thaler" <[email-masked]>
Date: Thu, 4 Dec 2003 15:05:21 -0800

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 

_______________________________________________
ifmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ifmib

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Dec 2003 13:33:47 +0100

On Thu, Dec 04, 2003 at 03:05:21PM -0800, Dave Thaler wrote:

[...]
 
> is in one place rather that two separate places with 

I think the root of the problem is that the IANA maintained interface
type TC is a rather uncontrolled place. Creating another uncontrolled
place next to it (regardless how close it is) is not going to fix this
nor will it make sure that the new TC gets only reasonable assignments.

I think there should be an Expert Review (see RFC 2434) before these
TCs can be updated and perhaps an expert can also be found to go
through the existing assignments and mark those assignments as 
deprecated which are known to be problematic.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 5 Dec 2003 07:57:10 -0800 (PST)

On Thu, 4 Dec 2003, Dave Thaler wrote:
DT> A proposal in the appendix of draft-thaler-inet-tunnel-mib-00.txt
DT> is to add the IANAtunnelType TC *into the IANAifType-MIB itself*
DT> alongside the IANAifType TC.  The rationale behind this is that
DT> it makes it easy to find both (you can't claim you didn't know
DT> tunnelType existed when you apply for an ifType) and means a
DT> paragraph of guidelines for when to ask for ifType vs tunnelType
DT> is in one place rather that two separate places with
DT> cross-references, etc.
DT> 
DT> I'd like to get feedback on this proposal from IANA and/or the
DT> IF-MIB WG.  This is the only open issue on the document, and
DT> I expect the document to be able to go to last call after this
DT> question is resolved.

I have looked at this proposal and I think it is a good idea. I do
have a few small procedural suggestions, however:

- Rework Section 5, IANA Considerations, to state that the document
introduces a new IANA-maintained TC to be added to the
IANAifType-MIB and that the initial version of the TC is in Appendix
A.  Also state explicitly that the policy for assigning new values
is first-come-first-serve, as defined in RFC 2434, just as is it is
for new ifType values.

- Include only the TC itself in Appendix A, and remove the RFC
Editor note that the section will be removed upon publication.  You
may recall that there was extensive discussion on the mreview list
some time ago about this subject and that there was an IESG ruling
that the initial version of an IANA-maintained MIB module is to to
be published in a non-normative section of the document that defines
a new namespace;  see Section 3.7 of the MIB review guidelines draft
<draft-ietf-ops-mib-review-guidelines-02.txt> for more details.
Even though you won't be creating a new MIB module I think that
including the first version of the new TC in the published RFC
would be in keeping with the spirit of this ruling.

On Fri, 5 Dec 2003, Juergen Schoenwaelder wrote:
JS> I think the root of the problem is that the IANA maintained
JS> interface type TC is a rather uncontrolled place. Creating
JS> another uncontrolled place next to it (regardless how close it
JS> is) is not going to fix this nor will it make sure that the new
JS> TC gets only reasonable assignments.
JS> 
JS> I think there should be an Expert Review (see RFC 2434) before
JS> these TCs can be updated and perhaps an expert can also be found
JS> to go through the existing assignments and mark those
JS> assignments as deprecated which are known to be problematic.

While that may be a reasonable idea, changing from the grandfathered
first-come-first-serve assignment rules for IANAifType TC values is
a separate project from updating the tunnel MIB and placing tunnel
types under IANA maintenance.  It would require an explicit update
to the IANA considerations for the IANAifType-MIB, which should go
in a separate document with its own Last Call.  And I'm not sure
that it's really an urgent priority.  Anything that's done for an
IETF MIB module gets expert review anyway (that's what MIB doctors
are for), and the damage done by unwis allocation requests from
outsiders is pretty limited, I think.

Mike