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

From: Lars Eggert via Datatracker <[email-masked]>
Date: Mon, 31 May 2021 02:31:59 -0700

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

---

From: <[email-masked]>
Date: Mon, 31 May 2021 09:56:06 +0000

Hi Lars, 

Thanks for the review. 

Fixed the nits when I think is needed: https://tinyurl.com/8782bis-latest. 

> Obsolete reference to RFC5246, obsoleted by RFC8446.

This is on purpose as you can see in: https://mailarchive.ietf.org/arch/msg/dots/-VafSjkSuxLDVbywXBky0qr2eWo/ 

Cheers,
Med

> -----Message d'origine-----
> De : Lars Eggert via Datatracker [mailto:[email-masked]]
> Envoyé : lundi 31 mai 2021 11:32
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Lars Eggert's No Objection on draft-ietf-dots-rfc8782-bis-07:
> (with COMMENT)
> 
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> 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.
> 
> Double negatives are discouraged in standard English. Can you
> reformulate this phrase or is a comma missing?
> 
> Use a comma before 'and' if it connects two independent clauses
> (unless they are closely connected and short).
> 
> Use a comma before 'so' if it connects two independent clauses
> (unless they are closely connected and short).
> 
> Use a comma before 'but' if it connects two independent clauses
> (unless they are closely connected and short).
> 
> 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.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.