Valery Smyslov writes: > >> What about EAP Message format and magic numbers? Remove and just > >> reference RFC3748 (or IANA entry for EAP)? > > > > No, those were left in because they came from an RFC, not from a > > particular IANA registry where the names match what we have in IKEv2bis. > > EAP numbers listed in RFC4306 might also be changed in future, > so from your logic it's better just to point to > http://www.iana.org/assignments/eap-numbers, right?
This is good example of confision what happens when you point to external iana registry. In RFC4306 we have "Nak (Response only)". If you look to the iana registry for eap, you cannot find that one. You do find "Legacy Nak". Are those two same? As both tables have also the number 2 associated to the code, you know they are same. Reading RFC3748 you notice that it uses both "Nak" and "Legacy Nak". > I don't agree with you. Remember, when IKEv2 was being developed, > one of the motivations for single self-contained document was complaint > from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1 > was very inconvinient and provoked confusions that led to interoperability > problems. Now you suggest to make IKEv2 not self-contained again. > Of course, I understand that IANA registry is not another RFC, but > I still prefer single self-contained document for core protocol. > If you need extensions - go to IANA and look for added numbers, > but core protocol must be implementable reading as few sources, > as possible, preferrably one. I completely agree on that. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
