> On Oct 7, 2019, at 16:12, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > Hiya, > > On 07/10/2019 18:29, Rob Sayre wrote: >> On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> >> 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 > 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 > 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.
draft-ietf-rtcweb-security-arch shepherd hat on To ekr’s point, the decision to make that switch I think actually pre-dated me. But before I go off and dig up the history, I think we should consider what an "updates” in terms of draft-ietf-tls-oldversions-deprecate would be. First the 2119 requirement in draft-ietf-rtcweb-security-arch is as follows: All Implementations MUST support DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 curve [FIPS186]. The rest of the quote contains no 2119 language and is merely an informative statement: Earlier drafts of this specification required DTLS 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and at the time of this writing some implementations do not support DTLS 1.2; endpoints which support only DTLS 1.2 might encounter interoperability issues. So, draft-ietf-tls-oldversions-deprecate would say nothing about DTLS1.2 because DTLS1.2 is not being deprecated. It could update the informative statement to say something else, but it is a factual statement. Maybe changing the last sentence to say “... which support only DTLS 1.0 might encounter interoperability issues” sounds somehow better, but maybe this is better just leave it alone. spt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
