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.
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
