[IPsec] #123: Proposal to remove the IANA tables from IKEv2bis

[Tero Kivinen <[e-mail]>]

Paul Hoffman writes:
> This has flummoxed a few reviewers. Tables such as those in section
> 3.3.2 are already out of date because things have been added since
> RFC 4306. I propose that we remove all these tables from IKEv2bis,
> and add notes pointing to the current IANA registries. I cannot see
> how doing this lookup will hurt developers: in fact, it forces them
> to actually look at the up-to-date tables. I can see how we might
> want to leave the tables in, but it really is confusing. 

I would be in favor of removing the tables which are updated
frequently, but I think most of the tables should still stay in the
IKEv2bis. For example I think IKEv2 exchange types, Next Payload
Types, Protocol ID, Transform type values etc should stay, but for
example tables like Transform type 1 (Encryption Algorithm) could
point to the IANA registry.

I.e if table is integral part of the protocol, then it should stay in
the IKEv2bis document, but if it is something like listing of crypto
algorithm etc, then it can be changed to point to the IANA registry.

Mostly that means that if the IANA registry has some other RFC(s) as
reference for the values in the registry (ENCR_3DES points ot RFC2451
etc, PRF_HMAC_MD5 points to RFC2104) then it it is useful to put
references to the IANA registry.

On the other hand if only references in the IANA registry is back to
the RFC4306 (or IKEv2bis document in future), then its bit pointless
to ask people to go to the iana registry to see that they should read
this document they are reading to get more information :-)

For examples of such registries are Next Payload Type, Transform Type
Values, IKEv2 Transform Attribute Types, IKEv2 Identification Payload
ID Types, IKEv2 Certificate Encodings...
-- 
[e-mail]