On Tue, Dec 8, 2020 at 4:50 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
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.
I'm curious, what do you think the point of having this update all the other documents was if it wasn't to constrain implementations?
-Ekr
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
