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

[Daniel Migault <[e-mail]>]

Thanks for the feedback. We did remove one sentence with ULA but this is
correct ULA has not entirely been removed.

Yours,
Daniel

On Tue, Jan 17, 2023 at 9:25 AM Tim Chown <[e-mail]> wrote:

> Thank you for the update Daniel, I am overall happy with the changes.  I
> suspect ULAs will be picked up by other reviews.
>
> Tim
>
> On 13 Jan 2023, at 19:17, Daniel Migault <[e-mail]> wrote:
>
> Hi Tim,
>
> Thanks for the feed backs. Please see how the document has been updated.
> The ULA comment may remain open.
>
> https://github.com/ietf-homenet-wg/ietf-homenet-hna/pull/62/commits/cbf182af1bf749f09348a178268d62b745c3d6d6
>
> You can also find some more description / comments inline.
>
> Thanks for the follow-up!
> Yours,
> Daniel
>
>
> On Thu, Jan 12, 2023 at 10:28 AM Tim Chown <[e-mail]> wrote:
>
>> Hi,
>>
>> In-line...
>>
>> On 9 Jan 2023, at 18:15, Daniel Migault <[e-mail]> wrote:
>>
>> 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 <
>> [e-mail]> 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.
>>
>>
>> The trouble is you are very familiar with the work.  It’s a bit of a
>> brick wall to those reading it for the first time, especially with so many
>> new terms being used for things that could be referred to with more
>> familiar terms.  I would strongly recommend a figure early on, but
>> obviously it’s up to the IESG as to what they want to see.
>>
>>
> I have added a simplified figure of the architecture that I think is
> readable.
>
>> 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.
>>
>>
>> Well, I don;’t think the primary has to live in the home network, for
>> example.  I don’t think this draft describes a bad idea, but presenting the
>> trade-offs may be useful.  Or perhaps that’s a separate draft.
>>
> In our case the HNA builds the zone so if the HNA is not in the home
> network that becomes a very specific case. I agree there could be a way the
> HNA may be split in to sub functions.  In my mind we provide a basic use
> case, which can be further declined in more specific ways, and I agree that
> these specificites should be the purpose of other drafts. At least that is
> what I intend to do for the specific case we have.
> I thought your initial comment was about comparing briefly DNSUPATE and
> this proposal. We tried and failed more than once, so I prefer not to raise
> that again.
>
>>
>> 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.
>>
>>
>> Perhaps an example, the simplest example, could be presented?
>>
>
> I think the use case section is appropriate for that if the description
> remains quite high level as many of the details can go well over the scope
> of the document and since this is one of the difficulties we had with that
> document I would refrain too much to go beyond the scope of the document. I
> think the current introduction of the envisioned deployment scenarios
> address your concern.
>
> """
> A number of deployment scenarios have been envisioned, this section aims at
> providing a brief description.
> The use cases are not limitations and this section is not normative.
>
> The main difference between the various deployments concerns the
> provisioning of the HNA - that is how it is configured to outsource the
> Public Homenet Zone to the DOI - as well as how the Public Homenet Zone is
> being provisioned before being outsourced.
> In both cases, these configuration aspects are out of the scope of the
> document.
>
> Provisioning the configuration related to the DOI is expected to be
> automated as much as possible and require as little as possible interaction
> with the end user.
> Zero configuration can only be achieved under some circumstances and
> {{?I-D.ietf-homenet-naming-architecture-dhc-options}} provides one such
> example under the assumption the ISP provides the DOI. {{sec-cpe-vendor}}
> describes another variant where the CPE is provided preconfigured with the
> DOI.
> {{sec-agnostic-cpe}} describes how an agnostic CPE may be configured by
> the home network administrator.
> Of course even in this case, the configuration can leverage mechanisms to
> prevent the end user manually entering all information.
>
> On the other hand, provisioning the Public Homenet Zone needs to combine
> the ability to closely reflect what the end user wishes to publish on the
> Internet while easing such interaction.
> The HNA may implement such interactions using Web GUI or specific mobile
> applications.
>
> With the CPE configured with the DOI, the HNA contacts the DOI to build a
> template for the
> Public Homenet Zone, and then provision the Public Homenet Zone.
> Once the Public Homenet Zone is built, the HNA strats synchronizing it
> with the DOI on the Synchronization channel.
> """
>
>
>> 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.
>>
>>
>> OK, that’s good. Is there any report or presentation on experience with
>> it available?
>>
> Not that I know.
>
>>
>> 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.
>>
>>
>> OK, but the problem at the moment is the MUST comes late in the
>> document.  It’s vague to that point.
>>
>
> I changed the sentence to the one below in the architecture overview. I
> think this addresses your concern.
> """
> It is RECOMMENDED the HNA implements DNSSEC, in which case the HNA MUST
> signs the Public Homenet Zone with DNSSEC.
> """
>
>
>> 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.
>> """
>>
>>
>> That’s better, thanks.
>>
>> “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:
>>
>>
>> Well, you imply that “IPv6 makes it MUCH simpler”, I’m not (yet)
>> convinced the “much” part is true, because the access is part of a broader
>> picture.  From a pure IP point of view, yes.
>>
>  I removed "much", but the idea was to say we did not have to NAT
> everything.
>
>
>> 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.
>>
>>
>> I would change to "which in principle can make this access simpler”, but
>> up to you.
>>
>> ok I changed to that abstract and adapted it to the intro as well.
>
>
>> The abstract could say this is an IPv6-only mechanism, if that’s the case.
>>
>> That is what we had initially and since the mechanism we describe can
> also be implemented for IPv4 we included both versions. So I prefer the
> first alternative you proposed. ;-)
>
>> 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.
>>
>>
>> I agree, my point is that mentioning ULA use is like mentioning SLAAC or
>> DHCPv6.  Just leave it out.  Use regular GUAs as the example.
>>
>>
> I am wondering if that would work for you. I need to discuss with my
> co-authors about removing ULA as I think they had a case for it.
>
> A device or service SHOULD have Global Unicast Addresses (GUA) (IPv6
> {{?RFC3787}} or IPv4), but MAY also have Unique Local IPv6 Addresses (ULA)
> {{?RFC4193}}, IPv6-Link-Local addresses{{?RFC4291}}{{?RFC7404}},
> IPv4-Link-Local Addresses {{?RFC3927}} (LLA), and finally, private IPv4
> addresses {{!RFC1918}}.
>
>> 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.
>> """
>>
>>
>> OK, but it’s still far from “simple”.
>>
> sure but automated ;-)
>
>>
>> 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.
>>
>>
>> ok.
>>
>>
>> In 5.2 does “protected” mean provision of confidentiality?
>>>
>>> at the very least with integrity protection, but here with TLS it means
>> confidentiality.
>>
>>
>> So maybe say that explicitly.
>>
>> changed to:
>  Since communications are established with names which remain a global
> identifier, the communication can be protected (at the very least with
> integrity protection) by TLS the same way it is protected on the global
> Internet - using certificates.
>
>> 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.
>>
>>
>> OK, but again if there were a common, simple deployment model/process
>> example in the appendix that might be clearer.
>>
>> 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.
>>
>>
>> OK.
>>
>> I also think Experimental would be a more appropriate classification for
>> the document.  But it’s good to see it getting this far, and an
>> implementation being available.
>>
>> Best wishes,
>>
> that is needed ;-)
>
>> Tim
>>
>>
>> Tim
>>>
>>>
>>>
>>> _______________________________________________
>>> homenet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/homenet
>>>
>>
>>
>> --
>> Daniel Migault
>> Ericsson
>>
>>
>>
>
> --
> Daniel Migault
> Ericsson
>
>
>

-- 
Daniel Migault
Ericsson