1 / 6

2929bis

2929bis. Donald E. Eastlake 3 rd +1-508-786-7554 Donald.Eastlake@motorola.com. RFC 2929. RFC 2929 Provided first IANA considerations for RR TYPEs, CLASSes, RCODEs, OpCodes, header bits, etc.

jprather
Download Presentation

2929bis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 2929bis Donald E. Eastlake 3rd +1-508-786-7554 Donald.Eastlake@motorola.com IETF DNSEXT

  2. 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. IETF DNSEXT

  3. RFC 2929 (cont.) • Main Problem: • “IETF Consensus” and even “Specification Required” were considered too hard for allocating Type Codes in a timely fashion, so people overload TXT, etc. • Solution History • There initially appeared to be a strong desire for a liberalized version of “Early Allocation” (RFC 4020) which was put in draft -00. • Then 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 explicit guidance for the Expert. IETF DNSEXT

  4. RFC 2929bis • Primary Effect: Replace RFC 2929 with a more liberal document • draft-ietf-dnsext-2929bis-02.txt will be submitted next week, available at www.pothole.com/~dee3 • Changes to RFC 2929 (see Appendix to draft): • Replace “IETF Consensus” for RR Type Codes with “Expert Review” as described on later slides. • Cover AFSDB Subtypes allocation using IETF Consensus. • Augments some “IETF Standards Action” required with “as modified by [RFC 4020]”. • Provides for hypothetical future “meta-CLASSes”. • Numerous minor updates and changes. IETF DNSEXT

  5. RFC 2929bis DNS 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 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. IETF DNSEXT

  6. DNS RR Type Parameter Allocation Template • Date • Name, telephone, and email of originator • Pointer to public RR description document • Need for new RR Type? • Closest existing RR Type • Does new RR Type require special handling different from an Unknown RR Type or an ignorable meta-Type? IETF DNSEXT

More Related