At 06:08 04-01-2010, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Nameservers for IPv4 and IPv6 Reverse Zones '
<draft-jabley-reverse-servers-01.txt> as a Proposed Standard
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf