On Tue, Nov 5, 2024 at 5:30 PM Jared Mauch <ja...@puck.nether.net> wrote:
> On Tue, Nov 05, 2024 at 02:09:44PM +0000, Steve Crocker wrote: > > Nick, > > Thanks. Even if the algorithm is just an encoding format, the same > issue > > applies: It's important that creating new messages with that algorithm > > must stop well before the receivers stop being able to receive > messages in > > that format. > > The point of the proposed life cycle model is that doing this smoothly > > takes multiple steps, not just one. After signalling to the community > > that an algorithm, encoding choice, etc. needs to be phased out, there > > needs to be some way to determine when usage has tailed off before > > removing the functionality for processing such messages is removed > from > > the receiving systems. > > My big concern when it comes to these things is losing access to > historical systems that perhaps don't support something more modern. My > iPhone1 (for example) still can connect to wifi etc but may not do > TLSv1.3, so even if I'm looking up the location of something that the > privacy folks would agree isn't sensitive, I still can't access that, > let alone use some of this historical software which may still work > fine. > > I worry about not getting the badly behaving software out of the > core is a problem, but I also worry about if we can or should provide an > interop translation layer. I see a lot of what is going on to be > related or similar to that. > > I assume that this is more related to the deprecation of algorithms than the terminology in the prefer pref64 over 7050 draft? Or am I mis-reading? > - Jared > >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
