[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
I think we have agreement to do a separate document on the liaison process? (as I'm writing, I see a mail just now from Scott saying this). Loa, not sure if you were volunteering the g-chng proc authors? They are probably the most appropriate. If you need support (either visible/ghosts), Steve (ok, Steve?) can help from the ITU perspective, I can help from the T1X1 side.
Steve, I agree for SDOs, the key problem is the lack of a liaison process. Regardless, for IETF, a change process is needed. The GMPLS work is just going to rfc status and there will be both individual and SDO requests for additions/changes. For the liaison process, I think we need to distinguish the communication protocol (administrative=receive/distribution/transmit) from the processing (administrative and technical) of the liaison request. Both need to be clarified.
Considering we agree to have a separate document for a liaison process, and applying a constructive filter to the mail exchange, Lyndon's mail and my mail have direct comments on the draft, any others?
As I noted previously, to distinguish this process from the liaison process, should either remove external standards bodies from the text or clarify "individuals of external standards bodies".
Agree with Lyndon, "dustbin" should be defined for non-ietf aware, i.e. a note describing the option as non-standards track=informational or experimental rfc.
As Lyndon says, resources in all the standards groups are extremely limited, it's in the industry and our companies interests to collaborate. Let's use this week for specific comments on the draft.
From: Stephen Trowbridge [mailto:email@example.com]
Sent: Monday, March 03, 2003 9:56 AM
To: George Swallow
Cc: firstname.lastname@example.org; Loa Andersson; mpls@UU.NET; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
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
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*
- 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.
George Swallow wrote:
> > In message <3E5F8A25.email@example.com>, 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 Swallow Cisco Systems (978) 497-8143
> 250 Apollo Drive
> Chelmsford, Ma 01824