Re: [homenet] Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25

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 <noreply@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.

> 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.

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.

> 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.

> 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.

> 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.
"""

> “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:

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.

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.

> 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.
"""

> 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.

> In 5.2 does “protected” mean provision of confidentiality?
>
> at the very least with integrity protection, but here with TLS it means
confidentiality.

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.

> 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.

Tim
>
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>

-- 
Daniel Migault
Ericsson