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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
