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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf