Domain Name System (DNS) IANA Considerations
draft-ietf-dnsext-2929bis-07

-------- Original Message --------
Subject: Re: 2929bis
Date: Fri, 25 Jul 2008 09:25:28 +0200
From: Mark Townsley
To: Russ Housley , dnsext-chairs@tools.ietf.org, draft-ietf-dnsext-2929bis-06@tools.ietf.org
References: <484E8241.9020702@cisco.com>



Russ - you seem to be the only remaining discuss.

Chairs, Authors, I sent this email to you in June to no response. Please
work with Russ on answering his question, and let me know if there are
any other outstanding issues. I'd like to see this cleared before the
end of the meeting... Even before dnsext if we're lucky.

- Mark


Mark Townsley wrote:
>
>
> The only blocking issue is Russ' below, could we have a change here
> that the mailing list could be at ietf.org instead of iana.org? I
> should be able to handle that with an RFC Editor's note.
>
> Are we holding the document for anything else here?
>
> - Mark
>
>
>    Discusses and Comments
>
> *Lars Eggert:*
> *Comment:*
> *[2007-12-18]* Are we seeing RRTYPE registration requests at a volume
> that would require such an elaborate variant of the vanilla 2434bis
> Expert Review? (I'm wondering if this is process overkill - I have no
> idea how many RRTYPE registrations IANA gets.)
>
> *Russ Housley:*
> *Discuss:*
> *[2008-02-19]*
>  I am holding the discuss for IANA.
>
>  The IANA considerations call for a maillist to be created at iana.org.
>  I think we want it to be at ietf.org.  Please tell me why you think
>  the one at IANA is preferred.
>
> *Chris Newman:*
> *Comment:*
> *[2007-12-20]* I support Russ's discuss and trust him to hold it
> appropriately.
>
> I also observe that if the new registration procedures are deemed more
> heavyweight than the previous procedures, the likely community response
> will be to "route around" the registration procedures.
>
> I'm concerned with the use of "namedroppers@ops.ietf.org" as the
> review mailing list.  For list-review registries the expert usually has
> to manually sift through the archives to find the registration and the
> person performing the registration has to subscribe temporarily.  It
> may not be desirable to mix registration review with a technical
> discussion list to keep the noise down.  This would be more of a concern
> if list review was mandated for standards action (thankfully it isn't)
> as that requires an AD or shepherd to do the sifting, often months after
> the list review occurred.  Regardless, did the authors consider using
> a separate list?
>
>
>
>

[Note]: 'Spoke with dnsext chairs, Olafur says moving this forward is up to him. New expert reviewers have been selected and identified to IANA.' added by Mark Townsley

[Ballot discuss]
I am holding the discuss for IANA.

  The IANA considerations call for a maillist to be created at iana.org.
  I think we want it to be at ietf.org.  Please tell me why you think
  the one at IANA is preferred.

[Ballot discuss]
The IANA considerations call for a maillist to be created at iana.org.
  I think we want it to be at ietf.org.  Please tell me why you think
  the one at IANA is preferred.

[Ballot discuss]
I have not seen a response to Last Call comment from Sam Weiler.
  I am not saying that his suggestion needs to be followed.  I am
  saying that a response that the whole community can see is needed
  if his suggestion is not followed.
 
  Michelle Cotton spoke with both Olafur and Donald at IETF 70 about
  some suggested changes that IANA would like to see made.  These have
  not been handled yet.

[Ballot comment]
I support Russ's discuss and trust him to hold it appropriately.

I also observe that if the new registration procedures are deemed more
heavyweight than the previous procedures, the likely community response
will be to "route around" the registration procedures.

I'm concerned with the use of "namedroppers@ops.ietf.org" as the
review mailing list.  For list-review registries the expert usually has
to manually sift through the archives to find the registration and the
person performing the registration has to subscribe temporarily.  It
may not be desirable to mix registration review with a technical
discussion list to keep the noise down.  This would be more of a concern
if list review was mandated for standards action (thankfully it isn't)
as that requires an AD or shepherd to do the sifting, often months after
the list review occurred.  Regardless, did the authors consider using
a separate list?

[Ballot discuss]
I have not seen a response to Last Call comment from Sam Weiler.
  I am not saying that his suggestion needs to be followed.  I am
  saying that a response that the whole community can see is needed
  if his suggestion is not followed.

[Ballot comment]
Are we seeing RRTYPE registration requests at a volume that would require such an elaborate variant of the vanilla 2434bis Expert Review? (I'm wondering if this is process overkill - I have no idea how many RRTYPE registrations IANA gets.)

IANA Last Call comments:

Action 1 (Section 2.2):

Upon approval of this document, the IANA will make the following
changes in "DOMAIN NAME SYSTEM PARAMETERS" registry located at
http://www.iana.org/assignments/dns-parameters
sub-registry "Domain System Operation Code"

OLD:
Registration Procedure: IETF Standards Action.

NEW:
Registration Procedure: IETF Standards Action as modified by [RFC4020].


Action 2 (Section 2.3):

Upon approval of this document, the IANA will make the following
changes in "DOMAIN NAME SYSTEM PARAMETERS" registry located at
http://www.iana.org/assignments/dns-parameters
sub-registry "Domain System Response Code"

OLD:
Registration Procedure: (?)

RCODE Name References
----- ---- ----------
4096-65535 available for assignment
0x1000-0xFFFF

NEW:
Registration Procedure: IETF Consensus

RCODE Name References
----- ---- ----------
4096-65534 available for assignment
0x1000-0xFFFE
65535 Reserved, can only be allocated by [RFC-dnsext-2929bis-06]
0xFFFF an IETF Standards Action


Action 3 (Section 3.1.1):
Upon approval of this document, the IANA will make the following
changes in "DOMAIN NAME SYSTEM PARAMETERS" registry located at
http://www.iana.org/assignments/dns-parameters
sub-registry "In the Internet (IN) class the following Resource Record (RR)
TYPEs and QTYPEs are defined"

OLD:
Registration Procedure: Expert Review

NEW:

Parameter values specified in Section 3.1 above as assigned based on
DNS RRTYPE Allocation Policy are allocated by Expert Review if they
meet the two requirements listed below. There will be a pool of a
small number of Experts appointed by the IESG. Each application will
be ruled on by an Expert selected by IANA. In any case where the
selected Expert is unavailable or states they have a conflict of
interest, IANA may selected another Expert from the pool.

Some guidelines for the Experts are given in Section 3.1.2. RRTYPEs
that do not meet the requirements below, may nonetheless be allocated
by IETF Standards Action as modified by [RFC4020].

1. A complete template as specified in Annex A has been posted for
three weeks to the namedroppers@ops.ietf.org mailing list before
the Expert Review decision.
Note that partially completed or draft templates may be posted
directly by the applicant for comment and discussion but the
formal posting to start the three week period is made by IANA.

2. The RR for which a RRTYPE code is being requested is either (a) a
data TYPE which can be handled as an Unknown RR as described in
[RFC3597] or (b) a Meta-Type who processing is optional, i.e.,
which it is safe to simply discard.
Note that such RRs may include additional section processing
provided such processing is optional.

IANA shall maintain a public archive of approved templates.


Action 4 (Section 3.1):

Upon approval of this document, the IANA will make the following assignments
in the "DOMAIN NAME SYSTEM PARAMETERS" registry located at
http://www.iana.org/assignments/dns-parameters
sub-registry "In the Internet (IN) class the following Resource Record (RR)
TYPEs and QTYPEs are defined"

TYPE value and meaning Reference
---------- -------------------------------------- ---------
0 [RFC-dnsext-2929bis-06]
0x0000 -
RRTYPE zero is used as a special indicator for the SIG
RR [RFC2931], [RFC4034] and in other circumstances and
must never be allocated for ordinary use.

50 - 54 [RFC-dnsext-2929bis-06]
0x0032 - 0x0036 -
RRTYPEs in this range are assigned for data TYPEs by
the DNS RRTYPE Allocation Policy as specified in
section 3.1.1.

56 - 98 [RFC-dnsext-2929bis-06]
0x0038 - 0x0062 -
RRTYPEs in this range are assigned for data TYPEs by
the DNS RRTYPE Allocation Policy as specified in
section 3.1.1.

104 - 127 [RFC-dnsext-2929bis-06]
0x0068 - 0x007F -
RRTYPEs in this range are assigned for data TYPEs by
the DNS RRTYPE Allocation Policy as specified in
section 3.1.1.

128 - 248 [RFC-dnsext-2929bis-06]
0x0080 - 0x00F8 -
RRTYPEs in this rage are assigned for Q and Meta TYPEs
by the DNS RRTYPE Allocation Policy as specified in
section 3.1.1.

256 - 32,767 [RFC-dnsext-2929bis-06]
0x0100 - 0x7FFF
assigned for data RRTYPEs by the DNS RRTYPE Allocation
Policy as specified in section 3.1.1.

32,770 - 61,439 [RFC-dnsext-2929bis-06]
0x8002 - 0xEFFF
assigned for data RRTYPEs by the DNS RRTYPE Allocation
Policy as specified in section 3.1.1.

61,440 - 65,279 [RFC-dnsext-2929bis-06]
0xF000 - 0xFEFF -
reserved for future use. IETF Consensus required to
define use.

65,280 - 65,534 [RFC-dnsext-2929bis-06]
0xFF00 - 0xFFFE - Private Use.

65,535 [RFC-dnsext-2929bis-06]
0xFFFF - Reserved, can only be assigned by an IETF
Standards Action.


Action 5 (Section 3.1.4):

Upon approval of this document, the IANA will in the following
registry "DOMAIN NAME SYSTEM PARAMETERS" located at
http://www.iana.org/assignments/dns-parameters
create a new sub-registry "AFSDB RR Subtype Fields"

Initial contents of this sub-registry will be:

Decimal
Hexadecimal
Code Name/Description Reference
------- ------------------------ ----------------
0 [RFC-dnsext-2929bis-06]
0x0000 - Reserved, allocation requires IETF Standards Action.

1 [RFC-dnsext-2929bis-06]
0x0001 - Andrews File Service v3.0 Location Service [RFC1183].

2 [RFC-dnsext-2929bis-06]
0x0002 - DCE/NCA root cell directory node [RFC1183].

3 - 65,279 [RFC-dnsext-2929bis-06]
0x0003 - 0xFEFF - Allocation by IETF Consensus.

65,280 - 65,534 [RFC-dnsext-2929bis-06]
0xFF00 - 0xFFFE - Private Use.

65,535 [RFC-dnsext-2929bis-06]
0xFFFF - Reserved, allocation requires IETF Standards Action.


Action 6 (Section 3.2):

Upon approval of this document, the IANA will make the following
changes in the "DOMAIN NAME SYSTEM PARAMETERS" registry located at
http://www.iana.org/assignments/dns-parameters
sub-registry "Domain System Class"

OLD:

Decimal Name References
--------- ---- ----------
0 Reserved [IANA]

2 Unassigned [IANA]

5-253 Unassigned [IANA]

256-65534 Unassigned [IANA]
65535 Reserved [IANA]

NEW:

Decimal
Hexadecimal Name References
--------- ---- ----------
0 [RFC-dnsext-2929bis-06]
0x0000 - Reserved, assignment requires an IETF Standards Action.

2 [RFC-dnsext-2929bis-06]
0x0002 - Available for assignment by IETF Consensus as a data CLASS.

5 - 127 [RFC-dnsext-2929bis-06]
0x0005 - 0x007F - available for assignment by IETF Consensus for data
CLASSes only.
128 - 253 [RFC-dnsext-2929bis-06]
0x0080 - 0x00FD - available for assignment by IETF Consensus for
QCLASSes and meta-CLASSes only.

256 - 32,767 [RFC-dnsext-2929bis-06]
0x0100 - 0x7FFF - Assigned by IETF Consensus.
32,768 - 57,343 [RFC-dnsext-2929bis-06]
0x8000 - 0xDFFF - Assigned for data CLASSes only based on
Specification Required as defined in [RFC2434].
57,344 - 65,279 [RFC-dnsext-2929bis-06]
0xE000 - 0xFEFF - Assigned for QCLASSes and meta-CLASSes only based
on Specification Required as defined in [RFC2434].
65,280 - 65,534 [RFC-dnsext-2929bis-06]
0xFF00 - 0xFFFE - Private Use.
65,535 [RFC-dnsext-2929bis-06]
0xFFFF - Reserved, can only be assigned by an IETF Standards Action.


We understand the above to be the only IANA Actions for this document.

PROTO Write-up

1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG
for publication?

There are no nits according to idnits 1.121 (via tools.ietf.org).
As this is a a replacement to an existing RFC where only some sections
have changed. The biggest change is in relaxing the rules for
allocation of new RR types. To test this new process DNSEXT is running
an experiment of this process. The result of the experiment is expected
before the IESG will process this document.


2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?


Yes during last-call this document has been reviewed in depth by (at
least) the following people.
-----------------


2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?


Yes during last-call this document has been reviewed in depth by (at
least) the following people.

Peter Koch
http://psg.com/lists/namedroppers/namedroppers.2006/msg00972.html

Scott Rose
http://psg.com/lists/namedroppers/namedroppers.2006/msg00973.html

Thierry Moreau
http://psg.com/lists/namedroppers/namedroppers.2006/msg00973.html

MÃ¥ns Nilsson
http://psg.com/lists/namedroppers/namedroppers.2006/msg01041.html

Sam Weiler (multiple postings)
Thomas Narten (multiple postings)


Following people made comments on the document during the last call
without explicitly stating support or not.
Simon Josefsson
Edward Lewis
Bill Manning


There is rough consensus to advance the document.

3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?


We think this document has had sufficient review.


4) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or whether there really is a need for it, etc., but at the same
time these issues have been discussed in the WG and the WG has
indicated it wishes to advance the document anyway.

There are no issues that are decisive in this document, there was
some undercurrent that the document was overly bureaucratic and
division of number spaces where there has been no demand is an
overkill. In the chairs opinion these are natural disagreements on
what is best in a world where people have differences of opinion on
how processes should work. This does not change the fact there is
consensus this document is an improvement over its predecessor and
should be advanced in current form.


5) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with
it?


The consensus is strong, on the document as whole, less strong on
certain sections.


6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No one has threatened an appeal.


7) Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).


Yes.


8) For Standards Track and BCP documents, the IESG approval
announcement includes a write up section with the following
sections:

- Technical Summary

The document updates rules for how certain DNS parameter values
are allocated. In most cases this is a relaxation of the existing
rules. The document is giving guidance to IANA on policies for
allocation. The DNS community wants to simplify the rules for
allocation of new RR types, and this document combined with the
rules in RFC3597 makes this possible. For RR types that fit within
the rules a simple template and review by WG and a designated
expert is the new process. Most other changes from RFC2929 are
insignificant.


- Working Group Summary

There is a broad consensus that this document is an improvement
over its predecessor.

- Protocol Quality

This is document about IETF/IANA process so there are no
implementations. The working group and sponsoring AD are running an
experiment of the new RR type process concurrently with the
publication request. see:
http://psg.com/lists/namedroppers/namedroppers.2006/msg01601.html
http://psg.com/lists/namedroppers/namedroppers.2006/msg01603.html
http://psg.com/lists/namedroppers/namedroppers.2007/msg00068.html
http://psg.com/lists/namedroppers/namedroppers.2007/msg00070.html

Olafur