The way I see it, the upcoming BCP applies to WebRTC irrespectively of whether it formally updates the document or not. The formal updates are important so people easily find the BCP, but not critical. Companies can anyway choose to implement WebRTC without implementing the BCP.
I do not think the BCP need to change any text in the WebRTC draft. The BCP updates a lot of other RFCs without changing the text in them. I do not think the TLS WG should ask the WebRTC working group for permission, the BCP updates a huge number of RFCs from a lot of different groups. These groups were not asked. I would like to see a formal update, but b) might be a valid reason to not do that. John From: Rob Sayre <say...@gmail.com> Date: Tuesday, 8 October 2019 at 07:02 To: Sean Turner <s...@sn3rd.com> Cc: "TLS@ietf.org" <tls@ietf.org>, IESG Secretary <iesg-secret...@ietf.org>, John Mattsson <john.matts...@ericsson.com>, "tls-cha...@ietf.org" <tls-cha...@ietf.org>, "draft-ietf-rtcweb-security-arch...@ietf.org" <draft-ietf-rtcweb-security-arch...@ietf.org>, Benjamin Kaduk <ka...@mit.edu> Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05 On Tue, Oct 8, 2019 at 7:31 AM Sean Turner <s...@sn3rd.com<mailto:s...@sn3rd.com>> wrote: 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. I think the relevant text from draft-ietf-tls-oldversions-deprecate is "Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347], [RFC6347]." The WebRTC text implies that it's ok to negotiate DTLS 1.0 [RFC4347], and certainly doesn't rule it out. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
