[lamps] Éric Vyncke's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-lamps-rfc6844bis-06: 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-lamps-rfc6844bis/



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

Thank you all for the work put into this document. I appreciate the section 7
about the differences with RFC 6844.

== COMMENTS ==

-- Section 2.2 --

"Domain Name: The label assigned to a node in the Domain Name System." AFAIK
RFC 1034 defines it differently "The domain name of a node is the list of the
labels on the path from the node to the root of the tree" Or are we talking
about different "domain names" ?

"Wildcard domain name": it would be interesting to define not only the syntax
but also the semantic do those wildcard domain names.

-- Section 3 --

While I am not a security expert, a TLD could add a CAA forcing all its FQDN to
either use the CA defined in the TLD CAA RRset or add a per FQDN CAA (which may
raise the bar for small not-so-managed domains which otherwise could have used
a cheap and easy CA such as letsencrypt). Is it really good to climb the DNS
tree up to the TLD? Just curious.

== NITS ==

-- Section 3 --

I would have preferred a recursive definition rather than an interative
algorithm but this is a matter of taste ;-)