At 11:11 PM +0300 11/27/09, Valery Smyslov wrote: >Hi Paul, > >please, see inline. > >>>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? > >Not, of course. > >>If not, how do you rectify this with your concern about confusion? > >For someone, who spent quite a lot of time working in this area, it is not >difficult fo figure out what is really important and what is not. But, I think, >a newcomer could be confused by a long list of all possible numbers.
This answer is inconsistent, and that's the crux of the issue I have with your concern. We very much want developers to look at the IANA registry; it's the only way for them to know definitively what values will cause interoperability. Yet you say things like "a newcomer could be confused by a long list of all possible numbers". You can't have it both ways. >>>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. > >No, you didn't get the point. I meant that Diffie-Hellman Group Transform IDs >table >in two cases doesn't assign individual numbers, just ranges. For example: > >1-2 Defined in Appendix B [RFC4306] >14-18 Defined in [RFC3526] [RFC3526] > >So, in first case it just points back to RFC4306 Appendix B, where the actual >numbers (what is 1 and what is 2) are assigned. Probably it may (and must) >be changed, but in its current form it's ridiculos - you went to IANA for >real numbers and have found only pointer back to RFC4306 where you >just have come from... These are the full definition of the semantics of the groups. How would you change this? >>>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? Yes, but *only* if the names and numbers we use in this document match those exactly *and* the WG is willing to cede change control to the EAP methods we use to the IANA registry that we do not have input to. So far, the WG hasn't said they want to do that, so I don't presume to make that change. >>>I think, removing all magic numbers from the RFC would make implementing >>>less convinient >> >>Yes. >> >>>and more error-prone >> >>No. > >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. Correct. >Now you suggest to make IKEv2 not self-contained again. Correct, because we have already made many changes to the values that developers need to know. >Of course, I understand that IANA registry is not another RFC, but >I still prefer single self-contained document for core protocol. Of course, but your preference is at odds with the preference of someone reading the document needing to understand the context for the values. >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. Seriously: how hard is "two"? Any serious developer can go look at a second URL to get the values. >>>, 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. > >Tero's approach is a compromise. You will need the IANA only for >few types of magic numbers, most of which don't affect protocol >logic. I can leave with it. This seems inconsistent to me ("it's OK to need a second file for some things but not others"). >>>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. > >As far as I understand, in this case new RFC must be issued, >which will obsolete current one, won't it? If so, no contradiction. That is not true. The new RFC can update just a portion of the old one. That is how this is normally handled in the IETF. >>>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. > >Just out of curiosity: is such approach (removing magic numbers from RFC >completely) widely used in IETF? I do not know if our situation has ever happened in the IETF for a major protocol. I will ask around and report back on that. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
