Hi Anthony,
Thanks for the review. Please see my response in line. You can also find the commit associated to the comments here:
Thanks for the review.
Yours,
Daniel
On Wed, Oct 12, 2022 at 8:25 AM Anthony Somerset via Datatracker <noreply@xxxxxxxx> 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.
: 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/homenet
Daniel Migault
Ericsson
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
