Subject: Duplication: Remove most of section 3.3.2 and all of 3.3.4 of draft-ietf-ipsec-ikev2

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 10 Jun 2003 20:05:43 -0700

Hi again. Most of section 3.3.2 in draft-ietf-ipsec-ikev2 (almost) 
duplicates the text from Jeff's algorithms document. Everything in 
the section after the Transform Type Values table should be removed.

All of section 3.3.4 of draft-ietf-ipsec-ikev2 is now covered in 
Jeff's algorithms document. Thus, the whole section should be removed.

(Yes, this begs the question of whether or not anyone is reading the 
three documents at all...)

--Paul Hoffman, Director
--VPN Consortium

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 17 Jun 2003 23:43:39 -0400

> Jeff's algorithms document. Thus, the whole section should be removed.

None of the code points in the IKEV2 document are authoratative; that
honor belongs to the IANA registry.  Yet, they are useful because
there are a useful guide to initial implementors.  It is for that
reason that I believe a little duplication can be a good thing.

Otherwise, one could argue that all of the tables in IKEv2 are
duplicative of the IANA registry, and therefore aren't needed; we
should just establish the IANA registry and just delete all of the
tables from the I-D (and from every other RFC that has initial
codepoint values in them).

						- Ted

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 18 Jun 2003 09:49:27 -0700

At 11:43 PM -0400 6/17/03, Theodore Ts'o wrote:
>honor belongs to the IANA registry.

Very true.

>   Yet, they are useful because
>there are a useful guide to initial implementors.

Correct.

>   It is for that

If you have to read two RFCs in order to implement IKEv2, having some 
duplication between them doesn't help anyone. And having differences 
between the two RFCs for the same values is exactly wrong.

What you are proposing is exactly one of the mistakes that we had in 
IKEv1 that we said many times we wanted to avoid in IKEv2.

>codepoint values in them).

This isn't the way that the IETF works. New registries get 
established by RFCs that have values in them, and then can be 
expanded based on the rules established in the RFCs.

--Paul Hoffman, Director
--VPN Consortium

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 18 Jun 2003 22:57:21 -0700 (PDT)

> codepoint values in them).

FWIW, this position is consistent with a recent IESG decision that
initial versions of IANA-maintained MIB modules (which are a special
type of registry) shall be published in an RFC, but shall be
accompanied by a normative reference to the actual IANA registry URL
and a note stating that the version maintained in that registry is
the definitive one.

//cmh