Re: [TLS] Additional TLS 1.3 results from Chrome

[Stephen Farrell <[e-mail]>]

Hiya,

On 19/12/17 13:56, Salz, Rich wrote:
> “dropped as a bad idea” is an interesting end-state.  Also “on hold
> for now” (which is how I want to see the TLS-breaking proposals).
> 
> Having more I-D workflow options seems like something the IESG should
> take up.
> 

Well, TBH I doubt it'd be best done from the IESG down.

If some WG wanted to pursue this kind of thing, I'd say
it'd be much better done by the WG and then the IESG
could get to decide what they think if/when such a draft
is ever put forward by the WG for publication as an RFC.

And for most WGs, there's little danger in expired I-Ds
hanging about unchanged. For TLS, as we've seen in this
case, there might be a downside to the expired I-D not
containing text saying: "Don't do this! Really. And
<here's> why." :-)

As an aside, I'd say it'd be better to not think of
this as a retraction, but more as a case of ensuring
that the public record, as seen in the I-D repository,
better reflects the WG consensus, for the few cases
where there would be a concrete reason to not want
people to write or deploy code implementing the draft
concerned.

For a WG draft, the WG itself can always decide that
the right thing to happen is to publish a tombstone
draft, so that could be handled easily enough.

For a draft that's proposed for WG adoption, or that's
discussed but not adopted, it might get complicated, if
the authors don't agree that WG non-adoption is a good
reason to put out a tombstone. (We'd likely need the WG
to adopt the draft solely to put out the tombstone,
which'd be a bit weird.)

So as I said, I'm about half-convinced:-)

Cheers,
S.