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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

Hi,

On 6 Jan 2023, at 13:36, Eric Vyncke (evyncke) <evyncke@xxxxxxxxx> wrote:

Well-deserved break for the R&E community, I also took about 10 days off ;-)
 
More seriously, there was a major rewrite between -18 (the first IESG telechat) and -25 (yesterday telechat):
 
But you are correct, even my French-reading eye spot two grammar errors: "needs to be made available" (rather than "need") and "how an this" (rather weird).

I can see at least:

This home -> their home
Needs to -> need to
IP address -> IP addresses
Are present in the -> are made available in the ?
On the behalf -> on behalf
Home owner -> home network owner
How an this -> how the

And then the bold claim about IPv6 making access simpler :)

But I think as an abstract it should better summarise the document.  This is probably a symptom of it being a document that’s been 10 years in the editing pot.  It’s ended up as an interesting idea, as the community feedback has been included, but there are gaps in details, and much that would lead many to prefer Experimental status at this stage.

As you may have read in the Homenet WG list [1], there are some ways forward about the intended status. Let's wait for authors/WG/IETF community feedback.

I’ve not read that recently. 

Tim
 
Regards
 
-éric
 
 
From: Tim Chown <Tim.Chown@xxxxxxxxxx>
Date: Friday, 6 January 2023 at 14:03
To: Eric Vyncke <evyncke@xxxxxxxxx>
Cc: "int-dir@xxxxxxxx" <int-dir@xxxxxxxx>, "draft-ietf-homenet-front-end-naming-delegation.all@xxxxxxxx" <draft-ietf-homenet-front-end-naming-delegation.all@xxxxxxxx>, "homenet@xxxxxxxx" <homenet@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx>
Subject: Re: Intdir telechat review of draft-ietf-homenet-front-end-naming-delegation-25
 
Hi Eric, 
 
Sorry, the R&E world closes for 2 weeks over the holiday period :)
 
I just read the IESG comments now, and your comment that "The flow and the text (grammar, English) had also a rewrite”, but the diffs from 24 (my review) to 25 (new) are very
minor and the abstract for example still has six typos or errors in just two paragraphs.  I don’t think any of the errors confuse semantics, but it’s in a very poor state compared to other draft that I’ve reviewed at a close to Ready state.
 
The suggestion to move it to Experimental is good, imo.
 
Tim


On 6 Jan 2023, at 11:56, Eric Vyncke (evyncke) <evyncke@xxxxxxxxx> wrote:
 

Thank you very much Tim for your review for int-dir.

Even if a little too late for the IESG telechat, I am sure that the authors will take your review in consideration. I personally like your suggestion to add an appendix section on the deployment/operation timeline.

Regards


-éric


On 05/01/2023, 16:12, "Tim Chown via Datatracker" <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> 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.


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


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.


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.


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.


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


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


Section 4:


In 4.1.1 the method in bullet point 3 seems very ugly.


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?


In 5.2 does “protected” mean provision of confidentiality?


Section 6:


In 6.1, “perhaps and” ?


In 6.5, the use of a DNS zone transfer to provide commands seems ugly.


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.


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?


Tim


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux