On Thu, 8 Dec 2005, Frank Ellermann wrote:
The IESG did not consider this an appropriate action to take
in this case.
Well, you are wrong, and everybody can see it. If one draft
says "SHOULD do x", and another draft says "SHOULD NOT do x",
then something has to give.
There seem to be three options going forward:
1) make no changes to the spec. The spec (assumably) documents the
existing behaviour, even if it is conflicting.
2) make the spec to disallow that. The implementations are not
changed. The spec no longer documents the existing behaviour, and
the conflicts continue, but those who implement the spec aren't
allowed to say it's compliant (but no one is enforcing this in
any case, so....).
3) make the spec to disallow that. Someone convinces the
implementors to change their running code, and all the code is
actually changed.
Basically the IESG decided that accurate documentation of the running
code is more important than documenting something that does not exist,
and maybe never will exist.
That's certainly an understandable tradeoff to make, and it gets back
to the more philosophical role of the IETF: should it be OK to
document even disrupting running code, or should the IETF "just say
no" (and then we'd likely have no documentation of the running code
whatsoever).
Note: I have no knowledge whether the implementors would or would not
be willing to change the code.
--
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf