Subject: [Inip-discuss] Domain Names

From: Edward Lewis <[email-masked]>
Date: Thu, 3 Dec 2015 15:41:34 +0000

This message was originally sent to the iab mail list.  I'm repeating it
on this inip-discuss list to move the discussion to this themed list for
public discussion.

The original message:

As an outcome of work happening in the DNSOP WG, the work being the
addition of .ONION to the Special Use Domain Names registry and the group
looking to revamp the process for that registry, I researched the recorded
history of Domain Names and am working on a draft that can be found here:

https://tools.ietf.org/html/draft-lewis-domain-names-01

The draft isn't a completed work, its a start which I think needs
community review.  I'm looking to find the right place for it.  Despite
the seemingly natural fit to the DNSOP WG, I don't believe that is the
right fit.

I'm asking the IAB for it's opinion on whether this is a network
architectural issue or not.  I suppose the placement of the discussion
within the IETF is a matter for the IESG, so I'm not asking about that in
this message.  I only mention my qualms about DNSOP WG as a home as a
motivation to wonder if the problem is an architectural one or not.

What I've found, looking at the RFCs cited in the draft (as opposed to
IETF folklore, memories, mail lists), is that the idea of Domain Names
preceded the DNS.  There has never been a clear definition of Domain
Names, they have assumed the role of the basis for identifiers and are
used in many applications.  The DNS was built as an evolutionary
operational step, not as studied architecture for managing identifiers.

Is there a need to have an architectural understanding of how identifiers
are used across the internet's protocols?  The example of Tor's ONION
identifier (top-level name) pushes the point of how an identifier system
can follow the fuzzy definition of what a Domain Name is while yet
outright rejecting the management model of the DNS.  I'd once asked
(privately to a few, about 2 years ago) whether the DNS defines Domain
Names or do Domain Names define the DNS, in advance of this situation.  At
the time I don't think anyone understood my question.

I think, and I mean that as "think", there is a need to find a happy
medium where identifiers can be managed in different ways (DNS hierarchy
and zone admin vs. Tor's cryptographic basis) yet use similar syntax for
the purposes of sharing existing protocols (like HTTP) while using
different resolution processes.  The "victims" of not having a clear
direction are implementers of client applications that will have to juggle
different kinds of identifiers as well as those that implement lower (in
the software stack) layers that manage how an identifier is resolved.

Comments?

---

From: Warren Kumari <[email-masked]>
Date: Thu, 17 Dec 2015 21:04:55 +0000

Ed, I was wondering if you got a reply to this, perhaps off list?

So far yours is the only message on the list (other than the "welcome") -
it's still fairly unclear to me what the relationship is between this list
and the IAB program (is this a write only list? What is it supposed to be
commenting on / what output is there from the inip program (if any), what
is the relationship between that and the design team? Etc)

W
On Thu, Dec 3, 2015 at 10:43 AM Edward Lewis <[email-masked]> wrote:

> _______________________________________________
> Inip-discuss mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/inip-discuss
>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Dec 2015 21:14:48 +0000

I haven't had any responses.  (I did have a call with one person.)  I had
some comments come in after contacting the IAB, one of the comments directed
me to inip-discuss.

I have it in mind to look at some updates to my document before the 25th of
this month - from that date I'll be off-line for a few weeks.

Not sure the status of the list or of any program.  I do plan to think about
this as other priorities allow me.

On 12/17/15, 16:04, "Warren Kumari" <[email-masked]> wrote:

> So far yours is the only message on the list (other than the "welcome") - it's
> still fairly unclear to me what the relationship is between this list and the
> IAB program (is this a write only list? What is it supposed to be commenting
> on / what output is there from the inip program (if any), what is the
> relationship between that and the design team? Etc)
> 
> W

---

From: Gihan Dias <[email-masked]>
Date: Fri, 18 Dec 2015 21:15:02 +0530

On 2015-12-18 පෙ.ව. 2:34, Warren Kumari wrote:
>
> So far yours is the only message on the list (other than the 
> "welcome") - it's still fairly unclear to me what the relationship is 
> between this list and the IAB program (is this a write only list? What 
> is it supposed to be commenting on / what output is there from the 
> inip program (if any), what is the relationship between that and the 
> design team? Etc)
I too was waiting for the list to get populated and then active.

Could someone post the list ToR?

Gihan

---

From: Warren Kumari <[email-masked]>
Date: Fri, 18 Dec 2015 19:22:08 +0000

You mean this?:
"NIP-discuss is the public discussion list for Internet Names and
Identifiers Program. See the full description at
https://www.iab.org/activities/programs/names-and-identifiers-program/

The inip-discuss list is an open-subscription list, sponsored by the IAB,
intended to be an open venue for discussion of the topics covered in the
scope description for the IAB Internet Names and Identifiers Program (
https://www.iab.org/activities/programs/names-and-identifiers-program/).
These topics broadly include the use and evolution of naming systems for
the Internet, including but not limited to DNS and other protocols that use
domain names. Contributions will be covered by the IETF Note Well (
https://www.ietf.org/about/note-well.html).

The list is intended to provide input and perspective, at the architectural
level, to discussions in current or potential IETF, IAB, or IRTF activities
on the topics the Program was formed to address. It is not intended to
replace or supersede discussions in the IETF on specific protocol matters,
such as those addressed in the charter for the DNSOP WG. It is also not
intended to replace or supersede having a formal membership and
deliverables for the IAB program, which is managed at the discretion of the
IAB."
https://www.iab.org/mailman/listinfo/inip-discuss

The IAB page says (amongst other things):
"The program seeks to provide a useful framework for thinking about naming
and resolution issues for the internet in general, and to deliver
recommendations for future naming or resolution systems.

The scope of initial investigations is deliberately somewhat open, but
could include:

some basic terminology: what do we mean by "names," "identifiers," and
"name resolution" in the internet? What attributes of naming systems and
identifiers are important with regards to comparison, search, human
accessibility,
overview: where are naming protocols and infrastructure important to the
work of the IETF (and perhaps elsewhere)? Where is the DNS being used (and
perhaps stretched too far)? What other identifier systems are we coming up
with, and how well are those efforts working? This area will include
examination of some of the naming systems under development or in use
elsewhere, such as NDN, as a way of informing our thinking.
For protocols (inside the IETF or outside), what should protocol designers
know about re-using existing naming systems or inventing their own? Are
there guidelines we can usefully provide?"

Which leads to some of my confusions about how this related to the design
team vs discussions in dnsop, what the status of all this is, etc.

W

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Dec 2015 20:29:47 +0000

I'm not sure if that answers the question, but the pointers are helpful.  It
might seem odd that I posted to the list without knowing of this material,
but I didn't get on the list in a conventional way.

In the description on the program page, I see a reference to RFC 6055 "IAB
Thoughts on Encodings for Internationalized Domain Names" (I encourage the
use of document titles and not numbers if you want clarity!).  I don't think
that that document is the best starting point for the discussion.  It's
useful, but not the start.  For one, it's related to one use case - names
rendered in ways not compatible with the DNS (aka IDNs).  IMHO, any thinking
on this topic that starts with the DNS and pushes outward is like the
mindset that Copernicus fought - that is, people believed the Earth was the
center of the universe and tried to explain planetary orbital dynamics as
relying on the Earth as center of the frame of reference.  If we do that
we'll have really ugly formulas to predict where the planets will be seen in
the night sky.

The DNS is an outlying planet in this game.  The DNS supports a subset of
what could be called Domain Names, setting aside that there's never been a
formal definition of Domain Names.  Gathering up the uses of Domain Names in
various applications and protocols that have been reviewed in the IETF,
Domain Names aren't even the only way to create a naming system.  (Prior to
the maturation of the DNS there were many commercial attempts.)

The DNS by itself isn't a naming system.  As a protocol, it's a distributed
database that scales really well and manages to deliver answers quickly.
It's not so hot when it comes to it's data model and other features.  (In
the office yesterday, I used the analogy that one could transport a couch in
a two-seat convertible with the top-down, but there are better tools for the
job.  The DNS can do a lot, but it is strongest in just two areas.)

(It's always bothered me - a DNS name is a name, an address, and a route.
It's a name in the sense that in isolation, it denotes a unique thing.  It's
an address inside the DNS data model tree.  It's a route telling one how to
find the data in the servers, because you always start at the root.  Now in
naming system 'theory', the three are supposed to be different - names are
absolute, addresses are relative to the object's location, and routes are
relative to both the object and the seeker's position.  Somehow in DNS that
all collapsed, maybe now I am beginning to understand why.)

When I began working on the draft called Domain Names, I had to divorce
myself from believing the DNS was the origin of all of this.  After the
early research I realized that the DNS was more like, well maybe, Jupiter
than the Sun in the conversation to be had.

RFC 6055 is an important document in a survey of how identifiers using
non-ASCII characters are rendered into protocols that assume ASCII.  From an
architectural layering perspective, how a name is converted into the binary
transmissions is way down in the stack.  (When I wrote my draft and early
review convinced me to not go down that far in such a stack, which is why
this sticks out to me.)  I don't have a well cooked layer of stacks in mind
but I would say that figuring out how to convert the identifier from a name
to something useful (like a network address), that is, how to resolve the
name, is more significant.

I mentioned before the draft Domain Names.
https://tools.ietf.org/html/draft-lewis-domain-names-01  The draft is
incomplete because, "there's a conversation to be had."

On 12/18/15, 14:22, "Inip-discuss on behalf of Warren Kumari"
<[email-masked] on behalf of [email-masked]> wrote:

> You mean this?: 
> "NIP-discuss is the public discussion list for Internet Names and Identifiers
> Program. See the full description at
> intended to be an open venue for discussion of the topics covered in the scope
> description for the IAB Internet Names and Identifiers Program
> (https://www.iab.org/activities/programs/names-and-identifiers-program/).
> These topics broadly include the use and evolution of naming systems for the
> Internet, including but not limited to DNS and other protocols that use domain
> names. Contributions will be covered by the IETF Note Well
> (https://www.ietf.org/about/note-well.html).
> 
> level, to discussions in current or potential IETF, IAB, or IRTF activities on
> the topics the Program was formed to address. It is not intended to replace or
> supersede discussions in the IETF on specific protocol matters, such as those
> addressed in the charter for the DNSOP WG. It is also not intended to replace
> or supersede having a formal membership and deliverables for the IAB program,
> which is managed at the discretion of the IAB."
> "The program seeks to provide a useful framework for thinking about naming and
> resolution issues for the internet in general, and to deliver recommendations
> for future naming or resolution systems.
> 
> The scope of initial investigations is deliberately somewhat open, but could
> include:
> 
> some basic terminology: what do we mean by "names," "identifiers," and "name
> resolution" in the internet? What attributes of naming systems and identifiers
> are important with regards to comparison, search, human accessibility,
> overview: where are naming protocols and infrastructure important to the work
> of the IETF (and perhaps elsewhere)? Where is the DNS being used (and perhaps
> stretched too far)? What other identifier systems are we coming up with, and
> how well are those efforts working? This area will include examination of some
> of the naming systems under development or in use elsewhere, such as NDN, as a
> way of informing our thinking.
> know about re-using existing naming systems or inventing their own? Are there
> guidelines we can usefully provide?"
> 
> Which leads to some of my confusions about how this related to the design team
> vs discussions in dnsop, what the status of all this is, etc.
>  
> W
> 
> 
> 
> 
>

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 18 Dec 2015 16:05:30 -0500

Warren,

Thanks, you saved me the cutting and pasting on what we’ve published about the INIP program, IAB programs generally, and this list. I’ll skip to your more specific question:

> On Dec 18, 2015, at 2:22 PM, Warren Kumari <[email-masked]> wrote:
> 
> Which leads to some of my confusions about how this related to the design team vs discussions in dnsop, what the status of all this is, etc.

First— the IAB INIP program, and this list, have no direct relationship with “the design team” (I presume you mean the discussion of special use names in DNSOP), or the DNSOP WG, or any IETF WG. They’re defined by an area of interest for the IAB in the architecture of the internet (see the program description you quoted).

To expand on that a little bit— the IAB’s technical programs are there to provide input and advice to the IAB on issues for the architecture of the internet— things the IAB should (or even should not) be working on. They’re a supplement to the knowledge of individual IAB members, meant to persist beyond any individual IAB member’s term, and a mechanism for doing intensive work when specific areas are identified where the IAB and the larger community might benefit from coherent advice in a timely way. But unless a WG or AD ask, there’s no direct relationship at all between an IAB program and an IETF WG.

The IAB recently decided that all of the technical programs should have public, open-subscription lists, to make sure we’re getting the widest input possible on those topics if architectural interest and to support transparency in “what are the programs doing anyway?”

For this list in particular: When Ed first sent his email  about his draft to the IAB, he got several responses, including some discussion within the INIP program, at least one detailed review I know of, and a suggestion that the draft might be good as an IAB-stream RFC. He also got a suggestion that since the IAB has decided to spin up open lists associated with Program topics, he might want to seek review of his document and his ideas among like-minded folks on this list.

As the IAB lead for the INIP program, I’d be very, very happy to see review of Ed’s document and associated ideas here, especially towards an IAB RFC that might provide guidance to the wider community.

And if you have a related topic you’d rather discuss, please feel free. But if it’s on-charter for an IETF WG, it might be too narrow and specific to bring here.

best,
Suzanne
(also happy to have other IAB members chime in)

---

From: Gihan Dias <[email-masked]>
Date: Sat, 19 Dec 2015 10:46:46 +0530

On 15/12/19 2:35 AM, Suzanne Woolf
wrote:

Warren, Ed, Suzanne,

Thanks.

I read the INIP description, and my take is that the mandate of INIP
is to

1. Study the current use of names and identifiers on the Internet
(including, but not limited to the DNS)

2a. Identify issues with current naming systems - in particular
incompatibilities between various systems.

2b. Identify gaps (e.g. bidirectional aliasing, or better protection
for privacy, or context information such as localization or
administrative boundaries) in the existing naming systems.

3. Architect a set of naming systems for the Internet (assuming that
a single naming system will not suffice).

and the purpose of this list is to discuss the issues in a broader
audience than only the INIP members.

Do we have any other documents than the INIP
description and Ed's
Internet Draft ?

I will try to get my thoughts together and post something to the
list.

Gihan

---

From: Warren Kumari <[email-masked]>
Date: Sat, 19 Dec 2015 18:14:56 +0000

There are many, many documents, including, but not limited to:

0: Ontology Engineering: A Reality Check -
http://ontocom.sti-innsbruck.at/docs/odbase2006.pdf

1: draft-adpkja-dnsop-special-names-problem-00
Problem Statement for the Reservation of Top-Level Domains in the
Special-Use Domain Names Registry

2: RFC2826 - IAB Technical Comment on the Unique DNS Root

3: RFC3869 - IAB Concerns and RecommendationsRegarding Internet Research
and Evolution
mainly sections 3.2.1 on DNS and 3.2.2 on New Namespaces

4: The Namespace Research Group (https://irtf.org/concluded/nsrg )
4.1: draft-irtf-nsrg-report-10 - What's In A Name: Thoughts from the NSRG

5: draft-ietf-dnsop-alt-tld-03
The ALT Special Use Top Level Domain

6: RFC 7686 (was draft-ietf-dnsop-onion-tld)
The ".onion" Special-Use Domain Name

7: RFC6761 - Special-Use Domain Names

8: The minutes of the DNSOP Interim meeting in May 2015:
https://www.ietf.org/proceedings/interim/2015/05/12/dnsop/minutes/minutes-interim-2015-dnsop-1

9: RFC6055 - IAB Thoughts on Encodings for Internationalized Domain Names

10: RFC1034 - Domain names - concepts and facilities

11: The "Identification" section of W3C  Architecture of the World Wide
Web, Volume One -http://www.w3.org/TR/webarch/#identification

12: Much of "Namespaces in XML 1.0" -
http://www.w3.org/TR/REC-xml-names/#iri-use

13: Huge amounts of academic literature on naming systems, what names mean,
etc. Go poke a philosopher for fun here :-)

W

On Sat, Dec 19, 2015 at 12:16 AM Gihan Dias <[email-masked]> wrote:

> On 15/12/19 2:35 AM, Suzanne Woolf wrote:
>
> I read the INIP description, and my take is that the mandate of INIP is to
>
> 2b. Identify gaps (e.g. bidirectional aliasing, or better protection for
> privacy, or context information such as localization or administrative
> boundaries) in the existing naming systems.
> 3. Architect a set of naming systems for the Internet (assuming that a
> single naming system will not suffice).
>
> Do we have any other documents than the INIP description
> <https://www.iab.org/activities/programs/names-and-identifiers-program/>and
> Ed's Internet Draft
> <https://tools.ietf.org/html/draft-lewis-domain-names-01> ?
>
> I will try to get my thoughts together and post something to the list.
>
>
> Gihan

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Dec 2015 16:02:45 +0000

Acting on Olaf's permission, in trying to prepare another version of my
draft.

On 12/18/15, 7:05, "Olaf Kolkman" <[email-masked]> wrote:

>Feel free to forward to appropriate list.
>
>
>A Domain Name is a sequence of labels concatenated by a designated
>separating character.  The Domain Name Space is organized in a strict
>hierarchical manner with a recognized root Domain Name.  The
>organization follows the rules of tree structure as defined by the
>field of graph theory in mathematics [Diestel].
>
>
>That definition covers my street address:
>
>Olaf Kolkman
>Internet Society
>400
>Science Park
>Netherlands
>
>I think that the recursive character of a domain from RFC805 should be
>part of the definition.

This comment hits on the central item in the draft that begs discussion,
that is, a definition of Domain Names.

There are a few ways to attack the definition, in increasing order of
specificity (and perhaps not complete):

1 - The nature of the hierarchical arrangement of domains (embedded in the
recursive definition in RFC 805). The notion that there is a single root
to the tree and domains descend from that.  The notion of "right-to-left"
or "left-to-right" is insignificant, "top to bottom" is.  The components
of a domain's name are the labels from top to bottom (expressed in
whatever order is appropriate for the locality).  The syntax of the labels
are undefined or rather not specifically defined.  The means to extract
information indexed by the domain name is also not specifically defined.
Meaning - there has to be some implicit means of determining syntax and
resolution process.  Similarly, the management of the domain name is also
undefined.

2 - The look of a domain name being a sequence of labels from top to
bottom, separated by a dot character. This descends quickly from the
architectural plane and comes a long way to what client applications (like
SSH, FTP, Web Browser) will see from human user input.  The basic
definition is tied to ASCII but with punycode, Unicode strings can be
mapped in.  There is implicit signaling established for punycode results.
What is still a variable are: length of labels, management of labels, and
means to resolve.

3 - A definition that is (or starts with) aligned to that of the DNS.
There's a syntax defined, both for DNS domain names "on the wire" and in
zone file format, which is restricted for an era where acceptable
performance assumed fixed or constrained field lengths.  The DNS imposes a
centralized means of creating and managing names.

Of these definitions, the final is the most pragmatic and concrete but
perpetuates an ASCII-dominate view of the Internet and is tied to ancient
realities of technology.  Personally I don't like that and is why I refer
to starting with the DNS definition like "assuming the earth is the center
of the universe" and then mapping out the other planets' orbits.

But, this isn't about defining naming and identifier systems, it is about
defining a particular name and identifier system that (continues to)
foster reuse of software across various protocols.  Whether there is a
line drawn around the collection as "IETF" protocols or not is rather
unimportant in so much as it may not be feasible nor desirable to ever
draw such a line.

Where I see the situation heading is a "clarifications" on the topic.  The
ingredients for a clarification are - lack of a clear definition as
evidenced by a plethora of valid interpretations (which my draft has come
to build), a specific need to unify the concept to stem or reverse the
divergence (the 'crisis' over new entries to the Special-Use Domain Names
registry), and a willingness to realize that a clarification is inherently
a change to the base specification and some backwards compatibility pain
will likely be felt.  This latter point is one that has not been reached
yet.

If we proceed towards a clarification on the topic of Domain Names,
whether or not as names and identifiers, the next order of questions to
consider includes the next - as one example, but a significant example:

>When you say:
>different resolution processes.
>
>Then I would agree with you. The requirement that gets out of that is
>that there is a requirement to be able to fork the use of that identifier
>so that the application knows which resolution mechanism to take. Tor
>seems to be doing that based on a magic cookie in the form of the TLD
>label. Not sure if there are any other ways.

There are two ways to determine the means of resolution when given a name.
 One is implicit in the name, using, as an example, the top-level name
(note, I don't use top-level domain nor TLD), using that as a switch in
software that resolves names.  The other, obviously, is explicit, by
building into software knowledge of what kind of name is being handled,
e.g., using separate http schemes.

Personal opinion of mine feels that explicit means would cause greater
disruption than building in an implicit definition.  Explaining this gets
into how to solve this as opposed to an architectural discussion, meaning
it gets into how client software could be built to add "yet another layer
of indirection" when handling the resolution of names.

BTW, one implicit way to consider is having the top-level name "looked up"
within a newer version of a special-use domain names registry.  Limiting
the needed lookup key to the top-level name might or might not alleviate
concerns over so-called pervasive monitoring.  (I am not sure if that is
acceptable.)  Beyond that I can't dream of another scaleable and future
proof means, I mean a piece of software would hard-code in the rules for
an untra-privacy desiring naming system but that would not be inherently
scaleable.

(I don't know if extreme privacy can scale well.  One has to be very
careful if one wants to be anonymous.)