Re: [Add] Paul Wouters' Discuss on draft-ietf-add-dnr-11: (with DISCUSS)

[[e-mail]]

Hi Paul, 

Thanks for the comments. 

Tiru already provided answers to some of the DISCUSS points. Please see inline a reply to the remaining ones. 

Cheers,
Med

> -----Message d'origine-----
> De : Paul Wouters via Datatracker <[e-mail]>
> Envoyé : mercredi 13 juillet 2022 21:47
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> Objet : Paul Wouters' Discuss on draft-ietf-add-dnr-11: (with
> DISCUSS)
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-add-dnr-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-add-dnr/
> 
> 
> 
> ------------------------------------------------------------------
> ----
> DISCUSS:
> ------------------------------------------------------------------
> ----
> 
> # Internet AD comments for {draft-ietf-add-dnr-11}
> CC @paulwouters
> 
> ## Discuss
> 
...
> 
> ###
> 
>    authentication-domain-name (variable length):  A fully
> qualified
>       domain name of the encrypted DNS resolver.  This field is
>       formatted as specified in Section 10 of [RFC8415].
> 
>       An example of the authentication-domain-name encoding is
> shown in
>       Figure 2.  This example conveys the FQDN
> "doh1.example.com.", and
>       the resulting Option-length field is 18.
> 
>        +------+------+------+------+------+------+------+------+--
> ----+
>        | 0x04 |   d  |   o  |   h  |  1   | 0x07 |   e  |   x  |
> a  |
>        +------+------+------+------+------+------+------+------+--
> ----+
>        |   m  |   p  |   l  |   e  | 0x03 |   c  |   o  |   m  |
> 0x00 |
>        +------+------+------+------+------+------+------+------+--
> ----+
> 
> The draft says "as specified in Section 10 of [RFC8415]" but that
> is just
> a redirect to Section 3.1 of [RFC1035]

[Med] Not only that. It also says: 
 
   A domain name, or list of domain names, in
   DHCP MUST NOT be stored in compressed form as described in
   Section 4.1.4 of [RFC1035].


 which doesn't tell me how
> to
> encode the NAME. For example, I do not understand why one "." is
> encoded
> as 0x07 and another "." is 0x03 ?
> 
> ###
> 
>       Addr Length:  Length of enclosed IPv6 addresses in octets.
> When
>       present, it MUST be a multiple of 16.
> 
> Why not just a one octet counter then? The number of IPv6
> addresses that follow.
> Then the length of the Addr field becomes counter times 16 octets.
> That seems
> more constrained than "multiple of 16"

[Med] This was discussed but we preferred to have an encoding that avoids as much specialized code for parsing structured options. FWIW, the discussion I had with Bernie (co-chair of DHC) in early stages of this spec led to this good summary for a possible update of RFC7227: https://mailarchive.ietf.org/arch/msg/dhcwg/gZ_EbiPVOt-3tARDeQHYLHbh8R8/. Please note also the discussion on length vs. count.

> 
> ###
> 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+
>       |
> |
>       |                         ipv6-address
> |
>       |
> |
>       |
> |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+
>       |                              ...
> |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+
> 
> The diagrams lack reference octets.

[Med] Updated the figure with the indication. 

 What is the width ? or 4 rows
> ? or ?
> I assume this is supposed to be 4 octets wide and 16 octets total?
> eg
> I would write:
> 
>                            1                   2
> 3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> 0 1
>       +-----------------------------------------------------------
> ----+
>       |
> |
>       |                         ipv6-address
> |
>       |
> |
>       |
> |
>       +-----------------------------------------------------------
> ----+
>       |                              ...
> |
>       +-----------------------------------------------------------
> ----+
> 
> (also my pet peeve is people using +-+-+-+ instead of -----)

[Med] We prefer to be consistent with https://datatracker.ietf.org/doc/html/rfc7227#section-5.1.

> 
> 
> ###
> 
>        A value of zero means that this Authentication Domain Name
> MUST no
>        longer be used.
> 
> Why not just omit the entry ?

[Med] This is not deterministic as clients are supposed to keep track of discovered resolvers as a function of their validity lifetime. The current behavior in the draft is particularly useful in the context of ** unsolicited RAs ** which can be issued by the network under some conditions (rfc4861#section-6.2.4):
	
   The information contained in Router Advertisements may change through
   actions of system management.  For instance, the lifetime of
   advertised prefixes may change, new prefixes could be added, a router
   could cease to be a router (i.e., switch from being a router to being
   a host), etc.  In such cases, the router MAY transmit up to
   MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the
   same rules as when an interface becomes an advertising interface.

FWIW, we are echoing RFC8106#section-5.1: 

  A value of zero means that the RDNSS addresses MUST no longer
  be used. 

 Are clients supposed to keep old
> entries for
> their entire lifetime even if when asking a new list, those
> entries no longer
> appear? That is not clear from this document. Either that should
> be made
> explicit, or the values of 0 should not be allowed.
> 
> 
> 
> ###
> 
> Multihoming is declared out of scope, but realistically most
> devices we are
> talking about here are phones, and those are all multihomed. So I
> feel pretty
> strongly that it should not be left out of scope.
> 
> 

[Med] The options can be used even for multihomed nodes:

   Devices may be connected to multiple networks; each providing their
   own DNS configuration using the discovery mechanisms specified in
   this document.

What is out of scope is the selection at the client side: 

   Nevertheless, it is out of the scope of this
   specification to discuss DNS selection of multi-interface devices.

Please note also that we are adhering with the IETF guidelines here, especially rfc7227#section-12:

   This is a generic DHCP issue and should not be dealt within each
   option separately.  This issue is better dealt with using a protocol-
   level solution, and fixing this problem should not be attempted on a
   per-option basis.  Work is ongoing in the IETF to provide a
   systematic solution to this problem.

Reverted back to the title we had in -10 as the new one is misleading. 

_________________________________________________________________________________________________________________________

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.