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

From: John Drake <[email-masked]>
Date: Fri, 28 Feb 2003 06:40:59 -0800

Gert,

I'm sorry, I was teasing.  I was saying that if the IETF didn't like certain
features of the G.709 transport plane, following Stephen's argument, it
shouldn't feel constrained about changing them.  

I wasn't talking about your draft, which I think is a very good piece of
work.

Thanks,

John

> -----Original Message-----
> From: Gert Grammel [mailto:[email-masked]]
> Sent: Friday, February 28, 2003 4:10 AM
> To: John Drake
> Cc: 'Kireeti Kompella'; Stephen Trowbridge; [email-masked];
> [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Hi John,
> 
> I am not sure if I've got your point here about G.709 and the 
> way it is linked
> to the liason stuff. ITU-T defined G.709 as another circuit 
> technology to
> transport bits from A to B. It is similar to SDH/SONET and 
> falls into the ASON
> scope. Applying GMPLS on G.709 is straight forward and I am 
> not aware of any
> specific open issues here.
> In SDH/SONET some of the involved guys were trying to include 
> non-standard
> SDH/SONET features in the ietf-draft, meaning those not 
> explicitly mentioned in
> G.707. This caused of course a lot of friction. In contrast 
> to that, the G.709
> authors team is committed to remove everything from
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g70
> 9-03.txt which is
> not covered by G.709. In this sense it has the potential to 
> become a boiler
> plate for tight collaboration.
> So why do you think this work should be depreciated in CCAMP?
> 
> Regards
> 
> Gert
> 
> 
> 
> 
> 
> 
> John Drake wrote:
> 
> > Kireeti,
> >
> > There's always been a few things that I didn't like about 
> G.709, so maybe we
> > can just go ahead and deprecate them in CCAMP.  Then we can 
> figure this
> > liason stuff and tell the ITU about it.
> >
> > Thanks,
> >
> > John
> >
> > > -----Original Message-----
> > > From: Kireeti Kompella [mailto:[email-masked]]
> > > Sent: Thursday, February 27, 2003 3:04 PM
> > > To: Stephen Trowbridge
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > >
> > > Hi Steve,
> > >
> > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote:
> > >
> > > > If they decide not to be involved and the other SDO 
> goes ahead with
> > > > developing their own solution, they don't need to bless the
> > > extension,
> > > > or even like it, but they do need to accept it.
> > >
> > > Going back to the examples that Deborah brought up: what 
> if other SDOs
> > > produced variants of SDH -- would you say that the ITU "do need to
> > > accept it"?
> > >
> > > Kireeti.
> > >
> 
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]
> 
>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 28 Feb 2003 17:11:17 +0100

All,

I might be stupid, but I actually see some commonality forming on this
thread, though there is much smoke

I think we agree on the following:

1. and most important - we want a productive, trustful and comprehensive
   co-operatiom between IETF and other SDOs
2. the process that describes how this co-operation is handled needs to
   be described
3. we need to have a known, reliable and open (g)mpls technology area
   process for how extend and change the (g)mpls protocols
4. this process also needs to be descirbed
5. that the (g)mpls working groups in the IETF (or maybe the IETF in
   general) [sometimes, often, regulary, a few times] have mismanaged
   incoming liasions from other SDOs

Note 1:
I know that some voices has been raised saying that "the general process
for c-operation between IETF and other SDOs" are not a subject matter for
for the mpls-list. I tend to agree, however one of our ADs made it
appropriate as long as we discuss the coupling between the to processes
above.

We disagree on:

a. whether the two processes needs to go into the same document or not
b. whether documents generated in one process could go seemlessly
   into the other process

I hope we agree on this:

6. that the relationship between IETF and other SDOs are by nature a
   relationship    between equal parties
7. that each organization are entitled to define it own processes,
   methodology and document types

Some personal reflections

- Kireeti and Bert has recognized that here has been less than satifactory
  performanse by the IETF in handling liasions in the past, we will not be
  any wiser if that aregument is repeated
- 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
  (I understand that from the other side this might look pretty much the
   same, but if the only problem is that of how some type of info sent
   from one organisation is received by another, let us solve that problem)
  It must be fairly easy for the sending organization say to the IETF 
"Please,
  handle the content of this liasion as an Internet Draft!" Based on that
  we can publish is as an ID, and include it in our work.
  But if there is written in stone that a liasion is a liasion is a liasion,
  then we will require that other SDOs send us IDs.
- in our internal processes we need documents ofer which we have change 
control
  and therefore it is unsatifactory to use non-IETF documents

Would be good if we could agree on points 1-6 and on a and b, would be far
easier to continue the disucssion.

/Loa

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 28 Feb 2003 11:50:10 -0500

>   is for our commuinication with other SDOs

If we can agree on this, then we can move forward with your document.

Curtis

---

From: Stephen Trowbridge <[email-masked]>
Date: Fri, 28 Feb 2003 10:15:40 -0700

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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 28 Feb 2003 12:42:24 -0500

> > If we can agree on this, then we can move forward with your document.

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.

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.  :-)

Curtis

---

From: George Newsome <[email-masked]>
Date: Fri, 28 Feb 2003 14:31:17 -0500

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.

> 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.

George

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 28 Feb 2003 14:58:14 -0500

> 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.

> any further discussion on mechanisms for collaboration, and one less ID 

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.

Curtis

---

From: George Swallow <[email-masked]>
Date: Fri, 28 Feb 2003 12:03:02 -0500

> If we can agree on this, then we can move forward with your document.

I think they need to be separate because the liaison draft should
apply across the board to IETF / ITU interactions and this document
applies only to (G)MPLS.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Loa Andersson <[email-masked]>
Date: Fri, 28 Feb 2003 23:16:23 +0100

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