Harald,
I have no strong opinion about the IPv6 hop-by-hop header in question. But I don't want to (effectively) remove the ability to refuse registration - I think we'll pay a high price for that later.
I tend to agree. To me, "IESG Approval" in an IANA considerations text means that we expect the IESG to think about the allocation and its impacts, and to make a decision -- one way or the other. Not an automatic refusal, not an automatic granting. And not something based on just the availability of space -- otherwise we could have written FCFS in the text. Looks like the IESG did its job here. Having said that, I think the hbh header request deserves serious consideration. I have not reviewed the proposed scheme myself, so I can't say what the right decision would have been. In any case, it seems fair to write it up as a draft so that we can discuss more widely. In terms of strictness of allocation policies, stuff in IPv6 headers seems more important to guard than something in application layer protocols. Nevertheless, its easy to err on either side in the policies. Make it too easy, and we end up with potential interoperability issues. Make it too hard, and people find other, perhaps worse ways to do what they wanted to do. I could cite many examples of IETF work where too tight control has actually reduced the amount of quality control the IETF can have over our technology. Say, we develop protocol X to replace a bad protocol Y, but make X so tightly controlled that in practise we can't convince vendors to use it. Suddenly everyone is using protocol Y... --Jari _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf