PP3: The Architecting of Identifier Expansion

[Lisa Dusseault <[e-mail]>]

PP3

============================================================
The Architecting of Identifier Expansion
February 2008 APPS Area Architecture Workshop
============================================================
This text:  December 2007
Leslie Daigle.

----------------------------------------
Introduction
----------------------------------------

I'd like to take this opportunity to explore one particular
aspect of applications infrastructure architecture.  Namely,
I'd like to offer some commentary on, and foster discussion
about, the general approach to expanding Internet application/
identifiers to accommodate new uses.

----------------------------------------
First reality:
    Deploying new infrastructure is hard
----------------------------------------

Stepping back from the specifics of technology for a moment,
there is a larger question of what to standardize and/or
specify in order to facilitate and promote applications
that work in the global Internet.    That is, rather than
standardizing specific piece protocols, are there well
understood principles for what is deployable/not?  Do we
know what "application infrastructure" is?

A decade ago, the focus was on developing a directory service
(or services) and a stack of Internet identifiers -- uniform
names that lead to uniform locators that relied (often) on
the DNS for final resolution.

Global directories didn't pan out -- at least in part because the
need for globally interoperable access to (potentially) sensitive
data was not clear.  And the struggle over control of the one
successfully-deployed lookup infrastructure (DNS) was fostering
concerns over the notion of a centrally "controled" infrastructure
in a globally-dispersed network.  We're still working through
the ramifications of that today, as national governments express
concerns that their country's commercial reality is in some way
dependent on the US government's continued willingness to
support their DNS country code in the DNS root.  (It's a tortuous
argument, but that really is the line of logic).  We can see
the spillover of this problem when the French agitate to set up
a separate ONS root (for RFID-based supply chain management
infrastructure), on the argument that they need/want their own
control.  (The formally sanctioned root of the ONS global tree
is operated under contract by a US-based company.  There is no
formal relation to the USG the way there is for the DNS root,
but the argument is that any company is subject to its (home)
nation's government).  That is, whether or not we manage to keep a
single root in the DNS, the DNS-based global argument is spilling
into a general philosophy of "nationally-controlled infrastructure".

So, what does all this higher-layer politicking mean for applications
infrastructure architecture for the Internet?  An obvious and
already well-understood conclusion is that services must have
distributed control (peer to peer, etc).  However, it is also
worth recognizing that we are not about to dismantle or stop using
existing infrastructure services.  We're going to keep piling on
top of them, because it is very hard to get ubiquitous deployment
of new, cooperatively managed, infrastructure services.  this is
as true for DNS as for routing and addressing.


----------------------------------------
Second reality:
    Stretching existing infrastructure
    is painful
----------------------------------------

If deploying new infrastructure is hard, the next thing to
try is extending existing protocols, protocol elements, and
infrastructures.   There are at least  3 different types
of challenge in doing this well:

1/ the obvious challenge of compatibility within the
protocol(s) being extended;

2/ the equally obvious challenge of ensuring continued
compatibility on the wire if there is interplay between
servers/clients of different generations; and

3/ the somewhat less obvious issue of expectations
and dependencies that may have been built by unrelated
protocols and services.

For example, when Internationalized domain names were
discussed, the primary focus was on the first two
challenges. The implications of the 3rd are still being
explored:  should protocols that carry "domain names"
now  allow "internationalized domain names"?
The answer should be a clear "no", from a protocol perspective:
IDNs are strings of unicode characters.  *IDNA* representations
are valid domain names.

However, this consideration gets a little trickier
from a human usage point of view.  A slightly more
subtle version of the question is:  what label goes into the
distinguished name of an X.509 certificate domain component?
These are not resolved in the DNS, so they could be
IDNs, right?   If the use of the domain component is to show
the end user a domain and ask them to confirm it is the
domain they intended to access, the IDNA representation
is not likely to be useful.  However, it's probably
equally difficult for a machine to compute a comparison between
two IDNs, particularly once one factors in the various
equivalence tables supported by different top level domains.



----------------------------------------
Building Archaeologically:
    New layers on top of old ones
----------------------------------------

Maybe we can think of applications infrastructure in the light of
layering on top of existing systems in as clean a fashion as possible.
Applications infrastructure itself should evolve as applicatons'
needs do:  but deploying completely new infrastructure is always
a challenge, and  simply dumping more stuff into the existing one is
not a winning solution for technical and operational reasons.

If we want to layer, then we have to have well understood:
	. semantics at each layer
	. translation between layers

This is more or less the general theory behind
the basic Internet identifiers in the Internet protocol
stack -- and there's an expired IAB Internet-Draft by
Geoff Huston and others that provides a taxonomy of
the characteristics that define identifiers at a given
layer, as well as eventual dependencies between
the layers (draft-iab-identities, expired).

Do we need to take that to another level and formalize
the notion of the "presentation layer", allow the human-facing
identifiers to be more human, without perturbing the
functioning of machine processing of protocols?  And,
does this separation more than just a difference of
size of character set, and have more to do with
a difference of representation?

John Klensin proposed that approach in defining a "layer
above the DNS (draft-klensin-dns-search, expired); Michael
Mealling and I worked on framing a protocol that would support
just such a separation (draft-mealling-sls, expired).

 From the fact that I'm referring to a bunch of (long since)
expired Internet-Drafts, it should be clear that this
approach has not been brought to completion.  We got to
the point of development where it was perfectly clear
that the technology was not the challenge:  we could
provide a sound protocol/infrastructure proposal to
support the layer above the DNS approach to separating
"identifying things that are maybe network accessible"
from "identifying network things".    Instead, the
challenge was the apparent lack of will or interest
in deployment.


----------------------------------------
Questions for further exploration
----------------------------------------

The need to extend and expand Internet identifiers,
particularly with respect to supporting an internationalized
Internet experience, is not going to go away. And we
know that deploying new systems is (impossibly hard) and
extending existing systems is (unexpectedly) painful.

1/  Do we just keep muddling with extensions, putting
out fires where they appear, or can we take some architectural
step back and get ahead of the development curve?

2/ Is layering an answer?  Can start this discussion
from the perspective of looking at what does/not
work with the layer above DNS approach.