Subject: [homenet] WGLC on "redact" and "homenet-dot"

From: Ray Bellis <[email-masked]>
Date: Fri, 18 Nov 2016 13:27:08 +0900

This email commences a four week WGLC comment period on
draft-ietf-homenet-redact and draft-ietf-homenet-dot

Please send any comments to the WG list as soon as possible.

Whilst there was a very strong hum in favour of ".homenet" vs anything
else during the meeting, and there's some discussion of that ongoing
here on the list - I'd like us to please keep the discussion of the
choice of domain separate from other substantive comment about the
drafts' contents.

thanks,

Ray

---

From: Ralph Droms <[email-masked]>
Date: Mon, 21 Nov 2016 08:25:46 -0500

(Updated comments on draft-ietf-homenet-dot originally posted prior to the WG last call)

I suggest that the paragraph in the Introduction that motivates the change from .home to .homenet be augmented or replaced with the reasons Ray listed in earlier e-mail:

1.  we cannot be sure that using .home is consistent with the existing (ab)use
2.  ICANN is in receipt of about a dozen applications for ".home", and some of those applicants no doubt have deeper pockets than the IETF does should they decide to litigate

This sentence appears in section 2:

   Names ending with '.homenet.'  MUST refer to
   services that are located within a home network (e.g., a printer, or
   a toaster).

I think "services" is too restrictive; in fact, the examples are really devices or hosts, not services provided by those devices.  What is the restriction "located within a home network", and what, exactly, does it mean?  In my opinion, this document should focus on name evaluation within the .homenet locally served zone.

Also in section 2, the phrase "Although home networks most often provide one or more service discovery mechanisms," assumes the reader knows that many service discovery mechanisms hide the domain name of the service or host and, hence, .homenet.

In section 3, the response to item 3 in the SUDN reservation considerations could be clarified by specifying that any queries in the .homenet zone must be forwarded to a DNS service as configured by explicitly by HNCP or other appropriate local configuration mechanism coordinated with .homenet resolution, as opposed to just “configured”.  A manually configured entry for some external server is “configured”, but not configured in a helpful way.

Also in item 3, s/for '.homenet'./for domain names ending in '.homenet'/

In item 4, s/part of the domain/part or all of the '.homenet' domain/

Given the existence of draft-ietf-dnsop-terminology-bis, it would be helpful (at least, I would find it helpful) to use the agreed common terminology; for example “recursive resolver” instead of “Caching DNS servers”.

In the answer for question 5, it might help the reader to specify which zones the “authoritative servers” are authoritative for.

“DNS server operator” is likely a term of art in the answer for question, but it’s not clear to me which operators and servers are referred to, here.  Although passive voice should be avoided, it might be appropriate to simply write “DNS servers outside a home network should not be configured to be authoritative for .homenet.

- Ralph

> On Nov 17, 2016, at 11:27 PM, Ray Bellis <[email-masked]> wrote:
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet