[homenet] SECOND Last Call: (Simple Provisioning of Public Names for Residential Networks) to Experimental RFC
The IESG has received a request from the Home Networking WG (homenet) to consider the following document: - 'Simple Provisioning of Public Names for Residential Networks' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-01-31. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Home network owners may have devices or services hosted on their 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 in principle makes this access 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 behalf of the home network owner. As a follow-up of the IESG telechat on the 5th of January 2023, it was decided by *all* the authors to change the intended status to experimental. Of course, this does not prevent a future -bis with a 'proposed standard' intended status leveraging the experience gained by implementations and experimentations. The change of intended status requires another IETF Last Call, so please review and comment on this document if not yet done (bearing in mind the experimental intended status). NB: this will also create a 'downref' for draft-ietf-homenet-naming-architecture-dhc-options per RFC 8067. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ No IPR declarations have been submitted directly on this I-D. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25
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 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 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 wrote: > >> Hi, >> >> In-line... >> >> On 9 Jan 2023, at 18:15, Daniel Migault 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
Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25
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 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 mailto:tim.ch...@jisc.ac.uk>> wrote: Hi, In-line... On 9 Jan 2023, at 18:15, Daniel Migault mailto: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 mailto: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
