Subject: [Uta] WGLC for draft-ietf-uta-tls-for-email-03

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 2 Dec 2019 09:57:07 +0300

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.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 2 Dec 2019 02:32:44 -0500

> with the draft, please send a short message confirming this).

Ready, no issues.

-- 
    Viktor.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 17 Dec 2019 12:45:42 +0300

Hi,

the WGLC period is over. No objections were received regarding publication of this draft.

Regards,
Valery.

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Keith Moore <[email-masked]>
Date: Thu, 19 Dec 2019 12:35:20 -0500

> with the draft, please send a short message confirming this).

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.

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.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 20 Dec 2019 10:24:19 +0300

Hi Keith,

From: Uta [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: Thursday, December 19, 2019 8:35 PM
To: [email-masked]
Subject: Re: [Uta] WGLC for draft-ietf-uta-tls-for-email-03

Hi,

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.