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

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

Loa,
(I know it is a joke, but if there weren't some element of truth
to this it would not be so funny).

Let me try to explain why the interface between an individual and
IETF, and an the interaction between another SDO and IETF have to
be different:

Differences on the incoming side:
- The ID brought in by an individual represents his/her individual
opinion.
- A liaison statement from another SDO represents an approved consensus
view from that other organization. I don't so much care whether it is
in ASCII or not, but it does represent a consensus view that cannot be
claimed of the individual ID submission.

Differences on the outgoing side:
- The individual discovers the response to their proposal by participating
in the mailing list discussion, looking at the IETF web site, using the ID
tracker, etc.
- The above methods are not realistic or appropriate for other SDOs to
receive information on what is going on in IETF. It is not realistic to
think that I should get 300 people in my study group to subscribe to
ccamp and mpls and decide for themselves what IETF thinks of something
that was sent over from ITU-T. There is no way in a formal organization
like ITU-T for us to take stuff we found on email discussions or web
sites and consider this as input to a study group meeting. It is not
ITU-Ts place to be watching the email lists and judging for ourselves
what the IETF consensus reaction might be to a particular proposal
(in fact, depending on which emails one pays the most attention to, one
can get some widely varying ideas about what IETF "thinks"). It should
be up to IETF to judge the consensus and to tell ITU-T the result.

Liaison statements are a method that is widely used to communicate between
standards groups. IETF has gone for a long time without employing these.
We have had the rare case where an IESG member takes the initiative to
put a response together, but it has not been standard operating procedure
to:
1) Pay attention to incoming liaisons.
2) Make sure that any request (For Action or For Comment) gets a reply
   (Note that SDOs are not compelled do what was asked of them in an incoming
   liaison statement for Action - but whether or not they do what was asked,
   other SDOs nearly always reply and, if not doing what was asked, they
   explain why not or make a counter-proposal).
3) Generate liaison statements to inform other SDOs about work ongoing in
   IETF that the other SDO should consider when doing their work.
4) Use liaison statements to ask for an "official" position about the
   meaning or intent of standards from other organizations (I recall an
   earlier debate where different IETF participants had different
   understandings of how some T1X1/ITU-T standards were to be interpreted.
   It would have been best to cut that discussion short and just ASK
   T1X1/ITU-T what they meant. You can be sure that T1X1 and ITU-T would
   have responded!)

As the importance of IP protocols increases, and the work of IETF becomes
increasingly intertwined with the technologies and standards that are in
the domain of other SDOs, it seems to me to be ESSENTIAL that IETF begin
to incorporate the sending and receiving of liaison statements as part of
its normal operating procedure. 
Regards,
Steve

Loa Andersson wrote:
> 
> Steve,
> 
> Bala said it was a joke! And it wasn't hard to parse with a bit of humor.
> Actuall quite funny :). I guess I could make a very similar flow chart,
> in trying to discuss with some people around mpls.
> 
> But seriously claiming (you are not joking, are you?) that Balas flow
> chart demonstrates that we intend to give work "externally generated"
> a fast track to the trash I find below the level of this discussion.
> 
> The intention of the change process is to create a way for the (g)mpls
> technology area to recieve and handle new requirements and new ideas, the
> exact opposite of you are claiming.
> 
> In fact every time I send a new  ID (draft-andersson-xxxx-foo-00.txt) seen
> from the IETF and the working groups it is in some sense "external".
> What is that
> makes something that originates from "the other SDOs" so special from a
> technical
> point of view. The change process are focused on guaranteeing that new
> (g)mpls technology ideas are  evaluated based on their technical merits.
> 
> /Loa
> 
> Stephen Trowbridge wrote:
> 
> >Curtis,
> >I have no problem to seperate the liaison process from the internal process.
> >In fact, a good liaison process is needed that would have much broader
> >applicability than (G)MPLS protocols.
> >
> >However, I do disagree that we can go forward on one with out the other.
> >As Bala's flowchart shows, the effect of applying this draft to internally
> >and externally initated work alike is to give the externally initiated
> >work a fast track to the trash. Without the liaison process, this draft
> >seems to make what is already a bad problem with how we deal with input
> >from other SDOs even worse.
> >Regards,
> >Steve
> >
> >Curtis Villamizar wrote:
> >
> >
> >>In message <3E5F8A25.8030201@pi.se>, Loa Andersson writes:
> >>
> >>
> >>>- I don't think it is agood idea to describe the two process in the same
> >>>  document. the chnage-process is for our internal use, the liasion process
> >>>  is for our commuinication with other SDOs
> >>>
> >>>
> >>If we can agree on this, then we can move forward with your document.
> >>
> >>Curtis
> >>
> >>
> >
> >
> >
> >