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... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
