Subject: [kitten] I-D Action: draft-ietf-kitten-tls-channel-bindings-for-tls13-01.txt

From: [email-masked]
Date: Wed, 18 Nov 2020 18:47:02 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Authentication Technology Next Generation WG of the IETF.

        Title           : Channel Bindings for TLS 1.3
        Author          : Sam Whited
	Filename        : draft-ietf-kitten-tls-channel-bindings-for-tls13-01.txt
	Pages           : 5
	Date            : 2020-11-18

Abstract:
   This document defines a channel binding type, tls-exporter, that is
   compatible with TLS 1.3 in accordance with RFC 5056, On Channel
   Binding.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-kitten-tls-channel-bindings-for-tls13-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-tls-channel-bindings-for-tls13-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Sam Whited" <[email-masked]>
Date: Thu, 19 Nov 2020 07:44:34 -0500

I noticed before submitting this one that I'd added an extra "tls"
before the name of the draft somehow (ie. tls-channel-bindings-for-tls
not channel-bindings-for-tls), but it won't let me change the filename
without resetting the version number. Does it matter, or is there
something I should do to fix this?

Thanks,
Sam

On Wed, Nov 18, 2020, at 21:47, [email-masked] wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Common Authentication
> Technology Next Generation WG of the IETF.
>
>         Title           : Channel Bindings for TLS 1.3 Author
>         : Sam Whited Filename        : draft-ietf-kitten-tls-channel-bindings-for-tls13-
>         01.txt Pages           : 5 Date            : 2020-11-18
>
> Abstract:   This document defines a channel binding type, tls-
> exporter, that is   compatible with TLS 1.3 in accordance with RFC
> 5056, On Channel   Binding.
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> _______________________________________________
> Kitten mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

-- 
Sam Whited

---

From: tom petch <[email-masked]>
Date: Thu, 19 Nov 2020 17:36:42 +0000

> something I should do to fix this?

Leave well alone!

I noticed it and thought how quaint so it is a identifier that will stay 
in my mind long after this is an RFC:-)

The WG chairs can allow the change and can set up a link in the 
datatracker so that the I-D can be backtracked through name changes but 
that is a hassle, you have to know that you need to do it and even ADs 
at AD review can lose sight of what has happened.

The I-D name is just a handle, an identifier, which is the reference  to 
use up until the RFC appears, after which it is the RFC number which counts.

I think that many people creater overcomplex names trying to encode 
every aspect of an I-D into a name but you have not done that; channel 
bindings, tls13, just what I need to know.

Tom Petch

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Nov 2020 17:37:47 +0000

On 19/11/2020 17:36, tom petch wrote:

> I noticed it and thought how quaint so it is a identifier that will 
> stay in my mind long after this is an RFC:-)
>
> datatracker so that the I-D can be backtracked through name changes 
> but that is a hassle, you have to know that you need to do it and even 
> ADs at AD review can lose sight of what has happened.
>
> The I-D name is just a handle, an identifier, which is the reference  
> to use up until the RFC appears, after which it is the RFC number 
> which counts.
>
+1

---

From: "Sam Whited" <[email-masked]>
Date: Thu, 19 Nov 2020 12:40:04 -0500

Sounds good to me; thanks!

—Sam

---

From: Robbie Harwood <[email-masked]>
Date: Fri, 20 Nov 2020 12:42:28 -0500

> something I should do to fix this?

It could be fixed if you really wanted, but as others have stated, it's
fine.

This new version addresses my concerns.  I encourage others to take a
look and review this document even if it's just to indicate that you
think it's ready - the document is not especially long.

Thanks,
--Robbie

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 20 Nov 2020 17:46:18 +0000

> think it's ready - the document is not especially long.
-01 looks better to me.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 29 Nov 2020 10:04:44 -0800

-01 looks fine to me.

--
Astra mortemque praestare gradatim