On 12/8/20 7:45 PM, Eric Rescorla wrote:
Well, part of the difference might be that there are things (e.g. practices) that you can't generally test for interoperability, so you can't advance them along the standards track.
On Tue, Dec 8, 2020 at 4:38 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
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.
Candidly, 2026 is fairly vague on this point. With that said the rationale in 2026 looks a lot more like "this doesn't need the three tier standards system"
Unlike standards-track documents, the mechanisms described in BCPs
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.
Yes, but asking for BCP when you really want to constrain
implementations is like a bait-and-switch. It's asking the
community to evaluate the document in one light, when you intend
it to be interpreted in a different light.
Now that you're claiming it is intended to constrain implementations, I must strongly object to its publication in its current form.
Well, speaking as someone with no authority, it appears to me that you are in the minority in that opinion, but I'll leave the AD to handle it.
This is a newly discovered issue, and there's been no input on this besides from you and me.
Keith
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
