On Tue, Dec 13, 2022 at 10:36 AM, Paul Wouters <[email protected]> wrote:
> On Tue, 13 Dec 2022, Warren Kumari via Datatracker wrote: > > [speaking with author hat on] > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > > Be ye not afraid -- see > https://www.ietf.org/about/groups/iesg/statements/ > handling-ballot-positions/ on handling ballots, especially DISCUSS > ballots... > > > > Can the IETF actually deprecate / make a protocol historic? (as stated in > "Internet Key Exchange version 1 (IKEv1) has been deprecated" and "IKEv1 > has been moved to Historic status.") > > > I agree that **making the documents that describe these** be historic is > the right thing to do, and also that the IETF can strongly recommend that > people don't use/deploy/whatever IKEv1, but I don't really know if we (or > anyone) have the power to deprecate a protocol. We are not the protocol > police, and we cannot instruct people to e.g deploy protocol foo, so I > don't know if we can deprecate a protocol either -- but I suspect that this > might be because I don't actually know what "IKEv1 has been deprecated" > actually *means*. > > Again, I'm not trying to block what this document is attempting to *do*, > but rather make it clear what it is actually doing. > > What it means is that the IETF has stopped maintaining it. It will not > allow any new registrations into the related IANA registries and no new > work will be started on this protocol version. > Perhaps you could add something to the document saying that (or, even better, drop in a reference to an RFC that says that)? From Rob's ballot: "I do wonder exactly how well understood "deprecated" is in the wider community." - it's not just "in the wider community", because it wasn't clear to me *exactly* what it meant. > It does not make any recommendations to users or administrators on whether > they should stop running it and migrate, although it is a pretty strong > hint that this protocol is dying and it would be wise to move away from it. > > It also means that other documents that want to depend on IKE, have to > ensure it works (and references) IKEv2, not IKEv1. > > The IETF does not tell you which protocols to use or not use. However, > other organizations that do, often base their requirements on IETF > recommendations. This is where the IETF and others (eg NIST, PCI-DSS) play > a careful balancing act. The IETF tries to nudge people in the right > direction. But it is indeed not the protocol police. > Yes, we have the BCP series, which "endorses" technical information and "define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations." That isn't the IETF telling someone what to do, but it is basically standing up, pointing, and saying "This thing over here! We think that this is a good thing to do!". Note that the document itself does not deprecate anything. > Well, now I'm confused: "This document deprecates those unmentioned algorithms that are no longer advised but for which there are no known attacks resulting in their earlier deprecation." and "5. Deprecating obsolete algorithms This document deprecates the following algorithms: [...]" It cannot. Only the IESG can change a document static to historic. > I'm unclear if you are arguing that a document doesn't do anything until the IESG formally approves it", which feels like a very semantic point. We very commonly say that draft-ietf-foo-bar does X (e.g change registry policy), even if technically we mean "draft-ietf-foo-bar does X, but only after it has completed IETF LC and then IESG Eval and had all of the DISCUSSES addressed and then approved" Perhaps when you said "the document itself does not deprecate anything" you were meaning "does not make other documents historic, that is handled by the status-change document - https://datatracker.ietf.org/doc/status-change-ikev1-to-historic/ " ? See your other work item on the telechat where this is requested. > Yes. That is partly what drove me to this discussion — in that case, the document had originally said: "The document marks as historic…" and Pete Resnick (correctly) pointed out that document don't mark things as historic, and suggested the new text "The document deprecates the use of [..]" W > > Only after that request passes the IESG, can this document move further > and say that > "it has happened". > > > Paul >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
