Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

[Benjamin Kaduk <[e-mail]>]

On Mon, Oct 07, 2019 at 09:12:44PM +0100, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 07/10/2019 18:29, Rob Sayre wrote:
> > On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell <[e-mail]>
> > wrote:
> >> we can't "UPDATE" an I-D.
> >
> > Not true. If you need to refer to something that's been IESG-approved but
> > still in the RFC queue, you can leave a note for the RFC editor to update
> > the reference to the eventual RFC number.
> 
> That would be an UPDATE on the eventual RFC and not on the
> I-D. And in this case, it'd IMO not be a good plan as a) the

Recent IESGs have been taking the stance that it's weird to have "Updates:"
to a document that's not yet an RFC, mostly preferring to pull the document
in question back and get changed directly.  But ...

> relevant WG didn't want that, b) the I-D in question is part
> of a mega-cluster, so any dependency on it (as you suggest)
> risks loadsa delay if the cluster doesn't get unstuck, which
> can happen and c) our draft already stretches the header

... given that C238 is unblocked, dependencies-wise, that seems
questionable in this case.  (The whole set of documents does have to go
through the xmlv2-->xmlv3 conversion, though.)

> enough updating 85 RFCs - trying to add an I-D to that list
> would break tools and cause much pointless process-angst.
> 
> Mostly (a) is the reason to not do it though. If you want
> to disagree with (a), then the right list for that would be
> the rtcweb list I guess, even though the WG is now concluded
> (which could, I guess, be (d);-)
> 
> Overall, the cost isn't worth the benefit IMO.

That's roughly where I'm landing, too, though as noted previously, it's
largely up to the sponsoring AD.

-Ben