There have been attempts in the past to signal this to product planners:
SHOULD+ This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at
some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, an algorithm
marked as SHOULD- may be deprecated to a MAY in a future
version of this document.
MUST- This term means the same as MUST. However, we expect at
some point that this algorithm will no longer be a MUST in
a future document. Although its status will be determined
at a later time, it is reasonable to expect that if a
future revision of a document alters the status of a MUST-
algorithm, it will remain at least a SHOULD or a SHOULD-.
Russ
> On Dec 16, 2022, at 11:27 AM, Nimrod Aviram <[email protected]> wrote:
>
> > There needs to be some plan with a schedule that gives downstream users
> > time to get their act in gear.
> I agree. And the schedule should also allow for deprecation in a reasonable
> timeline.
>
> > Should there be an IETF group to help coordinate things like this?
> I think it'd be better if each group coordinates this for itself.
> We should do this, if we can. I would suggest "Intent to Deprecate" documents
> that e.g. make it clear that you cannot count on TLS 1.2 only in, say, 2030.
> Otherwise we'll have the same conversation around that deprecation then.
>
> Is there interest in this?
>
>
>
> On Fri, 16 Dec 2022 at 09:41, Hal Murray <[email protected]
> <mailto:halmurray%[email protected]>> wrote:
>
> [email protected] <mailto:[email protected]> said:
> > For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
> > endlessly keeping old cipher suites alive. The unwise cost-cutting in those
> > areas does not constrain the rest of the internet.
>
> Agreeded, but the software maintainers can't just drop support for X because
> it has been deprecated. There needs to be some plan with a schedule that
> gives downstream users time to get their act in gear.
>
> Should there be an IETF group to help coordinate things like this? If
> nothing
> else, there should be a RFC explaining the problem to vendors planning to
> ship
> software that can't be updated -- and showing their potential customers what
> to consider.
> Maybe data sheets should list the RFCs they depend upon -- with a big red
> arrow nwxt to the ones that have been obsoleted or deprecated.
>
> IoT and embedded are not the only problems. There are many companies that
> run
> old stable software. Ubuntu supports LTS releases for 5 years with 5 more
> available for a fee.
> https://ubuntu.com/about/release-cycle
> <https://ubuntu.com/about/release-cycle>
> Do we have to worry about this area? Or will the companies like Ubuntu take
> care of their customers?
>
>
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> TLS mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/tls
> <https://www.ietf.org/mailman/listinfo/tls>
> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
