Review of draft-ietf-intarea-hostname-practice-04

Lionel Morand <lionel.morand@orange.com> Wed, 25 January 2017 13:28 UTC

Return-Path: <lionel.morand@orange.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E0D1298D3; Wed, 25 Jan 2017 05:28:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lionel Morand <lionel.morand@orange.com>
To: <ops-dir@ietf.org>
Subject: Review of draft-ietf-intarea-hostname-practice-04
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148535090022.6331.11990043554636926738.idtracker@ietfa.amsl.com>
Date: Wed, 25 Jan 2017 05:28:20 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ojuGZzewBu-a_UTur8L78_V9VXc>
Cc: draft-ietf-intarea-hostname-practice.all@ietf.org, int-area@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jan 2017 13:28:20 -0000

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.