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

[Curtis Villamizar <curtis@fictitious.org>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <200302271822.h1RIMn56013326@sj-msg-core-1.cisco.com>, Eric Rosen wr
ites:
> 
> It seems to me that Loa's  document simply describes how the IETF works.  As
> such, I'm not sure it is even necessary. 
> 
> True, many people have  noticed that the IETF is free to  ignore the work of
> other standard organizations.  True, the  fact that a particular proposal is
> made by another  standards organization does not even  give the proposal any
> special weight in the IETF.
> 
> I think these are  good things, and the IETF should not  make any changes in
> this respect.  Hence I don't think  Loa's draft (if it needs to exist) needs
> to change.
> 
> Certainly  the  fact  that  some  position  is  articulated  in  a  "liaison
> statement"  should not  give  it any  special  weight.  The  fact that  some
> position is supported  by "a threshold number of  vendors and SPs" shouldn't
> give it any special weight either.  


Eric,

I completely agree with you but would like to make one clarification.

The "number of vendors and SPs" should not be given any weight at all
in toward the rough consensus criteria.  However, implementation by
vendors and deployment by SPs should be given strong consideration
regarding whether there exists any "running code" and "independent
interoperable implementations".

The IETF shouldn't care who you think you are or who you work for if
you don't show up with running code.  This eliminates committee
contributions such as study groups with a spec and no code or
deployment (and sometimes no valid requirement).

The number of internet-drafts that were not advanced due to not having
concensus on a requirements statement is quite large.  Few rejected on
that grounds resurfaced later when a need became evident and extremely
few resurfaced and were later implemented.  Diffserv-TE is about the
only set of drafts to get pushed back, resurface, and get implemented
and this was not a liason work.

Curtis