At 11:42 AM +0300 11/27/09, Valery Smyslov wrote: >In my opinion, that would confuse people even more than now, for the >following reasons: > >1. Magic numbers would become splited between two sources (note, that not >all of them > are listed in IANA, for example payload types are, but Proposal and >Transform > substructures types are not, they are specified in the RFC only).
This is incorrect. The proposal is to remove the value numbers from the tables, not the figures that contain the substructures. Anything that is only in the RFC would obviously not be removed. >2. IANA registry already contains some very specific entries (like, for >example, > those that came from RFC4595) and their number will be increasing. I >think, > those numbers would confuse some implementers, who might be thinking > that they need to support all of them. If a developer does not know how to read the IANA tables, we are all in trouble. Nothing in the tables says "you must implement every thing in these tables", of course. Are you proposing that we get rid of the IANA registry altogether, or we hide it from developers? If not, how do you rectify this with your concern about confusion? I am now deeply concerned with this WG's relationship to the IANA registry. >3. Sometimes there might be difficulties in matching names from RFC with >IANA entries. > For example, IANA registry has an entry named ENCR_AES-CCM_8, but in > RFC5282 this algorithm is called AEAD_AES_128_CCM_SHORT_8. Are you sure > these names reference the same algorithm? I prefer to check their IDs in >RFC > and in IANA registry. This is a bug in the IANA registry that needs to be fixed. It is not related to the values being in the RFC. Tero has spent a lot of time trying to fix the registry, but clearly we need more effort here. I will certainly make sure that the names in the registry match those in RFC 4306, and that the exact names are used in IKEv2bis. >4. Some entries in Diffie-Hellman Group Transform IDs table do not really >assign > individual numbers, but instead point to other documens, even to RFC4306 >itself, > where the numbers are assigned. Again, I am concerned that you think we should get rid of the IANA registry. That is not how the IETF works. >By the way, some magic numbers in RFC4306 are present not only in tables, >but >in text also (for example Payload Types, TS Types). Do they need to be >removed >from text also? Yes, in my current draft, I already did that, and repeated the boilerplate. > 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. >I think, removing all magic numbers from the RFC would make implementing >less convinient Yes. >and more error-prone No. >, so I strongly support either "do >nothing" >approach, or Tero's suggestion. This is completely inconsistent. Tero's approach would lead you to need the IANA registry to implement IKEv2. >Those numbers won't change, so their >presence must not hurt, This is probably incorrect. In many WGs, when errors are found in old definitions, the error is corrected *and a new value is assigned*. That is the only way to assure interoperability. >just will make implementing of base protocol more >convinient. The goal of our work is clarity and interoperability, not convenience, particularly when the inconvenience is remedied by one extra lookup. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
