Hi Anthony, Thanks for the review. Please see my response in line. You can also find the commit associated to the comments here: https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/2fcc1c1606b8fbaf2ff10505ad00fab2c020ddd9
Thanks for the review. Yours, Daniel On Wed, Oct 12, 2022 at 8:25 AM Anthony Somerset via Datatracker < nore...@ietf.org> wrote: > Reviewer: Anthony Somerset > Review result: Ready with Nits > > Hello > > I have been selected as the DNS Directorate reviewer for this draft. The > DNS Directorate seeks to review all DNS or DNS-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the ADs. > For more information about the DNS Directorate, please see > https://wiki.ietf.org/en/group/dnsdir > > There are are clear and direct references to various DNS RFC's and this > draft is not in any major conflict with the wider DNS space but the > following specific suggestions relating to DNS are made. > > Major Issues: None > > Minor Issues: > > Section 2 - Public Authoritative Servers > > I would suggest that we don't specifically mention the resiliency > comments but instead point readers to the relevant RFC which looks to be > RFC1034 Section 4.1 to be specific, this is because RFC1034 suggests the > requirement is MUST and not SHOULD so would otherwise appear to be > conflicting > > the sentence has been suppressed > Section 3.2 = "SHOULD remain pointing at the cloud provider's server IP > address > - which in many cases will be an anycast addresses." > > I don't believe its correct to include this assumption about anycast > addresses > and is largely irrelevant to the content of the draft so i don't believe > there > is value in keeping the text after the hyphen > > I agree this is out of scope of the document, but I find it illustrative, so I would prefer to keep this. > Other Editorial comments and NITs please feel free to ignore these. Please > note that these are not exhaustive. > > The intro is very long and talks about things that don't get explained > until > much later in document and could cause some confusion, it may be better to > make > the intro more concise and move some of these aspects into the relevant > sections. > > This is a recurrent comment I objected as these sections have been moved back and forth. That said, I believe Tim's proposal is a good compromise. I think that should address the concern regarding the length of the intro. Thanks. > Section 1.2 - to me this would flow better if it was its own section after > the > solution is explained > > NITs > > 1.1 2nd Para says that "the HNA would then collect the IPv6 address(es)" > but > following para says "A device or service may have Global Unicast Addresses > (GUA) (IPv6 [RFC3787] or IPv4)..." > > is the former a typo that accidentally excludes IPv4? and would it be > better to > say IPv6 and IPv4 addresses > > Initially the document was only considering IPv6 as Homenet only considers IPv6. On the other hand, the mechanism described is not restricted to IPv6 and so we have been considering IPv4. So this is a typo now - but we know were it comes from ;-) I changed this to IP addresses. 1.2 - "Dynamic Updates solution are not" possible typos? > should it be "Dynamic Update solutions are not" > > changed > 3.1 - Typo "Resolver as detaille din further details below." should be > "Resolver as detailed in further details below." > > changed from a previous comment from Matt I think. Just to let you know you may not see the change in your commit. > 4.5.1 > > this section initially talks about communicating with the DM (Distribution > Manager) via an AXFR but then refers to the DOI in the same context as a > responder but they are described as different components in glossary - > This > should probably be clarified > > I am wondering what can we add to clarify thi sin the glossary: DNS Outsourcing Infrastructure (DOI): : is the infrastructure responsible for receiving the Public Homenet Zone and publishing it on the Internet. It is mainly composed of a Distribution Manager and Public Authoritative Servers. > I think there would be merit in this going for security review > additionally. > My specific minor concerns about this is about the concept of having a DNS > service exposed to the internet on a CPE to enable the transmission of > data > between Homenet Naming Authority and Distribution Manager. > > I see this as being described in HNA DM channel in the security considerations section. I am wondering if there is anything we are missing. > > _______________________________________________ > 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
