Subject: Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard

From: John C Klensin <[email-masked]>
Date: Tue, 05 Jan 2010 00:40:24 -0500

--On Monday, January 04, 2010 17:59 -0800 Joe Abley
<[email-masked]> wrote:

>...
> The draft plan is to re-delegate IN-ADDR.ARPA and IP6.ARPA to
> dedicated servers, named according to the text you have read.
> The servers are to be operated by the five RIRs plus ICANN,
> making six operators in total, consistent with the thinking
> that led to the current nameserver operators for IP6.ARPA.
> 
> The plan includes a timeline for the technical operations
> associated with the change, as well as communications with the
> root server operators, the RIRs, US DoC NTIA, VeriSign and the
> general public through operator mailing lists.
> 
> It is my understanding that re-delegation of IN-ADDR.ARPA and
> IP6.ARPA will follow procedures specified in the IANA
> functions contract, and will not require IAB or IETF action.

Ok, Joe, a few questions since, as indicated in another note,
you are generating these documents in your ICANN capacity:

(1) If ICANN can re-delegate the servers for these domains
without IAB or IETF action, why is IETF action needed to create
the new names?  They are, after all, just names.

(2) If IETF action is needed at all, why is this coming from you
as an individual submission, rather than as a formal request
from IANA to the IAB, presumably via normal liaison channels?
Ordinarily, and consistent with RFC 3172, this request would
come to the IAB and not via an individual submission to the IESG
since no "protocol entity" is involved?

(3) And why is this being processed as a Proposed Standard
rather than as a BCP (like other documents describing
allocations in .ARPA such as RFC 3152 (BCP49) and 3405 (BCP65))
or some sort of informational one?

(4) I also note that this document appears to update Section 4
of RFC 3172 but does not note that.  In addition, while that
Section 4 indicates, as of September 2001...

	"...The IAB is working with ICANN, IANA, and the
	regional registries to move "arpa" and "in-addr.arpa"
	records from the root servers in accord with the RFC
	2870 recommendation for exclusive use of those servers."

...the IAB has not been consulted on this issue (at least since
last March).

Writing/speaking for myself only, although with some personal
knowledge about the recent (and 2001) IAB involvement in this
area.

     john

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Jan 2010 22:00:14 -0800

> the new names?  They are, after all, just names.

We talked to people in the IAB about the idea of naming these servers using a consistent scheme under ARPA before we published -00. They were happy with the idea of using names under ARPA and indicated, following a review of 3172, that a standards action was required for the corresponding delegation.

> since no "protocol entity" is involved?

We discussed our plans with people in the IAB, and they advised us that an individual submission internet-draft was an appropriate path to take. We followed their advice.

> or some sort of informational one?

Members of the IAB advised us, with reference to RFC 3172, that a standards action document was required because a delegation from ARPA was being requested.

> of RFC 3172 but does not note that.

Section 4 of RFC 3172 describes the state of the ARPA zone at the time that 3172 was written. It is my understanding that updating that section with a document today would require access to a time machine, and my colleagues on the third floor indicate that time travel is not considered to be covered by the IANA Functions Contract.

>  In addition, while that

I am not aware of what work was being done in 2001 with respect to redelegation of IN-ADDR.ARPA and ARPA. I can only assume that the intentions documented in 3172 were not followed through for some reason.

Joe

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 05 Jan 2010 18:22:39 -0500

>you are generating these documents in your ICANN capacity:

John,
for the record, sink.arpa document was my idea and Joe volunteered to help
it has nothing to do with his day time job but is related to something that
Joe cares about, having explicit documentation of special cases.

>the new names?  They are, after all, just names.

Transparency ?

         Olafur

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Jan 2010 17:13:50 -0500

--On Tuesday, January 05, 2010 18:22 -0500 Olafur Gudmundsson
<[email-masked]> wrote:

>> without IAB or IETF action, why is IETF action needed to
>> create the new names?  They are, after all, just names.
> 
> Transparency ?

Transparency requires clear announcements and explanations, not
consultation and approval.  Please note the conditional on the
sentence as well: it wasn't "why should the IETF (or IAB) ever
be asked for an opinion", it was "if you don't feel obligated to
ask in some set of cases, where is the boundary and why?".   My
own view is that, consistent with 3172 (which may be now be old
enough in terms of ICANN and IANA evolution to be ripe for
review and possible updating) there are clearly some things
(e.g., subdomains that are created in support of particular
protocols) that require IETF review and action, other things
(e.g., externally-visible structural decisions) that require IAB
initiation and/or signoff, and probably still others which we
should trust IANA to just do something, get it right, and tell
us about in some reasonable way.  

I am extremely concerned about getting into a situation in which
the IETF spends time debating issues that are basically
minutiae, designing (or fine-tuning) procedures or naming
schemes in a committee of a few thousand.  A different way of
looking at the same concern is that most of us are able to
perform only a relatively small number of careful reviews of
standards-track documents a year and I'd like to see  that time
spent in areas and on documents that make the Internet work
better which, e.g., a choice of names generally does not.   I
don't want less review or less transparency; I want to see if we
can be more efficient about the time of both IANA staff
(including the calendar time it takes to get things done) and
that of the IETF community. 

In case it isn't clear, none of those concerns are specific to
this document.  They are about how to handle situations like
this ... and about how "like this" is properly identified.

     john

---

From: "John R. Levine" <[email-masked]>
Date: 9 Jan 2010 12:25:28 -0500

> Joe cares about, having explicit documentation of special cases.

In that case, could you work with him to add language to the draft that 
explains why SINK.ARPA provides something usefully different from 
FOO.INVALID?

The reason I keep harping on this is that this looks to me a lot more like 
a documentation problem than a technical problem.

R's,
John

---

From: Shane Kerr <[email-masked]>
Date: Mon, 11 Jan 2010 09:56:26 +0100

John,

> explains why SINK.ARPA provides something usefully different from 

The draft has this language:

   Various top-level domains are reserved by [RFC2606], including
   "INVALID".  The use of "INVALID" as a codified, non-existent domain
   was considered.  However:

   o  INVALID is poorly characterised from a DNS perspective in
      [RFC2606]; that is, the specification that INVALID does not exist
      as a Top Level Domain (TLD) is imprecise given the various uses of
      the term TLD in policy forums;

   o  the contents of the root zone are derived by interaction with many
      inter-related policy-making bodies, whereas the administrative and
      technical processes relating to the ARPA zone are much more
      clearly defined in an IETF context;

   o  the use of ARPA for purposes of operational infrastructure (and,
      by inference, the explicit non-use of a particular name in ARPA)
      is consistent with the purpose of that zone, as described in
      [RFC3172].

> a documentation problem than a technical problem.

The first bullet might be considered a documentation problem, but the
other two are not. You may not think they are valid, but that is a
separate discussion, right?

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Mon, 11 Jan 2010 10:21:24 +0100

John,

On Wed, 2010-01-06 at 17:13 -0500, John C Klensin wrote:
> schemes in a committee of a few thousand. 

*Getting* into a situation? The IETF spends a great deal of its time in
such activities, and has at least for the last 10 years or so (there may
have been a "golden age" before that, although it seems unlikely to me).

I think the reality is that there are certain technical issues that:

1. Are simple enough that everyone can understand them 
2. Have no completely obvious solution

These issues invite long, pointless threads discussing them.

Things that require a lot of time to understand the details tend to only
have a small handful of experts who discuss them, because there aren't
that many people who have the time and/or motivation to get up to speed.

Things that have a clear solution tend to only have a few net kooks who
argue (loudly, repeatedly, rudely) against this solution.

I think a number of process and other efforts have been made over the
decades to try to improve the signal-to-noise ratio of IETF discussions.
I don't know how successful these have been - perhaps the IAB has
metrics on this? I have no further proposals, except perhaps less
wringing of hands over the fact that we seemly waste a lot of time
arguing over not-so-important stuff.

Oh, and we might also remind people who have drafts caught up in a
vortex of endless nitpicking that it's not their fault, and there is
nothing wrong with their drafts. (Good luck Joe!) :)

--
Shane

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 11 Jan 2010 10:36:52 +0100

Shane Kerr writes:
>       as a Top Level Domain (TLD) is imprecise given the various uses 
>       of the term TLD in policy forums;

Hm. Then why doesn't this document supersede 2606's imprecise 
specification with a better one?

>       inter-related policy-making bodies, whereas the administrative 
>       and technical processes relating to the ARPA zone are much more 

That can be put that more clearly: "The IETF doesn't have sufficient 
authority over the root zone to publish 2606 and ensure its continued 
accuracy." My answer to that is that if so, then most of 2606 is 
broken, and it's necessary to much fix more than just the paragraph 
that defines .invalid.

>       is consistent with the purpose of that zone, as described in

Ie. if .invalid has to be dumped, the replacement should be in .arpa. I 
can accept that. _If_ it has to be dumped.

Maybe .invalid was a bad choice in the first place. But that's water 
under the bridge.

Arnt

---

From: Bill McQuillan <[email-masked]>
Date: Mon, 11 Jan 2010 01:54:44 -0800

> Maybe .invalid was a bad choice in the first place. But that's water 

My understanding was that the intended usages are slightly different: 

*.invalid could be used in places that if it accidentally got out onto the
internet it would do no harm to any legitimate domains. It was also
acceptable for a resolver to recognize that .invalid was "invalid" and
short circuit the DNS lookup.

sink.arpa seems to be intended to allow for recursive lookup and a proper
NXDOMAIN to be returned as normal. I think that it is specifically intended
NOT be treated specially by resolvers.

-- 
Bill McQuillan <[email-masked]>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 11 Jan 2010 07:44:31 -0500

At 04:36 11/01/2010, Arnt Gulbrandsen wrote:
>Shane Kerr writes:
>>    Various top-level domains are reserved by [RFC2606], 
>> including    "INVALID". The use of "INVALID" as a codified, 
>> non-existent domain    was considered. However:
>>
>>       as a Top Level Domain (TLD) is imprecise given the various 
>> uses       of the term TLD in policy forums;
>

That is a decent suggestion, not sure how well it will be accepted.
We tried to be much more precise in what sink.arpa is than invalid
specification.
My suggestion would be to say that any NEW uses of ".invalid" as a
non existing name MUST use sink.arpa. As for old uses if possible they
should migrate to sink.arpa. there is no inter operability issue
that I can think of only lag in changing code.
As for ".invalid" its intended use seems to be more of a "documentation"
use than protocol use.
Note:

As for ".invalid" the definition seem to me be more of a document
".invalid" is intended for use in on-line construction of domain
       names that are sure to be invalid and which it is obvious at a
       glance are invalid.

"Obvious at a glance" implies human to me.

>>       inter-related policy-making bodies, whereas the 
>> administrative       and technical processes relating to the ARPA 
>> zone are much more       clearly defined in an IETF context;
>
>authority over the root zone to publish 2606 and ensure its 
>continued accuracy." My answer to that is that if so, then most of 
>2606 is broken, and it's necessary to much fix more than just the 
>paragraph that defines .invalid.

I prefer not to do 2606 rewrite, I can agree to update 2606 saying
".invalid" SHOULD NOT be used on the wire.

>Ie. if .invalid has to be dumped, the replacement should be in 
>.arpa. I can accept that. _If_ it has to be dumped.
>
>__

Historical note: RFC2606 was done in hurry to get the names into document
before ICANN had really started to function.

Speculation: Even if the current ICANN is unlikely to allow wild card
in the root zone, that may change ==> ".invalid" suddenly exists.
IETF/IAB can prevent addition of wild card to .arpa.

Action: Next version of sink.arpa should say that .arpa MUST NOT
have a wild card as that will render sink.arpa. useless.

         Olafur

---

From: John C Klensin <[email-masked]>
Date: Mon, 11 Jan 2010 10:06:17 -0500

--On Monday, January 11, 2010 10:21 +0100 Shane Kerr
<[email-masked]> wrote:

>> I am extremely concerned about getting into a situation in
>> which the IETF spends time debating issues that are basically
> *Getting* into a situation? The IETF spends a great deal of
> its time in such activities, and has at least for the last 10
> years or so (there may have been a "golden age" before that,
> although it seems unlikely to me).

Well, yes.  I should perhaps have said "open up yet another set
of opportunities".

> 1. Are simple enough that everyone can understand them 

s/can understand/believes that they understand/

> 2. Have no completely obvious solution

s/$/ and, even if they do, that obvious solution, while
consistent with general understanding, raises complications or
issues that are not so easy to understand/

> Things that require a lot of time to understand the details
> tend to only have a small handful of experts who discuss them,
> because there aren't that many people who have the time and/or
> motivation to get up to speed.
> 
> Things that have a clear solution tend to only have a few net
> kooks who argue (loudly, repeatedly, rudely) against this
> solution.

My modifications above are intended to suggest that there is a
third case: a simple approach that seems to be a "clear
solution" to those who actually don't understand the issues (but
think they do) and that appears to raise other issues (if not be
outright wrong) to those who think they have a more in-depth
understanding of the issues and possible side-effects.   Where
we get into trouble isn't just the ranting, it is the
fundamental disconnect about what constitutes an adequate
understanding of the problem.

For this case, the community has traditionally given IANA a lot
of discretion about selecting particular names and numbers.
There are some important reasons for that, as well as just
avoiding noise.  Moving into a situation in which we require
IETF consensus for name selection or alteration is actually a
fairly big deal (having IANA consult the community to see if
anyone sees bad side effects is another matter entirely and both
reasonable and precedented).
 
> I think a number of process and other efforts have been made
> over the decades to try to improve the signal-to-noise ratio
> of IETF discussions. I don't know how successful these have
> been - perhaps the IAB has metrics on this? I have no further
> proposals, except perhaps less wringing of hands over the fact
> that we seemly waste a lot of time arguing over
> not-so-important stuff.

Let's save that discussion for another time, but I think it
would be safe to say that, typically, the community waits until
there is actually a crisis before making any significant changes
and then tends to get in a hurry and apply partial solutions
that end up causing new sets of problems.

> Oh, and we might also remind people who have drafts caught up
> in a vortex of endless nitpicking that it's not their fault,
> and there is nothing wrong with their drafts. (Good luck Joe!)
> :)

right.
    john

---

From: John Levine <[email-masked]>
Date: 11 Jan 2010 17:13:32 -0000

>specification with a better one?

Agreed.  The current bits on the wire for .INVALID, i.e., none, match
any plausible improved specification, after all.

>broken, and it's necessary to much fix more than just the paragraph 

Here's some proposed language which I believe accurately describes the
current situation:

   o  RFC 2680 documents a binding agreement between the IETF and
      ICANN with regard to the operation of the IANA.  In particular,
      Section 4.3 requires ICANN's management of the root zone to
      comply with the IETF's "assignments of domain names for
      technical uses", such as those described in RFC 2606.  Some
      people believe that ICANN or its successor may unilaterally
      break this agreement, although there is no evidence to support
      or refute this hypothesis.

>>       is consistent with the purpose of that zone, as described in

   o  Some people believe that ICANN is less likely to mess with .ARPA
      than with .INVALID, although there is no evidence to support or
      refute this hypothesis.

Also, based on recent mail here:

   o  DNS caches and proxies have in a few cases been observed to
      replace nonexistent names with synthesized records, typically
      the A record of a web server, in violation of standards and best
      practices.  Some people believe that noexistent names in .ARPA
      are less likely to be replaced than names in .INVALID, although
      there is no evidence to support or refute this hypothesis.

R's,
John