Skip to main content

Domain Name System (DNS) IANA Considerations
draft-ietf-dnsext-rfc6195bis-05

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 IESG member
Yes
Yes (for -04) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Barry Leiba Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2012-11-05) Unknown
(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 IESG member
No Objection
No Objection (for -04) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-10-10 for -04) Unknown
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 IESG member
No Objection
No Objection (for -04) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (2012-10-10 for -04) Unknown
  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 IESG member
No Objection
No Objection (2012-10-03 for -04) Unknown
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 IESG member
No Objection
No Objection (for -04) Unknown

                            
Stewart Bryant Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -04) Unknown