The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Feb> msg00190



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: Curtis Villamizar <curtis@fictitious.org>
  • Date: Fri, 28 Feb 2003 14:58:14 -0500
  • cc: curtis@fictitious.org, Stephen Trowbridge <sjtrowbridge@lucent.com>, Loa Andersson <loa@pi.se>, mpls@UU.NET


In message <3E5FB905.1000001@ieee.org>, George Newsome writes:
> Curtis Villamizar wrote:
> 
> > Steve,
> > 
> > Loa's draft documents IETF process that has pretty much been put into
> > place under the guidance of the IESG to keep the level of junk down to
> > a minimum and insure that extensions both address real needs and their
> > deployment is feasible.  The sooner participants in outside SDOs
> > recognize this, the better for them.
> 
> So in the spirit of reducing the amount of junk to IESG, it seems that 
> the IETF already understand their process, so this ID can be dropped.

Can we stick to constructive comments.

Determining that there are legitimate requirements is a good thing and
so Loa's draft should go forward.  As Deborah pointed out the mention
of liason should be removed to decouple the two issues.

> > Earlier you stated, that if an outside SDO specified an extension and
> > you expect the IETF to simply accept that.  It may turn out that the
> > IETF has documented their process in rfc2026 and clarified it here and
> > you simply have to accept that.  :-)
> 
> The IETF doesn't collaborate with other SDO's, so there is no need for 
> any further discussion on mechanisms for collaboration, and one less ID 
> is needed.

This draft wasn't intended to address liason.  It doesn't but it
serves a useful purpose.  Its clear we don't have full consensus on
SDO liason relationships to the IETF.

Those who wish to have liasons be given special consideration in the
IETF have brought up the orthogonal topic of liasons.  This document
is about having agreed upon requirements before considering protocol
extensions.

> George

Curtis