+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 >
