Subject: Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 18 Dec 2017 15:11:12 +0100

On Thu, Nov 30, 2017 at 01:36:00PM +0100,
 Martin Hoffmann <[email-masked]> wrote 
 a message of 297 lines which said:

> GLOBAL DNS -- FORMAT OF NAMES
> 
> | Names in the common display format are normally written such that the
> | directionality of the writing system presents labels by decreasing
> | distance from the root (so, in both English and C the first label in
> the | ordered list is right-most; but in Arabic it may be left-most,
> depending | on local conventions).
> 
> The first sentence makes it sound as if right-to-left languages would
> normally write ‘com.example’ which is not the case.

BiDI is complicated enough so I suggest we keep only examples where
the script of the domain name is the same as the parent script. This
way, sentences like "The TLD is at the end" are always true. Writing a
latin domain name in arabic is left as an exercice for the reader :-)

> under these circumstances the name will always be in the ‘usual’
> order.

I challenge this assumption. After all, numbers in arabic are
sometimes big-endian and sometimes little-endian (depending on wether
you are in the Middle-East or in North Africa).

> PRIMING
> 
> This comes a bit suddenly. Maybe it should start with a short
> introduction a la ‘In order to operate in recursive mode, a resolver
> needs to know the address of at least one root server.’

IMHO, the reference to the excellent RFC 8109 is sufficient.

> PASSIVE DNS
> 
> | A mechanism to collect DNS data by storing DNS transactions from name
> | servers.  Some of these systems also collect the DNS queries
> associated | with the responses.
> 
> I don’t think it has been defined yet, but the term ‘transaction’
> commonly refers to a pair of a query and its response (plus possibly
> any re-sent queries or responses due to packet loss). With this in
> mind, the second sentence doesn’t quite make sense.

I agree and I suggest this text:

Passive DNS:  A mechanism to collect DNS data by storing DNS
      responses from name servers.  Some of these systems also
      collect the DNS queries associated with the responses, although
      it raises some privacy concerns.  Passive
      DNS databases can be used to answer historical questions about DNS
      zones such as which values were present at a given time in the
      past, or when a name was spotted first.  Passive DNS databases allow searching of the stored records
      on keys other than just the name and type, such as "find all names
      which have A records of a particular value".

> IN-BAILIWICK
...
> Also, on behalf on non-native speakers, a short explanation of the
> origin of the term would perhaps be nice.

I like the Wiktionary (and it can be copied freely into a RFC):

Etymology
>From bailie (“bailiff”) and wick (“dwelling”), from Old English wīc.

bailiwick (plural bailiwicks)

    The district within which a bailie or bailiff has jurisdiction.

        The Bailiwick of Jersey.

    A person's concern or sphere of operations, their area of skill or authority. 

Synonyms

    (area or subject of authority or involvement): domain, department, jurisdiction, sphere, territory, turf.

---

From: Martin Hoffmann <[email-masked]>
Date: Tue, 19 Dec 2017 04:20:14 +0100

Stephane Bortzmeyer wrote:
> > | Names in the common display format are normally written such that
> > the | directionality of the writing system presents labels by
> > decreasing | distance from the root (so, in both English and C the
> > first label in the | ordered list is right-most; but in Arabic it
> > may be left-most, depending | on local conventions).
> > 
> > The first sentence makes it sound as if right-to-left languages
> > would normally write ‘com.example’ which is not the case.  
> 

RFC 5893 cleverly declares a "network order" and for it only speaks in
terms such as "previous" and "next" with regards to the order of octets
on the wire. This avoids the need for using left and right entirely
even though it is clear to a reader that "example" is previous to "com"
when written as "example.com".

That said, there seems to be a mistake in the text for the common
display format:

| so, in both English and C the first label in the ordered list is
| right-most

Previously this list was defined as being "ordered ordered by
decreasing distance from the root" which would make the first labal in
this list to be the left-most label in English.

> you are in the Middle-East or in North Africa).

I wouldn’t dare claim to understand the Unicode Bidi Algorithm, but it
seems to me that with the somewhat academic exception of names not
containing any ASCII letters and ignoring any shenanigans with explicit
overrides, domain names in common display format (that is, before
any possible IDNA processing) would always end up as a single
left-to-right run. 

Kind regards,
Martin

---

From: Richard Gibson <[email-masked]>
Date: Tue, 19 Dec 2017 02:09:28 -0500

> this list to be the left-most label in English.
Hmmm.
1. "Domain name" is defined as «an ordered list of one or more labels… 
identifying a portion along one edge of a directed acyclic graph» 
(presumably starting at the root).
2. In "Global DNS", "Composition of names" relies upon that same order: 
«in a fully-qualified domain name, the first label in the ordered list 
is 0 octets long… it is called the "root" or "root label"».
3. But then in "Format of names", the opposite order is specified: «The 
basic wire format for names in the global DNS is a list of labels 
/ordered by //*decreasing*//distance from the root/, with the root label 
last» and «The presentation format for names in the global DNS is a list 
of labels /ordered by *decreasing* distance from the root/» (emphasis 
mine) and «The common display format… is the same as the presentation 
format… in both English and C the first label in the ordered list is 
right-most». It makes sense if that last "ordered list" is the one from 
"Domain name" and "Composition of names", but not if it is the one from 
"presentation format", which I guess is the problem.

The initial graph-theoretic definition is accurate, but suggests 
(although notably does not require) an order backwards with respect to 
all three name formats. Perhaps everything would be more clear if those 
issues were eliminated right up front: «given a directed acyclic graph 
in which no node has in-degree greater than one, a domain name is a list 
of labels identifying a path in reverse (i.e., against the direction of 
the edges)» (the restriction on in-degree precluding child-to-parent 
directionality). For global DNS, the labels would then /always/ be 
ordered by decreasing distance from the root, hopefully eliminating 
confusion about how they appear in text or on the wire.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 21 Dec 2017 12:31:09 +0000

On 19 Dec 2017, at 7:09, Richard Gibson wrote:

> 1\. "Domain name" is defined as «an ordered list of one or more labels… identifying a portion along one edge of a directed acyclic graph» (presumably starting at the root).

I'm not sure why one would presume to start there.  As I read the following fragment
of RFC 1034, the list of labels explicitly starts at the node of interest and is read
towards the root.

    The domain name of a node is the list of the labels on the path from the
    node to the root of the tree.  By convention, the labels that compose a
    domain name are printed or read left to right, from the most specific
    (lowest, farthest from the root) to the least specific (highest, closest
    to the root).

Best regards,
Niall O'Reilly

---

From: Richard Gibson <[email-masked]>
Date: Thu, 21 Dec 2017 11:06:38 -0500

On 12/21/2017 07:31 AM, Niall O'Reilly wrote:
>     1. "Domain name" is defined as «an ordered list of one or more
>     labels… identifying a portion along one edge of a directed acyclic
>     graph» (presumably starting at the root).
>
> |The domain name of a node is the list of the labels on the path from 
> the node to the root of the tree. By convention, the labels that 
> compose a domain name are printed or read left to right, from the most 
> specific (lowest, farthest from the root) to the least specific 
> (highest, closest to the root). |
Two reasons why I presume edge direction to be away from the root: 
first, because it's consistent with the rest of the document in its 
current form (for example, the very next sentence after my quoted text 
describes how a fully qualified domain name "begins at the common root 
of the graph"), and second, because parent-to-child directionality is 
inherent to the DNS for delegations.

RFC 1034 seems to contemplate an undirected graph, so can happily use 
towards-the-root for domain names and away-from-the-root for 
delegations. But I don't think 7719bis has that luxury, because "domain 
name" should remain valid even in a "naming system" without a single 
common root.

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 21 Dec 2017 17:13:32 +0000

> I like the Wiktionary (and it can be copied freely into a RFC):

I like this suggestion.

As a native speaker of English (admittedly conditioned by the period
in which I acquired the language, by those who gave me instruction,
and by the literature to which I've been exposed), I'm wondering
whether it wouldn't be better to have "Bailiwick" as the head-word
in this repertoire of terminology, rather than having separate
entries for "In-Bailiwick" and "Out-of-Bailiwick".

In the English I learned, a hyphenated adjective such as "in-bailiwick"
can be used only as an attributive adjective (before the noun), and not
as a predicate or complement (after the verb).

Just as a five-year-old child is five years old (and neither five-years
old nor five years-old), so an in-bailiwick name is within the relevant
bailiwick, or is inside this bailiwick, or belongs to the bailiwick.
For me, all of these alternative expressions, none of which uses a
hyphen, are implicitly valid elements of the terminology in consequence
of including "In-Bailiwick".

I feel that having entries for "In-Bailiwick" and "Out-of-Bailiwick"
is unnecessarily prescriptive, and that a single entry for "Bailiwick"
would give sufficient clarity without unduly constraining the style of
future authors.

I hope this helps.

Best wishes for Christmas and the New Year, and apologies for being
late for Hannukah.

Niall O'Reilly

---

From: "Niall O'Reilly" <[email-masked]>
Date: Thu, 21 Dec 2017 19:17:40 +0000

> first, because it's consistent with the rest of the document in its current form (for example, the very next sentence after my quoted text describes how a fully qualified domain name "begins at the common root of the graph"),

But, as you pointed out in an earlier message, this depends on which portions of the rest
of the document you pick.  Under "Domain name" and "Composition of names" the order described
is away from the root, while under "presentation format", "wire format", and "display format",
the opposite is the case.

> and second, because parent-to-child directionality is inherent to the DNS for delegations.

That's an enticing analogy.  I'm not sure whether it's compelling.

> RFC 1034 seems to contemplate an undirected graph, so can happily use towards-the-root for domain names and away-from-the-root for delegations. But I don't think 7719bis has that luxury, because "domain name" should remain valid even in a "naming system" without a single common root.

I'ld be surprised, because of what I understood of how the development of 7719
was approached, to learn that 7719bis can be permitted to revise a foundational
document such as 1034.  I may be mistaken in this.

Best regards,

Niall O'Reilly

---

From: Richard Gibson <[email-masked]>
Date: Thu, 21 Dec 2017 15:31:00 -0500

> the opposite is the case.
The text is consistent in identifying "domain name" with "a list of 
labels ordered from parent to child", it's just confusing that wire 
format and presentation format are each /also/ "a list of [the same] 
labels" but ordered in reverse.
> document such as 1034.  I may be mistaken in this.
RFC 1034 defines domain name as "the list of the labels on the path… to 
the root of the tree" and references a /convention/ that labels "are 
printed or read… from the most specific (lowest, farthest from the root) 
to the least specific". I still think the original text applies to an 
undirected graph, so describing it in terms of a directed graph 
(specifically with edges from parents to children, as it is in the 
protocol) constitutes a clarification rather than a revision. That said, 
though, nailing down the ordering of domain name labels to /oppose/ the 
direction of such edges is most in accord with 1034 and seems like it 
would eliminate the most confusion in 7719bis.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Dec 2017 14:38:15 -0800

you guys are killing me with this thread.

<<The DNS namespace has a tree structure, where every node has a parent 
except the root node, which is its own parent. Nodes have labels that 
are from 1 to 63 characters long, except the root node whose label is 
empty. A domain is a node in context, and a fully qualified domain name 
has a presentation form that is just the node names, bottom up, with 
each followed by a period (.).>>

http://queue.acm.org/detail.cfm?id=1242499

---

From: Chris Thompson <[email-masked]>
Date: 22 Dec 2017 17:40:51 +0000

On Dec 21 2017, Paul Vixie wrote:

>except the root node, which is its own parent.

Well, that doesn't make sense already. Either the root node has no parent
(which seems to me to be the natural way to think of a tree structure), or
it is its own parent. They can't both be true.

-- 
Chris Thompson
Email: [email-masked]