Internet Engineering Task Force David Kessens Draft ISI Expires September 1997 Dhaval Shah <draft-kessens-ride-classes.txt> Cisco Systems, Inc. Rick Wesson Organic Online, Inc. March 1997 RIDE classes Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes the attributes and classes that will be used in the internet Registry Information Database Exchange formats (RIDE). For now it is mostly limited to 'domain' and 'contact' classes since they were widely considered as most urgent. Encoding that will be used for the objects and ways to find and access objects are beyond the scope of this document. This will be addressed in the future in separate drafts. Introduction This document follows a top-down approach. We will first describe the classes and it's properties. We will build the classes from attributes that we define when we use them. Kessens [Page 1]
Draft RIDE Classes March 1997 The properties are not absolutely defined. We expect certain attributes to have certain values, but we also expect that actual implementations are liberal in what they accept. Eg.: being too restrictive when receiving attributes that have values violating the specification could degrade the usability of the scheme a lot while it doesn't really help with making a more reliable system. On the other hand, everybody that is going to create their own Internet registry is well advised to follow the guidelines of this document to maximize interoperatibility with other registries. We already talk in the document about formats while we explicitly told earlier not to deal with the actual dataformats yet. Assume those formats as examples of exactly which data is supposed to be carried in certain attributes, for clearness sake and as an advise how the contents could be shown to the *human* user. They don't however, tell anything yet, about how they will eventually be represented in the exchange format as will be defined in a separate document. The contact class The contact class is a class that has two different functions. It defines contact information. Furthermore, it can work, when referenced by another object, as a macro definition for authentication information that can be used to authenticate a message or authorize an update to an object when the originator is properly authenticated. In addition to this functionality it may define information on how and who to notify of changes in the object that referenced the contact object. The contact class can be referenced by a NIC handle that will be guaranteed to be unique world wide [document needs to written] Definition of contact class: Contact Type Handle Auth Notify Address StandardAttributes Contact This attribute contains the name of a contact. For best search results, it is advised to accept full names only without titles Kessens [Page 2]
Draft RIDE Classes March 1997 and no abbreviations. Type Defines whether the contact refers to an individual, an organization/role or whether it is used for authentication/notification purposes only. values: <INDIVIDUAL | ROLE | MNTNER> Handle Contains a unique world wide identifier for the contact Auth Class The Auth is a class describes which authorization schemes to use for updating objects and how to notify when updates are accepted or failed due to an authorization failure The Auth class is defined as follows AuthSchemes Notify AuthSchemes Multiple schemes can be used and logical combinations can be formed by using '&', '|' and '!' operators: < AuthScheme-1 | ( AuthScheme-2 & AuthScheme-3 ) > A scheme can be used for authentication purposes or authorization of update requests. Curently, the following schemes are known: CRYPT-PW <crypted password> Password is encrypted with the DES algorithm which is available on most UNIX systems as a library routine 'crypt'. MAIL-FROM <Regular expression> Kessens [Page 3]
Draft RIDE Classes March 1997 Weak authorization schema. E-mail header 'From:' line is matched against the regular expression and updates are accepted when a match is found. PGP <Public key> Server can authenticate messages by using the specified PGP public key. The Notify class The Notify class defines which E-mail addresses are notified with a message in case of an update of an object or when an authorization failure happens when somebody tries to update an object. Definition of the Notify class NotifyOnSuccess NotifyOnAuthFailure NotifyOptions NotifyOnSuccess NotifyOnSuccess contains a list of Contacts and/or E-mail addresses of those who will want to receive a notification E-mail message when an object that references the Contact is successfully updated. NotifyOnAuthFailure NotifyOnAuthFailure will have the same syntax as NotifyOnSuccess but will only be used in case of an authorization/authentication failure when trying to update an object that references the Contact. NotifyOptions NotifyOptions needs to be defined. It seems that we need something like this to accomodate the InterNIC guardians. We will invetigate this one further. Any help/comments are appreciated. The Address class The address class defines the address related componets of the Kessens [Page 4]
Draft RIDE Classes March 1997 Contact. More then one address can be specified. Definition of the Address class: Title Organization PostalAddres E-mail Phone Fax Title Can be used to describe the function/title of an individual. Organization Can be used to describe the organization which the Contact is part of PostalAddress <FullAddress [CountryCode]|Street City [State] [PostalCode] CountryCode> All addresses MUST be specified in such a way that they are usable from any country in the world. That means that a country must be specified either in the FullAddress field or in the CountryCode. Phone numbers MUST be specified in international format with (+CountryCode). E-mail list of valid e-mail addresses Phone list of valid phone numbers Fax list of valid phone numbers connected to a fax Kessens [Page 5]
Draft RIDE Classes March 1997 The StandardAttributes class The StandardAttributes class describes generic attributes that can be used in almost any object. Definition of the StandardAttributes class Description URL ContactReference Countries Updated AUP Registry Description a description of the object URL list of urls that contains possible interesting information. ContactReference <Type, ...> <Handle> This attributes references single or multiple contact objects by use of it's NIC handles. Each Contact has associated types and possibly some options: Technical Administrative Zone Billing Generic Maintainer ( NEW, DEL, UPD, HIERNEW, HIERDEL, HIERUPD, ALL, HIERALL ) Countries List of ISO-3166 country codes. The list tells something about the physical location of the entity described in the object. Updated List of UTC dates and times (seconds granularity) which tells Kessens [Page 6]
Draft RIDE Classes March 1997 at which dates and times the object was changed. Note; this might/might not be a complete list. AUP Acceptable use policy for the object. This gives anybody a chance to legally protect their information against abuse. Registry master registry which currently maintains the object The Domain class The Domain class describes DNS domain names together with technical and administrative data necessary for a proper operation of the DNS system. Definition of the Domain class DomainName Status GoodUntil Nameservers StandardAttributes DomainName This attribute contains the fully qualified domain name without a trailing dot. Status This attribute refers to the current status of this domain. Values: RESERVED | WAIT | PRODUCTION GoodUntil This attribute specifies the duration until which the object or reservation is valid or until when the wait period will last Values: Kessens [Page 7]
Draft RIDE Classes March 1997 <Date|UNTILREVOKEDBYOWNERORLAW> Date is a UTC date. It's value is specified in the following format: YYYYMMDD [HH:MM:SS] Nameservers This attribute contains the set of nameserver(s) that are authoritative for this domain. Nameservers are specified by using their fully qualified domain name optionally followed by whitespace and a comma separated list of IP numbers (note: ALL valid IP versions are fine). The IPregistration class The IPregistration class describes to whom a certain range of IP addresses is allocated or assigned, together with technical and administrative data to facilitate the network operatrs and administrators. The object can use any existing IP version. Definition of the IPregistration class IPAddressRange IPStatus Status GoodUntil NetName ReverseNameservers StandardAttributes IPAddressRange This attribute defines the IP address range for which the allocation or assignment is valid. The range is specified by using the smallest and largest IP address of the range. IPStatus This attribute refers to the current CIDR status of the address range. Values: <IPversion> < PROVIDERINDEPENDANT | PROVIDERAGGREGRATEBALE | UNDEFINED > Kessens [Page 8]
Draft RIDE Classes March 1997 < ALLOCATION | ASSIGNMENT > NetName This attribute is the name of the network associated with this object. ReverseNameservers This attribute contains the set of nameserver(s) that are authoritative for the reverse resolution of the address range. Nameservers are specified by using their fully qualified domain name. The route, aut-num, as-set, rs-set, inet-rtr and dictionary classes Those classes are currently being defined by the RPS IETF working group. Since there only exist two different definitions in the world, RIPE181 [2] and RPSL, and RIPE181 is currently being substituted by RPSL, we will use the RPSL definitions as the standard and will only describe the differences between RIDE and the RPSL representation. The only exception in this is the aut-num object which has a different format in the InterNIC registry, however, this is merely a matter of naming conventions. Security considerations There are no security implications. The authentication/authorization mechanisms are a description of the systems that several Internet registries currently use, there is no claim made in this document that they are actually secure or safe. This is an issue that should be addressed by the individual registries. Furthermore, every user that registers information in an Internet registry should be warned that their information is globally visible and could be abused if no proper care is taken on which information one actually wanted to be visible. Acknowledgments We would like to thank Masaya Nakayama, and everybody that contributed to the work of the RIDE IETF working group in general, for their various comments and suggestions. Kessens [Page 9]
Draft RIDE Classes March 1997 Appendix A: formal description in IDL This section will be filled in by Rick Wesson when the classes are more ironed out. Appendix B: yacc parser This section will be filled in by David Kessens when the classes are more ironed out. References [1] C. Alaettinoglu et. al., draft-ietf-rps-rpsl-00.txt, March 1997. [2] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, and J. Yu, "Representation of IP Routing Policies in a Routing Registry", ripe-181, RIPE NCC, Amsterdam, Netherlands, October 1994. Author's Address: David Kessens, ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 USA davidk@ISI.EDU Rick H. Wesson Organic Online, Inc 510 3rd St. Suite 540 San Francisco, CA 94107 USA rick@organic.com Dhaval Shah Cisco Systems Inc. 170, W. Tasman Drive San Jose, CA 95134-1706 USA dhaval@cisco.com Kessens [Page 10]