Subject: Notes on pic-02

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 10 Jul 2001 15:55:00 -0700

Thanks again to the authors for doing this revision. I hope everyone 
on this list has read the document or intends to do so soon.

A few notes for the authors:

The document has a fair number of non-ASCII characters that do not 
render correctly on non-Windows machines (and probably some 
Windows-based machines as well).

The whole historical discussion will have to be revisited as we get 
closer to completion. Remember, this document will need to be able to 
make sense decades from now, long after all memories of the IPSRA 
charter arguments have been thankfully wiped from our minds.

In section 3.1, please add a note saying "This exchange type will 
change to a value between 6 and 31 when this document becomes an 
RFC." (The current value is in the private use area.)

Do we really want to use port 500 for PIC? For systems that combines 
gateways and ASs, this *forces* them to do both PIC and IKE in one 
piece of software.

In section 4.5, the extensive quoting from other documents makes it 
hard to follow the arguments. Could you cut the quotations but 
briefly summarize?

In the IANA considerations, please change "Next Payload identifiers" 
to "Payload identifiers". Yes, these appear in the "next payload" 
field, but they are really identifiers of the payloads themselves.

--Paul Hoffman, Director
--VPN Consortium

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 10 Jul 2001 19:13:24 -0400

> gateways and ASs, this *forces* them to do both PIC and IKE in one 

I definitely DO NOT want to reuse port 500 for this.

				- Bill

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 11 Jul 2001 13:30:47 +0300 (IDT)

> charter arguments have been thankfully wiped from our minds.

The text can always be refined and improved, but the discussion should be
there. For comparison, I wish IKE had some of this type of context and
rationale discussion. A lot of misunderstanding, arguments, and
out-of-context criticism would have been avoided. When you design security
by rough consensus you better document its "roughness" (or you'll keep
raising questions ten years from now too)

Hugo