Thanks Ray for the feed backs. Please see my questions inline. Yours, Daniel
On Fri, Oct 23, 2020 at 10:52 AM Ray Hunter (v6ops) <v6...@globis.net> wrote: > Hi Daniel, > > Thanks for publishing this draft. > > I have a three comments/concerns. > > Firstly: "this option is also defined in [I-D.ietf-dhc-sedhcpv6]." > > I just want to clarify that you are going to provide a new option code, > but with the identical semantics. > > <mglt> Actually I left this as a comment on similar ideas. The idea was originally to use the same format and use dhc-sedhcpv6 as the reference for the format. As far as I know this draft seems abandoned, and this is why the current draft does specify the format. I agree the comment is misleading and should be removed and yes we do ask for a specific code point if we were using that option ( see below: using a certificate is probably a better idea.). </mglt> I do think you need a separate code to avoid parsing ambiguity. > > But also going forward if the specification is amended, then this would > also be amended for this usage. > > i.e. s/DNSKEY RDATA format as defined in [RFC4034]/DNSKEY RDATA format as > defined in [RFC4034] or as amended/ ? > > <mglt> I believe that only the format would be defined by DNSSEC RFCs and the usage woudl be defined by our document. </mglt> > Second: I was planning on using certificates to secure the control > channel. The certificate would be linked to the individual HNA. > > <mglt> I think that is a great idea to use certificate instead of raw keys. The primary reason would be that certificate enables to carry meta data associated to the key - one of this metada is the CA and overall I believe that ISPs would be more at ease in managing/accept certificate that raw keys. I also believe that certificate will simplify the authentication between the HNA and the DOI. In fact, it might be the only case where rawkey would be used to authenticate the HNA. Moving to certificate would provide a single way to authenticate the client and would not require the TLS library to support the rawkey authentication. For keys that are generated by the HNA, building a self-signed certificate does not add much complexity. </mglt> Is there any provision for either downloading the relevant certificate > given the key data, or for containing the certificate directly in the DHCP > option? > > Thirdly: I know some operators have concerns about "individualising" DHCP > responses per user, rather than a static "get you configuration here" type > bootstrap for all users. > > Has this concern been discussed with any ISP's and is there an alternative > method of individualizing the bootstrap process? > <mglt> It seems to be fine to provide an individualized response. In our case I see the DHCP doing an individual action based on the request. That is good to get early feed back from ISP. Thanks! </mglt> > > regards, > > Daniel Migault wrote on 22/10/2020 15:10: > > Hi, > > Please find here an update for the DHCP options aiming at configuring the > Home Naming Authority (HNA). The document has been updated to better > reflect the changes made on the front-end draft. As the front-end draft > enables the Distributed Master (DM) and the HNA to agree on some > configuration parameters, these parameters no longer need to be provided > via DHCP. As a result, this resulted in simplifying the DHCP options which > is reflected by the current version. > > As always, comments are welcome! > > Yours, > Daniel > > > > > ---------- Forwarded message --------- > From: <internet-dra...@ietf.org> > Date: Thu, Oct 22, 2020 at 9:04 AM > Subject: [homenet] I-D Action: > draft-ietf-homenet-naming-architecture-dhc-options-08.txt > To: <i-d-annou...@ietf.org> > Cc: <homenet@ietf.org> > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Home Networking WG of the IETF. > > Title : DHCPv6 Options for Home Network Naming Authority > Authors : Daniel Migault > Ralf Weber > Tomek Mrugalski > Chris Griffiths > Wouter Cloetens > Filename : > draft-ietf-homenet-naming-architecture-dhc-options-08.txt > Pages : 14 > Date : 2020-10-22 > > Abstract: > This document defines DHCPv6 options so any agnostic Homnet Naming > Authority (HNA) can automatically proceed to the appropriate > configuration and outsource the authoritative naming service for the > home network. In most cases, the outsourcing mechanism is > transparent for the end user. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/ > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-homenet-naming-architecture-dhc-options-08 > > https://datatracker.ietf.org/doc/html/draft-ietf-homenet-naming-architecture-dhc-options-08 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-naming-architecture-dhc-options-08 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > -- > Daniel Migault > Ericsson > > > _______________________________________________ > 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> > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
