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

From: John Levine <[email-masked]>
Date: 4 Jan 2010 17:21:43 -0000

>- 'Nameservers for IPv4 and IPv6 Reverse Zones '
>   <draft-jabley-reverse-servers-01.txt> as a Proposed Standard

By my reading, section 5 of this document asks IANA to delegate
IN-ADDR-SERVERS.ARPA and IP6-SERVERS.ARPA to a set of nameservers, but
it doesn't ask them to provide contents for the zones for those
domains, nor to redelegate IN-ADDR.ARPA and IP6.ARPA to the newly
named set of nameservers.

Are those deliberate omissions, is it supposed to be obvious, or is
something missing?

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 4 Jan 2010 15:26:53 -0500

> The document aims to specify the names of the nameservers to which 
> IN-ADDR.ARPA and IP6.ARPA can be delegated to, and nothing more.

OK.  Does that mean it'll take another RFC to do the actual delegation?

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Jan 2010 17:43:27 -0500

I'm not really particularly happy with Joe's two recent DNS drafts.

They give me the impression as a reader that a lot of context is being
hidden from me and that the implications of the draft are being
carefully obscured so that I as a reviewer not involved in the process
won't know what is going on.  I suspect the actual cause has more to do
with preventing arguments about goals when mechanisms can be agreed to
or writing minimal drafts.

However I find the documents difficult to review; I do not consider that
a good thing.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 4 Jan 2010 18:06:49 -0500

> or writing minimal drafts.

The above makes me pretty uncomfortable as a reader: you make what
sound like pretty damning accusations without the slightest argument
from any text.  If you don't understand some passage, say so.  If you
think you disagree with a possible entailment of a draft, say so.  As
near as I can tell, you're saying you don't understand the
implications of a draft, so you think they're bad drafts.  It could
just be that your expertise is not the relevant one for these drafts,
and therefore you don't have the necessary context to understand the
implications of something plain to those who do have that context.
But since you don't even say what things you don't find clear, it's
pretty hard to know.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Jan 2010 17:21:32 -0800

Hi Phil,

[Replying from [email-masked] rather than [email-masked], since the former is the address which is subscribed to the [email-masked] list.]

On 2010-01-04, at 16:46, Phil Pennock wrote:

> On 2010-01-04 at 06:08 -0800, The IESG wrote:
>> The IESG has received a request from an individual submitter to consider 
>> the following document:
>> 
> First an editorial nit, there's an arithmetic error.  Then a security
> nit.
> 
>   The non-compressed representation of A.IP6-SERVERS.ARPA fills (1 + 1)
>   + (10 + 1) + (4 + 1) + 1 = 19 bytes.
> 
> "IP6-SERVERS" is 11 characters long.  The encoded sequence is 20 octets,
> not 19.
> 
> This then leads into adjustments to the relevant table below, with
> {A-F}.IP6-SERVERS.ARPA totalling 40 octets.

Thanks!

> Security nit: the Security Considerations section states that there are
> no new security considerations.  This is false.  Currently, five diverse
> names control the top-level delegation and in the event of a major
> dispute, the geopolitical diversity of the chosen names means that one
> rogue actor can be partially inhibited by a split -- the same protection
> that was afforded by the original choice of root nameserver operators.

I think you are in part conflating consistency of name with appointment of nameserver operators.

The root zone is served by nameservers which are individually operated by twelve different organisations; however, they are all named under the single domain ROOT-SERVERS.NET.

ICANN anticipates a similar, multi-organisational approach to selection of nameserver operators for the reverse DNS zones. The details of that are out-of-scope for this document, but themselves are not choices that will be made unilaterally. Changes to infrastructural zones in the DNS such as the root and ARPA zones are subject to procedural oversight (e.g. as specified in the IANA Functions Contract) and incorporate widespread review.

> [...]
> 
> For the root zone, the actual NS records and glue used are widely spread
> amongst resolvers, so the same hijack is infeasible.

Note that this is not entirely true. The hints files (and the addresses specified within those hints files) are widely distributed amongst resolvers, but those addresses are only used for priming queries. The act of priming amounts to far more centralised distribution of addresses.

> [...]
> 
> This draft represents a change in the threat boundaries for a unilateral
> future power-grab over the reverse DNS.  I'm not deliberately impugning
> any of the current operators, ICANN or anyone else who reads this and is
> offended; organisations can be replaced, 5, 20 or 50 years from now and
> the centralised control remains.  Postel's dispersion of control should
> not be so readily undone piecemeal.
> 
> At the very least, surely this warrants discussion in the Security
> Considerations?

Capture of the reverse DNS without failure of systems and processes which control changes to the root zone would require collusion between all organisations responsible for serving IN-ADDR.ARPA and IP6.ARPA, and also of the process by which the ARPA zone is modified to change the corresponding glue records installed there (i.e. IAB, the IANA functions operator, NTIA and VeriSign).

Although the threat boundary is different in this case than in the status quo, it's not clear to me that the risk of capture is increased.

If you could recast your thoughts in light of my comments above, that would be instructive for me.

Thanks,

Joe

---

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

> I'm not really particularly happy with Joe's two recent DNS drafts.

If I can help clarify anything, please let me know.

> However I find the documents difficult to review; I do not consider that

If you could me more substantive guidance as to where the documents could be improved, I'd be very happy. As things stand the best I can do is say "I'm sorry" :-)

Joe

---

From: "John R. Levine" <[email-masked]>
Date: 4 Jan 2010 20:40:34 -0500

> If you could me more substantive guidance as to where the documents could be improved, I'd be very happy. As things stand the best I can do is say "I'm sorry" :-)

Well, OK.  Is there a plan to move the DNS for in-addr.arpa 
and ip6.arpa to the new set of servers?  If so, what is it?  Will it need 
more IAB or IETF action?

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Jan 2010 17:59:45 -0800

On 2010-01-04, at 17:40, John R. Levine wrote:

> Well, OK.  Is there a plan to move the DNS for in-addr.arpa and ip6.arpa to the new set of servers?  If so, what is it?  Will it need more IAB or IETF action?

There is a plan being developed to re-delegate IN-ADDR.ARPA and IP6.ARPA. The plan is being developed by ICANN in conjunction with the five RIRs. Work has been going on for some time, and the specification of the naming scheme for the servers (i.e. this draft) is one of the pieces of the puzzle that needs to be in place before the plan can be finalised.

I am happy to share the highlights of this plan here, since you asked, but please note that this is a draft proposal which has not yet been authorised for implementation, and hence all of this is subject to change.

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.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Jan 2010 18:04:45 -0800

> There is a plan being developed to re-delegate IN-ADDR.ARPA and IP6.ARPA. The plan is being developed by ICANN in conjunction with the five RIRs. Work has been going on for some time, and the speci…

To clarify my role in this, since I'm sending mail from a personal e-mail address for ease of procmail-use and exchange-avoidance, I work for ICANN as Director of DNS Operations, and I'm writing about this draft plan to re-delegate IN-ADDR.ARPA and IP6.ARPA wearing that hat. Apologies if that wasn't already clear.

Joe

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Jan 2010 22:23:03 -0500

>>>>> "Joe" == Joe Abley <[email-masked]> writes:

> I'm not really particularly happy with Joe's two recent DNS drafts.

    Joe> If I can help clarify anything, please let me know.

So, I think John is asking the questions well about the in-addr.arpa
plan.

For the sink.arpa, it would be good to explain why we want this name to
exist.  Also, if your goal is that applications not have special logic
for sink.arpa you should *say* that: I read the draft assuming that it
was free license to applications to start doing special things with that
name and was starting to put together lists trying to figure out what
special application semantics motivated the work.

I do believe both sets of questions should be answered in the drafts.  I
don't feel that strongly about it though; if the IESG would rather not,
that's fine with me.

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Jan 2010 20:45:53 -0800

> So, I think John is asking the questions well about the in-addr.arpa

OK. I hope the answers are helpful.

> exist.

We *don't* want the name to exist; that's the point of the draft. I presume that's what you meant?

>          Also, if your goal is that applications not have special logic

OK, that's good feedback. I can see how that's non-obvious, looking at the problem from an implementator's perspective as opposed to a registry operator's perspective.

> don't feel that strongly about it though; if the IESG would rather not,

Thanks for providing more information about your concerns; it was helpful.

Joe

---

From: "John R. Levine" <[email-masked]>
Date: 5 Jan 2010 00:50:51 -0500

> We *don't* want the name to exist; that's the point of the draft. I presume that's what you meant?

It would still be nice to put in an explanation of the motivation for 
adding SINK.ARPA when its semantics and operations, at least for clients, 
appear identical to whatever.INVALID.

>> for sink.arpa you should *say* that:

Yeah.  As far as I know, it is quite uncommon for applications to hard 
code treatment of .INVALID.  But you seem to be saying that they do, and 
that causes problems that SINK.ARPA would solve. Tell us what they are.

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Mon, 4 Jan 2010 21:58:34 -0800

On 2010-01-04, at 21:50, John R. Levine wrote:

> It would still be nice to put in an explanation of the motivation for adding SINK.ARPA when its semantics and operations, at least for clients, appear identical to whatever.INVALID.

I don't know that I have anything much to add to my previous answers to that question.

> Yeah.  As far as I know, it is quite uncommon for applications to hard code treatment of .INVALID.  But you seem to be saying that they do, and that causes problems that SINK.ARPA would solve. Tell us what they are.

I fear you may be confusing me with someone else. Where did I say that applications hard-coded special handling of .INVALID?

Joe

---

From: "John R. Levine" <[email-masked]>
Date: 5 Jan 2010 01:09:57 -0500

> I don't know that I have anything much to add to my previous answers to that question.

Well, at this point there seems to be no practical difference at all 
between the two, which returns to the question of why we need two 
different ways to do the same thing.

If the problem is that people are unfamilar with .INVALID, that would 
suggest an informational or BCP to tell people how to use names known not 
to exist.

R's,
John

---

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

On 2010-01-04, at 22:09, John R. Levine wrote:

> Well, at this point there seems to be no practical difference at all between the two, which returns to the question of why we need two different ways to do the same thing.

And again, I have no additional answers beyond the ones I gave before. I suspect the IESG have sufficient data on this particular point to be able to make their own decision without either of us repeating ourselves further.

Joe

http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=49793&tid=1262672174
http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=49795&tid=1262672094

---

From: SM <[email-masked]>
Date: Tue, 05 Jan 2010 03:34:34 -0800

At 06:08 04-01-2010, The IESG wrote:
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send substantive comments to the

Is what is proposed in this draft a matter of interest to the DNS 
Operations Working Group?  If so, the document could have been 
brought to the attention of the relevant working group before the 
Last Call.  That doesn't preclude the draft from being an individual 
submission.  The IAB Stream might be more appropriate though, given 
the area it covers.

The intended status of this draft is Standard Track.  As the proposal 
is about operations, BCP looks like a better fit.  The proposal could 
be fitted into an update of BCP 49, with the removal of the parts of 
RFC 3152 that have been obsoleted by RFC 3596.

Quoting the IANA Considerations section of RFC 3152:

   "This memo requests that the IANA delegate the IP6.ARPA domain
    following instructions to be provided by the IAB.  Names within this
    zone are to be further delegated to the regional IP registries in
    accordance with the delegation of IPv6 address space to those
    registries.  The names allocated should be hierarchic in accordance
    with the address space assignment."

And Section 4 of RFC 3172:

   'The IPv4 reverse address domain, "in-addr.arpa" is delegated to the
    IANA.  The "in-addr.arpa" zone is currently located on the same same
    subset of the root servers  as "arpa".  Sub-delegations within this
    hierarchy are undertaken in accordance with the IANA's address
    allocation practices.'

   'The "ip6.arpa" IPv6 reverse address domain uses a method of
    delegation that is the same as is used for "in-addr.arpa", where the
    "ip6.arpa" domain is delegated to the IANA, and names within this
    zone further delegated to the regional IP registries in accordance
    with the delegation of IPv6 address space to those registries'

Section 1 of this draft states that:

   "The choice of operators for individual nameservers is beyond the
    scope of this document, and is an IANA function"

That is once again repeated in the IANA Considerations Section of 
this draft.  I don't have any comment about that statement at this 
time except to say that it would be useful to know what IANA plans to do.

Although it may not be the intent of the authors of this draft to do 
so, the proposal may set the bounds of what the IETF can or cannot do 
in relation to RFC 2860.

Section 4 of this draft contains a (proposed) IAB Statement.  As this 
is a Last Call, I expect that the subject of this draft has come up 
in discussions between the IESG and the IANA liaison and that IAB has 
been informed.  There is no mention of the matter in IESG or IAB minutes.

Section 6 of RFC 3172 mentions that any new subdomain delegation must 
adequately document any security considerations specific to the 
information stored therein.  Irrespective of whether this proposal is 
about a new subdomain delegation of not, it would be informative to 
the reader if Section 6 of this draft did more than say that it 
introduces no additional security risks for the Internet.

Regards,
-sm

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 05 Jan 2010 07:41:14 -0500

At 00:50 05/01/2010, John R. Levine wrote:
>It would still be nice to put in an explanation of the motivation 
>for adding SINK.ARPA when its semantics and operations, at least for 
>clients, appear identical to whatever.INVALID.

There are two parts to this, the sink.arpa for all practical purposes
will function just like .invalid, the only difference is the name space
that the name resides in. According to RFC 3152 IAB recommends that arpa
be the domain for addressing and routing special needs.
Based on this it seems logical to set up a framework for any special purpose
names in there instead of the Root zone.

The ARPA domain can be tuned better to the needs of negative caching than the
root zone, having a negative caching of a week in ARPA will not cause 
any problems. Currently the root has one day, if in the future  there are
frequent adds/deletes of names in the root zone the operators may
want to lower that value.

>Yeah.  As far as I know, it is quite uncommon for applications to 
>hard code treatment of .INVALID.  But you seem to be saying that 
>they do, and that causes problems that SINK.ARPA would solve. Tell 
>us what they are.

There is one case where knowledge and special handling of the name may
cause problems:
   DNS "Liers" i.e. specialized DNS resolvers that make all
   non-existing name exist that do not generate "lie" for sink.arpa.

In this case the name can not be used as test of the resolvers truthful ness.
If an application knows about the name that is not a problem as all 
that will do is
to avoid a name lookup, and this is exactly the reason we want the name to be
have explicit semantics that can not change and are under IETF/IAB 
"control" not
ICANN's.

How sink.apra or other specialized names in ARPA can be used we leave 
to application
specialists.

         Olafur

---

From: "John R. Levine" <[email-masked]>
Date: 5 Jan 2010 10:37:26 -0500

> root zone, having a negative caching of a week in ARPA will not cause any 
> problems. Currently the root has one day, if in the future  there are

That's the first plausible argument I've heard.  (It's not overwhemingly 
persuasive, but at least plausible.)  It would be nice if it could be in 
the draft for future readers.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 5 Jan 2010 10:47:59 -0500

>> Yeah.  As far as I know, it is quite uncommon for applications to hard code 
>> treatment of .INVALID.  But you seem to be saying that they do, and that 
>> causes problems that SINK.ARPA would solve. Tell us what they are.
>

That strikes me as appropriate for a BCP, not a new domain.  The 
non-existence of .INVALID has been well-documented since RFC 2606 in 1999, 
and ICANN has agreed to follow IETF technical domain name assignments 
since RFC 2860 in 2000.  If you fear that people won't pay attention to 
those, why would they pay any more attention to a new document?

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 Jan 2010 08:00:19 -0800

Hi,

On 2010-01-05, at 03:34, SM wrote:

> Is what is proposed in this draft a matter of interest to the DNS Operations Working Group?  If so, the document could have been brought to the attention of the relevant working group before the Last Call.  That doesn't preclude the draft from being an individual submission.  The IAB Stream might be more appropriate though, given the area it covers.

We think the re-delegation of IN-ADDR.ARPA and IP6.ARPA is of great interest to dnsop and other operational forums outside the IETF, and as I mentioned yesterday the redelegation of both zones includes a communication plan intended to inform the operational community of the changes that are taking place. Those plans are still in draft form, as noted yesterday. We appreciate that there are likely to be some hard-coded references to the current NS RRSet for both zones which will behave differently following the change.

We had expected the naming scheme (just the naming scheme, not the redelegation) for the nameservers to stimulate less operational interest, and did not specifically publicise the document there. However, the existence of the draft was brought to the attention of the dnsop wg in a review posted there by Alfred Hoenes on 13 November:

  http://www.ietf.org/mail-archive/web/dnsop/current/msg07815.html

and that review fed some of the changes that appeared in -01:

  http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-jabley-reverse-servers-01.txt

I believe there was no other reaction to -00 by the participants of the dnsop wg, although it was a couple of months ago and perhaps my memory is faulty.

> The intended status of this draft is Standard Track.  As the proposal is about operations, BCP looks like a better fit.  The proposal could be fitted into an update of BCP 49, with the removal of the parts of RFC 3152 that have been obsoleted by RFC 3596.

The proposal is not directly concerned with operations, but with the procedural assignment of namespace under the ARPA zone. We were advised that the use of domains under ARPA in this way, per RFC 3172, required a standards-track RFC, hence this document.

We also considered simply registering a domain under NET or some other TLD, which would have led to a naming scheme that required no documentation in the IETF (although we might have written up an informational draft for the historical record). However, we think the application is well-suited to the ARPA TLD as described in 3172, the IAB did not disagree, and here we are.

> Section 4 of this draft contains a (proposed) IAB Statement.  As this is a Last Call, I expect that the subject of this draft has come up in discussions between the IESG and the IANA liaison and that IAB has been informed.  There is no mention of the matter in IESG or IAB minutes.

The text that appears in the document in section 4 was supplied to the document authors by the IAB following their internal review of the document. I know that people on the IESG are aware of it since I've talked to them, but I'm not sure I would expect that awareness to be reflected in telechat minutes.

> Section 6 of RFC 3172 mentions that any new subdomain delegation must adequately document any security considerations specific to the information stored therein.  Irrespective of whether this proposal is about a new subdomain delegation of not, it would be informative to the reader if Section 6 of this draft did more than say that it introduces no additional security risks for the Internet.

Unless someone can identify new security risks for the Internet that assigning these two names would cause, I don't know what other text could plausibly be included in section 6. If you have suggestions, I would happily read them.

Joe

---

From: Phil Pennock <[email-masked]>
Date: Mon, 4 Jan 2010 16:46:06 -0800

The draft centralises the naming and thus the choice of delegation and
so creates a new privileged operator.  Changing the delegation would no
longer require update to the NS glue in the ARPA zone; instead in
practice a change could be imposed by the operator, provided they can
live with inconsistent A/AAAA glue until the topic of dispute is no
longer disputed; given the complete control, this would almost certainly
be settled in favour of the de facto new state of affairs.

For the root zone, the actual NS records and glue used are widely spread
amongst resolvers, so the same hijack is infeasible.  For the GTLD
servers, there's one central registry in any case.  For the current
IN-ADDR.ARPA. servers, the root-servers.net values are used, which are
the same hosts for which there is a widespread dispersal of the current
correct IP addresses and for which change comes very slowly.

Regards,
-Phil

---

From: Sam Hartman <[email-masked]>
Date: Tue, 05 Jan 2010 16:44:56 -0500

>>>>> "Olafur" == Olafur Gudmundsson <[email-masked]> writes:

    Olafur> There is one case where knowledge and special handling of
    Olafur> the name may cause problems: DNS "Liers" i.e. specialized
    Olafur> DNS resolvers that make all non-existing name exist that do
    Olafur> not generate "lie" for sink.arpa.

    Olafur> In this case the name can not be used as test of the
    Olafur> resolvers truthful ness.  If an application knows about the
    Olafur> name that is not a problem as all that will do is to avoid a
    Olafur> name lookup, and this is exactly the reason we want the name
    Olafur> to be have explicit semantics that can not change and are
    Olafur> under IETF/IAB "control" not ICANN's.
I cannot parse the above.
I cannot tell whether you are saying  that those who wish to monatize
    Olafur> DNS error traffic (which I believe is part of the tag line
    Olafur> for a popular such service) should or should not return a
    Olafur> result for sink.arpa.
Nor can I tell whether you're saying they will do so.

I'm quite certain that if someone's business model depends on violating
this specification that they will do so.

It sounds like you're saying that you want a name to use to test and see
if you are getting bogus DNS responses but you're not willing to say
that in a spec.  If so, I think this will be ultimately ineffective and
I think it is misleading to publish a spec without explaining what it's
good for.

In summary, I'm not strongly objecting.  However I do continue to feel
that a clear explanation of what's going on here is not being provided
and that the uses as I understand them seem ineffective.  However this
clearly falls into the category of "mostly harmless".

---

From: SM <[email-masked]>
Date: Tue, 05 Jan 2010 16:55:40 -0800

Hi Joe,
At 08:00 05-01-2010, Joe Abley wrote:
>We think the re-delegation of IN-ADDR.ARPA and IP6.ARPA is of great 
>interest to dnsop and other operational forums outside the IETF, and 
>as I mentioned yesterday the redelegation

I apologize for the working group question.  I forgot that the draft 
was brought to the attention of the WG.

>  of both zones includes a communication plan intended to inform the 
> operational community of the changes that are taking place. Those 
> plans are still in draft form, as noted yesterday. We appreciate 
> that there are likely to be some hard-coded references to the 
> current NS RRSet for both zones which will behave differently 
> following the change.

I think that those (draft) plans could have been circulated before 
the Last Call.  Although I prefer something more substantive than a 
communication plan intended to inform the community, this may not be 
the right venue for me to make such a request.

>We had expected the naming scheme (just the naming scheme, not the 
>redelegation) for the nameservers to stimulate less operational 
>interest, and did not specifically publicise the document there. 
>However, the existence of the draft was brought to the attention of 
>the dnsop wg in a review posted there by Alfred Hoenes on 13 November:

In my opinion, it is helpful to have early reviews, i.e. before the 
Last Call.  This is a matter of author preference.

>I believe there was no other reaction to -00 by the participants of 
>the dnsop wg, although it was a couple of months ago and perhaps my 
>memory is faulty.

It is my memory that is faulty.   For what it is worth, the draft was 
brought to the attention of namedroppers yesterday by Paul Hoffman 
[1].  As an off-topic note, there's a problem with the namedroppers 
list archive for the year 2010.

>The proposal is not directly concerned with operations, but with the 
>procedural assignment of namespace under the ARPA zone. We were 
>advised that the use of domains under ARPA in this way, per RFC 
>3172, required a standards-track RFC, hence this document.

That requires the technical approval of the IETF.  The community 
consensus can be expressed through a BCP as the proposal calls for 
full and immediate instantiation.  The RFCs about the naming scheme 
have a checkered history (see RFC 3152, predecessors and 
successor).  It can be argued that it is suitable to use the 
Standards Track Maturity Levels because of the IP6.ARPA delegation.

>The text that appears in the document in section 4 was supplied to 
>the document authors by the IAB following their internal review of 
>the document. I know that people on the IESG are aware of it since 
>I've talked to them, but I'm not sure I would expect that awareness 
>to be reflected in telechat minutes.

A year or so ago, the IAB Chair mentioned that minutes are published 
so that anyone who wants to read them can do so.  There is an 
expectation, at this end at least, that the non-confidential 
information brought to the attention of the IESG and the IAB are 
reflected in their minutes for the awareness of the IETF 
Community.  As IAB statements are not the usual fare in RFCs, I think 
that it is worth a mention.

>Unless someone can identify new security risks for the Internet that 
>assigning these two names would cause, I don't know what other text 
>could plausibly be included in section 6. If you have suggestions, I 
>would happily read them.

 From Appendix A:

The NS RRSet for the IN-ADDR.ARPA zone at the time of writing is as
    follows:

      IN-ADDR.ARPA.         86400   IN      NS      A.ROOT-SERVERS.NET.
      IN-ADDR.ARPA.         86400   IN      NS      B.ROOT-SERVERS.NET.
      IN-ADDR.ARPA.         86400   IN      NS      C.ROOT-SERVERS.NET.
      IN-ADDR.ARPA.         86400   IN      NS      D.ROOT-SERVERS.NET.
      IN-ADDR.ARPA.         86400   IN      NS      E.ROOT-SERVERS.NET.
      IN-ADDR.ARPA.         86400   IN      NS      F.ROOT-SERVERS.NET.
      IN-ADDR.ARPA.         86400   IN      NS      G.ROOT-SERVERS.NET.
      IN-ADDR.ARPA.         86400   IN      NS      H.ROOT-SERVERS.NET.
      IN-ADDR.ARPA.         86400   IN      NS      I.ROOT-SERVERS.NET.
      IN-ADDR.ARPA.         86400   IN      NS      K.ROOT-SERVERS.NET.
      IN-ADDR.ARPA.         86400   IN      NS      L.ROOT-SERVERS.NET.
      IN-ADDR.ARPA.         86400   IN      NS      M.ROOT-SERVERS.NET.

    The NS RRSet for the IP6.ARPA zone at the time of writing is as
    follows:

      IP6.ARPA.             84600   IN      NS      NS-SEC.RIPE.NET.
      IP6.ARPA.             86400   IN      NS      SEC1.APNIC.NET.
      IP6.ARPA.             86400   IN      NS      NS2.LACNIC.NET.
      IP6.ARPA.             86400   IN      NS      NS.ICANN.ORG.
      IP6.ARPA.             86400   IN      NS      TINNIE.ARIN.NET.

The diversity of operators has some advantages, i.e. not sharing 
fate.  The Introduction Section of this draft mentions that "The 
choice of operators for individual nameservers is beyond the scope of 
this document".  I don't know whether a change of operators is envisioned.

I leave it to the authors of the draft to determine whether a 
reference to RFC 2870 is necessary given that the "secure and stable 
hosting of the IN-ADDR.ARPA and IP6.ARPA zones is critical to the 
operation of the Internet".

The text from RFC 3172 could be adapted as follows:

    The security considerations as documented in RFC 2870 apply to
    the operation of the nameservers for "IN-ADDR.ARPA" and "IP6.ARPA".

I suggest changing the following paragraph in Section 1:

   "The choice of operators for individual nameservers is beyond the
    scope of this document, and is an IANA function which falls under the
    scope of section 4 of the MoU between the IETF and ICANN [RFC2860]."

to

    The operational administration of the IN-ADDR.ARPA and IP6.ARPA zones
    is performed by the IANA under the terms of the MoU between the
    IAB and ICANN concerning the IANA [RFC2860].

Section 3 of RFC 3172 mentions that:

   'The "IANA Considerations" section should include the name of the
    subdomain, the rules for how the subdomain is to be administered, and
    the criteria for entries within the subdomain.'

I suggest changing the following paragraph in Section 5:

   "The choice of operators for all nameservers concerned is beyond the
    scope of this document, and is an IANA function which falls under the
    scope of section 4 of the MoU between the IETF and ICANN [RFC2860]."

to

    The operational administration of the IN-ADDR-SERVERS.ARPA and
    IP6-SERVERS.ARPA zones shall be performed by the IANA under the terms
    of the MoU between the IAB and ICANN concerning the IANA [RFC2860].

Regards,
-sm

1. http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03218.html

---

From: Joe Abley <[email-masked]>
Date: Tue, 5 Jan 2010 21:01:19 -0800

On 2010-01-05, at 16:55, SM wrote:

> The diversity of operators has some advantages, i.e. not sharing fate.  The Introduction Section of this draft mentions that "The choice of operators for individual nameservers is beyond the scope of this document".  I don't know whether a change of operators is envisioned.

There is no plan to eliminate diversity of operators for either zone. See:

  http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=49851&tid=1262753935

Joe

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 15 Jan 2010 11:07:58 +0100

>   <draft-jabley-reverse-servers-01.txt> as a Proposed Standard

Colleagues, Ron,

In the context of Joe Abley's reverse servers draft (draft-jabley-reverse-servers) there has been some discussion about the need for a standards track document for the delegation.

I was the IAB member that suggested Joe to follow standards track on the basis of my strict reading of RFC3172 section 3. I did so after considering whether an IAB stream document for this was sufficient. Unfortunately, when the appropriateness of the IAB statement (section 4) in Abley's draft was brought to the IAB list, the reference to the trade-off between STD-track and IAB stream was overlooked and not discussed timely.

After having seen the discussion on the list I believe that RFC3172 (2.1) is clear about the use of zones under .arpa within the context of protocol parameters (in-addr.arpa, urn.arpa, etc e164.arpa). The implementation thereof is described in section 3 of the document.

However in this case the argument has been made that the creation of a subdomain is done for purely operational purposes.

In the case of purely operational matters, such as redelegation of nameservers for specific domains, or DNSSEC signing of .ARPA, the IAB instructs or approves modifications in the .ARPA zone that need to be implemented by IANA.

This document is closer to describing an operational matter than a protocol matter and could have been treated differently -- as an IAB-stream informational RFC-- obviously after a "Call for Comments".  The current review is useful for transparency: having to explain clearly the 'why and how' is beneficial to everyone.

The point I am trying to make is one of setting precedent: A future IAB may make a different tradeoff between IETF Standards Track versus IAB-stream publication. In this case the coin dropped in the direction of Standards Track review.

Having made that point I want to share the observation that the document has no protocol elements as such. Publication as BCP instead of Standards Track would therefore be better. Another decision the IESG could make based on the last call comments is to hand the document back to the IAB for publication on the IAB stream. As far as timely publication of the material is concerned either path would do. I do not think the IESG would need more time if the document would be BCP instead of Standards track, nor would the IAB need a call for comments, as the discussion on this list has been thorough.

To be clear, we are where we are, and I personally do not think that any of these consideration should delay publication: the decision is currently with Ron.

--Olaf
  as IAB chair.