Paul Hoffman writes: > 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.
Then we are already in trouble. There is lots of developers who do not know about the IANA tables, they just grab the RFCs (without knowing about the IETF) and start to implement them. Not all developers follow IETF work, and quite a lot of developers do not know how IETF work, and what is the relation between IETF and IANA and so on. Also I do not think developers NEED to know the this kind of things, it should be enough for them to grab the documents and implement them. I do not think it is mandatory for them to understand what different IANA registration procedures mean. There is also lots of developers who do not know the difference between Informational RFC and Standard track RFC, and if they see numbers in the IANA registry they will think they should implement all of them. > I am now deeply concerned with this WG's relationship to the IANA > registry. We are not talking about the developers who are working on this WG. The whole world is not this WG, there is other people out there. Also I myself do find extra unnecessary indirections very annoying, and if possible, I try to avoid those. > >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 really a bug in IANA registry, as RFC4106 use those names, and it did allocate them. It is bug in the RFC5282, which should have used the same names for the same algorithms. On the other hand the rfc5282 do have table mapping the names it uses to the ENCR identifier numbers, and it DOES NOT have IANA actions for the Encryption Transform identifiers table, as those numbers have already been allocated before. > 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. On of the problems is the RFC4106 which predates IKEv2, which means it used completely different naming scheme than what was used in the rest of the documents, i.e. their algorithms do not have ENCR_* format, but is just text. I do not think we change that anymore. > >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. I do not think anybody proposed to get rid of the IANA registry. I think everybody agreed that yes, we should have pointer to the IANA registry. But as those numbers are never going to change, they should also be listed here. > >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. Which means they existing numbers are not going to change. There may be new numbers meaning almost same thing (but with fixed semantics), but the old number can only mean exactly what was meant at the time the RFC was written. > >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. Extra lookup which WILL cause more bugs, which means implementations are not interoperable. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
