Hi Keith,
From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Keith Moore Sent: Thursday, December 19, 2019 8:35 PM To: uta@ietf.org Subject: Re: [Uta] WGLC for draft-ietf-uta-tls-for-email-03 On 12/2/19 1:57 AM, Valery Smyslov wrote: Hi, this message starts a two weeks long Working Group Last Call for draft-ietf-uta-tls-for-email-03. The Last Call will end 16 December 2019. Please, send your opinions regarding publication of the draft to the list before this date (even if you have no problems with the draft, please send a short message confirming this). Regards, Valery. Yeah, I know this is after the Last Call expiration date. I have comments anyway. I have no objection to the technical content of the document, and generally believe it is correct. I appreciate that this document is expressed as a delta from RFC 8314, and that the deprecation of TLS 1.1 was not used as an excuse to revisit the entirety of RFC 8314. (Note that if RFC 8314 were older, and conditions had changed significantly since it was approved, a revisit might have been appropriate.) But in general, I wonder if this document is either necessary or appropriate. IMO, the approval and RFC publication of draft-ietf-tls-oldversions-deprecate should be sufficient. There is too much overhead in the process for approval and publication of RFCs, to revise an RFC every time some other RFC updates it. draft-ietf-tls-oldversions-deprecate lists seventy-nine RFCs that are updated by that document. Are all of those RFCs now going to be also updated by separate new documents in addition to the updating that's already being done by draft-ietf-tls-oldversions-deprecate? If not, why is RFC 8314 different from the other RFCs that are not being updated? I am concerned that approval of this document may set a poor precedent, and invite IETF and the RSE to do a lot of work of dubious value, spending energy that could better be applied to more useful work. I suspect that the RFC errata process might be a better fit for this kind of change, than the RFC publication process. I'm not objecting to publication of this document as an RFC. But I urge that the errata process be considered as an alternative, perhaps in this instance, but also when considering future updates. I don’t think that RFC errata process is a right way to go in this case. In my understanding publishing errata means that there was something wrong with the document from the very beginning. In this case RFC 8314 at the time it was published was correct regarding using TLS 1.1, but the circumstances have been changed since then. Regards, Valery. Keith p.s. I'd very much like for IETF to consider developing the technology to annotate existing RFCs - so that instead of revising an entire RFC, a WG could use an IETF Consensus process to approve annotations to the RFC. The original RFCs would not be altered - they would still be available and byte-for-byte identical with the originally published documents. But for the default display of the RFC from rfc-editor.org and ietf.org sites, the annotations would be visible along with the original text. Such annotations should be visually distinguished from the original RFC text (say using strikethroughs, italics, and changebars). In this way, but overhead of producing new RFCs for minor changes could be avoided. It would also be easier for RFC readers (including implementors and operators) to see exactly what changes had been made, and therefore, to quickly understand how implementations and operational decisions might need to change to reflect the new consensus.
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
