idnits 2.17.1 draft-ietf-rps-location-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 Abstract section. ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 16 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 158 looks like a reference -- Missing reference section? '2' on line 163 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Rusty Eddy 2 Expires August 27, 1996 USC/ISI 3 draft-ietf-rps-location-00.txt February, 1996 5 Geographic Location Extension to Ripe-181 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its 11 areas, and its working groups. Note that other groups may also 12 distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months and may be updated, replaced, or obsoleted by other 16 documents at any time. It is inappropriate to use Internet- 17 Drafts as reference material or to cite them other than as 18 ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check 21 the ``1id-abstracts.txt'' listing contained in the Internet- 22 Drafts Shadow Directories on ftp.is.co.za (Africa), 23 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 24 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 26 1. Introduction 28 This document describes two proposals for specifying geographic location 29 of a database objects such as an Autonomous System (AS). This 30 information could be used by mapping tools that provide geographic maps 31 of the Internet topology. Two alternatives are documented here, the 32 first proposal uses a new attribute added to a database object. The 33 attribute provides longitude, latitude and size information. The second 34 method also uses a new location attribute added to the database object, 35 this new attribute contains the name of a location object that we 36 propose. The two methods describe direct and indirect location 37 information respectively. 39 2. Format of Location String 41 The format of the geographic ``location string'' or LocString will be a 42 single string consisting of the latitude, longitude and optionally the 43 size. The latitude and longitude are each represented by one to three 44 integers corresponding to degrees, minutes and seconds, with a direction 45 appended to the final integers of the latitude and longitude. If 46 minutes and/or seconds are not provided values of 0 will be assumed and 47 size will default to 0, a point. The directions are north, south, east 48 and west. 50 For example, the LocString for Irvine, California is: 52 33 40 10n 117 49 20w 10m 54 Representing 33 degrees, 40 minutes and 10 seconds north latitude, and 55 117 degrees, 49 minutes and 20 seconds west longitude with a 10 meter 56 encompassing circle. Informally the LocString would be of the form: 58 "LA [MM [SS]](n|s) LO [MM [SS]](e|w) [SIm]" 60 Where, LA and LO are integers representing the degrees latitude and 61 longitude, respectively. MM is an integer representing the number of 62 minutes. SS is an integer representing the number of seconds. The 63 characters 'n', 's', 'e', 'w' and 'm' are literals corresponding to 64 north, south, east, west and meters, respectively. 66 3. Proposals for AS Geographic Location 68 The following proposals are similar, the first suggests a new attribute 69 to the Ripe-181[1] aut-num object, the second also suggests new aut-num 70 attribute and a new ``location'' object. The following examples use the 71 aut-num object, however, they may be equally applied to the as-macro, 72 inet-rtr or route objects as well. Attributing locations to these other 73 database objects would provide the geographic topology internal to an 74 AS, which may represent reality more accurately. 76 3.1 Direct Location 78 This method proposes a new aut-num attribute, ``location''. This 79 attribute is a single, optional attribute: 81 aut-num: [mandatory] [single] 82 ... 83 location: [optional] [single] 85 The ``location'' attribute will contain a LocString. For example, say 86 AS8800 is an ISP in Irvine, California, it's aut-num could contain the 87 following: 89 aut-num: AS8800 90 location: 33 40 10n 117 49 20w 91 ... 93 3.2 Direct and Indirect Location 95 This method proposes the addition of a ``location'' attribute to the 96 aut-num as in 3.1. This attribute could directly hold the LocString, or 97 the name of a ``location'' object. The location object could be defined 98 as: 100 location: [mandatory] [single] 101 loc-string: [mandatory] [single] 102 descr: [optional] [multiple] 103 notify: [optional] [multiple] 104 mnt-by: [optional] [multiple] 105 changed: [mandatory] [multiple] 106 source: [mandatory] [single] 108 Using the example in section 3.1, we would have the following: 110 aut-num: AS8800 111 location: IrvineCA 112 ... 114 and the object ``IrvineCA'' would be: 116 location: IrvineCA 117 loc-string: 33 40 10n 117 49 20w 10m 118 descr: Example location object in Irvine, CA. 119 notify: eddy@isi.edu 120 mnt-by: MAINT-EXAMPLE 121 changed: eddy@isi.edu 960220 122 source: EXAMPLE 124 The loc-name could be any string desired by the creator. 126 4. Problems 128 One obvious problem with using geographic layout inherent to networks, 129 is that they often span large geographic areas, this is true of many 130 ISPs. When attributing a location to an AS, one must pick a single 131 location to be representative of the AS. The internal topology of an AS 132 may be mapped geographically when a location attribute has been added to 133 the inet-rtr or route objects. 135 5. Conclusion 137 The motivation for providing geographic locations was prompted by the 138 development of the Internet Routing Registry (IRR) visualization tool 139 (IRRv) as a possible method for topological layout. Methods for 140 obtaining the LocString are beyond the scope of this document, however, 141 it should be noted that RFC 1876[2] specifies a means for containing 142 location information in Domain Name System. Also worth noting is a 143 ``Geographic Nameserver'' at http://www.mit.edu:8001/geo, that derives 144 its information from the Geographic Nameserver database on 145 martini.eecs.umich.edu. 147 Work in this area will proceed if the community finds this feature 148 useful. 150 6. Thanks 152 Although we have never spoke, I would like to thank, Juergen 153 Schoenwaelder (schoenw@ibr.cs.tu-bs.de) for the development of 154 scotty/tkined, which IRRv is based on and the example geographic layout 155 script. Thanks also to Cengiz Alaettinoglu for suggestions that led to 156 these proposals. 158 [1] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 159 M. Terpstra, and J. Yu. Representation of IP Routing Policies in a 160 Routing Registry. Technical Report ripe-181, RIPE, RIPE NCC, Amsterdam, 161 Netherlands, October 1994. 163 [2] C. Davis, P. Vixie, T. Goodwin, and I. Dickinson. A Means for 164 Expressing Location Information in the Domain Name System, 165 RFC 1876, January 1996. 167 Author's Present Address 169 Rusty Eddy 170 Information Sciences Institute 171 University of Southern California 172 Marina del Rey, CA 90292 173 e-mail: eddy@isi.edu