Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
From: "Ong, Lyndon" <[email-masked]>
To: [email-masked]
Date: Fri, 28 Feb 2003 16:14:39 -0800

Hi Folks,

I support the request to stick to constructive comments.

Of course that means avoiding statements like "The
ITU has stepped out of bounds (again).  They deserve to be ignored."
(Last I heard, SDH/OTN networks were within bounds of ITU ;o)

Or "dogmatic statements of connection-oriented  religion" (these
are, for gmpls, connection-oriented networks we're talking about ;0)

Seriously, though, I do have some comments on the draft:

-- the figure shows the only path outside of the IETF process to
be a dustbin.  Hopefully that's not intentional, although a lot
of folks on the list probably believe this ;o)

-- there's some text mixed up in 2.2.1 regarding which mailing list
should be used.

-- we should incorporate Deborah's suggestion for 2.2.2 about having
the decision posted to the mailing list within a specified period  (the
posting of a decision could apply to liaisons, and might have helped
avoid the confusion with the ITU liaison)

-- in 2.2.4, the paragraph after item (2) seems a little premature - 
the recommendation by the rewg presumably must be approved by IESG/IAB
before a decision is made.

-- there is a bit of a loophole in that the problem could be accepted
and farmed off to a WG but there's no check to see if anything is ever
done, and items could easily fall through a crack given the large 
numbers of work items usually in CCAMP and MPLS.  There could be a 
procedure to revisit the decision in case no progress is being made
within some specified timeframe.

-- in general, I hope people keep in mind that the scope of interest
and the resources available in IETF are limited, and should not become a
bottleneck - if work can be or is already being done in other bodies and 
there is a process for IETF to review this work and identify potential
problems or simpler/more general ways to do the desired function,
this should be viewed as a generally positive thing.

Cheers,

Lyndon

Envelope-to: [email-masked]
Delivery-date: Fri, 28 Feb 2003 12:57:40 -0800
Date: Fri, 28 Feb 2003 15:56:59 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

yipe - go off-line for a long plane flight and kablooe the world 
explodes

You may rest assured that the intention of the ID (and the one that came
out today about change control for RSVP) is positive.

The basic concept is the same as RFC 3427 does for SIP - be sure that the
IETF is "in the loop" on extensions to IETF protocols.  Note that these two
IDs are 1st drafts and are meant to be discussed (that part seems to have
worked :-) )

We have had recent experience with the OIF UNI and ITU ASON documents that
it is easy to get into sort of a mess (and we are not accusing anyone
specific here). There were many reasons.  Including neglected liaison
statements from ITU and documents from ITU folk.  Clearly the IETF needs to
figure out a better way to deal with such messages (This was a topic at the
ITU-T TSAG (their sort of IESG) meeting this past week in geneva.)

So in order to try to regularize the change process with RSVP and (G)MPLS
the SUB-IP ADs with a few WG chairs prepared this document. The idea is
that we define the process so that it is clear how and when various steps
need to be taken and by whom. The doc is far from complete we suspect and
so comments (certainly ones with recommended wording) will be very welcome.
As noted above, these are first drafts and we expect that there will be
quite a few changes before these get adopted.

We also need to evaluate the issues w.r.t. to liaison statements. We think
we have seen quite a set of opinions on the usefulness and function of
liaison statements.  These opinions need to be evaluated and revised text
needs to be put in these documents to deal with them, but maybe this should
be done as a comprehensive IETF review of how we deal with liaison
statements.

It would be good to tone down the "discussion" a bit. We do not think that
making accusations etc helps the discussion.  The idea was to try and
prevent that from happening in the future. 
  
So now that you all have been able to blow of some steam, can you please
start to post constructive text proposals as how to do things in these
documents and relative to how the IETF deals with working with other SDOs
that want to use and extend IETF protocols.  

(BTW - it is not a bad thing that multiple SDOs want to make use of the
same protocols, it seems that it should be considered a good thing and we
should work out ways that using existing protocols or working together on
ways to extend current protocols is encouraged rather than making it more
likely that competing protocols doing the same function get developed.)

Thanks,
Bert and Scott

Delivery-date: Fri, 28 Feb 2003 12:20:52 -0800
Date: Fri, 28 Feb 2003 21:18:25 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: [email-masked]
Cc: Heiles Juergen <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-kawakami-mpls-lsp-vlan-00.txt

Delivery-date: Fri, 28 Feb 2003 10:21:06 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-08.txt
Date: Fri, 28 Feb 2003 13:16:36 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multiprotocol Label Switching Extensions  for SONET and SDH Control
	Author(s)	: E. Mannie, D. Papadimitriou
	Filename	: draft-ietf-ccamp-gmpls-sonet-sdh-08.txt
	Pages		: 21
	Date		: 2003-2-28
	
This document is a companion to the Generalized Multiprotocol
Label Switching (GMPLS) signaling. It defines the Synchronous
Optical Network (SONET)/Synchronous Digital Hierarchy (SDH)
technology specific information needed when using GMPLS signaling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.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-ietf-ccamp-gmpls-sonet-sdh-08.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-sonet-sdh-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 28 Feb 2003 10:08:17 -0800
Date: Fri, 28 Feb 2003 14:25:04 +0100
From: Genadi Velev <[email-masked]>
Subject: RE: draft-kawakami-mpls-lsp-vlan-00.txt
To: Heiles Juergen <[email-masked]>
Cc: [email-masked], [email-masked]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi Juergen,

thanks for the feedback! This was (and seems to be still) a hot topic. The
decision where to present the draft has been already a subject of
discussions with the chairmen of MPLS, PWE3 and PPVPN WGs. The reason to let
this draft for submission in the MPLS WG was that the basic intention is to
propose a new LDP extension ("VLAN label TLV") and MPLS WG is in charge of
the LDP protocol.

It's true that the transport plane in our proposal is based on VLAN-aware
Ethernet switches. Compared to the GMPLS classification of interfaces
(RFC3471), VLAN tag switching belongs (I'd say so) to the Packet-Switch
Capable (PSC) interfaces, and thus, extensions regarding these interfaces
should be a subject of the MPLS WG.

This is my personal opinion. However, since I'm not a long-experienced
person in the IETF's MPLS related work, I'd like to hear also another
opinions on this issue.

regards,
Genadi

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Heiles
> Juergen
> Sent: Friday, February 28, 2003 12:17 PM
> To: [email-masked]'; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: AW: draft-kawakami-mpls-lsp-vlan-00.txt
>
>
> Genadi,
>
> the draft proposes to use the MPLS control plane protocols for a
> different transport plane (Ethernet VLAN).
> This is excatly what GMPLS is about. So I think it would be
> better to have the ID and dicussion in ccamp under the GMPLS work.
>
> Regards
>
> Juergen
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Genadi Velev [mailto:[email-masked]]
> > Gesendet: Donnerstag, 27. Februar 2003 17:53
> > An: [email-masked]
> > Cc: [email-masked]
> > Betreff: draft-kawakami-mpls-lsp-vlan-00.txt
> >
> >
> > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> > [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> >
> > Hi all,
> >
> > A new draft was published today (please see below).
> >
> > Any feedback and comments are welcome, especially from those
> > of you who are
> > dealing with packet transport over wide area Ethernet networks.
> >
> > thanks,
> > Genadi
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > > [email-masked]
> > > Sent: Thursday, February 27, 2003 1:44 PM
> > > To: IETF-Announce:
> > > Cc: [email-masked]
> > > Subject: I-D ACTION:draft-kawakami-mpls-lsp-vlan-00.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > >
> > >
> > > 	Title		: Method to Setup LSP using VLAN Tag Switching
> > > 	Author(s)	: T. Kawakami et al.
> > > 	Filename	: draft-kawakami-mpls-lsp-vlan-00.txt
> > > 	Pages		: 15
> > > 	Date		: 2003-2-26
> > >
> > > This document describes a method to setup a Layer 2 tunnel over
> > > networks based on Ethernet technology. For this purpose,
> > the ports of
> > > an Ethernet switch are configured to forward VLAN
> > tag-labeled packets
> > > incoming from a certain port to another unambiguous port by using
> > > VLAN tag information. The Ethernet switches themselves are a part of
> > > the Label Switching Routers (LSRs), which distribute the VLAN tags
> > > using Label Distribution Protocol (LDP). To enable LDP to
> > fulfil this
> > > function, an LDP extension is proposed. The introduced method
> > > simplifies the transport of Ethernet frames over wide area Ethernet
> > > networks.
> > >
> > > A URL for this Internet-Draft is:
> > >
> http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-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-kawakami-mpls-lsp-vlan-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:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-kawakami-mpls-lsp-vlan-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.
> >

Delivery-date: Fri, 28 Feb 2003 09:58:22 -0800
From: Bala Rajagopalan <[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Thu, 27 Feb 2003 22:57:56 -0500

Just ran into this ID. The flow chart, as usual,
was too complicated for me to comprehend, to I
ran it through the decoder software that IESG 
provides to unscramble its policy statements
(see http://www.ietf.org/iesg/policy_faq/demystify.exe).
The flow chart was then rendered human-readable
as follows:

	MPLS and GMPLS Change Process 
	-----------------------------

        +-------------------------+ 
        |   Receive New ID        | 
        +-------------------------+
                   |
                   | 
                   V
       +-------------------------------------+              
       | Briefly wonder about the resilience |         
       | of the MPLS/GMPLS bandwagon.        |                         
       | Start review.                       |
       +-------------------------------------+             
                  |  
                  |  
                  V
       +-----------------------------------+ 
       | Does the draft contain the term   |  Yes 
       | "ASON"?                           |-------> TRASH 
       +-----------------------------------+
                  |   
                  | No
                  V
        +----------------------------------+ 
        | Does the draft contain the term  |   Yes
        | "UNI"?                           |--------> Incinerate
        +----------------------------------+                    
 	           |
	           | No 
	           V
        +-------------------------------+   Yes, I-NNI 
        |   How about "NNI?"            |-----+----> TRASH 
        +-------------------------------+     |
                  |                           | E-NNI
                  | No                        +-----> Shred 
	           V
        +-------------------------------+ 
        | Does the draft mention Call   |   Yes
        | vs Connection control?        |-------> Send a sample
        +-------------------------------+         of draft to CDC,
                  |                               incinerate rest
                  | No
                  V
        +-------------------------------+ 
        | Does the draft have the term  |  Yes
        | "G.xyz." in the title?        |---------> TRASH
        +-------------------------------+  
                  |		         
                  | No
                  V
        +-------------------------------+ 
        | Draft has progressed too far. |
        | Send to Curtis for review.    |
        +-------------------------------+
                  |
                  | 
                  V
             |            |
             |    TRASH   | 
             +------------+  

Seems a bit draconian and no wonder, people are anxious 
about the process and expect the worst.  Still, I believe 
this will help in limiting the generation of useless drafts 
and protocol extensions to
WGs within the IETF and prevent outside groups from doing the same. 

Regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Pl.
Ocean Port, NJ 07757
USA
Ph: +1-732-923-4237
Email: [email-masked]

Delivery-date: Fri, 28 Feb 2003 09:47:44 -0800
Date: Fri, 28 Feb 2003 12:46:51 -0500
From: Scott W Brim <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-04.txt
Mail-Followup-To: Scott W Brim <[email-masked]>, [email-masked]

On Fri, Feb 28, 2003 12:40:10PM -0500, Thomas D. Nadeau allegedly wrote:
> 
>         The weblink below does not work. I only see version -03.

The web site is currently behind the flow of announcements.  Give it a
minute.

Delivery-date: Fri, 28 Feb 2003 09:40:43 -0800
Date: Fri, 28 Feb 2003 12:40:10 -0500
To: [email-masked], IETF-Announce:;
From: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-04.txt
Cc: [email-masked]

         The weblink below does not work. I only see version -03.

         --Tom

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Common Control and Measurement Plane 
>Working Group of the IETF.
>
>         Title           : Generalized Multi-Protocol Label Switching 
> (GMPLS) Architecture
>         Author(s)       : E. Mannie
>         Filename        : draft-ietf-ccamp-gmpls-architecture-04.txt
>         Pages           : 57
>         Date            : 2003-2-28
>
>Future data and transmission networks will consist of elements such
>as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs),
>photonic cross-connects (PXCs), optical cross-connects (OXCs), etc
>that will use Generalized MPLS (GMPLS) to dynamically provision
>resources and to provide network survivability using protection and
>restoration techniques.This document describes the architecture of GMPLS. 
>GMPLS extends
>MPLS to encompass time-division (e.g. SDH/SONET, PDH, G.709),
>wavelength (lambdas), and spatial switching (e.g. incoming port or
>fiber to outgoing port or fiber). The main focus of GMPLS is on the
>control plane of these various layers since each of them can use
>physically diverse data or forwarding planes. The intention is to
>cover both the signaling and the routing part of that control plane.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.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-ietf-ccamp-gmpls-architecture-04.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:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.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.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt>

Delivery-date: Fri, 28 Feb 2003 09:35:47 -0800
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Fri, 28 Feb 2003 12:35:25 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Stephen Trowbridge" <[email-masked]>, <[email-masked]>
Cc: "Loa Andersson" <[email-masked]>, <[email-masked]>, <[email-masked]>

Was the concern by saying "external standards bodies", it was =
interpreted as liaisons (as this is the only formal way for T1/ITU to =
communicate), which implies submission of an "individual draft", review, =
etc.? So as not to confuse "standards bodies" with liaison =
communication, how about in the draft changing this to "participants of =
external standards bodies"? Or perhaps best is to just remove. And let =
the liaison process address, with links to this document.

Deborah

-----Original Message-----
From: Stephen Trowbridge [mailto:[email-masked]]
Sent: Friday, February 28, 2003 12:16 PM
To: [email-masked]
Cc: Loa Andersson; [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Curtis,
I have no problem to seperate the liaison process from the internal =
process.
In fact, a good liaison process is needed that would have much broader
applicability than (G)MPLS protocols.

However, I do disagree that we can go forward on one with out the other.
As Bala's flowchart shows, the effect of applying this draft to =
internally
and externally initated work alike is to give the externally initiated
work a fast track to the trash. Without the liaison process, this draft
seems to make what is already a bad problem with how we deal with input
from other SDOs even worse.
Regards,
Steve

Curtis Villamizar wrote:
>=20
> 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
>=20
> If we can agree on this, then we can move forward with your document.
>=20
> Curtis

Delivery-date: Fri, 28 Feb 2003 09:26:31 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-04.txt
Date: Fri, 28 Feb 2003 12:21:50 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multi-Protocol Label Switching (GMPLS) Architecture
	Author(s)	: E. Mannie
	Filename	: draft-ietf-ccamp-gmpls-architecture-04.txt
	Pages		: 57
	Date		: 2003-2-28
	
Future data and transmission networks will consist of elements such 
as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), 
photonic cross-connects (PXCs), optical cross-connects (OXCs), etc 
that will use Generalized MPLS (GMPLS) to dynamically provision 
resources and to provide network survivability using protection and 
restoration techniques.This document describes the architecture of GMPLS. GMPLS extends
MPLS to encompass time-division (e.g. SDH/SONET, PDH, G.709),
wavelength (lambdas), and spatial switching (e.g. incoming port or
fiber to outgoing port or fiber). The main focus of GMPLS is on the
control plane of these various layers since each of them can use
physically diverse data or forwarding planes. The intention is to
cover both the signaling and the routing part of that control plane.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.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-ietf-ccamp-gmpls-architecture-04.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-architecture-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 28 Feb 2003 09:04:44 -0800
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Loa Andersson'" <[email-masked]>, [email-masked], "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Fri, 28 Feb 2003 12:03:25 -0500

Hi,

Very helpful email.  I concur with points 1-6.  Re points (a) and
(b), perhaps the best approach would be to first generate the
material itself.  Discussion of its subsequent subdivision would
be far easier, if there were actual content to work with.

Eve

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Friday, February 28, 2003 11:11 AM
To: [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

All,

I might be stupid, but I actually see some commonality forming on this
thread, though there is much smoke

I think we agree on the following:

1. and most important - we want a productive, trustful and comprehensive
   co-operatiom between IETF and other SDOs
2. the process that describes how this co-operation is handled needs to
   be described
3. we need to have a known, reliable and open (g)mpls technology area
   process for how extend and change the (g)mpls protocols
4. this process also needs to be descirbed
5. that the (g)mpls working groups in the IETF (or maybe the IETF in
   general) [sometimes, often, regulary, a few times] have mismanaged
   incoming liasions from other SDOs

Note 1:
I know that some voices has been raised saying that "the general process
for c-operation between IETF and other SDOs" are not a subject matter for
for the mpls-list. I tend to agree, however one of our ADs made it
appropriate as long as we discuss the coupling between the to processes
above.

We disagree on:

a. whether the two processes needs to go into the same document or not
b. whether documents generated in one process could go seemlessly
   into the other process

I hope we agree on this:

6. that the relationship between IETF and other SDOs are by nature a
   relationship    between equal parties
7. that each organization are entitled to define it own processes,
   methodology and document types

Some personal reflections

- Kireeti and Bert has recognized that here has been less than satifactory
  performanse by the IETF in handling liasions in the past, we will not be
  any wiser if that aregument is repeated
- 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
  (I understand that from the other side this might look pretty much the
   same, but if the only problem is that of how some type of info sent
   from one organisation is received by another, let us solve that problem)
  It must be fairly easy for the sending organization say to the IETF 
"Please,
  handle the content of this liasion as an Internet Draft!" Based on that
  we can publish is as an ID, and include it in our work.
  But if there is written in stone that a liasion is a liasion is a liasion,
  then we will require that other SDOs send us IDs.
- in our internal processes we need documents ofer which we have change 
control
  and therefore it is unsatifactory to use non-IETF documents

Would be good if we could agree on points 1-6 and on a and b, would be far
easier to continue the disucssion.

/Loa

Delivery-date: Fri, 28 Feb 2003 08:51:11 -0800
From: Bala Rajagopalan <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: Loa Andersson <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Fri, 28 Feb 2003 11:46:25 -0500

Curtis:

First, thanks for your patient response.
Needless to say, a bit of exaggeration is
necessary for humor (I hope there was some
humor in this).

I wasn't really following the thread on G.709,
so this was not the issue. There are a number
of G.xxxx documents related to ASON that use
IETF protocols and this is what I was referring
to. 

Now, I don't think that all solutions developed
outside of IETF (using IETF protocols) are clean.
However, I do think that so far, there has not
been an adequate effort in IETF to understand
the problem formulations coming from outside.
This is the crux of my message.

In this regard, yes, I do believe that you have
been prominent in rejecting the entire notion
of the UNI. I personally don't have an addiction
to UNI (or any of the G.xxxx stuff), except that 
some number of service providers
(the potential customers of the technology) wanted
this and an effort was made to deliver the features
they wanted. Is there a better way of providing
the same UNI functionality using GMPLS protocols? This
is what one would like to hear from IETF, rather than
a dismissal of the whole concept. Correct me if
I'm wrong, but the present Andersson draft, IMO, 
doesn't address this problem. 

Clearly, I won't place any bets on
the success of UNI in the market place (what
market?). Neither will I place any bets on GMPLS 
at this point in time.

Thank you.

Bala

Bala Rajagopalan
Tellium, Inc.
2 Crescent Pl.
Ocean Port, NJ 07757
USA
Ph: +1-732-923-4237
Email: [email-masked]

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Friday, February 28, 2003 11:07 AM
> To: Bala Rajagopalan
> Cc: Loa Andersson; [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> 
> 
> 
> In message 
> <[email-masked]>, Bala R
> ajagopalan writes:
> > Just ran into this ID. The flow chart, as usual,
> > was too complicated for me to comprehend, to I
> > ran it through the decoder software that IESG 
> > provides to unscramble its policy statements
> > (see http://www.ietf.org/iesg/policy_faq/demystify.exe).
> > The flow chart was then rendered human-readable
> > as follows:
> 
> 
> AFAIK - When IESG members run the compiler they don't produce exe
> files.  :-)
> 
> 
> > 	MPLS and GMPLS Change Process 
> > 	-----------------------------
> > 
> >         +-------------------------+ 
> >         |   Receive New ID        | 
> >         +-------------------------+
> >                    |
> >                    | 
> >                    V
> >        +-------------------------------------+              
> >        | Briefly wonder about the resilience |         
> >        | of the MPLS/GMPLS bandwagon.        |              
>            
> >        | Start review.                       |
> >        +-------------------------------------+             
> >                   |  
> >                   |  
> >                   V
> >        +-----------------------------------+ 
> >        | Does the draft contain the term   |  Yes 
> >        | "ASON"?                           |-------> TRASH 
> >        +-----------------------------------+
> >                   |   
> >                   | No
> >                   V
> >         +----------------------------------+ 
> >         | Does the draft contain the term  |   Yes
> >         | "UNI"?                           |--------> Incinerate
> >         +----------------------------------+                    
> >  	           |
> > 	           | No 
> > 	           V
> >         +-------------------------------+   Yes, I-NNI 
> >         |   How about "NNI?"            |-----+----> TRASH 
> >         +-------------------------------+     |
> >                   |                           | E-NNI
> >                   | No                        +-----> Shred 
> > 	           V
> 
> 
> Not bad.  I think you're OK up to here.
> 
> 
> >         +-------------------------------+ 
> >         | Does the draft mention Call   |   Yes
> >         | vs Connection control?        |-------> Send a sample
> >         +-------------------------------+         of draft to CDC,
> >                   |                               incinerate rest
> >                   | No
> >                   V
> 
> 
> I think that either "call control" or "connection control" warents a
> trip to the dumpster.
> 
> 
> >         +-------------------------------+ 
> >         | Does the draft have the term  |  Yes
> >         | "G.xyz." in the title?        |---------> TRASH
> >         +-------------------------------+  
> >                   |		         
> >                   | No
> >                   V
> 
> 
> Not true.  Examples:
> 
>   2429 RTP Payload Format for the 1998 Version of ITU-T Rec. 
> H.263 Video
>        (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, 
> C. Maciocco,
>        D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. 
> October 1998.
>        (Format: TXT=43166 bytes) (Status: PROPOSED STANDARD)
> 
>   3047 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi.
>        January 2001. (Format: TXT=16292 bytes) (Status: 
> PROPOSED STANDARD)
> 
>   3095 RObust Header Compression (ROHC): Framework and four profiles:
>        RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M.
>        Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. 
> Hakenberg, T.
>        Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. 
> Svanbro, T.
>        Wiebke, T. Yoshimura, H. Zheng. July 2001. (Format: 
> TXT=368746 bytes)
>        (Status: PROPOSED STANDARD)
> 
>   3267 Real-Time Transport Protocol (RTP) Payload Format and File
>        Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive
>        Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, 
> M. Westerlund,
>        A. Lakaniemi, Q. Xie. June 2002. (Format: TXT=110652 
> bytes) (Status:
>        PROPOSED STANDARD)
> 
>   3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise
>        (CN). R. Zopf. September 2002. (Format: TXT=17018 
> bytes) (Status:
>        PROPOSED STANDARD)
> 
> These have plenty of G. and H. numbers in them and none of them are
> informational.  All of them make sense (for example: no severe scaling
> issues).
> 
> >         +-------------------------------+ 
> >         | Draft has progressed too far. |
> >         | Send to Curtis for review.    |
> >         +-------------------------------+
> >                   |
> >                   | 
> >                   V
> >              |            |
> >              |    TRASH   | 
> >              +------------+  
> 
> 
> I didn't realize I played such an important role in this process.  All
> this time I thought I was just making technical comments.
> 
> Sounds like you're still upset that I didn't like the OIF-UNI and/or
> you don't like technical comments regarding the feasibility of
> proposed encapsulation of G.709.  A primary point regarding OIF-UNI is
> that ATM-UNI service (ie: SVCs) never took off therefore the last
> thing we needed was a UNI for optical.  In other words, there is no
> credible requirement.
> 
> We'll have to see how the market acceptance of OIF-UNI goes.  So far
> it looks about as alive as CR-LDP did for a few years.  The market
> certainly put an end to LANE, NHRP, MPOA, and the whole idea of
> modeling ATM as a LIS.  Check the IPATM and ION archives if you'd like
> to read my comments on those standards which were strongly supported
> by SDOs outside the IETF.
> 
> I'm sorry that you don't like technical comments made about the G.709
> compressions.  Apparently some people think the IETF should just
> rubber stamp everything because it came from the ITU even if there are
> scalability issues which make deployment infeasible.
> 
> 
> > Seems a bit draconian and no wonder, people are anxious 
> > about the process and expect the worst.  Still, I believe 
> > this will help in limiting the generation of useless drafts 
> > and protocol extensions to
> > WGs within the IETF and prevent outside groups from doing the same. 
> > 
> > Regards,
> > 
> > Bala Rajagopalan
> 
> 
> The IETF can't stop other SDOs from creating useless protocols and
> protocol extensions and some have become quite good at it.  :-)
> 
> Curtis
> 

Delivery-date: Fri, 28 Feb 2003 08:43:37 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Kireeti Kompella (E-mail)" <[email-masked]>, [email-masked]
Cc: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: Last Call: Routing Extensions in Support of Generalized MPLS  vto  Proposed Standard
Date: Fri, 28 Feb 2003 17:42:45 +0100

Could the authors please answer to this IETF Last Call
Comment?

Thanks,
Bert 

-----Original Message-----
From: Jonathan Sadler [mailto:[email-masked]]
Sent: maandag 24 februari 2003 5:55
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call: Routing Extensions in Support of Generalized
MPLS vto Proposed Standard

Please consider the following comments on these drafts:
    draft-ietf-ccamp-gmpls-routing-05.txt
    draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
Many of the comments are based on implementation experience.  These comments are
marked with a (*).

Jonathan Sadler

==========

1. In section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt, the operations for
Packet Switch Capable (PSC) are defined.  Reference is made to Minimum LSP bandwidth
for SDH encoding.  None of the examples in section 5 of
draft-ietf-ccamp-gmpls-routing-05.txt show how this field should filled.

2. The mechanism for showing relationships between server and client layers is not
generalized*.  Specifically:
  - Relationships between SONET/SDH layers (ISC type: TDM) are
    implicitly stated based on the Min and Max LSP bandwidth
    advertised*.  To quote draft-ietf-ccamp-gmpls-routing-05.txt:

     "On an interface having Standard SDH multiplexing, an LSP
      at priority p could reserve any bandwidth allowed by the
      branch of the SDH hierarchy, with the leaf and the root
      of the branch being defined by the Minimum LSP Bandwidth
      and the Maximum LSP Bandwidth at priority p."

    This requires node doing the route calculation to understand
    the G.707 multiplexing hierarchy.  Since LSP routing is source
    routed, it could be the node doing the route calculation
    doesn't understand G.707.

    Furthermore, the G.707 multiplexing hierarchy is not a simple
    tree.  For example VC-11 and VC-12 can be supported over VC-3
    as well as over VC-4.  Consequently, the definition provided
    does not allow a system to explicitly state which "branch" of
    the G.707 hierarchy should be followed.

  - Relationships between PSC-n (for IP switching) and SONET/SDH are
    explicitly specified on the encoding type specified in the PSC-n
    announcement*.  However, SONET/SDH is not a single layer.  It
    must be possible to identify if the PSC-n layer can be carried
    by a VC-11 trail, a VC-12 trail, a VC-3 trail, a VC-4 trail,
    or a VC-4-nc trail.

    Section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt tries
    to deal with this in the following paragraph:

     "On a PSC interface that supports Standard SDH encoding, an
      LSP at priority p could reserve any bandwidth allowed by
      the branch of the SDH hierarchy, with the leaf and the root
      of the branch being defined by the Minimum LSP Bandwidth
      and the Maximum LSP Bandwidth at priority p."

    The problem is this contradicts the following paragraph:

     "The Maximum LSP Bandwidth takes the place of the Maximum
      Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum
      Bandwidth is a single fixed value (usually simply the link
      capacity), Maximum LSP Bandwidth is carried per priority,
      and may vary as LSPs are set up and torn down."
    Specifically, how does a completely available OC-48 interface
    with VC-11 over VC-3, VC-3, and VC-4 get encoded?  Based on
    the first paragraph, the encoding would be MinLSPBW=1.5M, and
    MaxLSPBW[p]=155M.  Ignoring the issue that VC-11 over VC-4
    ends up being shown as supported, the second paragraph states
    that the MaxLSPBW[p] should be 2.5G.

    Knowing the OC-48 is completely available is useful information,
    as multiple VC-4s could be used in an LCAS group to support
    connections that need data rates over 155M*.

 - The mechanism does not support describing common muli-layer
   relationships such as IP over DS1 over VC-11 or IP over DS3
   over VC-3*.

 - Sometimes layer relationships are described in an "inverted"
   manner*. Section 5.1 of draft-ietf-ccamp-gmpls-routing-05.txt
   states:
     "STM-16 POS Interface on a LSR

          Interface Switching Capability Descriptor:
             Interface Switching Capability = PSC-1
             Encoding = SDH
             Max LSP Bandwidth[p] = 2.5 Gbps, for all p"

   Where PSC-1 is the client of an SDH (sic) server.

   Section 5.5 states:
      "Interface of an opaque OXC (SDH framed) with support for
       one lambda per port/interface"

      "   Interface Switching Capability Descriptor:
             Interface Switching Capability = LSC
             Encoding = SDH"

   In this case, SDH is a client of a wavelength server (LSC).
   However, unlike in section 5.1, the layer relationship is
   inverted.

3. Layer specific attributes are not supported*.  Specifically:
 - It is not possible to have a link with different costs at
   different layers (ex. VC-11, VC-4, VC4-4c).  The link cost
   is a tool used by network designers to bias traffic toward or
   away from specific links.

   Since different hardware platforms are optimized for different
   layers, the network designer may wish to bias traffic in a layer
   to use or avoid a platform that inefficiently supports a
   particular layer.  The announcement of a link in the layer may
   still be desirable to allow for diverse routing.

 - Many attributes discussed actually refer to a specific layer*.
   For example SRLG can be an MS-layer attribute that is inherited
   by all supported layers (VC-11, VC-12, VC-3, VC-4, VC-4-nc).
   Likewise Protection mechanisms supported can be specified at
   the MS-layer and the path layer.

   Knowing the specific layer the attributes exist at allow for
   higher quality routes to be developed*.  It can also allow for
   proper provisioning of upper layer functions, such as protection
   hold off timers*.

 - Combining layer specific attributes with layer relationships can
   provide a more efficient encoding mechanism than requiring
   separate link announcements per layer*.

4. The "TDM" Interface Switching Capability presumably includes
   layers other than SONET/SDH, such as PDH* (DS1, DS3, E1, E3) and
   G.709.  The interaction with these layers needs to be defined.

5. In many cases, 8 levels of priority are not necessary*.  A more
   compact encoding that has a bitfield stating the priority levels
   being announced would reduce the size of the announcement.

The IESG wrote:

> The IESG has received a request from the Common Control and Measurement
> Plane Working Group to consider publication of the following two
> Internet-Drafts as Proposed Standards:
>
> o Routing Extensions in Support of Generalized MPLS
>     <draft-ietf-ccamp-gmpls-routing-05.txt>
> o OSPF Extensions in Support of Generalized MPLS
>     <draft-ietf-ccamp-ospf-gmpls-extensions-09.txt>
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2003-2-24.
>
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-05.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-09.txt

============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

_______________________________________________
This message was passed through [email-masked], which is a sublist of [email-masked]. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.

Delivery-date: Fri, 28 Feb 2003 08:08:44 -0800
Date: Fri, 28 Feb 2003 11:08:03 -0500
From: Scott W Brim <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Mail-Followup-To: Scott W Brim <[email-masked]>, [email-masked], [email-masked]

On Fri, Feb 28, 2003 04:52:40PM +0100, Mak, L (Leen) allegedly wrote:
> Wouldn't it be good to bring this whole discussion to the 
> ietf-problem-statement mailing list? It appears to be of
> a wider scope than ccamp and mpls.
> 
> Leen.

Yes, but wrong problem.  They're working on truly fundamental processes
right now, and won't have room for issues of external relations until
they finish with the internals.

Delivery-date: Fri, 28 Feb 2003 07:54:25 -0800
From: "Mak, L (Leen)" <[email-masked]>
To: "'Stephen Trowbridge'" <[email-masked]>, [email-masked]
Cc: John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Fri, 28 Feb 2003 16:52:40 +0100

Wouldn't it be good to bring this whole discussion to the 
ietf-problem-statement mailing list? It appears to be of
a wider scope than ccamp and mpls.

Leen.

> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: vrijdag 28 februari 2003 16:18
> To: [email-masked]
> Cc: John Drake; Kireeti Kompella; [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Dimitri,
> I have to respond in the same flavor that I responded to John.
> 
> Why is it that when we send the same type of request to ATM
> forum, the result is that they spend effort to try to understand
> the problem we are trying to solve and provide a great deal
> of helpful input directed at solving the problem we have raised?
> They have been genuinely interested in trying to figure out how
> their protocol can be applied and extended to solve our problem.
> 
> You mention needing a "decoder ring" to decipher G.8080 terminology,
> yet this terminology is certainly as foreign to ATM forum as it
> would be to ccamp (perhaps even moreso, since I think there is
> far more overlap in attendance between ITU-T SG15 and ccamp than
> there is between ITU-T SG15 and ATM forum). Yet ATM forum had no
> difficulty to understand what we were trying to do and to help us
> to develop the solution.
> 
> I do not think that this is because people in the ATM forum are
> so much more intelligent than those in ccamp: in fact, many people
> I have met in ccamp are absolutely brilliant. So if it is not the
> ability of the people that prevents this kind of productive work,
> I have to believe it is a shortcoming of the process.
> 
> IETF stands nearly alone in the community of International standards
> development organizations in not taking incoming liaisons as a
> very serious input. It is only recently that we even had a place
> to post incoming liaisons for IETF 
> (http://www.ietf.org/IESG/liaison.html).
> Now it is important to develop a process to make sure that 
> those liaisons
> are considered.
> 
> In addition, IETF needs to be able to generate liaison statements
> in order to effectively influence the work of other SDOs. IETF has
> historically taken the view that they don't need to send anybody
> anything because any information related to IETF can be found
> on their web site or seen on the mailing list. But as a practical
> matter, for most SDOs, input documents include contributions from
> members, documents (like agendas and reports) prepared by those with
> official positions, and LIAISON STATEMENTS. Surely you don't expect
> that most SDOs will consider as serious input something that somebody
> found on a web site or saw on a mailing list. To make IETF output
> be an input to another SDO, in most cases IETF will need to formally
> send it to the other SDO in the form of a liaison statement.
> To date, IETF has been unsuccessful in doing this.
> Regards,
> Steve
> 
> [email-masked] wrote:
> > 
> > stephen
> > 
> > i am resending you the e-mail sent to john because
> > i am not sure you have red it "> What we got from
> > IETF ccamp was ignored (until we finally did the
> > work somewhere else and tried to get code points
> > assigned)."
> > 
> > ---
> > 1) in order to initiate an action a clear under
> > standing of the problem must be achieved by the
> > ccamp wg community in order to make this happen
> > 
> > 2) expect that ietf community would understand
> > the terminology used in g.8080 (and subsequently
> > the issue) by sending a liaison was probably
> > a bit too optimistic -> thus the idea was to
> > initiate a sort of "decoder ring" (just to be sure
> > that when we say a "table" we are all in common
> > agreement on what a table is)
> > 
> > 3) instead of request changes to gmpls it would
> > have been much more constructive to know really
> > what are the architectural aspects covered by
> > itu that are the key in enabling signalling for
> > optical networks -> from that *clear* perspective
> > the ccamp wg was expecting a "functional spec"
> > i-d ... since the idea here was to understand
> > the functional requirement outside of any specific
> > signalling protocol (thus make abstraction of
> > what was included in g.7713.x in a first phase)
> > 
> > 4) once terminology + functional aspects would
> > have been understood by the ccamp wg deliver the
> > right answer using the ccamp community tools and
> > protocols
> > ---
> > 
> > last it is not the ccamp wg consensus that has
> > pushed itu editors to go to the info track ...
> > 
> > thanks,
> > - dimiti.
> > 
> > Stephen Trowbridge wrote:
> > >
> > > John,
> > >
> > > > JD:  Is that a threat or a promise?  BTW, call & 
> connection separation
> > > > doesn't exist in PNNI either, at least up to the point 
> that I stopped
> > > > attending the ATM Forum.
> > > Interesting that you should mention this.
> > >
> > > We sent liaisons to the ATM forum, just as we did to IETF ccamp.
> > > The reaction we got from the ATM forum was a great deal of help to
> > > extend the PNNI protocols to meet our requirements. They provided
> > > us numerous, helpful comments all through the process of 
> development
> > > of G.7713.1.
> > >
> > > What we got from IETF ccamp was ignored (until we finally did the
> > > work somewhere else and tried to get code points assigned).
> > >
> > > We seem to have different understandings of what the 
> problem is that
> > > needs to be solved. My belief is that the problem is that we don't
> > > have a good process for dealing with liaisons in IETF, and this
> > > inhibits the kinds of productive relationships between 
> IETF and other
> > > SDOs that exist between many other (non-IETF) SDOs.
> > >
> > > Some others on this thread seem to think that the problem is those
> > > other pesky SDOs: after all, how could there possibly be a valid
> > > problem statement or requirement that wasn't conceived of 
> and developed
> > > entirely within IETF? Every possible measure should be taken to
> > > prevent that any work is done to address such requirements.
> > >
> > > What is your perception of the problem?
> > > Steve
> > 
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : +32 3 240-8491
> 

Delivery-date: Fri, 28 Feb 2003 07:18:34 -0800
Date: Fri, 28 Feb 2003 08:17:41 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
CC: John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Dimitri,
I have to respond in the same flavor that I responded to John.

Why is it that when we send the same type of request to ATM
forum, the result is that they spend effort to try to understand
the problem we are trying to solve and provide a great deal
of helpful input directed at solving the problem we have raised?
They have been genuinely interested in trying to figure out how
their protocol can be applied and extended to solve our problem.

You mention needing a "decoder ring" to decipher G.8080 terminology,
yet this terminology is certainly as foreign to ATM forum as it
would be to ccamp (perhaps even moreso, since I think there is
far more overlap in attendance between ITU-T SG15 and ccamp than
there is between ITU-T SG15 and ATM forum). Yet ATM forum had no
difficulty to understand what we were trying to do and to help us
to develop the solution.

I do not think that this is because people in the ATM forum are
so much more intelligent than those in ccamp: in fact, many people
I have met in ccamp are absolutely brilliant. So if it is not the
ability of the people that prevents this kind of productive work,
I have to believe it is a shortcoming of the process.

IETF stands nearly alone in the community of International standards
development organizations in not taking incoming liaisons as a
very serious input. It is only recently that we even had a place
to post incoming liaisons for IETF (http://www.ietf.org/IESG/liaison.html).
Now it is important to develop a process to make sure that those liaisons
are considered.

In addition, IETF needs to be able to generate liaison statements
in order to effectively influence the work of other SDOs. IETF has
historically taken the view that they don't need to send anybody
anything because any information related to IETF can be found
on their web site or seen on the mailing list. But as a practical
matter, for most SDOs, input documents include contributions from
members, documents (like agendas and reports) prepared by those with
official positions, and LIAISON STATEMENTS. Surely you don't expect
that most SDOs will consider as serious input something that somebody
found on a web site or saw on a mailing list. To make IETF output
be an input to another SDO, in most cases IETF will need to formally
send it to the other SDO in the form of a liaison statement.
To date, IETF has been unsuccessful in doing this.
Regards,
Steve

[email-masked] wrote:
> 
> stephen
> 
> i am resending you the e-mail sent to john because
> i am not sure you have red it "> What we got from
> IETF ccamp was ignored (until we finally did the
> work somewhere else and tried to get code points
> assigned)."
> 
> ---
> 1) in order to initiate an action a clear under
> standing of the problem must be achieved by the
> ccamp wg community in order to make this happen
> 
> 2) expect that ietf community would understand
> the terminology used in g.8080 (and subsequently
> the issue) by sending a liaison was probably
> a bit too optimistic -> thus the idea was to
> initiate a sort of "decoder ring" (just to be sure
> that when we say a "table" we are all in common
> agreement on what a table is)
> 
> 3) instead of request changes to gmpls it would
> have been much more constructive to know really
> what are the architectural aspects covered by
> itu that are the key in enabling signalling for
> optical networks -> from that *clear* perspective
> the ccamp wg was expecting a "functional spec"
> i-d ... since the idea here was to understand
> the functional requirement outside of any specific
> signalling protocol (thus make abstraction of
> what was included in g.7713.x in a first phase)
> 
> 4) once terminology + functional aspects would
> have been understood by the ccamp wg deliver the
> right answer using the ccamp community tools and
> protocols
> ---
> 
> last it is not the ccamp wg consensus that has
> pushed itu editors to go to the info track ...
> 
> thanks,
> - dimiti.
> 
> Stephen Trowbridge wrote:
> >
> > John,
> >
> > > JD:  Is that a threat or a promise?  BTW, call & connection separation
> > > doesn't exist in PNNI either, at least up to the point that I stopped
> > > attending the ATM Forum.
> > Interesting that you should mention this.
> >
> > We sent liaisons to the ATM forum, just as we did to IETF ccamp.
> > The reaction we got from the ATM forum was a great deal of help to
> > extend the PNNI protocols to meet our requirements. They provided
> > us numerous, helpful comments all through the process of development
> > of G.7713.1.
> >
> > What we got from IETF ccamp was ignored (until we finally did the
> > work somewhere else and tried to get code points assigned).
> >
> > We seem to have different understandings of what the problem is that
> > needs to be solved. My belief is that the problem is that we don't
> > have a good process for dealing with liaisons in IETF, and this
> > inhibits the kinds of productive relationships between IETF and other
> > SDOs that exist between many other (non-IETF) SDOs.
> >
> > Some others on this thread seem to think that the problem is those
> > other pesky SDOs: after all, how could there possibly be a valid
> > problem statement or requirement that wasn't conceived of and developed
> > entirely within IETF? Every possible measure should be taken to
> > prevent that any work is done to address such requirements.
> >
> > What is your perception of the problem?
> > Steve
> 
> --
> Papadimitriou Dimitri
> E-mail : [email-masked]
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : +32 3 240-8491

Delivery-date: Fri, 28 Feb 2003 07:04:42 -0800
Date: Fri, 28 Feb 2003 16:03:07 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: John Drake <[email-masked]>
Cc: "'Stephen Trowbridge'" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

john,

i worry about the fundamental reasons behind "I'm 
assuming that in your worldview that the Yokohama 
CCAMP meeting never happened?" which is for me 
a very sensible and relevant point

because it means imho that independently of the 
real quality and level of details of the (future)
liaison process, clearly there are some "centrifuge" 
forces that tends to discourage a good collaboration 
(meaning is there somewhere reasons and interest 
in not making this happening - why ?), consensus
made during this yokohama meeting was unformal and
had been overridden thus why the formal one would
work better and preclude such situations to happen
once again ? since at the end of the day people 
behind the process make the decision (and since 
we speak about the same group of people...)

in a sense the yokohama meeting is not just about it
went to an info track ... it is to know *which* were
the technical and non-technical reasons for the i-d
editors in deciding to go the info track and not 
working in the scope of the working group ? 

as long as this question is not solved i really
worry about the real intent behind the current 
thread.

thanks,
- dimitri.

John Drake wrote:
> 
> Snipped...
> 
> > If SONET/SDH did not have what was required for this application,
> > I assume that IETF should first come to T1X1/ITU-T for the needed
> > extensions (much as ITU-T first came to IETF for the needed
> > extensions-remember?)
> 
> JD:  I'm assuming that in your worldview that the Yokohama CCAMP meeting
> never happened?
> 
> > In contrast to the IP network, you have demarcation points User/Network
> and
> > between network operators for billing purposes, etc. This
> > leads to some new requirements (e.g., call & connection separation)
> > not met by the base protocol. Is it reasonable that we want to
> > use the (G)MPLS protocols as a base and (inside or outside of
> > IETF) define the minimum set of extensions to meet the requirements,
> > or should we just have stuck with PNNI?
> 
> JD:  Is that a threat or a promise?  BTW, call & connection separation
> doesn't exist in PNNI either, at least up to the point that I stopped
> attending the ATM Forum.
> 
> 

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Fri, 28 Feb 2003 07:01:23 -0800
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "'Brungard, Deborah A, ALABS'" <[email-masked]>, Loa Andersson <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, Kireeti Kompella <[email-masked]>, Scott W Brim <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Fri, 28 Feb 2003 10:00:38 -0500

One of the reasons I believe it to be critical to address the liaison aspects
up front is that the issue actually goes well beyond specification
of an administrative process.  I.e., as can be seen from the email threads, it
brings up the whole discussion of how requirements for non-IP applications
originating from other SDOs are addressed.  One train of thought expressed
on the email list appears to take the view that such requirements should
have no extra weight than an individual than that of an individual; there
is no concept of a peer SDO.

Eve  

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 5:20 PM
To: Loa Andersson
Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim;
[email-masked]; [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

agree...

I suggest the liaison process should be a separate document. And update this if it needs updating. For people outside of IETF or new to IETF, it is useful to have these process descriptions. And they are two different subjects (with common links).

For Steve, Eve, etc, I think there are two (at least) discussions on-going (1) the liaison process (which will have the "hooks" to this document and vice versa), and (2) the "what if scenario" (for non-USA, this is our new shuttle terminology): how this document relates to if an sdo (or individual) works outside this process (info rfcs). It would be good (considering the discussion level) to add some clarification text to the chng proc draft.

One option suggested by Kireeti "this is where the SDO can decide, as you point out, that it can do it on its own, but changes the name of the protocol so that innocent bystanders can tell the difference." The SDO protocol is not IETF (as this chng proc draft states) and not (G)MPLS. And as Kireeti suggested the assignments by IANA should distinguish. Another option, suggested by Steve, is that IETF should be a clearinghouse. And discussion is on-going on the interpretation of clearinghouse. 

Steve, your email may be mis-interpreted, e.g.:
"A better approach would be for the IETF to PROMOTE the use of its
protocols for new applications, and, when another Standards Development
Organization wishes to apply (G)MPLS protocols to an application domain
outside of the scope of IETF, that IETF will (1) assist with the development
of any necessary extensions; and (2) to facilitate documentation of
such new applications and extensions in a central place (e.g., by
informational RFC, even for extensions that are developed outside of
IETF) and to insure that code points are assigned in a coherent manner
through IANA to avoid collisions where different extensions may use
the same code points to indicate different things."

I don't think you are requesting IETF to simply endorse another sdo's work without review (unless the interpretation of assist=review), and I am not so sure about the promotion either. In T1X1/ITU, just at this last meeting, many have voiced concern with new applications (suggested within the group) for GFP: PON, switched layer. The concern is on extending GFP beyond what it was designed. What if another forum decided to do switched GFP? And they liaisoned to ITU to incorporate the necessary extensions? Remember the difficulties we have with IEEE 10G WAN. It calls itself SDH, but it is not SDH (as we know SDH is more than just G.707). And it is already causing confusion among the innocent. And remember "SONET Lite". Here, in IETF, they have the same concern if the name GMPLS is used. GMPLS is more than just extensions.

Some possibilities: at minimum, if IANA assignment is requested by a sdo, the name should at least distinguish it as non-IETF. And in the scope clarify it is outside of the IETF process. Or change the rfc name "informational" as it can be mis-interpreted. In ITU rec'ds, we have appendices which are informational, but they are part of the "ITU process" i.e. reviewed/agreed.

Deborah

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 11:59 AM
To: Brungard, Deborah A, ALABS
Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim;
[email-masked]; [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Deborah,

I suggested earlier that we describe (short) in the draft how we will 
handle liasions
comeing into the IETF with request for changes or requirments related to 
the (g)mpls
protocols. It needs to be understood that the internal IETF process is 
specified for
IDs, and in some way we need bridge that gap. IETF and its working 
groups modifies IDs,
and I don't think it is good idea to start modifying liasions from other 
SDOs.

That we define the liasion process so it becoes crips and clear, and if 
when we are doing
find that it has an impact on the change process, we updte or 
re-organize the the
documents at that time.

Would that work? I guess that the answer is - yes, but only as much 
(little) as needed.

/Loa

Brungard, Deborah A, ALABS wrote:

>Maybe lets go back to my hopefully simple question, will the liaison process be included in this draft or not? I (thought) the answer was no. Maybe best to clarify. And not that it is not important, all the mail agrees it is important. Then we can work from this draft with comments, recognizing the liaison process will be separate, e.g. where the draft discusses other sdos, we can add text to clarify.
>
>One comment on all of this from an ITU/T1X1 history, it is difficult to say apriori how a liaison will be processed. We do not have such a process either. Several ways exist to respond:
>1. simple thank you for the information
>2. here's the answer/clarification based on current work
>3. for a quick answer, at the meeting, have a breakout group to address a proposal
>4. for new work, send a response saying we invite contributions to our future meetings to progress
>   - if no contributions, not anything is done (yes we have done this too)
>   - at the next meeting, send several proposals to the other group for their review
>
>I had understood this draft as including option 4. Other mails are raising the concern, as in the past, if no response to the other sdo, the other sdo can not determine the status of the work. That can be part of the liaison process.
>
>Let's first clarify, do we want this draft to include the liaison process or should we do it separate (in parallel?)?
>
>Deborah
>
>
>
>-----Original Message-----
>From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>Sent: Thursday, February 27, 2003 10:47 AM
>To: Kireeti Kompella; Wijnen, Bert (Bert)
>Cc: Scott W Brim; [email-masked]; [email-masked]
>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
>Inline
>
>  
>
>>-----Original Message-----
>>From: Kireeti Kompella [mailto:[email-masked]]
>>Sent: donderdag 27 februari 2003 10:09
>>To: Wijnen, Bert (Bert)
>>Cc: Scott W Brim; [email-masked]; [email-masked]
>>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>>
>>
>>Hi Bert,
>>
>>On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote:
>>
>>    
>>
>>>No of course NOT. Many Liasons will want an answer.
>>>So we need a process to follow up and to track if a timely
>>>response has been (or will be) send.
>>>      
>>>
>>Is the IETF process for replying to liaison statements (and of
>>generating them) written down, say in some RFC?  If so, could you
>>send me a pointer?
>>
>>    
>>
>Unfortunately, I don't think the process for that has been defined.
>That is why I said that "we need a process..."
>We do not have it yet (I think... at least I do not know it either).
>I think we were all just hoping people would take responsibility and
>do the right things... but as we know that is how things fall through
>the cracks.
>
>  
>
>>>But the Liasons communication between ITU and CCAMP/MPLS has not
>>>been going smoothly so far (even though we had good intentions).
>>>Responses have not gone out in time (or in some cases at all).
>>>      
>>>
>>I'll take full responsibility for that.
>>
>>    
>>
>W.r.t. CCAMP I will share some of the responsibility too. I should 
>also have kept a better eye on it.
>
>Bert
>  
>
>>Thanks,
>>Kireeti.
>>
>>    
>>
>
>
>
>
>  
>

Delivery-date: Fri, 28 Feb 2003 06:53:31 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Fri, 28 Feb 2003 06:52:50 -0800

Stephen,

This is the note I sent yesterday, which I thought was fairly clear.

Thanks,

John
============================================================================
====================================
Kireeti,

Extremely well reasoned and thoughtful.  As I understand it, this document
is intended to prevent the situation that just occured, in which the IETF
published an RFC which detailed some changes to RSVP-TE (which had technical
issues) without any review by the CCAMP or MPLS working groups, thereby
explicitly appearing to endorse these changes.

The minutes of the Yokohama CCAMP meeting (see below) seem to indicate that
the CCAMP working group wanted to work on the ASON extensions, so I am still
puzzled as to why the authors of the ASON draft decided, after the Yokohama
meeting, to progress the draft as an informational RFC rather than as a
normal working group draft.

Thanks,

John

> -----Original Message-----
> From: Stephen Trowbridge [mailto:[email-masked]]
> Sent: Friday, February 28, 2003 6:22 AM
> To: John Drake
> Cc: Kireeti Kompella; [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> John,
> 
> > JD:  Is that a threat or a promise?  BTW, call & connection 
> separation
> > doesn't exist in PNNI either, at least up to the point that 
> I stopped
> > attending the ATM Forum.
> Interesting that you should mention this.
> 
> We sent liaisons to the ATM forum, just as we did to IETF ccamp.
> The reaction we got from the ATM forum was a great deal of help to
> extend the PNNI protocols to meet our requirements. They provided
> us numerous, helpful comments all through the process of development
> of G.7713.1.
> 
> What we got from IETF ccamp was ignored (until we finally did the
> work somewhere else and tried to get code points assigned).
> 
> We seem to have different understandings of what the problem is that
> needs to be solved. My belief is that the problem is that we don't
> have a good process for dealing with liaisons in IETF, and this
> inhibits the kinds of productive relationships between IETF and other
> SDOs that exist between many other (non-IETF) SDOs.
> 
> Some others on this thread seem to think that the problem is those
> other pesky SDOs: after all, how could there possibly be a valid
> problem statement or requirement that wasn't conceived of and 
> developed
> entirely within IETF? Every possible measure should be taken to
> prevent that any work is done to address such requirements.
> 
> What is your perception of the problem?
> Steve
> 

Delivery-date: Fri, 28 Feb 2003 06:47:41 -0800
Date: Fri, 28 Feb 2003 15:45:16 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: Stephen Trowbridge <[email-masked]>
Cc: John Drake <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

stephen

i am resending you the e-mail sent to john because
i am not sure you have red it "> What we got from 
IETF ccamp was ignored (until we finally did the
work somewhere else and tried to get code points 
assigned)."

---
1) in order to initiate an action a clear under
standing of the problem must be achieved by the 
ccamp wg community in order to make this happen 

2) expect that ietf community would understand 
the terminology used in g.8080 (and subsequently
the issue) by sending a liaison was probably 
a bit too optimistic -> thus the idea was to
initiate a sort of "decoder ring" (just to be sure
that when we say a "table" we are all in common
agreement on what a table is)

3) instead of request changes to gmpls it would 
have been much more constructive to know really 
what are the architectural aspects covered by 
itu that are the key in enabling signalling for 
optical networks -> from that *clear* perspective 
the ccamp wg was expecting a "functional spec" 
i-d ... since the idea here was to understand 
the functional requirement outside of any specific
signalling protocol (thus make abstraction of 
what was included in g.7713.x in a first phase)

4) once terminology + functional aspects would
have been understood by the ccamp wg deliver the 
right answer using the ccamp community tools and
protocols
---

last it is not the ccamp wg consensus that has
pushed itu editors to go to the info track ...

thanks,
- dimiti.

Stephen Trowbridge wrote:
> 
> John,
> 
> > JD:  Is that a threat or a promise?  BTW, call & connection separation
> > doesn't exist in PNNI either, at least up to the point that I stopped
> > attending the ATM Forum.
> Interesting that you should mention this.
> 
> We sent liaisons to the ATM forum, just as we did to IETF ccamp.
> The reaction we got from the ATM forum was a great deal of help to
> extend the PNNI protocols to meet our requirements. They provided
> us numerous, helpful comments all through the process of development
> of G.7713.1.
> 
> What we got from IETF ccamp was ignored (until we finally did the
> work somewhere else and tried to get code points assigned).
> 
> We seem to have different understandings of what the problem is that
> needs to be solved. My belief is that the problem is that we don't
> have a good process for dealing with liaisons in IETF, and this
> inhibits the kinds of productive relationships between IETF and other
> SDOs that exist between many other (non-IETF) SDOs.
> 
> Some others on this thread seem to think that the problem is those
> other pesky SDOs: after all, how could there possibly be a valid
> problem statement or requirement that wasn't conceived of and developed
> entirely within IETF? Every possible measure should be taken to
> prevent that any work is done to address such requirements.
> 
> What is your perception of the problem?
> Steve

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Fri, 28 Feb 2003 06:41:48 -0800
From: John Drake <[email-masked]>
To: 'Gert Grammel' <[email-masked]>
Cc: 'Kireeti Kompella' <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Fri, 28 Feb 2003 06:40:59 -0800

Gert,

I'm sorry, I was teasing.  I was saying that if the IETF didn't like certain
features of the G.709 transport plane, following Stephen's argument, it
shouldn't feel constrained about changing them.  

I wasn't talking about your draft, which I think is a very good piece of
work.

Thanks,

John

> -----Original Message-----
> From: Gert Grammel [mailto:[email-masked]]
> Sent: Friday, February 28, 2003 4:10 AM
> To: John Drake
> Cc: 'Kireeti Kompella'; Stephen Trowbridge; [email-masked];
> [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Hi John,
> 
> I am not sure if I've got your point here about G.709 and the 
> way it is linked
> to the liason stuff. ITU-T defined G.709 as another circuit 
> technology to
> transport bits from A to B. It is similar to SDH/SONET and 
> falls into the ASON
> scope. Applying GMPLS on G.709 is straight forward and I am 
> not aware of any
> specific open issues here.
> In SDH/SONET some of the involved guys were trying to include 
> non-standard
> SDH/SONET features in the ietf-draft, meaning those not 
> explicitly mentioned in
> G.707. This caused of course a lot of friction. In contrast 
> to that, the G.709
> authors team is committed to remove everything from
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g70
> 9-03.txt which is
> not covered by G.709. In this sense it has the potential to 
> become a boiler
> plate for tight collaboration.
> So why do you think this work should be depreciated in CCAMP?
> 
> Regards
> 
> Gert
> 
> 
> 
> 
> 
> 
> John Drake wrote:
> 
> > Kireeti,
> >
> > There's always been a few things that I didn't like about 
> G.709, so maybe we
> > can just go ahead and deprecate them in CCAMP.  Then we can 
> figure this
> > liason stuff and tell the ITU about it.
> >
> > Thanks,
> >
> > John
> >
> > > -----Original Message-----
> > > From: Kireeti Kompella [mailto:[email-masked]]
> > > Sent: Thursday, February 27, 2003 3:04 PM
> > > To: Stephen Trowbridge
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > >
> > >
> > > Hi Steve,
> > >
> > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote:
> > >
> > > > If they decide not to be involved and the other SDO 
> goes ahead with
> > > > developing their own solution, they don't need to bless the
> > > extension,
> > > > or even like it, but they do need to accept it.
> > >
> > > Going back to the examples that Deborah brought up: what 
> if other SDOs
> > > produced variants of SDH -- would you say that the ITU "do need to
> > > accept it"?
> > >
> > > Kireeti.
> > >
> 
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:[email-masked]
> 
> 

Delivery-date: Fri, 28 Feb 2003 06:22:37 -0800
Date: Fri, 28 Feb 2003 07:21:33 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: John Drake <[email-masked]>
CC: Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

John,

> JD:  Is that a threat or a promise?  BTW, call & connection separation
> doesn't exist in PNNI either, at least up to the point that I stopped
> attending the ATM Forum.
Interesting that you should mention this.

We sent liaisons to the ATM forum, just as we did to IETF ccamp.
The reaction we got from the ATM forum was a great deal of help to
extend the PNNI protocols to meet our requirements. They provided
us numerous, helpful comments all through the process of development
of G.7713.1.

What we got from IETF ccamp was ignored (until we finally did the
work somewhere else and tried to get code points assigned).

We seem to have different understandings of what the problem is that
needs to be solved. My belief is that the problem is that we don't
have a good process for dealing with liaisons in IETF, and this
inhibits the kinds of productive relationships between IETF and other
SDOs that exist between many other (non-IETF) SDOs.

Some others on this thread seem to think that the problem is those
other pesky SDOs: after all, how could there possibly be a valid
problem statement or requirement that wasn't conceived of and developed
entirely within IETF? Every possible measure should be taken to
prevent that any work is done to address such requirements.

What is your perception of the problem?
Steve

Delivery-date: Fri, 28 Feb 2003 05:42:08 -0800
Date: Fri, 28 Feb 2003 08:40:39 -0500
From: Yangguang Xu <[email-masked]>
Organization: Lucent Technologies, Inc.
To: [email-masked]
CC: Stephen Trowbridge <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Curtis,

> 
> Go right a head and use PNNI.  Don't forget to run it over CLNP on a
> cell based infrastructure.  :-)
> 

Just a minor correction, it's PNNI over SSCOPMCE over anything (include IP).
Yet, I am not saying that I like it :-)

Yangguang

Delivery-date: Fri, 28 Feb 2003 04:11:18 -0800
Date: Fri, 28 Feb 2003 13:10:08 +0100
From: Gert Grammel <[email-masked]>
Organization: Alcatel TND Product Strategy
To: John Drake <[email-masked]>
CC: "'Kireeti Kompella'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi John,

I am not sure if I've got your point here about G.709 and the way it is linked
to the liason stuff. ITU-T defined G.709 as another circuit technology to
transport bits from A to B. It is similar to SDH/SONET and falls into the ASON
scope. Applying GMPLS on G.709 is straight forward and I am not aware of any
specific open issues here.
In SDH/SONET some of the involved guys were trying to include non-standard
SDH/SONET features in the ietf-draft, meaning those not explicitly mentioned in
G.707. This caused of course a lot of friction. In contrast to that, the G.709
authors team is committed to remove everything from
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-03.txt which is
not covered by G.709. In this sense it has the potential to become a boiler
plate for tight collaboration.
So why do you think this work should be depreciated in CCAMP?

Regards

Gert

John Drake wrote:

> Kireeti,
>
> There's always been a few things that I didn't like about G.709, so maybe we
> can just go ahead and deprecate them in CCAMP.  Then we can figure this
> liason stuff and tell the ITU about it.
>
> Thanks,
>
> John
>
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:[email-masked]]
> > Sent: Thursday, February 27, 2003 3:04 PM
> > To: Stephen Trowbridge
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > Hi Steve,
> >
> > On Thu, 27 Feb 2003, Stephen Trowbridge wrote:
> >
> > > If they decide not to be involved and the other SDO goes ahead with
> > > developing their own solution, they don't need to bless the
> > extension,
> > > or even like it, but they do need to accept it.
> >
> > Going back to the examples that Deborah brought up: what if other SDOs
> > produced variants of SDH -- would you say that the ITU "do need to
> > accept it"?
> >
> > Kireeti.
> >

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:[email-masked]

Delivery-date: Fri, 28 Feb 2003 03:24:10 -0800
From: Heiles Juergen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: AW: draft-kawakami-mpls-lsp-vlan-00.txt
Date: Fri, 28 Feb 2003 12:16:46 +0100

Genadi,

the draft proposes to use the MPLS control plane protocols for a =
different transport plane (Ethernet VLAN).
This is excatly what GMPLS is about. So I think it would be better to =
have the ID and dicussion in ccamp under the GMPLS work.

Regards

Juergen

> -----Urspr=FCngliche Nachricht-----
> Von: Genadi Velev [mailto:[email-masked]]
> Gesendet: Donnerstag, 27. Februar 2003 17:53
> An: [email-masked]
> Cc: [email-masked]
> Betreff: draft-kawakami-mpls-lsp-vlan-00.txt
>=20
>=20
> [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
> [ Mail was delivered through VPN PEL->MEI/AVCDC! ]
>=20
> Hi all,
>=20
> A new draft was published today (please see below).
>=20
> Any feedback and comments are welcome, especially from those=20
> of you who are
> dealing with packet transport over wide area Ethernet networks.
>=20
> thanks,
> Genadi
>=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > [email-masked]
> > Sent: Thursday, February 27, 2003 1:44 PM
> > To: IETF-Announce:
> > Cc: [email-masked]
> > Subject: I-D ACTION:draft-kawakami-mpls-lsp-vlan-00.txt
> >
> >
> > A New Internet-Draft is available from the on-line
> > Internet-Drafts directories.
> >
> >
> > 	Title		: Method to Setup LSP using VLAN Tag Switching
> > 	Author(s)	: T. Kawakami et al.
> > 	Filename	: draft-kawakami-mpls-lsp-vlan-00.txt
> > 	Pages		: 15
> > 	Date		: 2003-2-26
> >
> > This document describes a method to setup a Layer 2 tunnel over
> > networks based on Ethernet technology. For this purpose,=20
> the ports of
> > an Ethernet switch are configured to forward VLAN=20
> tag-labeled packets
> > incoming from a certain port to another unambiguous port by using
> > VLAN tag information. The Ethernet switches themselves are a part =
of
> > the Label Switching Routers (LSRs), which distribute the VLAN tags
> > using Label Distribution Protocol (LDP). To enable LDP to=20
> fulfil this
> > function, an LDP extension is proposed. The introduced method
> > simplifies the transport of Ethernet frames over wide area Ethernet
> > networks.
> >
> > A URL for this Internet-Draft is:
> >=20
http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-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-kawakami-mpls-lsp-vlan-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:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-kawakami-mpls-lsp-vlan-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.
>

Delivery-date: Thu, 27 Feb 2003 18:48:59 -0800
Date: Thu, 27 Feb 2003 18:47:35 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Curtis Villamizar <[email-masked]>
cc: [email-masked], "" <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 

Hi Curtis,

On Thu, 27 Feb 2003, Curtis Villamizar wrote:

> The emphasis on running code and rough consensus rather than study
> groups and voting has worked quite well.  There is not reason to
> change it or to consider a liason comment or contribution and
> different from any other contribution.

I'm glad to hear this!

It is important, especially as this argument goes downhill fast
(starting with veiled threats and "I'm calling your bluff" responses),
to keep the big picture in mind:

a) There is a half-written, half-implicit and half-in-the-hallways
   process *for the IETF* to change IETF protocols.  It would be good
   to have more of the process written down, at least in the context of
   (G)MPLS.  The primary goal of the (G)MPLS change document is that
   this process is made known to all SDOs (including the IETF!).
b) There are often requirements from other SDOs for changes in IETF
   protocols.  *If* they choose to bring these to the IETF and have
   the IETF do the changes, it is good for them to know the process.
   If, as Steve points out, the SDO chooses to make the changes on its
   own, for whatever reason, that is beyond the scope of the (G)MPLS
   change document.
c) A liaison statement may declare the intent to follow up with the
   requirements or requests for changes in IETF protocols, but should
   not (IMO) be used to effect those changes.  A process for replying
   to (and generating) liaisons statements is needed.
d) The fundamental IETF mechanisms (though some may view them as broken)
   such as rough consensus and running code are *not* in question here.
   Those may be brought up on the general IETF list, or with the IESG
   or IAB.

Kireeti.

Delivery-date: Thu, 27 Feb 2003 17:52:49 -0800
From: John Drake <[email-masked]>
To: 'Stephen Trowbridge' <[email-masked]>, Kireeti Kompella <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 17:50:27 -0800

Snipped...

> If SONET/SDH did not have what was required for this application,
> I assume that IETF should first come to T1X1/ITU-T for the needed
> extensions (much as ITU-T first came to IETF for the needed 
> extensions-remember?)

JD:  I'm assuming that in your worldview that the Yokohama CCAMP meeting
never happened?

> In contrast to the IP network, you have demarcation points User/Network
and
> between network operators for billing purposes, etc. This
> leads to some new requirements (e.g., call & connection separation)
> not met by the base protocol. Is it reasonable that we want to
> use the (G)MPLS protocols as a base and (inside or outside of
> IETF) define the minimum set of extensions to meet the requirements,
> or should we just have stuck with PNNI?

JD:  Is that a threat or a promise?  BTW, call & connection separation
doesn't exist in PNNI either, at least up to the point that I stopped
attending the ATM Forum.

Delivery-date: Thu, 27 Feb 2003 17:52:41 -0800
To: Kireeti Kompella <[email-masked]>
cc: Stephen Trowbridge <[email-masked]>, [email-masked], "" <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Thu, 27 Feb 2003 18:56:41 -0500
From: Curtis Villamizar <[email-masked]>

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <[email-masked]>, Kireeti Kompella writes:
> Hi Steve,
> 
> On Thu, 27 Feb 2003, Stephen Trowbridge wrote:
> 
> > If they decide not to be involved and the other SDO goes ahead with
> > developing their own solution, they don't need to bless the extension,
> > or even like it, but they do need to accept it.
> 
> Going back to the examples that Deborah brought up: what if other SDOs
> produced variants of SDH -- would you say that the ITU "do need to
> accept it"?
> 
> Kireeti.

It really becomes a practical matter.

For example, SONET scrambling was changed because the original was too
short and too easy to send an IP packet containing the entire reverse
scramble sequence leading to all same bit after scrambling, causing a
SONET framing error.  The ease of doing this was demostrated by a BBN
engineer in network operations.  Although the push came from the IETF
to change this and there was resistance it was changed when it was
obvious that customers were going to insist on the change in products,
whether or not any SDO blessed the change.

The opposite is true in the case of ITU requirements for QoS published
in the mid 1990s.  IETF didn't like it.  No one implemented.  No
customers asked for it.  End of story.

An example where the SDO didn't accept changes and the SDO became
irrelevant wrt those specs is ISIS, where nearly 100% of implemented
and deployed ISIS is according to the IETF defined extensions to ISIS
which began with rfc1195.  ISO has never quite recognized the IETF
extensions, but no one really cares much what ISO thinks about this.

A few things have been jammed through the IETF that never went any
where.  For example, guarenteed services in RSVP, NHRP (and everything
the ROLC and ION WGs did, and most of what IPATM did), QoS routing
extensions for OSPF.  The requirements documet first is a means of
insuring better quality control over what emerges from the IETF.  (Not
in terms of "to the letter perfect" documents, but useful protocols).

The emphasis on running code and rough consensus rather than study
groups and voting has worked quite well.  There is not reason to
change it or to consider a liason comment or contribution and
different from any other contribution.

Curtis

Delivery-date: Thu, 27 Feb 2003 15:22:42 -0800
From: John Drake <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, Stephen Trowbridge <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 15:22:17 -0800

Kireeti,

There's always been a few things that I didn't like about G.709, so maybe we
can just go ahead and deprecate them in CCAMP.  Then we can figure this
liason stuff and tell the ITU about it.

Thanks,

John  

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 3:04 PM
> To: Stephen Trowbridge
> Cc: [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Hi Steve,
> 
> On Thu, 27 Feb 2003, Stephen Trowbridge wrote:
> 
> > If they decide not to be involved and the other SDO goes ahead with
> > developing their own solution, they don't need to bless the 
> extension,
> > or even like it, but they do need to accept it.
> 
> Going back to the examples that Deborah brought up: what if other SDOs
> produced variants of SDH -- would you say that the ITU "do need to
> accept it"?
> 
> Kireeti.
> 

Delivery-date: Thu, 27 Feb 2003 15:19:41 -0800
Date: Thu, 27 Feb 2003 16:18:54 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: Kireeti Kompella <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Kireeti,
I'm not sure that this is the same.
IETF develops control plane technology that can control SONET/SDH
equipment used to carry physical layer connections supporting an
IP network. Presumably SONET/SDH doesn't need to change for this
application as long as virtual concatenation, etc. support the
necessary pipe sizes.

If SONET/SDH did not have what was required for this application,
I assume that IETF should first come to T1X1/ITU-T for the needed
extensions (much as ITU-T first came to IETF for the needed extensions-
remember?). If ITU-T then was not interested to help and if standardized
SONET/SDH did not meet the requirements, I suppose
that IETF would have the right to do what it needed for its
application and inform ITU-T what it had done.

ITU-T wants to apply the control plane technology to a general
purpose (not necessarily IP) transport network. In contrast to
the IP network, you have demarcation points User/Network and
between network operators for billing purposes, etc. This
leads to some new requirements (e.g., call & connection separation)
not met by the base protocol. Is it reasonable that we want to
use the (G)MPLS protocols as a base and (inside or outside of
IETF) define the minimum set of extensions to meet the requirements,
or should we just have stuck with PNNI?
Regards,
Steve

Kireeti Kompella wrote:
> 
> Hi Steve,
> 
> On Thu, 27 Feb 2003, Stephen Trowbridge wrote:
> 
> > If they decide not to be involved and the other SDO goes ahead with
> > developing their own solution, they don't need to bless the extension,
> > or even like it, but they do need to accept it.
> 
> Going back to the examples that Deborah brought up: what if other SDOs
> produced variants of SDH -- would you say that the ITU "do need to
> accept it"?
> 
> Kireeti.

Delivery-date: Thu, 27 Feb 2003 15:06:07 -0800
Date: Fri, 28 Feb 2003 00:04:13 +0100
From: [email-masked]
Organization: optical network architecture (nta - antwerpen)
To: John Drake <[email-masked]>
Cc: "'George Newsome'" <[email-masked]>, "'Kireeti Kompella'" <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

john, here it is ...

... and if i well remember.. trying to summarize
here the issue:

1) in order to initiate an action a clear under
standing of the problem must be achieved by the 
ccamp wg community in order to make this happen 

2) expect that ietf community would understand 
the terminology used in g.8080 (and subsequently
the issue) by sending a liaison was probably 
a bit too optimistic -> thus the idea was to
initiate a sort of "decoder ring" (just to be sure
that when we say a "table" we are all in common
agreement on what a table is)

3) instead of request changes to gmpls it would 
have been much more constructive to know really 
what are the architectural aspects covered by 
itu that are the key in enabling signalling for 
optical networks -> from that *clear* perspective 
the ccamp wg was expecting a "functional spec" 
i-d ... since the idea here was to understand 
the functional requirement outside of any specific
signalling protocol (thus make abstraction of 
what was included in g.7713.x in a first phase)

4) once terminology + functional aspects would
have been understood by the ccamp wg deliver the 
right answer using the ccamp community tools and
protocols

in brief, the idea developed in yokohama was
"please put the g.8080 architecture on the table,
and let's have a signalling functional i-d to 
clearly understand the issue and then the ccamp 
wg community will deliver the adequate gmpls 
profile" instead of that the two editors of the 
document decided to go the "info track" ... i 
never understood the real argumentation behind 
this ... clearly as we say in french "la sauce 
n'a pas prise" but i consider this as a turning-
point in the ccamp/sg15 collaboration

then, as already pointed out, we couldn't avoid  
"that the SDO can decide to do it on its own, but 
then changes the name of the protocol so that 
innocent bystanders can tell the difference." 
and this is what happened for signalling.

note: kireeti please correct me if you think
there is something missing or wrong here

hope this clarifies,
- dimitri.

John Drake wrote:
> 
> George,
> 
> I didn't attend.
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: George Newsome [mailto:[email-masked]]
> > Sent: Thursday, February 27, 2003 10:17 AM
> > To: John Drake
> > Cc: 'Kireeti Kompella'; Stephen Trowbridge; [email-masked];
> > [email-masked]
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> >
> > John Drake wrote:
> >
> >
> > > Snipped...
> > >
> > > Stephen Trowbridge asked what further information the IETF
> > requires.
> > >
> > > Dimitri and Kireeti answered the question in detail."
> > >
> >
> >
> > And the answer was ????
> >
> > A pity that the detailed answer is apparently not minuted.
> >
> > George
> >

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

Delivery-date: Thu, 27 Feb 2003 15:04:28 -0800
Date: Thu, 27 Feb 2003 15:04:03 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Stephen Trowbridge <[email-masked]>
cc: [email-masked], "" <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi Steve,

On Thu, 27 Feb 2003, Stephen Trowbridge wrote:

> If they decide not to be involved and the other SDO goes ahead with
> developing their own solution, they don't need to bless the extension,
> or even like it, but they do need to accept it.

Going back to the examples that Deborah brought up: what if other SDOs
produced variants of SDH -- would you say that the ITU "do need to
accept it"?

Kireeti.

Delivery-date: Thu, 27 Feb 2003 14:59:55 -0800
Date: Thu, 27 Feb 2003 15:57:44 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: "Brungard, Deborah A, ALABS" <[email-masked]>
CC: Loa Andersson <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, Kireeti Kompella <[email-masked]>, Scott W Brim <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Deborah,

> I don't think you are requesting IETF to simply endorse another
> sdo's work without review (unless the interpretation of assist=review),
> and I am not so sure about the promotion either.

This is not quite what I am trying to say -
Presumably the other SDO starts communication at the problem statement
phase (e.g., the Oct 2001 liaisons SG15 to ccamp). IETF is free to decide
if it makes sense for IETF to be involved in development of the solution.

If they decide not to be involved and the other SDO goes ahead with
developing their own solution, they don't need to bless the extension,
or even like it, but they do need to accept it. At this point we may
as well document it in an info RFC (not standards track for IETF) and
make sure the codepoint assignments are done in a way that avoids conflict
or overlap with other extensions.

There is another subtlety that perhaps I failed to capture in
enough detail. If the IETF does decide to be involved, their involvement
is in applying their protocol expertise in determining HOW to solve the
problem that the other SDO has raised. I am uncomfortable with a
process that leaves the IETF as the sole arbiter of WHETHER the problem
will be solved or whether the requirements developed by the other SDO
are valid. The application domain being addressed by the other SDO
may very well be different than the one being addressed by IETF, and
the validity of what the other SDO sees as their requirements for
their application domain is not for IETF to decide.

I am also a concerned with the following:
> One option suggested by Kireeti "this is where the SDO can decide,
> as you point out, that it can do it on its own, but
> changes the name of the protocol so that innocent bystanders can tell
> the difference."
This seems like a road to chaos. You end up with a proliferation of
(G)MPLS-like protocols which are all slightly different whenever there
is a requirement of another SDO that IETF doesn't accept or understand.
I think if we can come up with something more of the "clearinghouse"
flavor, we can at least keep a common umbrella over the family of
IETF and non-IETF developed extensions (based on whether IETF had
the interest or expertise to be involved in any particular extension),
to understand (as Stephen Shew pointed out) which extensions can
co-exist, to avoid conflicts, etc.

Regards,
Steve

Delivery-date: Thu, 27 Feb 2003 14:21:48 -0800
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 17:19:46 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Loa Andersson" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, "Scott W Brim" <[email-masked]>, <[email-masked]>, <[email-masked]>

agree...

I suggest the liaison process should be a separate document. And update =
this if it needs updating. For people outside of IETF or new to IETF, it =
is useful to have these process descriptions. And they are two different =
subjects (with common links).

For Steve, Eve, etc, I think there are two (at least) discussions =
on-going (1) the liaison process (which will have the "hooks" to this =
document and vice versa), and (2) the "what if scenario" (for non-USA, =
this is our new shuttle terminology): how this document relates to if an =
sdo (or individual) works outside this process (info rfcs). It would be =
good (considering the discussion level) to add some clarification text =
to the chng proc draft.

One option suggested by Kireeti "this is where the SDO can decide, as =
you point out, that it can do it on its own, but changes the name of the =
protocol so that innocent bystanders can tell the difference." The SDO =
protocol is not IETF (as this chng proc draft states) and not (G)MPLS. =
And as Kireeti suggested the assignments by IANA should distinguish. =
Another option, suggested by Steve, is that IETF should be a =
clearinghouse. And discussion is on-going on the interpretation of =
clearinghouse.=20

Steve, your email may be mis-interpreted, e.g.:
"A better approach would be for the IETF to PROMOTE the use of its
protocols for new applications, and, when another Standards Development
Organization wishes to apply (G)MPLS protocols to an application domain
outside of the scope of IETF, that IETF will (1) assist with the =
development
of any necessary extensions; and (2) to facilitate documentation of
such new applications and extensions in a central place (e.g., by
informational RFC, even for extensions that are developed outside of
IETF) and to insure that code points are assigned in a coherent manner
through IANA to avoid collisions where different extensions may use
the same code points to indicate different things."

I don't think you are requesting IETF to simply endorse another sdo's =
work without review (unless the interpretation of assist=3Dreview), and =
I am not so sure about the promotion either. In T1X1/ITU, just at this =
last meeting, many have voiced concern with new applications (suggested =
within the group) for GFP: PON, switched layer. The concern is on =
extending GFP beyond what it was designed. What if another forum decided =
to do switched GFP? And they liaisoned to ITU to incorporate the =
necessary extensions? Remember the difficulties we have with IEEE 10G =
WAN. It calls itself SDH, but it is not SDH (as we know SDH is more than =
just G.707). And it is already causing confusion among the innocent. And =
remember "SONET Lite". Here, in IETF, they have the same concern if the =
name GMPLS is used. GMPLS is more than just extensions.

Some possibilities: at minimum, if IANA assignment is requested by a =
sdo, the name should at least distinguish it as non-IETF. And in the =
scope clarify it is outside of the IETF process. Or change the rfc name =
"informational" as it can be mis-interpreted. In ITU rec'ds, we have =
appendices which are informational, but they are part of the "ITU =
process" i.e. reviewed/agreed.

Deborah

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 11:59 AM
To: Brungard, Deborah A, ALABS
Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim;
[email-masked]; [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Deborah,

I suggested earlier that we describe (short) in the draft how we will=20
handle liasions
comeing into the IETF with request for changes or requirments related to =

the (g)mpls
protocols. It needs to be understood that the internal IETF process is=20
specified for
IDs, and in some way we need bridge that gap. IETF and its working=20
groups modifies IDs,
and I don't think it is good idea to start modifying liasions from other =

SDOs.

That we define the liasion process so it becoes crips and clear, and if=20
when we are doing
find that it has an impact on the change process, we updte or=20
re-organize the the
documents at that time.

Would that work? I guess that the answer is - yes, but only as much=20
(little) as needed.

/Loa

Brungard, Deborah A, ALABS wrote:

>Maybe lets go back to my hopefully simple question, will the liaison =
process be included in this draft or not? I (thought) the answer was no. =
Maybe best to clarify. And not that it is not important, all the mail =
agrees it is important. Then we can work from this draft with comments, =
recognizing the liaison process will be separate, e.g. where the draft =
discusses other sdos, we can add text to clarify.
>
>One comment on all of this from an ITU/T1X1 history, it is difficult to =
say apriori how a liaison will be processed. We do not have such a =
process either. Several ways exist to respond:
>1. simple thank you for the information
>2. here's the answer/clarification based on current work
>3. for a quick answer, at the meeting, have a breakout group to address =
a proposal
>4. for new work, send a response saying we invite contributions to our =
future meetings to progress
>   - if no contributions, not anything is done (yes we have done this =
too)
>   - at the next meeting, send several proposals to the other group for =
their review
>
>I had understood this draft as including option 4. Other mails are =
raising the concern, as in the past, if no response to the other sdo, =
the other sdo can not determine the status of the work. That can be part =
of the liaison process.
>
>Let's first clarify, do we want this draft to include the liaison =
process or should we do it separate (in parallel?)?
>
>Deborah
>
>
>
>-----Original Message-----
>From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>Sent: Thursday, February 27, 2003 10:47 AM
>To: Kireeti Kompella; Wijnen, Bert (Bert)
>Cc: Scott W Brim; [email-masked]; [email-masked]
>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
>Inline
>
> =20
>
>>-----Original Message-----
>>From: Kireeti Kompella [mailto:[email-masked]]
>>Sent: donderdag 27 februari 2003 10:09
>>To: Wijnen, Bert (Bert)
>>Cc: Scott W Brim; [email-masked]; [email-masked]
>>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>>
>>
>>Hi Bert,
>>
>>On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote:
>>
>>   =20
>>
>>>No of course NOT. Many Liasons will want an answer.
>>>So we need a process to follow up and to track if a timely
>>>response has been (or will be) send.
>>>     =20
>>>
>>Is the IETF process for replying to liaison statements (and of
>>generating them) written down, say in some RFC?  If so, could you
>>send me a pointer?
>>
>>   =20
>>
>Unfortunately, I don't think the process for that has been defined.
>That is why I said that "we need a process..."
>We do not have it yet (I think... at least I do not know it either).
>I think we were all just hoping people would take responsibility and
>do the right things... but as we know that is how things fall through
>the cracks.
>
> =20
>
>>>But the Liasons communication between ITU and CCAMP/MPLS has not
>>>been going smoothly so far (even though we had good intentions).
>>>Responses have not gone out in time (or in some cases at all).
>>>     =20
>>>
>>I'll take full responsibility for that.
>>
>>   =20
>>
>W.r.t. CCAMP I will share some of the responsibility too. I should=20
>also have kept a better eye on it.
>
>Bert
> =20
>
>>Thanks,
>>Kireeti.
>>
>>   =20
>>
>
>
>
>
> =20
>

Delivery-date: Thu, 27 Feb 2003 13:29:38 -0800
To: [email-masked]
cc: Loa Andersson <[email-masked]>, Kireeti Kompella <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Thu, 27 Feb 2003 14:14:22 -0500
From: Curtis Villamizar <[email-masked]>

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <[email-masked]>, Eric Rosen wr
ites:
> 
> It seems to me that Loa's  document simply describes how the IETF works.  As
> such, I'm not sure it is even necessary. 
> 
> True, many people have  noticed that the IETF is free to  ignore the work of
> other standard organizations.  True, the  fact that a particular proposal is
> made by another  standards organization does not even  give the proposal any
> special weight in the IETF.
> 
> I think these are  good things, and the IETF should not  make any changes in
> this respect.  Hence I don't think  Loa's draft (if it needs to exist) needs
> to change.
> 
> Certainly  the  fact  that  some  position  is  articulated  in  a  "liaison
> statement"  should not  give  it any  special  weight.  The  fact that  some
> position is supported  by "a threshold number of  vendors and SPs" shouldn't
> give it any special weight either.  

Eric,

I completely agree with you but would like to make one clarification.

The "number of vendors and SPs" should not be given any weight at all
in toward the rough consensus criteria.  However, implementation by
vendors and deployment by SPs should be given strong consideration
regarding whether there exists any "running code" and "independent
interoperable implementations".

The IETF shouldn't care who you think you are or who you work for if
you don't show up with running code.  This eliminates committee
contributions such as study groups with a spec and no code or
deployment (and sometimes no valid requirement).

The number of internet-drafts that were not advanced due to not having
concensus on a requirements statement is quite large.  Few rejected on
that grounds resurfaced later when a need became evident and extremely
few resurfaced and were later implemented.  Diffserv-TE is about the
only set of drafts to get pushed back, resurface, and get implemented
and this was not a liason work.

Curtis

Delivery-date: Thu, 27 Feb 2003 13:29:27 -0800
To: "Ong, Lyndon" <[email-masked]>
cc: "'Loa Andersson'" <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, Kireeti Kompella <[email-masked]>, Scott W Brim <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Thu, 27 Feb 2003 13:20:24 -0500
From: Curtis Villamizar <[email-masked]>

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <[email-masked]>, "Ong,
 Lyndon" writes:
> Hi,
> 
> Can I ask a clarifying question regarding liaisons?  The
> issue revolves around making extensions to GMPLS.  Is
> it the view that such extensions must be generated 
> through Internet Drafts, and cannot be through
> liaisons?
> 
> It sounds like people may be assuming that liaisons are
> always providing background information or requesting
> information, when on occasion a liaison may be requesting
> a change or action.
> 
> BTW, regarding responses to liaisons, the A-D may or may
> not be the proper source for a response, but the knowledge
> for putting together the response would typically reside
> within a particular WG, I believe.  One problem is that
> you don't have the time within an IETF meeting to assign
> a "stuckie" (to use the new term) to write a response ;o)
> 
> Cheers,
> 
> Lyndon

The way you initiate action within the IETF is to submit an internet
draft.  The liason response from the IETF should simply be to send a
copy of rfc2026 and invite participants of the other forum to
participate in the IETF process.

Curtis

Delivery-date: Thu, 27 Feb 2003 13:29:19 -0800
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: Kireeti Kompella <[email-masked]>, Scott W Brim <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Thu, 27 Feb 2003 12:39:08 -0500
From: Curtis Villamizar <[email-masked]>

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

In message <[email-masked]
om>, "Wijnen, Bert (Bert)" writes:
> Inline
> 
> > -----Original Message-----
> > From: Kireeti Kompella [mailto:[email-masked]]
> > Sent: donderdag 27 februari 2003 10:09
> > To: Wijnen, Bert (Bert)
> > Cc: Scott W Brim; [email-masked]; [email-masked]
> > Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> > 
> > 
> > Hi Bert,
> > 
> > On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote:
> > 
> > > No of course NOT. Many Liasons will want an answer.
> > > So we need a process to follow up and to track if a timely
> > > response has been (or will be) send.
> > 
> > Is the IETF process for replying to liaison statements (and of
> > generating them) written down, say in some RFC?  If so, could you
> > send me a pointer?
> > 
> Unfortunately, I don't think the process for that has been defined.
> That is why I said that "we need a process..."
> We do not have it yet (I think... at least I do not know it either).
> I think we were all just hoping people would take responsibility and
> do the right things... but as we know that is how things fall through
> the cracks.
> 
> > > But the Liasons communication between ITU and CCAMP/MPLS has not
> > > been going smoothly so far (even though we had good intentions).
> > > Responses have not gone out in time (or in some cases at all).
> > 
> > I'll take full responsibility for that.
> > 
> W.r.t. CCAMP I will share some of the responsibility too. I should 
> also have kept a better eye on it.
> 
> Bert
> > Thanks,
> > Kireeti.

To be honest, I think there is a process.

IETF recognizes individuals, not organizations.  A liason may present
a liason statement in an IETF meeting or send it to a WG (or other)
mailing list but like any other type of organization the individual is
recognized, not the organization.  That same person is free to take
impressions back to their organization.

The IETF believes in running code and rough consensus.  Too much
standardization occurs without running code (and preferably also at
least trial deployment) and too much gets standardized committee style
and ends up not working (quite often protocols can't be deployed
because they don't scale, often predicted but the standards body
marched forward despite technical objections related to scaling).  If
the ITU wants to work that way fine.  At least the IETF wants to make
sure there are clear requirements before pursuing much effort toward
standardization in advance of running and deployed code.  The
chng-proc draft clarifies this and puts procedure in place toward that
end.  It is also worth noting that if you have deployed code you have
good evidence that there was a requirement and there should be
empirical evicence related to the solution's ability to meet the
requirement.

Curtis

Delivery-date: Thu, 27 Feb 2003 10:45:12 -0800
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Loa Andersson <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Date: Thu, 27 Feb 2003 13:44:35 -0500

Hi,

The conversation that's being stimulated from the draft gets to the crux of
the issue I see with its current wording.  The draft is being
interpreted as simply describing the present IETF mode of operation.  I didn't
think that was supposed to be the intent.

Eve

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 1:23 PM
To: Loa Andersson
Cc: Kireeti Kompella; Stephen Trowbridge; [email-masked];
[email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 

It seems to me that Loa's  document simply describes how the IETF works.  As
such, I'm not sure it is even necessary. 

True, many people have  noticed that the IETF is free to  ignore the work of
other standard organizations.  True, the  fact that a particular proposal is
made by another  standards organization does not even  give the proposal any
special weight in the IETF.

I think these are  good things, and the IETF should not  make any changes in
this respect.  Hence I don't think  Loa's draft (if it needs to exist) needs
to change.

Certainly  the  fact  that  some  position  is  articulated  in  a  "liaison
statement"  should not  give  it any  special  weight.  The  fact that  some
position is supported  by "a threshold number of  vendors and SPs" shouldn't
give it any special weight either.  

Delivery-date: Thu, 27 Feb 2003 10:42:21 -0800
From: John Drake <[email-masked]>
To: 'George Newsome' <[email-masked]>
Cc: 'Kireeti Kompella' <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 10:41:45 -0800

George,

I didn't attend.

Thanks,

John

> -----Original Message-----
> From: George Newsome [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 10:17 AM
> To: John Drake
> Cc: 'Kireeti Kompella'; Stephen Trowbridge; [email-masked];
> [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> John Drake wrote:
> 
> 
> > Snipped...
> > 
> > Stephen Trowbridge asked what further information the IETF 
> requires. 
> > 
> > Dimitri and Kireeti answered the question in detail."
> >
> 
> 
> And the answer was ????
> 
> A pity that the detailed answer is apparently not minuted.
> 
> George
> 

Delivery-date: Thu, 27 Feb 2003 10:35:04 -0800
To: Loa Andersson <[email-masked]>
cc: Kireeti Kompella <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
Reply-To: [email-masked]
Date: Thu, 27 Feb 2003 13:22:48 -0500
From: Eric Rosen <[email-masked]>

It seems to me that Loa's  document simply describes how the IETF works.  As
such, I'm not sure it is even necessary. 

True, many people have  noticed that the IETF is free to  ignore the work of
other standard organizations.  True, the  fact that a particular proposal is
made by another  standards organization does not even  give the proposal any
special weight in the IETF.

I think these are  good things, and the IETF should not  make any changes in
this respect.  Hence I don't think  Loa's draft (if it needs to exist) needs
to change.

Certainly  the  fact  that  some  position  is  articulated  in  a  "liaison
statement"  should not  give  it any  special  weight.  The  fact that  some
position is supported  by "a threshold number of  vendors and SPs" shouldn't
give it any special weight either.  

Delivery-date: Thu, 27 Feb 2003 10:18:14 -0800
Date: Thu, 27 Feb 2003 13:16:31 -0500
From: George Newsome <[email-masked]>
To: John Drake <[email-masked]>
CC: 'Kireeti Kompella' <[email-masked]>, Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

John Drake wrote:

> Snipped...
> 
> Stephen Trowbridge asked what further information the IETF requires. 
> 
> Dimitri and Kireeti answered the question in detail."
>

And the answer was ????

A pity that the detailed answer is apparently not minuted.

George

Delivery-date: Thu, 27 Feb 2003 10:02:36 -0800
From: John Drake <[email-masked]>
To: 'Kireeti Kompella' <[email-masked]>, Stephen Trowbridge <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 10:01:41 -0800

Kireeti,

Extremely well reasoned and thoughtful.  As I understand it, this document
is intended to prevent the situation that just occured, in which the IETF
published an RFC which detailed some changes to RSVP-TE (which had technical
issues) without any review by the CCAMP or MPLS working groups, thereby
explicitly appearing to endorse these changes.

The minutes of the Yokohama CCAMP meeting (see below) seem to indicate that
the CCAMP working group wanted to work on the ASON extensions, so I am still
puzzled as to why the authors of the ASON draft decided, after the Yokohama
meeting, to progress the draft as an informational RFC rather than as a
normal working group draft.

Thanks,

John

============================================================================
====================================
"Minute takers were volunteered (Josh Broch and Eric Gray) 

Snipped...

Osama Aboul-Magd presented status on his draft on ASON extensions to CR-LDP.

He asked if the WG would accept this as a WG draft. 

Kireeti pointed out that there is a meta discussion on the issue of
progressing both CR-LDP and RSVP-TE in the MPLS working group tomorrow and
suggested that the discussion should be taken to the mailing list after that
has been addressed. 

Snipped...

Dimitri Papadimitriou discussed work on ASON extensions to RSVP-TE. He asked
if the WG believes this to be valuable work and should eventually be put
forward to the ITU. 

Kireeti talked about the need to work out the relationship with the ITU on
these issues. 

Choy asked why the work does nt include call/connection information. 

Kireeti said that the functional specification should first capture the
solution independent requirements. 

Stephen Trowbridge asked what further information the IETF requires. 

Dimitri and Kireeti answered the question in detail."
============================================================================
====================================

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 12:57 AM
> To: Stephen Trowbridge
> Cc: [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Hi Steve,
> 
> On Wed, 26 Feb 2003, Stephen Trowbridge wrote:
> 
> > However, as Deborah, Kireeti, and Scott
> > have observed, the way it is written it seems to hinder rather than
> > help the process of collaborating with other Standards Developement
> > Organizations(SDOs)
> 
> If this is the impression that my comments gave, I must have used the
> wrong words.  The GMPLS change document is intended to help other SDOs
> understand the change process, and as such *help* collaboration.
> 
> > and doesn't provide a good way to deal with and respond
> > to liaison statements, which is the avenue by which many of these
> > requests will arrive from other SDOs.
> 
> This I agree with.  But as Loa pointed out, it was not the intent of
> the gmpls change doc to address this issue -- that is the domain of
> a different document; and as several people have pointed out by now,
> the change document is very specific (a small set of WGs), whereas
> a liaison document should probably be much broader (IETF-wide).
> 
> > The document as
> > written creates impediments to the ability to apply, and extend as
> > necessary, these protocols to new problem spaces.
> 
> I don't see this at all.  The IETF does have processes, for example,
> RFC 2026.  So (I assume) does the ITU.  Most would consider writing
> down a process for change, especially with the intent of maintaining
> architectural soundness, a Good Thing, not an impediment.  Process
> does on occasion slow things down.  Sometimes that is laudable --
> deliberation vs haste; sometimes that is a price one pays in return
> for avoiding chaos.  It takes longer for me to hang up my 
> clothes rather
> than throw them on the floor -- but I opt to hang them up.
> 
> > As noted, biggest flaw seems to be the way in which the 
> document deals
> > with new applications or requirements identified by 
> external standards
> > organizations. In addition to not recognizing that this 
> information may
> > come to IETF via liaison statements,
> 
> Let's take these one at a time.  A liaison statement (LS) has not been
> heretofore a replacement for an ID.  A LS of the form "we invite you
> to take part in such-and-such meeting" or "we would like to bring to
> your attention such-and-such work" are fine uses (in my opinion) for
> LSs.  However, if an SDO thinks that x, y and z are requirements for
> protocol foo, communicating this solely via a liaison statement is not
> (again, IMO) the right approach.  Requirements need to be discussed,
> possibly modified, and captured in some permanent form.  There is a
> well established process in the IETF for that; introducing a new
> vehicle for that process is neither necessary nor appropriate, at
> least without a revision of 2026 that states this.  It is not the
> intent of the gmpls change process to at the same time change the
> IETF's process and to update 2026.
> 
> > the document seems not to consider
> > the fact that there may be a valid application that is 
> outside of the
> > scope of IETF (and in the scope of another standards development
> > organization) to which the (G)MPLS protocols may be applied, and for
> > which the (G)MPLS protocols may require extension.
> 
> Not at all true.
> 
> > By insisting that
> > every possible extension be done internally in IETF, the IETF either
> > (1) Extends the scope of its work without bound; or (2) Needlessly
> > restricts the application of its protocols. Neither one of these is
> > good for IETF or for the Standards Development community at large.
> 
> The reason for insisting that extensions be done in the IETF is:
> (a) the IETF developed the protocols, knows them best, and knows the
>     bigger architectural picture in which they fit.  A good example
>     is the (unnecessary) deprecation of RSVP messages in a recent RFC.
> (b) when all is said and done, the IETF does own the protocols.
> 
> It is instructive to harken back to how CCAMP took extraordinary pains
> *not* to change the SDH spec, nor even to give the impression 
> of such a
> change.  There was a clear recognition that SDH "belonged" to the ITU,
> and when representatives felt that there was "intrusion", even if
> unintended, CCAMP stepped back.  There were two reasons for this: we
> recognized that we (as an SDO, not as individuals) didn't have the
> expertise; and we wanted to maintain cordial relations.
> 
> > One reality that this draft fails to recognize is that, 
> while IETF may
> > be able to say "no" to standardizing something proposed by 
> an individual,
> > it does not have the ability (or the right) to say "no" to something
> > proposed by another Standards Development Organization. As 
> a practical
> > matter, the IETF is not the only place where something can 
> be standardized.
> 
> I agree that the IETF cannot stop other SDOs from extending its
> protocols; it can (I believe) insist that such modified 
> protocols use a
> new name to call out the differences.
> 
> However, the problem that the change document addresses is not what
> other SDOs are doing, but what the IETF should be doing.  As far as
> other SDOs are concerned, they can decide on their own to abide by
> the IETF's rules if they want, or to forge ahead on their own, at
> the risk (which they may consider worthwhile) of marring 
> their relations
> with the IETF.
> 
> > If the IETF creates impediments to applying IETF protocols to
> > the application space of another standards development organization,
> > there is really nothing that the IETF can do to prevent 
> that the other
> > organization standardizes something themselves. The result 
> would tend
> > to be a proliferation of (G)MPLS "like" protocols instead 
> of a coherent
> > suite of protocols with broad applicability. This result 
> would not be
> > good for the IETF or the industry in general.
> 
> There is already a proliferation of GMPLS like protocols.  The OIF
> has its own; the ITU is developing its own.  It is not the intention
> of the change document to stop this, nor to create impediments.  But
> there is the (fond!) hope that with such a change document in place,
> other SDOs will say -- "hey, instead of changing the 
> protocols ourselves,
> there is this process whereby we can take our requirements to the IETF
> and get the experts who really know that protocol to change it to meet
> our needs."
> 
> > A better approach would be for the IETF to PROMOTE the use of its
> > protocols for new applications
> 
> Far be it for me to say what the IETF should or should not 
> do.  However,
> I personally don't think the IETF should promote its 
> protocols.  In the
> final analysis, the IETF is concerned with running (and promoting) the
> Internet.  Any protocols it designs should have that as the end goal.
> 
> > and, when another Standards Development
> > Organization wishes to apply (G)MPLS protocols to an 
> application domain
> > outside of the scope of IETF, that IETF will (1) assist 
> with the development
> > of any necessary extensions; and (2) to facilitate documentation of
> > such new applications and extensions in a central place (e.g., by
> > informational RFC, even for extensions that are developed outside of
> > IETF) and to insure that code points are assigned in a 
> coherent manner
> > through IANA to avoid collisions where different extensions may use
> > the same code points to indicate different things.
> 
> If the IETF is convinced that such extensions will in some way help
> to achieve its own goals AND will not hurt the protocol, the IETF can
> and should undertake the activity.  If the extensions do not match
> the IETF's goals, but they don't hurt the protocol, there should be
> a way (such as Bob Braden's SPIFFY_ITU_... idea) for the IETF to
> yield the floor to some other SDO.
> 
> > The difference in flavor for what I am proposing is that IETF should
> > try to position itself as a Clearinghouse for (G)MPLS 
> protocol extensions
> > rather than as a Gatekeeper for (G)MPLS protcol extensions.
> 
> The Gatekeeper function is for the case where the said extensions do
> hurt the protocol (in the eyes of the IETF).  This is where the SDO
> can decide, as you point out, that it can do it on its own, but
> changes the name of the protocol so that innocent bystanders can tell
> the difference.
> 
> Kireeti.
> 

Delivery-date: Thu, 27 Feb 2003 09:33:19 -0800
Date: Thu, 27 Feb 2003 12:32:25 -0500
From: George Newsome <[email-masked]>
To: Malcolm Betts <[email-masked]>, Stephen Trowbridge <[email-masked]>
CC: 'Loa Andersson' <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Malcolm Betts wrote:

> 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. 
> .........

It seems to me that Malcolm and Monica's remarks, and Steve's 
suggestions to improve the usefulness of the document are all heading in 
the right direction.

I would have thought that the IETF understands very well how to make 
changes to its documents, so a new document discussing that aspect seems 
to have little use.

On the other hand, Loa suggested earlier that the liaison process is not 
well understood, so a document describing how the interaction between 
SDO's can work seems very relevant.

It is difficult or impossible to separate out the fact that other SDO's 
are not individuals, and that formal communications (liaison's) are how 
other SDO's communicate with each other. Steve's suggested changes 
address both of these facts, and are thus helpful.

George

Delivery-date: Thu, 27 Feb 2003 09:32:23 -0800
From: "Ong, Lyndon" <[email-masked]>
To: 'Loa Andersson' <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, Kireeti Kompella <[email-masked]>, Scott W Brim <[email-masked]>,  [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 09:31:12 -0800

Hi,

Can I ask a clarifying question regarding liaisons?  The
issue revolves around making extensions to GMPLS.  Is
it the view that such extensions must be generated 
through Internet Drafts, and cannot be through
liaisons?

It sounds like people may be assuming that liaisons are
always providing background information or requesting
information, when on occasion a liaison may be requesting
a change or action.

BTW, regarding responses to liaisons, the A-D may or may
not be the proper source for a response, but the knowledge
for putting together the response would typically reside
within a particular WG, I believe.  One problem is that
you don't have the time within an IETF meeting to assign
a "stuckie" (to use the new term) to write a response ;o)

Cheers,

Lyndon

Delivery-date: Thu, 27 Feb 2003 09:25:58 -0800
Date: Thu, 27 Feb 2003 12:25:16 -0500
From: Scott W Brim <[email-masked]>
To: Loa Andersson <[email-masked]>
Cc: "Brungard, Deborah A, ALABS" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Mail-Followup-To: Scott W Brim <[email-masked]>, Loa Andersson <[email-masked]>, "Brungard, Deborah A, ALABS" <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]

Loa,

On Thu, Feb 27, 2003 05:58:40PM +0100, Loa Andersson allegedly wrote:
> It needs to be understood that the internal IETF process is specified
> for IDs, and in some way we need bridge that gap. IETF and its working
> groups modifies IDs, and I don't think it is good idea to start
> modifying liasions from other SDOs.

But

> Brungard, Deborah A, ALABS wrote:
> >One comment on all of this from an ITU/T1X1 history, it is difficult
> >to say apriori how a liaison will be processed. We do not have such a
> >process either. Several ways exist to respond:
> >1. simple thank you for the information
> >2. here's the answer/clarification based on current work
> >3. for a quick answer, at the meeting, have a breakout group to
> >   address a proposal
> >4. for new work, send a response saying we invite contributions to
> >   our future meetings to progress
> >  - if no contributions, not anything is done (yes we have done this
> >    too)
> >  - at the next meeting, send several proposals to the other group
> >    for their review

There is no incompatibility.  Among a rich set of possible responses,
bullet 4 covers what you were looking for above.

Delivery-date: Thu, 27 Feb 2003 09:22:55 -0800
From: "Varma, Eve L (Eve)" <[email-masked]>
To: "Betts, Malcolm [SKY:Q870:EXCH]" <[email-masked]>, Loa Andersson <[email-masked]>
Cc: Stephen Trowbridge <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 12:21:57 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2DE84.BB433B30
Content-Type: text/plain;
	charset="iso-8859-1"

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:[email-masked]]
Sent: Thursday, February 27, 2003 8:11 AM
To: 'Loa Andersson'
Cc: Stephen Trowbridge; Kireeti Kompella; [email-masked]; [email-masked]
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: [email-masked] 
 
-----Original Message----- 
From: Loa Andersson [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Thursday, February 27, 2003 7:33 AM 
To: Kireeti Kompella 
Cc: Stephen Trowbridge; [email-masked]; [email-masked] 
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> 

------_=_NextPart_001_01C2DE84.BB433B30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt</TITLE>

<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"cid:[email-masked]" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@font-face {
	font-family: Times;
}
@font-face {
	font-family: Helvetica;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; =
mso-header-margin: .5in; mso-footer-margin: .5in; mso-paper-source: 0; =
}
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
H1 {
	FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt; TEXT-INDENT: =
0in; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; mso-pagination: =
widow-orphan; mso-style-next: Normal; mso-outline-level: 1; tab-stops: =
list .25in; mso-bidi-font-family: "Times New Roman"; mso-font-kerning: =
14.0pt; mso-bidi-font-weight: normal
}
H2 {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt; TEXT-INDENT: =
0in; FONT-STYLE: italic; FONT-FAMILY: Arial; mso-pagination: =
widow-orphan; mso-style-next: Normal; mso-outline-level: 2; tab-stops: =
list .25in; mso-bidi-font-family: "Times New Roman"; =
mso-bidi-font-weight: normal; mso-style-update: auto; =
mso-bidi-font-style: normal
}
H3 {
	FONT-WEIGHT: normal; FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt; =
TEXT-INDENT: 0in; FONT-FAMILY: Arial; mso-pagination: widow-orphan; =
mso-style-next: Normal; mso-outline-level: 3; tab-stops: list .25in; =
mso-bidi-font-family: "Times New Roman"; mso-style-update: auto
}
H4 {
	FONT-WEIGHT: normal; FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt; =
TEXT-INDENT: 0in; FONT-FAMILY: Helvetica; mso-pagination: widow-orphan; =
mso-style-next: Normal; mso-outline-level: 4; tab-stops: list .25in; =
mso-bidi-font-family: "Times New Roman"; mso-style-update: auto
}
H5 {
	FONT-WEIGHT: normal; FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt; =
TEXT-INDENT: 0in; FONT-FAMILY: "Times New Roman"; mso-pagination: =
widow-orphan; mso-style-next: Normal; mso-outline-level: 5; tab-stops: =
list .25in
}
H6 {
	FONT-WEIGHT: normal; FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt; =
FONT-STYLE: italic; FONT-FAMILY: "Times New Roman"; mso-pagination: =
widow-orphan; mso-style-next: Normal; mso-outline-level: 6; =
mso-bidi-font-style: normal
}
P.MsoHeading7 {
	FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: Arial; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-style-next: Normal; mso-outline-level: 7; =
mso-bidi-font-family: "Times New Roman"
}
LI.MsoHeading7 {
	FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: Arial; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-style-next: Normal; mso-outline-level: 7; =
mso-bidi-font-family: "Times New Roman"
}
DIV.MsoHeading7 {
	FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: Arial; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-style-next: Normal; mso-outline-level: 7; =
mso-bidi-font-family: "Times New Roman"
}
P.MsoHeading8 {
	FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt; FONT-STYLE: italic; =
FONT-FAMILY: Arial; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-next: Normal; =
mso-outline-level: 8; mso-bidi-font-family: "Times New Roman"; =
mso-bidi-font-style: normal
}
LI.MsoHeading8 {
	FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt; FONT-STYLE: italic; =
FONT-FAMILY: Arial; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-next: Normal; =
mso-outline-level: 8; mso-bidi-font-family: "Times New Roman"; =
mso-bidi-font-style: normal
}
DIV.MsoHeading8 {
	FONT-SIZE: 12pt; MARGIN: 12pt 0in 3pt; FONT-STYLE: italic; =
FONT-FAMILY: Arial; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-next: Normal; =
mso-outline-level: 8; mso-bidi-font-family: "Times New Roman"; =
mso-bidi-font-style: normal
}
P.MsoHeading9 {
	FONT-WEIGHT: bold; FONT-SIZE: 9pt; MARGIN: 12pt 0in 3pt; FONT-STYLE: =
italic; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-style-next: Normal; mso-outline-level: 9; mso-bidi-font-family: =
"Times New Roman"; mso-bidi-font-weight: normal; mso-bidi-font-style: =
normal
}
LI.MsoHeading9 {
	FONT-WEIGHT: bold; FONT-SIZE: 9pt; MARGIN: 12pt 0in 3pt; FONT-STYLE: =
italic; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-style-next: Normal; mso-outline-level: 9; mso-bidi-font-family: =
"Times New Roman"; mso-bidi-font-weight: normal; mso-bidi-font-style: =
normal
}
DIV.MsoHeading9 {
	FONT-WEIGHT: bold; FONT-SIZE: 9pt; MARGIN: 12pt 0in 3pt; FONT-STYLE: =
italic; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-style-next: Normal; mso-outline-level: 9; mso-bidi-font-family: =
"Times New Roman"; mso-bidi-font-weight: normal; mso-bidi-font-style: =
normal
}
P.MsoIndex1 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 12pt; TEXT-INDENT: -12pt; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-next: Normal; =
mso-style-update: auto
}
LI.MsoIndex1 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 12pt; TEXT-INDENT: -12pt; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-next: Normal; =
mso-style-update: auto
}
DIV.MsoIndex1 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 12pt; TEXT-INDENT: -12pt; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-next: Normal; =
mso-style-update: auto
}
P.MsoFootnoteText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
LI.MsoFootnoteText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
DIV.MsoFootnoteText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
P.MsoCommentText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: Times
}
LI.MsoCommentText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: Times
}
DIV.MsoCommentText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: Times
}
P.MsoHeader {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; tab-stops: center 3.0in right 6.0in
}
LI.MsoHeader {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; tab-stops: center 3.0in right 6.0in
}
DIV.MsoHeader {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; tab-stops: center 3.0in right 6.0in
}
P.MsoFooter {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; tab-stops: center 3.0in right 6.0in
}
LI.MsoFooter {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; tab-stops: center 3.0in right 6.0in
}
DIV.MsoFooter {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; tab-stops: center 3.0in right 6.0in
}
P.MsoCaption {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 6pt 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-next: Normal; =
mso-bidi-font-weight: normal
}
LI.MsoCaption {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 6pt 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-next: Normal; =
mso-bidi-font-weight: normal
}
DIV.MsoCaption {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 6pt 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-style-next: Normal; =
mso-bidi-font-weight: normal
}
SPAN.MsoFootnoteReference {
	VERTICAL-ALIGN: super
}
SPAN.MsoCommentReference {
	mso-ansi-font-size: 8.0pt
}
P.MsoList {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoList {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoList {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: -0.25in; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
P.MsoList2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoList2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoList2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.5in; TEXT-INDENT: -0.25in; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
P.MsoListBullet2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in; =
mso-style-update: auto
}
LI.MsoListBullet2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in; =
mso-style-update: auto
}
DIV.MsoListBullet2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in; =
mso-style-update: auto
}
P.MsoListNumber2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in left =
1.0in 1.5in 2.0in 2.5in 3.0in 3.5in
}
LI.MsoListNumber2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in left =
1.0in 1.5in 2.0in 2.5in 3.0in 3.5in
}
DIV.MsoListNumber2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in left =
1.0in 1.5in 2.0in 2.5in 3.0in 3.5in
}
P.MsoListNumber3 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in left =
.5in 1.0in 1.5in 2.0in 2.5in 3.0in 3.5in
}
LI.MsoListNumber3 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in left =
.5in 1.0in 1.5in 2.0in 2.5in 3.0in 3.5in
}
DIV.MsoListNumber3 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in left =
.5in 1.0in 1.5in 2.0in 2.5in 3.0in 3.5in
}
P.MsoTitle {
	FONT-WEIGHT: bold; FONT-SIZE: 16pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: =
Arial; TEXT-ALIGN: center; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-outline-level: 1; =
mso-font-kerning: 14.0pt
}
LI.MsoTitle {
	FONT-WEIGHT: bold; FONT-SIZE: 16pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: =
Arial; TEXT-ALIGN: center; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-outline-level: 1; =
mso-font-kerning: 14.0pt
}
DIV.MsoTitle {
	FONT-WEIGHT: bold; FONT-SIZE: 16pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: =
Arial; TEXT-ALIGN: center; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-outline-level: 1; =
mso-font-kerning: 14.0pt
}
P.MsoBodyText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
TEXT-ALIGN: justify; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoBodyText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
TEXT-ALIGN: justify; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoBodyText {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
TEXT-ALIGN: justify; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
P.MsoBodyTextIndent {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Times New =
Roman"; mso-pagination: widow-orphan; mso-fareast-font-family: "Times =
New Roman"
}
LI.MsoBodyTextIndent {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Times New =
Roman"; mso-pagination: widow-orphan; mso-fareast-font-family: "Times =
New Roman"
}
DIV.MsoBodyTextIndent {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Times New =
Roman"; mso-pagination: widow-orphan; mso-fareast-font-family: "Times =
New Roman"
}
P.MsoListContinue {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.25in; FONT-FAMILY: Arial; =
TEXT-ALIGN: justify; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-bidi-font-family: =
"Times New Roman"
}
LI.MsoListContinue {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.25in; FONT-FAMILY: Arial; =
TEXT-ALIGN: justify; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-bidi-font-family: =
"Times New Roman"
}
DIV.MsoListContinue {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.25in; FONT-FAMILY: Arial; =
TEXT-ALIGN: justify; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-bidi-font-family: =
"Times New Roman"
}
P.MsoBodyText2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; LAYOUT-GRID-MODE: line; COLOR: =
black; FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoBodyText2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; LAYOUT-GRID-MODE: line; COLOR: =
black; FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoBodyText2 {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; LAYOUT-GRID-MODE: line; COLOR: =
black; FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
P.MsoBodyText3 {
	FONT-WEIGHT: bold; FONT-SIZE: 7pt; MARGIN: 0in 0in 0pt; =
LAYOUT-GRID-MODE: line; COLOR: black; FONT-FAMILY: "Times New Roman"; =
TEXT-ALIGN: justify; mso-bidi-font-size: 12.0pt; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-bidi-font-weight: normal
}
LI.MsoBodyText3 {
	FONT-WEIGHT: bold; FONT-SIZE: 7pt; MARGIN: 0in 0in 0pt; =
LAYOUT-GRID-MODE: line; COLOR: black; FONT-FAMILY: "Times New Roman"; =
TEXT-ALIGN: justify; mso-bidi-font-size: 12.0pt; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-bidi-font-weight: normal
}
DIV.MsoBodyText3 {
	FONT-WEIGHT: bold; FONT-SIZE: 7pt; MARGIN: 0in 0in 0pt; =
LAYOUT-GRID-MODE: line; COLOR: black; FONT-FAMILY: "Times New Roman"; =
TEXT-ALIGN: justify; mso-bidi-font-size: 12.0pt; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-bidi-font-weight: normal
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
P.MsoDocumentMap {
	FONT-SIZE: 12pt; BACKGROUND: navy; MARGIN: 0in 0in 0pt; FONT-FAMILY: =
Tahoma; mso-pagination: widow-orphan; mso-fareast-font-family: "Times =
New Roman"; mso-bidi-font-family: "Times New Roman"
}
LI.MsoDocumentMap {
	FONT-SIZE: 12pt; BACKGROUND: navy; MARGIN: 0in 0in 0pt; FONT-FAMILY: =
Tahoma; mso-pagination: widow-orphan; mso-fareast-font-family: "Times =
New Roman"; mso-bidi-font-family: "Times New Roman"
}
DIV.MsoDocumentMap {
	FONT-SIZE: 12pt; BACKGROUND: navy; MARGIN: 0in 0in 0pt; FONT-FAMILY: =
Tahoma; mso-pagination: widow-orphan; mso-fareast-font-family: "Times =
New Roman"; mso-bidi-font-family: "Times New Roman"
}
P.MsoPlainText {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: =
"Courier New"; mso-pagination: widow-orphan; mso-fareast-font-family: =
"Times New Roman"; mso-bidi-font-family: "Times New Roman"; =
mso-font-kerning: 14.0pt; mso-bidi-font-weight: normal
}
LI.MsoPlainText {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: =
"Courier New"; mso-pagination: widow-orphan; mso-fareast-font-family: =
"Times New Roman"; mso-bidi-font-family: "Times New Roman"; =
mso-font-kerning: 14.0pt; mso-bidi-font-weight: normal
}
DIV.MsoPlainText {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: =
"Courier New"; mso-pagination: widow-orphan; mso-fareast-font-family: =
"Times New Roman"; mso-bidi-font-family: "Times New Roman"; =
mso-font-kerning: 14.0pt; mso-bidi-font-weight: normal
}
P.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
SPAN.EmailStyle16 {
	COLOR: navy; mso-bidi-font-family: Arial; mso-ansi-font-size: 10.0pt; =
mso-style-type: personal-reply; mso-ascii-font-family: Arial; =
mso-hansi-font-family: Arial
}
P.Appendix {
	FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt 0.3in; =
TEXT-INDENT: -0.3in; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; =
mso-style-parent: "Heading 1,1,h1,1st level,I1,heading 1,Chapter =
title,l1,l1+toc 1,Level 1,Level 11,AboutDocument"; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-style-next: Normal; mso-outline-level: 1; tab-stops: list .3in; =
mso-bidi-font-family: "Times New Roman"; mso-font-kerning: 14.0pt; =
mso-bidi-font-weight: normal; mso-style-name: Appendix
}
LI.Appendix {
	FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt 0.3in; =
TEXT-INDENT: -0.3in; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; =
mso-style-parent: "Heading 1,1,h1,1st level,I1,heading 1,Chapter =
title,l1,l1+toc 1,Level 1,Level 11,AboutDocument"; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-style-next: Normal; mso-outline-level: 1; tab-stops: list .3in; =
mso-bidi-font-family: "Times New Roman"; mso-font-kerning: 14.0pt; =
mso-bidi-font-weight: normal; mso-style-name: Appendix
}
DIV.Appendix {
	FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt 0.3in; =
TEXT-INDENT: -0.3in; FONT-FAMILY: Arial; mso-bidi-font-size: 12.0pt; =
mso-style-parent: "Heading 1,1,h1,1st level,I1,heading 1,Chapter =
title,l1,l1+toc 1,Level 1,Level 11,AboutDocument"; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-style-next: Normal; mso-outline-level: 1; tab-stops: list .3in; =
mso-bidi-font-family: "Times New Roman"; mso-font-kerning: 14.0pt; =
mso-bidi-font-weight: normal; mso-style-name: Appendix
}
P.Bodytext {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan lines-together; mso-fareast-font-family: =
"Times New Roman"; tab-stops: 45.0pt 73.0pt 102.0pt; mso-style-name: =
"Body text"
}
LI.Bodytext {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan lines-together; mso-fareast-font-family: =
"Times New Roman"; tab-stops: 45.0pt 73.0pt 102.0pt; mso-style-name: =
"Body text"
}
DIV.Bodytext {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan lines-together; mso-fareast-font-family: =
"Times New Roman"; tab-stops: 45.0pt 73.0pt 102.0pt; mso-style-name: =
"Body text"
}
P.Reference {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; TEXT-ALIGN: justify; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in; =
mso-style-name: Reference
}
LI.Reference {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; TEXT-ALIGN: justify; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in; =
mso-style-name: Reference
}
DIV.Reference {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; FONT-FAMILY: =
"Times New Roman"; TEXT-ALIGN: justify; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; tab-stops: list .25in; =
mso-style-name: Reference
}
P.Requirement {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: 0in; =
FONT-STYLE: italic; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: =
justify; mso-style-parent: "List Continue"; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; tab-stops: =
list .25in; mso-bidi-font-style: normal; mso-style-name: Requirement
}
LI.Requirement {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: 0in; =
FONT-STYLE: italic; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: =
justify; mso-style-parent: "List Continue"; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; tab-stops: =
list .25in; mso-bidi-font-style: normal; mso-style-name: Requirement
}
DIV.Requirement {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt 0.25in; TEXT-INDENT: 0in; =
FONT-STYLE: italic; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: =
justify; mso-style-parent: "List Continue"; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; tab-stops: =
list .25in; mso-bidi-font-style: normal; mso-style-name: Requirement
}
P.Ednote {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: blue; =
FONT-STYLE: italic; FONT-FAMILY: "Times New Roman"; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-bidi-font-weight: normal; mso-style-update: auto; =
mso-bidi-font-style: normal; mso-style-name: "Ed note"
}
LI.Ednote {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: blue; =
FONT-STYLE: italic; FONT-FAMILY: "Times New Roman"; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-bidi-font-weight: normal; mso-style-update: auto; =
mso-bidi-font-style: normal; mso-style-name: "Ed note"
}
DIV.Ednote {
	FONT-WEIGHT: bold; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; COLOR: blue; =
FONT-STYLE: italic; FONT-FAMILY: "Times New Roman"; mso-pagination: =
widow-orphan; mso-fareast-font-family: "Times New Roman"; =
mso-bidi-font-weight: normal; mso-style-update: auto; =
mso-bidi-font-style: normal; mso-style-name: "Ed note"
}
P.Requirementlist {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; LAYOUT-GRID-MODE: line; =
TEXT-INDENT: 0in; FONT-FAMILY: "Times New Roman"; mso-pagination: =
widow-orphan lines-together; mso-fareast-font-family: "Times New =
Roman"; tab-stops: list .25in; mso-style-name: "Requirement list"
}
LI.Requirementlist {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; LAYOUT-GRID-MODE: line; =
TEXT-INDENT: 0in; FONT-FAMILY: "Times New Roman"; mso-pagination: =
widow-orphan lines-together; mso-fareast-font-family: "Times New =
Roman"; tab-stops: list .25in; mso-style-name: "Requirement list"
}
DIV.Requirementlist {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; LAYOUT-GRID-MODE: line; =
TEXT-INDENT: 0in; FONT-FAMILY: "Times New Roman"; mso-pagination: =
widow-orphan lines-together; mso-fareast-font-family: "Times New =
Roman"; tab-stops: list .25in; mso-style-name: "Requirement list"
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: .5in" vLink=3Dblue =
link=3Dblue>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D436150417-27022003>Just=20
putting in my two cents.&nbsp; I'd like to support aspects of the =
liaison=20
process being included in the draft.&nbsp; Given the close coupling =
between=20
the</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D436150417-27022003>change=20
and liaison processes, and </SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><SPAN class=3D436150417-27022003>the issues that triggered =
generation of=20
the draft, I believe we should bite the bullet and work to establish a =
cohesive=20
process now.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D436150417-27022003>It=20
will be well worth the effort.&nbsp;&nbsp;In my view,&nbsp;not =
expending=20
the&nbsp;time now will result in&nbsp;far more time spent=20
later.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D436150417-27022003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D436150417-27022003>I'd=20
also like to express support for the&nbsp;proposed =
revisions&nbsp;provided by=20
Steve Trowbridge,&nbsp;&nbsp;as&nbsp;I believe they increase the value =
of the=20
draft by&nbsp;adding necessary clarifications and promoting a =
cooperative spirit=20
to the entire endeavor.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D436150417-27022003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D436150417-27022003>Eve=20
Varma</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D436150417-27022003></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><![if =
!supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><!--[if supportFields]><span =
class=3DEmailStyle16><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font></span><![end=
if]--><!--[if supportFields]><span class=3DEmailStyle16><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]-->=
<SPAN=20
  class=3DEmailStyle16><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-bidi-font-size: =
12.0pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></SPAN></DI=
V>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DTahoma color=3Dblack size=3D2><SPAN =

  style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: =
Tahoma">-----Original=20
  Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: bold">From:</SPAN></B> =
Malcolm=20
  Betts [mailto:[email-masked]]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, February 27, =
2003 8:11=20
  AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> 'Loa=20
  Andersson'<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> =
Stephen=20
  Trowbridge; Kireeti Kompella; [email-masked]; =
[email-masked]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: I-D=20
  ACTION:draft-andersson-mpls-g-chng-proc-00.txt</SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><![if =
!supportEmptyParas]><![endif]>&nbsp;<o:p></o:p></SPAN></FONT></P>
  <P><FONT face=3D"Times New Roman" color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Loa, the from the outside =
looking in the=20
  liaison process and the change process are closely coupled.&nbsp; The =
liaison=20
  process is described in ITU-T Recommendation A.4 and A.5 and in RFC=20
  3356.&nbsp; </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P><FONT face=3D"Times New Roman" color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">The coupling occurs because =
the ITU uses=20
  the agreed liaison process to communicate requests to modify IETF =
protocols=20
  based on requirements agreed by the members of the Study Group (that=20
  originated the liaison).&nbsp; The change process being proposed =
requires that=20
  this official request from a SDO is converted into an individuals =
ID.&nbsp;=20
  The level of agreement in the SDO is therefore obscured, this process =
appears=20
  to be in conflict with RFC 3356.&nbsp; The problem is particularly =
acute when=20
  the requirements are to enable (or enhance) the management of a non =
IP network=20
  to support a non IP client.&nbsp; If my understanding of the draft is =
correct=20
  such requests would be rejected by the IETF.</SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P><FONT face=3D"Times New Roman" color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">It is clearly beneficial to =
the industry=20
  if the basic IETF protocols can be extended to address such=20
  applications.&nbsp; The IETF plays a key role in ensuring that the =
integrity=20
  of the base protocols is not compromised.</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P><FONT face=3D"Times New Roman" color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Malcolm =
Betts</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P><FONT face=3D"Times New Roman" color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Phone: +1 613 763 7860 (ESN=20
  393)</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">FAX:&nbsp;&nbsp; +1 613 763 =
6608 (ESN=20
  393)</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">email:=20
  [email-masked]</SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"> </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt; COLOR: black"><![if =
!supportEmptyParas]><![endif]>&nbsp;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P><FONT face=3D"Times New Roman" color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">-----Original=20
  Message-----</SPAN></FONT><FONT color=3Dblack><SPAN style=3D"COLOR: =
black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">From: Loa Andersson [<A=20
  href=3D"mailto:[email-masked]">mailto:[email-masked]</A>] </SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"><BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">Sent: =
Thursday, February=20
  27, 2003 7:33 AM</SPAN></FONT><FONT color=3Dblack><SPAN =
style=3D"COLOR: black">=20
  <BR></SPAN></FONT><FONT color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">To: Kireeti =
Kompella</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: black">Cc: Stephen =
Trowbridge;=20
  [email-masked]; [email-masked]</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black"> <BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">Subject: Re: I-D=20
  ACTION:draft-andersson-mpls-g-chng-proc-00.txt</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> <BR></SPAN></FONT><FONT =
color=3Dblack=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">&lt;snip&gt;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P><FONT face=3D"Times New Roman" color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">I think I've clearly pointed =
out the=20
  limited scope of the change process, recognized that there is a =
orthogonal=20
  problem on how we treats liasions coming into the ietf, that the =
liasion=20
  process needs to be documented, and that we will add text to address =
the=20
  limited intersection of the change-process and liasion process in =
order to=20
  promote the cooperation with other SDOs.</SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P><FONT face=3D"Times New Roman" color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: black">/Loa</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P><FONT face=3D"Times New Roman" color=3Dblack size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: =
black">&lt;snip&gt;</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTM=
L>

------_=_NextPart_001_01C2DE84.BB433B30--

Delivery-date: Thu, 27 Feb 2003 09:05:29 -0800
Date: Thu, 27 Feb 2003 17:58:40 +0100
From: Loa Andersson <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
CC: "Wijnen, Bert (Bert)" <[email-masked]>, Kireeti Kompella <[email-masked]>, Scott W Brim <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Deborah,

I suggested earlier that we describe (short) in the draft how we will 
handle liasions
comeing into the IETF with request for changes or requirments related to 
the (g)mpls
protocols. It needs to be understood that the internal IETF process is 
specified for
IDs, and in some way we need bridge that gap. IETF and its working 
groups modifies IDs,
and I don't think it is good idea to start modifying liasions from other 
SDOs.

That we define the liasion process so it becoes crips and clear, and if 
when we are doing
find that it has an impact on the change process, we updte or 
re-organize the the
documents at that time.

Would that work? I guess that the answer is - yes, but only as much 
(little) as needed.

/Loa

Brungard, Deborah A, ALABS wrote:

>Maybe lets go back to my hopefully simple question, will the liaison process be included in this draft or not? I (thought) the answer was no. Maybe best to clarify. And not that it is not important, all the mail agrees it is important. Then we can work from this draft with comments, recognizing the liaison process will be separate, e.g. where the draft discusses other sdos, we can add text to clarify.
>
>One comment on all of this from an ITU/T1X1 history, it is difficult to say apriori how a liaison will be processed. We do not have such a process either. Several ways exist to respond:
>1. simple thank you for the information
>2. here's the answer/clarification based on current work
>3. for a quick answer, at the meeting, have a breakout group to address a proposal
>4. for new work, send a response saying we invite contributions to our future meetings to progress
>   - if no contributions, not anything is done (yes we have done this too)
>   - at the next meeting, send several proposals to the other group for their review
>
>I had understood this draft as including option 4. Other mails are raising the concern, as in the past, if no response to the other sdo, the other sdo can not determine the status of the work. That can be part of the liaison process.
>
>Let's first clarify, do we want this draft to include the liaison process or should we do it separate (in parallel?)?
>
>Deborah
>
>
>
>-----Original Message-----
>From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>Sent: Thursday, February 27, 2003 10:47 AM
>To: Kireeti Kompella; Wijnen, Bert (Bert)
>Cc: Scott W Brim; [email-masked]; [email-masked]
>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>
>
>Inline
>
>  
>
>>-----Original Message-----
>>From: Kireeti Kompella [mailto:[email-masked]]
>>Sent: donderdag 27 februari 2003 10:09
>>To: Wijnen, Bert (Bert)
>>Cc: Scott W Brim; [email-masked]; [email-masked]
>>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>>
>>
>>Hi Bert,
>>
>>On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote:
>>
>>    
>>
>>>No of course NOT. Many Liasons will want an answer.
>>>So we need a process to follow up and to track if a timely
>>>response has been (or will be) send.
>>>      
>>>
>>Is the IETF process for replying to liaison statements (and of
>>generating them) written down, say in some RFC?  If so, could you
>>send me a pointer?
>>
>>    
>>
>Unfortunately, I don't think the process for that has been defined.
>That is why I said that "we need a process..."
>We do not have it yet (I think... at least I do not know it either).
>I think we were all just hoping people would take responsibility and
>do the right things... but as we know that is how things fall through
>the cracks.
>
>  
>
>>>But the Liasons communication between ITU and CCAMP/MPLS has not
>>>been going smoothly so far (even though we had good intentions).
>>>Responses have not gone out in time (or in some cases at all).
>>>      
>>>
>>I'll take full responsibility for that.
>>
>>    
>>
>W.r.t. CCAMP I will share some of the responsibility too. I should 
>also have kept a better eye on it.
>
>Bert
>  
>
>>Thanks,
>>Kireeti.
>>
>>    
>>
>
>
>
>
>  
>

Delivery-date: Thu, 27 Feb 2003 08:17:35 -0800
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 11:14:28 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>, "Kireeti Kompella" <[email-masked]>
Cc: "Scott W Brim" <[email-masked]>, <[email-masked]>, <[email-masked]>

Maybe lets go back to my hopefully simple question, will the liaison =
process be included in this draft or not? I (thought) the answer was no. =
Maybe best to clarify. And not that it is not important, all the mail =
agrees it is important. Then we can work from this draft with comments, =
recognizing the liaison process will be separate, e.g. where the draft =
discusses other sdos, we can add text to clarify.

One comment on all of this from an ITU/T1X1 history, it is difficult to =
say apriori how a liaison will be processed. We do not have such a =
process either. Several ways exist to respond:
1. simple thank you for the information
2. here's the answer/clarification based on current work
3. for a quick answer, at the meeting, have a breakout group to address =
a proposal
4. for new work, send a response saying we invite contributions to our =
future meetings to progress
   - if no contributions, not anything is done (yes we have done this =
too)
   - at the next meeting, send several proposals to the other group for =
their review

I had understood this draft as including option 4. Other mails are =
raising the concern, as in the past, if no response to the other sdo, =
the other sdo can not determine the status of the work. That can be part =
of the liaison process.

Let's first clarify, do we want this draft to include the liaison =
process or should we do it separate (in parallel?)?

Deborah

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 10:47 AM
To: Kireeti Kompella; Wijnen, Bert (Bert)
Cc: Scott W Brim; [email-masked]; [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Inline

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: donderdag 27 februari 2003 10:09
> To: Wijnen, Bert (Bert)
> Cc: Scott W Brim; [email-masked]; [email-masked]
> Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
>=20
>=20
> Hi Bert,
>=20
> On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote:
>=20
> > No of course NOT. Many Liasons will want an answer.
> > So we need a process to follow up and to track if a timely
> > response has been (or will be) send.
>=20
> Is the IETF process for replying to liaison statements (and of
> generating them) written down, say in some RFC?  If so, could you
> send me a pointer?
>=20
Unfortunately, I don't think the process for that has been defined.
That is why I said that "we need a process..."
We do not have it yet (I think... at least I do not know it either).
I think we were all just hoping people would take responsibility and
do the right things... but as we know that is how things fall through
the cracks.

> > But the Liasons communication between ITU and CCAMP/MPLS has not
> > been going smoothly so far (even though we had good intentions).
> > Responses have not gone out in time (or in some cases at all).
>=20
> I'll take full responsibility for that.
>=20
W.r.t. CCAMP I will share some of the responsibility too. I should=20
also have kept a better eye on it.

Bert
> Thanks,
> Kireeti.
>=20

Delivery-date: Thu, 27 Feb 2003 07:48:44 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Kireeti Kompella <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: Scott W Brim <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 16:46:56 +0100

Inline

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: donderdag 27 februari 2003 10:09
> To: Wijnen, Bert (Bert)
> Cc: Scott W Brim; [email-masked]; [email-masked]
> Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Hi Bert,
> 
> On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote:
> 
> > No of course NOT. Many Liasons will want an answer.
> > So we need a process to follow up and to track if a timely
> > response has been (or will be) send.
> 
> Is the IETF process for replying to liaison statements (and of
> generating them) written down, say in some RFC?  If so, could you
> send me a pointer?
> 
Unfortunately, I don't think the process for that has been defined.
That is why I said that "we need a process..."
We do not have it yet (I think... at least I do not know it either).
I think we were all just hoping people would take responsibility and
do the right things... but as we know that is how things fall through
the cracks.

> > But the Liasons communication between ITU and CCAMP/MPLS has not
> > been going smoothly so far (even though we had good intentions).
> > Responses have not gone out in time (or in some cases at all).
> 
> I'll take full responsibility for that.
> 
W.r.t. CCAMP I will share some of the responsibility too. I should 
also have kept a better eye on it.

Bert
> Thanks,
> Kireeti.
> 

Delivery-date: Thu, 27 Feb 2003 05:23:23 -0800
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 08:22:31 -0500
From: "Lazer, Monica A, ALABS" <[email-masked]>
To: "Malcolm Betts" <[email-masked]>, "Loa Andersson" <[email-masked]>
Cc: "Stephen Trowbridge" <[email-masked]>, "Kireeti Kompella" <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C2DE63.4810FA95
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Loa, Kireeti,
I agree with Malcolm.=20
Since this draft proposes a process change specifically dealing with
requirements and problem statements, and since ITU uses the liaison
process for this reason, the liaison process is very relevant to the
changes proposed in this draft, and it is not an orthogonal problem.
=20
=20
Monica A. Lazer
Network Architecture and Reliability
=20
908 234 8462
[email-masked]
=20
-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 8:11 AM
To: 'Loa Andersson'
Cc: Stephen Trowbridge; Kireeti Kompella; [email-masked];
[email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
=20
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. =20
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=20
Phone: +1 613 763 7860 (ESN 393)=20
FAX:   +1 613 763 6608 (ESN 393)=20
email: [email-masked]=20
=20
-----Original Message-----=20
From: Loa Andersson [ mailto:[email-masked]]=20
Sent: Thursday, February 27, 2003 7:33 AM=20
To: Kireeti Kompella=20
Cc: Stephen Trowbridge; [email-masked]; [email-masked]=20
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt=20
<snip>=20
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=20
<snip>=20

------_=_NextPart_001_01C2DE63.4810FA95
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<title>RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:Times;
	panose-1:2 2 6 3 5 4 5 2 3 4;
	mso-font-charset:0;
	mso-generic-font-family:roman;
	mso-font-pitch:variable;
	mso-font-signature:536902279 -2147483648 8 0 511 0;}
@font-face
	{font-family:Helvetica;
	panose-1:2 11 6 4 2 2 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:536902279 -2147483648 8 0 511 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
h1
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-indent:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	tab-stops:list .25in;
	font-size:14.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
h2
	{mso-style-update:auto;
	mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-indent:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:2;
	tab-stops:list .25in;
	font-size:12.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";
	font-weight:bold;
	mso-bidi-font-weight:normal;
	font-style:italic;
	mso-bidi-font-style:normal;}
h3
	{mso-style-update:auto;
	mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-indent:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:3;
	tab-stops:list .25in;
	font-size:12.0pt;
	font-family:Arial;
	mso-bidi-font-family:"Times New Roman";
	font-weight:normal;}
h4
	{mso-style-update:auto;
	mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-indent:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:4;
	tab-stops:list .25in;
	font-size:12.0pt;
	font-family:Helvetica;
	mso-bidi-font-family:"Times New Roman";
	font-weight:normal;}
h5
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-indent:0in;
	mso-pagination:widow-orphan;
	mso-outline-level:5;
	tab-stops:list .25in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:normal;}
h6
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	mso-outline-level:6;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:normal;
	font-style:italic;
	mso-bidi-font-style:normal;}
p.MsoHeading7, li.MsoHeading7, div.MsoHeading7
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	mso-outline-level:7;
	font-size:12.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
p.MsoHeading8, li.MsoHeading8, div.MsoHeading8
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	mso-outline-level:8;
	font-size:12.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	font-style:italic;
	mso-bidi-font-style:normal;}
p.MsoHeading9, li.MsoHeading9, div.MsoHeading9
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	mso-outline-level:9;
	font-size:9.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	font-weight:bold;
	mso-bidi-font-weight:normal;
	font-style:italic;
	mso-bidi-font-style:normal;}
p.MsoIndex1, li.MsoIndex1, div.MsoIndex1
	{mso-style-update:auto;
	mso-style-next:Normal;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:12.0pt;
	margin-bottom:.0001pt;
	text-indent:-12.0pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoFootnoteText, li.MsoFootnoteText, div.MsoFootnoteText
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoCommentText, li.MsoCommentText, div.MsoCommentText
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:Times;}
p.MsoHeader, li.MsoHeader, div.MsoHeader
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	tab-stops:center 3.0in right 6.0in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoFooter, li.MsoFooter, div.MsoFooter
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	tab-stops:center 3.0in right 6.0in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoCaption, li.MsoCaption, div.MsoCaption
	{mso-style-next:Normal;
	margin-top:6.0pt;
	margin-right:0in;
	margin-bottom:6.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	font-weight:bold;
	mso-bidi-font-weight:normal;}
span.MsoFootnoteReference
	{vertical-align:super;}
span.MsoCommentReference
	{mso-ansi-font-size:8.0pt;}
p.MsoList, li.MsoList, div.MsoList
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.25in;
	margin-bottom:.0001pt;
	text-indent:-.25in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoList2, li.MsoList2, div.MsoList2
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	text-indent:-.25in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoListBullet2, li.MsoListBullet2, div.MsoListBullet2
	{mso-style-update:auto;
	margin:0in;
	margin-bottom:.0001pt;
	text-indent:0in;
	mso-pagination:widow-orphan;
	tab-stops:list .25in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoListNumber2, li.MsoListNumber2, div.MsoListNumber2
	{margin:0in;
	margin-bottom:.0001pt;
	text-indent:0in;
	mso-pagination:widow-orphan;
	tab-stops:list .25in left 1.0in 1.5in 2.0in 2.5in 3.0in 3.5in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoListNumber3, li.MsoListNumber3, div.MsoListNumber3
	{margin:0in;
	margin-bottom:.0001pt;
	text-indent:0in;
	mso-pagination:widow-orphan;
	tab-stops:list .25in left .5in 1.0in 1.5in 2.0in 2.5in 3.0in 3.5in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoTitle, li.MsoTitle, div.MsoTitle
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	mso-pagination:widow-orphan;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin:0in;
	margin-bottom:.0001pt;
	text-align:justify;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoBodyTextIndent, li.MsoBodyTextIndent, div.MsoBodyTextIndent
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.MsoListContinue, li.MsoListContinue, div.MsoListContinue
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.25in;
	margin-bottom:.0001pt;
	text-align:justify;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
p.MsoBodyText2, li.MsoBodyText2, div.MsoBodyText2
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	color:black;
	layout-grid-mode:line;}
p.MsoBodyText3, li.MsoBodyText3, div.MsoBodyText3
	{margin:0in;
	margin-bottom:.0001pt;
	text-align:justify;
	mso-pagination:widow-orphan;
	font-size:7.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	color:black;
	layout-grid-mode:line;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.MsoDocumentMap, li.MsoDocumentMap, div.MsoDocumentMap
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	background:navy;
	font-size:12.0pt;
	font-family:Tahoma;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Courier New";
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle16
	{mso-style-type:personal-reply;
	mso-ansi-font-size:10.0pt;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
p.Appendix, li.Appendix, div.Appendix
	{mso-style-name:Appendix;
	mso-style-parent:"Heading 1\,1\,h1\,1st level\,I1\,heading 1\,Chapter =
title\,l1\,l1+toc 1\,Level 1\,Level 11\,AboutDocument";
	mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.3in;
	text-indent:-.3in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	tab-stops:list .3in;
	font-size:14.0pt;
	mso-bidi-font-size:12.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.Bodytext, li.Bodytext, div.Bodytext
	{mso-style-name:"Body text";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan lines-together;
	tab-stops:45.0pt 73.0pt 102.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.Reference, li.Reference, div.Reference
	{mso-style-name:Reference;
	margin:0in;
	margin-bottom:.0001pt;
	text-align:justify;
	text-indent:0in;
	mso-pagination:widow-orphan;
	tab-stops:list .25in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p.Requirement, li.Requirement, div.Requirement
	{mso-style-name:Requirement;
	mso-style-parent:"List Continue";
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.25in;
	margin-bottom:.0001pt;
	text-align:justify;
	text-indent:0in;
	mso-pagination:widow-orphan;
	tab-stops:list .25in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	font-style:italic;
	mso-bidi-font-style:normal;}
p.Ednote, li.Ednote, div.Ednote
	{mso-style-name:"Ed note";
	mso-style-update:auto;
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	color:blue;
	font-weight:bold;
	mso-bidi-font-weight:normal;
	font-style:italic;
	mso-bidi-font-style:normal;}
p.Requirementlist, li.Requirementlist, div.Requirementlist
	{mso-style-name:"Requirement list";
	margin:0in;
	margin-bottom:.0001pt;
	text-indent:0in;
	mso-pagination:widow-orphan lines-together;
	tab-stops:list .25in;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	layout-grid-mode:line;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
 /* List Definitions */
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dblue style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Lo=
a, Kireeti,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>I =
agree
with Malcolm. <o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'>Si=
nce this
draft proposes a process change specifically dealing with requirements =
and
problem statements, and since ITU uses the liaison process for this =
reason, the
liaison process is very relevant to the changes proposed in this draft, =
and it
is not an orthogonal problem.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><!=
[if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D2 =
color=3Dnavy face=3DArial><span
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><!=
[if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoAutoSig><!--[if supportFields]><span =
class=3DEmailStyle16><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-begin'></span><span=20
style=3D"mso-spacerun: yes">&nbsp;</span>AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span></span></font></span><![endi=
f]--><font
color=3Dnavy><span style=3D'color:navy'>Monica A. =
Lazer</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></=
p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>Network Architecture and =
Reliability</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></=
p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'><span style=3D"mso-spacerun:
yes">&nbsp;</span></span></font><font color=3Dnavy><span =
style=3D'color:navy;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>908 234 8462</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></=
p>

<p class=3DMsoAutoSig><font size=3D3 color=3Dnavy face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:navy'>[email-masked]</span></font><font
color=3Dnavy><span =
style=3D'color:navy;mso-color-alt:windowtext'><o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><!--[if supportFields]><span =
class=3DEmailStyle16><font=20
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'><span =
style=3D'mso-element:field-end'></span></span></font></span><![endif]--><=
span
class=3DEmailStyle16><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:
10.0pt;font-family:Tahoma;color:black'>-----Original Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Malcolm Betts
[mailto:[email-masked]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, February =
27, 2003
8:11 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Loa Andersson'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Stephen Trowbridge; =
Kireeti
Kompella; [email-masked]; [email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: I-D
ACTION:draft-andersson-mpls-g-chng-proc-00.txt</span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>Loa, the from the outside looking in the liaison process =
and the
change process are closely coupled.&nbsp; The liaison process is =
described in ITU-T
Recommendation A.4 and A.5 and in RFC 3356.&nbsp; </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>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).&nbsp;
The change process being proposed requires that this official request =
from a
SDO is converted into an individuals ID.&nbsp; The level of agreement in =
the
SDO is therefore obscured, this process appears to be in conflict with =
RFC
3356.&nbsp; 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.&nbsp; If my understanding of the draft is correct such requests =
would
be rejected by the IETF.</span></font><font color=3Dblack><span =
style=3D'color:
black;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>It is clearly beneficial to the industry if the basic IETF
protocols can be extended to address such applications.&nbsp; The IETF =
plays a
key role in ensuring that the integrity of the base protocols is not
compromised.</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>Malcolm Betts</span></font><font color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>Phone: +1 613 763 7860 (ESN 393)</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>FAX:&nbsp;&nbsp; +1 613 763 6608 (ESN =
393)</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>email: [email-masked]</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>-----Original Message-----</span></font><font =
color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>From: Loa Andersson [<a =
href=3D"mailto:[email-masked]">mailto:[email-masked]</a>]
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Sent: Thursday, February 27, 2003 7:33 =
AM</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>To: Kireeti Kompella</span></font><font color=3Dblack><span
style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Cc: Stephen Trowbridge; [email-masked]; =
[email-masked]</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Subject: Re: I-D =
ACTION:draft-andersson-mpls-g-chng-proc-00.txt</span></font><font
color=3Dblack><span style=3D'color:black'> <br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>&lt;snip&gt;</span></font><font color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>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.</span></font><font color=3Dblack><span =
style=3D'color:black;mso-color-alt:
windowtext'><o:p></o:p></span></font></p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>/Loa</span></font><font color=3Dblack><span =
style=3D'color:black'> </span></font><font
color=3Dblack><span =
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

<p><font size=3D2 color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt;
color:black'>&lt;snip&gt;</span></font><font color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C2DE63.4810FA95--

Delivery-date: Thu, 27 Feb 2003 05:13:55 -0800
Date: Thu, 27 Feb 2003 08:13:36 -0500
From: Scott W Brim <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Mail-Followup-To: Scott W Brim <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked], [email-masked]

On Thu, Feb 27, 2003 01:22:01AM +0100, Bert allegedly wrote:
> > Liaisons are an IETF-wide issue.
> >
> YES.
>  
> > I think if we want to send a liaison to another group, the AD just sends
> > e-mail, and archives it on ietf.org.  That's just an administrative
> > matter, nothing we even need a draft for.
> > 
> It is not always the AD who sends. It could be a WG. Or whole IETF.

Liaisons can be *generated* anywhere, but should be *sent* through a
predictable agent.  Having the IETF Chair, or "the whole IETF", send a
liaison is too general -- liaisons need to be more focused than that to
be useful.  Individual WGs could send individual liaisons but I believe
the AD level would be better for the usual reasons, coordination, an
integrative view, etc.

> > Incoming liaisons take a little more policy but not much.  We want them
> > archived, so just saying "submit a draft" isn't good enough.  I'm afraid
> > we need to provide mailto:[email-masked], and yet another folder
> > on the web pages.  All ADs get to hear about all incoming liaisons, and
> > if they think it's appropriate for one of their WGs they forward it.
> > Done?
> > 
> No of course NOT. Many Liasons will want an answer.
> So we need a process to follow up and to track if a timely
> response has been (or will be) send.

I do not believe any organization is obligated to reply to everything
that requests a reply (just think about the spam you get).  If the AD
and/or one or more WGs find the liaison (and the idea of replying to it)
interesting and useful, then they will reply.  The process for keeping
track of this is at the AD level.  

..swb

Delivery-date: Thu, 27 Feb 2003 05:11:57 -0800
From: "Malcolm Betts" <[email-masked]>
To: "'Loa Andersson'" <[email-masked]>
Cc: Stephen Trowbridge <[email-masked]>, Kireeti Kompella <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 08:10:41 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2DE61.A0E63C74
Content-Type: text/plain

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: [email-masked]

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Thursday, February 27, 2003 7:33 AM
To: Kireeti Kompella
Cc: Stephen Trowbridge; [email-masked]; [email-masked]
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>

------_=_NextPart_001_01C2DE61.A0E63C74
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Loa, the from the outside looking in the liaison =
process and the change process are closely coupled.&nbsp; The liaison =
process is described in ITU-T Recommendation A.4 and A.5 and in RFC =
3356.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>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).&nbsp; The change process being proposed =
requires that this official request from a SDO is converted into an =
individuals ID.&nbsp; The level of agreement in the SDO is therefore =
obscured, this process appears to be in conflict with RFC 3356.&nbsp; =
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.&nbsp; If my understanding of the draft is correct such requests =
would be rejected by the IETF.</FONT></P>

<P><FONT SIZE=3D2>It is clearly beneficial to the industry if the basic =
IETF protocols can be extended to address such applications.&nbsp; The =
IETF plays a key role in ensuring that the integrity of the base =
protocols is not compromised.</FONT></P>

<P><FONT SIZE=3D2>Malcolm Betts</FONT>
</P>

<P><FONT SIZE=3D2>Phone: +1 613 763 7860 (ESN 393)</FONT>
<BR><FONT SIZE=3D2>FAX:&nbsp;&nbsp; +1 613 763 6608 (ESN 393)</FONT>
<BR><FONT SIZE=3D2>email: [email-masked]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Loa Andersson [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, February 27, 2003 7:33 AM</FONT>
<BR><FONT SIZE=3D2>To: Kireeti Kompella</FONT>
<BR><FONT SIZE=3D2>Cc: Stephen Trowbridge; [email-masked]; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: I-D =
ACTION:draft-andersson-mpls-g-chng-proc-00.txt</FONT>
<BR><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>/Loa</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2DE61.A0E63C74--

Delivery-date: Thu, 27 Feb 2003 04:39:40 -0800
Date: Thu, 27 Feb 2003 13:32:35 +0100
From: Loa Andersson <[email-masked]>
To: Kireeti Kompella <[email-masked]>
CC: Stephen Trowbridge <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Kireeti,

thanks you captured most of my points and said it possibly more clearly
and more polite than I would have.

I just want to strengthen one of the points a bit. Chapter 2
bullet 4 says clearly

>   4  that the problem is real and that they would be solved with exten-
>      sions to the (G)MPLS protocols, but that this for some reason is
>       not best done within the IETF, but some other organization. The
>      IETF might in such a case come to an agreement with this organiza-
>      tion to specify the protocol extensions and that these will be
>      described in a ID sent to the IETF for review and eventually be
>      published as an RFC.
>
>
>  
>
How this could be contrued as trying to stop other organizations from
extending and improving the IETF protocols escapes my imagination, we
even offer to put our expertise in for eview and makes it possible
to use the IETF as a vehicle for publication-

Further in testing Stephen logic on "you are not alone" - if I came
to the absurd conclusion that I wanted to use Q.931 for label distribution
and I failed to convince ITU that this was a good idea, would then ITU
accept that the IETF or any other SDO published an extension to Q.931?
Those arguments cuts both ways!

Last, the IETF standards process works with IDs and RFCs, that one
working group (or a coupel of them) should start working with another type
of document (liasions) in that process is ... It would also take us
to the point where we need to do the same thing with the prefered
document from other SDOs. "You are not alone!"

How would ITU react if I started sending IDs to them?

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

Kireeti Kompella wrote:

>Hi Steve,
>
>On Wed, 26 Feb 2003, Stephen Trowbridge wrote:
>
>  
>
>>However, as Deborah, Kireeti, and Scott
>>have observed, the way it is written it seems to hinder rather than
>>help the process of collaborating with other Standards Developement
>>Organizations(SDOs)
>>    
>>
>
>If this is the impression that my comments gave, I must have used the
>wrong words.  The GMPLS change document is intended to help other SDOs
>understand the change process, and as such *help* collaboration.
>
>  
>
>>and doesn't provide a good way to deal with and respond
>>to liaison statements, which is the avenue by which many of these
>>requests will arrive from other SDOs.
>>    
>>
>
>This I agree with.  But as Loa pointed out, it was not the intent of
>the gmpls change doc to address this issue -- that is the domain of
>a different document; and as several people have pointed out by now,
>the change document is very specific (a small set of WGs), whereas
>a liaison document should probably be much broader (IETF-wide).
>
>  
>
>>The document as
>>written creates impediments to the ability to apply, and extend as
>>necessary, these protocols to new problem spaces.
>>    
>>
>
>I don't see this at all.  The IETF does have processes, for example,
>RFC 2026.  So (I assume) does the ITU.  Most would consider writing
>down a process for change, especially with the intent of maintaining
>architectural soundness, a Good Thing, not an impediment.  Process
>does on occasion slow things down.  Sometimes that is laudable --
>deliberation vs haste; sometimes that is a price one pays in return
>for avoiding chaos.  It takes longer for me to hang up my clothes rather
>than throw them on the floor -- but I opt to hang them up.
>
>  
>
>>As noted, biggest flaw seems to be the way in which the document deals
>>with new applications or requirements identified by external standards
>>organizations. In addition to not recognizing that this information may
>>come to IETF via liaison statements,
>>    
>>
>
>Let's take these one at a time.  A liaison statement (LS) has not been
>heretofore a replacement for an ID.  A LS of the form "we invite you
>to take part in such-and-such meeting" or "we would like to bring to
>your attention such-and-such work" are fine uses (in my opinion) for
>LSs.  However, if an SDO thinks that x, y and z are requirements for
>protocol foo, communicating this solely via a liaison statement is not
>(again, IMO) the right approach.  Requirements need to be discussed,
>possibly modified, and captured in some permanent form.  There is a
>well established process in the IETF for that; introducing a new
>vehicle for that process is neither necessary nor appropriate, at
>least without a revision of 2026 that states this.  It is not the
>intent of the gmpls change process to at the same time change the
>IETF's process and to update 2026.
>
>  
>
>>the document seems not to consider
>>the fact that there may be a valid application that is outside of the
>>scope of IETF (and in the scope of another standards development
>>organization) to which the (G)MPLS protocols may be applied, and for
>>which the (G)MPLS protocols may require extension.
>>    
>>
>
>Not at all true.
>
>  
>
>>By insisting that
>>every possible extension be done internally in IETF, the IETF either
>>(1) Extends the scope of its work without bound; or (2) Needlessly
>>restricts the application of its protocols. Neither one of these is
>>good for IETF or for the Standards Development community at large.
>>    
>>
>
>The reason for insisting that extensions be done in the IETF is:
>(a) the IETF developed the protocols, knows them best, and knows the
>    bigger architectural picture in which they fit.  A good example
>    is the (unnecessary) deprecation of RSVP messages in a recent RFC.
>(b) when all is said and done, the IETF does own the protocols.
>
>It is instructive to harken back to how CCAMP took extraordinary pains
>*not* to change the SDH spec, nor even to give the impression of such a
>change.  There was a clear recognition that SDH "belonged" to the ITU,
>and when representatives felt that there was "intrusion", even if
>unintended, CCAMP stepped back.  There were two reasons for this: we
>recognized that we (as an SDO, not as individuals) didn't have the
>expertise; and we wanted to maintain cordial relations.
>
>  
>
>>One reality that this draft fails to recognize is that, while IETF may
>>be able to say "no" to standardizing something proposed by an individual,
>>it does not have the ability (or the right) to say "no" to something
>>proposed by another Standards Development Organization. As a practical
>>matter, the IETF is not the only place where something can be standardized.
>>    
>>
>
>I agree that the IETF cannot stop other SDOs from extending its
>protocols; it can (I believe) insist that such modified protocols use a
>new name to call out the differences.
>
>However, the problem that the change document addresses is not what
>other SDOs are doing, but what the IETF should be doing.  As far as
>other SDOs are concerned, they can decide on their own to abide by
>the IETF's rules if they want, or to forge ahead on their own, at
>the risk (which they may consider worthwhile) of marring their relations
>with the IETF.
>
>  
>
>>If the IETF creates impediments to applying IETF protocols to
>>the application space of another standards development organization,
>>there is really nothing that the IETF can do to prevent that the other
>>organization standardizes something themselves. The result would tend
>>to be a proliferation of (G)MPLS "like" protocols instead of a coherent
>>suite of protocols with broad applicability. This result would not be
>>good for the IETF or the industry in general.
>>    
>>
>
>There is already a proliferation of GMPLS like protocols.  The OIF
>has its own; the ITU is developing its own.  It is not the intention
>of the change document to stop this, nor to create impediments.  But
>there is the (fond!) hope that with such a change document in place,
>other SDOs will say -- "hey, instead of changing the protocols ourselves,
>there is this process whereby we can take our requirements to the IETF
>and get the experts who really know that protocol to change it to meet
>our needs."
>
>  
>
>>A better approach would be for the IETF to PROMOTE the use of its
>>protocols for new applications
>>    
>>
>
>Far be it for me to say what the IETF should or should not do.  However,
>I personally don't think the IETF should promote its protocols.  In the
>final analysis, the IETF is concerned with running (and promoting) the
>Internet.  Any protocols it designs should have that as the end goal.
>
>  
>
>>and, when another Standards Development
>>Organization wishes to apply (G)MPLS protocols to an application domain
>>outside of the scope of IETF, that IETF will (1) assist with the development
>>of any necessary extensions; and (2) to facilitate documentation of
>>such new applications and extensions in a central place (e.g., by
>>informational RFC, even for extensions that are developed outside of
>>IETF) and to insure that code points are assigned in a coherent manner
>>through IANA to avoid collisions where different extensions may use
>>the same code points to indicate different things.
>>    
>>
>
>If the IETF is convinced that such extensions will in some way help
>to achieve its own goals AND will not hurt the protocol, the IETF can
>and should undertake the activity.  If the extensions do not match
>the IETF's goals, but they don't hurt the protocol, there should be
>a way (such as Bob Braden's SPIFFY_ITU_... idea) for the IETF to
>yield the floor to some other SDO.
>
>  
>
>>The difference in flavor for what I am proposing is that IETF should
>>try to position itself as a Clearinghouse for (G)MPLS protocol extensions
>>rather than as a Gatekeeper for (G)MPLS protcol extensions.
>>    
>>
>
>The Gatekeeper function is for the case where the said extensions do
>hurt the protocol (in the eyes of the IETF).  This is where the SDO
>can decide, as you point out, that it can do it on its own, but
>changes the name of the protocol so that innocent bystanders can tell
>the difference.
>
>Kireeti.
>
>
>  
>

Delivery-date: Thu, 27 Feb 2003 01:10:11 -0800
Date: Thu, 27 Feb 2003 01:09:07 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
cc: Scott W Brim <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi Bert,

On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote:

> No of course NOT. Many Liasons will want an answer.
> So we need a process to follow up and to track if a timely
> response has been (or will be) send.

Is the IETF process for replying to liaison statements (and of
generating them) written down, say in some RFC?  If so, could you
send me a pointer?

> But the Liasons communication between ITU and CCAMP/MPLS has not
> been going smoothly so far (even though we had good intentions).
> Responses have not gone out in time (or in some cases at all).

I'll take full responsibility for that.

Thanks,
Kireeti.

Delivery-date: Thu, 27 Feb 2003 01:02:07 -0800
Date: Thu, 27 Feb 2003 00:57:18 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Stephen Trowbridge <[email-masked]>
cc: [email-masked], "" <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi Steve,

On Wed, 26 Feb 2003, Stephen Trowbridge wrote:

> However, as Deborah, Kireeti, and Scott
> have observed, the way it is written it seems to hinder rather than
> help the process of collaborating with other Standards Developement
> Organizations(SDOs)

If this is the impression that my comments gave, I must have used the
wrong words.  The GMPLS change document is intended to help other SDOs
understand the change process, and as such *help* collaboration.

> and doesn't provide a good way to deal with and respond
> to liaison statements, which is the avenue by which many of these
> requests will arrive from other SDOs.

This I agree with.  But as Loa pointed out, it was not the intent of
the gmpls change doc to address this issue -- that is the domain of
a different document; and as several people have pointed out by now,
the change document is very specific (a small set of WGs), whereas
a liaison document should probably be much broader (IETF-wide).

> The document as
> written creates impediments to the ability to apply, and extend as
> necessary, these protocols to new problem spaces.

I don't see this at all.  The IETF does have processes, for example,
RFC 2026.  So (I assume) does the ITU.  Most would consider writing
down a process for change, especially with the intent of maintaining
architectural soundness, a Good Thing, not an impediment.  Process
does on occasion slow things down.  Sometimes that is laudable --
deliberation vs haste; sometimes that is a price one pays in return
for avoiding chaos.  It takes longer for me to hang up my clothes rather
than throw them on the floor -- but I opt to hang them up.

> As noted, biggest flaw seems to be the way in which the document deals
> with new applications or requirements identified by external standards
> organizations. In addition to not recognizing that this information may
> come to IETF via liaison statements,

Let's take these one at a time.  A liaison statement (LS) has not been
heretofore a replacement for an ID.  A LS of the form "we invite you
to take part in such-and-such meeting" or "we would like to bring to
your attention such-and-such work" are fine uses (in my opinion) for
LSs.  However, if an SDO thinks that x, y and z are requirements for
protocol foo, communicating this solely via a liaison statement is not
(again, IMO) the right approach.  Requirements need to be discussed,
possibly modified, and captured in some permanent form.  There is a
well established process in the IETF for that; introducing a new
vehicle for that process is neither necessary nor appropriate, at
least without a revision of 2026 that states this.  It is not the
intent of the gmpls change process to at the same time change the
IETF's process and to update 2026.

> the document seems not to consider
> the fact that there may be a valid application that is outside of the
> scope of IETF (and in the scope of another standards development
> organization) to which the (G)MPLS protocols may be applied, and for
> which the (G)MPLS protocols may require extension.

Not at all true.

> By insisting that
> every possible extension be done internally in IETF, the IETF either
> (1) Extends the scope of its work without bound; or (2) Needlessly
> restricts the application of its protocols. Neither one of these is
> good for IETF or for the Standards Development community at large.

The reason for insisting that extensions be done in the IETF is:
(a) the IETF developed the protocols, knows them best, and knows the
    bigger architectural picture in which they fit.  A good example
    is the (unnecessary) deprecation of RSVP messages in a recent RFC.
(b) when all is said and done, the IETF does own the protocols.

It is instructive to harken back to how CCAMP took extraordinary pains
*not* to change the SDH spec, nor even to give the impression of such a
change.  There was a clear recognition that SDH "belonged" to the ITU,
and when representatives felt that there was "intrusion", even if
unintended, CCAMP stepped back.  There were two reasons for this: we
recognized that we (as an SDO, not as individuals) didn't have the
expertise; and we wanted to maintain cordial relations.

> One reality that this draft fails to recognize is that, while IETF may
> be able to say "no" to standardizing something proposed by an individual,
> it does not have the ability (or the right) to say "no" to something
> proposed by another Standards Development Organization. As a practical
> matter, the IETF is not the only place where something can be standardized.

I agree that the IETF cannot stop other SDOs from extending its
protocols; it can (I believe) insist that such modified protocols use a
new name to call out the differences.

However, the problem that the change document addresses is not what
other SDOs are doing, but what the IETF should be doing.  As far as
other SDOs are concerned, they can decide on their own to abide by
the IETF's rules if they want, or to forge ahead on their own, at
the risk (which they may consider worthwhile) of marring their relations
with the IETF.

> If the IETF creates impediments to applying IETF protocols to
> the application space of another standards development organization,
> there is really nothing that the IETF can do to prevent that the other
> organization standardizes something themselves. The result would tend
> to be a proliferation of (G)MPLS "like" protocols instead of a coherent
> suite of protocols with broad applicability. This result would not be
> good for the IETF or the industry in general.

There is already a proliferation of GMPLS like protocols.  The OIF
has its own; the ITU is developing its own.  It is not the intention
of the change document to stop this, nor to create impediments.  But
there is the (fond!) hope that with such a change document in place,
other SDOs will say -- "hey, instead of changing the protocols ourselves,
there is this process whereby we can take our requirements to the IETF
and get the experts who really know that protocol to change it to meet
our needs."

> A better approach would be for the IETF to PROMOTE the use of its
> protocols for new applications

Far be it for me to say what the IETF should or should not do.  However,
I personally don't think the IETF should promote its protocols.  In the
final analysis, the IETF is concerned with running (and promoting) the
Internet.  Any protocols it designs should have that as the end goal.

> and, when another Standards Development
> Organization wishes to apply (G)MPLS protocols to an application domain
> outside of the scope of IETF, that IETF will (1) assist with the development
> of any necessary extensions; and (2) to facilitate documentation of
> such new applications and extensions in a central place (e.g., by
> informational RFC, even for extensions that are developed outside of
> IETF) and to insure that code points are assigned in a coherent manner
> through IANA to avoid collisions where different extensions may use
> the same code points to indicate different things.

If the IETF is convinced that such extensions will in some way help
to achieve its own goals AND will not hurt the protocol, the IETF can
and should undertake the activity.  If the extensions do not match
the IETF's goals, but they don't hurt the protocol, there should be
a way (such as Bob Braden's SPIFFY_ITU_... idea) for the IETF to
yield the floor to some other SDO.

> The difference in flavor for what I am proposing is that IETF should
> try to position itself as a Clearinghouse for (G)MPLS protocol extensions
> rather than as a Gatekeeper for (G)MPLS protcol extensions.

The Gatekeeper function is for the case where the said extensions do
hurt the protocol (in the eyes of the IETF).  This is where the SDO
can decide, as you point out, that it can do it on its own, but
changes the name of the protocol so that innocent bystanders can tell
the difference.

Kireeti.

Delivery-date: Wed, 26 Feb 2003 16:24:21 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Scott W Brim <[email-masked]>, [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Thu, 27 Feb 2003 01:22:01 +0100

> Liaisons are an IETF-wide issue.
>
YES.
 
> I think if we want to send a liaison to another group, the AD just sends
> e-mail, and archives it on ietf.org.  That's just an administrative
> matter, nothing we even need a draft for.
> 
It is not always the AD who sends. It could be a WG. Or whole IETF.

> Incoming liaisons take a little more policy but not much.  We want them
> archived, so just saying "submit a draft" isn't good enough.  I'm afraid
> we need to provide mailto:[email-masked], and yet another folder
> on the web pages.  All ADs get to hear about all incoming liaisons, and
> if they think it's appropriate for one of their WGs they forward it.
> Done?
> 
No of course NOT. Many Liasons will want an answer.
So we need a process to follow up and to track if a timely
response has been (or will be) send.

> But this shouldn't be discussed on these lists anyway :-)
> 
The general issue should not....
But the Liasons communication between ITU and CCAMP/MPLS has not
been going smoothly so far (even though we had good intentions).
Responses have not gone out in time (or in some cases at all).

So in that respect some of it is relevant here.
But possibly not to this specific document.
Depends on how you look at things I guess.

Bert

Delivery-date: Wed, 26 Feb 2003 14:22:53 -0800
Date: Wed, 26 Feb 2003 15:21:26 -0700
From: Stephen Trowbridge <[email-masked]>
Organization: Lucent Technologies
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

All,
draft-andersson-mpls-g-chng-proc-00.txt seems to be addressed at a
noble goal of bringing some order to new applications and extensions
of the (G)MPLS protocols. However, as Deborah, Kireeti, and Scott
have observed, the way it is written it seems to hinder rather than
help the process of collaborating with other Standards Developement
Organizations(SDOs) and doesn't provide a good way to deal with and respond
to liaison statements, which is the avenue by which many of these
requests will arrive from other SDOs.

It speaks well for the protocols that others will find applications
of them beyond the scope for which they were originally designed, and
even outside the scope of areas addressed by the IETF. The document as
written creates impediments to the ability to apply, and extend as
necessary, these protocols to new problem spaces. I think it would be
a far better goal to promote the reuse and widest application of these
protocols, and to try to enable these new applications through a
process that keeps some order to the applications and extensions of
the protocols.

As noted, biggest flaw seems to be the way in which the document deals
with new applications or requirements identified by external standards
organizations. In addition to not recognizing that this information may
come to IETF via liaison statements, the document seems not to consider
the fact that there may be a valid application that is outside of the
scope of IETF (and in the scope of another standards development
organization) to which the (G)MPLS protocols may be applied, and for
which the (G)MPLS protocols may require extension. By insisting that
every possible extension be done internally in IETF, the IETF either
(1) Extends the scope of its work without bound; or (2) Needlessly
restricts the application of its protocols. Neither one of these is
good for IETF or for the Standards Development community at large.

One reality that this draft fails to recognize is that, while IETF may
be able to say "no" to standardizing something proposed by an individual,
it does not have the ability (or the right) to say "no" to something
proposed by another Standards Development Organization. As a practical
matter, the IETF is not the only place where something can be standardized.
If the IETF creates impediments to applying IETF protocols to
the application space of another standards development organization,
there is really nothing that the IETF can do to prevent that the other
organization standardizes something themselves. The result would tend
to be a proliferation of (G)MPLS "like" protocols instead of a coherent
suite of protocols with broad applicability. This result would not be
good for the IETF or the industry in general.

A better approach would be for the IETF to PROMOTE the use of its
protocols for new applications, and, when another Standards Development
Organization wishes to apply (G)MPLS protocols to an application domain
outside of the scope of IETF, that IETF will (1) assist with the development
of any necessary extensions; and (2) to facilitate documentation of
such new applications and extensions in a central place (e.g., by
informational RFC, even for extensions that are developed outside of
IETF) and to insure that code points are assigned in a coherent manner
through IANA to avoid collisions where different extensions may use
the same code points to indicate different things.

I think that this could lay the groundwork for a much more constructive
collaborative relationship between the IETF and other Standards Development
Organizations than the draft as it stands.

The difference in flavor for what I am proposing is that IETF should
try to position itself as a Clearinghouse for (G)MPLS protocol extensions
rather than as a Gatekeeper for (G)MPLS protcol extensions.

What I have included below are some specific proposed text changes to
try to change the flavor of the current draft to try to accomplish this.

One final question regarding the applicability of this draft: The
sub-IP area is still classified as a temporary area, and it seems
that this particular procedure that will not be valid as written if
remaining sub-IP work is returned to the "native" IETF areas. I
don't have any specific suggestion as to how to solve this problem.

My specific text proposals follow below.
Regards,
Steve

Specific text proposals are as follows:
=======================================================================
Abstract
 Original Text:
   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.
_______________________________________________________________________
 Proposed New Text:

   This memo describes the process through which individuals, working
   groups and external standards bodies can influence the development of
   MPLS and GMPLS standards.

   MPLS and GMPLS technology has attracted the interest of individuals
   and other Standards Development Organizations (SDOs) to apply and,
   where necessary, extend the protocols to cover problems and
   application spaces beyond those for which the protocols were
   originally designed. This speaks well for the architecture of the
   protocols that they can find such widespread application, and it
   is highly desirable to find ways to reuse and extend existing protocols
   rather than inventing new protocols to address these other problem
   areas.

   The challange going forward is to find ways to maximize the opportunities
   for reuse of these protocols, while trying to maintain architectural
   integrity of the protocols themselves. This draft outlines a proposal
   for such a process.

==========================================================================

Terminology:
Add:
problem statement liaison
  a formal liaison statement from another Standards Development Organization (SDO)
  that initiates the discussion on extending the (G)MPLS protocols. This
  liaison will generally include a detailed problem description and a set of
  requirements that the (G)MPLS protocols need to meet to solve the problem.
  Such a liaison statement may contain a draft or approved document from
  the originating standards organization that characterizes the problem,
  indicating the level of agreement or approval that such a document has
  acheived in the originating organization.

Supplement existing definition:
requirement evaluating working group (rewg) -
  in the process descreibed below, the Working Group charged with the
  task of evaluating a certain problem statement and a certain set of
  requirements is termed the rewg. The focus of this group is somewhat
  different for the cases described here based on whether the problem
  statement and requirements came from an individual or another Standards
  Development Organization (SDO): in the individual case, the group may focus
  on assessing the validity of the requirements. In the case of a problem
  statement or requirements coming from an SDO, the other SDO may already
  have decided that the problem statement and requirements are valid for
  their application space, so the focus is directed more toward evaluation
  of whether IETF should be involved in developing the solution to that
  problem.

==========================================================================

Section 2.1 Overview

  The existing diagram should be labeled "Procedure for initiation of New
  Applications and/or Extensions to (G)MPLS Protocols by Individuals".
  Even for individuals, there seems to be a missing "shortcut" from the
  document procedure. It seems to be assumed that we have already developed
  complete, perfect solutions to everything within the current charter,
  and not allow for the possibility that there is some missing element or
  overlooked requirement that may require a (G)MPLS extension that is
  within the current charter. This may require a line directly from the
  "review by wg chairs and ad's" box to the "IETF WG process" box to indicate
  the path taken where the problem statement is considered to fall entirely
  within the current charter.

  An additional diagram should be included labeled "Procedure for
  initiation of New Applications and/or Extensions to (G)MPLS protocols
  by other Standards Development Organizations (SDOs)"

         +---------+               
         |problem  |               
         |statement|<--------------------------------------------- Originating
         |liaison  |                                                  SDO  |
         +---------+                                                   ^   |
              |discusson                                               |   |
              |on mailing                                              |   |
              Vlist                                                    |   |
         +---------+                                                   |   |
         |review by|      NACK                                         |   |
       +-|WG chairs|--------------+                                    |   |
       | | and ADs |              |                                    |   |
       | +---------+              |                                    |   |
       |      |request IESG/IAB   |                                    |   |
       |      |to appoint rewg    |                                    |   |
       |      |and charter        |                                    |   |
       |      Vreq eval           |         +-------------------+      |   |
       | +---------+              +-------->|liaison indicating |      |   |
       | |IESG/IAB |              +-------->|out of scope or    |----->|   |
       | |decision |              |   +---->|interest for IETF  |      |   |
       | +---------+              |   |     +-------------------+      |   |
       |      |rewg chartered     |   |                                |   |
       |      |to work on         |   |                                |   |
       |      Vproblem statement  |   |     +-------------------+      |   |
       | +---------+       NACK   |   |     |liaison explaining |      |   |
       +>|rewg req |--------------+   |     |how problem can be |----->|   |
       +-| eval    |----------------------->|solved with        |      |   |
       | +---------+ no change reqd   |     |existing protocol  |      |   |
       |      |  |                    |     +-------------------+      |   |
       |      |  |         ACK        |                                |   |
       |      |  +------------------------------+                      |   |
       |      V                       |         |                      |   |
       | +---------+                  |         v                      |   |
       | |AD review|                  |     +-------------------+      |   |
       | +---------+                  |     |liaison accepting  |------+   |
       |      |request to IESG/       |     |new work item      |          |
       |      |IAB to approve         |     +-------------------+          |
       |      Vcharter changes        |         ^                          |
       | +---------+         NACK     |         |        +------------+    |
       | |IESG/IAB |------------------+         |        | Externally |    |
       | |decision |----------------------------+        | Developed  |<---+
       | +---------+         ACK                         | Solution   |
       |      |wg chartered to                           +------------+
       |      |work solution                                    |
       |      V                                                 v
       | +---------+                                     +------------+
       +-|IETF WG  |----/ /----> stds track RFC          | IANA code  |
         |process  |                                     |   points   |
         +---------+                                     +------------+
              ^                                                 |
              |                                                 v
          solutions                                        info RFC
             ID

=========================================================================
Section 2.2 - Change title to:
2.2. Changes or Extensions to (G)MPLS Protocols Initiated by Individuals

could also consider deleting item 4 of 2.2.4 since new section 2.3 is
proposed to handle proposals from other SDOs. item 4 of 2.2.4 would only
be valid in the case of an individual proposing a new problem to be solved
by extending (G)MPLS protocols that IETF decides would be better addressed
in another standards group. IETF could send a liaison to the other group
with the suggested problem. This case may not be important enough to
spell out explicitly in the document.

=========================================================================
Add new section 2.3:
2.3. Changes or Extensions to (G)MPLS Protocols Initated at the request of
     another Standards Development Organization (SDO)

2.3.1. Initiating changes or extensions to (G)MPLS Protocols

   If a Standards Development Organization (SDO) wishes to apply the
   (G)MPLS protocols to a new application problem space, or sees
   a need to extend the (G)MPLS protocols to support the requirements for
   that new application, they may inform the IETF in one of the following
   manners:

   -  An internet draft may be produced explaining the problem they are
      trying to solve and, if applicable, why the existing (G)MPLS protocols
      must be extended to address this problem. A note from the authors
      should be sent to the relevant mailing lists to initiate discussion.

   -  An SDO (particularly those SDOs with whom ISOC/IETF have a
      formal relationship, e.g, see RFC 3356 or ITU-T A.sup3, and ITU-T
      Rec. A.4 regarding the relationship and communication method with
      ITU-T) may also be communicated via a formal liaison or communication
      statement. Such a statement is posted via a link from
      http://www.ietf.org/IESG/liaison.html and advertised by the iesg
      secretariat (who posts the incoming liaison) via the mailing
      list to initiate discussion.

   The mailing list to use should be Area mailing list and, if known,
   the WG mailing list for the WG that will likely be the requirement
   evaluation working group. In the case of discussion initiated from
   an incoming liaison statement, the liaison may be addressed to a
   specific Area or Working Group and notification should me made to
   the indicated mailing lists accordingly.

   Note concerning work initiated as a result of a liaison statement:
   Often a liaison statement that indicates that it is for action will
   indicated a deadline. The ADs and WG chairs should be diligent to
   make sure that a reply liaison is generated by the requested date,
   even if all that can be reported by that date is current status or
   a positive acknowledgement of receipt of the information. When the
   IETF chooses to undertake work as a result of an incoming liaison,
   regular reports of progress should be made via reply liaisons
   including anticipated time frames for completion of the work. In
   this way, the originating SDO can assess whether they can wait for
   an IETF solution or should pursue other avenues.

2.3.2. Problem statement review

   The MPLS and CCAMP working group chairs in conjunction with the Area
   Directors will determine if the particular problems raised in the
   Internet Draft or Incoming Liaison should be evaluated by a working
   group. This decision will be based on mailing list discussion. If
   the decision is that a requirement evaluation is warranted a decision
   is taken on which working group should act as requirement evaluation
   working group (rewg).

   In the case where the decision is that the IETF will proceed with
   further examination of these requirements, the originating SDO should
   be informed of this decision in a reply liaison.

   In the case where the decision is that the IETF will not proceed
   with further requirements evaluation, the "dustbin" which would have
   been the result for an individual submission is not an option for
   the case where the problem satement and requirements have already
   been accepted by another SDO. Since the other SDO has already
   accepted the problem statement and requirements, the likelihood is
   that this will lead to a standardized solution whether or not IETF
   chooses to be involved. At the same time, IETF has an interest in
   the long term integrity of the protocol, and can choose one of two
   options:

   - Even though the particular problem may be out of scope for IETF,
     participants may have insight which would assist in the solution to that
     problem. For the integrity of the protocol, it is certainly best if
     similar problems are solved in similar ways, and since the IETF should
     have the broadest view of all applications of the protocol, they are
     in a position to offer helpful advice to the other SDO about how to
     solve it. This information should be collected from the aforementioned
     email discussion and sent to the other SDO in a reply liaison.

   - The IETF is not in a position to offer any advice or insight as
     to how the problem can be solved. In this case, the IETF should indicate
     to the other SDO via a reply liaison that the IETF cannot help them with
     the problem, and it is up to the other SDO to define any solution.

   In either of case, the reply liaison to the originating SDO should
   encourage them to document their additional application or protocol
   extension via an informational RFC, (to keep the most complete possible
   library of extensions in one place), and to have any protocol code points
   assigned via IANA to insure that there are no cases where the same
   protocol code points might mean different things in the context of
   different extensions developed by different SDOs. This documentation
   would also enable the IETF to have a repository of extensions that
   would enable it and others to assess relationships between extensions.
   Any two extensions might:

   - be complementary and be usable at the same time
 
   - co-exist at the same time but it would make sense to only use one or
     the other at a time 

   - not co-exist in an implementation but share a common base

2.3.3. Charter update

   If the chairs and the ADs both feel that the particular problems
   should be added to the MPLS or the CCAMP Working Group charter the
   ADs will propose specific charter modificiations for the Working Group
   to the IESG and the IAB. If the IESG and IAB approve of the charter
   changes the Working Group can then update its charter and start the
   work to study the requirements and the problems described in the
   Liaison statement.

2.3.4. Problem statement study

   The rewg will study the problem statement liaison statement and based
   on the evaluation, generate a response to the originating SDO and, if
   further work is to be undertaken within IETF, make such a recommendation
   to the IESG/IAB. The recommendation may be:

   1  that no extensions to the (G)MPLS protocols are needed since the
      problem can be solved by the protocols as they exist. In this case,
      the WG chairs shall coordinate generating a liaison statement back
      to the originating SDO explaining how their problem can be solved
      with the current protocols.

   2  that there is no interest in extending this protocol in IETF.
      Note that in the individual submission case (section 2.2.4) IETF
      is in the position to decide not to continue the work. However,
      in the case of work initiated due to a liaison from another SDO,
      the other SDO has already decided that there is a problem for
      which a standardized solution should be pursued. If IETF decides
      at this point not to pursue a standardized solution to the
      problem proposed by the incoming liaisons, a reply liaison is
      needed at this point with the same information content as discussed
      in section 2.3.2 if the ADs and WG chairs had decided not to
      pursue a standardized solution within IETF.

   In cases 1 and 2, IETF will not publish a standards track RFC to
   address the problem. However, should the originating SDO standardize
   its own solution, IETF will facilitate documenting that extension
   via an informational RFC and assignment of code points via IANA so
   that there is no conflict between this extension and those that may
   arise from other sources.

   3  that the problem is of interest to IETF and the IETF is interested
      in developing extensions to the (G)MPLS protocols to address the
      problem. If the problem falls within the current charter,
      the normal WG process can be followed at this point. A reply
      liaison should be generated to the originating SDO indicating
      IETFs intent to accept the work and pursue a solution.

      If the problem requires extensions to the charter of the appropriate
      working group and the ADs agree, the proposal will be brought
      before the IESG and the IAB. If the IESG (with IAB advice) agrees
      that the task should be added to that particular charter then the
      rewg can work on it with the aim of adopting a final set of
      requirements to be forwarded to the working group that will handle
      the specification of the protocol changes.

      If the ADs or IESG/IAB do not agree to the charter extensions,
      a reply liaison should be sent to the originating SDO as in item
      2 above.

      If a charter revision is agreed, a liaison should be sent to the
      originating SDO informing them of the revised charter and the
      intent to pursue the work.

   The rewg will study and clarify the requirements, merging them with
   others if warranted. The resulting requirements should be verified
   with the originating SDO via liaison, or other method is appropriate
   for that SDO. With concurrence from the originating SDO, the result
   is published as a requirements RFC. When the IESG approves
   publication of the requirements RFC it will add it as a new task to
   the protocol specifying Working Group charter.

   The protocol specifying working group will then develop the modifications
   or extensions to the (G)MPLS protocols needed to fulfil the requirements.
   In the case that the originating liaison has indicated any work or
   progress in the originating SDO to develop a protocol solution, that
   work shall be taken into account by the protocol specifying working
   group. To the extent that sound decisions have been made by the
   originating SDO, this should be used as the basis for the work in IETF.
   If errors are found, these shall be brought to the attention of the
   originating SDO via a liaison statement. Every effort shall be made
   to make sure that either the protocol is developed in one place, or
   the results are aligned if two specifications cannot be avoided.

========================================================================

Section 4 (obviously):
Add:
RFC 3471
RFC 3472
RFC 3473
RFC 3477
RFC 3478
RFC 3479
RFC 3480
========================================================================
References
Add:
[RFC3356]
     Internet Engineering Task Force and International
     Telecommunication Union - Telecommunications Standardization Sector
     Collaboration Guidelines. G. Fishman, S. Bradner. August 2002.

Delivery-date: Wed, 26 Feb 2003 12:54:32 -0800
Date: Wed, 26 Feb 2003 15:53:13 -0500
From: Scott W Brim <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Mail-Followup-To: Scott W Brim <[email-masked]>, [email-masked], [email-masked]

On Wed, Feb 26, 2003 08:05:35PM +0100, Loa Andersson allegedly wrote:
> We need to document the (g)mpls-change process, most of this is in the
> current draft. The concerns I've seen so far is on how and what could
> be accepted as input to the process, that should be easily solvable.
> 
> We need to doucment the ietf way of responding to liasions.
> 
> It is my immediate reaction that this do not really belong in the same
> document, if for no other reasons, at least for practical reasons. If
> there is a strong motive to put them in the same document, I can live
> with that.

They don't.  The change process is specific to a particular protocol
group.  Liaisons are an IETF-wide issue.

I think if we want to send a liaison to another group, the AD just sends
e-mail, and archives it on ietf.org.  That's just an administrative
matter, nothing we even need a draft for.

Incoming liaisons take a little more policy but not much.  We want them
archived, so just saying "submit a draft" isn't good enough.  I'm afraid
we need to provide mailto:[email-masked], and yet another folder
on the web pages.  All ADs get to hear about all incoming liaisons, and
if they think it's appropriate for one of their WGs they forward it.
Done?

But this shouldn't be discussed on these lists anyway :-)

Delivery-date: Wed, 26 Feb 2003 11:12:24 -0800
Date: Wed, 26 Feb 2003 20:05:35 +0100
From: Loa Andersson <[email-masked]>
To: Scott Bradner <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

this might be a candidate for the understatement of the month :)

Scott Bradner wrote:

>>.Good point.  CCAMP has received liaison statements in the past and
>>we haven't really responded to them -
>>    
>>
>
>this was pointed out to me (again) this week :-)
>
>we (the IETF) need to work out a reliable way to respond to liaison
>statements
>
>Scott
>
My understanding of where we are now in this discussion it could be 
summarized as:

We need to document the (g)mpls-change process, most of this is in the
current draft. The concerns I've seen so far is on how and what could be 
accepted as
input to the process, that should be easily solvable.

We need to doucment the ietf way of responding to liasions.

It is my immediate reaction that this do not really belong in the same
document, if for no other reasons, at least for practical reasons. If 
there is a
strong motive to put them in the same document, I can live with that.

It has been pointed out that - inter-organization information, requests, 
suggestions
and communications are handled different by differnt organisations.

I think we should view the (g)mpls change process as IETF internal, and 
that we need
to add some text to explain how and when external documents sent to the 
ietf in
other format than IDs could and should be taken into the (g)mpls change 
process.

I will update the draft with some text addressing this, the darft won't 
be possible
to re-publish until after the IETF in SF, however we have allocated time 
on the ccamp
and mpls working group agendas for Ron to discuss the issues with this 
draft. I will
have this text ready in good time before this presentation.

/Loa

Envelope-to: [email-masked]
Delivery-date: Wed, 26 Feb 2003 01:45:37 -0800
Date: Wed, 26 Feb 2003 04:45:09 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: [email-masked], [email-masked]

>.Good point.  CCAMP has received liaison statements in the past and
> we haven't really responded to them -

this was pointed out to me (again) this week :-)

we (the IETF) need to work out a reliable way to respond to liaison
statements

Scott

Envelope-to: [email-masked]
Delivery-date: Wed, 26 Feb 2003 01:32:11 -0800
Date: Wed, 26 Feb 2003 04:29:18 -0500 (EST)
From: Scott  Bradner <[email-masked]>
Message-Id: <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

this ID was brought up in a meeting I am at in the ITU - there 
is some concern about it - I have asked that people with 
concerns please send their concerns in.

Scott

Delivery-date: Tue, 25 Feb 2003 15:41:01 -0800
Date: Tue, 25 Feb 2003 15:39:26 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: "Brungard, Deborah A, ALABS" <[email-masked]>
cc: [email-masked], "" <[email-masked]>
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Hi Deborah,

On Tue, 25 Feb 2003, Brungard, Deborah A, ALABS wrote:

> 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.

Good point.  CCAMP has received liaison statements in the past and
we haven't really responded to them -- in fact, I am not even sure
that there is a written process to handle liaison statements, nor a
well defined return channel.

Since this draft is about writing down processes, we should (a) figure
out how liaisons are handled; and (b) write that down as well.

Ron and I will have a pow-wow with the ADs and figure this out.

> 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.

Another good idea -- in line with the "new IETF with better visibility
and accountability" thrust.

Kireeti.

Delivery-date: Tue, 25 Feb 2003 15:22:27 -0800
content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Tue, 25 Feb 2003 18:19:55 -0500
From: "Brungard, Deborah A, ALABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

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: [email-masked] [mailto:[email-masked]]
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
=09
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.t=
xt

To remove yourself from the IETF Announcement list, send a message to=20
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=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt".
=09
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.
	=09
	=09
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Delivery-date: Mon, 24 Feb 2003 03:49:11 -0800
To: IETF-Announce: ;
CC: [email-masked], [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
Date: Mon, 24 Feb 2003 06:45:04 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: OSPF Extensions to Support Multi-Area Traffic 
                          Engineering
	Author(s)	: D. Cheng
	Filename	: draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt
	Pages		: 7
	Date		: 2003-2-21
	
The [MULTI-AREA] introduces a set of mechanisms that could be used
to construct LSPs that span multiple IS-IS/OSPF areas, where one 
scenario is to allow the head-end LSR to compute the path all the
way to the ABR in the tail-end area. This document proposes some
new OSPF extensions that can be used in supporting that scenario,
i.e., by leaking some of the useful information from individual 
areas to others, the constraint-based routing at the head-end LSR
of LSPs in OSPF networks with multiple areas can be optimized.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-01.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-cheng-ccamp-ospf-multiarea-te-extensions-01.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-01.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 24 Feb 2003 03:48:53 -0800
To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-douville-ccamp-gmpls-waveband-extensions-03.txt
Date: Mon, 24 Feb 2003 06:44:24 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Extensions to Generalized MPLS in support of Waveband 
                          Switching
	Author(s)	: R. Douville et al.
	Filename	: draft-douville-ccamp-gmpls-waveband-extensions-03.txt
	Pages		: 10
	Date		: 2003-2-21
	
Generalized MPLS (GMPLS) extends the MPLS control plane to encompass
layer 2, time-division, wavelength and spatial switching. A
functional description of the extensions to MPLS signaling needed to
support the new types of switching is provided in [RFC-3471]. On the
other hand, along with the current development on IP over optical
switching, considerable advances in optical transport systems based
on the multiple optical switching granularities have been developed.
[RFC-3471] currently defines two layers of optical granularity using
wavelengths and fibers. By introducing an extended definition of
waveband switching, this document specifies the corresponding GMPLS
extensions, to further integrate optical multi-granularity and
benefit from the features of the corresponding switching layers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-03.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-douville-ccamp-gmpls-waveband-extensions-03.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-03.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-douville-ccamp-gmpls-waveband-extensions-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 24 Feb 2003 03:01:34 -0800
Date: Mon, 24 Feb 2003 02:59:44 -0800 (PST)
From: Kireeti Kompella <[email-masked]>
To: Bob Braden <[email-masked]>
cc: [email-masked], "" <[email-masked]>, "" <[email-masked]>, "" <[email-masked]>
Subject: Re: IANA Considerations for RSVP

Hi Bob,

On Wed, 22 Jan 2003, Bob Braden wrote:

> There is a growing unease about IANA assignments of RSVP parameters --
> object numbers, CTypes, message types, and error numbers -- for new
> uses of RSVP.

To come back to your email, I should say that I am happy that someone
else is also concerned about this.

> 3. The IANA Considerations draft should be published as an RFC,
> 	perhaps after updating.

Scant hours from the cut-off, I just submitted an ID (rsvp-change) that is
basically new IANA Considerations for RSVP.  This is intended to get the
discussion rolling.  I would suggest to folks who intend to take part in
such a discussion to read Bob and Lixia's document at
http://www.isi.edu/rsvp/DOCUMENTS/IANAconsider.txt .

> 	(A) How to handle requests for RSVP assignments for
> 		extensions developed outside IETF?
>
> 	    Here is my suggestion:
>
> 		For all assignments of numbers for extensions defined
> 		in non-IETF standards bodies, the IANA should use
> 		assignment names (e.g., object names) that are prefixed
> 		with the name of the responsible standards body.  For
> 		example, the "SPIFFY_SESSION" object would become
> 		"ATM_FORUM_SPIFFY_SESSION" or "ITU-T_SPIFFY_SESSION",
> 		etc., object.

Not addressed in the rsvp-change ID, but should be.

> 	(B) What policies should be imposed?

The rsvp-change ID suggests three sets of spaces: Standards Action
(a standards track RFC is needed); Expert Review (used as the moral
equivalent of Experimental code points); and Private Use (no
registration).

> 	(C) What are the appropriate documentation requirements?

A lengthy discussion on the IETF mailing list still hasn't enlightened
me as to what "IETF Consensus" means.  Thus, the suggestion in the
rsvp-change ID is to use the "Standards Action" designation for code
points whose specification one cares about.

Kireeti.

Delivery-date: Sun, 23 Feb 2003 20:59:29 -0800
Date: Sun, 23 Feb 2003 22:55:16 -0600
From: Jonathan Sadler <[email-masked]>
Reply-To: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS  vto  Proposed Standard

Please consider the following comments on these drafts:
    draft-ietf-ccamp-gmpls-routing-05.txt
    draft-ietf-ccamp-ospf-gmpls-extensions-09.txt
Many of the comments are based on implementation experience.  These comments are
marked with a (*).

Jonathan Sadler

==========

1. In section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt, the operations for
Packet Switch Capable (PSC) are defined.  Reference is made to Minimum LSP bandwidth
for SDH encoding.  None of the examples in section 5 of
draft-ietf-ccamp-gmpls-routing-05.txt show how this field should filled.

2. The mechanism for showing relationships between server and client layers is not
generalized*.  Specifically:
  - Relationships between SONET/SDH layers (ISC type: TDM) are
    implicitly stated based on the Min and Max LSP bandwidth
    advertised*.  To quote draft-ietf-ccamp-gmpls-routing-05.txt:

     "On an interface having Standard SDH multiplexing, an LSP
      at priority p could reserve any bandwidth allowed by the
      branch of the SDH hierarchy, with the leaf and the root
      of the branch being defined by the Minimum LSP Bandwidth
      and the Maximum LSP Bandwidth at priority p."

    This requires node doing the route calculation to understand
    the G.707 multiplexing hierarchy.  Since LSP routing is source
    routed, it could be the node doing the route calculation
    doesn't understand G.707.

    Furthermore, the G.707 multiplexing hierarchy is not a simple
    tree.  For example VC-11 and VC-12 can be supported over VC-3
    as well as over VC-4.  Consequently, the definition provided
    does not allow a system to explicitly state which "branch" of
    the G.707 hierarchy should be followed.

  - Relationships between PSC-n (for IP switching) and SONET/SDH are
    explicitly specified on the encoding type specified in the PSC-n
    announcement*.  However, SONET/SDH is not a single layer.  It
    must be possible to identify if the PSC-n layer can be carried
    by a VC-11 trail, a VC-12 trail, a VC-3 trail, a VC-4 trail,
    or a VC-4-nc trail.

    Section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt tries
    to deal with this in the following paragraph:

     "On a PSC interface that supports Standard SDH encoding, an
      LSP at priority p could reserve any bandwidth allowed by
      the branch of the SDH hierarchy, with the leaf and the root
      of the branch being defined by the Minimum LSP Bandwidth
      and the Maximum LSP Bandwidth at priority p."

    The problem is this contradicts the following paragraph:

     "The Maximum LSP Bandwidth takes the place of the Maximum
      Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum
      Bandwidth is a single fixed value (usually simply the link
      capacity), Maximum LSP Bandwidth is carried per priority,
      and may vary as LSPs are set up and torn down."
    Specifically, how does a completely available OC-48 interface
    with VC-11 over VC-3, VC-3, and VC-4 get encoded?  Based on
    the first paragraph, the encoding would be MinLSPBW=1.5M, and
    MaxLSPBW[p]=155M.  Ignoring the issue that VC-11 over VC-4
    ends up being shown as supported, the second paragraph states
    that the MaxLSPBW[p] should be 2.5G.

    Knowing the OC-48 is completely available is useful information,
    as multiple VC-4s could be used in an LCAS group to support
    connections that need data rates over 155M*.

 - The mechanism does not support describing common muli-layer
   relationships such as IP over DS1 over VC-11 or IP over DS3
   over VC-3*.

 - Sometimes layer relationships are described in an "inverted"
   manner*. Section 5.1 of draft-ietf-ccamp-gmpls-routing-05.txt
   states:
     "STM-16 POS Interface on a LSR

          Interface Switching Capability Descriptor:
             Interface Switching Capability = PSC-1
             Encoding = SDH
             Max LSP Bandwidth[p] = 2.5 Gbps, for all p"

   Where PSC-1 is the client of an SDH (sic) server.

   Section 5.5 states:
      "Interface of an opaque OXC (SDH framed) with support for
       one lambda per port/interface"

      "   Interface Switching Capability Descriptor:
             Interface Switching Capability = LSC
             Encoding = SDH"

   In this case, SDH is a client of a wavelength server (LSC).
   However, unlike in section 5.1, the layer relationship is
   inverted.

3. Layer specific attributes are not supported*.  Specifically:
 - It is not possible to have a link with different costs at
   different layers (ex. VC-11, VC-4, VC4-4c).  The link cost
   is a tool used by network designers to bias traffic toward or
   away from specific links.

   Since different hardware platforms are optimized for different
   layers, the network designer may wish to bias traffic in a layer
   to use or avoid a platform that inefficiently supports a
   particular layer.  The announcement of a link in the layer may
   still be desirable to allow for diverse routing.

 - Many attributes discussed actually refer to a specific layer*.
   For example SRLG can be an MS-layer attribute that is inherited
   by all supported layers (VC-11, VC-12, VC-3, VC-4, VC-4-nc).
   Likewise Protection mechanisms supported can be specified at
   the MS-layer and the path layer.

   Knowing the specific layer the attributes exist at allow for
   higher quality routes to be developed*.  It can also allow for
   proper provisioning of upper layer functions, such as protection
   hold off timers*.

 - Combining layer specific attributes with layer relationships can
   provide a more efficient encoding mechanism than requiring
   separate link announcements per layer*.

4. The "TDM" Interface Switching Capability presumably includes
   layers other than SONET/SDH, such as PDH* (DS1, DS3, E1, E3) and
   G.709.  The interaction with these layers needs to be defined.

5. In many cases, 8 levels of priority are not necessary*.  A more
   compact encoding that has a bitfield stating the priority levels
   being announced would reduce the size of the announcement.

The IESG wrote:

> The IESG has received a request from the Common Control and Measurement
> Plane Working Group to consider publication of the following two
> Internet-Drafts as Proposed Standards:
>
> o Routing Extensions in Support of Generalized MPLS
>     <draft-ietf-ccamp-gmpls-routing-05.txt>
> o OSPF Extensions in Support of Generalized MPLS
>     <draft-ietf-ccamp-ospf-gmpls-extensions-09.txt>
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2003-2-24.
>
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-05.txt
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-09.txt

============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================

Delivery-date: Thu, 20 Feb 2003 16:47:53 -0800
From: "Roberto Albanese" <[email-masked]>
To: "CCAMP WG" <[email-masked]>
Subject: Error Code Info
Date: Wed, 19 Feb 2003 19:29:02 +0100

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi all,
can anyone solve my doubts, please?
I'd like to implement a link-failure functionality in a MPLS architecture
using RSVP. I'd like to do this using a PathErr message i forward towards
the SENDER node of the LSP. In this PathErr i put the only information:
link-failure event occurred to LSP.
I saw that there is an ERROR_SPEC Object with error code and values i can
use, but i haven't found any proposal about what error code to use.
Have you any? Is there a standard error code i haven't seen?
What error code could i use?
If there is not even one proposed  i can use only an unassigned/private
error code. What are the private error codes i can use?

Thanks in advance for your kind answer

Roberto Albanese

Delivery-date: Thu, 20 Feb 2003 07:54:36 -0800
Date: Thu, 20 Feb 2003 16:51:43 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: [email-masked]
CC: [email-masked]
Subject: Re: Question about gmpls-recovery-terminology draft

hi,

the relationship is detailed in the proceedings:

http://www.ietf.org/proceedings/02nov/slides/ccamp-8/index.html
http://www.ietf.org/proceedings/02nov/slides/ccamp-8/sld2.htm

the last status report can be found at:

http://psg.com/lists/ccamp/ccamp.2002/msg01243.html

we also plan to submit a new status report very soon,

hope this will help you,
- dimitri.

[email-masked] wrote:
> 
> Dimitri,
> 
> Thank you for your answer. I found a similar explanation in 5.4.1 of
> the gmpls-recovery-analysis draft as well. Could you tell me how those
> drafts
> (recovery-analysis, recovery-functional and recovery-terminology) interacts
> each other?
> 
> Takao
> 
> On Thursday, February 20, 2003 1:51 PM, [email-masked]
> [SMTP:[email-masked]] wrote:
> > hi,
> >
> > normally in section 7 "restoration schemes"
> > which will be completed once other i-d's
> > are finalized - note that more description
> > of this can be found in section 3.3 of
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-
> > functional-00.txt
> >
> > thanks,
> > - dimitri.
> >
> > [email-masked] wrote:
> > >
> > > Think about the following scenario.
> > >
> > > A  *-------------* B
> > >    |             |
> > > C  *-------------* D
> > >    |             |
> > > E  *-------------* F
> > >
> > > Two working paths are established between A-B and E-F.
> > > The protection path for A-B is A-C-D-B.
> > > The protection path for E-F is E-C-D-F.
> > > Since the two working paths are disjointed,
> > > the protection resource between C and D is common,
> > > i.e. shared by two working paths.
> > >
> > > My question is where does this protection/restoration method
> > > fit in the gmpls-recovery-terminology document?
> > >
> > > Takao
> >
> > --
> > Papadimitriou Dimitri
> > E-mail : [email-masked]
> > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> > E-mail : [email-masked]
> > Public : http://psg.com/~dpapadimitriou/
> > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> > Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Thu, 20 Feb 2003 06:37:49 -0800
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Question about gmpls-recovery-terminology draft
Date: Thu, 20 Feb 2003 14:36:03 -0000
content-class: urn:content-classes:message

Dimitri, 

Thank you for your answer. I found a similar explanation in 5.4.1 of 
the gmpls-recovery-analysis draft as well. Could you tell me how those
drafts 
(recovery-analysis, recovery-functional and recovery-terminology) interacts
each other?

Takao

On Thursday, February 20, 2003 1:51 PM, [email-masked]
[SMTP:[email-masked]] wrote:
> hi,
> 
> normally in section 7 "restoration schemes"
> which will be completed once other i-d's 
> are finalized - note that more description 
> of this can be found in section 3.3 of
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-
> functional-00.txt
> 
> thanks,
> - dimitri.
> 
> [email-masked] wrote:
> > 
> > Think about the following scenario.
> > 
> > A  *-------------* B
> >    |             |
> > C  *-------------* D
> >    |             |
> > E  *-------------* F
> > 
> > Two working paths are established between A-B and E-F.
> > The protection path for A-B is A-C-D-B.
> > The protection path for E-F is E-C-D-F.
> > Since the two working paths are disjointed,
> > the protection resource between C and D is common,
> > i.e. shared by two working paths.
> > 
> > My question is where does this protection/restoration method
> > fit in the gmpls-recovery-terminology document?
> > 
> > Takao
> 
> -- 
> Papadimitriou Dimitri 
> E-mail : [email-masked] 
> Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
> E-mail : [email-masked]
> Public : http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Thu, 20 Feb 2003 05:52:31 -0800
Date: Thu, 20 Feb 2003 14:50:35 +0100
From: [email-masked]
Organization: Optical Network Architecture (NTA - Antwerpen)
To: [email-masked]
CC: [email-masked]
Subject: Re: Question about gmpls-recovery-terminology draft

hi,

normally in section 7 "restoration schemes"
which will be completed once other i-d's 
are finalized - note that more description 
of this can be found in section 3.3 of

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-00.txt

thanks,
- dimitri.

[email-masked] wrote:
> 
> Think about the following scenario.
> 
> A  *-------------* B
>    |             |
> C  *-------------* D
>    |             |
> E  *-------------* F
> 
> Two working paths are established between A-B and E-F.
> The protection path for A-B is A-C-D-B.
> The protection path for E-F is E-C-D-F.
> Since the two working paths are disjointed,
> the protection resource between C and D is common,
> i.e. shared by two working paths.
> 
> My question is where does this protection/restoration method
> fit in the gmpls-recovery-terminology document?
> 
> Takao

-- 
Papadimitriou Dimitri 
E-mail : [email-masked] 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : [email-masked]
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : Work: +32 3 2408491 - Home: +32 2 3434361

Delivery-date: Thu, 20 Feb 2003 05:39:38 -0800
From: [email-masked]
To: [email-masked]
Subject: Question about gmpls-recovery-terminology draft
Date: Thu, 20 Feb 2003 13:36:10 -0000
content-class: urn:content-classes:message

Think about the following scenario.

A  *-------------* B
   |             |
C  *-------------* D
   |             | 
E  *-------------* F

Two working paths are established between A-B and E-F.
The protection path for A-B is A-C-D-B.
The protection path for E-F is E-C-D-F.
Since the two working paths are disjointed,
the protection resource between C and D is common, 
i.e. shared by two working paths.

My question is where does this protection/restoration method 
fit in the gmpls-recovery-terminology document?

Takao

Delivery-date: Thu, 20 Feb 2003 00:18:59 -0800
Date: Thu, 20 Feb 2003 00:15:50 -0800 (PST)
From: Sameer K <[email-masked]>
Subject: RFC 3471: IF ID specification WRT component link.
To: [email-masked], [email-masked]

Hello All,

>From the RFC 3471 - GMPLS Signaling Functional
Description, Section 9.1.1, it appears that there is
no way for upstream node, to specify component links
that are numbered, in the IF-ID HOP object.

The TLV format for IF-ID Types 4 and 5 assumes that
the component link is always un-numbered.

Is this the way it was planned to be?.  If yes, then
what should IF-ID look like for numbered component
link (which is a valid scenario per the Link Bundling
draft).

Or did I get it all wrong?
TIA
- Sameer

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Delivery-date: Thu, 20 Feb 2003 00:12:28 -0800
Date: Thu, 20 Feb 2003 00:07:47 -0800 (PST)
From: Sameer K <[email-masked]>
Subject: RE: Regarding Switching capability and GPID in OSPF-TE and GMPLS- RSVP
To: Charles Chen <[email-masked]>, [email-masked], [email-masked]

Thanks for the clarification Charles.  I understand
that this is not an issue for overlay network model
where the peering NEs at each individual layer (in
our example, the routers) have an understanding of
the "layer resources" and interfaces at the same
layer.

But does this argument stay valid for peering model as
well?

- Sameer
 
--- Charles Chen <[email-masked]> wrote:
> It is an interesting question to ask, but it may not
> be an issue in the real
> world. In your example, one can assume that a router
> A would like to ask the
> transport network to set up a PPP link dynamically
> to a remote router B.
> Let's put this in the overlay mode perspective, the
> router A (edge device)
> will request a connection to a core device (OXC). In
> reality, the router A
> has some prior knowledge or is driven by the traffic
> engineering policy that
> it wants to connect to the remote router B. At the
> minimum, the router A has
> to provide the information about the router B
> (destination address in the
> transport network), the path constraints and so on.
> 
> It is not possible to build a network that provides
> all possible application
> level information.  The above issue makes no
> difference from that a user A
> establishes a UDP connection in order to transmit
> JPEG video over it to a
> user B. The user A finds out later that the
> receiving user B only supports
> the MPEG coding scheme. Yes, it is a blocking model
> but scalable.
> 
> Charles
> 
> > -----Original Message-----
> > From: Sameer K [mailto:[email-masked]]
> > Sent: Thursday, February 13, 2003 3:01 PM
> > To: [email-masked]; [email-masked]
> > Subject: Regarding Switching capability and GPID
> in OSPF-TE and
> > GMPLS-RSVP
> > 
> > 
> > Hello All,
> > 
> > I have some questions regarding switching
> capability
> > descriptor, encoding type and GPID parameters, and
> the
> > correlation between the values signaled in
> signaling
> > request and the values advertised in OSPF TE LSAs.
> > 
> > From the previous discussions, it appears that if
> a
> > data capable device has to establish LSP through a
> > network of OXCs, the switching type requested
> would be
> > FSC, the encoding type would be SDH/SONET with
> GPID
> > being PPP (assuming that the data device that is
> LSP
> > ingress wants to send IP data over the LSP).  Now,
> the
> > LSP will be established without any problem as
> long as
> > the destination node is advertising a switching
> > capability FSC and the encoding type SONET/SDH for
> all
> > its interfaces.
> > 
> > However, for the LSP to be of any use to ingress
> node,
> > the destination must be capable of terminating PPP
> > (which in turn requires data capability on the
> > incoming interface of egress node).  The way to
> ensure
> > this would be to read GPID and then egress can
> reject
> > the LSP if it cannot support the GPID.
> > 
> > However, what if destination is a multi-service
> switch
> > and bears certain interfaces that are FSC capable
> and
> > can terminate PPP as well (that is, support data
> over
> > FSC -if you will), other than the FSC only
> interfaces.
> >  CSPF running at ingress can never tell the
> difference
> > between these (data over FSC type) interfaces and
> > other (FSC only) interfaces and the LSP might end
> up
> > on an interface that cannot support PPP
> termination. 
> > In such a case, even though the node supports PPP
> at
> > certain interfaces, the LSP will have to be
> rejected.
> > 
> > 
> > Now, if some "higher layer" information (PPP
> > termination capability for this example), is
> > advertised as a part of OSPF TE LSAs, the CSPF
> running
> > on the ingress node can pick up the correct
> incoming
> > interface on egress node based on the GPID
> desired,
> > thus reducing the probability of LSP failures.
> > 
> > Would like to hear opinions.
> > TIA
> > - Sameer.
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Shopping - Send Flowers for Valentine's Day
> > http://shopping.yahoo.com
> > 
> 

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Delivery-date: Wed, 19 Feb 2003 19:45:29 -0800
Date: Wed, 19 Feb 2003 22:43:44 -0500
To: [email-masked]
From: "Siva Sivabalan (msiva)" <[email-masked]>
Subject: Question on draft-ietf-ccamp-gmpls-routing-05.txt

Hi all,

In section 4.4.2 draft-ietf-ccamp-gmpls-routing-05.txt, Max LSP Bandwidth 
has been
defined for PSC capable link as follows:

    "For a simple (unbundled) link its Maximum LSP Bandwidth at priority p
    is defined to be the smaller of its unreserved bandwidth at priority
    p and its Maximum Reservable Bandwidth........"

For a link (simple), the initial value of unreserved bandwidth at any given 
priority is equal
to Maximum Reservable Bandwidth. Furthermore, unreserved bandwidth at any 
given priority
is always less than or equal to Maximum Reservable Bandwidth. If this is 
true, then Maximum LSP
Bandwidth at priority p is equal to unreserved bandwidth at priority p. Is 
it correct or am I missing
something ?

Thanks,

Siva 

Delivery-date: Wed, 19 Feb 2003 15:23:09 -0800
Date: Wed, 19 Feb 2003 18:19:35 +0100
Subject: =?iso-8859-1?Q?Info_about_code?=
From: "=?iso-8859-1?Q?[email-masked]?=" <[email-masked]>
To: "=?iso-8859-1?Q?ccamp?=" <[email-masked]>

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi all,=0D=0Ai'd like to know if there is an error code for ERROR_SPEC Ob=
ject in PathErr=0D=0Amessage for RSVP Protocol in case of link failure.=0D=
=0AIn example when i see that a link is down i'd like to send a PathErr w=
ith=0D=0Athis error code.=0D=0AI haven't found such a code or a proposal =
for this.=0D=0AHave i any free or personal code i can use if there isn't =
a dedicated one?=0D=0A=0D=0AThanks in advance for your kind answer=0D=0A=0D=
=0ARoberto Albanese=0D=0A

Delivery-date: Wed, 19 Feb 2003 04:11:08 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-sdhsonet-control-02.txt
Date: Wed, 19 Feb 2003 07:03:50 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Framework for GMPLS-based Control of SDH/SONET 
                          Networks
	Author(s)	: G. Bernstein, E. Mannie, V. Sharma
	Filename	: draft-ietf-ccamp-sdhsonet-control-02.txt
	Pages		: 26
	Date		: 2003-2-14
	
The suite of protocols that defines Multi-Protocol Label Switching 
(MPLS) is in the process of enhancement to generalize its 
applicability to the control of non-packet based switching, that is, 
optical switching.  One area of prime consideration is to use these 
generalized MPLS (GMPLS) protocols in upgrading the control plane of 
optical transport networks.  This document illustrates this process 
by describing those extensions to MPLS protocols that are directed 
towards controlling SONET/SDH networks.  SONET/SDH networks make 
very good examples of this process since they possess a rich 
multiplex structure, a variety of protection/restoration options, 
are well defined, and are widely deployed. The document discusses 
extensions to MPLS routing protocols to disseminate information 
needed in transport path computation and network operations, 
together with the extensions to MPLS label distribution protocols 
needed for the provisioning of transport circuits. New capabilities 
that an MPLS control plane would bring to SONET/SDH networks, such 
as new restoration methods and multi-layer circuit establishment, 
are also discussed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-02.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-ietf-ccamp-sdhsonet-control-02.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-02.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-sdhsonet-control-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Fri, 14 Feb 2003 14:17:55 -0800
Date: Fri, 14 Feb 2003 23:13:07 +0100
From: Loa Andersson <[email-masked]>
To: "Andrew G. Malis" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Andy,

when writing the draft we briefly discussed whether to mention pwe3 or not,
I gather that ther were different reasons for different people not to. 
The mpls
and ccamp wg-chairs and the SubIP ADs had discussed the process for some 
time,
on my part I did not want to delay publication by throwing this on the pwe3
chair just minutes before the prublication.

I also think that there is an issue that pwe3 is not squarely within what
we define as (G)MPLS technology, pwe3 is an end to end technology and that
is why it is in transport.

This could be splitting hairs by an axe, we took the decision to publish
to get the type of reaction you given us here. The draft is out there to be
discussed.

If the pwe3 were to take up those extensions to ldp today, we would ask for
problem description and requirments, on my part it is not my intention 
(and I
don't think of any of the other authors) to retro-engineer existing work to
fit the process.

You might have noticed that I gave Jerry Ash the same answer when he 
suggested
that the mpls should take up work on header compression over mpls. But 
since his
work is not accepted or rejected yet, give us as much of the information as
possible in the format we want to have in the change process. Though he has
a certain freedom here.

pwe3 in specifying extensions to ldp, would be a "protocol specifying 
working
group", but note that this does not automatically transmorgraphies it into a
(g)mpls technology working group.

If you suggest that the pwe3 wg should be included as one of the (g)mpls 
technology
working groups, then I suggest that you give us text to be  discussed and
if a consensus is reached included in the draft.

Personally I would like to hear the transport ADs and pwe3 wg chairs opinion
on this.

Strictly I don't think we can require that people follow the process until
the IESG has OKed it, but as a wg chair I can clearly have an opinion on how
and where work on protocols specified by the mpls wg are done and how the
mpls wg takes on new work.

To avoid cross-posts I suggest that we taken the discussion on the
draft-andersson-mpls-g-chng-proc-00.txt on the mpls list :). We will 
allocate
time in both the mpls and ccamp working group meetings in SF to discuss 
this.

/Loa

Andrew G. Malis wrote:

> Loa,
>
> I assume that the mpls and ccamp lists are the appropriate places for 
> discussion of this draft.  I also included the pwe3 list, since this 
> also affects the work in that WG.  I apologize for the crossposts to 
> those of you on more than one of these lists (including myself).  
> Perhaps once the discussion has started, we can pick just one place to 
> continue it.
>
> My initial reaction on reading your draft was that I didn't see any 
> discussion of the pwe3 WG, which as you know is specifying extensions 
> to RFC 3036.  For the purposes of your draft, would pwe3 be classified 
> as a "protocol specifying working group"?  And is it your intention 
> that the current work in the pwe3 WG be approved by the "requirement 
> evaluating working group" prior to its documents being published as 
> RFCs?  Or would this be grandfathered in as already having been 
> chartered by the IESG?
>
> Thanks,
> Andy
>
> -------
>
> At 2/14/2003 06:43 AM -0500, [email-masked] wrote:
>
>> 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:
>>         [email-masked].
>> 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.
>> Content-Type: text/plain
>> Content-ID:     <[email-masked]>
>>
>> ENCODING mime
>> FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt
>>
>> <ftp://ftp.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt> 
>>
>
>
>
>

Delivery-date: Fri, 14 Feb 2003 13:22:20 -0800
Date: Fri, 14 Feb 2003 16:05:57 -0500
To: Loa Andersson <[email-masked]>
From: "Andrew G. Malis" <[email-masked]>
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Cc: [email-masked],[email-masked],[email-masked]

Loa,

I assume that the mpls and ccamp lists are the appropriate places for 
discussion of this draft.  I also included the pwe3 list, since this also 
affects the work in that WG.  I apologize for the crossposts to those of 
you on more than one of these lists (including myself).  Perhaps once the 
discussion has started, we can pick just one place to continue it.

My initial reaction on reading your draft was that I didn't see any 
discussion of the pwe3 WG, which as you know is specifying extensions to 
RFC 3036.  For the purposes of your draft, would pwe3 be classified as a 
"protocol specifying working group"?  And is it your intention that the 
current work in the pwe3 WG be approved by the "requirement evaluating 
working group" prior to its documents being published as RFCs?  Or would 
this be grandfathered in as already having been chartered by the IESG?

Thanks,
Andy

-------

At 2/14/2003 06:43 AM -0500, [email-masked] wrote:

>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:
>         [email-masked].
>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.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt>

Delivery-date: Thu, 13 Feb 2003 16:15:53 -0800
To: IETF-Announce: ;
Subject: RFC 3472 on Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Thu, 13 Feb 2003 16:11:47 -0800

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3472

        Title:      Generalized Multi-Protocol Label Switching (GMPLS)
                    Signaling Constraint-based Routed Label
                    Distribution Protocol (CR-LDP) Extensions
        Author(s):  P. Ashwood-Smith, L. Berger, Editors
        Status:     Standards Track
        Date:       January 2003
        Mailbox:    [email-masked], [email-masked]
        Pages:      23
        Characters: 49006
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-mpls-generalized-cr-ldp-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3472.txt

This document describes extensions to Multi-Protocol Label Switching
(MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP)
signaling required to support Generalized MPLS.  Generalized
MPLS extends the MPLS control plane to encompass time-division (e.g.,
Synchronous Optical Network and Synchronous Digital Hierarchy,
SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.,
incoming port or fiber to outgoing port or fiber).  This document
presents a CR-LDP specific description of the extensions.  A generic
functional description can be found in separate documents.

This document is a product of the Common Control and Measurement Plane
(ccamp) Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3472

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3472.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

Delivery-date: Thu, 13 Feb 2003 16:15:45 -0800
To: IETF-Announce: ;
Subject: RFC 3473 on Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Thu, 13 Feb 2003 16:14:03 -0800

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3473

        Title:      Generalized Multi-Protocol Label Switching (GMPLS)
                    Signaling Resource ReserVation Protocol-Traffic
                    Engineering (RSVP-TE) Extensions
        Author(s):  L. Berger, Editor
        Status:     Standards Track
        Date:       January 2003
        Mailbox:    [email-masked]
        Pages:      42
        Characters: 91808
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-mpls-generalized-rsvp-te-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3473.txt

This document describes extensions to Multi-Protocol Label Switching
(MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)
signaling required to support Generalized MPLS.  Generalized MPLS
extends the MPLS control plane to encompass time-division (e.g.,
Synchronous Optical Network and Synchronous Digital Hierarchy,
SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.,
incoming port or fiber to outgoing port or fiber).  This document
presents a RSVP-TE specific description of the extensions.  A generic
functional description can be found in separate documents.

This document is a product of the Common Control and Measurement Plane
(ccamp) Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3473

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3473.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

Delivery-date: Thu, 13 Feb 2003 16:00:38 -0800
To: IETF-Announce: ;
Subject: RFC 3471 on Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Thu, 13 Feb 2003 15:56:04 -0800

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3471

        Title:      Generalized Multi-Protocol Label Switching (GMPLS)
                    Signaling Functional Description
        Author(s):  L. Berger, Editor
        Status:     Standards Track
        Date:       January 2003
        Mailbox:    [email-masked]
        Pages:      34
        Characters: 72746
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-mpls-generalized-signaling-09.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3471.txt

This document describes extensions to Multi-Protocol Label Switching
(MPLS) signaling required to support Generalized MPLS.  Generalized
MPLS extends the MPLS control plane to encompass time-division (e.g.,
Synchronous Optical Network and Synchronous Digital Hierarchy,
SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g.,
incoming port or fiber to outgoing port or fiber).  This document
presents a functional description of the extensions.  Protocol
specific formats and mechanisms, and technology specific details are
specified in separate documents.

This document is a product of the Common Control Measurement Plane
(ccamp) Working Group of the IETF.

This is a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3471

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3471.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

Delivery-date: Thu, 13 Feb 2003 15:46:51 -0800
From: Charles Chen <[email-masked]>
To: 'Sameer K' <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Regarding Switching capability and GPID in OSPF-TE and GMPLS- RSVP
Date: Thu, 13 Feb 2003 15:45:55 -0800

It is an interesting question to ask, but it may not be an issue in the real
world. In your example, one can assume that a router A would like to ask the
transport network to set up a PPP link dynamically to a remote router B.
Let's put this in the overlay mode perspective, the router A (edge device)
will request a connection to a core device (OXC). In reality, the router A
has some prior knowledge or is driven by the traffic engineering policy that
it wants to connect to the remote router B. At the minimum, the router A has
to provide the information about the router B (destination address in the
transport network), the path constraints and so on.

It is not possible to build a network that provides all possible application
level information.  The above issue makes no difference from that a user A
establishes a UDP connection in order to transmit JPEG video over it to a
user B. The user A finds out later that the receiving user B only supports
the MPEG coding scheme. Yes, it is a blocking model but scalable.

Charles

> -----Original Message-----
> From: Sameer K [mailto:[email-masked]]
> Sent: Thursday, February 13, 2003 3:01 PM
> To: [email-masked]; [email-masked]
> Subject: Regarding Switching capability and GPID in OSPF-TE and
> GMPLS-RSVP
> 
> 
> Hello All,
> 
> I have some questions regarding switching capability
> descriptor, encoding type and GPID parameters, and the
> correlation between the values signaled in signaling
> request and the values advertised in OSPF TE LSAs.
> 
> From the previous discussions, it appears that if a
> data capable device has to establish LSP through a
> network of OXCs, the switching type requested would be
> FSC, the encoding type would be SDH/SONET with GPID
> being PPP (assuming that the data device that is LSP
> ingress wants to send IP data over the LSP).  Now, the
> LSP will be established without any problem as long as
> the destination node is advertising a switching
> capability FSC and the encoding type SONET/SDH for all
> its interfaces.
> 
> However, for the LSP to be of any use to ingress node,
> the destination must be capable of terminating PPP
> (which in turn requires data capability on the
> incoming interface of egress node).  The way to ensure
> this would be to read GPID and then egress can reject
> the LSP if it cannot support the GPID.
> 
> However, what if destination is a multi-service switch
> and bears certain interfaces that are FSC capable and
> can terminate PPP as well (that is, support data over
> FSC -if you will), other than the FSC only interfaces.
>  CSPF running at ingress can never tell the difference
> between these (data over FSC type) interfaces and
> other (FSC only) interfaces and the LSP might end up
> on an interface that cannot support PPP termination. 
> In such a case, even though the node supports PPP at
> certain interfaces, the LSP will have to be rejected.
> 
> 
> Now, if some "higher layer" information (PPP
> termination capability for this example), is
> advertised as a part of OSPF TE LSAs, the CSPF running
> on the ingress node can pick up the correct incoming
> interface on egress node based on the GPID desired,
> thus reducing the probability of LSP failures.
> 
> Would like to hear opinions.
> TIA
> - Sameer.
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Shopping - Send Flowers for Valentine's Day
> http://shopping.yahoo.com
> 

Delivery-date: Thu, 13 Feb 2003 15:02:58 -0800
Date: Thu, 13 Feb 2003 15:00:57 -0800 (PST)
From: Sameer K <[email-masked]>
Subject: Regarding Switching capability and GPID in OSPF-TE and GMPLS-RSVP
To: [email-masked], [email-masked]

Hello All,

I have some questions regarding switching capability
descriptor, encoding type and GPID parameters, and the
correlation between the values signaled in signaling
request and the values advertised in OSPF TE LSAs.

>From the previous discussions, it appears that if a
data capable device has to establish LSP through a
network of OXCs, the switching type requested would be
FSC, the encoding type would be SDH/SONET with GPID
being PPP (assuming that the data device that is LSP
ingress wants to send IP data over the LSP).  Now, the
LSP will be established without any problem as long as
the destination node is advertising a switching
capability FSC and the encoding type SONET/SDH for all
its interfaces.

However, for the LSP to be of any use to ingress node,
the destination must be capable of terminating PPP
(which in turn requires data capability on the
incoming interface of egress node).  The way to ensure
this would be to read GPID and then egress can reject
the LSP if it cannot support the GPID.

However, what if destination is a multi-service switch
and bears certain interfaces that are FSC capable and
can terminate PPP as well (that is, support data over
FSC -if you will), other than the FSC only interfaces.
 CSPF running at ingress can never tell the difference
between these (data over FSC type) interfaces and
other (FSC only) interfaces and the LSP might end up
on an interface that cannot support PPP termination. 
In such a case, even though the node supports PPP at
certain interfaces, the LSP will have to be rejected.

Now, if some "higher layer" information (PPP
termination capability for this example), is
advertised as a part of OSPF TE LSAs, the CSPF running
on the ingress node can pick up the correct incoming
interface on egress node based on the GPID desired,
thus reducing the probability of LSP failures.

Would like to hear opinions.
TIA
- Sameer.

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

Delivery-date: Tue, 11 Feb 2003 23:48:56 -0800
From: Heiles Juergen <[email-masked]>
To: "'Wijnen, Bert (Bert)'" <[email-masked]>, "Ccamp-wg (E-mail)" <[email-masked]>
Subject: AW: Last Call: Generalized Multiprotocol Label Switching Extensio ns  for SONET and SDH Control to Proposed Standard
Date: Wed, 12 Feb 2003 08:45:08 +0100

The signals that are part of the virtual concatenation are virtually =
concatenated.

Regards

Juergen

> -----Urspr=A8=B9ngliche Nachricht-----
> Von: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Gesendet: Dienstag, 11. Februar 2003 17:49
> An: Ccamp-wg (E-mail)
> Betreff: FW: Last Call: Generalized Multiprotocol Label=20
> Switching Extensio ns for SONET and SDH Control to Proposed Standard
>=20
>=20
> IESG received this comment. I guess the answer is: no difference
> right?
>=20
> Thanks,
> Bert=20
>=20
> -----Original Message-----
>=20
> I have some doubt with the following text about virtual =
concatenation.
> -----------------
> The standard definition for virtual concatenation allows each
>    virtual concatenation components to travel over diverse paths.
>    Within GMPLS, virtual concatenation components must travel over
>    the same (component) link if they are part of the same LSP. This
>    is due to the way that labels are bound to a (component) link.
>    Note however, that the routing of components on different paths is
>    indeed equivalent to establishing different LSPs, each one having
>    its own route. Several LSPs can be initiated and terminated
>    between the same nodes and their corresponding components can then
>    be associated together (i.e. virtually concatenated).
> ---------------
> I wonder what's the difference between "virtual=20
> concatenation" and "virtually concatenated"?
> Thanks!
>=20
> rick
>=20

Delivery-date: Tue, 11 Feb 2003 08:50:22 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: FW: Last Call: Generalized Multiprotocol Label Switching Extensio ns  for SONET and SDH Control to Proposed Standard
Date: Tue, 11 Feb 2003 17:48:38 +0100

IESG received this comment. I guess the answer is: no difference
right?

Thanks,
Bert 

-----Original Message-----

I have some doubt with the following text about virtual concatenation.
-----------------
The standard definition for virtual concatenation allows each
   virtual concatenation components to travel over diverse paths.
   Within GMPLS, virtual concatenation components must travel over
   the same (component) link if they are part of the same LSP. This
   is due to the way that labels are bound to a (component) link.
   Note however, that the routing of components on different paths is
   indeed equivalent to establishing different LSPs, each one having
   its own route. Several LSPs can be initiated and terminated
   between the same nodes and their corresponding components can then
   be associated together (i.e. virtually concatenated).
---------------
I wonder what's the difference between "virtual concatenation" and "virtually concatenated"?
Thanks!

rick

Envelope-to: [email-masked]
Delivery-date: Mon, 10 Feb 2003 09:46:24 -0800
Message-Id: <[email-masked]>
To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Generalized Multiprotocol Label Switching Extensions  for SONET and SDH Control to Proposed Standard
Reply-to: [email-masked]
Date: Mon, 10 Feb 2003 12:42:06 -0500

The IESG has received a request from the Common Control and Measurement
Plane Working Group to consider Generalized Multiprotocol Label
Switching Extensions  for SONET and SDH Control
<draft-ietf-ccamp-gmpls-sonet-sdh-07.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2003-2-24.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-07.txt

Envelope-to: [email-masked]
Delivery-date: Mon, 10 Feb 2003 09:22:37 -0800
Message-Id: <[email-masked]>
To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard
Reply-to: [email-masked]
Date: Mon, 10 Feb 2003 12:17:23 -0500

The IESG has received a request from the Common Control and Measurement
Plane Working Group to consider publication of the following two
Internet-Drafts as Proposed Standards:

o Routing Extensions in Support of Generalized MPLS
    <draft-ietf-ccamp-gmpls-routing-05.txt>
o OSPF Extensions in Support of Generalized MPLS
    <draft-ietf-ccamp-ospf-gmpls-extensions-09.txt>

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2003-2-24.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-05.txt
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-09.txt

Delivery-date: Mon, 10 Feb 2003 04:48:39 -0800
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Ccamp-wg (E-mail)" <[email-masked]>
Subject: AD comments on: draft-ietf-ccamp-gmpls-sonet-sdh-07.txt
Date: Mon, 10 Feb 2003 13:47:19 +0100

All,

I have asked IESG secretariat to issue an IETF Last Call
for this document for PS. We have detached the 
sonet-sdh-extensions document from the "package" and it
will have to stand on its own. Remember that I am not
willing to defend the sonet-sdh-extensions signalling 
document if nobody can come up with documents (or ptrs to 
documents) that describe the technology to be signalled.

W.r.t. draft-ietf-ccamp-gmpls-sonet-sdh-07.txt I have
still a few nits. Pls consider them as the first comments
for the IETF Last Call process (so you can integrate
any edits with whatever needs to be done as a result of
IETF Last Call).

- Personal opinion... I find it disgusting that a list of
  contributors makes up the first 3 pages of the document.
  I wonder why you moved it to the front... If you want to
  keep it, I think it much better fits at the end.
  Nevertheless, I personally will not block it if this is
  what you want.

- At the bottom of section 1, remove the text about changes
  reb 6 to rev 7

- I see funny redmond characters
  - in first para on page 8
  - in footer on each page
  - in the references section, 1st reference
  - in Authors' Addresses section (title)
  - possibly at other places?
  You may want to fix that

- one but last para page 10: s/Others flags/Other flags/

- in the Security Considerations section, you may want to
  make clear that RFC3212 discusses security considerations
  for CR-LDP.

- In the IANA considerations... (but I bet IANA will ask for it)
  you better make it clear which assignments are in which name
  space. I personally would also repeat the actual code points
  to be assigned.

Thanks,
Bert 

Delivery-date: Sun, 09 Feb 2003 17:08:47 -0800
From: "Soo-Hyun Choi" <[email-masked]>
To: <[email-masked]>
Subject: [Test Message]
Date: Mon, 10 Feb 2003 10:06:35 +0900

Hi, ccamp-ers,

This is [TEST-MESSAGE]. For some reasons, the outgoing e-mail from our site
is always bounced.

I'm sorry if this bothered you.

SH-

Delivery-date: Sat, 08 Feb 2003 20:24:24 -0800
Date: Sat, 08 Feb 2003 23:21:14 -0500
From: Ron Bonica <[email-masked]>
Subject: Posted on behalf of Young Hwa Kim
To: [email-masked]

Folks,

The following message is posted on behalf of Young Hwa Kim. He attempted to
post this message several days ago, but for some reason, it didn't get
posted to the list.

                                                         Ron

=====================================================

Hi, all.
I'd like to discuss the control plane resilience via the mailing list and in
the next IETF meeting.
In current, we do not have works about the control plane resilience.
The current focus of resilience has been only on transport plane.
The draft-ietf-ccamp-gmpls-recovery-analysis-00.txt also describes as
follows:
"Here, the focus will only be on transport plane survivability and recovery
 issues and not on control plane resilience related aspects."
I do not think it means that control plane does not need to have features of
the control plane resilience.
In order to provide reliable control networks in relevant networks, the
control plane resilience is also important.
I think the first issue to handle the problem domain, called the control
plane resilience is whether the problem domain is related to the CCAMP
charter or not.

We could read the following in the CCAMP charter.
"Abstract link and path properties needed for link and path protection.
Define signaling mechanisms for path protection, diverse routing and fast
path restoration. Ensure that multi-layer path protection and restoration
functions are achievable using the defined signaling and measurement
protocols, either separately or in combination."

In the sentence above, I could not assure whether link and path protection
means only transport plane, or
transport plane and control plane together.
If the sentence means the former, the charter have to be updateted.
But, if the sentence means the latter, the one seems good as such.
I think the latter interpretation is appropriate to us  because the CCAMP
realm handle control plane.
If so, I'm free to get into discussion on the control plane resilience.
But, our current concerns are on transport plane.
Under this status, it may be not possible to discuss a protocol
specification for protecting control channels.
I think the work for a framework or requirements for protecting control
channels may be good as a starting point.
I'm looking forward your opinions.
If you're interested in the control plane resilience, please refer to
draft-kim-ccamp-cc-protection-01.txt.
The document has the abstract section such as the following:
Abstract
   This document proposes a protocol used to protect control channels
   between adjacent nodes in GMPLS. Control channels are used to carry
   several control packets that include signaling related, routing
   related, or link management related information. The protocol may
   be used not in in-fiber(or in-band) network configurations but in
   out-of-fiber(or out-of-band) network configurations.
   Because this proposal is a first document for specifying the protocol
   used to protect control channels, it has no full contents for the
   specification to be proposed. Instead, this document focuses on basic
   concepts, necessity and requirements to be analyzed for protecting
   control channels. If we agree to this proposal including necessity
   and requirements for protecting control channels, we may proceed
   further works for the protection of control channels.
Thank you for reading this email.
******************************************
Young Hwa Kim
Senior Member, Network Technology Lab., ETRI
Office No. : 82-42-860-5819
Fax No. : 82-42-860-6342
Email addr. : [email-masked]
******************************************

Delivery-date: Tue, 04 Feb 2003 03:49:47 -0800
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-functional-00.txt
Date: Tue, 04 Feb 2003 06:43:56 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized MPLS Recovery Functional Specification
	Author(s)	: J. Lang, B. Rajagopalan
	Filename	: draft-ietf-ccamp-gmpls-recovery-functional-00.txt
	Pages		: 19
	Date		: 2003-2-3
	
This document presents a functional description of the protocol 
extensions needed to support GMPLS-based recovery (i.e. protection 
and restoration). Protocol specific formats and mechanisms will be 
described in companion documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-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-ietf-ccamp-gmpls-recovery-functional-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-recovery-functional-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Mon, 03 Feb 2003 16:44:09 -0800
Date: Mon, 03 Feb 2003 19:42:09 -0500
From: Ron Bonica <[email-masked]>
Subject: FW: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003)
To: [email-masked]

fyi

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Internet-Drafts
> Administrator
> Sent: Monday, February 03, 2003 7:08 AM
> To: IETF-Announce:
> Subject: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21,
> 2003)
> 
> 
> 
> NOTE: There are two (2) Internet-Draft Cutoff dates
> 
> February 24th: Cutoff for Initial Submissions (new documents)
> 
> All initial submissions(-00) must be submitted by Monday, February 24th, 
> at 09:00 ET.  Initial submissions received after this time will NOT be
> made available in the Internet-Drafts directory, and will have to be
> resubmitted.
> 
>  
> As before, all initial submissions (-00.txt) with a filename beginning
> with a draft-ietf MUST be approved by the appropriate WG Chair prior to
> processing and announcing. WG Chair approval must be received by
> Monday, February 24th.
> 
>  Please do NOT wait until the last minute to submit.
> 
> Be advised: NO placeholders. Updates to initial submissions received
>             the week of February 24th will NOT be accepted.
> 
> March 3rd: FINAL Internet-Draft Cutoff
> 
> All revised Internet-Draft submissions must be submitted by Monday,
> March 3rd, 2003 at 09:00 ET.  Internet-Drafts received after this
> time will NOT be announced NOR made available in the Internet-Drafts
> Directories.
> 
> We will begin accepting Internet-Draft submissions the week of the
> meeting, though announcements will NOT be sent until the IETF meeting
> is over.
> 
> Thank you for your understanding and cooperation. Please do not hesitate
> to contact us if you have any questions or concenrs.
> 
> FYI: These and other significant dates can be found at
>       http://www.ietf.org/meetings/cutoff_dates_56.html
> 
>