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 <noreply@xxxxxxxx> 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
homenet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/homenet
-- |
<<attachment: smime.p7s>>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
