[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Where to define IANAtunnelType TC



My 2 agorot:

1. I agree with Bert that the TC does not belong to IANAifType-MIB. Actually the change in the model seems to be departing from mandating the modeling of a tunnel as an interface.
2. If this is accepted, Annex A should be the core of a new document defining the IANAtunnelType MIB and TC
3. Paragraph 2 and 3 in the current IANA considerations should be moved in the DESCRIPTION clause of the TC, so that anybody looking in the IANA files can understand how to extend the TC with new values.
4. Paragraph 4 in the IANA considerations is puzzling me somehow. Does this refer to existing pre-standard implementations of the tunnel MIB, or is there another MIB module that recommends using the sixToFour(215) value for IANAifType. Who and when was this defined?

Regards,

Dan



> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org]On Behalf Of Wijnen, Bert (Bert)
> Sent: 01 September, 2004 2:57 PM
> 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
> 
>