On Wed, Oct 9, 2019 at 8:00 PM Rob Sayre <say...@gmail.com> wrote: > On Wed, Oct 9, 2019 at 8:04 PM Eric Rescorla <e...@rtfm.com> wrote: > >> So, 6347 was totally reasonable at the time and I expect the guidance in >> this document to override 6347 which all seems quite normal. >> > > Right, that makes sense. > > >> >> draft-ietf-rtcweb-security arch doesn't precisely encourage you to >> implement DTLS 1.0; there's no normative language at all (even in the >> non-2119 sense). >> > > It does have a normative reference to RFC 6347, and seems to be > referencing this part of it: "Implementations that speak both DTLS 1.2 and > DTLS 1.0 can interoperate with those that speak only DTLS 1.0 (using DTLS > 1.0 of course)" >
Yes, but this section of 6347 will be overriden by the present document I can understand the WG's "MUST (but we know you won't)" situation. Trying > to write spec text for those situations always ends badly over time (imho), > but maybe editing the draft itself would be controversial. > > It does look like draft-ietf-tls-oldversions-deprecate should update the > draft, if it's changed so that it updates DTLS-using RFCs. For example, if > the document had been published in 2017, would there even be a debate? > Yes. You don't need to mark the transitive closure of all dependent RFCs as Updated. -Ekr > thanks, > Rob > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls