At 12:19 AM +0300 11/30/09, Valery Smyslov wrote: >>>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. > >You probably speaks about "ideal" developers. I speak about real people. >I've seen a few cases when people implemented a bunch of really >unnecessary things just because "it was in standard".
We still agree, and your answer is still inconsistent. If you worry about those type of developers, then you must want to get rid of the IANA registry, because that is what is giving them the silly ideas. >Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not defined >in IANA. >For me this is inconsistent. Either change two abovementioned lines to: > >1 768-Bit MODP Group [RFC4306] >2 1024-Bit MODP Group [RFC4306] > >14 2048-Bit MODP Group [RFC3526] >15 3072-Bit MODP Group [RFC3526] >16 4096-Bit MODP Group [RFC3526] >17 6144-Bit MODP Group [RFC3526] >18 8192-Bit MODP Group [RFC3526] Sorry, I misunderstood what you were saying. Yes, that is a good suggestion; I'll make it happen. >>>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 fail to understand your logic here. You seem to want to have ability to >change >already assigned numbers in IKEv2 in the future (and for this purpose remove >them from RFC), but at the same time you seem to presume that other >groups will not ever change their numbers. I do not presume that. I presume that this WG is not concerned about it; otherwise, we would have created our own IANA registry for the EAP values we use. We didn't. >I fail to understand how removing values from the RFC will help >understanding the context for them. The context for the values is "they are assigned and maintained by IANA". It is not "they came from this RFC". You may not like that, but that's how the IETF works. >>>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. > >It's not hard, but what for? I see some drawbacks and I don't see >how it will help interoperability. Again: it helps interoperability if developers look in the IANA registry at the time of coding and see changes have been made to what they thought was true based only on reading an RFC. >>>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"). > >I didn't say I like it. I said I can bear it. Tero has suggested removing >values for Transform IDs only. Those values mostly are "external" to >IKEv2 logic, it just "transfers" them between network, policy module, >ipsec module and crypto module. Theoretically they should not affect >IKEv2 itself (*). That's why I can bear removing them. > >(*) Unfortunately, they do affect: AEAD algorithms require special >handling in construction proposals. But this is another story. >I've been thinking that introducing a new Transform type for >AEAD algorithms instead of reusing Encryption Algorithm Transform >would probably have made protocol simpler and cleaner, but that was that. Your second paragraph is a shining example of why this should have been done in RFC 4306, and why we should not presume that what we do in IKEv2bis will be held constant. >>>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. > >In any case base RFC will be updated. And the first thing one must do before >implementing any protocol is to find most recent RFC for it, including >all updates and erratas. This is natural way to go, and if one starts >implementing old RFC, then even if you manage to force him to go >to IANA for numbers, I doubt if he will get interoperable product. The IANA registry lists the current RFCs. Do you not think that is enough clue? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
