Subject: Split the IANA functions?

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Jan 2014 11:20:47 -0500

Following up on Jari's post, I think it would be a prudent political move
to split the IANA functions so that assignment of IP addresses is separate
from the protocol registry functions. The motivation behind this is to
protect the IETF.

Like the DNS, the allocation of IP address space and BGP parameters is a
potential control point. It is thus an activity that is at the eye of the
storm as far as Internet governance goes. That can't be helped and isn't
our problem. Governments can and should argue over the governance of a
control point that could potentially cripple their economies if abused in a
trade war.

The allocation of protocol parameters is not a control point since there is
no enforcement mechanism. Nobody is going to take notice if IANA were to
ever refuse to register a content type or an algorithm under political
pressure.

So if Iceland develops its own word processor and wants to register the
content type, the US government cannot protect Microsoft from competition
by passing a law that tells IANA not to issue a content-type.
Alternatively, if the NSA was to instruct IANA to refuse to register code
points required by Brazil's new email security scheme the effort would be
an obvious waste of time.

Abusing control of allocations in the IP, DNS and BGP spaces would also be
difficult to maintain but the switching costs are much higher and the
outcome is not so obvious. That dispute is certain to continue.

The problem the current situation creates is that because half of the IANA
function intersects with IETF activities and half with ICANN type
activities, the combination brings IETF into the line of fire in disputes
where it can better serve all sides by being neutral.

There is already a defacto split since the IANA operates the protocol
registry under contract with IETF and the IP/BGP registries under contract
with the DoC. The IETF might propose protocol changes that would impact the
numbers registry but the same is equally true of ICANN. Similarly, the IETF
could de facto reserve chunks of IPv6 space (and in fact does still
controls 7/8th of the total space) just as it can de facto attempt to grab
TLDs if it chooses. But this is a consequence of the fact that it is much
easier to fork a chunk of namespaces than is generally admitted.

So splitting IANA in two would have little operational impact but ensures
that there is a clear boundary between the governance of Internet control
points which is clearly in ICANN space and the governance of Internet
standards which is clearly separate from it.

The only practical impact would be changing the name of the protocol
registry. It would still be maintained by the same people, etc. Since the
protocol registries are not only numbers, the name Internet Assigned
Registry Authority (IARA) would be more appropriate in any case.

Logically, the thing to do would be for ICANN to rename the IP/BGP side of
IANA but that would not have the same protective effect politically.

-- 
Website: http://hallambaker.com/

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Jan 2014 08:12:16 +1300

> from the protocol registry functions. The motivation behind this is to

Actually the reason we included explosive bolts in the IETF-ICANN MoU was
to protect the IETF in this way. (By "explosive bolts" I mean the unilateral
6 months notice.) I'm not sure why would need to blow the bolts in adavance
of an emergency.

> potential control point. 

The MoU contains no exception to IETF control for BGP parameters.
And to be clear, the IETF retains control of "assignments of domain
names for technical uses", so DNS asignments and IP address assignments
are on exactly the same footing: IANA functions where the IETF has
agreed that "policy issues are outside the scope of this MOU." That
is not the case for BGP parameters. Since AS numbers are not in short
supply, and are allocated by IANA upon "RIR request to the IANA or IETF
Review" I can't see why we would want to change anything.

    Brian

> It is thus an activity that is at the eye of the

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Jan 2014 14:58:44 -0500

> 6 months notice.) I'm not sure why would need to blow the bolts in adavance

I am not suggesting changing the operation of the registry or taking it
away from ICANN which is what I would see as 'blowing the bolts'.

I am suggesting painting a new sign for the protocol side of the functions.

The closest analogy I have is that in Vermont during hunting season it is
very common to find a cow with 'COW' painted on the side in big white
letters. The reason for this is that there is a particular type of 'hunter'
who comes up from the city once a year with his mates, a large quantity of
beer and an injudicious quantity of firearms and ammunition. They are
liable shoot anything that moves. Labeling the livestock is the best way to
mitigate the losses.

> Review" I can't see why we would want to change anything.

The vulnerability is to folk whose knowledge of the IETF and IANA is
equivalent to the weekend hunter types. It is important to take the issue
off the table.

---

From: John Curran <[email-masked]>
Date: Mon, 6 Jan 2014 15:51:16 -0500

On Jan 6, 2014, at 2:58 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> I am not suggesting changing the operation of the registry or taking it away from ICANN which is what I would see as 'blowing the bolts'.
> 
> The closest analogy I have is that in Vermont during hunting season it is very common to find a cow with 'COW' painted on the side in big white letters. The reason for this is that there is a particular type of 'hunter' who comes up from the city once a year with his mates, a large quantity of beer and an injudicious quantity of firearms and ammunition. They are liable shoot anything that moves. Labeling the livestock is the best way to mitigate the losses.
> ...

It is admirable goal, i.e. setup things so that the IETF is truly doing just technical coordination, 
and thus does not attract any government/policy attention... However, it does sort of presume 
that the "protocol development side" stays away from such public policy matters, does it not?

Alas, the success of the Internet actually preempts any reasonable chance of creating competing 
protocols and approaches that will achieve similar success - basic network economies make 
interoperability with (and therefore adoption of) IETF-specified protocols a near absolute 
requirement for successful global deployment.  For example, if the IETF decides that certain 
protocol should be encrypted by default, then governments have to live with that outcome;
 i.e. arguing that there is any meaningful workaround is specious.

What happens when the IETF makes a decision that particular "public policy" requirements 
are _to be considered_ (perpass), or specifically _not to be considered_ (RFC 2804) in protocol
development?   Such is the equivalent of exercising a "control point" (your term) on the Internet, 
and one that's entirely with respect to protocol development matters (not names or numbers).  
The fact that there is not an "enforcement mechanism" doesn't preclude the control point aspects; 
i.e. if there's an IETF consensus (quite appropriately) that pervasive surveillance activities are
"a technical attack that should be mitigated in the design of IETF protocols", then governments
are impacted by that public policy decision of the IETF. 

> The vulnerability is to folk whose knowledge of the IETF and IANA is equivalent to the weekend hunter types. It is important to take the issue off the table.

See above.  The IETF would also need to truly be neutral (and not imbed publicl policy values
into protocol requirements) in order to take the issue off the table.  Trying to separate the IANA 
tasks with the theoretical goal of technical purity thus would mean not advancing some fairly
important social values, and these already put the IETF into the cross-hairs due to the control
aspects.

/John

Disclaimer: My views alone.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 06 Jan 2014 22:45:08 +0000

On 01/06/2014 08:51 PM, John Curran wrote:
> development? 

I think that's a mis-characterisation. IMO both of those are cases
where there are sound technical reasons for the IETF to do, or not
do, work. Yes, those have impacts, but the public policy angle (if
that's the right term) is a side-effect and is not the reason for
the decision.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Jan 2014 17:58:50 -0500

On Mon, Jan 6, 2014 at 3:51 PM, John Curran <[email-masked]> wrote:

> > The closest analogy I have is that in Vermont during hunting season it
> is very common to find a cow with 'COW' painted on the side in big white

No, I am very aware of the public policy dimension in my protocol work. I
am in the security area, I remember the cryptowars.

The question that should be asked is why the IETF gets targeted in the way
W3C and OASIS do not. I think that the confusion of the IETF role in all
things ICANN is the main reason.

W3C and OASIS also do crypto work and the security area is actually rather
more likely than others to 'go walkabout'. There is no point in a
government trying to capture our standards forum because we can always
create another.

The much bigger problem has been the effect of governments trying to
promote security protocols inside IETF that are designed to meet government
security needs at the expense of the general good. I really don't care if
fixing OCSP would require the DoD to upgrade the certificate server they
use despite the fact that the supplier went out of business a decade ago.

As an industry we already get together and rewrite specifications that we
think are nonsense. PKIX says that name constraints MUST be marked
critical, the industry consensus and running code says that they are not.

---

From: <[email-masked]>
Date: Mon, 6 Jan 2014 23:03:39 +0000

Both perpass and RFC2804 are political reactions to the public environment.

To characterize either of them as technically motivated is disingenuous. Neither outlines
a technical approach.

>From RFC2804:
   These questions are believed to be irrelevant to the policy outlined
   in this memo.

See? policy.

>From draft-farrell-perpass-attack-03:

   The technical plenary of the November 2013 IETF meeting
   [IETF88Plenary] discussed pervasive monitoring (or surveillance)
   which requires the monitoring party to take actions that are
   indistinguishable from an attack on Internet communications.
   Participants at that meeting therefore expressed strong agreement
   that this was an attack that should be mitigated where possible via
   the design of protocols that make pervasive monitoring significantly
   more expensive or infeasible.  This Best Current Practice (BCP, see
   [RFC2026] Section 5) formally documents that consensus.

again, policy, pure and simple.

The usual claim that the IETF is a technical organisation that doesn't do politicics
is itself a disingenuous political position...

The public policy angle is the prime motivation for the existence of these
documents. It is not a side-effect.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Stephen Farrell [[email-masked]]
Sent: 06 January 2014 22:45
To: John Curran; Phillip Hallam-Baker
Cc: IETF Discussion Mailing List
Subject: Re: Split the IANA functions?

S.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 7 Jan 2014 00:14:06 +0100

I agree with you,

IETF should consider policies for designing protocols/technologies for
the public user community in all regions with diversity and fareness.
If the IETF still does not know how to solve attacks on the
internet/design/practice, so why will it allow separting related IANA
functions.

The first message in the thread suggests the motivation is to protect
IETF but what about protecting the Internet users in the world.

AB

On 1/6/14, John Curran <[email-masked]> wrote:
>> letters. The reason for this is that there is a particular type of
>> 'hunter' who comes up from the city once a year with his mates, a large
>> quantity of beer and an injudicious quantity of firearms and ammunition.
>> They are liable shoot anything that moves. Labeling the livestock is the
>> best way to mitigate the losses.
>> ...
>

---

From: John Curran <[email-masked]>
Date: Mon, 6 Jan 2014 19:16:35 -0500

On Jan 6, 2014, at 5:58 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> The question that should be asked is why the IETF gets targeted in the way W3C and OASIS do not. I think that the confusion of the IETF role in all things ICANN is the main reason.

You keep making that assertion, and I'll agree that the IETF is targeted more frequently
because of the policy aspects of its work.  That doesn't mean governments don't watch
the policy aspects of W3C (e.g. DNT), only that much less of that work has public policy
implications, and hence there are less mutual encounters.

Note - the other reason that IP and DNS names get more attention is because there are 
international treaty organizations which operate in apparently similar spaces, i.e. it's not
necessarily the result of actual interest by governments in the public policy implications 
of the IETF's work, but an expression of inter-organanization dynamics.  The W3C has 
not been honored with having any helpful friends similar in nature to the ITU and WIPO.

FYI,
/John

---

From: John Curran <[email-masked]>
Date: Mon, 6 Jan 2014 20:27:53 -0500

> that's the right term) is a side-effect and is not the reason for

Stephen - 
 
 I did not mean to imply that the primary driver was the IETF taking
 on a public policy matter; only that the decision being made (even 
 if on a sound technical basis) have real public policy implications, 
 and thus will attract interest of many non-technical parties, including
 governments.

/John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Jan 2014 16:15:58 +1300

>  and thus will attract interest of many non-technical parties, including

Of course, this has been true of every major technology innovation for
the last couple of thousand years, once the technology pervades society.
So we shouldn't be surprised or alarmed when public policy implications
of IETF technical decisions show up.

It's certainly true that in the current case, and the cases of RFC 1984
and 2804, there were public events and debates prior to the IETF taking
a position. I don't see why we should be worried by that either, as long
as we take technically based decisions that help the Internet work better.

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Jan 2014 07:02:34 +0100

Hi,

> that's the right term) is a side-effect and is not the reason for

Why do we state that confidentiality is important to pursue in our
protocols?  That is a political decision made by the community.  We then
layer on top of that decision technical requirements.  IMHO it's a very
important and good political decision.  We struggle with such decisions
all the time.  That there is a single root is both a technical AND a
political decision.  ICANN wouldn't be quite the political focal point
if there were a reasonable technical approach that scaled to the size of
the Internet that allowed for multiple roots.  As a community we know
this and have accepted it.

That pervasive surveillance can be used for good or bad reduces the
political element in as much as we're not saying any particular use is
good or bad.  That as a matter of IETF policy we may view it on the
whole as a bad thing is itself a political decision because it is
fundamentally tied to confidentiality and privacy (which is even more a
political area than confidentiality).

Nothing is wrong with making political decisions from time to time, when
it's important to do so, in order to see to a growing Internet that
provides benefit to the broader society.

Eliot
ps: I'll have more to say about perpass later today.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 06 Jan 2014 22:21:03 -0800

On 1/6/2014 10:02 PM, Eliot Lear wrote:
> political decision.

Almost any group decision can legitimately be characterized as 
"political".  The decision will favor some and work to the detriment of 
others.  Hence the decision has a component that can be classed as 
exercising "power".

But the reference to politics is distinctly unhelpful for the IETF. 
Whatever the knowledge and experience of our participants individually, 
as a group we lack meaningful, coherent language or practice with it.

What we do have is experience being guided by design criteria stated in 
terms of engineering politics, not social politics.  We tends towards 
greater efficiency, robustness, etc.  This include permitting use of 
various security-related mechanisms for authentication, confidentiality, 
etc.  Political language might cast that as saying that the IETF "favors 
protection of participant data".

But really we are simply taking directives from those who consume our 
work and we are trying to design solutions that satisfy the directives.

There is a community desire to create better participant protections 
from pervasive monitoring.  To be honest, there is also some community 
desire to /permit/ pervasive monitoring.  We choose to listen to our 
"customers" -- that is, those who buy and use what we produce -- rather 
than third-party actors who might favor ensuring that pervasive 
monitoring be made easy.

That choice can be classed as political, but really, we're just 
listening to our market...

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 7 Jan 2014 10:51:41 +0100

On 1/7/14, Dave Crocker <[email-masked]> wrote:

> We choose to listen to our

Who are the IETF customers? can be: a majority of diverse individual
users of the Internet, a minority of large organisations, and a
majority of small/medium organisations (all have different purposes,
not ignoring possible attackers).

> listening to our market...

What is/are the IETF market(s), or should IETF be getting fees from its markets?
Each world region has its own answers.

Political decisions is not the problem, it happens as output of any
organisation, the problem is that IETF is not diversified enough !!!

AB

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Jan 2014 08:18:17 -0500

> this and have accepted it.

It isn't the single technical root that creates the political focal point,
that would be quite easy to fix.

It is the uniform namespace that creates the political focal point, the
fact that a label has to resolve to the same resource in every part of the
net. That issue is then compounded by the entirely unnecessary and
unfortunate decision to introduce hierarchy at the root level. The problems
would have been much less if the only TLD was .com. That is, no CC TLDs, no
.NET, no .org, everything in one big bucket with the only hierarchy being
at the network level.

> political area than confidentiality).

The problem isn't 'politics'. The problem is the degree of specificity in
the decisions made.

The IETF is not deciding whether there will be passive surveillance in one
country but not another. All the IETF can do is to provide tools that
empower individuals to protect their own privacy and to empower providers
to protect the privacy of customers.

That is very different from the decision as to whether Muggins should have
their registrar affiliation withdrawn because Boggins claims that they are
a dirty filthy spammer.

There is a political element to all the work but the decisions to do with
IP address and BGP AS numbers and DNS numbers are very different in
character from the type of decisions IETF makes.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Jan 2014 09:44:12 -0500

On Tue, Jan 07, 2014 at 07:02:34AM +0100, Eliot Lear wrote:
> That there is a single root is both a technical AND a
> political decision. 

I have to disagree with this.  The uniqueness of the root is not a
political decision.  It's a fact of mathematics.  DNS is a tree.
There's one root.

Now, one might argue that choosing this kind of name space was a
political decision.  I might buy that argument (I don't know).  There's
good reason to suppose that there was at least some organizational
principle behind the decision in favour of a hierarchical namespace.
There were technical constraints too, I think: I don't believe a fully
peer to peer system was practical in the network environment of the
1980s.  But if we wanted to call anything that had non-technical
elements in it "political", then the selection of the DNS
(hierarchical) name space was in that sense political.

This is not to say that the single root doesn't have additional
political implications.  But I will not concede that this is some
contingent fact of the DNS that could be otherwise.  The particular
root we have could be different.  That there is a single root could
not.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Jan 2014 15:58:32 +0100

Andrew,

It's clear that I wasn't clear.  Deciding on a tree structure has
political implications, be that DNS, RPKI, or other (and there are
other).  To ignore those implications would be unwise.  They are weighed
against technical considerations, as always.

Eliot

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 7 Jan 2014 17:03:30 +0100

> against technical considerations, as always.

One have to go back to the basics for requirements of identifiers, and one of them has to do with uniqueness (others are persistence, human readability, lookup mechanisms, scale, stability, homogeneity, ability to do searches, inverse functions, and more...). Uniqueness can be local or global. And global uniqueness can in turn, if that is necessary, be done in an opportunistic way or a fool proof way. If one really need guaranteed global uniqueness and at the same time easy lookups (but not searches, inverse and other things) global distributed hierarchal allocation is a very efficient way of doing it.

What I think you say Eliot is that when one look at the requirements on whatever name space is designed, one have to take also political arguments into account. That I agree with.

But for some set of requirements, doing things in a different way than hierarchal delegated allocation is darn difficult. Instead one have to work around the political problems by (as you say) not ignoring them, but understanding the issues exist and design around them.

   Patrik

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Jan 2014 08:06:52 -0800

> principle behind the decision in favour of a hierarchical namespace.

As many folks remember, around 15 years ago, when ICANN was being 
formed, there was a strong constituency in favor of more than one root. 
  The problem with their arguments was that either their designs ensured 
chaotic name ambiguity, or they were simply moving the single root to an 
automated mechanism rather than an administered process.

So the 'political' decisions about the existing DNS technology have been 
such things as ensuring name uniqueness, administrative scaling and 
query scaling.  The design of the DNS and the design of its 
administrative structure derive from these operational requirements.

None of this is really 'political' in the way that people tend to use 
the term.  In practical terms, there hasn't been any choice.  No 
alternative design has been put forward that is viable at scale.

IMO, to be meaningfully political, a decision needs to represent 
meaingful choice among significantly different alternatives.

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Jan 2014 11:29:04 -0500

> political decision.  It's a fact of mathematics.  DNS is a tree.

It didn't have to be a tree, it could have been something else, we could
still change it.

You might think that there is no other possible technical solution but that
is a failure of imagination rather than a fact. It might even be the best
technical solution but the definition of 'best' is with respect to
requirements.

A lot of the 'technical' arguments that are made against demands made by
Russia, China, etc. are actually technical choices and it undermines our
position when people falsely claim that there is no alternative.

I am currently at a conference where Fadi Chehadé just talked about Russia
asking to host a root server and he led the audience to believe that there
could only be 13 servers. So I had to correct him and point out that Russia
already has a DNS server due to anycast and what we are actually arguing
about is a root service, an abstract construct.

There is of course no technical reason that the number of services is
limited to 13. We can have as many as there are institutions willing to run
them at an acceptable level of reliability.

Putin's technical advisor is probably telling Putin that the westerner's
claims of technical limitations are bogus and he would be right.

The argument against more root servers is political, not technical and the
politics are rather more complex than just 'should Russia have one'.

At the moment the root is small and the load relatively light. In fact the
legitimate load is essentially zero. The root zone could probably be
distributed as a flat file, it isn't large, it doesn't change very much.
Certainly it is nothing like .com. The only real issue in root server
management is dealing with the load from the DoS attacks which are awesome
in scale.

The main consequence of expanding the root zone is that the root zone
operators would constrain future development of the DNS. The root zone is
going to grow with the new TLDs. When the number of TLDs reaches a certain
point there will be a tipping point and there will be pressure to open up.

Having a hundred root operators would greatly constrain those changes, But
that might in part be why Russia and China want a seat at that table

> root we have could be different.  That there is a single root could

Uniformity of the name space is the essential criteria. The Web can't work
on UUCP bang path addressing.

Describing this as having a single root conflates a large number of issues
and essentially commits to a particular conclusion. A uniform namespace is
a requirement, a single 'root' is not.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Jan 2014 12:39:42 -0500

> It didn't have to be a tree, it could have been something else, we could

Gee, Phill, I love it when people elide the exact point I made when
selectively quoting, and then chide me for not having made that point.

Yes, it could be something else.  In the logically-possible world in
which I am a mud puddle, I spend less time responding to emails about
the nature of naming on the Internet.  But both the naming system on
the Internet and I (perhaps unhappily for one of us) exist in this
world.  The Internet as it stands uses the DNS, a tree-structured name
space.  A tree-structured name space has, by definition, a unique
root, due to the math in this universe.[1],[2]

> a requirement, a single 'root' is not.

I wasn't claiming a single root is a requirement for a uniform name
space; I don't care about that question.  I was suggesting that, given
that we have the DNS and it is the name system that is actually
deployed, we have right now a requirement for a unique root in that
name system.  If you want to make up a new non-DNS naming system and
deploy it and get the world to use it, please go nuts.  I have plenty
of complaints about the DNS and the way it works.  I suggest that the
history of IPv6 deployment prior to the actual exhaustion of the IPv4
number space gives us a pretty good lesson in the likelihood of non-DNS
global naming taking off without some killer feature.  In my opinion,
"Doesn't make Vladimir Putin grumpy," is unlikely to be the killer
feature that will cause people to change whatever invisible naming
system they use to bootstrap the applications on their tablets or find
Google or Bing.

Best regards,

A

[1] To acknowledge Avri's point elsewhere in this thread, yes, it is
possible to have a different CLASS with different RDATA at the name
owner name and RRTYPE.  The name space is still tree shaped with a
unique root, in that the owner names persist across all CLASSes.  This
is perhaps not quite as obvious as one would like in RFCs 1034, 1035,
and maybe 2181.  DNSEXT attempted to do something about this a few
years ago, but we didn't get any traction so we gave up. 

It is undoubtedly the case that there was some reason people didn't do
something about the difficulties with CLASSes.  One of the explanations,
of course, is that if we were going to fix the DNS at that basic a
level, we might as well replace it completely with something else that
doesn't have the properties we'd be trying to repair.

[2] I refuse to have a position on whether there is a logically
possible world in which mathematical tree structures do not by
definition have a single root.  Possible-worlds semantics over
mathematical proofs was probably too hard for me when I actually did
possible-worlds semantics work, and by now I've forgotten most of that
Latin.

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 07 Jan 2014 13:40:39 -0500

Eliot,
> important and good political decision.
Confidentiality is not an IETF-specific notion.  Long ago (mid-80's) the
ISO published a doc, ISO 7498-2, which describes security services and
mechanisms. That doc defines confidentiality as a security service, and
encryption as a mechanism that can be used to implement the service.

The same doc defines authentication, (data) integrity, access control
and other security services, with several variants of each service to
be more precise. It also includes a description of numerous security
mechanisms.  While 7498-2 is not perfect, it does demonstrate that a
large community (after all, it's an ISO doc) viewed these services as
generally desirable characteristics for communication systems. Thus
when the IETF says (as we did long ago in 3552) that confidentiality
(and authentication and integrity) are good things, we are consistent
with long-established principles that extend far beyond our standards
environment.

I see the political aspect of our current discussion as how we choose to
make tradeoffs between the security and privacy aspects of our protocols,
vs. other aspects of protocol design and network operation. Stephen's
doc does not address these tradeoffs in any detail. So, if we avoid terms
(near the end of the doc) that might appear to establish the rules for
evaluating these tradeoffs, we can make a statement that is not perceived
as political. Most means of effecting PM are attacks, as per 3552. This
ought not be viewed as a debate relative to our previous docs. I'd
prefer if this doc noted that, and explained what aspects of PM don't
neatly fall under the old threat model, thus providing a motivation for
a new threat model.  That way this doc can be seen a a simple statement of
the consensus from Vancouver, and an indication that the IETF has plans
to address concerns about PM, as established by the consensus.

Steve

---

From: Thomas Narten <[email-masked]>
Date: Tue, 07 Jan 2014 13:48:17 -0500

+1 to Andrew's comments.

To further emphasize a key point, the core issue is that the DNS *name
space* is hierarchical. That has nothing to do with roots and how
things are implemented underneath the covers. The name space itself is
hierarchical -- that is where the "mathematics" come in.

That means that someone or something has to decide what names are
allowed at the top of the hierarchy. That means you have to have some
entitity (e.g., ICANN) that says ".com" is OK, ".bozo" is not.

Sure, one can come up with all sorts of clever
schemes/algorithms/processes for deciding what names should be allowed
(and who owns them), but fundamentally, someone or something has to
decide (e.g., you need an ICANN). And I can guarantee you that no
matter how the decision is made, someone or some group will scream
"not fair", "corrupt", etc., etc. when they aren't able to get their
name.

So any talk about having a different/better naming scheme is really
just wishful thinking and a mostly a waste of everybody's time. If
there was a better system, some set of smart folk would surely have
already clued the rest of us in on what that was. Anyone remember Tim
Bass?

Thomas

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 7 Jan 2014 20:20:24 +0100

> already clued the rest of us in on what that was. Anyone remember Tim

On top of that (if you look at some arguments that "change is needed") I would like to know what the problem really is. And yes, I am happy(?) to, and have tried to, understand what the problem is.

As others have explained, often "the problem" has to do with misunderstanding of how Internet and DNS works. In other cases it has to do with real issues, like the actual decision making process for what strings can exist.

When knowing what the problem is, there is often not much disagreement on the fact improvements can be made. But more disagreements in what the best path forward is. But THAT discussion is much more fruitful and effective than just saying "things must change".

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Jan 2014 17:59:53 -0500

--On Tuesday, January 07, 2014 20:20 +0100 Patrik Fältström
<[email-masked]> wrote:

>> So any talk about having a different/better naming scheme is
>> really just wishful thinking and a mostly a waste of
>> everybody's time. If there was a better system, some set of
>> smart folk would surely have already clued the rest of us in
>> on what that was. Anyone remember Tim Bass?
> 
> On top of that (if you look at some arguments that "change is
> needed") I would like to know what the problem really is. And
> yes, I am happy(?) to, and have tried to, understand what the
> problem is.
> 
> As others have explained, often "the problem" has to do with
> misunderstanding of how Internet and DNS works. In other cases
> it has to do with real issues, like the actual decision making
> process for what strings can exist.
> 
> When knowing what the problem is, there is often not much
> disagreement on the fact improvements can be made. But more
> disagreements in what the best path forward is. But THAT
> discussion is much more fruitful and effective than just
> saying "things must change".

While agreeing with this and with most of Thomas's and Andrew's
comments, I think there are a few substantive problems that can
be easily identified and that keep coming back (I do not
consider arguments about who controls the root of a strict
hierarchy to be substantive, no matter how entertaining they
become).   Most of them are associated with expectations of the
DNS that it, as a strictly hierarchical system with one name per
node, one-way links, and fairly weak aliases, cannot satisfy.  

For example, we see repeated requests (or "requirements",
demands, or fantasies) about treating two (or more) names as so
identical that retrievals or actions that affect one of them
affect the others.  It is certainly within the state of the art
to do that in a strictly hierarchical  system.  Hierarchical
database and file systems with support for those relationships
have been around for close to 50 years if not longer.  But it
isn't a modification that can be patched into the DNS -- it just
isn't going to happen without replacing the DNS.  Some of the
people who make those requests can be educated; others prefer to
believe that, if only they repeat their demands often enough and
loudly enough, they will get their way.

Similarly, we see repeated requests (etc.) for search and
matching systems that are context-dependent based on either
locations in the hierarchy or hints/ specifications stored in
the hierarchy itself.  Again, it is possible to design a
hierarchical system to do that but almost certainly not possible
to retrofit it into the current DNS.  

There are other examples, typically involving other types of
search and matching procedures, that can't be done in the DNS
because they are incompatible with a strict hierarchy.  Using
them would either require replacing the DNS with something
entirely different (and probably less suitable for unique
identifiers of network objects) or layering a separate system on
top of the DNS (depending on one's perspective, it could be
argued that contemporary search engines serve that role and the
problem is solved).

I suggest that the things that these examples and others have in
common are:

(i) They cannot be realized within the DNS as we know it, even
if some hypothetical replacement system could accommodate some
or all of them.

(ii) Under the best of circumstances, deploying a replacement
system would be a long, slow, and painful process.  Independent
of the difficulty of deploying such a system (including thinking
through transition issues), it is almost certain that taking
advantage of the requested features of a new system would
require different parameters in the query/lookup process and
that would, in turn, require updating every application on the
Internet.

(iii) The people advocating the changes implied by those
examples are either ignorant of the reasons for (i) and (ii) or
aren't willing to admit to and deal with those reasons.

(iv) When we have tried to stimulate interest in the community
about various solutions and approaches, including the "above
DNS" ones that are, IMO, the most plausible from a deployment
and adoption standpoint, we generally discover that there isn't
any such interest, especially once people understand what would
actually be involved.

best,
   john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 7 Jan 2014 20:14:39 -0500

> node, one-way links, and fairly weak aliases, cannot satisfy.

That is a much better argument.

What I was trying to object to is the use of 'mathematical possibility' as
a slapdown as if the design of the DNS were so perfect that anyone
proposing an alternative approach is a complete fool.

That sort of argument can work inside IETF but it looks really bad when it
is made in an external forum where the audience does not start from the
same assumptions as to what is immutable fact.

The choices are constrained by the legacy technical infrastructure and the
requirements.

> loudly enough, they will get their way.

This is a better statement but the statement suggests that the problem is
only in the DNS infrastructure when the problem is also with the clients
that try to make lookups. For names to be useful, they have to work
predictably which means that at minimum they need to work the same with
every app on a given machine. Changes to the semantics of names will only
take effect after all the clients that perform recursive DNS resolution are
updated. And there are many of those now.

Yes, making two names look the same is also an example of the general cache
coherency problem, but Soviet science may believe it has an answer to that.

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 8 Jan 2014 08:06:00 -0500

Colleagues, 

On the DNS discussion generally: I respectfully suggest it tends to be more productive if we are careful with terminology, in distinguishing among different facets or aspects of DNS.

1.There’s no hard limit on the number of physical devices or diverse locations where we can put nameservers to provide the service (IP-based anycast). There’s probably a limit beyond which adding more service points adds to administrative overhead without improving the service. I haven’t done the math; I suspect someone has, most likely a large DNS or CDN operator. The constraints on where they're measurably useful are also driven by operational concerns like available connectivity, which in the case of the root are tied to the contents of the zone and other larger policy concerns but very indirectly.

2. There’s a functional limit in the DNS to how many NS records one can have for a zone. It may be meaningful to say that number is larger than 13 for the root, now, if one assumes widespread usefulness of EDNS0 (essentially, full penetration e2e of the ability to handle larger packet sizes than originally specified in the DNS, since we have to be careful about the implementation details of response truncation, packet sizes, etc.), but there’s still likely an upper bound. There are also protocol consequences to selecting which NS set to share for a zone as a subset of possible ones (answers won’t always be consistent). Those are protocol issues, and not specific to the root. (The operational limitation above is also relevant to the number of NS records/service points, in that at some point the nth new service point is measurably useful and the n+1’th isn’t.) This is primarily a matter of the DNS protocol, and the IETF is where people work on the protocol.

3. What people are usually talking about when they argue about “alternate roots” is not how many servers or how many named service points we can have, which are operational and protocol matters, but the namespace— what goes in the tree, where, with what characteristics, and who decides. And traditionally, this is where IANA is most directly involved, and generally where the strictly policy-based tussles ICANN engages in appear. The way we’ve structured DNS data, including certain of its key advantages, there’s one such namespace, and bad things (relative to the original requirements, which seem to persist to a very meaningful degree today) start to happen if it’s fragmented or inconsistent. As John's comments note, there are also other characteristics of the namespace, chosen early, that have had significant policy consequences. Some are easily separable from the on-the-wire protocol and operational considerations; some aren't. 

We can discuss any or all of these things in the context of IANA and the root, but I suspect that the discussion will be more useful if we make some distinctions among them. Otherwise we’ll continue to have a world where, for example, people believe that having control of a named service point for DNS resolution service for the root of the namespace gives them some meaningful degree of control over what’s in the namespace as it appears in the public or global context, even though as a matter of both protocol and operations, that’s simply not true.

It's also probably useful to have further discussion in another venue. The DNSOP WG is meant for discussions/work on DNS operational characteristics, scalability, best practices, etc. The DNSEXT WG is closed but there's still a mailing list, probably best suited for protocol discussion on DNS. 

best,
Suzanne

On Jan 7, 2014, at 8:14 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> What I was trying to object to is the use of 'mathematical possibility' as a slapdown as if the design of the DNS were so perfect that anyone proposing an alternative approach is a complete fool.
> 
> That sort of argument can work inside IETF but it looks really bad when it is made in an external forum where the audience does not start from the same assumptions as to what is immutable fact.
> 
> 
> The choices are constrained by the legacy technical infrastructure and the requirements.

---

From: manning bill <[email-masked]>
Date: Wed, 8 Jan 2014 13:07:12 -0800

Andrew, I think I will have to disagree with you in your over simplification.
There can be/ have been multiple roots in the DNS - HOWEVER, there is a always a single root _per class_.
One root for IN, one root for CH, one for HS,  etc…

These days, every class but IN is vestigial, so it is easy to conflate the IN class with the DNS as a whole.  

/bill  -picking nits-
Neca eos omnes.  Deus suos agnoscet.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Jan 2014 18:21:30 -0500

So that I don't have to keep replying to this off list:

> One root for IN, one root for CH, one for HS,  etc…

Right.  Except it turns out that CNAME and DNAME are specified in
terms of names and not name+class, so at the very least the class
boundaries are not as clean as we would like.

As you note, in any case, all anyone uses is IN.  

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 09 Jan 2014 07:06:22 +0700

Date:        Wed, 8 Jan 2014 13:07:12 -0800
    From:        manning bill <[email-masked]>
    Message-ID:  <[email-masked]>

  | There can be/ have been multiple roots in the DNS - HOWEVER, there is
  | a always a single root _per class_.

I'm not sure that's correct.   Nor do I know it is incorrect.  Classes
were (and are) so under-specified that exactly how they were intended to
work (if there was ever a clear and understood interpretation of that)
seems lost in the mists of time.

Another interpretation is that classes operate more like BIND's implementation
of views - that is allow different data for the same types in the same
namespace - except without requiring the server to guess bases on source
address of the query which set of data is required.

I am not even certain I am convinced whether the set of available types
is global, or varies per class, nor whether the same lookup algorithm applies
(does A == a in all classes?)  Probably, but who knows.

But even if you're correct, then conceptually, what is now isi.edu simply
becomes isi.edu.internet. (whether actually written that way or not) and
then the set of classes would become the "top level domains", and we're
back at a single tree, with a single root, that root being a list of all of
the classes.

There really is no way out of this - people wanting multiple roots really
just want to change who controls that rot - usually to someone they consider
friendly to themselves (like themselves) rather than someone that they consider
the enemy (ietf/iana/icann/...)

kre

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Jan 2014 06:50:31 -0500

--On Tuesday, January 07, 2014 15:58 +0100 Eliot Lear
<[email-masked]> wrote:

> Andrew,
> 
> It's clear that I wasn't clear.  Deciding on a tree structure
> has political implications, be that DNS, RPKI, or other (and
> there are other).  To ignore those implications would be
> unwise.  They are weighed against technical considerations, as
> always.
>...

Eliot,

In the hope of focusing the discussion a bit, I think it would
be more accurate to say that "having a tree structure...r
"having decided on a tree structure...".

It feels a little strange for me to be defending the DNS design
because I've never been a huge fan of some aspects of it, but a
little bit of insight into the context of those decisions may be
helpful.

I was not involved in the DNS design process, but I was doing
work on databases, including distributed databases, at the time
in the early to mid-1980s.  Against the backdrop of the database
state of the art at the time, if one started with design
criteria of approximately:

-- replacing the name-to-address and
	name-to-limited-supplementary-information functions of
	the Host Table without significant loss of functionality
-- having a hierarchical name structure (which does not,
	itself, imply a hierarchical database)
-- having something that could be administratively
	distributed at multiple levels of the name structure
-- having a distributed database that could be plausibly
	implemented without lock-commit-acknowledge or
	journal-based update facilities
-- having an arrangement that would facilitate local
	caching, not just for performance but as a mechanism to
	allow systems that were temporarily disconnected from
	all or part of the network to keep functioning reasonably
-- The result needed to be plausible for non-specialists
	to implement in a way that would interoperable.
	
Most of the above are documented in the various pre-DNS papers.
Most are also pretty obvious.  Given how bad some
implementations have been, there is a pretty good case to be
made that the design failed on the last criterion, but a
non-hierarchical alternative, especially given the then state of
the art, would have been much worse in that regard.

There just were not a lot of choices other than a hierarchical
database system.  The designers could have made some different
choices within the general hierarchical model, some of which I
hinted about in my earlier note.  I don't know if those
alternatives were even considered (and suspect most of them were
not).   But the decision to use a hierarchical model, again
given the state of the art, had to be pretty much determined by
those  design criteria.

I think a choice between something that meets the criteria and
is comparatively simple, robust, understandable, and
implementable and something that is much more complex and/or
that lacks robustness against network interruptions is an
engineering choice (and an obvious one).  One could argue that
it is political, but that requires arguing either that every
decision the involves either implementation or operational
economics or other operational issues is political.  

One could also argue that the criteria were wrong and that "no
central administrative or coordination function" should have
been a requirement.  But that requirement would be a very
difficult one technically even today and the environment at the
time -- IANA existed well before the DNS and was generally
trusted and the DNS design was a lot less centralized than its
predecessor-- just didn't call for it.  So, except with extremes
of hindsight about what we might like to have had today given an
evolution path that certainly could not have been accurately
anticipated at the time, I think it is hard to argue that the
omission of a "no central..." criterion was political at the
time.

Of course, one can say today that the technical/ engineering
decisions made then have political implications today but, given
the right set of conditions, that could be true of almost any
decision or fact, as the history of ignorant legislative efforts
to change PI or modify the speed of light amply illustrate.   It
doesn't retroactively make the decisions themselves political as
others have implied.

Finally, with regard to CLASSes just being treated as a another
level of the hiararchy, a sort of super-root... Again, I wasn't
there, no only not there for the DNS design effort but not
involved in the Chaosnet and Hesiod implementations that have
been the major examples of actually deployed and actively used
examples of CLASSes.  But it is clear to me from both reading
the specs and what little I know of those implementations that
kre is correct and the capability is badly underspecified.  I
think there are even some errors in what the spec does appear to
say.  But getting from there to either "there is a political
problem because CLASSes don't work" in the presence of
counterexamples to "don't work" or  "CLASSes just create another
level of the tree with the same properties in all CLASSes that
the CLASS=IN [sub]tree has" seems to me to be a huge stretch
that is not really justified by either implementation history or
the spec.

Just my opinion, of course.

best,
    john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Jan 2014 08:27:27 -0500

> that is not really justified by either implementation history or

+1

Some of the constraints on the DNS system are set by existing technology.

But some of the constraints are not and it greatly damages ICANN when I see
the head of ICANN making misleading technical arguments to claim that a
particular outcome is impossible as I saw on Tuesday this week.

When pressed he withdrew his original claim and announced that he has hired
the original architect of DNS to perform a thorough re-evaluation of the
architecture and design asking if things could be done differently.
Presumably because the original architects of Internet services are well
known for their enthusiasm for re-imagining and re-engineering their
deployed legacy designs.

Another variation of the bogus technical argument is 'we can't do X because
it would allow Russia to do Y and increase control.'

It may not be turned on all the time but we know that when it suits them,
Russia simply diverts traffic in Russia for ALL DNS root services to
servers of their own. They used that capability to effect during the
Georgia crisis.

When I was up at Oxford, Lord Marshall came to tell lies about the nuclear
power program. Papers released since during the attempt to privatize
nuclear power show that Marshall knew or should have known that the
technical arguments he was making were untrue.

Due to climate change we might actually need to build new nuclear capacity
but the incontrovertible fact that the UK establishment lied early and lied
often about the safety and economics of the program has created means that
the necessary level of trust is simply not there.

Technical arguments that can only be understood by experts are actually
weak ones.

Oh and one more thing. For years people have tried to ridicule my concern
that US control of ICANN might result in the Cuba or Palestine CC TLD codes
being dropped out of the root zone.

Anyone who has been following US politics this week will know that emails
from the private office of a Governor previously one of the frontrunners
for the 2016 presidential nomination prove beyond doubt that the Governor's
minions shut down part of the busiest bridge in the world for a petty act
of political revenge. While we can't do very much about the risk that a
person of that type would gain control of the NSA we can and should make
sure that the Internet institutions are protected against that type of
politician.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 09 Jan 2014 15:47:28 +0100

John,

Just to be clear, I was using DNS as an example.  We can always question
design decisions we've made.  I believe that Andrew and others may be
interested in doing just that, but not from the top down (as it were).

Eliot

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 9 Jan 2014 12:09:28 -0500

> seems lost in the mists of time.
<snip> 
> the enemy (ietf/iana/icann/...)

The fundamental problem with multiple namespaces we have now is "how does one express what namespace the name is in?"

Some people have tried to do this with postfix (eg. .onion or .local)
Others have said look first in namespace X then in namespace Y (MDNS)

Another signifiant problem is how to provide a programming interface to lookups in the new namespaces, 
for expediency people frequently start out by extending the functions that look up in DNS. 

Personally I think that if we want to to become serious about supporting multiple namespaces we need guidelines on:
	How new namespaces are identified 
	How to "register" namespace identifiers and operators of the namespace root (if applicable) as well as how names 
		are registered/selected in the namespace. I use the word register here loosely, as I do not know if anything other than 
	        centralized service will work to avoid conflicts. 
	On top of existing name lookup functions we need a multiplexer function that understands how to access 
		the namespace and calls appropriate lookup functions 
	Automated discovery of how to use new namespaces without this new namespaces will take a long time to deploy.
	How/If to support Meta Namespaces i.e. check a series of namespaces in either in a particular order and use first match OR
	       lookup in parallel in a number of name spaces. 

The difference in lookup function could be DNS vs  DNS for different class vs Distributed hash. 
In the first and second case we can in theory use the same functions but with different starting point and different cache (if one is present) 
in the third case a different function is needed. 

<potentially moving into solution space to make a point, this is NOT A FORMAL PROPOSAL> 

No matter how we do the identification of name spaces other than DNS in class IN, postfix IMHO is the wrong answer. 

One possibility is to use a prefix, something like GNU##freedom.eff     (## picked at random as separator) 
to express that lookup should take place in the namespace GNU for host freedom.eff.  
The advantage of a prefix is that it appears in a better location for a namespace multiplexing function when it is parsing the string and in theory
the namespace multiplexing function does not need to understand the rest of the string past the namespace identifier. 

Thus in this notation DNS###tools.ietf.org is the corresponding expression for looking up the host name: tools.ietf.org in class IN of DNS,

On a billboard or web page this would become either https://DNS##tools.ietf.org or DNS##https://tools.ietf.org depending if we put the
protocol or Namespace first. 

Working out a timeline to complete an effort to make all of this work is left as an exercise to the reader 

	Olafur

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Jan 2014 12:48:47 -0500

--On Thursday, January 09, 2014 15:47 +0100 Eliot Lear
<[email-masked]> wrote:

> John,
> 
> Just to be clear, I was using DNS as an example.  We can
> always question design decisions we've made.  I believe that
> Andrew and others may be interested in doing just that, but
> not from the top down (as it were).

Certainly we can, and should, question design decisions we've
made, if only to learn from them.  For the same reason, I also
think it is appropriate to review and question the goal and
constraint decisions that drive those design decisions

But I think two points are relevant when we start doing so:

(1) The observation that a decision may have political
implications -- at present or at some point in the future-- does
not make the decision itself political rather than technical.
For the IETF's work, political considerations are best
incorporated into goal and constraint spaces rather than leading
us into an argument about the basis on which those decisions are
made.

(2) Unless one is either trying to learn in the hope of doing a
better job on future designs or likes purely theoretical
discussions about the circumstances that would prevail in some
alternate reality, it seems to me that discussions of the
implications of trying to deploy redesigned versions of
something should be considered as part of the constraint space
for any results of questioning design decisions.   Our track
record for deployment of incompatible replacements for things
that work even moderately well has been, IMO, poor enough to
give us considerable pause if, e.g., someone proposes to take
"questioning design decisions" toward an effort to redesign,
reimplement, and redeploy the DNS.  My own hypothesis about that
is that the DNS we have is pretty much the DNS we are going to
have and that it would serve the broader community well if we
both accepted that and because more aggressive about saying "not
a good idea, find some other facility to use as a base" when
ideas come along that require violations of important principles
of the design.

best,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Jan 2014 08:13:45 +1300

> Working out a timeline to complete an effort to make all of this work is left as an exercise to the reader

Since it's an infinite regression (any N namespaces can be converted to a single
namespace by adding N unique suffixes or prefixes) I think the timescale
is infinite.

Seriously. We have a perfectly fine unambiguous namespace. Enough already.

   Brian

---

From: David Conrad <[email-masked]>
Date: Thu, 9 Jan 2014 11:40:52 -0800

> Seriously. We have a perfectly fine unambiguous namespace. Enough already.

The problem is that this issue keeps repeating, particularly in (shall we say) non-technical venues. In a private message I semi-seriously suggested someone should write an RFC that deprecates classes other than IN.  However, I'm beginning to think this might not be that bad of an idea -- at least there would be a document that the non-technical folks who keep raising the issue could be pointed at...

Regards,
-drc

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Jan 2014 13:03:35 -0800

> The problem is that this issue keeps repeating, particularly in (shall we say) non-technical venues. In a private message I semi-seriously suggested someone should write an RFC that deprecates clas…

I would propose exactly the opposite document: "Want your own namespace? Here are most of the known the pros and cons of owning your own DNS CLASS." Talk about the know pitfalls, but don't assume that those pitfalls are fatal for a given scenario. Give out the new classes liberally for a few years. The result might be someone else really does find good uses for them, and takes pressure of CLASS=IN for some things that really shouldn't be in the global Internet.

--Paul Hoffman

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Jan 2014 13:17:11 -0800

> The problem is that this issue keeps repeating, particularly in (shall we say) non-technical venues. In a private message I semi-seriously suggested someone should write an RFC that deprecates clas…

The premise to your line of thinking is that deprecating other classes 
will reduce these periodic demands for new name spaces.

One of the benefits of having had so many of these cycles of demands, 
over the last 15+ years, is that we can see that straightforward 
technical discussion and explanation does not dissuade the proponents. 
They want what they want and they reject information that counters what 
they want.

As I've become too fond of suggesting, the real requirement here is to 
move the work back onto those seeking the change.

      It is /their/ burden to do the work of proposing and specifying 
the change, in sufficient technical detail.

      It is /their/ burden to do the detail work of explaining how it 
can be viable.

      It is /their/ burden to recruit sufficient community support.

For the rest of us, the only burden is to put the burden back onto those 
folk.  Rather than saying "that won't work" and rather than trying to 
explain why it won't work, and rather than trying to narrow their 
opportunities for making criticisms, we merely need to recite some 
version of the above litany.

If they are so certain what they want is viable, they need to do the 
work of making it viable.

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Jan 2014 17:58:40 -0500

On Thu, Jan 9, 2014 at 4:17 PM, Dave Crocker <[email-masked]> wrote:

>> The problem is that this issue keeps repeating, particularly in (shall we
>> say) non-technical venues. In a private message I semi-seriously suggested
>> someone should write an RFC that deprecates classes other than IN.
>>  However, I'm beginning to think this might not be that bad of an idea --
>> at least there would be a document that the non-technical folks who keep
>> raising the issue could be pointed at...
>>
>
>
> One of the benefits of having had so many of these cycles of demands, over
> the last 15+ years, is that we can see that straightforward technical
> discussion and explanation does not dissuade the proponents. They want what
> they want and they reject information that counters what they want.
>
>      It is /their/ burden to do the work of proposing and specifying the
> change, in sufficient technical detail.
>
>      It is /their/ burden to do the detail work of explaining how it can
> be viable.
>
> opportunities for making criticisms, we merely need to recite some version
> of the above litany.
>
> If they are so certain what they want is viable, they need to do the work
> of making it viable.

+1

This is the way to deal with technical issues. Just lay out the facts and
make sure that every fact that is laid out is completely supportable.

When people draw the conclusion that 'X is impossible', people like me take
that as a challenge.

---

From: George Michaelson <[email-masked]>
Date: Fri, 10 Jan 2014 11:29:17 +1000

it is worth bearing in mind that the namespace of wide use before DNS was
email, and for many had already been made a tree. explicit hop-paths
persisted alongside initiatives like honey-danber and user@host forms, the
latter having adopted dot-separated labels under a tree form, well before
widespread adoption of port 53. almost all conversations around 'how do we
glue this external mail service in' wound up assuming a new top-level
domain such as .BITNET to create a clean tree entrypoint for an otherwise
unconstrained/unknown namespace.