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

# 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"

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.

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.

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.

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?

Thanks for working on this specifications. In my review there is no TSV related issue flagged.

I support Paul's discuss as I to feel that experimental would be a better track for this document.

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