On Thu, Apr 4, 2024 at 7:38 PM Mike Bishop <mbis...@evequefou.be> wrote:
> Ekr, can I ask you to clarify this a little? I fully agree that extensions > to TLS which support a particular application-layer protocol should be done > in that protocol’s working group unless and until it’s demonstrated that > many unrelated applications will need something similar. (At which point, > it probably makes sense to build the general thing, either in TLS or a new > WG.) But this isn’t that. > > > > For something that concerns the TLS exchange itself, the TLS WG does still > seem like the natural home to me. Where are you suggesting the standards > work happens instead? Are you suggesting that this should be registered to > the I-D, or go to a new/different working group? The former path seems like > it won’t get the review it needs, and I’m not sure any other WGs are > appropriately chartered for the latter. > I'm suggesting it be registered based on the ID. When you say "get the review it needs", I think that's at the heart of the question. My position is that the TLS WG (and the IETF generally) should spend its limited resources on things which are important and likely to receive wide deployment. Other code points can just be registered and marked "recommended=N". Of course, they won't get review, but nothing stops people from registering all kinds of bad ideas without review; that's why the registries were open. Here's what would make me interested in seeing the TLS WG spend time on this: a critical mass of both servers and clients of the type contemplated here (e.g., search engines or crawlers) who say they would actually use it. -Ekr > > > Personally, I support adoption for the use case. It sounds like there’s an > alternative design that might need to be hammered out, but since it appears > a document may be needed for either path, let’s adopt and argue about that > later. > > > > *From:* TLS <tls-boun...@ietf.org> *On Behalf Of *Eric Rescorla > *Sent:* Wednesday, April 3, 2024 10:28 AM > *To:* Watson Ladd <watsonbl...@gmail.com> > *Cc:* Christopher Patton <cpatton=40cloudflare....@dmarc.ietf.org>; TLS > List <tls@ietf.org> > *Subject:* Re: [TLS] Adoption call for TLS Flag - Request mTLS > > > > > > > > On Tue, Apr 2, 2024 at 10:36 PM Watson Ladd <watsonbl...@gmail.com> wrote: > > > > On Tue, Apr 2, 2024, 5:08 PM Eric Rescorla <e...@rtfm.com> wrote: > > Adoption should not be required to register a code point [0], as the > policy is Specification Required. > > > > I'm mildly negative on adopting this document. What is the reason we need > to spend WG time on this, rather than just having a code point assignment? > > > > Well, don't we want to say how this is supposed to work somewhere? > > > > Why? The attitude I am trying to get away from is that the TLS WG has to > > be involved in every extension to TLS. Rather, we should decide what things > > are important and spend time on them and then let others extend TLS > independently > > in areas we don't think are important. > > > > -Ekr > > > > I doubt this will take much time. > > > > -Ekr > > > > [0] As an aside the IANA considerations of draft-ietf-tls-tlsflags-13 > should clearly have > > a policy which matches 8447 S 7, which is to say that an I-D is sufficient. > > > > > > On Tue, Apr 2, 2024 at 12:59 PM Christopher Patton <cpatton= > 40cloudflare....@dmarc.ietf.org> wrote: > > I'd like to see this problem solved. There was some discussion about > whether an I-D is needed or all we needed was to register a code point > somewhere. If most agree that an I-D is needed, then let's adopt it. I'm > happy to review. > > > > Chris P. > > > > On Tue, Apr 2, 2024 at 12:22 PM Sean Turner <s...@sn3rd.com> wrote: > > At the IETF 119 TLS session there was some interest in the mTLS Flag I-D ( > https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see > previous list discussions at [0]. This message is to judge consensus on > whether there is sufficient support to adopt this I-D. If you support > adoption and are willing to review and contribute text, please send a > message to the list. If you do not support adoption of this I-D, please > send a message to the list and indicate why. This call will close on 16 > April 2024. > > Thanks, > Deirdre, Joe, and Sean > > [0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls