Subject: Polling for two new working group I-Ds

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 13 Aug 2007 16:33:10 +0100

Hi,

In Chicago we considered the possibility of two new CCAMP drafts. Please 
give your opinions:

1. draft-chen-ccamp-isis-interas-te-extension-00.txt
This is a partner draft to draft-ietf-ccamp-ospf-interas-te-extension-00.txt
The draft was discussed at the ISIS working group and several questions of 
detail were raised.
Thus, accepting this I-D now, does not imply that we would not change the 
mechanism.

2. draft-nadeau-ccamp-gmpls-oam-requirements-01.txt
This work is a charter milestone, and Deborah and I are both co-authors, so 
we are likely to be influenced in favour of adoption. So please voice your 
opinions loud and clear.

Thanks,
Adrian

---

From: Wataru Imajuku <[email-masked]>
Date: Tue, 14 Aug 2007 09:57:55 +0900

Hi, Adrian

 Yes to all.

Best Regards
Wataru

At 00:33 07/08/14, Adrian Farrel wrote:
>Hi,
>
>In Chicago we considered the possibility of two new CCAMP drafts. Please give your opinions:
>
>The draft was discussed at the ISIS working group and several questions of detail were raised.
>Thus, accepting this I-D now, does not imply that we would not change the mechanism.
>
>This work is a charter milestone, and Deborah and I are both co-authors, so we are likely to be influenced in favour of adoption. So please voice your opinions loud and clear.
>
>Thanks,
>Adrian 

-------------------------------------
Wataru Imajuku@NTT Network Innovation Labs
TEL: +81-46-859-4315
FAX: +81-46-859-5541

---

From: JP Vasseur <[email-masked]>
Date: Tue, 14 Aug 2007 10:22:11 -0400

Hi,

> Thus, accepting this I-D now, does not imply that we would not  

Yes.

> This work is a charter milestone, and Deborah and I are both co- 
> authors, so we are likely to be influenced in favour of adoption.  
> So please voice your opinions loud and clear.
>

Yes.

Thanks.

JP.

---

From: Young Lee <[email-masked]>
Date: Tue, 14 Aug 2007 10:50:44 -0500

I support both ID's. 

Young

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: Monday, August 13, 2007 10:33 AM
To: [email-masked]
Subject: Polling for two new working group I-Ds

Hi,

Thanks,
Adrian

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 14 Aug 2007 11:49:58 -0700

Yes to both.

Greg B.

Adrian Farrel wrote:
> This is a partner draft to 
> draft-ietf-ccamp-ospf-interas-te-extension-00.txt
> This work is a charter milestone, and Deborah and I are both 
> co-authors, so we are likely to be influenced in favour of adoption. 

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: Dan Li <[email-masked]>
Date: Wed, 15 Aug 2007 08:59:34 +0800

Yes to both I-Ds.

Dan

---

From: "tom.petch" <[email-masked]>
Date: Fri, 17 Aug 2007 15:54:36 +0200

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Monday, August 13, 2007 5:33 PM
Subject: Polling for two new working group I-Ds

> we are likely to be influenced in favour of adoption. So please voice your

Mmmmm ... I agree that this will, most likely, be the basis of the charter
milestone but it does seem to lack clarity and consistency, especially from
about 4.3 onwards.  From many possible examples,

- if the reader is assumed to be familiar with [RFC3945, RFC4377] then I expect
those to be normative references.

- are requirements subject to RFC2119? I've seen this argued both ways recently;
here the approach seems to be 'yes' up to 4.2.3, 'no' for 4.3 onwards

-  "... between control planes of different layers.  For the operational
convenience,

4.10 Support for OAM Interworking for Fault Notification ..."

Am I missing something?

- "4.3 Interaction between the GMPLS Control Plane and Data Plane. ...The
operational state of one plane should be automatically reflected to that of
another plane. "

Reflecting control plane operational state to data plane does not sound like OAM
as I understand it.  Like, does that mean when the control plane goes down, the
data plane is taken down:-(?

 -" 4.2.2 The Management plane SHALL provide the capability to verify routing
consistency in the control plane with the data plane."

I am struggling to imagine what this is (especially given the emphasis elsewhere
in this document on the separation of data and control planes).

-  "4.2.1 The change of recovery type of LSPs is required, for example, from
unprotected to 1+1 protected LSP, or from full LSP rerouting to pre-planned LSP
rerouting. Other capabilities include changing a recovery type of LSPs [RFC4426,
Segment]"

What is the difference between 'the change of recovery type of LSPs' and
'changing a recovery type of LSPs' (apart from one being a noun and the other a
verbal noun)?

Like I said, mmmmmmm

Tom Petch