Lars Eggert has entered the following ballot position for
draft-ietf-tls-dtls-connection-id-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

Section 3, paragraph 10, nit:
>    the record format defined in {{dtls-ciphertext} with the new MAC

Broken kramdown reference?

Section 1, paragraph 4, nit:
-    This document defines an extension to DTLS 1.2 to add a CID to the
+    This document defines an extension to DTLS 1.2 to add a Connection ID 
(CID) to the
+                                                             ++++++++++  ++++++

Section 3, paragraph 7, nit:
-    for example by having the length in question be a compile-time
+    for example, by having the length in question be a compile-time
+               +

Section 3, paragraph 7, nit:
-    different length to other parties.  Implementations that want to use
-    variable-length CIDs are responsible for constructing the CID in such
+    different lengths to other parties.  Implementations that want to use
+                    +
+    variable-length CIDs are responsible for constructing the CIDs in such
+                                                                 +

Section 3, paragraph 12, nit:
-    datagram with the RFC 6347-defined record format the MAC calculation
+    datagram with the RFC 6347-defined record format, the MAC calculation
+                                                    +

Section 4, paragraph 6, nit:
-    *  The true content type is inside the encryption envelope, as
-           - -
+    *  The real content type is inside the encryption envelope, as
+             ++

Section 6, paragraph 2, nit:
-    datagram unless the following three conditions are met:
+    datagram, unless all of the following three conditions are met:
+            +       +++++++

Section 10, paragraph 2, nit:
-    This document requests three actions by IANA.
-                                         ^^
+    This document requests three actions from IANA.
+                                         ^^^^

Section 4, paragraph 17, nit:
> cord. outer_type The outer content type of a DTLSCiphertext record carrying a
>                                    ^^^^^^^^^
If 'type' is a classification term, 'a' is not necessary. Use "type of". (The
phrases 'kind of' and 'sort of' are informal if they mean 'to some extent'.)

Section 4, paragraph 19, nit:
> the CID value it will receive and use to identify the connection, so an 
> implemen
>                                   ^^^^^^
Make sure that 'use to' is correct. For habitual actions in the past or to mean
'accustomed to', use "used to".

Section 5, paragraph 6, nit:
> Plaintext The length (in bytes) of the serialised DTLSInnerPlaintext 
> (two-byte inte
>                                        ^^^^^^^^^^
Do not mix variants of the same word ('serialise' and 'serialize') within a
single text.

Section 6, paragraph 2, nit:
>  that has a source address different than the one currently associated with 
> the D
>                                      ^^^^
Did you mean 'different "from"? 'Different than' is often considered colloquial
style.

Section 6, paragraph 2, nit:
> ied in the received datagram, unless all of the following three conditions 
> are met:
>                                      ^^^^^^^^^^
Consider using "all the".

"Appendix A.", paragraph 1, nit:
>  History RFC EDITOR: PLEASE REMOVE THE THIS SECTION 
> draft-ietf-tls-dtls-connect
>                                    ^^^^^^^^
Maybe you need to remove the second determiner so that only "THE" or "THIS" is
left.

"Appendix A.", paragraph 29, nit:
> 2 * Move to internal content types a la DTLS 1.3. draft-ietf-tls-dtls-conne
>                                    ^^^^
'a la' is an imported foreign expression, which originally has a diacritic.
Consider using "à la"

"Appendix B.", paragraph 1, nit:
> formation RFC EDITOR: PLEASE REMOVE THE THIS SECTION The discussion list for 
> the
>                                     ^^^^^^^^
Maybe you need to remove the second determiner so that only "THE" or "THIS" is
left.

"Appendix C.", paragraph 1, nit:
>  Many people have contributed to this specification and we would like to 
> thank the following
>                                       ^^^^^^^^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

These reference issues exist in the document:
 * No reference entries found for:
     [ChangeCipherSpec], [length], [length_of_padding],
     [DTLSCiphertext.length],
     [draft-rescorla-tls-dtls-connection-id-00],
     [cid_length], [DTLSPlaintext.length]
 * Uncited references: [RFC5246]
 * Obsolete reference to RFC5246, obsoleted by RFC8446

These URLs in the document did not return content:
 * https://www1.ietf.org/mailman/listinfo/tls
 * http://www.ietf.org/internet-drafts/draft-tschofenig-tls-dtls-rrc-01.txt
 * http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls13-40.txt



_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls

Reply via email to