[homenet] Last call updates to draft-ietf-homenet-dothome and draft-ietf-homenet-redact

[Ted Lemon <[e-mail]>]

Here are my notes from updating the above two drafts.

Ralph Droms writes regarding draft-ietf-homenet-dothome:

> 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
>
I updated the text as follows:

The '.homenet' top-level domain replaces '.home' which was specified in
[RFC7788] as the default domain-name for home networks. '.home' had been
selected as the most user-friendly option.  However, there are existing
uses of '.home' that may be in conflict with this use: evidence indicates
that '.home' queries frequently leak out and reach the root name servers
[ICANN1] [ICANN2].  Also, ICANN has about a dozen applicants for the
'.home' top-level domain name, which creates a significant risk of
litigation if it were claimed by the IETF outside of that process.  As a
result, the use of '.home' has been deprecated; this document updates
[RFC7788] to replace '.home' with '.homenet', while another document,
[I-D.ietf-homenet-redact] deprecates the use of the '.home' TLD.


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.


I updated the text as follows:

The top-level domain name '.homenet.' is to be used for naming within a
home network. Names ending with '.homenet.' reference a locally-served
zone, the contents of which are unique only to a particular home network,
and are not globally unique.  Such names refer to nodes and/or services
that are located within a home network (e.g., a printer, or a toaster).

 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.


I updated the text as follows:

Some service discovery user interfaces that are expected to be used on
homenets conceal information such as domain names from end users.  However,
it is still expected that in some cases, users will need to see, remember,
and even type, names ending with '.homenet'. It is therefore desirable that
users identify the top-level domain and understand that using it expresses
the intention to connect to a service that is specific to the home network
to which they are connected.  Enforcing the fulfillment of this intention
is out of scope for this document.

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'/


I updated the text as follows:

Name resolution APIs and libraries MUST NOT recognize names that end in
'.homenet.' as special an MUST NOT treat them differently. Name resolution
APIs MUST send queries for such names to their configured caching DNS
server(s). Using a caching server other than the server or servers offered
by the home network will result in failure to correctly resolve queries for
subdomains of '.homenet'.   If a host is configured to always use a
resolver other than the one offered by the local network, it will be unable
to resolve queries that are subdomains of '.homenet'.



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

updated

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”.


I updated the draft to use "recursive resolver" instead of "caching name
server" and sent a note to Paul asking him why there is no definition for
that term in the document.   :)

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


Well, now, when I looked at the answer to question five, I realized that
the text is wrong.   There is no need to specify anything here.   If an
authoritative server is configured to be authoritative for .homenet or any
subdomain(s) of .homenet, it will do the right thing.   If it is not, it
will do the right thing.   The text here requiring an auth server not to
return an NS record for .homenet would only apply to the root operator, and
we are addressing that in a different way.   I think requiring special
treatment for this name in an authoritative server would be a mistake.   I
have updated the text as follows:

Only a DNS server that is authoritative for the root ('.') or is configured
to be authoritative for '.homenet' or a subdomain of '.homenet' will ever
answer a query about '.homenet.'  In both of these cases, the server should
simply answer as configured: no special handling is required.

“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.


I like your proposed text, and updated the document to use it.

Jacques Latour and Bob Harold got into a conversation where Jacque said:

Where do you delegate homenet to? Advanced DNSSEC validation may check for
> proper delegation?


This is actually addressed in the IANA considerations: the proposal is to
do an unsigned delegation to the AS112 servers.   However, the document
doesn't actually do anything to make sure that that delegation will produce
the right result.  I do not know how to address this.

Bob then asked:

If an insecure delegation can be made in the root, then could a local trust
> anchor be used by those who want their .homenet domain DNSSEC validated?


I added the following text to the security considerations to address this:

In order to enable DNSSEC validation of a particular '.homenet', it might
make sense to configure a trust anchor for that homenet.   How this might
be done is out of scope for this document.


Andrew Sullivan wrote, regarding draft-ietf-homenet-redact:

in ¶1 of §1, "This document recommends the use of the '.home'…." reads as
> though the present document (i.e. the I-D itself) is making the
> recommendation.  Perhaps "That document" instead would work, or "Said
> RFC", or something.


 I think "that document" does the job—thanks for catching this.

Andrew also raised the point about the unsigned root zone delegation and
the process woes that might follow such a request.   The working group
appears to have decided to try going down that path despite the potential
problems it presents, so I will say no more about that here.

He also wrote:

> In §1, "evidence indicates that '.home' queries frequently leak out and
> reach the root name servers [ICANN1] [ICANN2]", I don't think that's the
> issue.  The issue is that home is a well-known, in use TLD (we know
> because of those queries), and the consequences of reusing it are
> therefore completely unknown.


I updated this according to Ralph's suggestion, which I believe hit on the
same point.   Please let me know if you think further clarification or
deincorrectification is required.

New versions of these documents will be hitting the datatracker shortly.
If you feel that you had some comment that was not addressed, please let me
know: I did my best not to ignore what anybody said, but there was a long
thread, so I may have done so anyway.