[Dots] Éric Vyncke's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-dots-server-discovery-14: 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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/



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

Thank you for the work put into this document. It is easy to read.

Please find below a couple of blocking DISCUSS points and some non-blocking
COMMENT points and some nits.

In addition to my own points, please consider Zhen Caos' INT directorate review
at:
https://datatracker.ietf.org/doc/review-ietf-dots-server-discovery-11-intdir-lc-cao-2020-10-12/

I hope that this helps to improve the document,

Regards,

-éric

== Previous DISCUSS -- solved by Med Boucadair and kept here for archiving
purposes == -- Section 4 -- Trivial to fix: there is no "DHCP lease" for
stateless DHCPv6... You should probably rather refer to the information-request
refresh time option (section 21.23 of RFC 8415).

-- Section 5.1.2 --
I fully second Zhen Cao's review: how will the IPv4-mapped IPv6 address(es) be
used? They MUST not appear on the wire and there is a DHCPv4 option to convey
the DOTS information. Is it when DHCPv6 is available, no DHCPv4, and only IPv4
connectivity to the DOTS server ? If so, then please clarify the text.

== End of previous DISCUSS ==

Is DHCP really the way to go ? Even if it seems that there are use cases,
relying on dynamic DHCP for such an important security protocol looks very
strange to me (as the security AD has approved DHCP use, it is a mere
non-blocking comment).

Should DNSSEC be required for domain name resolution or is relying only on TLS
server authentication enough ?

The document gives a lot of IPv6 examples: thank you for this but it also
mention multiple address families. Should Happy Eyeball be used when connected
to the DOTS server?

-- Section 4 --
While this section title is "Unified DOTS Discovery Procedure", I read 3
different mechanisms so apparently conflicting with the section title. Suggest
to remove "unified" from the section title.

Putting DHCP configuration under explicit configuration appears weird to me as
DHCP is rather dynamic and on the same level as DNSD.

May I suggest to move the sentence "DOTS clients will prefer information
received from the discovery methods in the order listed" before the list? It is
an important sentence IMHO.

I wonder wheter the sentence "Expiry of a peer DOTS agent's certificate
currently in use." is correct... Should it be "agent peer DOTS certificate" ?

-- Sections 5.1.3 and 5.2.3--
The part of the sentence "as distinguished by the presence of multiple root
labels" should be explained more as it is unclear.

-- Section 6 --
Just to say that the use of S-NAPTR surprised me (no need to reply)

== NITS ==

The id-nits tool indicates a non used reference to RFC 8783, so, please clean
up the reference list ;-)

-- Section 1 --
s/by multi-homed DOTS clients are out of scope/by multi-homed DOTS clients are
out of this document scope/ ?