Subject: [PCN] PCN Agenda @ Anaheim IETF

From: Kwok Ho Chan <[email-masked]>
Date: Tue, 09 Mar 2010 09:51:54 -0500

Hi Scott, Steven:
Can I have 15 minutes for the Encoding Comparison draft to discuss the changes
and to see if the document is in the right direction toward its completion.
Thanks!
-- Kwok --

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 10 Mar 2010 14:21:37 +0000

Scott,

Altho I've posted a couple of updated encoding drafts, I don't think 
I need to speak about them - no significant functional changes were made.

The main thing I would want to say is about how the decision on 
encodings will be affected by the changed status of 
draft-ietf-tsvwg-ecn-tunnel. But I'm sure Kwok's talk on the encoding 
comparison draft will cover that sufficiently, and I'll chip in as necessary.

Nonetheless, I ought to give the w-g an update on 
draft-ietf-tsvwg-ecn-tunnel, as there have been some significant 
changes during w-g review (don't worry, the benefits to PCN remain 
intact and have been slightly improved). Therefore can I request the 
following before Kwok's talk:

Presenter: Bob Briscoe
Draft: draft-ietf-tsvwg-ecn-tunnel-08
Duration: 10mins

Primary changes to ecn-tunnel since the Hiroshima IETF are:
- draft 04 is now 08.
- Two appendices gave full justification for why pre-existing 
tunnelling impeded PCN deployment. These are now marked for removal 
by the RFC Editor, but they remain in place during the review 
process, particularly for the Security Directorate review to save 
them having to read a load of PCN docs. Summaries of these appendices 
are now included in the main body.
- Tightened up loop-holes in normative text that might have allowed 
lazy implementers to claim compliance while still not supporting PCN 
(following comments from someone in the security community who wants 
PCN supported, but told me that most implementers don't bother to 
implement what IPsec RFC4301 already says they should do with the ECN field.)
- ECT(1) outer with Not-ECT inner to be forwarded as Not-ECT rather 
than dropped.
- Alarm removed for one codepoint combination that PCN planned to use 
(but allowed operators to configure alarms for combinations they deem 
are suspect).

Bob

At 14:51 09/03/2010, Kwok Ho Chan wrote:
>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design