> >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.
No, I didn't mean that. I meant that the simpler description of the protocol is, the better implementation is (usually) developed by an average person. In this context adding one more step in the process of developing may (and, I think, will) lead to increasing number of non-ineroperable implementations. I suspect, you may get just the opposite results than you expects. > >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. IANA doesn't assign any number by its own will - there must be request for that number and a corresponding RFC. And if this is a change to existing number, then this new RFC must either update base RFC or make it obsolete. Is it right? And even laziest developer will start implementing from finding the most recent RFC, updates and errata. > >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. Those changes don't come from IANA itself, they come from updating RFC. And it is this RFC, which developer starts implementing from, not IANA. And only after finding this RFC he/she will usually go to IANA. And making changes to already assigned values must be as rare as possible, because it automatically makes existing implementations non-compliant. On the other hand, adding new values usually doen't affect base protocol. > >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? No. RFC Editor Search Engine gives much more information regarding current status of RFC, existence of updates and errata. IANA is best for looking for protocol extensions, but it gives only current snapshot of the situation. If some values were changed, IANA wouldn't keep old references, and if you want to keep your product interoperable with previous versions, IANA won't help you. And if you remove number values from RFC, keepeng new products interoperable with previous in case of changing some assigned values will become next to impossible - you just will have no sources for old numbers. Regards, Smyslov Valery. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
