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

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

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


Loa Andersson wrote:
> 
> 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
> 
> Stephen Trowbridge wrote:
> 
> >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 <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.
> >>>
> >>>
> >>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
> >>
> >>
> >
> >
> >
> >