In this case 'the idea' was "we would like an option code point
assigned".
if that's all there is to the proposal, it should be rejected
out-of-hand without discussion.
who said that's all there was to the proposal? there was clearly a
proposed use. but the use factors into the question only to the
extent that we would want to ensure the codepoint will actually be
used (and not just a gratuitous request for codepoint assignment).
no. it's also important to evaluate the proposed extension for
technical soundness.
assuming we're happy the codepoint will be used, assign one. let
later deployment realities, and if necessary "don't do this"
style of RFCs, be the judge of whether the proposal (which uses
the codepoint) is a good idea.
in other words, allow the disease to spread before you try to fix it.
those are both valid concerns, but relatively minor concerns compared
to the potential for poorly designed IP options to have an adverse
effect on Internet interoperation, at any layer from 3 up.
and one stops that by refusing a unique codepoint?
one stops it by any means that is effective and available.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf