1. Slide 1 July 2006, Montreal, QuebecIETF DNSEXT 2929bis Donald E. Eastlake 3 rd +1-508-786-7554 Donald.Eastlake@motorola.com

2. Slide 2 July 2006, Montreal, QuebecIETF DNSEXT RFC 2929 RFC 2929 Provided first IANA considerations for RR TYPEs, CLASSes, RCODEs, OpCodes, header bits, etc. RFD 2929 generally provides some Private Use, some Publication Required, some IETF Consensus, and few reserved or Standards Action required allocation policies.

3. Slide 3 July 2006, Montreal, QuebecIETF DNSEXT RFC 2929 (cont.) Problem: –“IETF Consensus” and “Specification Required” were considered too hard for allocating Type Codes in a timely fashion, so people overload TXT, etc. Solution History: –Initially there appeared to be a strong desire for a liberalized version of “Early Allocation” (RFC 4020) which was put in draft - 00. –There was a backlash at the Paris meeting against “Early Allocation” and for “Expert Review” resulting in draft -01. –In Vancouver, feelings seemed a bit more positive but there was a desire for more guidance for and limitations on the Expert. So - 02 limits Expert Reivew allocation to innocuous data and meta RRs. –At the Dallas meeting, there were requests for more explicit and details guidance, so these have been added in section 3.1.3 of version -03.

4. Slide 4 July 2006, Montreal, QuebecIETF DNSEXT RFC 2929bis Primary Effect: Replace RFC 2929 with a more liberal document Changes to RFC 2929 (see Appendix to draft): –Replace “IETF Consensus” for RR Type Codes with “Expert Review” as described on later slides. –Augments some “IETF Standards Action” required with “as modified by [RFC 4020]”. –Cover AFSDB Subtypes allocation using IETF Consensus. –Provides for hypothetical future “meta-CLASSes”. –Numerous minor updates and changes.

5. Slide 5 July 2006, Montreal, QuebecIETF DNSEXT RFC 2929bis DNS RR Type Allocation Policy About half of the RR Type Codes can be allocated with Expert Review. Most of the other half is “Specification Required”. Expert Review is only available –After a completed DNS RR Type Allocation Template has been posted for at least three weeks on the namedroppers mailing list. –The RR for which a TYPE code is being requested must be either (a) a data TYPE which can be handled as an Unknown RR as described in [RFC 3597] or (b) a Meta TYPE who processing is optional, i.e., which it is safe to simply discard.

6. Slide 6 July 2006, Montreal, QuebecIETF DNSEXT DNS RR Type Parameter Allocation Template Date Name, telephone, and email of originator Pointer to public RR description document Description of need for new RR Type Closest existing RR Type and why it does not meet the need Does new RR Type require special handling different from an Unknown RR Type or an ignorable meta-Type? Comments

7. Slide 7 July 2006, Montreal, QuebecIETF DNSEXT RR Type Designated Expert Guidelines Reasons for refusal 1.Did not have a complete template as specified above posted to the namedroppers mailing list for at least three weeks. 2.Was documented in a manner that was not sufficiently clear to evaluate or ensure interoperability. 3.The RRTYPE value is needed for a DNS extension, but the extension is not consistent with the documented (or generally understood) architecture of the DNS protocol, and would be harmful to the DNS if widely deployed. 4.The intended use of the proposed RRTYPE would cause problems with existing DNS deployments. 5.The requested RRTYPE would conflict with one under development within the IETF and the existence of more than one such type would harm interoperability. 6.An existing RRTYPE or RRTYPEs appear to adequately meet the purpose of the RR for which an RRTYPE value or values are requested. 7.An excessive number of RRTYPE values is being requested when the purpose could be met with a smaller number. 8.The request appears to be for an RRTYPE value that would not genuinely be used in the DNS or whose use would be insignificant or whose near term use would be better met by a value from the range reserved for Private Use.