RE: draft-iesg-vendor-extensions-00.txt
"Thomas D. Nadeau" <tnadeau@cisco.com> Mon, 10 March 2003 14:58 UTC
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 10 Mar 2003 06:59:34 -0800
Message-Id: <5.2.0.9.2.20030310095746.095791b8@bucket.cisco.com>
Date: Mon, 10 Mar 2003 09:58:58 -0500
To: Shahram Davari <Shahram_Davari@pmc-sierra.com>, ccamp@ops.ietf.org, mpls@UU.NET
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: draft-iesg-vendor-extensions-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
>Thanks, I am happy to hear that my proposal is in fact in-line with >current IETF standardization process. However, my proposal is about allowing >other SDOs to develop extensions to IETF protocols, even if IETF does >not agree to those extension, while the iesg draft prohibits other SDOs from >developing any extension to IETF protocols without IETF's approval. I personally happen to agree with the IESG on the last point. --Tom >-Shahram > > > > >-----Original Message----- > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >Sent: Friday, March 07, 2003 12:43 PM > >To: Shahram Davari; ccamp@ops.ietf.org; mpls@UU.NET > >Subject: Re: draft-iesg-vendor-extensions-00.txt > > > > > > > > I don't see how your proposal differs from the current > >IETF standards process. How could extensions created by other > >SDOs be considered IETF compliant without being passed through the > >process within the IETF? If they are passed through the processes and > >are eventually approved as standards, then they are called > >IETF compliant. > >Where exactly do you see this as being broken and requiring > >additional red > >tape? > > > > --Tom > > > > > >>Hi All, > >> > >>I would like to make an alternative proposal to what is > >proposed in this > >>draft. > >>I think that IETF should not prevent other SDOs from > >developing extensions > >>(minor or major), > >>to IETF protocols, as long as they don't call those > >extensions being IETF > >>compliant. > >>I think IETF could recommend that the other SDOs present > >their protocol > >>extensions > >>to IETF (in the form of a draft). The IETF community then has > >3 choices: > >>1) IETF agrees with the requirements and nature of the > >extensions and find > >>them useful. In that case IETF could engage in technical > >discussions with > >>the other SDO and reach to a mutually agreeable draft, which > >could then be > >>advanced to Proposed Standard. > >> > >>2) IETF agrees with the requirement, but does not agree with > >the proposed > >>extension, and prefers other solutions/extensions that it thinks meet > >>those requirements. In that case IETF could develop its solution and > >>present it to the requesting SDO. If that SDO is satisfied with > >>IETF's solution, then fine, otherwise nobody can prevent them from > >>developing their own extension. If that happens then there > >would be two > >>solutions for the same requirements > >>and we should let the Market decide which solution/extension > >do they prefer. > >> > >>3) IETF does not agree with the requirement for such > >extensions at all. In > >>that case, the > >>other SDO should be free to developed their own extension, > >provided they > >>don't call those extensions to be IETF compliant. > >> > >> > >> > >>Thanks, > >>-Shahram > > > >
- RE: draft-iesg-vendor-extensions-00.txt Thomas D. Nadeau
- RE: draft-iesg-vendor-extensions-00.txt Shahram Davari
- Re: draft-iesg-vendor-extensions-00.txt Thomas D. Nadeau
- RE: draft-iesg-vendor-extensions-00.txt Shahram Davari
- Re: draft-iesg-vendor-extensions-00.txt Alex Zinin
- draft-iesg-vendor-extensions-00.txt Shahram Davari