I was hoping others would comment, but maybe not. Inline.. On Fri, 4 Jun 2004, Bob Hinden wrote: > >Subcases 1) and 3) are too loose. Just make it 'IETF Consensus', > >'IESG Approval', or 'IESG Approval with Specification Required'. > > > >We really don't need a land-rush for ICMP types/codes. On the other > >hand, there is a valid need for pre-assignment. This would be worth > >having in-line with draft-kompella-zinin-early-allocation-01.txt. > > I don't think there is any evidence of a "land-rush" and even if there were > it's fairly trivial to expand the type range. The thinking behind this > approach is that as long as there is an open specification, there isn't any > compelling reason to limit allocations to IETF approval. > > The goal is to make it easy for a w.g. to get allocations early in the > process so people can get implementation experience and avoid collisions if > the protocol becomes widely deployed. Having to wait until there is IESG > approval makes it much harder or risky to do deployment.
I'm not sure if I agree. If you have an open specification, and if your use of types/codes is reasonable (e.g., you don't try to use 10 different types when you could just use one type and 10 codes), there should be no problem getting the ICMP types you want. Note that IESG approval does not require to submit the document to the IETF process; you can just send a mail to [EMAIL PROTECTED] with a pointer to the open specification and you might get your codepoint -- and this has the benefit that with the current process, any IETF RFCs already go past that point. I don't want to prevent the legitimate, well-designed use of ICMP types/codes, but I don't want to create rules which would allow anyone with an open specification to get e.g. 5 or 10 types (in that single document) if they tried to. Requiring IESG Approval is one way to obtain that. Some other WGs use "Expert Review". There may be other options. Just specifying e.g., "IESG Approval of an open specification" should be pretty close to what you're describing, but closer to RFC2434 language, and also more future-proof. > >Also note that you're burdening IANA with the responsibility of > >monitoring the assignment of type values and reporting back when > >they exceed a threshold. One could argue that IANA is too burdened > >as it > > While the IANA may or may not have resource issues, the "burden" placed on > the IANA is fairly trivial. If the allocations get to the 85% point, all > the IANA has to do is to ask to IETF to review the allocations. This > doesn't seem very burdensome to me. IMHO we won't ever get to that point > based on the history with the IPv4 ICMP allocations and IPv6 to date. Yes, this doesn't seem very burdensome, but it's still a new responsibility they'd have to be doing. Btw. the IANA considerations section doesn't seem to be specify the assignment policy for the code values for the existing ICMP types (see the last paragraph of 6.1). I guess these should be added in section 6.2. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
