RE: Where to define IANAtunnelType TC

["Dave Thaler" <dthaler@windows.microsoft.com>]

This question was discussed last year on this list and on the IF-MIB
list (which created the IANAifType-MIB in the first place).

See http://ops.ietf.org/lists/mreview/mreview.2003/msg00632.html
which is the approach which is now taken by the tunnel mib.

(Bert, you were on this thread too:
http://ops.ietf.org/lists/mreview/mreview.2003/msg00631.html)

I can't remember who all commented on the if-mib list (the mailing
list archive seems to be down at the moment).

-Dave

> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]
On
> Behalf Of Wijnen, Bert (Bert)
> Sent: Wednesday, September 01, 2004 4:57 AM
> To: Mreview (E-mail)
> Subject: Where to define IANAtunnelType TC
> 
> Dave Thaler has proposed (and IETF Last Call did not generate
> comment or objections) to put it in the IANAifType-MIB as
> documented in draft-ietf-ipv6-inet-tunnel-mib-02.txt.
> 
> I do not want to just have the discussion between Dave Thaler and
> myself, so I would appreciate if some MIB doctors can chime in.
> 
> Here is my original questions to Dave (prefixed with > ) and
> my follow up questions when I saw no changes in the document that
> went through IETF Last Call
> 
> > - Is it wise to put IANAtunnelType TC in IANAifType-MIB?
> >   Or would a different module be better.
> 
> I see no change, neither do I see an answer as to why this belongs
> in IANAifType-MIB
> 
> >   In any event, the DESCRIPTION clause of that TC should explain
> >   the rules for IANA on when/how to assign new values.
> 
> I see no text for that yet, do I?
> 
> >   It also seems to me that we may want to update the DESCRIPTION
> >   clause of the ianaIfType TC to say something about tunnels and
> >   that they better have tunnel(131) as ifType and a listing
> >   in the new TC.
> >
> I see no proposed text for that either.
> 
> I also would like MIB doctors to comment on these IANA considerations
> which are in Dave's I-D:
> 
> The policy for assigning new IANAtunnelType values is First Come
> First Served, as defined in [RFC2434], just as it is for new
> IANAifTypes values.  The assignment policy for IANAtunnelType
> values should always be identical to the policy for assigning
> IANAifType values.
> 
> New types of tunnels over IPv4 or IPv6 should not be assigned
> IANAifType values.  Instead, they should be assigned
> IANAtunnelType values and hence reuse the interface type
> tunnel(131).  (Note this restriction does not apply to "tunnels"
> which are not over IPv4 or IPv6.)
> 
> Previously tunnel types which were not point-to-point tunnels were
> problematic in that they could not be properly expressed in the
> tunnel MIB, and hence were assigned IANAifType values.  This
> document now corrects this problem, and as a result, IANA should
> deprecate the sixToFour(215) IANAifType value in favor of the
> sixToFour(11) IANAtunnelType value.
> 
> Bert