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

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:ietfc@btconnect.com]
> Envoyé : mercredi 25 janvier 2017 18:46
> À : MORAND Lionel IMT/OLN; ops-dir@ietf.org
> Cc : int-area@ietf.org
> 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" <lionel.morand@orange.com>
> To: <ops-dir@ietf.org>
> Cc: <draft-ietf-intarea-hostname-practice.all@ietf.org>;
> <int-area@ietf.org>; <ietf@ietf.org>
> 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.
> >
> > 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.
> >
> > _______________________________________________
> > Int-area mailing list
> > Int-area@ietf.org
> > https://www.ietf.org/mailman/listinfo/int-area

_________________________________________________________________________________________________________________________

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.