+1 as well. The problem of BCPs modifying standards needs to be addressed, but this is not the right context for that to happen. The operational considerations text that has been proposed is sufficiently curative that it is OK for this document to move forward with that addition. Ned > +1 (as a & discussant on RFC 1818 and as the editor of 2026 ) > Scott > > On Dec 9, 2020, at 12:23 AM, John C Klensin <john-ietf@xxxxxxx> wrote: > > > > (Changing the subject line and copying the IETF list for reasons > > that will become obvious. I hope that any follow-up will occur > > on the IETF list only.) > > > > --On Tuesday, December 8, 2020 19:38 -0500 Keith Moore > > <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > > > >>> I think it's clear from the fact that this document updates a > >>> pile of other documents and that we in fact have been > >>> looking at revisions to documents in the pipeline makes > >>> clear that it is intended to constrain implementations. > >>> We've done quite a number of other deprecation documents as > >>> BCP and to the best of my knowledge they have generally been > >>> read this way. > >> > >> Maybe that practice needs to change, because it is starting to > >> look like an end run around the standards process. > >> > >> I was just to the point of concluding that this document was > >> Mostly Harmless because it was only being LC'ed for BCP, and I > >> think it's somewhat reasonable as a statement of best > >> operational practice, but ONLY if it's confined to that scope. > >> > >> Now that you're claiming it is intended to constrain > >> implementations, I must strongly object to its publication in > >> its current form. > > > > Keith, > > > > First, thanks to Ben for what is, IMO, an excellent and fair > > summary. Period. Not "but..." or "let's continue litigating > > this already too-long thread". > > > > I believe that there has been a increasing tendency in recent > > years to use the BCP category for documents that, if 2026 were > > taken seriously, would be required to be ordinary Technical > > Specification or Applicability Statement documents. My reading > > of 2026 (including the paragraphs quoted by ekr) as well as the > > distinction I think you are making is that a BCP should never be > > used to alter the technical content of a standards track > > document. If we have a document, RFC NNNN that says "you MUST > > do this in so-and-so way", then a BCP that says "regardless of > > what RFC NNNN says, the best practice is to do it is this other > > way". That would (and, IMO, has) put us in the rather odd > > position of defining something as a Standard (even if only a > > "Proposed" one) and then turning around and saying "don't take > > our standards seriously". IMO, not good. > > > > Saying in a BCP "the MUST in that other spec may have been a > > little too strong" or "here a some circumstances in which a > > SHOULD does not apply" are in more of a gray area. > > > > So, yes, I think a specification like this should have been > > written somewhat differently and then published as a an updating > > Technical Specification or as an Applicability Statement. The > > latter would, IMO, have been especially appropriate because > > classifying those problem methods as "Limited Use" and then > > explaining why people should be phasing them out and why they > > might not want to hurry to do that is precisely in line with > > what A/S documents are supposed to be all about. That was part > > of what I was getting at when I asked for the clarification that > > Ben mentioned. However, because we have been using BCPs in > > this way for quite a while, I don't think it is fair or > > reasonable to jump on a WG that has gotten a document into Last > > Call and say "despite all of the precedent for this, it is your > > bad luck week and you need to go back to the drawing board". > > > > So, IMO, if this situation is going to be straightened out, we > > should let this document go with Ben's suggested changes but > > should go back to the IETF list and push for some changes, > > ideally binding on the IESG, which prevents our getting into > > this kind of situation again. In other words, while I think > > this document is a mistake as written, I think the authors and > > WG are victims and we should not punish them for it. Instead, > > we should learn from this example and work to avoid its > > happening again. Or we should find out that the community does > > not care and then proceed to revise 2026 accordingly. > > > > john > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
