Re: [Last-Call] Results of Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/8/20 7:45 PM, Eric Rescorla wrote:



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.
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.

   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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux