Hi Christer,
We followed Tim's recommendation to put the early subsection as sections to
make the introduction more concise.
We added the following text to section 3, which I hope addresses your
concern.
This section provides an overview of the architecture for outsourcing the
authoritative naming service from the HNA to the DOI.
As a consequence, this prevents HNA to handle the DNS traffic from the
Internet associated to the resolution of the Homenet Zone as depicted in
{{fig-naming-arch-overview}}.
More specifically, DNS resolution for the Public Homenet Zone ( here
myhome.example) from Internet DNSSEC resolvers is handled by the DOI as
opposed to the HNA.
The DOI benefits from a cloud infrastructure while the HNA is dimension ed
for home network and as such likely enable to support any load.
In the case the HNA is a CPE, outsourcing to the DOI protects the
homenetwork against DDoS for example.
Of course the DOI needs to be informed dynamically about the content of
myhome.example.
The description of such a synchronization mechanism is the purpose of this
document.
~~~~
Home network | Internet
+----------------------+ | +----------------------+
| HNA | | | DOI |
|+--------------------+| | |+--------------------+|
|| Public Homenet Zone||<------------>|| Public Homenet Zone||
|| (myhome.example) || | || (myhome.example) ||
|+--------------------+| DNS Zone | |+--------------------+|
+----------------------+ Synchron- | +----------------------+
ization | ^ | (DNS resolution)
| | v
| +-----------------------+
| | Internet |
| | DNSSEC Resolver |
| +-----------------------+
~~~~
{: #fig-naming-arch-overview title="Homenet Naming Architecture Overview" }
Note that {{info-model}} defines necessary parameter to configure the HNA.
On Mon, Oct 10, 2022 at 4:27 AM Christer Holmberg <
christer.holmb...@ericsson.com> wrote:
> Hi,
>
>
>
> >Thanks for the review. I do agree with you the introduction is taken as
> a whole quite long. Its current structure resulted from (multiple)
> discussions where we have been told to clarify some upcoming
>
> >questions many people in the group would come up with and needed to be
> clarified. This is why we do have a short introduction text that is
> followed by some more specific subsections.
>
> >
>
> >I do not necessarily disagree with you saying these sections could be in
> appendices. We tried and moved them back and forth from the very
> beginning of the draft to the very end. As a result,
>
> >unless you have a strong feeling against the current structure, I
> would be inclined to leave it as it is.
>
>
>
> It’s editorial, so I don’t have a strong feeling :)
>
>
>
> >To address your second point, I can think of adding a figure with maybe
> one sentence in the introduction after the following text:
>
> >
>
> >This document describes how a Homenet Naming Authority (HNA) can
> instruct a DNS Outsourcing Infrastructure (DOI) to publish a Public
> Homenet Zone on its behalf.
>
> >
>
> >Would this address your concern or do you have something more specific
> in mind ? Given the length of the document I would like to avoid adding any
> new section.
>
>
>
> I don’t think you need to add a new section. I think you can clarify in
> the existing Section 3, by first describe the difference “boxes” etc in the
> architecture, and after that give some examples on how they work. I am sure
> call flows would make things easier to understand.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> On Tue, Oct 4, 2022 at 6:19 AM Christer Holmberg via Datatracker <
> nore...@ietf.org> wrote:
>
> Reviewer: Christer Holmberg
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-homenet-front-end-naming-delegation-18
> Reviewer: Christer Holmberg
> Review Date: 2022-10-04
> IETF LC End Date: 2022-10-04
> IESG Telechat date: 2022-10-20
>
> Summary:
>
> Since the topic is outside the area of my expertise, I have no technical
> comments. I do think the document is a little difficult to read. Below I
> have a
> couple of editorial comments, and I think addressing those could improve
> the
> readability of the document.
>
> Major issues: N/A
>
> Minor issues: N/A
>
> Nits/editorial comments:
>
> Q1:
>
> In my opinion the Introduction section is too long, and goes into too many
> details. There are also things which I don't think belong to the
> Introduction.
>
> For example, I don't think the text in Section 1.1 belongs to the
> Introduction,
> and is not needed in order to get an overview of the mechanism. I think it
> belongs to a separate section (perhaps an Appendix). The same applies to
> Section 1.3.
>
> Similarly, Section 1.2 seems to talk about alternative solutions, before
> the
> solution in the draft has been clearly explained. I think it should be a
> separate section, later in the document.
>
> Q2:
>
> It is quite difficult to get a picture of how the mechanism work. There
> are no
> examples, or step-by-step functionality/use-case descriptions. Also,
> Section
> 3.1 seems to be a mixture of architecture and functionality, which is a
> little
> confusing.
>
>
>
> _______________________________________________
> homenet mailing list
> home...@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>
--
Daniel Migault
Ericsson
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
