Re: [homenet] Genart last call review of draft-ietf-homenet-front-end-naming-delegation-18
Daniel Migault <mglt.ietf@gmail.com> Wed, 19 October 2022 17:27 UTC
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93065C183F9A; Wed, 19 Oct 2022 10:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBNkzTXeFiGi; Wed, 19 Oct 2022 10:27:18 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A098C1524C0; Wed, 19 Oct 2022 10:27:08 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id i65so15116459ioa.0; Wed, 19 Oct 2022 10:27:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bgkvxqdBWcnsn676vggP06KUYYcg5dfQDHb6GTkXM4U=; b=imj1iqkZJYTjXkbaLDDSX7S02cwI1nZZtJSDo2FxSsBaO844CDJGUOV3wsc2KBW5sc guEKbkC313Bw/CQoD7Kj9j4CmMvzrWs8oe25aJujdu/zFIchWL7d1s/Bc+xSq81arw3i CqyTr4IS8GAOkTDo4Y8ZXvdySQuwpw+o/E5baV8L1VATsKQQQVPjvK4GiEIE2+zptf8w 8g2ijrwjxCa/ab7T6fWaY7ykbLc+M+LMRR7rF27Rcoq1EpRsZi5MNXL86QSgCTLQUaxQ bBQvgye358DrgUdB4KXxcGfhuBPUwxcPVSDHIii1tyxVSh7xLmRfh+oNWa2X1n8rwp5/ CCQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bgkvxqdBWcnsn676vggP06KUYYcg5dfQDHb6GTkXM4U=; b=pm4ywyeksCJfDJkhGi+Uq6Vp6whFNOMQjSg1STX1ynhhFM2Bwq1a/dwzyk5AEiLNjC 7Bm3d0Is6l9iaOP7CS5YbWi7k/UVuKcxWPHBHKJHeoyKG9UWYF/+AO1gejuEs3WMK7bF NNNLuVuWAYQk2c5ND93bLI/N8T3TXhByCT6eXF2Z57FRjsb5cCHm83Q8WAGf9tzLoPul ZRBXfYEbiac2UcasvoLWH+HmKp88UK5y4CXknUytKDmXiCeOD6mg0CO1qQVcZa94Rkuz n5ETVMmWBQugGJJ/xekU7h7fqOz/U6KkwhQ3ZzaU9yOa/uEW5gpZUMTjSUjoICgcuUAV Zsag==
X-Gm-Message-State: ACrzQf1SPyLgeWyOfAOZ38FI3dKHVCIeSKJX2s00wLgtYy1r1JcmbWAE ESJpBX79zer1AGevrnHACgxvyErjiKyDCNmIS54+DG9e
X-Google-Smtp-Source: AMsMyM5tUhj7z4S1TL0W+NxPCKpC2B35LvtXud6pfU0X2Z35M1DAI4bzgTBsiTB7SgtR4heqcHBH3vH6euFOsujsX1U=
X-Received: by 2002:a6b:be86:0:b0:6b9:7a46:479f with SMTP id o128-20020a6bbe86000000b006b97a46479fmr6473457iof.130.1666200427788; Wed, 19 Oct 2022 10:27:07 -0700 (PDT)
MIME-Version: 1.0
References: <166487874905.50678.4622524125123802453@ietfa.amsl.com> <CADZyTkm+vtD5qiJUeuDrVXxvQ4zw_geb_VmHNau9KgUo_7S6kg@mail.gmail.com> <HE1PR07MB44414B0AEAF69CA4123426AC93209@HE1PR07MB4441.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB44414B0AEAF69CA4123426AC93209@HE1PR07MB4441.eurprd07.prod.outlook.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Wed, 19 Oct 2022 13:26:56 -0400
Message-ID: <CADZyTkkft0wjmDTc8pPi7kwLUqKJcQXh-9_USsbrFhcSG0fsoQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "gen-art >> General area reviewing team" <gen-art@ietf.org>, "draft-ietf-homenet-front-end-naming-delegation.all@ietf.org" <draft-ietf-homenet-front-end-naming-delegation.all@ietf.org>, homenet <homenet@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009f81f305eb66842a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/mdaLuCE1tUAsIAU88-6NW0-LcnI>
Subject: Re: [homenet] Genart last call review of draft-ietf-homenet-front-end-naming-delegation-18
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2022 17:27:23 -0000
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.holmberg@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 < > noreply@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 > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > > > -- > > Daniel Migault > > Ericsson > -- Daniel Migault Ericsson
- [homenet] Genart last call review of draft-ietf-h… Christer Holmberg via Datatracker
- Re: [homenet] Genart last call review of draft-ie… Daniel Migault
- Re: [homenet] Genart last call review of draft-ie… Christer Holmberg
- Re: [homenet] Genart last call review of draft-ie… Daniel Migault
- Re: [homenet] [Last-Call] Genart last call review… Lars Eggert
- Re: [homenet] Genart last call review of draft-ie… Christer Holmberg