Skip to main content

Domain Name System (DNS) IANA Considerations
RFC 6895

Yes

(Ralph Droms)

No Objection

(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Robert Sparks)
(Ron Bonica)
(Stephen Farrell)
(Stewart Bryant)
(Wesley Eddy)

Note: This ballot was opened for revision 04 and is now closed.

(Ralph Droms; former steering group member) Yes

Yes (for -04)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (for -04)

                            

(Barry Leiba; former steering group member) (was Discuss, No Objection) No Objection

No Objection (2012-11-05)
(5 Nov: DISCUSS for IANA is now cleared)

While you're tweaking the instructions for the Designated Expert:

-- Section 3.1.2 --
   The Expert should normally reject any RRTYPE allocation request that
   meets one or more of the following criteria:

I presume that means that the Expert should normally approve any requests that do not meet those criteria, and it'd be nice if this said that, or something related to it that connects to what you have in mind.  In other words, it would be good to say whether you want the Designated Expert to be lenient or strict.  So perhaps something like this (or whatever variant is suitable)?:

   The Designated Expert should normally be lenient, preferring
   to approve most requests.  However, the Expert should normally
   reject any RRTYPE allocation request that meets one or more of
   the following criteria:

(Benoît Claise; former steering group member) No Objection

No Objection (for -04)

                            

(Brian Haberman; former steering group member) No Objection

No Objection (for -04)

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -04)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -04)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (2012-10-10 for -04)
The only 2119 keyword in this thing is in section 2.3 where it says:

   With the existing exceptions of
   error numbers 9 and 16, the same error number MUST NOT be assigned
   for different errors even if they would only occur in different RR
   types.

That doesn't need a 2119 keyword. Lowercase it, delete the 2119 template and reference, and be done with it.

(Robert Sparks; former steering group member) No Objection

No Objection (for -04)

                            

(Ron Bonica; former steering group member) No Objection

No Objection (for -04)

                            

(Russ Housley; former steering group member) No Objection

No Objection (2012-10-10 for -04)
  Please consider the comments from the Gen-ART Review by Dan Romascanu
  on 9-Oct-2012.  You can find the review here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07830.html

(Sean Turner; former steering group member) No Objection

No Objection (2012-10-03 for -04)
Nicely done!

In deference to the bygone era of low bandwidth, I believe s2.1 should be retitled:  "Brother, can you spare a bit?" ;)

s3.1.1: Should the rejection also go back to the dns-rrtype-applications@ietf.org mailing list so the other experts in the pool can see whether it was approved/rejected?  Only sending to dnsext@ietf.org kind of assumes all the experts are on the dnsext@ietf.org list.

s3.1.1: Should rejected applications also be tracked for historical purposes and so experts can say no we already no before to this?

(Stephen Farrell; former steering group member) No Objection

No Objection (for -04)

                            

(Stewart Bryant; former steering group member) No Objection

No Objection (for -04)

                            

(Wesley Eddy; former steering group member) No Objection

No Objection (for -04)