Hi Ray, Thanks for the question. I do not think that using such URI really fits our needs here. To my understanding, the URI provides an abstract way to designate the DNS entry without specifying how these entries are reached or resolved. Typically, when multiple servers are hosting that DNS entry, the user does not really care which server will be reached. At the time the URI was defined, only Do53 was used. This has changed, so the URI designates a DNS entry that may be reached multiple transports. This also means that there is a need to discover which transport will be used. Such discovery mechanism are in scope of the add WG but are not yet defined. Currently the add WG is focused on auto upgrade mechanisms. This means you know this server has enabled DoH and you switch the use DoH instead of Do53. In our case, the architecture document define the DoT as a base line but does not prevent other mechanisms to be used such as DoH for example. It is likely that some auto upgrade mechanism could apply as well - when standardized. I think that in our case one issue we have is that we would like to mandate that the channels are secured, but the URI abstraction does not enable this. The other aspect that makes the use of such URI difficult is that we are re-using DNS messages to configure a Primary / Secondary which is a bit out of scope of the designation of the DNS data.
Yours, Daniel On Fri, Apr 2, 2021 at 8:08 AM Ray Hunter (v6ops) <v6...@globis.net> wrote: > Hi Daniel, > > I have a question both for this draft and our "own" Homenet draft > > Up until now we've been passing the specification of the DM * Reverse DM > connections via separate configuration parameters: address/name, port > number, and transport protocol. > > Should we instead be using a DNS URI from > https://tools.ietf.org/html/rfc4501? > > That reduces the DM spec to a single parameter that is also extensible for > the future. > > regards, > > Daniel Migault wrote on 01/04/2021 18:18: > > Hi Bernie, > > I apology for missing that email. Your comments addressed an old version, > however most of them applies to the new version. I think all comments have > been addressed on my working local copy and I provide more details on how > we addressed them. > > I do have one remaining question regarding the IANA section on whether the > specific values associated to a field of the DHCP option are part of the > IANA section with the creation of a new registry or not. > > Please see inline my response for more details. > > > Thanks for the review! > > Yours, > Daniel > ------------------------------ > *From:* Bernie Volz (volz) <v...@cisco.com> <v...@cisco.com> > *Sent:* Tuesday, March 9, 2021 11:54 AM > *To:* draft-ietf-homenet-naming-architecture-dhc-opti...@ietf.org > <draft-ietf-homenet-naming-architecture-dhc-opti...@ietf.org> > <draft-ietf-homenet-naming-architecture-dhc-opti...@ietf.org> > *Subject:* draft-ietf-homenet-naming-architecture-dhc-options-08 > > > Hi: > > > > Took a quick look at the document … just a few nits to point out: > > > > 1. You use “Homnet” in 2 places; I think that should be Homenet? > > <mglt> > fixed thanks. > </mglt> > > 1. For the FQDN option data, please make sure you refer to encoding > used is specified in https://tools.ietf.org/html/rfc8415#section-10 > > < <https://tools.ietf.org/html/rfc8415#section-10>mglt> > thanks, the encoding has been specified for all FQDN data, i.e., the > Registered Domain, the Distribusion Master and Reverse Distribution Master. > </mglt> > > 1. In 4.1, the diagram shows “Public Key Data” yet the definition > below it has “Client Public Key Data”; fix them to match. > > <mglt> > This has been fixed in the previous version by removing these options. > </mglt> > > 1. Sometimes you indicate the “length” of the data in the options, > sometimes you don’t; and “(varaiable)” is used in one place which is > misspelled. > > <mglt> > Variable has been fixed. I suppose the these comments has been fixed from > the latest version. As far as i can see, the current version has (variable) > indicated for all variable fields. and option-len field in each > description. > > </mglt> > > 1. You still reference RFC3315 when current DHCPv6 standard is RFC8415. > > <mglt> > I have updated the reference. Thanks. > </mglt> > > 1. The IANA considerations needs some work. You might see > > https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/15/?include_text=1 > as an example of a recent very good IANA considerations section. > > <mglt> > I have updated the IANA section. I do have one remaining question. > One option specifies the the values of a field in a DHCP option. I am > wondering if a specific registry needs to be created or not. For now I have > assumed yes. The IANA section looks like: > > IANA is requested to assign the following new DHCPv6 Option Codes in the > registry maintained in: > https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. > > > ~~~ > Value Description Client ORO Singleton Option > TBD1 OPTION_REGISTERED_DOMAIN Yes Yes > TBD2 OPTION_DIST_MASTER Yes Yes > TBD3 OPTION_REVERSE_DIST_MASTER Yes Yes > ~~~ > > The document also requests a Supported Transport Registry: > > ~~~ > Bit | Transport Protocol | Reference > ----+--------------------+----------- > 0 | DNS over TLS | > 1 | DNS over HTTPS | > 2-7 | unallocated | > ~~~ > > </mglt> > > > > - Bernie > > > > _______________________________________________ > homenet mailing > listhomenet@ietf.orghttps://www.ietf.org/mailman/listinfo/homenet > > > -- > regards, > RayH > > <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach> > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
