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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf