idnits 2.17.1 draft-ietf-crisp-iris-areg-urires-01.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 191. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 198. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 204. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. 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 (February 19, 2005) is 7005 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: '3' is defined on line 147, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 156, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3707 (ref. '3') == Outdated reference: A later version (-15) exists of draft-ietf-crisp-iris-areg-10 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '5') (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Gunduz 2 Internet-Draft RIPE NCC 3 Expires: August 20, 2005 February 19, 2005 5 IRIS - URI Resolution for AREG Type for the Internet Registry 6 Information Service 7 draft-ietf-crisp-iris-areg-urires-01 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 20, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes a URI Resolution method for the IRIS registry 43 schema for IP address and Autonomous System Number information. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 49 3. URI Resolution for AREG . . . . . . . . . . . . . . . . . . . 5 50 3.1 Application Service Label . . . . . . . . . . . . . . . . 5 51 3.2 Top-Down Resolution . . . . . . . . . . . . . . . . . . . 5 52 3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Internationalization Considerations . . . . . . . . . . . . . 7 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 57 6.2 Informative References . . . . . . . . . . . . . . . . . . . 9 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 59 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 60 Intellectual Property and Copyright Statements . . . . . . . . 11 62 1. Introduction 64 This document describes a URI resolution method for AREG [4] (Address 65 Registry) type in the IRIS [2] namespace. URI resolution is the 66 process of determining which directory server to query for a given 67 resource. 69 2. Document Terminology 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC2119 [1]. 75 3. URI Resolution for AREG 77 3.1 Application Service Label 79 The application service label associated with AREG registry type MUST 80 be "AREG1". This is the abbreviated form the URN for this registry 81 type, urn:ietf:params:xml:ns:areg1. 83 3.2 Top-Down Resolution 85 The top-down alternative resolution method MUST be identified as 86 'top' in IRIS URI's. 88 The client SHOULD start every query from the IRIS server 89 iris.nro.net, the top of the hierarchy, and follow the referrals to 90 find the authoritative server to actually query. The client MAY 91 start from any other IRIS server in the hierarchy, in which case, 92 that IRIS server MAY choose to refer the client to the top of the 93 hierarchy if it does not have the authoritative information, or if it 94 has an up-to-date map of the current delegation status, it MAY choose 95 to refer the client to the IRIS server it believes to be the 96 authoritative server for the information sought for. 98 3.3 Discussion 100 AREG URI resolution does not use DNS unlike DREG URI resolution [6]. 102 Using DNS makes sense in two cases: 103 o When the directory already has natural links to DNS, 104 o When the entities involved do not have the resources or intention 105 to maintain the top of the hierarchy. 107 In the case of AREG, the entities involved are RIRs (Regional 108 Internet Registries) and NRO (Number Resource Organisation), which 109 have enough resources and intention to maintain the top of the 110 hierarchy. In fact, RIRs have to keep the global distribution map of 111 address allocation, which makes them, or the NRO, which is formed by 112 the RIRs to formalize their co-operative efforts, the natural 113 candidate to maintain the top of the hierarchy. 115 Address registry does not have natural links to DNS either. Using 116 reverse DNS tree presents problems for IP address delegation (for 117 example, delegations do not fall into byte boundaries, unlike reverse 118 DNS), and DNS does not currently contain any information regarding 119 autonomous system delegation. 121 As a result, this memo suggests not using DNS for AREG URI 122 resolution. 124 DNS could perhaps be used to point to the top of the IRIS server 125 hierarcy, but this is considered unnecessary indirection. 127 4. Internationalization Considerations 129 This document lays out no new considerations for internationalization 130 beyond that specified in IRIS [2]. 132 5. Security Considerations 134 This document lays out no new considerations for security precautions 135 beyond that specified in IRIS [2]. 137 6. References 139 6.1 Normative References 141 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 142 Levels", RFC 2119, BCP 14, March 1997. 144 [2] Newton, A. and M. Sanz, "Internet Registry Information Service", 145 RFC 3981, January 2005. 147 [3] Newton, A., "Cross Registry Internet Service Protocol (CRISP) 148 Requirements", RFC 3707, February 2004. 150 [4] Gunduz, E., Newton, A. and S. Kerr, "IRIS - An Address Registry 151 (areg) Type for the Internet Registry Information Service", 152 draft-ietf-crisp-iris-areg-10 (work in progress), February 2005. 154 6.2 Informative References 156 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 157 Considerations Section in RFCs", RFC 2434, BCP 26, October 1998. 159 [6] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type for 160 the Internet Registry Information Service (IRIS)", RFC 3982, 161 January 2005. 163 Author's Address 165 Engin Gunduz 166 RIPE NCC 167 Singel 258 168 Amsterdam 1016AB 169 The Netherlands 171 Phone: +31 20 535 4444 172 EMail: e.gunduz@computer.org 174 Appendix A. Acknowledgements 176 Andy Newton, David Blacka, Tim Christensen, Eric Hall, William 177 Leibzon, April Marine, George Michaelson, Cathy Murphy, Andrei 178 Robachevsky, Shane Kerr, Marcos Sanz, Frederico Neves, Leslie Daigle, 179 Rick Wesson and many others contributed constructively in the mailing 180 list discussions and IETF Meeting sessions. 182 Intellectual Property Statement 184 The IETF takes no position regarding the validity or scope of any 185 Intellectual Property Rights or other rights that might be claimed to 186 pertain to the implementation or use of the technology described in 187 this document or the extent to which any license under such rights 188 might or might not be available; nor does it represent that it has 189 made any independent effort to identify any such rights. Information 190 on the procedures with respect to rights in RFC documents can be 191 found in BCP 78 and BCP 79. 193 Copies of IPR disclosures made to the IETF Secretariat and any 194 assurances of licenses to be made available, or the result of an 195 attempt made to obtain a general license or permission for the use of 196 such proprietary rights by implementers or users of this 197 specification can be obtained from the IETF on-line IPR repository at 198 http://www.ietf.org/ipr. 200 The IETF invites any interested party to bring to its attention any 201 copyrights, patents or patent applications, or other proprietary 202 rights that may cover technology that may be required to implement 203 this standard. Please address the information to the IETF at 204 ietf-ipr@ietf.org. 206 Disclaimer of Validity 208 This document and the information contained herein are provided on an 209 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 210 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 211 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 212 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 213 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 214 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 216 Copyright Statement 218 Copyright (C) The Internet Society (2005). This document is subject 219 to the rights, licenses and restrictions contained in BCP 78, and 220 except as set forth therein, the authors retain all their rights. 222 Acknowledgment 224 Funding for the RFC Editor function is currently provided by the 225 Internet Society.