idnits 2.17.1 draft-koch-mboned-mcast-arpa-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 241. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 254. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 16, 2006) is 6399 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1034' is defined on line 172, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 175, but no explicit reference was found in the text == Unused Reference: 'RFC2780' is defined on line 196, but no explicit reference was found in the text == Unused Reference: 'RFC2908' is defined on line 200, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3171 (Obsoleted by RFC 5771) -- Obsolete informational reference (is this intentional?): RFC 2908 (Obsoleted by RFC 6308) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Koch 3 Internet-Draft DENIC eG 4 Expires: April 19, 2007 October 16, 2006 6 Moving MCAST.NET into the ARPA infrastructure top level domain 7 draft-koch-mboned-mcast-arpa-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 19, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document proposes to migrate the MCAST.NET domain into the ARPA 41 top level domain that is dedicated to infrastructure support. It 42 also covers migration issues and caveats. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 47 1.1. The ARPA top level domain . . . . . . . . . . . . . . . 3 48 2. Current Use . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Registration Policy . . . . . . . . . . . . . . . . . . 3 50 3.1. Names and Addresses eligible for Registration in 51 MCAST.ARPA . . . . . . . . . . . . . . . . . . . . . . 3 52 3.2. Subdomains of MCAST.ARPA . . . . . . . . . . . . . . . 3 53 4. Migration Issues . . . . . . . . . . . . . . . . . . . 3 54 4.1. Migration Strategies . . . . . . . . . . . . . . . . . 4 55 4.1.1. Freeze . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1.2. Phase Out . . . . . . . . . . . . . . . . . . . . . . . 4 57 4.1.3. Continue . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . 4 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . 5 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Normative References . . . . . . . . . . . . . . . . . 5 63 8.2. Informative References . . . . . . . . . . . . . . . . 5 64 Appendix A. Document Revision History . . . . . . . . . . . . . . . 6 65 A.1. Initial Document . . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . 8 69 1. Introduction 71 Comments should be directed at the author or to the mboned working 72 group. 74 {This is an early version and thus will not pass the ID nits test.} 76 1.1. The ARPA top level domain 78 [RFC3172] designates the ARPA top level domain as "Address and 79 Routing Parameters Area" to be used for infrastructure applications. 81 The mcast.net second level domain fulfills the criteria layed out in 82 section 2.1 of [RFC3172]. However, there is no standards track 83 document explicitly designating this domain to a multicast group name 84 to multicast group address mapping. 86 [RFC3171] defines the multicast address assignment policy. 88 2. Current Use 90 Currently the zone MCAST.NET reflects the contents of the IANA 91 multicast address registry. However, some names are missing from the 92 DNS zone and some names used differ from the description that appears 93 in the registry file. 95 3. Registration Policy 97 Names within MCAST.ARPA will consist of one additional label and will 98 adhere to the hostname syntax requirements of [RFC1123]. These names 99 will own a single A RR, a single AAAA RR, or both. Addresses will be 100 in the IPv4 or IPv6 multicast address space. 102 3.1. Names and Addresses eligible for Registration in MCAST.ARPA 104 Only IANA multicast address registrations are eligible for being 105 listed in MCAST.ARPA. 107 3.2. Subdomains of MCAST.ARPA 109 There might be subdomains below MCAST.ARPA that serve special 110 purposes. 112 4. Migration Issues 113 The current content of the MCAST.NET zone shall be brought in line 114 with the multicast address registry. 116 Since legacy systems may use MCAST.NET for quite some time, there 117 needs to be a mapping/forwarding solution to answer those queries in 118 a useful manner without discouraging migration. 120 RFCs mentioning MCAST.NET are [RFC3261] and [RFC3678]. 122 A proposal in [I-D.ietf-mboned-addrdisc-problems] mentions a 123 subdomain of MCAST.NET. 125 4.1. Migration Strategies 127 After the move, several options are available for the future handling 128 of MCAST.NET. 130 4.1.1. Freeze 132 The current MCAST.NET zone could be frozen, so that no additions, 133 deletions or changes to the content (apart from those necessary for 134 maintenance, e.g. SOA and NS RRs) would be perfomed. New 135 registrations would only be available in MCAST.ARPA, so this could be 136 an incentive for querying clients to alter their behavior as well. 138 4.1.2. Phase Out 140 MCAST.NET would only see deletions. 142 4.1.3. Continue 144 MCAST.NET could be further operated in parallel, either by 145 operational habit or per DNAME RR. 147 5. Security Considerations 149 The usual Security Considerations for the DNS apply. 151 There is no Security Problem associated with the migration itself. 153 MCAST.ARPA. should be signed with DNSSEC as soon as the ARPA domain 154 is signed. 156 This section needs more work 158 6. IANA Considerations 160 This document makes a recommendation to IANA. 162 This section needs more work 164 7. Acknowledgements 166 The author would like to thank David Conrad for his input. 168 8. References 170 8.1. Normative References 172 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 173 STD 13, RFC 1034, November 1987. 175 [RFC1035] Mockapetris, P., "Domain names - implementation and 176 specification", STD 13, RFC 1035, November 1987. 178 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 179 and Support", STD 3, RFC 1123, October 1989. 181 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 182 "IANA Guidelines for IPv4 Multicast Address Assignments", 183 BCP 51, RFC 3171, August 2001. 185 [RFC3172] Huston, G., "Management Guidelines & Operational 186 Requirements for the Address and Routing Parameter Area 187 Domain ("arpa")", BCP 52, RFC 3172, September 2001. 189 8.2. Informative References 191 [I-D.ietf-mboned-addrdisc-problems] 192 Savola, P., "Lightweight Multicast Address Discovery 193 Problem Space", draft-ietf-mboned-addrdisc-problems-02 194 (work in progress), March 2006. 196 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 197 Values In the Internet Protocol and Related Headers", 198 BCP 37, RFC 2780, March 2000. 200 [RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet 201 Multicast Address Allocation Architecture", RFC 2908, 202 September 2000. 204 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 205 A., Peterson, J., Sparks, R., Handley, M., and E. 206 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 207 June 2002. 209 [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 210 Extensions for Multicast Source Filters", RFC 3678, 211 January 2004. 213 Appendix A. Document Revision History 215 This section is to be removed should the draft be published. 217 A.1. Initial Document 219 First draft 221 Author's Address 223 Peter Koch 224 DENIC eG 225 Wiesenhuettenplatz 26 226 Frankfurt 60329 227 DE 229 Phone: +49 69 27235 0 230 Email: pk@DENIC.DE 232 Intellectual Property Statement 234 The IETF takes no position regarding the validity or scope of any 235 Intellectual Property Rights or other rights that might be claimed to 236 pertain to the implementation or use of the technology described in 237 this document or the extent to which any license under such rights 238 might or might not be available; nor does it represent that it has 239 made any independent effort to identify any such rights. Information 240 on the procedures with respect to rights in RFC documents can be 241 found in BCP 78 and BCP 79. 243 Copies of IPR disclosures made to the IETF Secretariat and any 244 assurances of licenses to be made available, or the result of an 245 attempt made to obtain a general license or permission for the use of 246 such proprietary rights by implementers or users of this 247 specification can be obtained from the IETF on-line IPR repository at 248 http://www.ietf.org/ipr. 250 The IETF invites any interested party to bring to its attention any 251 copyrights, patents or patent applications, or other proprietary 252 rights that may cover technology that may be required to implement 253 this standard. Please address the information to the IETF at 254 ietf-ipr@ietf.org. 256 Disclaimer of Validity 258 This document and the information contained herein are provided on an 259 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 260 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 261 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 262 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 263 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 264 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 266 Copyright Statement 268 Copyright (C) The Internet Society (2006). This document is subject 269 to the rights, licenses and restrictions contained in BCP 78, and 270 except as set forth therein, the authors retain all their rights. 272 Acknowledgment 274 Funding for the RFC Editor function is currently provided by the 275 Internet Society.