Re: IANAifType-MIB issue

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