Simple Provisioning of Public Names for Residential Networks
draft-ietf-homenet-front-end-naming-delegation-27

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-homenet-front-end-naming-delegation and RFC 9526, changed IESG state to RFC Published)

[Ballot comment]
Thanks for all the work that went into this, especially since its last pass through the IESG.  Thank you also for reconsidering the document's official status.

I generally found this to be readable if I look at it as an applicability statement (RFC 2026, Section 3.2) over DNS for the Homenet use case.  Was that the intent, or am I way off?

Thanks to Darrel Miller for his ARTART review.  (A second review on the latest revision is pending as I write this.)

The last bullet of Section 4.1.1 appears to be mangled in a few places.  Please review.

I have my usual complaint about the use of SHOULD throughout the document: SHOULD provides implementers with a choice, and generally the SHOULDs here don't acknowledge that choice or provide implementers with any guidance about when it might be appropriate to exercise that choice.  I suggest reviewing them (there are 25, and 6 RECOMMENDEDs) and either adding such prose, or reconsidering whether they should be MUST or MAY.

This I-D is now aiming at experimental status as strongly suggested by several ADs. This has created a downref for the companion DHC-option I-D, this downref was approved by the IESG during the informal telechat of 26th of Jan 2023.

[Ballot discuss]
According to the shepherd writeup (and assuming it still reflects reality today; it's dated July of this year, nine revisions ago), there are no implementations, and none are planned.  There's no Implementation Status section either.  However, in the reply to Paul's earlier DISCUSS, there is a claim that some part of this was implemented.  I've also been told there is one vendor planning to implement this, but that doesn't match the record.  Can someone clarify where we are today?  The existence of implementations would certainly allay the previous concerns about complexity and clarity that were expressed in other prior ballot positions.

This document has been in development for over 10 years.  Assuming there is no wide deployment or an implementation to which one can refer, why are we publishing this on the standards track?  Wouldn't Experimental or Informational be more appropriate?  The shepherd writeup doesn't explain why Proposed Standard is justified; it just says "PS".

(Please note that RFC 2026 says implementations aren't required, so I am not requiring one either by posting this ballot.  I just want to have the discussion.)

[Ballot comment]
My earlier discusses and comments have been addressed. (well except the TLS session resumption being a SHOULD instead of a MAY, but I'll count myself in the rough of consensus on that.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-homenet-front-end-naming-delegation-26, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-01-31):

From: The IESG
To: IETF-Announce
CC: draft-ietf-homenet-front-end-naming-delegation@ietf.org, evyncke@cisco.com, homenet-chairs@ietf.org, homenet@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: last-call@ietf.org
Sender:
Subject: SECOND Last Call:  (Simple Provisioning of Public Names for Residential Networks) to Experimental RFC


The IESG has received a request from the Home Networking WG (homenet) to
consider the following document: - 'Simple Provisioning of Public Names for
Residential Networks'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-01-31. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Home network owners may have devices or services hosted on their 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 in principle makes this access
  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 behalf of the home network owner.

As a follow-up of the IESG telechat on the 5th of January 2023, it was decided by *all* the authors to change the intended status to experimental. Of course, this does not prevent a future -bis with a 'proposed standard' intended status leveraging the experience gained by implementations and experimentations.

The change of intended status requires another IETF Last Call, so please review and comment on this document if not yet done (bearing in mind the experimental intended status).

NB: this will also create a 'downref' for draft-ietf-homenet-naming-architecture-dhc-options per RFC 8067.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/



No IPR declarations have been submitted directly on this I-D.

As a follow-up of the IESG telechat on the 5th of January 2023, it was decided by the *all* the authors to change the intended status to experimental. Of course, this does not prevent a future -bis with a 'proposed standard' intended status leveraging the experience gained by implementations and experimentations.

The change of intended status requires another IETF Last Call, so please review and comment on this document if not yet done (bearing in mind the experimental intended status).

NB: this will also create a 'downref' for draft-ietf-homenet-naming-architecture-dhc-options per RFC 8067.

# Document Shepherd Writeup

*This version is dated 16 January 2023. Only change is to intended status.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

N/A.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

Experimental. (Following IETF LC and IEST discussion.)

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM, MR and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

There are some downrefs to fix. It looks like all should be fine
as informative references:

  ** Downref: Normative reference to an Informational RFC: RFC 4192
  ** Downref: Normative reference to an Informational RFC: RFC 6092
  ** Downref: Normative reference to an Informational RFC: RFC 7010
  ** Downref: Normative reference to an Informational RFC: RFC 7084
  ** Downref: Normative reference to an Informational RFC: RFC 7368
  ** Downref: Normative reference to an Informational RFC: RFC 7707

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

All good.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

[Ballot comment]
Personally, I would prefer to see this published as experimental or informational rather then PS because I think that categorization is more helpful/informative for the reader of this specification.  Specifically, I wonder whether there is really IETF consensus that this is the best engineering way to solve this problem in 2023.  I.e., is there any realistic expectation for the industry to move away from dynamic DNS services towards implementing this instead? 

However, I also understand the desire to get this last work in the workgroup finished, and the authors have clearly made an effort to cleanup the spec based on the previous round of comments, so keeping my ballot as No Obj.

Thanks for your work on this document.

Regards,
Rob

[Ballot comment]
Thank you for the work on this document.

Many thanks to Darrel Miller for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/PDXnM9p_Sgj9Th-1YI_Wp-tgJSs/, and to the authors for addressing Darrel's comments.

[Ballot comment]
Thank you for the work on this document.

Many thanks to Darrell Miller for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/PDXnM9p_Sgj9Th-1YI_Wp-tgJSs/, and to the authors for addressing Darrell's comments.

[Ballot comment]
Thanks for the updated in text in -19, -20 and -21 to address my DISCUSS and COMMENT points from the October 2022 telechat.

[For archival purposes, here is the residual DISCUSS elements cleared from the Datatracker for this January 2023 telechat.  We discussed it in this thread, https://mailarchive.ietf.org/arch/msg/homenet/i3q-lX2Clw_YHvE3seVQl2RV1xo/.  No action required.]

** Section 1.3

[per -18] 
  When the resolution is performed from within the home network, the
  Homenet DNSSEC Resolver MAY proceed similarly. 

[per -18] I’m not sure if this my misreading of the behavior of internal clients.  To clarify, the (internal) Homenet DNSSEC Resolver will “... resolves the DS record on the Global DNS and the name associated to the Public Homenet Zone (myhome.example) on the Public Authoritative Servers.”?  Why would the internal resolver serving a request for an internal client for an internal service go to the Global DNS if the information if it could come from the internal Homenet Zone it is already configured with?  As an operational consideration, why go outside of the network if you don’t need to?  As a privacy consideration, why leak the request to an outside entity if the network already has the information.

[per -20] Thanks for the revised text:
  On the other hand, to provide resilience to the Public Homenet Zone
  in case of WAN connectivity disruption, the Homenet DNSSEC Resolver
  SHOULD be able to perform the resolution on the Homenet Authoritative
  Servers.

-- Is there a reason this can’t be a MUST?

[Ballot discuss]
Thanks for the updated document. It is much clearer now which parts are specified and which parts are out of scope. The repeated clarifications with primary/secondary also makes the document much easier to read.

I have a few discuss items left to resolve. Other than the Document Status also raised by others, I think the DISCUSSes should be easy to resolve.

#1 Document Status

As other ADs have pointed out, Standards Track would not be the right
intended status. Experimental would be a much better fit. I understand
this is done because otherwise 3gpp won't consider the document, but
whether the IETF should make its decisions based on that is something
I'd like to discuss with the other members of the IESG.

#2 Security Considerations for DM/DOI missing

There is no Security Considerations paragraph for the DM/DOI ?

For example, if I want to use "ietf.org" for my Public Homenet
Zone, that should probably not be allowed to be served by the
ISPs DM/DOI infrastructure. Similarly, currently non-existing
domains like "mailietf.org" or TLDs should probably not be
allowed. When allowing subdomains of existing registrations,
perhaps it can recommend the DM/DOI does a verification check,
eg via draft-ietf-dnsop-domain-verification-techniques

#3 Conveying the name of the zone to use

        The HNA builds the Public Homenet Zone based on a template that is
        returned by the DM to the HNA.  Section 6.5 explains how this
        leverages the AXFR mechanism.

If it uses AXFR, I guess the name itself cannot be part of the template and
has to be handled differently. Unless it would use DNS catalog zones, eg
draft-ietf-dnsop-dns-catalog-zones.

Information on how to convey the name to be used as Public Homenet Zone
should be added to Section 6.1.

#4 HNA IP address

        As a result, the HNA must provide the IP address the DM should use to reach the HNA.

Note there is an odd lowercase "must" here, which becomes stranger when later on it states:

        By default, the IP address used by the HNA in the Control Channel
        is considered by the DM and the explicit specification of the
        IP by the HNA is only OPTIONAL.

So it seems the HNA doesn't need to "must provide", as its IP as visible by the DM/DOI is
used anyway and providing it (explicitly) is deemed OPTIONAL ?

[Ballot comment]
The description of what a Public Homenet Zone is a bit better, but I think
it would be good to add a sentence somewhere saying it more concise,
eg "The device assigned zone or user configurable zone to use as the
domain to publicly serve hostnames in the home network is called the "Public
Homenet Zone". In this document, "myhome.example" is used as the example
for an enduser owned domain configured as Public Homenet Zone.

After reading a few "Public Homenet Zone" names, I also didn't understand
a sentence where it said "Homenet Zone" because it is so similar and
I didn't realize for a bit that "Public" was missing. I'd recommend
renaming "Homenet Zone" to "Private Homenet Zone" to make this more
obvious (to both implementers and endusers)


        This is a zone transfer over TLS

It would be clearer to call this to be over mutual TLS to distinguish it
from DoH or Dot where the client does not authenticate itself at all.
(other places did properly add a note about mutual auth)


        Revealing the address of the HNA in the DNS is not desirable.

Is there an issue if this is revealed? How hard is it to find the HNA
if you know any other IP from the Public Homenet Zone ? Should there
be a Ssecurity Consideration for embedded DHCP/RA servers on how to
assign IPv6 addresses to hide the HNA better from the user content?


        (if the NS are in-bailiwick [RFC8499]).

The term "in-bailiwick" is being sunset for "in-domain", see https://www.mail-archive.com/dnsop@ietf.org/msg26229.html
(this term appears more than once in the document)


        (a high range port)

It is an ephemeral port. Those happen to be high in the valid range, but I would
not call it "high port" as that is poorly defined (32768+ ? 55000+ ? etc)


        (another high range port)

Same here. I would also change XXXX and YYYY to XXXXX and YYYYY as these would very likely
be higher than 32768 and so would be 5 digits, not 4.


        and so DNS notifies are sent over the Control Channel, secured by TLS.

mutually authenticated TLS.


        As this AXFR runs over a TCP channel secured by TLS

mutually authenticated TLS.


        [RFC9103] makes no requirements or recommendations on any extended
        key usage flags for zone transfers, and this document adopts the view
        that none should be required, but that if there are any set, they
        should be tolerated and ignored.  A revision to this specification
        could change this, and if there is a revision to [RFC9103] to clarify

This is a weird way of saying, "EKU usage SHOULD follow the requirements of [RFC9103]"
and leave it up to 9103 to get updated for this document's normative reference to
be considered updated as well. (this appears twice in the document)


        The use of a TLS session tickets [RFC8446], Section 4.6.1 is RECOMMENDED.

According to 2119, RECOMMENDED means SHOULD. I think that a SHOULD for using TLS
session tickets is a bit strong. I could see that a setup like this might not need
to communicate more than once every few days, in which case it is likely that the
TLS session ticket has expired anyway. I think MAY would be more appropriate here.


        The DM SHOULD ignore the Pre-requisite and Additional Data sections, if present.

Why is this not a MUST ?


        This document exposes a mechanism that prevents the HNA from being
        exposed to queries from the Internet.

It does not "expose a mechanism" for that. It did offer some policy decisions on
how to limit queries and drop certain ones. Which is re-iterated in the sentences
immediately following this. I would remove this sentence.


        The DNSSEC keys are needed on an hourly to weekly basis, but not more often.

This isn't entirely true, when devices' their IP addresses are being added, removed
of modified. Perhaps add some weasel wording like "are generally needed on an ...."


I find the term "home network operator" a bit misleading. We are really talking about
endusers here, not qualified or licensed "operators". Some of the Security Considerations
given to these "home network operators" seems rather technical. Instead, I feel the protocol
really needs to protect the enduser from making mistakes. Perhaps the Security Considerations
for them need to be tweaked to apply to the protocol and its implementers.


        Carriers may need to deploy additional mitigations to ensure that attacks
        do not originate from their networks.  The use of RFC8520 (MUD) filters
        is one such method.

I didn't think MUD was deployed by Carriers for in-home devices? Do you mean to say
that Carriers could recommend CPE equipment and in-home devices that support the
use of RFC8520 (MUD) filters ? Or do you envision MUD capable devices in the HomeNet
actually get their MUD profiles enforced by the Carrier/ISP ?


NITS:

        The DOI benefits from a cloud infrastructure
        while the HNA is dimensioned for home network and as such likely
        enable to support any load.

Should that be "unable to support any load" ?

        This specification defines a mechanism that re-use the [...]

that re-uses


        An error indicates the MD

MD -> DM

[Ballot discuss]
According to the shepherd writeup (and assuming it still reflects reality today; it's dated July of this year, nine revisions ago), there are no implementations, and none are planned.  There's no Implementation Status section either.  However, in the reply to Paul's earlier DISCUSS, there as a claim that some part of this was implemented.  I've also been told there is one vendor planning to implement this, but that doesn't match the record.  Can someone clarify where we are today?  The existence of implementations would certainly allay the previous concerns about complexity and clarity that were expressed in other prior ballot positions.

This document has been in development for over 10 years.  Assuming there is no wide deployment or an implementation to which one can refer, why are we publishing this on the standards track?  Wouldn't Experimental or Informational be more appropriate?  The shepherd writeup doesn't explain why Proposed Standard is justified; it just says "PS".

(Please note that RFC 2026 says implementations aren't required, so I am not requiring one either by posting this ballot.  I just want to have the discussion.)

[Ballot comment]
Thanks for all the work that went into this, especially since its last pass through the IESG.

I generally found this to be readable if I look at it as an applicability statement (RFC 2026, Section 3.2) over DNS for the Homenet use case.  Was that the intent, or am I way off?

Thanks to Darrel Miller for his ARTART review.  (A second review on the latest revision is pending as I write this.)

The last bullet of Section 4.1.1 appears to be mangled in a few places.  Please review.

I have my usual complaint about the use of SHOULD throughout the document: SHOULD provides implementers with a choice, and generally the SHOULDs here don't acknowledge that choice or provide implementers with any guidance about when it might be appropriate to exercise that choice.  I suggest reviewing them (there are 25, and 6 RECOMMENDEDs) and either adding such prose, or reconsidering whether they should be MUST or MAY.

[Ballot comment]
# Internet AD comments for draft-ietf-homenet-front-end-naming-delegation-25
CC @ekline

Re-pasting my previous comments, as the previous ballots were cleared.

## Comments

### S6.3

* Consider adding a forward reference to S6.6 at the of the last paragraph,
  just to say that the DM authenticates the HNA using a mechanism that has
  nothing to do with its (continuously changing) IP address(es).

### S6.5

* This says the authentication of the control channel SHOULD be based on
  certificates, but S6.6 seems to be saying that certificates are a MUST.

  Perhaps I'm just misunderstanding something.  The language in S6.6 seems
  much more preferable.

### S10

* A weakness of this IPv6 ACL scheme would seem to be that it can be very
  hard for the ISP to know precisely *which* device within the access link
  address space (or delegated prefix address space) should be trusted to
  act as the HNA.

  Can any device in the home, or with access to the GUAs on the access link
  (assuming it's numbered), start being an HNA?  The dhc-options draft seems
  to suggest that the HNA needs to have the requisite credentials for mutual
  TLS.  If that's actually REQUIRED then that seems strong enough, and also
  worth mentioning here.

## Nits

### S6.1

* "The HNA then perhaps and DNS Update operation to the DOI" ->
  "The HNA then performs a DNS Update operation to the DOI"

### S9

* "differs the regular" -> "differs from the regular"

[Ballot comment]
This is a major rewrite since the -18 revision of the 1st ballot, hence this new 2nd ballot.

The changes should address all the previous COMMENT/DISCUSS points on -18.. -21 including security, clarifications, operations, ...

The flow and the text (grammar, English) had also a rewrite.

[Ballot comment]
# Internet AD comments for draft-ietf-homenet-front-end-naming-delegation-25
CC @ekline

## Comments

### S6.3

* Consider adding a forward reference to S6.6 at the of the last paragraph,
  just to say that the DM authenticates the HNA using a mechanism that has
  nothing to do with its (continuously changing) IP address(es).

### S6.5

* This says the authentication of the control channel SHOULD be based on
  certificates, but S6.6 seems to be saying that certificates are a MUST.

  Perhaps I'm just misunderstanding something.  The language in S6.6 seems
  much more preferable.

### S10

* A weakness of this IPv6 ACL scheme would seem to be that it can be very
  hard for the ISP to know precisely *which* device within the access link
  address space (or delegated prefix address space) should be trusted to
  act as the HNA.

  Can any device in the home, or with access to the GUAs on the access link
  (assuming it's numbered), start being an HNA?  The dhc-options draft seems
  to suggest that the HNA needs to have the requisite credentials for mutual
  TLS.  If that's actually REQUIRED then that seems strong enough, and also
  worth mentioning here.

## Nits

### S6.1

* "The HNA then perhaps and DNS Update operation to the DOI" ->
  "The HNA then performs a DNS Update operation to the DOI"

### S9

* "differs the regular" -> "differs from the regular"

[Ballot comment]
My previous DISCUSS position for the record: https://mailarchive.ietf.org/arch/msg/homenet/GyVNZWfNBoYXNn3erPG2HNEVtXA/

After (in-person) discussions with one of the authors (Michael Richardson), and all of the changes made to the document, I am changing my original (blocking) DISCUSS position to (non-blocking) Abstain. The authors have made substantial changes to improve the document (https://www.ietf.org/rfcdiff?url1=draft-ietf-homenet-front-end-naming-delegation-18&url2=draft-ietf-homenet-front-end-naming-delegation-22&difftype=--html). I still find it very hard to follow and lacking in detail in many places (hence the Abstain), but feel that it is sufficiently improved that I'm removing my DISCUSS.

Much much thanks to the authors for significant amounts of hard work (and also remaining polite during what I'm sure must have been very frustrating and discouraging).

[Ballot discuss]
(updated ballot for the -21 text)

** Section 1.3

[per -18] 
  When the resolution is performed from within the home network, the
  Homenet DNSSEC Resolver MAY proceed similarly. 

[per -18] I’m not sure if this my misreading of the behavior of internal clients.  To clarify, the (internal) Homenet DNSSEC Resolver will “... resolves the DS record on the Global DNS and the name associated to the Public Homenet Zone (myhome.example) on the Public Authoritative Servers.”?  Why would the internal resolver serving a request for an internal client for an internal service go to the Global DNS if the information if it could come from the internal Homenet Zone it is already configured with?  As an operational consideration, why go outside of the network if you don’t need to?  As a privacy consideration, why leak the request to an outside entity if the network already has the information.

[per -20] Thanks for the revised text:
  On the other hand, to provide resilience to the Public Homenet Zone
  in case of WAN connectivity disruption, the Homenet DNSSEC Resolver
  SHOULD be able to perform the resolution on the Homenet Authoritative
  Servers.

-- Is there a reason this can’t be a MUST?

[Ballot discuss]
(updated ballot for the -20 text)

(1) (per -18 and -20) The security properties of the communication channels would benefit from refinement. 

Thanks for the effort to harmonize the text around TLS usage noted in my ballot on -18 per https://mailarchive.ietf.org/arch/msg/homenet/Qc2sOcBD4P7j3LXYKP61pra7w_E/.

The much clear text in Section 5.2:

  The entity within the
  DOI responsible to handle these communications is the DM and
  communications between the HNA and the DM MUST be protected and
  mutually authenticated.
  ...
  The information exchanged between the HNA and the DM uses DNS
  messages protected by DNS over TLS (DoT) [RFC7858].

Still appears to conflict with the text:

-- Section 5.2
  While Section 6.6 discusses in more depth
  the different security protocols that could be used to secure, it is
  RECOMMENDED to use TLS with mutual authentication based on
  certificates to secure the channel between the HNA and the DM.

-- Section 14.1
  At the time of writing TLS 1.2 or TLS 1.3 can be used and TLS 1.3 (or
  newer) SHOULD be supported.  It is RECOMMENDED that all DNS exchanges
  between the HNA and the DM be protected by TLS to provide integrity
  protection as well as confidentiality.

Per the TLS guidance in Section 14.1, should this document define it’s own guidance, follow what comes with DoT/RFC7858 (which points to RFC7525), or point to draft-ietf-uta-rfc7525bis?  What is written here is slightly different than RFC7858 so I recommend draft-ietf-uta-rfc7525bis or something stronger.


(2) Section 6.5

  The provisioning process SHOULD provide a method of securing the
  Control Channel, so that the content of messages can be
  authenticated.

Per the changes made in (1), and the strict requirement to mutually authenticate with TLS, why isn’t this a MUST?


** Section 1.3

[per -18] 
  When the resolution is performed from within the home network, the
  Homenet DNSSEC Resolver MAY proceed similarly. 

[per -18] I’m not sure if this my misreading of the behavior of internal clients.  To clarify, the (internal) Homenet DNSSEC Resolver will “... resolves the DS record on the Global DNS and the name associated to the Public Homenet Zone (myhome.example) on the Public Authoritative Servers.”?  Why would the internal resolver serving a request for an internal client for an internal service go to the Global DNS if the information if it could come from the internal Homenet Zone it is already configured with?  As an operational consideration, why go outside of the network if you don’t need to?  As a privacy consideration, why leak the request to an outside entity if the network already has the information.

[per -20] Thanks for the revised text:
  On the other hand, to provide resilience to the Public Homenet Zone
  in case of WAN connectivity disruption, the Homenet DNSSEC Resolver
  SHOULD be able to perform the resolution on the Homenet Authoritative
  Servers.

-- Please also point out that the use of the Homenet resolver would enhance privacy since the user on the home network would no longer be leaking interactions with internal services to an external DNS provider and to an on-path observer.

-- Is there a reason this can’t be a MUST?

-- Editorial (comment level, but adding here for convenience) Consider if you want to use the “DNSSEC Resolver” or “DNS(SEC) Resolver” (as was introduced later) since DNSSEC is not mandatory.

[Ballot comment]
I agree with the Discusses and Comments on this document - this simply isn't implementable as described.

My main reason for abstaining is something else though. This document has been worked on for almost ten years. While in the beginning, we might have expected or at least hoped that a solution in the shape that this document tries to describe would see adoption, it's become very clear that dynamic DNS services as described in Section 4 have won out here. These services are far from perfect, but at least some of the limitations in Section 4 have been addressed, and others are arguably a feature and not a limitation.

[Ballot comment]
Like other ADs, I found this document hard to read.

Rather than defining a JSON schema file in Appendix B, it would be much better if this was defined in YANG, which is the IETF standard data modelling language for network configuration.  A JSON encoding for YANG defined data also exists so it would still work for what is proposed here.


I also ran a grammar tool over the XML for -19, and it flagged up these warnings that you might want to consider checking/fixing in the next revision (they are not necessarily all valid):

Spellings:
Sometimes you use HomeNet, in other places, Homenet, and also homenet.
Pre-requisite,
SIgning,


Grammar Warnings:
Section: abstract, draft text:
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).
Warning:  This phrase is redundant. Consider using outside.
Suggested change:  "outside"

Section: 1, draft text:
The appendices discuss several management (see [sec-reverse]) provisioning (see [sec-reverse]), configurations (see [info-model]) and deployment (see [sec-deployment] and [sec-ex-manu]) aspects.
Warning:  Possible agreement error. The noun management seems to be uncountable; consider using: some management.
Suggested change:  "some management"

Section: 3, draft text:
The IPv6 ULA and the private IPv4 addresses may be useful to publish, if the home network environment features a VPN that would allow the home owner to reach the network.
Warning:  This noun normally spelled as one word.
Suggested change:  "homeowner"

Section: 3, draft text:
Since communications are established with names which remain a global identifier, the communication can be protected by TLS the same way it is protected on the global Internet - using certificates. 
Warning:  Possible typo: you repeated a whitespace
Suggested change:  " "

Section: 4, draft text:
While the IETF has defined a DNS based mechanism Dynamic Update [RFC2136], in many – as far as the co-authors know in all cases – case commercial “Dynamic Update” solutions are primarily implemented via a HTTPS RESTful API.
Warning:  Use an instead of 'a' if the following word starts with a vowel sound, e.g. 'an article', 'an hour'
Suggested change:  "an"

Section: 4, draft text:
Any host can do this regardless of whether or not the home network administrator wants the name published or not.
Warning:  Consider shortening this phrase to just whether. It is correct though if you mean 'regardless of whether'.
Suggested change:  "whether"

Section: 4, draft text:
The DNS zone are then synchronized using an alternative mechanism as the one designed for zone synchronisation inherited from the primary used case where the synchronization is performed at the node level.
Warning:  Do not mix variants of the same word ('synchronisation' and 'synchronization') within a single text.
Suggested change:  "synchronization"

Section: 4, draft text:
Our proposal use the standard mechanism defined by DNS for zone synchronisation.
Warning:  Possible agreement error - use third-person verb forms for singular and mass nouns: uses.
Suggested change:  "uses"

Section: 4, draft text:
Our proposal use the standard mechanism defined by DNS for zone synchronisation.
Warning:  Do not mix variants of the same word ('synchronisation' and 'synchronization') within a single text.
Suggested change:  "synchronization"

Section: 5.1, draft text:
Such a domain name does not need to be human readable.
Warning:  This word is normally spelled with hyphen.
Suggested change:  "human-readable"

Section: 5.1, draft text:
Instead these keys are solely used by the HNA for the authentication to the DM.
Warning:  Did you forget a comma after a conjunctive/linking adverb?
Suggested change:  "Instead,"

Section: 5.1.1, draft text:
One potential mechanism to provide the parameters would be to provide the user with a JSON object which they can copy paste into the CPE - such as described in [info-model].
Warning:  Did you mean copy and paste?
Suggested change:  "copy and paste"

Section: 6.1, draft text:
The “.local” as well as “.home.arpa” are explicitly not considered as Public Homenet zones and represented as Homenet Zone in [fig-naming-arch].
Warning:  The singular proper name 'Homenet' must be used with a third-person or a past tense verb: zones, zoned.
Suggested change:  "Zones"

Section: 3.1, draft text:
In some cases, the HNA and Homenet Authoritative Servers may be combined together which would result in a common instantiation of an authoritative server on the WAN and inner homenet interface.
Warning:  'combined together' is redundant. Use combined
Suggested change:  "combined"

Section: 6.2, draft text:
The Control Channel and the Synchronization Channel are the interfaces used between the HNA and the DOI.
Warning:  The singular proper name 'Channel' must be used with a third-person or a past tense verb: is, was, were.
Suggested change:  "is"

Section: 4.1, draft text:
In term of RRset information this includes:
Warning:  Did you mean the commonly used phrase In terms of?
Suggested change:  "In terms of"

Section: 4.2, draft text:
Though the HNA may also later directly update the values of the DS via the Control Channel, it is RECOMMENDED to use other mechanisms such as CDS and CDNSKEY [RFC7344] for transparent updates during key roll overs.
Warning:  This expression is normally spelled as one or with hyphen.
Suggested change:  "roll-overs"

Section: 4.5.2, draft text:
A SERVFAIL error is returned when a internal error is encountered.
Warning:  Use an instead of 'a' if the following word starts with a vowel sound, e.g. 'an article', 'an hour'
Suggested change:  "an"

Section: 4.5.4, draft text:
As indicated by [RFC2136] Section 2.5.2 the delete instruction is set by setting the TTL to 0, the Class to ANY, the RDLENGTH to 0 and the RDATA MUST be empty.
Warning:  After 'the', do not use a verb. Make sure that the spelling of 'delete' is correct. If 'delete' is the first word in a compound adjective, use a hyphen between the two words. Note: This error message can occur if you use a verb as a noun, and the word is not a noun in standard English.

Section: 7.6, draft text:
TLS [RFC8446]) MUST be used to secure the transactions between the DM and the HNA and the DM and HNA MUST be mutually authenticated.
Warning:  Unpaired symbol: '(' seems to be missing

Section: 4.7, draft text:
This results in a limited number of possible exchanges (AXFR/IXFR) with a small number of IP addresses and an implementation SHOULD enable filtering policies as described in [sec-cpe-sec-policies].
Warning:  Specify a number, remove phrase, use a few, or use some
Suggested change:  "a few"

Section: 8, draft text:
Note that the Control Channel and the Synchronization Channel are by construction different channels even though there they may use the same IP address.
Warning:  The singular proper name 'Channel' must be used with a third-person or a past tense verb: is, was, were.
Suggested change:  "is"

Section: 8, draft text:
On the other hand, the Synchronization Channel is set between the DM working as a client using port ZZZZ ( another high range port) toward a service provided by the HNA at port XX.
Warning:  Don't put a space after the opening parenthesis.
Suggested change:  "("

Section: 8.1, draft text:
The AXFR request from the DM to the HNA MUST be secured with TLS [RFC8446]) following DNS Zone Transfer over TLS [RFC9103].
Warning:  Unpaired symbol: '(' seems to be missing

Section: 7, draft text:
The HNA SHOULD drop any packets arriving on the WAN interface that are not issued from the DM – as opposed to server as an Homenet Authoritative Server exposed on the Internet.
Warning:  The usual proposition after "arriving" is "at" not "on". Did you mean arriving at?
Suggested change:  "arriving at"

Section: 7, draft text:
The HNA SHOULD drop any packets arriving on the WAN interface that are not issued from the DM – as opposed to server as an Homenet Authoritative Server exposed on the Internet.
Warning:  Use a instead of 'an' if the following word doesn't start with a vowel sound, e.g. 'a sentence', 'a university'
Suggested change:  "a"

Section: 10, draft text:
Only TLS packet or potentially some DNS packets ( see XoT) packets SHOULD be allowed.
Warning:  Don't put a space after the opening parenthesis.
Suggested change:  "("

Section: 7, draft text:
The HNA SHOULD reject any incoming messages other than DNS NOTIFY response, SOA  query, IXFR query or AXFR query.
Warning:  Possible typo: you repeated a whitespace
Suggested change:  " "

Section: 8, draft text:
More specifically, a common case is that the upstream ISP provides the IPv6 prefix to the Homenet with a IA_PD [RFC8415] option and manages the DOI of the associated reverse zone.
Warning:  Use an instead of 'a' if the following word starts with a vowel sound, e.g. 'an article', 'an hour'
Suggested change:  "an"

Section: 11, draft text:
Such constraints does not raise major concerns either for hot standby or load sharing configuration.
Warning:  You should probably use do.
Suggested change:  "do"

Section: 11, draft text:
Outsourcing the DNS Authoritative service from the HNA to a third party raises a few privacy related concerns.
Warning:  Possible agreement error. The noun privacy seems to be uncountable; consider using: little privacy.
Suggested change:  "little privacy"

Section: 11, draft text:
A well designed User Interface would combine a policy for making a service public by a name with a policy on who may access it.
Warning:  This word is normally spelled with hyphen.
Suggested change:  "well-designed"

Section: 12.1, draft text:
This MAY involved a mix of exchanges protected by TLS and exchanges not protected by TLS.
Warning:  The modal verb 'MAY' requires the verb's base form.
Suggested change:  "involve"

Section: 12.1, draft text:
This MAY be handled by a off-line agreement between the DM and HNA as well as with the use of RCODES defined in Section 7.8 of [RFC9103].
Warning:  Use an instead of 'a' if the following word starts with a vowel sound, e.g. 'an article', 'an hour'
Suggested change:  "an"

Section: 12.3, draft text:
In addition IPv6 enables temporary addresses that makes them even more volatile [RFC8981].
Warning:  Did you forget a comma after a conjunctive/linking adverb?
Suggested change:  "addition,"

Section: 12.4, draft text:
To provide resilience against CPE breaks, it is RECOMMENDED to backup these keys to avoid an emergency key roll over when the CPE breaks.
Warning:  Did you mean to back up?
Suggested change:  "to back up"

Section: 17, draft text:
The authors wish to thank Philippe Lemordant for his contributions on the early versions of the draft; Ole Troan for pointing out issues with the IPv6 routed home concept and placing the scope of this document in a wider picture; Mark Townsley for encouragement and injecting a healthy debate on the merits of the idea; Ulrik de Bie for providing alternative solutions; Paul Mockapetris, Christian Jacquenet, Francis Dupont and Ludovic Eschard for their remarks on HNA and low power devices; Olafur Gudmundsson for clarifying DNSSEC capabilities of small devices; Simon Kelley for its feedback as dnsmasq implementer; Andrew Sullivan, Mark Andrew, Ted Lemon, Mikael Abrahamson, and Ray Bellis for their feedback on handling different views as well as clarifying the impact of outsourcing the zone signing operation outside the HNA; Mark Andrew and Peter Koch for clarifying the renumbering.
Warning:  The usual preposition for "contribution" is "to". Did you mean contributions to?
Suggested change:  "contributions to"

Section: A.1, draft text:
This section details what needs to be provisioned into the HNA and serves as a requirements statement for mechanisms.
Warning:  Apostrophe might be missing.
Suggested change:  "requirements'"

Section: A.1, draft text:
— the Registered Domain (e.g., myhome.example ) — the contact info for the Distribution Manager (DM), including the DNS name (FQDN), possibly including the IP literal, and a certificate (or anchor) to be used to authenticate the service — the DM transport protocol and port (the default is DNS over TLS, on port 853) — the HNA credentials used by the DM for its authentication.
Warning:  Don't put a space before the closing parenthesis.
Suggested change:  ")"

Section: A.1, draft text:
The above parameters MUST be be provisioned for ISP-specific reverse zones.
Warning:  Did you mean been?
Suggested change:  "been"

Section: A.1, draft text:
Once the registrar has been selected, the HNA redirects the end user to that registrar in order to receive a access token.
Warning:  Use an instead of 'a' if the following word starts with a vowel sound, e.g. 'an article', 'an hour'
Suggested change:  "an"

Section: Appendix B, draft text:
Note that HNA does not defines ports for the Synchronization Channel.
Warning:  Did you mean define? As 'do' is already inflected, the verb cannot also be inflected.
Suggested change:  "define"

Section: Appendix B, draft text:
Currently the Configuration Channel does not provide this, and limits its agility to a dedicated IP address.
Warning:  Did you forget a comma after a conjunctive/linking adverb?
Suggested change:  "Currently,"

Section: Appendix B, draft text:
The device would need to be provisioned with a device-unique credential, and it is likely that the Registered Homenet Domain would be derived from a public attribute of the device, such as a serial number (see [sec-ex-manu] or [I-D.richardson-homerouter-provisioning] for more details ).
Warning:  Don't put a space before the closing parenthesis.
Suggested change:  ")"

Section: Appendix C, draft text:
In addition to having a assymmetric credential known to the manufacturer, the device also has been provisioned with an agreed upon name.
Warning:  Use an instead of 'a' if the following word starts with a vowel sound, e.g. 'an article', 'an hour'
Suggested change:  "an"

[Ballot comment]
I have not completed my review.  I expect to ballot to at least support some or all of the existing DISCUSS positions, and will have comments of my own.  The DISCUSSes are broad enough that I'm going to stop my review for now.

The one thing I noticed right away is that Section 2 defines "Reverse Public Authoritative Servers" and "Reverse Distribution Manager", but those terms appear nowhere else in the document.

[Ballot comment]
# Internet AD comments for {draft-ietf-homenet-front-end-naming-delegation-18}
CC @ekline

I support the other DISCUSSes in flight.

## Comments

### S1

* "as a primary, as a secondary" ... meaning DNS nameservers?  This is more
  clear later on, including where 8499 is mentioned, but I think a simple
  clarification here helps too.

### S3.1

* It might be good to state that .local and .home.arpa names MUST NOT be
  sent over the synchronization channel and that the DOI MUST not accept
  any such names.

[Ballot discuss]
I have to agree with Warren here. I do not understand how this protocol is supposed to work. It renames a bunch of DNS terms (hidden primary, primary, seconday, AXFR/IXFR, DNS update --> HNA, DM, DOI, Control Channel, Sync channel) which makes the document very hard to read.

For those parts where protocol glue is needed to use these DNS technologies, the document presents no solutions.
I don't understand if users can create their own named zones, or whether this is only provider generated zones. The latter seems less useful to the user, the former seems to need more specification on how to handle registry/registrar/registrant matters (especially with respect to DS)

The security seems to mix up transport security with TLS and data integrity security of the DNS protocol (typically TSIG or SIG0, but the document claims this cannot be used)

Having provider generated homenet named DNS zones makes scanning for hostnames in those zones much easier than scanning an entire /64 IPv6 for vulnerable devices. Eg well known host names like "tv" or "LG" or "washing_machine" or just any <= 8 character string based hostnames or dictionary attacks.


Like Warren, I've added my notes as comments without splitting them further into DISCUSSes or COMMENTs

[Ballot comment]
  *  the CPE/HNA router is unaware of the process, and cannot respond
      to queries for these names and communications to these names
      require an Internet connectivity is order to perform the DNS
      resolution.  Such dependence does not meet the requirement for
      internal communications to be resilient to ISP connectivity
      disruptions [RFC7368].

If there is a host within the home network that is the DHCP/DNS server,
then this does not require further support from a CPE/HNA or internet
uplink. For example Linux openwrt with avahi and dnsmasq is a common
deployment of this: https://openwrt.org/docs/guide-user/base-system/dhcp
Arguably, one could say openwrt is the CPE/HNA in such case, provided
that user has their own domain they can send "dynamic DNS" updates for
on the public internet hosting their homenet zone.

  *  the CPE/HNA router cannot control the process.  Any host can do
      this regardless of whether or not the home network administrator
      wants the name published or not.  There is therefore no possible
      audit trail.

To be fair, even with dpeloying all of homenet, those hosts can still keep
doing this - choices made here does not affect this, so I don't see this
as a valid argument one way or the other.

  The DOI is also responsible for ensuring the DS record has been
  updated in the parent zone.

This sentence carries a LOT of process/protocol work. Will it use CDS? How is the
authorization boot strapped? Does it work for non-ISP generated zones, eg "toronto.nohats.ca" ?
If so, how does it handle delegation of NS and DS ?

  The information exchanged between the HNA and the DM uses DNS
  messages protected by DNS over TLS (DoT) [RFC7858].  In the future,
  other specifications may consider protecting DNS messages with other
  transport layers, among others, DNS over DTLS [RFC8094], or DNS over
  HTTPs (DoH) [RFC8484] or DNS over QUIC [RFC9250].

what does "protected" here mean? Privacy protection? Because if it is using
DNS Dynamic Updates, the data authenticity protection comes from a TSIG/SIG0 key.

  The main issue is that the Dynamic DNS update would also update the
  parent zone's (NS, DS and associated A or AAAA records) while the
  goal is to update the DM configuration files.  The visible NS records
  SHOULD remain pointing at the cloud provider's server IP address -

But isn't this simply a "forward" statement for the zone to the private IP
of the local DNS authoritative server within the local DNS recursive server?
That way, the recursive dns IP does not need to have a NS record at all, so
there is also no risk of accidentally pushing it out to public servers and
replacing the real NS records?

  *  By default, the HNA uses a single IP address for both the Control
      and Synchronization channel.  However, the HNA MAY use distinct IP
      addresses for the Control Channel and the Synchronization Channel
      - see Section 5 and Section 4.3 for more details.

Why does this matter and need mentioning? TSIG/SIG0 would not care about the
IP address used, and/or whether it is NATed?

  As such the HNA has a prior knowledge of the DM identity (X509
  certificate), the IP address and port number to use and protocol to
  set secure session.

Ah, so this is a preconfigured IP/name/TSIG/SIG0 key, and limits the HNA to only CPE
supported DNS providers? Either this locks in where users can host their homenet zone
based on CPE preconfiguration, or it is just a fancy way of saying "configure your DNS
server with your remote DNS settings" (which would not need anything of this document to run,
and I was hoping this document was going to provide some automation for this?)

  The HNA SHOULD provide the hash of the KSK (DS RRset), so the DOI
  provides this value to the parent zone.  A common deployment use case
  is that the DOI is the registrar of the Registered Homenet Domain and
  as such, its relationship with the registry of the parent zone
  enables it to update the parent zone.

This now means that the solution is limited to those scenarios that have:
- CPE support for homenet RFCs
- ISP support for CPE for HNA for DOI that supports DNSSEC DS submission via EPP, or
- A Registrar that is also DNS hoster AND supports DNSSEC AND supports CDS/CDNSKEY AND supports AXFR/IXFR
  AND supports homenet RFCs


I would argue these requirements are far more restrictive than:
- CPE with support for stock Dynamic DNS updates for itself only (eg client registrations,
  but could also be autoatic conversion of MDNS/.local to its local homenet zone.
- CPE that can run recursive with an authoritative zone
- Any DNS hoster that supports AXFR/IXFR, DNSSEC and CDS/CDNSKEY
- Any Register that supports DNSSEC

with the only difference that the latter one needs a one step registration of the initial DS record.


  Though the HNA may also later directly update the values of the DS
  via the Control Channel, it is RECOMMENDED to use other mechanisms
  such as CDS and CDNSKEY [RFC7344] for transparent updates during key
  roll overs.

If this is going to be a fully automated enduser CPE solution, this RECOMMENDED
is too weak. It should be a MUST because otherwise DNSSEC rollover is just impossible.


Section 4

this all seems to imply "registered domains". Can these be subdomains? Eg can I own nohats.ca
and configure one CPE for toronto.nohats.ca. and the other for amsterdam.nohats.ca. ? This involves
talking to NS for nohats.ca for sub delegation, but I don't see that mentioned anywhere ?

Section 4.5.1

How would the bootstrap work. I pick "paulhomenet.com" as my zone, but then my CPE doens't have
nameservers for it, so it does AXFR via the Control Channel ? And get a set of NS records back
that my CPE adds to paulhomenet.com ? And then it becomes authoritative? How is the ownership
of paulhomenet.com tested? if it is registered, who will be the registrar, registrant? Is ".io"
supported? Or other TLDs? Or will this all be under "nameyoupick.homenet.cpevender.com" ?

AXFR is normally based on authentication of domain name plus shared key. How does that work when
creating a _new_ domain name by the enduser? How can this be authenticated without knowing the
zone name ?

Section 4.5.3

  The default IP address used by the HNA for the Synchronization
  Channel is the IP address of the Control Channel.  To provide a
  different IP address, the HNA MAY send a DNS UPDATE message.

What does this DNS UPDATE message contain? It says NS records but what
name? And as this is the authoritative server sending an DMS UPDATE
message, it would need to send the RRSIG too, which means it needs to
set the entire NS RRset? Which means it needs to know the remote NS
records, but how can it do that without first already using the proper
IP address to talk to the systems?

Section 4.5.4:

If a deletion is processed, what happens with the domain name? Will all
its NS records be deleted and it is now a lame delegation? How is the enduser
supposed to get their domain under their own control again? Is it ever truly
theirs?


4.6 Securing the control channel

Isn't this channel DNS dynamic updates? Are these not secured by TSIG/SIG0 ?
Did you mean TLS only for privacy considerations and not security considerations?

Apparently this is not the case?

  A pure DNS solution using TSIG and/or SIG(0) to authenticate message
  was also considered.



  A way to translate this OAUTH2 token from HTTPS web space to DNS SIG(0)
  space seems overly problematic,

Why not use TSIG? That is literally the keyed hash of a blob, and the blob can
be an OAUTH2 token ?

ection 4.7

  Interface Binding:  the Hidden Primary Server will almost certainly
      listen on the WAN Interface, whereas a regular Homenet
      Authoritative Servers would listen on the internal home network
      interface.

Does that matter if either one provides a routable public IPv6 address?

  Limited exchanges:  the purpose of the Hidden Primary Server is to
      synchronize with the DM, not to serve any zones to end users, or
      the public Internet.

I thought it was serving endusers so that local things would keep working
with a broken internet link? Or at least "serve" its "resolver" part. And
also serve as auth server to take in DNS Dynamic Updates?

Section 5:

  Uploading and dynamically updating the zone file on the DM can be
  seen as zone provisioning between the HNA (Hidden Primary) and the DM
  (Secondary Server).  This can be handled via AXFR + DNS UPDATE.

I don't see how the start of this works, when the end user tells their CPE
the name of their local homenet zone ?

(also I think you mean AXFR/IXFR ? The DNS UPDATE would be the local machine
talking to the local CPE ? Not between HNA and DM?)

  Note that there is no standard way to distribute a DNS primary
  between multiple devices.  As a result, if multiple devices are
  candidate for hosting the Hidden Primary, some specific mechanisms
  should be designed so the home network only selects a single HNA for
  the Hidden Primary.  Selection mechanisms based on HNCP [RFC7788] are
  good candidates.

This seems rather under specified. If there is only one, how is it found and
used? I was expecting that the domainname configured on the CPE would be
queried for DNS UPDATES by clients. But looking at RFC2136 Section 4:

  From a requestor's point of view, any authoritative server for
  the zone can appear to be able to process update requests, even
  though only the primary master server is actually able to modify the
  zone's master file.  Requestors are expected to know the name of the
  zone they intend to update and to know or be able to determine the
  name servers for that zone.

  If the requestor has reasonable cause to believe that all of a
  zone's servers will be equally reachable, then it should arrange to
  try the primary master server (as given by the SOA MNAME field if
  matched by some NS NSDNAME

This would be only one possible target based on the domainname given to
a device via DHCP. What "some specific mechanism should be designed" will
be deployed for the clients (eg my phones, laptop and TV ?) I think the
only real chance they have of doing this (without waiting 10 years for
all our electronics to cycle/get updated) is standard the SOA MNAME's IP
address, eg RFC 2136 DNS Dynamic Updates. My devices already support this.

So that redefines the above problem to "Who becomes the Hidden Primary",
which I assumed was the CPE supporting this framework ? And if there
are more than one CPE that can do this, it should be configured by
the user to be done only by one CPE - similar to have a user should
ensure there is only one DHCP server running in the network ?

Section 5:

        First the HNA (primary) notifies the DM (secondary)

The entire document would have been so much more readable if HNA and DM
had not been introduced and primary/secondary was used througout.

  The HNA SHOULD apply an ACL on inbound AXFR requests to ensure they
  only arrive from the DM Synchronization Channel.

Unless the CPE is preconfiguted with service providers, these ACLs cannot
come by default? Also, if this channel uses TSIG (which also needs preconfiguration)
then it can already ACL this based on the known shared secret. No IP based
ACLs needed (which are risky to put into CPE firmware as networks change)

Section 7:

Why can't the HNA be the local authoritative server for clients? Why should
this functionality be split in two? It just means another recursive resolver
needs to query the HNA (and have it configured as forwarder) for the local
homenet zone (in case uplink goes down). For example, this could be a single
instance of the Bind DNS server dong both authoritative and recursive DNS.

Dropping received queries for DNS servers is always a bad idea, as it just
causes the client to retransmit. Always returning an error is the common
DNS reply strategy. This section goes against common best practise for DNS
servers.

Section 9:

  [RFC7368] in Section 3.7.3 recommends DNSSEC to be deployed on both
  the authoritative server and the resolver.  The resolver side is out
  of scope of this document, and only the authoritative part of the
  server is considered.

But if things must work without an internet connection working, then the
resolver needs to be configured for the homenet domain to ask the HNA
and not go the regular upstream path. So it should be in scope I believe.

  Typically, the DS RRset can be updated
  manually in the parent zone with nsupdate for example.

I don't think this applies to "typical DS". The DS RRset lives on the "wrong"
side of the zone cut. A dns update client is would not have permissions to
update its parent zone with dns updates, only its own child zone. So this
would be better done by pushing a CDS record and let the parent pull the CDS
and recreate its own DS record. This method is not widely supported by TLDs,
and I dont know how this solution would work for second or third level domains,
eg if I use provider X to host nohats.ca, and provider Y for my home internet
and I want toronto.nohats.ca to be my home network name using CPE vendor Z.

Section 10:

  The ISP SHOULD ensure that the DNS cache has expired before re-
  assigning the prefix to a new home network.

How does it do that? It can't send queries to get the data for TTL anymore,
since the network already got renumbered and returned and the NS servers
removed. The records now only live in worldwide caches. You don't know the TTL.
Unless you grabbed the data just before getting it returned. But that is also
unlikely, eg imagine a user taking down their CPE because they moved house.
From the ISP point of view the network just vanished including all its nameservers
for it (the public ones will work for a while but will the ISP act within that time?)

And what of the CPE/HNA set TTLs on data of 1 year ?

The TTL math in section 10 makes no sense to me as the CPE/HNA could set it to whatever
it wants. The ISPs secondary servers cannot change the TTL (it is protected by DNSSEC
from being modified)

Section 11:

The Privacy Considerations section is a bit hard to read. But in the end it comes down
to "dont make your homenet DNS publicly reachable if you want privacy". Indeed, I find
publishing my entire home network into public DNS a serious risk. DNS scanners will end
up scanning for well known names of popular brands of TVs, washing machines, saunas,
lightbulbs, etc. Or they will start scanning zones based on well known ISP based secondary
services. It is almost as if the better solution would be to only provide a publicly reachable
homenet VPN server, that provides both DNS and the only working routes from my (remote) devices
on my to my home network based devices.

The privacy and security of the DNS names is a small thing if homenet puts all my devices on
the public IPv6 network. Scanning IPv6 is still fairly hard to do, even of endusers /64. And
putting those IPv6 addresses in DNS makes it much much easier to find all these devices and
use their exposed services to compromise the device and/or network that they are in. These
considerations are completely missing from the Security Considerations Section 12.

Appendix A:

  This document does not deal with how the HNA is provisioned with a
  trusted relationship to the Distribution Manager for the forward
  zone.

But that is core to the protocol ?

  Similarly, if the HNA is provided by a registrar, the HNA may be
  handed pre-configured to end user.

How can that be if the user decides on the homenet network name it wants to use?

Appendix C:

The example zone used is n8d234f.r.example.net. I thought the idea was for the user
to have a memorable zone it can use, eg sharing with friends. Was I wrong?

with the "dm_acl"    : "2001:db8:1234:111:222::/64", set, what happens to the zone
"n8d234f.r.example.net." when the user got unplugged and replugged and lives on a
different ip range now ?

[Ballot discuss]
(1) The security properties of the communication channels would benefit from refinement.  In trying to piece them together, there appear to be inconsistencies:

** Section 3.2.
  The information exchanged between the HNA and the DM uses DNS
  messages protected by DNS over TLS (DoT) [RFC7858].  In the future,
  other specifications may consider protecting DNS messages with other
  transport layers, among others, DNS over DTLS [RFC8094], or DNS over
  HTTPs (DoH) [RFC8484] or DNS over QUIC [RFC9250].

-- Is this guidance scoped to all of the information exchanged between the HNA and the DM?

-- (Editorial, treat as COMMENT). If so, please explicitly state the use of DoT with normative language -- "DNS over TLS (DoT) MUST be used for ..."

-- If so, this suggests to me that all traffic is over TLS.  This text doesn’t align with the Section 4.6’s weaker guidance that “[s]ecure protocols (like TLS [RFC8446]) SHOULD be used to secure the transactions between the DM and the HNA” as the text in this section does not make for allowance for anything beyond DoT.

** Section 4.6.  Thanks for discussing the flexible deployment options in section.  My concern is that the mandatory to implement security properties are not sufficiently specified for an interoperable solution.  The statement “The control channel between the HNA and the DM MUST be secured at both the HNA and the DM” is helpful.  How does one conform to it?  What exact security properties are required (MUST)?

Various text hints at these properties:
(a) Section 3.2 said that HNA and DM communication uses DoT (no normative language)

(b) Section 3.2, “it is RECOMMENDED to use TLS with mutually authentication based on certificates to secure the channel between the HNA and the DM.”

(c) Section 4.5, “ The provisioning process SHOULD provide a method of securing the Control Channel, so that the content of messages can be    authenticated.”

(d) Section 4.6, “Secure protocols (like TLS) SHOULD ...” be used

(e) Section 4.6., “HNA SHOULD authenticate inbound connections from the DM …”

(f)  Section 4.6., “DM SHOULD authenticate the HNA …

Even assuming DoT is a MUST (which is not stated), all of these statements are SHOULD or RECOMMENDED suggesting that the HNA might not need to authenticate to the DM.

** Section 12.1.   

The channels between HNA and DM are mutually authenticated and
  encrypted with TLS [RFC8446] and its associated security
  considerations apply. 

I would recommend this design.  Where is this stated in a normative fashion?  The text in Section 4.6 and 5.1 states that mutual authentication is a SHOULD.

(2) Why would internal clients have to use public DNS for internal services given that there is an authoritative server for the Homenet Zone in the internal network?

** Section 1.3
  When the resolution is performed from within the home network, the
  Homenet DNSSEC Resolver MAY proceed similarly. 

I’m not sure if this my misreading of the behavior of internal clients.  To clarify, the (internal) Homenet DNSSEC Resolver will “... resolves the DS record on the Global DNS and the name associated to the Public Homenet Zone (myhome.example) on the Public Authoritative Servers.”?  Why would the internal resolver serving a request for an internal client for an internal service go to the Global DNS if the information if it could come from the internal Homenet Zone it is already configured with?  As an operational consideration, why go outside of the network if you don’t need to?  As a privacy consideration, why leak the request to an outside entity if the network already has the information.

[Ballot comment]
I support Warren's DISCUSS position and tried to be more specific on the rational in my DISCUSS write-up.  I also support John's DISCUSS position which highlights similar or potentially identical issues.  I have not attempted to deconflict them.

** Section 1.
  Home network owners often have devices and services that they wish to
  access outside their home network - i.e., from the Internet using
  their names.  To do so, these names needs to be made publicly
  available in the DNS.

Note: this paragraph is also in the abstract

This text isn’t clear on the problem setup.
-- Per “… using their names”, names defined where?

-- Is there the unstated assumption that these devices are hosted on the home network?

NEW
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).  To enable this access, the names and IP addresses of these devices and services needs to be made available in the public DNS.

** Section 1.

  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.

-- Editorially, this paragraph doesn’t bridge at all from the previous one describing the “home network” with “devices and services”.  What is the relationship between the HNA, DOI and Public Homenet Zone and that previously described network

** Section 1.  The last two paragraphs describe the role of most of the sections in the document.  However, they omit Section 2.

** Section 1.1
(a)    While this document does not create any normative mechanism to select
  the names to publish, this document anticipates that the home network
  administrator (a human being), will be presented with a list of
  current names and addresses.

(b)  The administrator would mark which devices and services (by name),
  are to be published. 

(c) The HNA would then collect the IPv6 address(es)
  associated with that device or service, and put the name into the
  Public Homenet Zone. 

Per (c), why does the HNA need to collect the IPv6 addresses if the selecting and marking processes of (a) and (b) already appear to have both the names+IP addresses?  Aren’t the “marked” names+IP addresses from (b) getting fed into the HNA?

** Section 1.2
  An alternative existing solution is to have a single zone, where a
  host uses a RESTful HTTP service to register a single name into a
  common public zone.

Why does it have to be a “single name”?  For example, the edge CPE/NAT/reverse proxy device running the DDNS client could resolved to multiple public names using the inbound SNI as a discriminator.

** Section 1.2.  the limitation sub-bullets #1 and 2 (“the CPE/HNA router …”) makes reference to an HNA router without defining what it is.  If there is going to be a comparison to the current practice to what’s proposed in this specification, the architectural elements which are being compared need to be introduced.  Baring that, at least provide a forward reference.

** Section 1.2.
    the CPE/HNA router is unaware of the process, and cannot respond
      to queries for these names and communications to these names
      require an Internet connectivity is order to perform the DNS
      resolution.  Such dependence does not meet the requirement for
      internal communications to be resilient to ISP connectivity
      disruptions [RFC7368].

Can you please provide a more specific section number in RFC7368 enumerating the requirement that the CPE must serve the DNS queries for the services behind it.

** Section 1.2.
  *  the CPE/HNA router cannot control the process.  Any host can do
      this regardless of whether or not the home network administrator
      wants the name published or not.  There is therefore no possible
      audit trail.

-- Can’t the CPE and home network interdict the communication of the clients contacting and registering an DDNS provider

** Section 1.2 
      This is not a
      problem for a technical user to do with one or two hosts, but it
      does not scale to multiple hosts and becomes a problem for non-
      technical users.

Why does sharing of DDNS credentials not scale for technical users beyond one or two hosts.  Is there an assumption that these are being shared by hand?

** Section 1.2
"all the good names are taken"  -current services provide a small
      set of zones shared by all hosts across all home networks.  More
      especially, there is no notion of a domain specific home network.
      As there are some commonalities provided by individual home
      networks, there are often conflicts. 

I’m having trouble following the thesis of this bullet.

-- Per “current services provide …”, is it current “dynamic DNS services …”?

-- what is a “domain specific home network”?

-- what are the “commonalities provided by individual home networks …”?

** Section 1.2. 

The RESTful services do not always support all RR types. 

Is there a sense for what kinds of devices or services for which this is an impediment?  Put in another way, many Dynamic DNS doesn’t support this now, so what are the things running on the home network now that would benefit?

** Section 1.3.  Editorial. Given the sequencing of the text, the deployment scenarios are not illustrative and largely opaque.  They rely on knowledge and terminology of the proposed solution not yet explained in the document.  There are no forward references to orient the reader.

** Section 1.3.1

Instead these
  keys are solely used by the HNA to proceed to the authentication.
  Normally the keys should be necessary and sufficient to proceed to
  the authentication. The reason to combine the domain name and the
  key is that DOI are likely handle names better than keys and that
  domain names might be used as a login which enables the key to be
  regenerated.

-- What does “proceed to authentication” mean?  Is there some kind of MFA happening?
-- The text says “The reason to combine the domain name and key …”, but the text prior didn’t explain that this was happening. 

** Section 1.3.1.  Editorial.

OLD
An CPE that is not preconfigured may also take advantage to the
  protocol

NEW
An CPE that is not preconfigured may also take advantage of the
  protocol

** Section 1.3.1.  Editorial.

OLD
The owner of the home network buys a domain name to a registrar

NEW
The owner of the home network buys a domain name from a registrar

** Section 3.  Typo. s/detaille din/detailed in/

** Section 3.  Editorial.  Make clear this is a statement about the example.

OLD
The Public Homenet Zone is identified by the Registered Homenet
  Domain Name - myhome.example. 

NEW
In this example, the Public Homenet Zone is identified by the Registered Homenet Domain Name - myhome.example. 

** Section 3

the HNA communicates and
  synchronizes it with the DOI using a primary/secondary setting as
  described in Figure 1.

I understand the intent of the text and who is operating as the primary and secondary from it.  However, I don’t see how Figure 1 reflects the primary and secondary configuration.

** Section 3.  Editorial.  The term “hidden primary” is not in used in RFC8499.  I believe the term there is “hidden master” which we stopped using for inclusive language reasons.  Cite Section 6 or provide bridging text between the old and new term.

** Section 3.  Typo.  Missing close parentheses.  s/ one or more Distribution Channels (Section 6 that/one or more Distribution Channels (Section 6) that/

** Section 3.2.
The visible NS records
SHOULD remain pointing at the cloud provider's server IP address.

Who is the cloud provider in Figure 1?  Is cloud provide the DOI?  If so, please use consistent terminology in the normative language.

** Section 4.5. s/any any/

** Section 10.  Typo. s/The remaining of the/The remainder of this/

** Section 11. 

The Public Homenet Zone lists the names of services hosted in the
  home network.  Combined with blocking of AXFR queries, the use of
  NSEC3 [RFC5155] ...

Thanks for calling out that NSEC3 provides some mitigation for zone enumeration.  Since it’s use is not mandatory (only RECOMMENDED), please explicitly state the consequence of it NOT being used (i.e., an enumerated list of services on your internal network).

Section 12.2.  The analysis in this section seems to be focused on IPv6 addresses. Section 1.1. seems to allow for IPv4.  Please reflect that.

** Missing Operational Considerations.

HomeNet technologies makes it easier to expose devices and services to the Internet.  This imposes broader operational considerations for the operator and the Internet:

-- The home network operator must carefully assess whether a device or service previously fielded only on a home network is robust enough to be exposed to the Internet

-- The home network operator will need to increase the diligence to regularly managing these exposed devices due to their increased risk posture of being exposed to the Internet

-- Depending on the operational practices of the home network operators, there is an increased risk to the Internet architecture through the possible introduction of additional internet-exposed system that are poorly managed and likely to be compromised.  Carriers may not to deployed additional mitigations to ensure that attacks do not originate from their networks.

[Ballot discuss]
This isn't my only concern with this document but Warren Kumari has broadly covered the space with his own DISCUSS.  I did want to highlight this one, though.  I think it should be relatively easy to fix.

Section 4.6, "Securing the Control Channel", almost-mandates security:

```
  The control channel between the HNA and the DM MUST be secured at
  both the HNA and the DM.
```

It does not, however, specify any mandatory-to-implement security mechanism, although it provides an interesting and wide-ranging discussion of many options.  It's very difficult for me to see how interoperable implementations can be built, that comply with the quoted requirement, by someone working from the current specification. It does seem from other hints in the document that the authors consider TLS mandatory even though it's not stated as such in Section 4.6. For example, Security Considerations subsection 12.1 says,

```
  The channels between HNA and DM are mutually authenticated and
  encrypted with TLS [RFC8446] and its associated security
  considerations apply.
```

Another hint that TLS is viewed as mandatory-to-implement is from a different document also currently under review, draft-ietf-homenet-naming-architecture-dhc-options-21 (Sections 4.2 and 4.3):

```
      The bit for DNS over TLS [RFC7858] MUST be set.
```

I talk about this more in my comment on Section 4.6, but there's just no way to read this paragraph as mandating TLS:

```
  Secure protocols (like TLS [RFC8446]) SHOULD be used to secure the
  transactions between the DM and the HNA.
```

It doesn't even quite mandate secure transport in general, since it's a SHOULD (so presumably there are times when an implementor can sensibly ignore it, though these are not discussed). What's more, TLS is only given as an example of one transport that would be OK, not as the mandatory-to-implement secure transport. As written, any secure transport, for example TCP-AO, would satisfy this SHOULD.

Based on the hints throughout the rest of the document set, that the authors think of TLS as the mandatory-to-implement base transport, I think this section should be rewritten to match that expectation.

[Ballot comment]
# RTG AD John Scudder's comments for draft-ietf-homenet-front-end-naming-delegation-18

CC @jgscudder

Thanks for the work on this document, it clearly reflects a lot of effort. I hope these comments help you get it over the finish line.

Although I'm not enough of a DNS expert to evaluate the details of what the document specifies, the number of inconsistencies and minor errors I've flagged in my review makes me concerned that there may be problems with implementability.  For this reason I support Warren Kumari's DISCUSS.

In my comments below I've flagged a few grammar nits, but for the most part I've tried to restrict myself to cases where it seemed like there was a risk of misunderstanding if not corrected.  Even when/if these are fixed I think the document would benefit from a full go-over either manually or using an automated grammar checker, before sending it to the RFC Editor.  (Yes the RFC Editor will do their best to fix all of these.  But it's better for the authors to do it to the best of their ability, including because occasionally, despite their best efforts, the RFC Editor introduces a "fix" that results in an unwanted normative change.)

## COMMENTS

### Global - "associated to"

There are at least 13 occurrences of the phrase "associated to".  Can these all be replaced by the more idiomatically correct "associated with"?  I hesitate, because "associated to" in computing can have a technically-distinct meaning, however if that's the case in any of these I think such uses of "associated to" may need clarification.

So, to be clear: I suggest either replacing these by "associated with", or if that's inappropriate, clarifying the meaning.

### Global - SHOULD vs. MUST

A quick grep shows 32 instances of SHOULD or SHOULD NOT in the document (not counting the two in the boilerplate). I haven't audited each one, but for many of these it's difficult to see why they're SHOULD and not MUST. My own heuristic is to think of SHOULD as a "must/unless" pair -- it's desirable to provide some guidance to the implementator as to what circumstances would justify ignoring the SHOULD. If you can't actually think of good reasons to do that, consider changing the SHOULD to a MUST. Or if you're using SHOULD in the sense of "we think you ought to implement it this way but we are trying to be considerate and not yell MUST at you all the time" it's also reasonable to use lower-case words instead of RFC 2119 keywords.

I won't comment separately on each individual SHOULD in the document but I encourage you to review them.

### Section 1

"KSK (DS RRset)"

Please provide a reference or other hints for those readers who don't speak DNSSEC as a first language (like me). "KSK" could probably use to be expanded on first use, too.

### Section 1.1

```
  However, since communications
  are established with names which remains a global identifier
```
 
I don't understand what that clause means.

### Section 1.2

```
  even adapted to IPv6 and ignoring those associated to an IPv4
  development
```
 
I don't understand what this clause means. Is there a word missing between "those" and "associated", and perhaps "to" should be "with"?

### Section 1.3.2

Please expand "CSR" on first use (and provide a reference if appropriate).

### Section 3.1 - "as described"

```
  as
  described in Figure 1
```

Perhaps "as depicted in Figure 1"? I don't think Figure 1 can be said to be a (full) description of anything.

### Section 3.1 - "answer to"

"it is not expected to answer to DNS requests" --> "it is not expected to answer DNS requests" (changed "answer to" to just "answer", there is a slightly different shade of meaning)

### Section 3.2

```
  The visible NS records
  SHOULD remain pointing at the cloud provider's server IP address"
```

This is the sole mention of a "cloud provider" in the document. Re-word?

### Section 4

```
  the IP address and port number to use and protocol to
  set secure session
```
 
I don't understand what that clause means (in particular "protocol to set secure session").

### Section 4.2

For this text,

```
  By accepting the DS RR, the DM commits in taking care of advertising
  the DS to the parent zone.  Upon refusal, the DM clearly indicates it
  does not have the capacity to proceed to the update.
```

Would the below rewrite be correct? If not, please propose another.

```
  By accepting the DS RR, the DM commits to advertise
  the DS to the parent zone.  On the other hand if the DM
  does not have the capacity to advertise the DS to the
  parent zone, it indicates this by refusing the DS RR.
```

### Section 4.3

I don't understand what this paragraph is telling me about the provision of the IP address by the HNA:

```
  The HNA works as a primary authoritative DNS server, while the DM
  works like a secondary.  As a result, the HNA must provide the IP
  address the DM is using to reach the HNA.  The synchronization
  Channel will be set between that IP address and the IP address of the
  DM.  By default, the IP address used by the HNA in the Control
  Channel is considered by the DM and the specification of the IP by
  the HNA is only OPTIONAL.  The transport channel (including port
  number) is the same as the one used between the HNA and the DM for
  the Control Channel.
```

You start out by saying the "the HNA must provide the IP address the DM is using to reach the HNA". (By the way when you say "is using" I think you mean "should use". No?) I note the use of "must".

But then you go on to say that "the specification of the IP by the HNA is only OPTIONAL". (I assume that "the IP" here means "the IP address" that was discussed a few sentences back, probably you should add the word "address" if so.)

These two sentences, the "must" in the first one and the "OPTIONAL" in the later, seem directly in opposition to one another. :-(

### Section 4.5.2

```
  The DM SHOULD ignore non-empty the Pre-requisite and
  Additional Data section"
```

I don't know what this means. If "non-empty" weren't there, I would get it, it would just mean "ignore the pre-req and additional data sections no matter what their content is" -- so maybe the easiest fix is to delete "non-empty" (and changing "section" to "sections" while you're at it), as in

```
  The DM MUST ignore the Pre-requisite and Additional Data
  sections, if present.
```

### Section 4.5.2

These two paragraphs seem a little inconsistent:

```
  An error indicates the MD does not
  update the DS, and other method should be used by the HNA.

  The regular DNS error message SHOULD be returned to the HNA when an
  error occurs.  In particular a FORMERR is returned when a format
  error is found, this includes when unexpected RRSets are added or
  when RRsets are missing.  A SERVFAIL error is returned when a
  internal error is encountered.  A NOTZONE error is returned when
  update and Zone sections are not coherent, a NOTAUTH error is
  returned when the DM is not authoritative for the Zone section.  A
  REFUSED error is returned when the DM refuses to proceed to the
  configuration and the requested action.
```

I would have guessed that the implication of some of the errors cited in the second paragraph is that the HNA should correct the problem and then retry.  But the first paragraph seems to indicate that an HNA shouldn't bother even considering the error code, because "and other method should be used by the HNA".

I'm not sure how, or if, to resolve this seeming inconsistency.

### Section 4.5.3

```
  Similarly to Section 4.5.2, DNS errors are used and an error
  indicates the DM is not configured as a secondary.
```

Related to the previous comment -- is this true regardless of what error code is returned, for example would a FORMERR mean that the DM is not configured as a secondary?

Even given that any error implies that the operation failed, what if the DM had already been previously configured as secondary, and the operation were merely updating some parameter? Would the previous configuration be voided, as the text currently implies? Or would the DM remain configured as secondary, using the previous configuration?

### Section 4.6

These two paragraphs seem inconsistent:

```
  The control channel between the HNA and the DM MUST be secured at
  both the HNA and the DM.

  Secure protocols (like TLS [RFC8446]) SHOULD be used to secure the
  transactions between the DM and the HNA.
```

MUST the channel be secured?  Or is it only SHOULD?  Also, does the second paragraph really mean "secure *transport* protocols", or is the ambiguity intentional?  By ambiguity, I suppose the paragraph as written might be satisfied by object-level security, for instance, and for that matter it leaves it up to the reader to even define exactly what they mean by "security". Finally, see also my DISCUSS comments -- if you actually want to mandate TLS (as implied by some of the other parts of this document, and draft-ietf-homenet-naming-architecture-dhc-options-21), you need to make some changes to this section.

### Section 4.6

Please expand SAN on first use.

### Section 7

```
  Depending how the communications between the HNA and the DM are
  secured, only packets associated to that protocol SHOULD be allowed.
```

This is too vague. What specifically about the means of securing the communications would lead the implementor to follow, or disregard, the SHOULD?

### Section 10

```
  Then,
  the HNA advertises the DM via a NOTIFY, that the Public Homenet Zone
  has been updated
```

Probably you mean "advertises to" or maybe better, "advises", where you've written "advertises"? If not, then I don't understand what's happening in this part.

### Section 12.2

Consider using "their" instead of "his".

### Section 14

Was "its" chosen as the pronoun for two persons being thanked, based on those persons' preferences? If not then consider whether you've used the right pronoun in those two places, in my experience it's fairly rare -- but not unheard-of! -- for a person to prefer to be referred to as "it" rather than the more common "he", "she", or "they".

### Appendix A.1

I'm a little confused -- the first couple of paragraphs led me to believe that this section was just going to tell me what parameters are required, but wasn't going to mandate the means of providing them. But then we come to,

```
  The above parameters MUST be be provisioned for ISP-specific reverse
  zones, as per [I-D.ietf-homenet-naming-architecture-dhc-options].
```

The "MUST" combined with the "as per" implies you're mandating that DHCPv6 be used to provision the parameters. If you really do intend to make dhc-options mandatory, it needs to be a normative reference. On the other hand if, as I think is likely, you only intended to use dhc-options as an example, perhaps something like this rewrite?

```
  The above parameters MUST be be provisioned for ISP-specific reverse
  zones. One example of how to do this can be found in
  [I-D.ietf-homenet-naming-architecture-dhc-options].
```

### Appendix B - "registered_domain" or "zone"?

This threw me off -- in the CDDL you show "registered_domain" but in the explanatory text you describe (what I think is) this field as "Registered Homenet Domain (zone)". Should the latter be "Registered Homenet Domain (registered_domain)" instead? (Or, rename "registered_domain" in the CDDL as "zone"?)

### Appendix B - 2119 keywords

It's weird that you lead with "This section is non-normative" but then pepper the content with the RFC 2119 keyword "OPTIONAL". I think probably you don't mean it's "non-normative" (that generally means something like "this is an example, it doesn't define anything, it can safely be ignored"). Rather, I think you mean implementing it is optional. I think you could fix this by deleting the words "is non-normative and".

Also, "MANDATORY" isn't an RFC 2119 keyword but you've capitalized it like one. If you want to introduce your own keyword to put the the force of VERY SERIOUS NORMATIVE CAPITALIZATION behind this word, I think it would be a good idea to define it in your Terminology section, probably right after the RFC 2119 boilerplate paragraph. Alternately, you could just change all your uses of "mandatory" and "optional" in this section to lower-case. It would still be clear, IMO.

## NITS

- "these names needs" --> "these names need"
- "The remaining of the document" --> "the rest of the document"
- "buys a domain name to a registrar" --> "buys a domain name from a registrar"
- "DOI has a roof of ownership" --> "roof" should be... "proof"?
- "as detaille din further details below" --> "as detailed below"
- "rsynch" --> "rsync"
- "meth of" --> "method"

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot discuss]
Please see: https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

I am (reluctantly) balloting DISCUSS on the following criteria:
* The specification is impossible to implement due to technical or clarity issues.
* The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity.
* It is unlikely that multiple implementations of the specification would interoperate, usually due to vagueness or incomplete specification.

I apologize for doing this, as I know that this will be a difficult set of comments to address. This isn't just a few "here are the DISCUSS points", but rather "there are a sufficient number of lack of clarity issues (and readability issues) that I don't think it can be understood and implemented without ambiguity."

I have reviewed most of the document, but have only transcribed my comments up to page 13. Because there are both nits and substantive comments on the same bits of text (and to stop this gettign even longer) I have not separated them into separate sections like I normally would.

I wanted to send this out now, so that the authors, WG and AD can start reviewing and we can discuss some way to resolve this...

[Ballot comment]

Section 1:
1:
O: The remaining of the document is as follows.
P: The remainder of the document is as follows:
C: Nit - Grammar


2:
O: Section 3 provides an architectural view of the HNA, DM and DOI as well as its different communication channels
P: Section 3 provides an architectural view of the HNA, DM and DOI as well as their different communication channels
C: Nit - Plural.

3:
O: Section 7 and Section 9 respectively details HNA security policies as well as DNSSEC
P: Section 7 and Section 9 respectively detail HNA security policies as well as DNSSEC
C: Nit - Grammar / plural

Section 1.1:
4:
O: Of these the link-local are never useful for the Public
Zone,
C: I don't really agree with the "never" - the document does discuss
failing back to the Public zone if needed, and so this may sometimes be
useful. I agree that it is much less common / useful, and this this is
probably a nit...


5:
O: "However, since communications
are established with names which remains a global identifier, the
communication can be protected by TLS the same way it is protected on
the global Internet."
C: "However" implies that the sentence follows on from a previous point and provides a refutation / comparison, and this sentence doesn't - it is more of a fragment / new thought.
C: s/remains/remain/ (grammar)
C: More text is needed here - I'm *assuming* that you are meaning that because the name is globally resolvable to an address, that this can be used to obtain a certificate for that name? If so, that's really not clear.


Section 1.2:
6:
O: "An alternative existing solution is to have a single zone, where a
host uses a RESTful HTTP service to register a single name into a
common public zone. "
P: "An alternative existing solution for residential customers is to..."
C: There are a number of alternative solutions, for example many companies use DHCP to populate a zone (usually using RFC 2136), Windows Active Directory does something similar, many cloud / hosting providers will add and remove entries, etc.


7:
O: "This is often called "Dynamic DNS" [DDNS], and
there are a number of commercial providers. While the IETF has
defined Dynamic Update [RFC3007], in many - as far as the co-authors
know in all cases - case commercial "Dynamic Update" solutions are
implemented via a HTTPS RESTful API."
C1: I think that you need to be much clearer that the "Dynamic DNS" you are talking about in the first sentence is different to Dynamic Updates.
C2: I think that that is the wrong reference - RFC2136 is the Dynamic Updates RFC, RFC3007 wraps it in TSIG.
C3: You have a repeated "case" (actually, "case" should move before the hyphen, and the second "cases" should be removed).
C4: 30 seconds with a search engine shows that Dyn DNS (of of the largest providers) supports RFC2136 dynamic DNS updates - https://help.dyn.com/tsig/, as does Dynu - https://www.dynu.com/DynamicDNS/IPUpdateClient/NSUpdate . I'm assuming that many others to too...

8:
O: "For a very few numbers of hosts, the use of such a system provides an
alternative to the architecture described in this document."
C: Why? There are a huge number of users/hosts using Dynamic DNS services, and many of the Dynamic DNS providers are doing quite well, so I don't understand how their users count as "a very few".

9:
O: "Dynamic
DNS - even adapted to IPv6 and ignoring those associated to an IPv4
development - does suffer from some severe limitations:"
C1: Why do you say "even adapted to IPv6"? IPv6 Dynamic DNS already exists and is deployed -- e.g: https://www.noip.com/blog/2019/11/03/ip-now-offers-ipv6-dynamic-dns/
C2: " and ignoring those associated to an IPv4
development" - I'm unable to parse this.

10:
O: "* the CPE/HNA router is unaware of the process, and cannot respond
to queries for these names and communications to these names
require an Internet connectivity is order to perform the DNS
resolution."
C: In many many cases the CPE itself is the Dynamic DNS clinet, e.g: https://www.noip.com/support/knowledgebase/how-to-configure-ddns-in-router/ lists 9 vendors of CPE whose devices do DDNS, and I'm aware of many many more.

11:
O: "* the CPE/HNA router cannot control the process. Any host can do
this regardless of whether or not the home network administrator
wants the name published or not."
C: This proposal doesn't "fix" that -- any host will stil be able to run a DDNS client and publish a name. I don't really view this as a bug, but if you are pointing out "issues"/"limitations" with something that you are aiming to replace, you should clarify that your proposal doesn't address some of them.

12:
O: "* "all the good names are taken" - current services provide a small
set of zones shared by all hosts across all home networks. More
especially, there is no notion of a domain specific home network."
C: That's completely wrong - a number of Dynamic DNS providers do this. 10 seconds with a search engine show:
https://www.noip.com/support/knowledgebase/can-i-use-my-own-domain-name-with-no-ip/
https://www.namecheap.com/support/knowledgebase/article.aspx/595/11/how-do-i-enable-dynamic-dns-for-a-domain/
https://blog.jswart.xyz/posts/cloudflare-dynamic-dns/
https://support.google.com/domains/answer/6147083?hl=en

13:
O: "* Dynamic Updates solution are not interoperable and each provider
has its own way to implement it."
C: This is also wrong. A number of providers support the 'dyndns2' protocol, including Dyn DNS, Amazon Route 53, Google Domains, No-IP, etc.

Section 1.3.1:
14:
O: "A specific vendor with specific relations with a registrar or a
registry may sell a CPE that is provisioned with provisioned domain
name."
C: "is provisioned with provisioned"

15:
O: "Such domain name does not need to be necessary human readable."
C1: "Such *a* domain name"
C2: Remove "necessary"
C3: Is it really useful to have a name like "aheriuthga23.somevendor.exmaple.com"?

16:
O: "One possible way is that the vendor also provisions..."
C: One possible way to what? The previous sentence talks about a vendor selling CPE, so one possible way for them to sell something? You probably need some text around "one way for a vendor to bootstrap" or "provision this", or something. Needs work.

17:
O: "One possible way is that the vendor also provisions the HNA with a
private and public keys as well as a certificate."
C1: Either "with a private and public keys" or "with a
private and public key"
C2: You say with keys and a certificate, and then talk about what the purpose of the keys are, but not what the cert is used for.

18:
O: "Instead these
keys are solely used by the HNA to proceed to the authentication."
C: "solely used" - does this mean that they cannot / must not be used for anything else?
C: "proceed to the authentication" does not parse. Perhaps "used for authentication" or "to the authentication phase" (not that that is really described either)

19:
O: "The reason to combine the domain name and the
key is that DOI are likely handle names better than keys and that
domain names might be used as a login which enables the key to be
regenerated."
C: "are likely handle" doesn't parse.
C: "domain names might be used as a login" - the domain name and what? Presumably I cannot just login with the credential "foo.cpe.example" without some other piece of information or anyone could regenerate the keys. And in that case, why are keys pre-provisioned on the device?

20:
O: "When the home network owner plugs the CPE at home, ...""
C: "plugs in the CPE"


Section 1.3.2. Agnostic CPE:
21:
O: "An CPE that is not preconfigured may also take advantage to the
protocol defined in this document but some configuration steps will
be needed."
C: s/An CPE/A CPE/
C: s/may also take advantage to the protocol/may also take advantage of the
protocol/ (actually I think "may also use the protocol", but whatever...)

22:
O: " 1. The owner of the home network buys a domain name to a registrar,
and as such creates an account on that registrar"
C: s/to a registrar/from a registrar/

23:
O: "A good way to provide the
parameters would be the home network be able to copy/paste a JSON
object"
C: home networks cannot copy and paste. Perhaps "One potential mechanism would be to provide the user with a JSON object which they can copy and paste into the CPE" (or similar).

24:
O: "What matters at that point is the DOI
being able to generate authentication credentials for the HNA to
authenticate itself to the DOI.
C: s/being able/is able/
C: It also isn't that it needs to be able to do this, but rather that it can provide authentication credentials to the HNA.

25:
O: "If the DOI is not the registrar, then the proof of ownership needs
to be established using protocols like ACME [RFC8555] for example
that will end in the generation of a certificate."
C: Why does it need to "end in the generation of a certificate"? All you need is proof of ownership, yes? And ACME is generally used to prove ownership of a hostname / SAN - it is very unclear here what exactly you are proving ownership of / to -- the hostname to the IP/device? Presumably not because the purpose of this is to create that delegation...

26:
O: "ACME is used
here to the purpose of automating the generation of the
certificate, the CA may be a specific CA or the DOI. "
C: Why "a specific CA or the DOI"? If I get a (valid) cert from any old CA, is that not valid? And it I get a cert from the DOI, it is acting as a CA, isn't it? What is this actually trying to say?

27:
O: "With that
being done, the DOI has a roof of ownership and can proceed as
above."
C: "proof of ownership"



Section 3. Architecture Description
28:
O: "Note that
Appendix B defines necessary parameter to configure the HNA."
C: Does this mean that Appendix B is normative?
C: s/parameter/parameters/


29:
O: "The DOI will
serve every DNSSEC request of the Public Homenet Zone coming from
outside the home network."
C: The DOI gets DNS requests, not DNSSEC requests (there isn't really such a thing as a DNSSEC request)
C: "every"?
C: What about if a device inside the home queries the DOI? It should still respond, yes?

30:
O: "the resolution is expected to be handled by the Homenet
Resolver as detaille din further details below."
C: "detailed in"

31:
O: "Registered Homenet Domain Name"
C: You don't have "Registered Homenet Domain Name" in the terminology section, either add it or (better yet) s/Name/name/

32:
O: "The HNA SHOULD build the Public Homenet Zone in a single view
populated ..."
C: It is unclear what "in a single view" means here - views are a way of mapping clients to different sets of answers, and they are not in a zone.

33:
O: "Once the Public Homenet Zone has been built, the HNA communicates and
synchronizes it with the DOI using a primary/secondary setting as
described in Figure 1. "
C: It is unclear what "using a primary/secondary setting" means, and it isn't "described in Figure 1."

34:
O: "The HNA acts as a hidden primary [RFC8499]"
C: 8499 doesn't define hidden primary; it does define Hidden master and Primary server. It also says that a master and a primary are the same, but the reference should be clearer.

35:
O: "the DM behaves as a secondary responsible to distribute the
Public Homenet Zone to the multiple Public Authoritative Servers that
DOI is responsible for."
C: s/responsible to distribute/responsible for distributing/
C: "the multiple Public Authoritative Servers" - which servers? A DOI may have many many sets of authoritative servers, only some of which may be authoritative for this zone.

36:
O: "one or more Distribution Channels (Section 6 that distribute the
Public Homenet Zone from the DM to the Public Authoritative Server
serving the Public Homenet Zone on the Internet."
C: (Section 6/ (Section 6)/
C: s/Public Authoritative Server/Public Authoritative Servers/

37:
O: "Resolution is performed by the DNSSEC resolvers."
C: Which "the DNSSEC resolvers"? ("the" implies a specific set) Also, why are these "DNSSEC resolvers"? Does this mean that non-DNSSEC validating DNS servers cannot resolve these names (presumably not, but...)

38:
O: "When the resolution
is performed outside the home network, the DNSSEC Resolver resolves
the DS record on the Global DNS and the name associated to the Public
Homenet Zone (myhome.example) on the Public Authoritative Servers."
C: What is this actually trying to say? The DS record is resolved on the "Global DNS" but the name is resolved on the "Public Authoritative Servers" - is this supposed to mean that the Public Authoritative Servers are not part of the Global DNS? And the DS record is part of the "name associated to the Public Homenet Zone", but published at the parent. Is this supposed to just be "is resolved like any other name"?

39:
O: "On the other hand, to
provide resilience to the Public Homenet Zone in case of WAN
connectivity disruption, the Homenet DNSSEC Resolver SHOULD be able
to perform the resolution on the Homenet Authoritative Servers."
C: "the Homenet DNSSEC Resolver" - this implies that this is only one. It also seems odd to say that it "SHOLD be able to", and then immediately say that this can't actually be done because this isn't any (current) way to configure the DNSSEC information (or, if it is defined in 7788 I missed it)

40:
O: "How the Homenet Authoritative Servers are provisioned is also out of
scope of this specification. It could be implemented using primary
and secondary servers, or via rsync."
C: It is unclear what this is trying to say - "are provisioned" with what? It this trying to say "how the zone information is syncronized between the servers"? Or how the domains are provisioned onto the servers?


41:
O: "The main issue is that the Dynamic DNS update would also update the
parent zone's (NS, DS and associated A or AAAA records) while the
goal is to update the DM configuration files. The visible NS records SHOULD remain pointing at the cloud provider's server IP address -
which in many cases will be an anycast addresses. Revealing the
address of the HNA in the DNS is not desirable. "
C: Huh? *What* main issue? Is this text just misplaced and supposed to be somewhere else? It seems completely unrelated to this section. Also, what "cloud provider"? This is the only mention of a cloud provider. And what Dynamic DNS update are you talking about here?

42:
O: "While
information is carried from the DOI to the HNA and from the HNA to
the DOI, the HNA is always initiating the exchange in both
directions.
As such the HNA has a prior knowledge of the DM identity (X509
certificate), the IP address and port number to use and protocol to
set secure session."
C: "As such" doesn't make sense here (or I'm unable to parse it) -- the first bit says that the HNA initiates the exchanges, but the second bit says that "As such it has knowledge" - perhaps you mean "requires"? I have no idea what this is supposed to say.

Section 4.1. Information to Build the Public Homenet Zone:
43:
O: "The HNA builds the Public Homenet Zone based on information retrieved
from the DM."
C: Retrieved how? (Link to 4.5.1, otherwise the reader will be very confused.)


44:
O: "The information includes at least names and IP addresses of the
Public Authoritative Name Servers. In term of RRset information this
includes:
* the MNAME of the SOA,"
C: This says "this includes at least names and IP addresses" but then also suddenly throws in the MNAME. Also, what is the MNAME actually used for? The document says that you have to put it in the zone, but why must it be what the DM says, but the other parameter in the SOA can be changed?

45:
O: "The DM MAY also provide operational parameters such as other fields
of SOA (SERIAL, RNAME, REFRESH, RETRY, EXPIRE and MINIMUM)."
C: S 4.5.1 says that this is received over AXFR, so the HNA always gets the SOA -- so how is this a "MAY also provide"? Or is it supposed to be that it always provides these, but the HNA can ignore some or all of them?

Section "4.2. Information to build the DNSSEC chain of trust"
46:
O: "The HNA SHOULD provide the hash of the KSK (DS RRset), so the DOI
provides this value to the parent zone."
C: Is it that the HNA should provide the DS, or a hash of the KSK? (The DS is more than just the hash).
C: "so that the DOI can provide"

47:
O: "When such relation exists, the
HNA should be able to request the DOI to update the DS RRset in the
parent zone."
C: "should be able to request" - this implies that there is a specific way for the HNA to request this, if this relationship exists -- how would the HNA know this? Shouldn't it always send the DS?

48:
O: "The HNA SHOULD provide... " and "Though the HNA may also later directly update the values of the DS
via the Control Channel, it is RECOMMENDED to use other mechanisms".
"SHOULD provide" how? Over the Control Channel? And how does that relate to the RECOMMEND to use other mechanisms?

Section 4.3. Information to set the Synchronization Channel
49:
O: "As a result, the HNA must provide the IP
address the DM is using to reach the HNA. The synchronization
Channel will be set between that IP address and the IP address of the
DM. By default, the IP address used by the HNA in the Control
Channel is considered by the DM and the specification of the IP by
the HNA is only OPTIONAL. The transport channel (including port
number) is the same as the one used between the HNA and the DM for
the Control Channel."
C: This entire paragraph is really confusing. I'm guessing that this is trying to sat that the HNA provides the IP for the DM to contact it?
C: It also says that the DM "considers" the IP used by the HNA, and so the specification of the IP is OPTIONAL. I'm guessing that this is trying to say that the DM will, by default, use the IP that the HNA used to contact it? In the non-default case, how exactly does the HNA specify the address? (how is this communicated?).
C: Also, "The transport channel (including port
number) is the same as the one used between the HNA and the DM for
the Control Channel." -- so the transport channel and Control Channel use the same IPs and ports? How are messages disambiguated? Isn't this jsut one channel then?

[Ballot discuss]
Please see: https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/

I am (reluctantly) balloting DISCUSS on the following criteria:
* The specification is impossible to implement due to technical or clarity issues.
* The protocol has technical flaws that will prevent it from working properly, or the description is unclear in such a way that the reader cannot understand it without ambiguity.
* It is unlikely that multiple implementations of the specification would interoperate, usually due to vagueness or incomplete specification.

I apologize for doing this, as I know that this will be a difficult set of comments to address. This isn't just a few "here are the DISCUSS points", but rather "there are a sufficient number of lack of clarity issues (and readability issues) that I don't think it can be understood and implemented without ambiguity."

I have reviewed most of the document, but have only transcribed my comments up to page 13.  I wanted to send this out now, so that the AD, WG and authors can start reviewing and we can discuss some way to resolve this... Note that there are a mixture of nits and also more substantive issues in these comments...

[Ballot comment]

Section 1:
1:
O: The remaining of the document is as follows.
P: The remainder of the document is as follows:
C: Grammar


2:
O: Section 3 provides an architectural view of the HNA, DM and DOI as well as its different communication channels
P: Section 3 provides an architectural view of the HNA, DM and DOI as well as their different communication channels
C: Plural.

3:
O: Section 7 and Section 9 respectively details HNA security policies as well as DNSSEC
P: Section 7 and Section 9 respectively detail HNA security policies as well as DNSSEC
C: Grammar / plural

Section 1.1:
4:
O: Of these the link-local are never useful for the Public
Zone,
C: I don't really agree with the "never" - the document does discuss
failing back to the Public zone if needed, and so this may sometimes be
useful. I agree that it is much less common / useful.


5:
O: "However, since communications
are established with names which remains a global identifier, the
communication can be protected by TLS the same way it is protected on
the global Internet."
C: "However" implies that the sentence follows on from a previous point and provides a refutation / comparison, and this sentence doesn't - it is more of a fragment / new thought.
C: s/remains/remain/ (grammar)
C: More text is needed here - I'm *assuming* that you are meaning that because the name is globally resolvable to an address, that this can be used to obtain a certificate for that name? If so, that's really not clear.


Section 1.2:
6:
O: "An alternative existing solution is to have a single zone, where a
host uses a RESTful HTTP service to register a single name into a
common public zone. "
P: "An alternative existing solution for residential customers is to..."
C: There are a number of alternative solutions, for example many companies use DHCP to populate a zone (usually using RFC 2136), Windows Active Directory does something similar, many cloud / hosting providers will add and remove entries, etc.


7:
O: "This is often called "Dynamic DNS" [DDNS], and
there are a number of commercial providers. While the IETF has
defined Dynamic Update [RFC3007], in many - as far as the co-authors
know in all cases - case commercial "Dynamic Update" solutions are
implemented via a HTTPS RESTful API."
C1: I think that you need to be much clearer that the "Dynamic DNS" you are talking about in the first sentence is different to Dynamic Updates.
C2: I think that that is the wrong reference - RFC2136 is the Dynamic Updates RFC, RFC3007 wraps it in TSIG.
C3: You have a repeated "case" (actually, "case" should move before the hyphen, and the second "cases" should be removed).
C4: 30 seconds with a search engine shows that Dyn DNS (of of the largest providers) supports RFC2136 dynamic DNS updates - https://help.dyn.com/tsig/, as does Dynu - https://www.dynu.com/DynamicDNS/IPUpdateClient/NSUpdate . I'm assuming that many others to too...

8:
O: "For a very few numbers of hosts, the use of such a system provides an
alternative to the architecture described in this document."
C: Why? There are a huge number of users/hosts using Dynamic DNS services, and many of the Dynamic DNS providers are doing quite well, so I don't understand how their users count as "a very few".

9:
O: "Dynamic
DNS - even adapted to IPv6 and ignoring those associated to an IPv4
development - does suffer from some severe limitations:"
C1: Why do you say "even adapted to IPv6"? IPv6 Dynamic DNS already exists and is deployed -- e.g: https://www.noip.com/blog/2019/11/03/ip-now-offers-ipv6-dynamic-dns/
C2: " and ignoring those associated to an IPv4
development" - I'm unable to parse this.

10:
O: "* the CPE/HNA router is unaware of the process, and cannot respond
to queries for these names and communications to these names
require an Internet connectivity is order to perform the DNS
resolution."
C: In many many cases the CPE itself is the Dynamic DNS clinet, e.g: https://www.noip.com/support/knowledgebase/how-to-configure-ddns-in-router/ lists 9 vendors of CPE whose devices do DDNS, and I'm aware of many many more.

11:
O: "* the CPE/HNA router cannot control the process. Any host can do
this regardless of whether or not the home network administrator
wants the name published or not."
C: This proposal doesn't "fix" that -- any host will stil be able to run a DDNS client and publish a name. I don't really view this as a bug, but if you are pointing out "issues"/"limitations" with something that you are aiming to replace, you should clarify that your proposal doesn't address some of them.

12:
O: "* "all the good names are taken" - current services provide a small
set of zones shared by all hosts across all home networks. More
especially, there is no notion of a domain specific home network."
C: That's completely wrong - a number of Dynamic DNS providers do this. 10 seconds with a search engine show:
https://www.noip.com/support/knowledgebase/can-i-use-my-own-domain-name-with-no-ip/
https://www.namecheap.com/support/knowledgebase/article.aspx/595/11/how-do-i-enable-dynamic-dns-for-a-domain/
https://blog.jswart.xyz/posts/cloudflare-dynamic-dns/
https://support.google.com/domains/answer/6147083?hl=en

13:
O: "* Dynamic Updates solution are not interoperable and each provider
has its own way to implement it."
C: This is also wrong. A number of providers support the 'dyndns2' protocol, including Dyn DNS, Amazon Route 53, Google Domains, No-IP, etc.

Section 1.3.1:
14:
O: "A specific vendor with specific relations with a registrar or a
registry may sell a CPE that is provisioned with provisioned domain
name."
C: "is provisioned with provisioned"

15:
O: "Such domain name does not need to be necessary human readable."
C1: "Such *a* domain name"
C2: Remove "necessary"
C3: Is it really useful to have a name like "aheriuthga23.somevendor.exmaple.com"?

16:
O: "One possible way is that the vendor also provisions..."
C: One possible way to what? The previous sentence talks about a vendor selling CPE, so one possible way for them to sell something? You probably need some text around "one way for a vendor to bootstrap" or "provision this", or something. Needs work.

17:
O: "One possible way is that the vendor also provisions the HNA with a
private and public keys as well as a certificate."
C1: Either "with a private and public keys" or "with a
private and public key"
C2: You say with keys and a certificate, and then talk about what the purpose of the keys are, but not what the cert is used for.

18:
O: "Instead these
keys are solely used by the HNA to proceed to the authentication."
C: "solely used" - does this mean that they cannot / must not be used for anything else?
C: "proceed to the authentication" does not parse. Perhaps "used for authentication" or "to the authentication phase" (not that that is really described either)

19:
O: "The reason to combine the domain name and the
key is that DOI are likely handle names better than keys and that
domain names might be used as a login which enables the key to be
regenerated."
C: "are likely handle" doesn't parse.
C: "domain names might be used as a login" - the domain name and what? Presumably I cannot just login with the credential "foo.cpe.example" without some other piece of information or anyone could regenerate the keys. And in that case, why are keys pre-provisioned on the device?

20:
O: "When the home network owner plugs the CPE at home, ...""
C: "plugs in the CPE"


Section 1.3.2. Agnostic CPE:
21:
O: "An CPE that is not preconfigured may also take advantage to the
protocol defined in this document but some configuration steps will
be needed."
C: s/An CPE/A CPE/
C: s/may also take advantage to the protocol/may also take advantage of the
protocol/ (actually I think "may also use the protocol", but whatever...)

22:
O: " 1. The owner of the home network buys a domain name to a registrar,
and as such creates an account on that registrar"
C: s/to a registrar/from a registrar/

23:
O: "A good way to provide the
parameters would be the home network be able to copy/paste a JSON
object"
C: home networks cannot copy and paste. Perhaps "One potential mechanism would be to provide the user with a JSON object which they can copy and paste into the CPE" (or similar).

24:
O: "What matters at that point is the DOI
being able to generate authentication credentials for the HNA to
authenticate itself to the DOI.
C: s/being able/is able/
C: It also isn't that it needs to be able to do this, but rather that it can provide authentication credentials to the HNA.

25:
O: "If the DOI is not the registrar, then the proof of ownership needs
to be established using protocols like ACME [RFC8555] for example
that will end in the generation of a certificate."
C: Why does it need to "end in the generation of a certificate"? All you need is proof of ownership, yes? And ACME is generally used to prove ownership of a hostname / SAN - it is very unclear here what exactly you are proving ownership of / to -- the hostname to the IP/device? Presumably not because the purpose of this is to create that delegation...

26:
O: "ACME is used
here to the purpose of automating the generation of the
certificate, the CA may be a specific CA or the DOI. "
C: Why "a specific CA or the DOI"? If I get a (valid) cert from any old CA, is that not valid? And it I get a cert from the DOI, it is acting as a CA, isn't it? What is this actually trying to say?

27:
O: "With that
being done, the DOI has a roof of ownership and can proceed as
above."
C: "proof of ownership"



Section 3. Architecture Description
28:
O: "Note that
Appendix B defines necessary parameter to configure the HNA."
C: Does this mean that Appendix B is normative?
C: s/parameter/parameters/


29:
O: "The DOI will
serve every DNSSEC request of the Public Homenet Zone coming from
outside the home network."
C: The DOI gets DNS requests, not DNSSEC requests (there isn't really such a thing as a DNSSEC request)
C: "every"?
C: What about if a device inside the home queries the DOI? It should still respond, yes?

30:
O: "the resolution is expected to be handled by the Homenet
Resolver as detaille din further details below."
C: "detailed in"

31:
O: "Registered Homenet Domain Name"
C: You don't have "Registered Homenet Domain Name" in the terminology section, either add it or (better yet) s/Name/name/

32:
O: "The HNA SHOULD build the Public Homenet Zone in a single view
populated ..."
C: It is unclear what "in a single view" means here - views are a way of mapping clients to different sets of answers, and they are not in a zone.

33:
O: "Once the Public Homenet Zone has been built, the HNA communicates and
synchronizes it with the DOI using a primary/secondary setting as
described in Figure 1. "
C: It is unclear what "using a primary/secondary setting" means, and it isn't "described in Figure 1."

34:
O: "The HNA acts as a hidden primary [RFC8499]"
C: 8499 doesn't define hidden primary; it does define Hidden master and Primary server. It also says that a master and a primary are the same, but the reference should be clearer.

35:
O: "the DM behaves as a secondary responsible to distribute the
Public Homenet Zone to the multiple Public Authoritative Servers that
DOI is responsible for."
C: s/responsible to distribute/responsible for distributing/
C: "the multiple Public Authoritative Servers" - which servers? A DOI may have many many sets of authoritative servers, only some of which may be authoritative for this zone.

36:
O: "one or more Distribution Channels (Section 6 that distribute the
Public Homenet Zone from the DM to the Public Authoritative Server
serving the Public Homenet Zone on the Internet."
C: (Section 6/ (Section 6)/
C: s/Public Authoritative Server/Public Authoritative Servers/

37:
O: "Resolution is performed by the DNSSEC resolvers."
C: Which "the DNSSEC resolvers"? ("the" implies a specific set) Also, why are these "DNSSEC resolvers"? Does this mean that non-DNSSEC validating DNS servers cannot resolve these names (presumably not, but...)

38:
O: "When the resolution
is performed outside the home network, the DNSSEC Resolver resolves
the DS record on the Global DNS and the name associated to the Public
Homenet Zone (myhome.example) on the Public Authoritative Servers."
C: What is this actually trying to say? The DS record is resolved on the "Global DNS" but the name is resolved on the "Public Authoritative Servers" - is this supposed to mean that the Public Authoritative Servers are not part of the Global DNS? And the DS record is part of the "name associated to the Public Homenet Zone", but published at the parent. Is this supposed to just be "is resolved like any other name"?

39:
O: "On the other hand, to
provide resilience to the Public Homenet Zone in case of WAN
connectivity disruption, the Homenet DNSSEC Resolver SHOULD be able
to perform the resolution on the Homenet Authoritative Servers."
C: "the Homenet DNSSEC Resolver" - this implies that this is only one. It also seems odd to say that it "SHOLD be able to", and then immediately say that this can't actually be done because this isn't any (current) way to configure the DNSSEC information (or, if it is defined in 7788 I missed it)

40:
O: "How the Homenet Authoritative Servers are provisioned is also out of
scope of this specification. It could be implemented using primary
and secondary servers, or via rsync."
C: It is unclear what this is trying to say - "are provisioned" with what? It this trying to say "how the zone information is syncronized between the servers"? Or how the domains are provisioned onto the servers?


41:
O: "The main issue is that the Dynamic DNS update would also update the
parent zone's (NS, DS and associated A or AAAA records) while the
goal is to update the DM configuration files. The visible NS records SHOULD remain pointing at the cloud provider's server IP address -
which in many cases will be an anycast addresses. Revealing the
address of the HNA in the DNS is not desirable. "
C: Huh? *What* main issue? Is this text just misplaced and supposed to be somewhere else? It seems completely unrelated to this section. Also, what "cloud provider"? This is the only mention of a cloud provider. And what Dynamic DNS update are you talking about here?

42:
O: "While
information is carried from the DOI to the HNA and from the HNA to
the DOI, the HNA is always initiating the exchange in both
directions.
As such the HNA has a prior knowledge of the DM identity (X509
certificate), the IP address and port number to use and protocol to
set secure session."
C: "As such" doesn't make sense here (or I'm unable to parse it) -- the first bit says that the HNA initiates the exchanges, but the second bit says that "As such it has knowledge" - perhaps you mean "requires"? I have no idea what this is supposed to say.

Section 4.1. Information to Build the Public Homenet Zone:
43:
O: "The HNA builds the Public Homenet Zone based on information retrieved
from the DM."
C: Retrieved how? (Link to 4.5.1, otherwise the reader will be very confused.)


44:
O: "The information includes at least names and IP addresses of the
Public Authoritative Name Servers. In term of RRset information this
includes:
* the MNAME of the SOA,"
C: This says "this includes at least names and IP addresses" but then also suddenly throws in the MNAME. Also, what is the MNAME actually used for? The document says that you have to put it in the zone, but why must it be what the DM says, but the other parameter in the SOA can be changed?

45:
O: "The DM MAY also provide operational parameters such as other fields
of SOA (SERIAL, RNAME, REFRESH, RETRY, EXPIRE and MINIMUM)."
C: S 4.5.1 says that this is received over AXFR, so the HNA always gets the SOA -- so how is this a "MAY also provide"? Or is it supposed to be that it always provides these, but the HNA can ignore some or all of them?

Section "4.2. Information to build the DNSSEC chain of trust"
46:
O: "The HNA SHOULD provide the hash of the KSK (DS RRset), so the DOI
provides this value to the parent zone."
C: Is it that the HNA should provide the DS, or a hash of the KSK? (The DS is more than just the hash).
C: "so that the DOI can provide"

47:
O: "When such relation exists, the
HNA should be able to request the DOI to update the DS RRset in the
parent zone."
C: "should be able to request" - this implies that there is a specific way for the HNA to request this, if this relationship exists -- how would the HNA know this? Shouldn't it always send the DS?

48:
O: "The HNA SHOULD provide... " and "Though the HNA may also later directly update the values of the DS
via the Control Channel, it is RECOMMENDED to use other mechanisms".
"SHOULD provide" how? Over the Control Channel? And how does that relate to the RECOMMEND to use other mechanisms?

Section 4.3. Information to set the Synchronization Channel
49:
O: "As a result, the HNA must provide the IP
address the DM is using to reach the HNA. The synchronization
Channel will be set between that IP address and the IP address of the
DM. By default, the IP address used by the HNA in the Control
Channel is considered by the DM and the specification of the IP by
the HNA is only OPTIONAL. The transport channel (including port
number) is the same as the one used between the HNA and the DM for
the Control Channel."
C: This entire paragraph is really confusing. I'm guessing that this is trying to sat that the HNA provides the IP for the DM to contact it?
C: It also says that the DM "considers" the IP used by the HNA, and so the specification of the IP is OPTIONAL. I'm guessing that this is trying to say that the DM will, by default, use the IP that the HNA used to contact it? In the non-default case, how exactly does the HNA specify the address? (how is this communicated?).
C: Also, "The transport channel (including port
number) is the same as the one used between the HNA and the DM for
the Control Channel." -- so the transport channel and Control Channel use the same IPs and ports? How are messages disambiguated? Isn't this jsut one channel then?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-homenet-front-end-naming-delegation-18, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-10-04):

From: The IESG
To: IETF-Announce
CC: draft-ietf-homenet-front-end-naming-delegation@ietf.org, evyncke@cisco.com, homenet-chairs@ietf.org, homenet@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Simple Provisioning of Public Names for Residential Networks) to Proposed Standard


The IESG has received a request from the Home Networking WG (homenet) to
consider the following document: - 'Simple Provisioning of Public Names for
Residential Networks'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-10-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Home network owners often have devices and services that they wish to
  access outside their home network - i.e., from the Internet using
  their names.  To do so, these names need to be made publicly
  available in the DNS.

  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/



No IPR declarations have been submitted directly on this I-D.

Shepherd's write-up to be updated with the justification for PS intended status.
Authors to fix idnits.
AD will try to do the AD review before IETF-114.
-éric

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

N/A.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

PS.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM, MR and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

There are some downrefs to fix. It looks like all should be fine
as informative references:

  ** Downref: Normative reference to an Informational RFC: RFC 4192
  ** Downref: Normative reference to an Informational RFC: RFC 6092
  ** Downref: Normative reference to an Informational RFC: RFC 7010
  ** Downref: Normative reference to an Informational RFC: RFC 7084
  ** Downref: Normative reference to an Informational RFC: RFC 7368
  ** Downref: Normative reference to an Informational RFC: RFC 7707

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

All good.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

N/A.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

PS.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM, MR and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

There are some downrefs to fix. It looks like all should be fine
as informative references:

  ** Downref: Normative reference to an Informational RFC: RFC 4192
  ** Downref: Normative reference to an Informational RFC: RFC 6092
  ** Downref: Normative reference to an Informational RFC: RFC 7010
  ** Downref: Normative reference to an Informational RFC: RFC 7084
  ** Downref: Normative reference to an Informational RFC: RFC 7368
  ** Downref: Normative reference to an Informational RFC: RFC 7707

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

All good.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

Request for posting confirmation emailed to previous authors: homenet-chairs@ietf.org, Wouter Cloetens , Michael Richardson , Ralf Weber , Ray Hunter , Daniel Migault , Chris Griffiths