On 1/25/2017 2:06 PM, [email protected] wrote: > Hi Tom, > > The definition in RFC 1594 was far better. > > A Fully Qualified Domain Name (FQDN) is a domain name that > includes all higher level domains relevant to the entity named. > If you think of the DNS as a tree-structure with each node having > its own label, a Fully Qualified Domain Name for a specific node > would be its label followed by the labels of all the other nodes > between it and the root of the tree. For example, for a host, a > FQDN would include the string that identifies the particular host, > plus all domains of which the host is a part up to and including > the top-level domain (the root domain is always null). For > example, atlas.arc.nasa.gov is a Fully Qualified Domain Name for > the host at 128.102.128.50. In addition, arc.nasa.gov is the FQDN > for the Ames Research Center (ARC) domain under nasa.gov. > > Unfortunately, this definition has disappeared in the RFC 2664 that has > obsoleted RFC 1594. > After investigation, I have failed to find a correct reference for the > definition in IETF documentation... which is weird, isn't it? I will add a reference to RFC 1983. Better than chasing which RFC is obsolete.
> As I said, this comment is a minor one and its applicability is broader than > the scope of the present draft. It is not intended to block its publication. > > Regards, > > Lionel > >> -----Message d'origine----- >> De : t.petch [mailto:[email protected]] >> Envoyé : mercredi 25 janvier 2017 18:46 >> À : MORAND Lionel IMT/OLN; [email protected] >> Cc : [email protected] >> Objet : Re: [Int-area] Review of draft-ietf-intarea-hostname-practice-04 >> >> Lionel >> >> On FQDN, would RFC1983 do? >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Lionel Morand" <[email protected]> >> To: <[email protected]> >> Cc: <[email protected]>; >> <[email protected]>; <[email protected]> >> Sent: Wednesday, January 25, 2017 1:28 PM >>> Reviewer: Lionel Morand >>> Review result: Ready >>> >>> I have reviewed this document as part of the Operational directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written with the intent of improving the >>> operational aspects of the IETF drafts. Comments that are not >>> addressed in last call may be included in AD reviews during the IESG >>> review. Document editors and WG chairs should treat these comments >>> just like any other last call comments. >>> >>> Document: draft-ietf-intarea-hostname-practice-04 >>> Category: Informational >>> >>> Summary: This document describes some of the protocols that leak >>> hostnames e.g. DHCP, DNS, mDNS. To solve this problem, this document >>> proposes to investigate the use of randomized hostnames instead of >>> static hostnames to overcome the existing privacy issues with hostname >>> leaking. >>> >>> Main feedback: >>> >>> This document is ready for publication. The document is simple, >>> well-written, with a clear and simple argumentation. It does not >>> promote a specific technical solution but advocates for further >>> investigations on the use of randomized hostnames instead of static >>> hostnames. >>> >>> Very minor comments below. >>> >>> ******************************************************** >>> >>> 1) In the section 1. Introduction >>> >>> There is a long established practice of giving names to computers. >>> In the Internet protocols, these names are referred to as >>> "hostnames" >>> [RFC7719] . Hostnames are normally used in conjunction with a >>> domain >>> name suffix to build the "Fully Qualified Domain Name" (FQDN) of a >>> host. >>> >>> [LM] it would be great if someone could also find a reference for the >>> definition of FQDN. For IETFer, it seems obvious but from the outside >>> world, it is not so crystal clear. Not related to this draft but it >>> could help. Hopefully, RFC 1983 is clear enough. >>> 2) In the section 4.5. DNS-Based Service Discovery >>> >>> Participating hosts publish a service described by an "instance >>> name," typically chosen by the user responsible for the >>> publication. >>> >>> [LM] >>> >>> s/by an "instance name," typically/ by an "instance name", typically >>> (--> coma out of the quotes) Yes. The RFC Editor will want that... >>> 3) Last paragraph of section 5 >>> >>> >>> Some operating systems, including Windows, support "per network" >>> hostnames, but some other operating systems only support "global" >>> hostnames. In that case, changing the hostname may be difficult if >>> the host is multi-homed, as the same name will be used on several >>> networks. Other operating systems already use potentially >>> different >>> hostnames for different purposes, which might be a good model to >>> combine both static hostnames and randomized hostnames based on >>> their >>> potential use and threat to a user's privacy. Obviously, further >>> studies are required before the idea of randomized hostnames can be >>> implemented. >>> >>> [LM] I would have put the last sentence of this paragraph in a >>> following stand-alone paragraph, as it is the general conclusion of >>> this section and of the document. OK, will do. -- Christian Huitema _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
