Scott W Brim wrote:
On 07/01/2005 13:02 PM, Ken Carlberg allegedly wrote:
My view is that your impression of the reaction is incorrect. in
taking the position that respondents can be classified as either:
a) being satisfied with the IESG *decision*, b) dissatisfied or
uncomfortable with the decision, or c) could not be clearly
determined by the content of their response, I came up with the
following list.
You can add me to the "satisfied" column. The IESG is asked to take
positions and to lead (despite what a few think). That's risky -- no
matter what they do they get criticism from somewhere. Maybe they
didn't *phrase* the announcement perfectly, but the decision is
correct. Something like this must have a serious, long-term IETF
review. We need to take the overall design of the Internet into
account and not just be administrators.
Add me to the "satisfied" column as well.
Much of the objection expressed on this list seems to have been not to
the decision itself, but that the way the decision was expressed by the
IESG appeared to preempt what the result of an IETF consensus process
would be. My opinion on this is that:
- the IESG is entitled to hold positions about the suitability of
particular proposals, and to express those positions publically and
forcefully. They should not be prevented or discouraged from doing
so by politics.
- if there are substantive objections to the grounds on which the IESG
approved or did not approve a request in any particular case, that is
what the appeals process is for.
- expressing the position that Dr. Robert's proposal would be unlikely
to reach IETF consensus *as part of the decision not to approve the request*
was arguably unwise.
Some people appear to want to use this case as a stepping-off point for a
campaign to liberalise the policies for allocation of code points in all or
most code spaces. This would effectively result in the prior decisions of
working groups and others as to what level of review is required in any
particular code space to be altered, without consulting those groups.
The idea that in general, allocating code points based only on availability
of documentation and not technical review must be harmless as long as
extension/option mechanisms are designed correctly, is dangerously naive.
As several posters have pointed out, the problem here is with extensions/
options that *are* implemented, not those that are ignored. A policy of
(essentially) rubber-stamping code point allocations would, in practice,
lead to more options with a marginal or poor usefulness/complexity trade-off,
that would nevertheless have to be implemented to ensure interoperability.
If the description of what IESG Approval should involve is unclear, then
that option, and that option only, should be clarified in an update to
RFC 2434. There are no grounds for any radical rethink of allocation
policies in general.
--
David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf