draft-ietf-ipsec-ikev2-iana-01.txt

[Tero Kivinen <kivinen@iki.fi>]

Michael Richardson writes:
> I have updated draft-ietf-ipsec-ikev2-iana-01.txt 
>   (available at: http://www.sandelman.ca/SSW/ietf/ipsec/ikev2/ until ID
> editor gets to it)

I think the section 4, might need little more text, it took at least
for me some time to realize that this change was for v1 registry, and
the reserved range matches the payload numbers allocated for the
IKEv2. 

>   IKEv2 Exchange types may created by Standards Action.

Do we really need standard action here, wouldn't the specification
required be enough. 

>   IKEv2 Payload Types may be allocated by Specification Required.

This is propably the first resource we are running out... We already
have 48 reserved numbers, and when extensions are made they quite
often want to use their own payloads... I still think the
specification required is the correct fr this. 

>   IKEv2 Proposal Substructure Protocol-IDs may be allocated by Standards Action.

Why standards action, why not specification required? I do not think
we are going to have too many of those, but on the other hand some of
those extensions might not be on standard track. I would suggest
specification required for this too.

>   IKEv2 Encryption Transform IDs may be allocated by expert review.
> 	The initial expert reviewer is REVIEW.

The RFC2434 says that "When a Designated Expert is used, documents
MUST NOT name the Designated Expert in the document itself; instead,
the name should be relayed to the appropriate IESG Area Director at
the time the document is sent to the IESG for approval." 

>   IKEv2 Diffie-Hellman, ECP and EC2N Transform IDs may be allocated by Spec Required. 

Why this is specification required instead of expert review like
crypto algorithms? In both cases some kind of specification is needed
to implement them, and I think expert review would be enough for this
too. 

>   IKEv2 Extended Sequence Numbers Transform IDs may be allocated by
>   IETF Consenus.
	       ^ typo in the document too..

Why IETF consensus? Specification required would propably be enough.
If I understand correctly the difference is that IETF consensus
requires the specification to be RFC, and specification required
allows other documents too... 

>   IKEv2 Security Protocol Identifiers may be allocated by Standards Action.

Again same as with proposal substructure protocol-IDs, I think
specification required would be enough. I can see that someone might
want to use IKE as a key exchange method for non-ipsec cases, where
the easiest way would be to use new protocol number for that, and if
it is not IP related protocol, then its documents might not be
standard track documents, or RFCs at all. Preventing duplicate numbers
in those cases might still be usefull, in case someone sometime define
way to transport that stuff on the internet too...

>   IKEv2 Configuration Payload Attribute Types may be allocated by Specification Required.

Here the expert review might also be enough. Perhaps the specification
required is still better. 

> At a previous time, kivinen@ssh.fi was proposed for "REVIEW", and was
> generally acceptable to many. I do not know if Kivinen is still able to
> perform this function.

I am available if requested. The RFC2434 says that reviewers are
appointed by the relevant Area Director of the IESG....
-- 
kivinen@iki.fi