Domain Name System (DNS) IANA Considerations
RFC 6195
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
(Jari Arkko; former steering group member) Yes
This is a good document and should go forward. A few comments regarding the comments and discusses from other ADs: - I do not believe this document is the place to obsolete z-bit. This is an IANA considerations doc. - Regarding URLs and the template, I note that Specification Required is not explictly called for. Maybe it should be, and that would solve the URL problem (as the semantics of Specification Required have been defined elsewhere and reference stability is one criteria).
(Ralph Droms; former steering group member) Yes
(Ron Bonica; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
A nit: The Abstract reads... Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System (DNS) resource record types, CLASSes, operation codes, error codes, DNS protocol message header bits, and AFSDB resource record subtypes. Pedantically, this Abstract says nothing about *this* document. Could you make it read... This document specifies Internet Assigned Number Authority (IANA) parameter assignment considerations for the allocation of...
(Alexey Melnikov; former steering group member) (was Discuss, No Objection) No Objection
I am agreeing with David's DISCUSS regarding use of stable URLs to documents. I think "Specification Required" would be a better IANA registration policy here. I have a couple of comments. Taking into consideration that this is a bis document, I am making them Comment-level: 1) 3.1.1. DNS RRTYPE Allocation Policy No less than three weeks and no more than six weeks after a completed template has been formally posted to dnsext@ietf.org, the selected Expert shall post a message, explicitly accepting or rejecting the application, to IANA, dnsext@ietf.org, and the email address provided by the applicant. If the Expert does not post such a message, the application shall be considered rejected but may be re-submitted to IANA. The last sentence: is "rejection by silence" a good idea? Has this worked well in the past? 2) Excuse my ignorance, but what is the relationship between 2 mailing lists: 3.1.1. DNS RRTYPE Allocation Policy No less than three weeks and no more than six weeks after a completed template has been formally posted to dnsext@ietf.org, the selected Expert shall post a message, explicitly accepting or rejecting the application, to IANA, dnsext@ietf.org, and the email address provided by the applicant.
(Dan Romascanu; former steering group member) No Objection
(David Harrington; former steering group member) (was Discuss) No Objection
in section 1, s/is the change is the public review mailing list /is the change to the public review mailing list/ in section 2.3, might it be good to recommend NOT overloading the values, ala the 16 bit, since we have 60000+ bits available? section 3.1.4 uses MX RR without prior definition, or reference to the definition. in Annex 1, field E, why does this end in a colon? why is field J on a totally separate page?
(Gonzalo Camarillo; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
I agree with David Harrington's discuss.
(Tim Polk; former steering group member) No Objection