Re: [Int-area] Review of draft-ietf-intarea-hostname-practice-04

[Christian Huitema <[e-mail]>]

On 1/25/2017 2:06 PM, [e-mail] 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:[e-mail]]
>> Envoyé : mercredi 25 janvier 2017 18:46
>> À : MORAND Lionel IMT/OLN; [e-mail]
>> Cc : [e-mail]
>> 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" <[e-mail]>
>> To: <[e-mail]>
>> Cc: <[e-mail]>;
>> <[e-mail]>; <[e-mail]>
>> 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