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

From: Lionel Morand <[email-masked]>
Date: Wed, 25 Jan 2017 05:28:20 -0800

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.

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)

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.

---

From: t.petch <[email-masked]>
Date: Wed, 25 Jan 2017 17:46:20 +0000

Lionel

On FQDN, would RFC1983 do?

Tom Petch

----- Original Message -----
From: "Lionel Morand" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, January 25, 2017 1:28 PM
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: <[email-masked]>
Date: Thu, 26 Jan 2017 00:06:12 +0000

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?

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-masked]]
> Envoyé : mercredi 25 janvier 2017 18:46
> À : MORAND Lionel IMT/OLN; [email-masked]
> Cc : [email-masked]
> Objet : Re: [Int-area] Review of draft-ietf-intarea-hostname-practice-04
> 
> Lionel
> 
> >    hostnames.  In that case, changing the hostname may be difficult if
> >    studies are required before the idea of randomized hostnames can be
> >    implemented.
> >

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 25 Jan 2017 17:27:38 -1000

> 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.

>>> Very minor comments below.
Hopefully, RFC 1983 is clear enough.
>>> (--> coma out of the quotes)
Yes. The RFC Editor will want that...
>>> this section and of the document.
OK, will do.

-- Christian Huitema