(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
