From ifmib-admin@ietf.org Thu Dec 4 16:55:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18811; Thu, 4 Dec 2003 16:55:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS1SD-0002Co-00; Thu, 04 Dec 2003 16:56:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS1SD-0002Cj-00; Thu, 04 Dec 2003 16:56:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1S5-0002tn-1O; Thu, 04 Dec 2003 16:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS1Ro-0002tN-MS for ifmib@optimus.ietf.org; Thu, 04 Dec 2003 16:55:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18789 for ; Thu, 4 Dec 2003 16:55:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS1Rm-0002C0-00 for ifmib@ietf.org; Thu, 04 Dec 2003 16:55:42 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AS1Rl-0002BX-00 for ifmib@ietf.org; Thu, 04 Dec 2003 16:55:42 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 4 Dec 2003 13:55:01 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 04 Dec 2003 13:55:12 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Dec 2003 13:53:13 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Dec 2003 13:56:16 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 4 Dec 2003 13:55:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Dec 2003 13:55:05 -0800 Message-ID: Thread-Topic: FW: I-D ACTION:draft-thaler-inet-tunnel-mib-00.txt thread-index: AcOt9ZZ+vJNsLzHfT/WmEF1t5E5ZAwMutF4g From: "Dave Thaler" To: , X-OriginalArrivalTime: 04 Dec 2003 21:55:14.0640 (UTC) FILETIME=[4C2B7500:01C3BAB1] Content-Transfer-Encoding: quoted-printable Subject: [ifmib] Re: FW: I-D ACTION:draft-thaler-inet-tunnel-mib-00.txt Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-BeenThere: ifmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Interfaces MIB working group mailing list. List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Pekka Savola writes: > Thanks Dave. >=20 > Two very high-level comments. >=20 > An obvious oversight (or intentional one :-) is that I see an IANA > registry being created, but no guidance on how new values should be added > to it (IETF Consensus, Standards Action, FCFS, etc.) Actually the proposal is that the guidance be identical to that for ifType values (anything different results in prolonging the incentive problem that exists today). I believe ifType is currently first-come-first-serve. I'll put a summary of this issue shortly in a subsequent email. > Also, it was not clear which WG you intend to run this through officially. > I'm assuming ifmib. (Just trying to figure out what will be the role of > v6ops WG in this process..) IFMIB is concluded so that's not an official option (although I still want any feedback from people on this list :) As a result, in Minneapolis, the IPv6 WG accepted the document as a WG document, just like for all the other "core" IP MIBs which don't have an official home and which are just being updated to be version-agnostic. -Dave =20 _______________________________________________ ifmib mailing list ifmib@ietf.org https://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Thu Dec 4 18:06:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23630; Thu, 4 Dec 2003 18:06:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS2Ym-00048D-00; Thu, 04 Dec 2003 18:07:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS2Ym-00048A-00; Thu, 04 Dec 2003 18:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2Yn-0006Tw-8m; Thu, 04 Dec 2003 18:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2Y7-0006PE-5Q for ifmib@optimus.ietf.org; Thu, 04 Dec 2003 18:06:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23501 for ; Thu, 4 Dec 2003 18:06:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS2Y4-000479-00 for ifmib@ietf.org; Thu, 04 Dec 2003 18:06:16 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AS2Y3-00046A-00 for ifmib@ietf.org; Thu, 04 Dec 2003 18:06:15 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 4 Dec 2003 15:05:07 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 4 Dec 2003 15:05:33 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 04 Dec 2003 15:05:27 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Dec 2003 15:05:14 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 4 Dec 2003 15:05:17 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 4 Dec 2003 15:05:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Dec 2003 15:05:21 -0800 Message-ID: Thread-Topic: IANAifType-MIB issue thread-index: AcOt9ZZ+vJNsLzHfT/WmEF1t5E5ZAwMu7wUw From: "Dave Thaler" To: , Cc: "Wijnen, Bert \(Bert\)" X-OriginalArrivalTime: 04 Dec 2003 23:05:31.0087 (UTC) FILETIME=[1D5E35F0:01C3BABB] Content-Transfer-Encoding: quoted-printable Subject: [ifmib] IANAifType-MIB issue Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-BeenThere: ifmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Interfaces MIB working group mailing list. List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable 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 =3D 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 =3D tunnel(131) and then use different tunnel subtypes. As a result, there have been at least one, probably multiple=20 cases where IANA has (correctly, as there was no alternative) assigned ifType values to new tunnel types, and hence some=20 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=20 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=20 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*=20 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=20 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=20 _______________________________________________ ifmib mailing list ifmib@ietf.org https://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Fri Dec 5 07:34:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03010; Fri, 5 Dec 2003 07:34:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASFAo-0000RK-00; Fri, 05 Dec 2003 07:35:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASFAo-0000RH-00; Fri, 05 Dec 2003 07:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASFAk-0001xM-Ox; Fri, 05 Dec 2003 07:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASFAA-0001wa-FT for ifmib@optimus.ietf.org; Fri, 05 Dec 2003 07:34:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03006 for ; Fri, 5 Dec 2003 07:34:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASFA9-0000R9-00 for ifmib@ietf.org; Fri, 05 Dec 2003 07:34:25 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ASFA9-0000Q8-00 for ifmib@ietf.org; Fri, 05 Dec 2003 07:34:25 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 8608C7CB95; Fri, 5 Dec 2003 13:33:51 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.18]) by merkur.iu-bremen.de (Postfix) with ESMTP id 2CEC27CB77; Fri, 5 Dec 2003 13:33:48 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 98E0681C8; Fri, 5 Dec 2003 13:33:47 +0100 (CET) Date: Fri, 5 Dec 2003 13:33:47 +0100 From: Juergen Schoenwaelder To: Dave Thaler Cc: ifmib@ietf.org, Iana@iana.org, "Wijnen, Bert (Bert)" Subject: Re: [ifmib] IANAifType-MIB issue Message-ID: <20031205123347.GB1007@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Dave Thaler , ifmib@ietf.org, Iana@iana.org, "Wijnen, Bert (Bert)" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-BeenThere: ifmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Interfaces MIB working group mailing list. List-Post: List-Help: List-Subscribe: , On Thu, Dec 04, 2003 at 03:05:21PM -0800, Dave Thaler wrote: [...] > 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 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 P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ ifmib mailing list ifmib@ietf.org https://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Fri Dec 5 10:57:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10671; Fri, 5 Dec 2003 10:57:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASILC-00039d-00; Fri, 05 Dec 2003 10:58:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASILB-00039a-00; Fri, 05 Dec 2003 10:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASILA-0000MG-OD; Fri, 05 Dec 2003 10:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASIKR-0000Kn-Na for ifmib@optimus.ietf.org; Fri, 05 Dec 2003 10:57:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10643 for ; Fri, 5 Dec 2003 10:56:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASIKP-00038p-00 for ifmib@ietf.org; Fri, 05 Dec 2003 10:57:13 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASIKO-00038g-00 for ifmib@ietf.org; Fri, 05 Dec 2003 10:57:12 -0500 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id hB5FvBO22022; Fri, 5 Dec 2003 07:57:11 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 5 Dec 2003 07:57:10 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "IF-MIB (E-mail)" cc: "IANA (E-mail)" , "Mreview (E-mail)" Subject: Re: [ifmib] IANAifType-MIB issue In-Reply-To: <20031205123347.GB1007@iu-bremen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-BeenThere: ifmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Interfaces MIB working group mailing list. List-Post: List-Help: List-Subscribe: , 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 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 _______________________________________________ ifmib mailing list ifmib@ietf.org https://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Sat Dec 6 10:24:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11173; Sat, 6 Dec 2003 10:24:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASeIo-0001pc-00; Sat, 06 Dec 2003 10:25:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASeIo-0001pV-00; Sat, 06 Dec 2003 10:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASeIn-0004RH-EG; Sat, 06 Dec 2003 10:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASeIb-0004Qg-RV for ifmib@optimus.ietf.org; Sat, 06 Dec 2003 10:24:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11144 for ; Sat, 6 Dec 2003 10:24:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASeIZ-0001ot-00 for ifmib@ietf.org; Sat, 06 Dec 2003 10:24:47 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ASeIY-0001nz-00 for ifmib@ietf.org; Sat, 06 Dec 2003 10:24:46 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB6FOCg12957 for ; Sat, 6 Dec 2003 09:24:13 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Sat, 6 Dec 2003 16:24:11 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155031D6462@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: j.schoenwaelder@iu-bremen.de, Dave Thaler Cc: ifmib@ietf.org, Iana@iana.org, "Wijnen, Bert (Bert)" Subject: RE: [ifmib] IANAifType-MIB issue Date: Sat, 6 Dec 2003 16:24:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-BeenThere: ifmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Interfaces MIB working group mailing list. List-Post: List-Help: List-Subscribe: , > > 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 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. > IANA already (often, but maybe not always) asks Keith McKloghrie and myself for review of not-so-clear cases. Did/do you see trouble in recent assignments? I do not know what has happened several years back. And further: are you volunteering as additional expert? Bert > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ ifmib mailing list ifmib@ietf.org https://www1.ietf.org/mailman/listinfo/ifmib From ifmib-admin@ietf.org Mon Dec 8 04:04:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01654; Mon, 8 Dec 2003 04:04:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATHKE-0007F0-00; Mon, 08 Dec 2003 04:05:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATHKE-0007Ev-00; Mon, 08 Dec 2003 04:05:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATHK9-0004gX-2h; Mon, 08 Dec 2003 04:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATHJc-0004eC-8b for ifmib@optimus.ietf.org; Mon, 08 Dec 2003 04:04:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01647 for ; Mon, 8 Dec 2003 04:04:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATHJZ-0007En-00 for ifmib@ietf.org; Mon, 08 Dec 2003 04:04:25 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ATHJY-0007Dd-00 for ifmib@ietf.org; Mon, 08 Dec 2003 04:04:24 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 1B4F481D77; Mon, 8 Dec 2003 10:03:16 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.18]) by merkur.iu-bremen.de (Postfix) with ESMTP id 315E57C5CE; Mon, 8 Dec 2003 10:03:15 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 4FB5181C8; Mon, 8 Dec 2003 10:03:14 +0100 (CET) Date: Mon, 8 Dec 2003 10:03:13 +0100 From: Juergen Schoenwaelder To: "Wijnen, Bert (Bert)" Cc: Dave Thaler , ifmib@ietf.org, Iana@iana.org Subject: Re: [ifmib] IANAifType-MIB issue Message-ID: <20031208090313.GA1316@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Wijnen, Bert (Bert)" , Dave Thaler , ifmib@ietf.org, Iana@iana.org References: <7D5D48D2CAA3D84C813F5B154F43B155031D6462@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155031D6462@nl0006exch001u.nl.lucent.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: ifmib-admin@ietf.org Errors-To: ifmib-admin@ietf.org X-BeenThere: ifmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Interfaces MIB working group mailing list. List-Post: List-Help: List-Subscribe: , On Sat, Dec 06, 2003 at 04:24:10PM +0100, Wijnen, Bert (Bert) wrote: > IANA already (often, but maybe not always) asks Keith McKloghrie and myself > for review of not-so-clear cases. Did/do you see trouble in recent > assignments? Frankly, I did not check the latest assignements. But it is good to know that there is some form of expert review (and I trust you and Keith to probably have a very good overview of the many interface types we have ;-). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ ifmib mailing list ifmib@ietf.org https://www1.ietf.org/mailman/listinfo/ifmib