On 12/8/20 7:28 PM, Eric Rescorla wrote:
Do you have a citation for this distinction? I believe that in both cases this means "you are in violation of RFC XXXX if you do this".Yes, but a BCP really does have a different meaning and scope than a standard protocol specification.
Hmm... I don't think that that's obvious. Do you have a textual argument for this claim?
Maybe later. But why have different statuses if they mean the same thing? BCP was created specifically for a case that standards-track didn't work for.
I would counter that if the real goal of this document is to constrain implementations, it should be written as a standards-track document, and have been last called as a standards-track document, and to Last Call it as BCP was an error.
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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
