Channel Bindings for TLS 1.3
draft-ietf-kitten-tls-channel-bindings-for-tls13-16

In the Abstract, if you're going to quote "default", you should also quote "tls-exporter".

In Section 5.1, there's a Subject field presented as part of the registration.  Without a reference to RFC 5056, this looks like it's meant to populate a column that isn't actually part of the registry.  I suggest either including a reference to RFC 5056, or drop the Subject field.

At the top of Section 5.2, I suggest:

This document adds the following registration in the "TLS Exporter Labels" registry, which is part of the "Transport Layer Security (TLS) Parameters" group:

Thanks for this document to ensure TLS 1.3 support in SCRAM and GSS-API.

Thanks for addressing my DISCUSS.

Per how this document is updating other documents:

** The “updates” header doesn’t note RFC8446 but the abstract and Section 1 suggest that this document does update it.  Per Martin Duke’s DISCUSS point (which I support), please clarify.

** Per Section 3
  … this
   document updates [RFC5801], [RFC5802], and [RFC7677] to use "tls-
   exporter" as the default channel binding over TLS 1.3 (and greater).  

In what way is RFC7677 being updated?  If RFC5802 is already updated to required tls-exporter for TLS 1.3 what additional guidance is needed for RFC7677?

Wow, a TLS related document that even I can (mostly!) understand :-)

Thanks to Niclas Comstedt for the OpsDir review: https://datatracker.ietf.org/doc/review-ietf-kitten-tls-channel-bindings-for-tls13-09-opsdir-lc-comstedt-2021-10-13/

Thank you for the work put into this document.

Special thanks to Alexey Melnikov for the shepherd's write-up including the section about the WG consensus even if I would have appreciated the justification for proposed standard status. 

As Martin Duke wrote: let's have the abstract and the meta-data "update" be consistent (I am not raising a DISCUSS as I trust Ben and Martin for handling this issue).

The whole text is rather dry, and the introduction would have benefited to the readers if it included more context and explanations.

I am also assuming that in section 2 the length is really 32 octets while the string "EXPORTER-Channel-Binding" has only 25 characters (I had no time to dig into the details of RFC 5705).

I hope that this helps to improve the document,

Regards,

-éric

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "master"; alternatives might be "active", "central", "initiator",
   "leader", "main", "orchestrator", "parent", "primary", "server".

Thanks to Dale Worley for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/pO9096L_fD2Ey3DKJ2mfFOpGVHY).

The IANA review of this document seems to not have concluded yet.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

"Abstract", paragraph 2, nit:
> h RFC 5056, On Channel Binding. Furthermore it updates the default channel b
>                                 ^^^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Furthermore".

Section 1. , paragraph 2, nit:
> ent updates [RFC5929] by adding an additional unique channel binding type, "t
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
This phrase might be redundant. Consider either removing or replacing the
adjective "additional".

Reference [RFC5246] to RFC5246, which was obsoleted by RFC8446 (this may be on
purpose).

Thanks for making the document consistent about updating RFC8446. Whether the resolution is correct is a question I will leave to the responsible AD.