RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

[Mark.Jones@mail.sprint.com]

I don't understand how the development of a "major extension" by another 
group would necessarily indicate a "complete breakdown in relationship." 
 If that were the case, then the "veto" of the ITU-T based requirements 
and models have already shown we are in that condition now.  The 
continued discussion between IETF and ITU-T now proves that is not true.

The extensions by other groups only indicates differences in 
applications, models, scope, etc.  The development of "major extensions" 
by outside SDOs will continue unless the IETF decides to accept the 
applications defined in other organizations as serious work items.  As 
long as the IETF scope is focused on supporting and enabling IP, there 
will be broader applications that require those extensions that the IETF 
participants will not be willing to address.

I hope the IETF can find a way to retain ownership of the base protocols 
like GMPLS, while recognizing the fact that other applications will 
require extensions by other groups.  Those extensions should not 
infringe on the IETF application of the protocols as long as the 
applications defined by the IETF are clearly stated.  Only if the 
outside groups decide to address the exact same application as the IETF 
would I concede that we have a "breakdown in relationship."

To work this out, there needs to be a way for the IETF to respond to 
queries by outside groups about whether the IETF will or will not 
address the precise application of concern in another SDO.  Simply not 
agreeing to that application or not acknowledging the requirements in 
not a valid response.  The IETF then will retain control over which 
applications it will work on and which ones it will pass on.  I don't 
know if this is a liaison process or discussion of an ID, but some 
mechanism is needed for other organizations to hear whether they need to 
do their own extensions or whether they can expect the IETF to address 
them.

Mark Loyd Jones
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139
 

-----Original Message-----
From: Shahram.Davari [mailto:Shahram_Davari@pmc-sierra.com]
Sent: Thursday, March 06, 2003 9:10 AM
To: curtis
Cc: zinin; Mark.Jones; ccamp; mpls
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt


>> 1) Is the decision on how to deal with extension requests, an IESG
>> decision or an IETF consensus is required?
>
>If it is published as an informational recommendation by the IESG,
>then no.  The IESG does have veto power over internet-drafts that are
>on the standards track, therefore it might be worth paying attention
>to their recommendations.

Using their veto power against IETF community's consensus, seems "a 
complete breakdown of relationship" between IETF community and IESG.

>
>btw- I should also point out that Scott Bradner does not make this
>stuff up without talking to the other members of the IESG.

I know. but IESG != IETF


>
>> 2) No one can stop other SDOs from extending any IETF protocol
>
>True.
>
>> 3) The draft says:
>> 
>>    "No individual, vendor, SDO or forum should be able 
>create what is viewed
>>    to be a major extension to an IETF protocol on its own and
>>    legitimately be able to claim that implementations that 
>implement the
>>    extension are compliant to the IETF specification."
>> 
>> So if the other SDOs don't claim IETF compliance, rather 
>they claim their
>> respective organizations compliance, there should not be any 
>problem. And if 
>> they mess up nobody would blame IETF for that.
>
>This would represent a complete breakdown of relationships.  I'm not
>making any value judgement, just an observation.


Why? are you saying that if an SDO wants to define a brand new protocol 
(let's say MPLSv2),
but to reuse some parts of an existing IETF protocol, then they 
shouldn't do it because
IETF will get mad at them?

-Shahram


>
>> -Shahram
>
>Curtis
>
>
>> >-----Original Message-----
>> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
>> >Sent: Wednesday, March 05, 2003 5:34 PM
>> >To: Shahram Davari
>> >Cc: 'curtis@fictitious.org'; Alex Zinin; 
>'Mark.Jones@mail.sprint.com';
>> >ccamp@ops.ietf.org; mpls@UU.NET
>> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >
>> >
>> >
>> >In message 
>> ><4B6D09F3B826D411A67300D0B706EFDEB03D65@nt-exch-yow.pmc-sierra.bc.ca
>> >>, Shahram Davari writes:
>> >> Is IESG=Curtis?
>> >> 
>> >> -Shahram
>> >
>> >
>> >That looks like a cheap shot of some kind.
>> >
>> >IESG == draft-iesg-vendor-extensions-00.txt
>> >
>> >  3.  Recommendation
>> >
>> >   The following principles are the main guiding principles 
>concerning
>> >   extensions to IETF protocol:
>> >
>> >    o All major extensions to IETF protocols should be done 
>with direct
>> >      involvement of the IETF.
>> >
>> >    o The decision on whether an extension is major or 
>minor should be
>> >      done with the direct involvement of the IETF.
>> >
>> >Those words are from the IESG draft.  They are not my words.
>> >
>> >I thought that was obvious enough in my prior reply, but apparently
>> >not.
>> >
>> >Curtis
>> >
>> >
>> >> >-----Original Message-----
>> >> >From: Curtis Villamizar [mailto:curtis@fictitious.org]
>> >> >Sent: Wednesday, March 05, 2003 4:53 PM
>> >> >To: Alex Zinin
>> >> >Cc: Shahram Davari; 'Mark.Jones@mail.sprint.com'; 
>> >ccamp@ops.ietf.org;
>> >> >mpls@UU.NET
>> >> >Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
>> >> >
>> >> >
>> >> >
>> >> >In message <18057706577.20030305113734@psg.com>, Alex 
>Zinin writes:
>> >> >> Wednesday, March 5, 2003, 11:12:10 AM, Shahram Davari wrote:
>> >> >> [...]
>> >> >> > It might be a good idea to require that all IETF 
>> >protocols support
>> >> >> > vendor-specific extensions, so that they could be used by 
>> >> >other SDOs
>> >> >> > and for experiments.
>> >> >> 
>> >> >> Ouch... draft-iesg-vendor-extensions-00.txt
>> >> >> 
>> >> >> Alex
>> >> >
>> >> >
>> >> >Looks like the IESG doesn't agree with Shahram on this.
>> >> >
>> >> >Curtis
>> >> >
>> >> 
>> >
>> 
>