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

[Dave Thaler <[e-mail]>]

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