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

["Varma, Eve L (Eve)" <evarma@lucent.com>]

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

Just putting in my two cents.  I'd like to support aspects of the liaison process being included in the draft.  Given the close coupling between the

change and liaison processes, and the issues that triggered generation of the draft, I believe we should bite the bullet and work to establish a cohesive process now.

It will be well worth the effort.  In my view, not expending the time now will result in far more time spent later.

 

I'd also like to express support for the proposed revisions provided by Steve Trowbridge,  as I believe they increase the value of the draft by adding necessary clarifications and promoting a cooperative spirit to the entire endeavor.

 

Eve Varma

 

 

-----Original Message-----
From: Malcolm Betts [mailto:betts01@nortelnetworks.com]
Sent: Thursday, February 27, 2003 8:11 AM
To: 'Loa Andersson'
Cc: Stephen Trowbridge; Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

 

Loa, the from the outside looking in the liaison process and the change process are closely coupled.  The liaison process is described in ITU-T Recommendation A.4 and A.5 and in RFC 3356. 

The coupling occurs because the ITU uses the agreed liaison process to communicate requests to modify IETF protocols based on requirements agreed by the members of the Study Group (that originated the liaison).  The change process being proposed requires that this official request from a SDO is converted into an individuals ID.  The level of agreement in the SDO is therefore obscured, this process appears to be in conflict with RFC 3356.  The problem is particularly acute when the requirements are to enable (or enhance) the management of a non IP network to support a non IP client.  If my understanding of the draft is correct such requests would be rejected by the IETF.

It is clearly beneficial to the industry if the basic IETF protocols can be extended to address such applications.  The IETF plays a key role in ensuring that the integrity of the base protocols is not compromised.

Malcolm Betts

Phone: +1 613 763 7860 (ESN 393)
FAX:   +1 613 763 6608 (ESN 393)
email: betts01@nortelnetworks.com

 

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Thursday, February 27, 2003 7:33 AM
To: Kireeti Kompella
Cc: Stephen Trowbridge; ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
<snip>

I think I've clearly pointed out the limited scope of the change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation with other SDOs.

/Loa

<snip>