[Dots] Lars Eggert's No Objection on draft-ietf-dots-rfc8782-bis-07: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-dots-rfc8782-bis-07: 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-dots-rfc8782-bis/



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

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.

Section 4.3, paragraph 2, nit:
-    connectionless and connection-oriented protocols.  As such, the DOTS
+    connection-less and connection-oriented protocols.  As such, the DOTS
+              +

Section 4.4.1.1, paragraph 39, nit:
-       The use of FQDNs may be suboptimal because:
+       The use of FQDNs may be suboptimal, because:
+                                         +

Section 5.3, paragraph 26, nit:
-                 Ths is is a mandatory attribute when a client
-                   --
+                 This is a mandatory attribute when a client

Section 10.1, paragraph 3, nit:
-    assigned to this docuement:
-                         -
+    assigned to this document:

Section 1, paragraph 5, nit:
> lient. The DOTS server may or may not not be co-located with the DOTS mitiga
>                                   ^^^^^^^
Double negatives are discouraged in standard English. Can you reformulate this
phrase or is a comma missing?

Section 4.4.1.1, paragraph 3, nit:
> ys MUST handle 'cuid' collision directly and it is RECOMMENDED that 'cuid' c
>                                 ^^^^^^^^^^^^
Use a comma before 'and' if it connects two independent clauses (unless they
are closely connected and short).

Section 4.4.3, paragraph 6, nit:
> DOTS client will send a Reset | message so it does not receive any more retra
>                                 ^^^^^^^^^^
Use a comma before 'so' if it connects two independent clauses (unless they are
closely connected and short).

Section 4.5.1, paragraph 22, nit:
> rtbeat frequency. It is NOT RECOMMENDED to return a Max-Age Option set to 0.
>                             ^^^^^^^^^^^^^^^^^^^^^
The verb 'RECOMMENDED' is used with the gerund form: "RECOMMENDED returning".

Section 6, paragraph 5, nit:
> S server when the Content-Format is used but the request is not formatted as
>                                     ^^^^
Use a comma before 'but' if it connects two independent clauses (unless they
are closely connected and short).

Section 6, paragraph 5, nit:
> ' URI IANA is requested to update the the 'dots' well-known URI (Table 6) en
>                                   ^^^^^^^
Possible typo: you repeated a word

Obsolete reference to RFC5246, obsoleted by RFC8446.

Document references draft-ietf-dots-multihoming-05, but -06 is the latest
available revision.

Document references draft-ietf-dots-telemetry-15, but -16 is the latest
available revision.

Document references draft-ietf-dots-use-cases, but that has been published as
RFC8903.

These URLs in the document can probably be converted to HTTPS:
 * http://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
 * http://www.iana.org/assignments/media-types
 * http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats
 * http://www.iana.org/assignments/protocol-numbers