The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

Deborah,

the non-mentioning of the liasions are quite intentionally, since we 
thought
that the liasion process is quite well described, understood and used. 
Later
communications have brought to our attention that this assumption is not 
entirely
true.

However, my take is that the liasions and the change-process address two
orthogonal issues. The liasion addreses how information is exchanged 
between
IETF and other organisations, this could be anything from general info 
on latest
development to specifics that one of the organisations sees as useful 
for the other
to be aware of.

It is below my current horizon if the liasion process needs to be 
defined in more
detail and in a draft ov its own, I guess I* in general and Harald in 
particular
could have a view on this.

The change-process on the other hand addresses a specific issue, how 
propsed new
work for the (g)mpls technology is accepted or rejected. This is 
something I feel
more comfortable to discuss than the IETF realtionships to other 
organisations.

In my mind there is no overlap between those two processes, the change 
process
in no way changes or affects the liasions, and the liasions is not the 
format to
bring new work into the IETF (in this case the (g)mpls) working groups. 
IETF working
groups work with Internet Drafts, either individual drafts or working 
group drafts.

I'm not entirely clear on if something that leaves one organisation as a 
liasion
could be received by the IETF as an Internet Draft, all other things 
equal. However
once it reaches the IETF, it will become an ID and published as such. In 
the other
direction I think it is clear if IETF or one of its working groups want to
communicate with another organisation, we will have to go through the 
liasion
process, that involves some approval on the iesg level. We do this out 
of respect
for how those organisations has told us they want this type of 
communication to
be handled and what format to use. What we do in the change process, is 
basically that
we give the same level of information on what is our process to 
accept/reject new
work and specifies input format to that process, declare that as long as 
we get
the input in that format we will in a timely fashion act on this input, 
and also
ask others to respect how our processes work.

I also agree on that if we can clarify and make more precise on how 
decisions are
taken, documented and communicated, though we need to remember that 
everything that
is a decision in this meaning will be taken by the iesg. Again I'm under 
the
impression that there is a quite well understood and used way of taking, 
documenting
and communicating iesg decision. You might be right that when it comes 
to wg chairs
and ADs and the responsibility to communicate (iesg) decision relating 
to the
working group in general and the people the made the proposal in 
particular, the
change-process could very well state something.

Hope this clarifies at least some of the issues!



/Loa


Brungard, Deborah A, ALABS wrote:

>Loa,
>(I included ccamp as I was not sure everyone is on the mpls list)
>
>The draft does not include any reference to liaisons (inputs from other standards groups). Will there be a separate process for liaisons or this draft will be extended to include? It would be useful (especially for other standards groups) to have clarification on how liaisons are input to a WG, generation of responses, and process required to coordinate work/initiate work within a working group in relation to other standards groups.
>
>On section 2.2.2 problem statement review, and in other steps where decisions are taken, it would help to clarify if say that the decision (e.g., 'no action') plus the basis for the decision be posted to the Area/WG mailing list within a specified time period.
>
>Thanks,
>Deborah
>
>-----Original Message-----
>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>Sent: Friday, February 14, 2003 6:44 AM
>Subject: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: MPLS and GMPLS Change Process
>	Author(s)	: L. Andersson
>	Filename	: draft-andersson-mpls-g-chng-proc-00.txt
>	Pages		: 11
>	Date		: 2003-2-13
>	
>This memo describes the process through which individuals, working
>groups and external standards bodies can influence the development of
>MPLS and GMPLS standards.  With respect to standardization, this
>process means that (G)MPLS extensions and changes can be done through
>the IETF only, the body that created the (G)MPLS technology.  The
>IETF will not publish a (G)MPLS technology extension RFC outside of
>the processes described here.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to 
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>	"get draft-andersson-mpls-g-chng-proc-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	mailserv@ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>
>  
>