Thanks for the feedback. We did remove one sentence with ULA but this is correct ULA has not entirely been removed.
Yours, Daniel On Tue, Jan 17, 2023 at 9:25 AM Tim Chown <tim.ch...@jisc.ac.uk> wrote: > Thank you for the update Daniel, I am overall happy with the changes. I > suspect ULAs will be picked up by other reviews. > > Tim > > On 13 Jan 2023, at 19:17, Daniel Migault <mglt.i...@gmail.com> wrote: > > Hi Tim, > > Thanks for the feed backs. Please see how the document has been updated. > The ULA comment may remain open. > > https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/cbf182af1bf749f09348a178268d62b745c3d6d6 > > You can also find some more description / comments inline. > > Thanks for the follow-up! > Yours, > Daniel > > > On Thu, Jan 12, 2023 at 10:28 AM Tim Chown <tim.ch...@jisc.ac.uk> wrote: > >> Hi, >> >> In-line... >> >> On 9 Jan 2023, at 18:15, Daniel Migault <mglt.i...@gmail.com> wrote: >> >> Hi Tim, >> >> Thanks for the review we updated the file as follows: >> >> https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/038395265e821aeeb59ccd3b1ba50c4dbf831a3b >> >> Please see my responses in line for more details. >> >> Yours, >> Daniel >> >> On Thu, Jan 5, 2023 at 10:12 AM Tim Chown via Datatracker < >> nore...@ietf.org> wrote: >> >>> Reviewer: Tim Chown >>> Review result: Almost Ready >>> >>> Hi, >>> >>> I have reviewed this document as part of the Operational directorate's >>> ongoing >>> effort to review all IETF documents being processed by the IESG. These >>> comments were written with the intent of improving the operational >>> aspects of >>> the IETF drafts. Comments that are not addressed in last call may be >>> included >>> in AD reviews during the IESG review. Document editors and WG chairs >>> should >>> treat these comments just like any other last call comments. >>> >>> This document describes an architecture by which names and IP addresses >>> of >>> hosts or services may be made available in the public DNS through the >>> use of a >>> homenet naming authority (HNA) and associated (hidden) primary DNS >>> function >>> resident in the home network and a DNS outsourcing infrastructure (DOI) >>> function which through a distribution manager also acts as a secondary. >>> Methods >>> for synchronisation and control of the information between the HNA and >>> DOI are >>> presented. >>> >>> I would say this document is getting close to being Ready, but still has >>> issues. >>> >>> A significant problem is that the document is not particularly well >>> written. >>> The quality of the text is poor, with at least six typos or mistakes in >>> just >>> the initial two paragraph abstract, which does not put the reader in a >>> good >>> frame of mind to read the main body of the document. There are mistakes >>> throughout the document. I would suggest that a full check, from start >>> to >>> finish, is required before the draft can progress. >>> >>> It may be the fact that the draft is now over 10 years old means it has >>> been >>> “cobbled” over a long period and perhaps it therefore doesn’t flow as >>> well as >>> it would were it written from scratch today. >>> >>> General comments: >>> >>> The introduction section introduces a lot of new terms and language, and >>> notes >>> on how various elements and components are related, and communicate. A >>> clear >>> diagram would be really helpful here. There is one in 5.1, but a >>> high-level >>> one in section 1 would improve the document. >>> >>> You are probably right, but when we tried we almost ended up in >> repeating the figure of section 5.1 and finally removed it. If this is not >> essential, I would prefer to leave it as it is. >> >> >> The trouble is you are very familiar with the work. It’s a bit of a >> brick wall to those reading it for the first time, especially with so many >> new terms being used for things that could be referred to with more >> familiar terms. I would strongly recommend a figure early on, but >> obviously it’s up to the IESG as to what they want to see. >> >> > I have added a simplified figure of the architecture that I think is > readable. > >> Otherwise, I am ok with the general principle of what is proposed, i,.e. a >>> ‘hidden’ primary and a secondary in the DOI part, feeding the publicly >>> accessible servers. But this could also be done with a standard DNS >>> approach - >>> should thus be noted and a section added pointing out the pros and cons >>> of each >>> approach? >>> >>> I suppose the standard approach you are referring to is the use of DNS >> UPDATE. If that is the case, we tried to have such a section to state >> differences between the two methods and removed it. The main difference is >> that DNS UPDATE does not update the zone itself but of course one could >> update each RRset of the zone. >> >> >> Well, I don;’t think the primary has to live in the home network, for >> example. I don’t think this draft describes a bad idea, but presenting the >> trade-offs may be useful. Or perhaps that’s a separate draft. >> > In our case the HNA builds the zone so if the HNA is not in the home > network that becomes a very specific case. I agree there could be a way the > HNA may be split in to sub functions. In my mind we provide a basic use > case, which can be further declined in more specific ways, and I agree that > these specificites should be the purpose of other drafts. At least that is > what I intend to do for the specific case we have. > I thought your initial comment was about comparing briefly DNSUPATE and > this proposal. We tried and failed more than once, so I prefer not to raise > that again. > >> >> I would like to see, perhaps as an Appendix, a clear list of steps that >>> would >>> happen, to go from the starting point (presumably arrangement for the >>> domain(s) >>> and startup of the HNA function) to a steady operational state, maybe >>> even as a >>> state diagram. This could include a clearer view of how the user updates >>> the >>> information they wish to make available. There’s hints of parts of this >>> in the >>> document, but not a whole view. >>> >>> >> The purpose of the draft is to set a primary / secondary to outsource the >> zone. How the domain name is acquired, how the zone(s) are populated and >> how the HNA is implemented / deployed in the home network can be very >> complex and can be done in so many ways. We provided some hints but I fear >> the scope could be way too large. I suspect that the companion document >> DHCP options provide more than what you ask for but in the narrow scope of >> an ISP providing names and DOI. I agree it would be good if we have a more >> standard way, but currently I prefer that we remain focused on one >> functionality we want to implement. >> >> >> Perhaps an example, the simplest example, could be presented? >> > > I think the use case section is appropriate for that if the description > remains quite high level as many of the details can go well over the scope > of the document and since this is one of the difficulties we had with that > document I would refrain too much to go beyond the scope of the document. I > think the current introduction of the envisioned deployment scenarios > address your concern. > > """ > A number of deployment scenarios have been envisioned, this section aims at > providing a brief description. > The use cases are not limitations and this section is not normative. > > The main difference between the various deployments concerns the > provisioning of the HNA - that is how it is configured to outsource the > Public Homenet Zone to the DOI - as well as how the Public Homenet Zone is > being provisioned before being outsourced. > In both cases, these configuration aspects are out of the scope of the > document. > > Provisioning the configuration related to the DOI is expected to be > automated as much as possible and require as little as possible interaction > with the end user. > Zero configuration can only be achieved under some circumstances and > {{?I-D.ietf-homenet-naming-architecture-dhc-options}} provides one such > example under the assumption the ISP provides the DOI. {{sec-cpe-vendor}} > describes another variant where the CPE is provided preconfigured with the > DOI. > {{sec-agnostic-cpe}} describes how an agnostic CPE may be configured by > the home network administrator. > Of course even in this case, the configuration can leverage mechanisms to > prevent the end user manually entering all information. > > On the other hand, provisioning the Public Homenet Zone needs to combine > the ability to closely reflect what the end user wishes to publish on the > Internet while easing such interaction. > The HNA may implement such interactions using Web GUI or specific mobile > applications. > > With the CPE configured with the DOI, the HNA contacts the DOI to build a > template for the > Public Homenet Zone, and then provision the Public Homenet Zone. > Once the Public Homenet Zone is built, the HNA strats synchronizing it > with the DOI on the Synchronization channel. > """ > > >> Is the HNA typically a function in the home router? Do we expect CPE >>> vendors >>> to implement this? Which begs the question are there at least two >>> independent >>> implementations of what is described in this text? Is what’s written >>> here >>> theory, or has it been proven? The ideas for this approach have clearly >>> been >>> around for some 10 years at least. >>> >>> We have one implementation. >> >> >> OK, that’s good. Is there any report or presentation on experience with >> it available? >> > Not that I know. > >> >> The HNA signs the zone for DNSSEC, but is this a MUST? DNSSEC is >>> mentioned >>> many times, but this is unclear. In 5.1 and in 6.1 the sentence about >>> this >>> doesn’t say MUST, but later in section 11 it does. If it is a MUST, say >>> so >>> earlier. Of course, DNSSEC is not exactly pervasive as it is. >>> >>> This is how we would like things to be. However, we prefer the zone to >> be signed by the DOI than not being signed. >> >> >> OK, but the problem at the moment is the MUST comes late in the >> document. It’s vague to that point. >> > > I changed the sentence to the one below in the architecture overview. I > think this addresses your concern. > """ > It is RECOMMENDED the HNA implements DNSSEC, in which case the HNA MUST > signs the Public Homenet Zone with DNSSEC. > """ > > >> Specific comments: >>> >>> Abstract: >>> >>> “The names and IP address of the home network are present in the Public >>> Homenet >>> Zone by the Homenet Naming Authority (HNA)“ - “are present” needs >>> correcting. >>> >>> change to set : >> """ >> The names and IP address of the home network are set in the Public >> Homenet Zone by the Homenet Naming Authority (HNA), which in turn instructs >> an outsourced infrastructure to publish the zone on the behalf of the home >> owner. >> """ >> >> >> That’s better, thanks. >> >> “Home networks are increasingly numbered using IPv6 addresses, which >>> makes this >>> access much simpler.” - well, it means global addresses are available, >>> but the >>> issues of for example naming, numbering, firewalling and appropriate >>> access >>> control remain. >>> >>> >> My understanding of the text you propose is that it can be interpreted as >> there are no mechanisms to update the DNS and that we are raising multiple >> issues that we do not deal with in the draft. I rephrase the abstract as >> follows: >> >> >> Well, you imply that “IPv6 makes it MUCH simpler”, I’m not (yet) >> convinced the “much” part is true, because the access is part of a broader >> picture. From a pure IP point of view, yes. >> > I removed "much", but the idea was to say we did not have to NAT > everything. > > >> Home network owners may have devices or services hosted on this home >> network that they wish to access from the Internet (i.e., from a network >> outside of the home network). >> Home networks are increasingly numbered using IPv6 addresses, which makes >> this access much simpler, but their access from the Internet requires the >> names and IP addresses of these devices and services to be made available >> in the public DNS. >> >> This document describes how an Home Naming Authority (NHA) instructs the >> outsourced infrastructure to publish these pieces of information >> in the public DNS. >> The names and IP addresses of the home network are set in the Public >> Homenet Zone by the Homenet Naming Authority (HNA), which in turn instructs >> an outsourced infrastructure to publish the zone on the behalf of the home >> network owner. >> >> >> I would change to "which in principle can make this access simpler”, but >> up to you. >> >> ok I changed to that abstract and adapted it to the intro as well. > > >> The abstract could say this is an IPv6-only mechanism, if that’s the case. >> >> That is what we had initially and since the mechanism we describe can > also be implemented for IPv4 we included both versions. So I prefer the > first alternative you proposed. ;-) > >> Section 3: >>> >>> ULA use here should be very strongly discouraged. For a “Public Homenet >>> Zone” >>> should we not use strong language for GUA? Documents talking about ULAs >>> tend >>> to take a long time to get published :) >>> >>> These are in my opinion recommendations that go a bit out of the scope >> of the document as we limit our scope to the outsourcing mechanism. As a >> result, I would prefer not to be too strong on these recommendations. We do >> not limit what can be put in the zone file. >> >> >> I agree, my point is that mentioning ULA use is like mentioning SLAAC or >> DHCPv6. Just leave it out. Use regular GUAs as the example. >> >> > I am wondering if that would work for you. I need to discuss with my > co-authors about removing ULA as I think they had a case for it. > > A device or service SHOULD have Global Unicast Addresses (GUA) (IPv6 > {{?RFC3787}} or IPv4), but MAY also have Unique Local IPv6 Addresses (ULA) > {{?RFC4193}}, IPv6-Link-Local addresses{{?RFC4291}}{{?RFC7404}}, > IPv4-Link-Local Addresses {{?RFC3927}} (LLA), and finally, private IPv4 > addresses {{!RFC1918}}. > >> Section 4: >>> >>> In 4.1.1 the method in bullet point 3 seems very ugly. >>> >>> This is an example. We updated the text as follows: >> >> """ >> * If the DOI is not the DNS Registrar, then the proof of ownership needs >> to be established using some other protocol. >> ACME {{?RFC8555}} is one protocol that would allow an owner of an >> existing domain name to prove their ownership (but requires they have DNS >> already setup!) >> There are other ways such as putting a DOI generated TXT record, or web >> site contents, as championed by entities like Google's Sitemaster and >> Postmaster protocols. >> """ >> >> >> OK, but it’s still far from “simple”. >> > sure but automated ;-) > >> >> Section 5: >>> >>> In the diagram, does the DOI in fact cover the public authoritative >>> servers, >>> given you say “The DOI will serve every DNS request of the Public >>> Homenet Zone >>> coming from outside the home network.“ As it is the diagram shows the >>> DOI only >>> populating the public authoritative servers? >>> >>> That seems correct, we will update the figure. >> >> >> ok. >> >> >> In 5.2 does “protected” mean provision of confidentiality? >>> >>> at the very least with integrity protection, but here with TLS it means >> confidentiality. >> >> >> So maybe say that explicitly. >> >> changed to: > Since communications are established with names which remain a global > identifier, the communication can be protected (at the very least with > integrity protection) by TLS the same way it is protected on the global > Internet - using certificates. > >> Section 6: >>> >>> In 6.1, “perhaps and” ? >>> >>> In 6.5, the use of a DNS zone transfer to provide commands seems ugly. >>> >>> this is the The HNA then performs a DNS Update operation >> >> Section 12: >>> >>> Talks about power cycling of the HNA. This implies it’s resident on >>> specific >>> hardware, but what is expected or recommended? COPE an d HNA are >>> sometimes >>> used interchangeably in the document. >>> >>> This document considers the HNA is hosted on the CPE but the HNA may be >> hosted elsewhere and the HNA should be seen as a function. In the >> renumbering section, we prefer to say the CPE is being renumbered as >> opposed to the function. >> >> >> OK, but again if there were a common, simple deployment model/process >> example in the appendix that might be clearer. >> >> Section 14: >>> >>> The document “exposes a mechanism” ? >>> >>> In 14.4, maybe mention here if any special considerations for a >>> replacement CPE >>> (and thus HNA if that model its used) are needed? >>> >>> Well, I believe that is more related to the operation of the HNA, and >> this can be handled in multiple ways. The DHCP companion describes one way >> to do. >> >> >> OK. >> >> I also think Experimental would be a more appropriate classification for >> the document. But it’s good to see it getting this far, and an >> implementation being available. >> >> Best wishes, >> > that is needed ;-) > >> Tim >> >> >> Tim >>> >>> >>> >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>> >> >> >> -- >> Daniel Migault >> Ericsson >> >> >> > > -- > Daniel Migault > Ericsson > > > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet