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

From: Stephen Trowbridge <[email-masked]>
Date: Mon, 03 Mar 2003 07:56:28 -0700

All,
Lets try to zero in on what the problem really is.

I think that liaison handling (or the lack thereof) is not just a
problem. It is THE problem. Does anybody really believe that the
reason this draft exists in the first place is that there are a
bunch of individuals going wild trying to change or extend the
(G)MPLS protocols?

What seems to have generated most of the arguments is the handling
(or bungling) of the communications process (or lack of process)
with other SDOs. This is the process we need to fix.
Dealing with requests from individuals to extend or change the
protocols might be good to have a process for, but realistically,
has any individual made such a request yet? Why is this important?

Now, if we can agree that liaisons are THE problem,
there are two ways we can go:
- We can start work on a general purpose liaison process to be
applied across the whole of IETF (revival of one of the POIS*
working groups?).
- We could try to develop a pilot process for sub-IP (which is
where we seem to have a lot of the problems), and take what we
learn from its implementation to feed into a process that would
apply to the whole of IETF.

While I can appreciate that a general problem should usually have
a general solution, there is some appeal to taking the second
approach because (1) we could probably get something underway
faster; and (2) sub-IP seems to be where the lack of such a
process is causing us the most pain.
Regards,
Steve

George Swallow wrote:
> 
> > In message <[email-masked]>, 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.
> 
> 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: Scott Bradner <[email-masked]>
Date: Mon, 3 Mar 2003 10:51:48 -0500 (EST)

I think that we (the IETF) do need to work on the "liaison problem"
but I do not think that a perfect liaison process would reduce the
requirement for the IETF to be sure that the extension process for
IETF protocols is clearly documented.

We have been trying to be clear in new protoocls by including 
an IANA Considerations section that says how to extend the technology.  But
many IETF protocols come from a time before we started doing that and
I think it is vital that the process gets defined for those protocols
(one example is RFC 2780, another is RFC 3427)

I expect that we will have to have a quite formal dicussion
on the "liaison problem" and think it needs to be added to the
problems list (and have been told that it will be noted in the
next version of the ID)

Scot

---

From: Loa Andersson <[email-masked]>
Date: Mon, 03 Mar 2003 18:06:12 +0100

Steve,

you are right that the liasion process are a problem - if anyone thinks 
it will
do any good (AD's nod or shake your heads) I'm of course willing to help 
sort that
out. And it might be that we can make Sub-IP a pilot (again nods or 
shakes from
AD's). My tentative view is that this should be done as part of the 
problem statement
work.

BUT - it is far from the only problem, in fact the very draft that we 
ougth to be
discussing here was written with the liasion process very low on the 
horizion, it
was definitely not triggered by getting liasion carried requirments form 
other SDOs,
but it was triggered because, we seen more and more solutions coming in for
undocumented or poorly understood problems. We have an increasing 
concern over the
(g)mpls coherence and architecture in relation to these "solutions".

For the moment I'm not aware of any mpls related liasions hanging 
un-answered, there
are a set of them for ccamp, but Kireeti and Bert, have acknowledged 
that, and I
sincerly hope they won't try to use the change process to answer those 
liasions,
the process was not designed to do that.

There is something in this discussion that makes me think that there is 
a drive for
trying to take the origin of an requirement and make that an criterium 
when evaluating
the requirment. Kind of giving a group requirment precedence over an 
individula
requirment. I sincerly object to this, since I think ti is the technical 
merit
that is the evaluation point.

/Loa

---

From: Stephen Trowbridge <[email-masked]>
Date: Mon, 03 Mar 2003 10:51:02 -0700

Loa,
Can you give me some examples of things you consider to be solutions
being proposed (by individuals) for undocumented or poorly understood
problems? I admit to following mpls only peripherally, but in ccamp
it seems like the bulk of proposals (if not ALL of the proposals)
originate from attempts to solve problems raised by other SDOs.
If I could see examples of this sort for mpls, I perhaps could
understand better why this kind of change control procedure would
be necessary.

Here is the sense in which the evaluation of the requirement must take
into consideration the source:
Evaluation of a requirement by an IETF WG (or any other body to which
a requirement is proposed) is a subjective process. The IETF WG will
interpret the requirement in the context of their charter and the kinds
of networks and technologies they are most familiar with.

Another SDO may come up with requirements related to THEIR charter and
the kinds of networks and technologies they are familiar with. These
requirements may be exceedingly critical within the application domain
for the other SDO, but may seem irrelevant or unimportant for the
application domain of the IETF WG.

So an IETF WG which is trying to maintain sanity over a protocol that
is applied by different SDOs to different application spaces DOES need
to consider requirements from different SDOs in a different way from
internal requirements. When evaluating an internal requirement, people
should understand why that requirement is important in the context of
the charter of the IETF WG. When evaluating a requirement, for example,
from ITU-T, the question should be, not why this is an important
requirement within the context of the WG charter, but to understand
why (or accept that) it is an important requirement for ITU-T and
their application space.

Regards,
Steve

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 3 Mar 2003 14:02:21 -0800 (PST)

Hi Steve,

> Lets try to zero in on what the problem really is.

Good idea.

> problem. It is THE problem.

I disagree.  I think there are two problems, and both are important.

> Does anybody really believe that the

Yes, actually, I do.  Maybe not "going wild", but the necessary
review is not always done to make sure the changes are needed and
in concert with the architecture of the protocols.

> with other SDOs. This is the process we need to fix.

No argument here.

> has any individual made such a request yet? Why is this important?

Every ID is a request from an individual.  Every ID is important
(until proven otherwise).

> Now, if we can agree that liaisons are THE problem,

We agree to disagree on that :-)

> apply to the whole of IETF.

We (you and I) can do little (except write IDs :-)).  The ADs should
give us guidance on how to proceed.  And, from my reading, the
guidance is that the liaison problem should be solved holistically
(not piecemeal in Sub-IP) and in *some other WG*, like the problem
statement WG.

Kireeti.