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.
are not well suited to the phased roll-in nature of the three stage
standards track and instead generally only make sense for full and
immediate instantiation.
The BCP process is similar to that for proposed standards. The BCP
is submitted to the IESG for review, (see section 6.1.1) and the
existing review process applies, including a Last-Call on the IETF
Announce mailing list. However, once the IESG has approved the
document, the process ends and the document is published. The
resulting document is viewed as having the technical approval of the
IETF.
Specifically, a document to be considered for the status of BCP must
undergo the procedures outlined in sections 6.1, and 6.4 of this
document. The BCP process may be appealed according to the procedures
in section 6.5.
Because BCPs are meant to express community consensus but are arrived
at more quickly than standards, BCPs require particular care.
Specifically, BCPs should not be viewed simply as stronger
Informational RFCs, but rather should be viewed as documents suitable
for a content different from Informational RFCs.
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.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
