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

[[e-mail]]

Hi Éric, 

Thank you for the review. The changes to address your review can be seen at: https://tinyurl.com/opsawg-add-latest.

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker <[e-mail]>
> Envoyé : mardi 14 mars 2023 10:30
> À : The IESG <[e-mail]>
> Cc : [e-mail]; opsawg-
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Éric Vyncke's Discuss on draft-ietf-opsawg-add-encrypted-
> dns-11: (with DISCUSS and COMMENT)
> 
> É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"
> 

[Med] Absent any local policy, non-permitted attributes should be considered as invalid (rfc6929#section-2.8). 

RADIUS attributes specs usually don't repeat validation checks as this is redundant with rfc8044, especially: 

   Where the contents of a data type do not match the definition,
   implementations MUST treat the enclosing attribute as being an
   invalid attribute.  This requirement includes, but is not limited to,
   the following situations...

Unless Alan has a string objection, we can add this generic text right before Section 3.1:

"As a reminder, invalid attributes are handled as per Section 2.8 of [RFC6929]".


> 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.
> 

[Med] OK, deleted that part of the sentence. 

> ### 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 ?
> 

[Med] Good suggestion. Fixed. 

> ### 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.
> 

[Med] I'm afraid that "s/is no/MAY NOT" is not justified here as the client is prepared that its preference to be ignored. There is no impact on interop or there will be a "reduced functionality".


> ### 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)
> 

[Med] Works for me.


> ## NITS
> 
> ### Section 3.2
> 
> Suggest to use the same layout as in section 3.1 for the "value"
> field.

[Med] Thanks for catching this. Fixed 


_________________________________________________________________________________________________________________________

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.