Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

[Pekka Savola <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf