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

> On Jan 19, 2017, at 1:47 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> Here are my notes from updating the above two drafts.

Ted - thanks for the notes.  In general, I think you've addressed my comments and the document is ready to be forwarded to the IESG.  I do have one remaining small issue (see inline).

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

Ok.

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

Ok.

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

Ok.

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

I think this is almost right, but still misses the explicit requirement the "configured ... servers" be the servers in the home network.

Perhaps:

Name resolution APIs MUST send queries for such name to a recursive DNS server configured to be authoritative for the .homenet zone appropriate to the home network.  This RDNSS or list of RDNSSes will usually be supplied to the client through a local configuration mechanism like HNCP or DHCP.  If a host is configured to use a resolver other than one that is authoritative for the appropriate .homenet zone, the client may be unable to resolve or receive incorrect results for names in sub domains of ".homenet".

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

Ok.
>> 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.   :)

Ok.  I threw "RDNSS" in the text above, dunno which term is best.
> 
>> 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. 

Good catch and I agree with your new text.

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

Ok.

- Ralph

> 
> 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. 
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet