On Tue, Dec 13, 2022 at 12:51 PM, Warren Kumari <[email protected]> wrote:
> 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. > Just following up before the telechat - if we agree to add a clarification I can clear. W > >> 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
