[OPSAWG] Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-dns-11: (with DISCUSS and COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-opsawg-add-encrypted-dns-11: Discuss

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-add-encrypted-dns/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-add-encrypted-dns-11
CC @evyncke

Thank you for the work put into this document. Once the trivial DISCUSS is
addressed, I will be happy to ballot a YES.

Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education), and some nits.

Special thanks to Bernie Volz for the shepherd's detailed write-up including
the WG consensus even if the justification of the intended status is rather
vague.

Other thanks to Tatuya Jinmei, the Internet directorate reviewer (at my
request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-opsawg-add-encrypted-dns-10-intdir-telechat-jinmei-2023-03-09/
(and I have read Med's replies and resolution of the issues)

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

### What to do with non-permitted DHCP option ?

Sections 3.1 and 3.2 contain text like `Permitted DHCPv6 options in the
DHCPv6-Options Attribute are maintained by IANA in the registry created in
Section 8.4.1.` but I was unable to find anywhere in the document what is the
expected behaviour of a RADIUS client receiving a non-permitted DHCP option ?
At the bare minimum, I would expect the I-D to mention "non-permitted DHCP
options MUST silently be ignored by the RADIUS client"

Or did I fail to find a similar statement in the text ?


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


## COMMENTS

### Abstract

Should the sentence `Even if the specification was initially motivated by the
configuration of encrypted DNS resolvers,` be removed from the abstract ? It
adds nothing but confusion.

### Section 3

Should the whole paragraph starting with `RADIUS servers have conventionally
tolerated the input of arbitrary data via the "string" data type (Section 3.5
of [RFC8044])... ` rather be in the security (or operational) considerations
section ?

### Section 3.1

Should normative language be used in `However, the server is not required to
honor such a preference.`? I.e., the rest of the paragraph uses normative
language.

### Section 4

Should 'DHCP relay' be mentioned in the section title ? It would of course be
very long then but clearer for the reader (esp in the ToC)

## NITS

### Section 3.2

Suggest to use the same layout as in section 3.1 for the "value" field.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments