Subject: [Int-area] WGLC for draft-ietf-intarea-hostname-practice-02

From: Juan Carlos Zuniga <[email-masked]>
Date: Mon, 16 May 2016 12:33:29 -0400

Dear Int-Area WG,
 
A review of draft-ietf-intarea-hostname-practice has been published. Since there was wide support for this document from the beginning, and the document has now been reviewed, we believe it is ready for WG Last Call.
 
This email starts an Int-Area WG Last Call on:
 
https://tools.ietf.org/html/draft-ietf-intarea-hostname-practice-02
 
Please respond to this email to support the document and/or send comments by 2016-05-30.
 
In addition, to satisfy RFC 6702 "Promoting Compliance with Intellectual Property Rights (IPR)":
Are you personally aware of any IPR that applies to draft-ietf-intarea-hostname-practice? 
If so, has this IPR been disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)
 
Best,
 
Juan Carlos Zuniga & Wassim Haddad
(Int-Area WG co-chairs)

---

From: Dave Thaler <[email-masked]>
Date: Mon, 16 May 2016 21:01:49 +0000

I just found a couple typos, and suggest one potential addition below…

Grammar issue in -02:
>   Experiments on operational networks such as the IETF meeting network
>   have shown that with the help of external data such as the publicly
>   available IETF attendees list or other data sources such as LDAP
>   servers on the network can [TRAC2016], the identification of the
>   device owner can become trivial given only partial identifiers in a
>   hostname.

I believe the “can” immediately before “[TRAC2016]” should be deleted.

Section 4.4 grammar:
>    of a specific host on a network, by issuing a multicast requests to

s/requests/request/

Another variation of leakage is where a *unicast* (rather than multicast)
request is sent to a host in order to either ask it or its name(s), or ask it
whether it has a specific name.   Unicast queries are less discoverable by others
(e.g. IDS’s) than multicast queries are.   For example, mDNS and NetBIOS-over-TCPIP
[RFC1002] both support unicast queries to ask if the host has a specific name, and
the experimental [RFC4620] (probably not implemented in any real deployments)
has a unicast mechanism for asking for all names of a host.

Minimally, the section on “DNS Address to Name Resolution”, the
document might add a sentence to the end of that section like
“Other name lookup mechanisms, such as [RFC4620], share similar issues.”
Section 4 already says it’s a non-exhaustive list though, so it’s ok to leave it as is
if the WG prefers, but personally I think it would be useful to mention the class of 
unicast “ask the host” threats. 

Section 5 grammar:
> picks a random
> hostname and start publicizing that random name in protocols such as

s/start/starts/

typo:
> potential use and thread to a user's privacy.  Obviously, further

s/thread/threat/

Dave