Subject: full diffs of rps-auth

From: Curtis Villamizar <[email-masked]>
Date: Thu, 11 Mar 1999 11:47:33 -0500

FYI-

In looking at mail to prepare for slides I just noticed that in my
last mail I sent diffs of the submitted draft against the preview
announced to the list earlier and not diffs against the prior version.
The full set of diffs are below.

I'll review the draft and explain the differences in the slides next
week.  If you'd rather not read unified diffs, then just delete.

Curtis

Index: rps-auth.rfc
===================================================================
RCS file: /usr/local/CVS-routing-dev/doc/ietf/rps-sec/rps-auth.rfc,v
retrieving revision 1.13
retrieving revision 1.18
diff -u -r1.13 -r1.18
--- rps-auth.rfc	1998/05/15 20:33:26	1.13
+++ rps-auth.rfc	1999/02/23 20:24:00	1.18
@@ -3,17 +3,15 @@
 Routing Policy System Security}{http://engr.ans.net/rps-auth}}
 \pubdate{\today}
 \author{Curtis Villamizar}
-\address{ANS}
+\address{UUNET}
 \author{Cengiz Alaettinoglu}
 \address{ISI}
 \author{David M. Meyer}
-\address{University of Oregon}
+\address{Cisco}
 \author{Sandy Murphy}
 \address{TIS}
-\author{Carol Orange}
-\address{RIPE}
 \footer{Villamizar, et. al.}
-\filename{draft-ietf-rps-auth-01}
+\filename{draft-ietf-rps-auth-02}
 \begin{document}
 \begin{alltt}
 \bibliographystyle{plain}
@@ -23,11 +21,10 @@
 %\end{htmlonly}
 %
 \begin{htmlonly}
-\author{Curtis Villamizar (ANS) \\
+\author{Curtis Villamizar (UUNET) \\
 	Cengiz Alaettinoglu (ISI) \\
-	David M. Meyer (University of Oregon) \\
-	Sandy Murphy (TIS) \\
-	Carol Orange (RIPE)}
+	David M. Meyer (Cisco) \\
+	Sandy Murphy (TIS)
 \end{htmlonly}
 \maketitle
 \resync
@@ -37,26 +34,29 @@
 
 \section*{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 view the entire list of current Internet-Drafts, please check
-     the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
-     Shadow Directories on
-     \htmladdnormallink{ftp.is.co.za}{ftp://ftp.is.co.za} (Africa),
-     \htmladdnormallink{ftp.nordu.net}{ftp://ftp.nordu.net} (Europe),
-     \htmladdnormallink{munnari.oz.au}{ftp://munnari.oz.au} (Pacific Rim),
-     \htmladdnormallink{ds.internic.net}{ftp://ds.internic.net}
-     (US East Coast), or
-     \htmladdnormallink{ftp.isi.edu}{ftp://ftp.isi.edu} (US West Coast).
+    This document is an Internet-Draft and is in full conformance with
+    all provisions of Section 10 of RFC2026.
+
+    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.''
+
+    The list of current Internet-Drafts can be accessed at
+    \htmladdnormallink{http://www.ietf.org/ietf/1id-abstracts.txt}{%
+    http://www.ietf.org/ietf/1id-abstracts.txt}
+
+    The list of Internet-Draft Shadow Directories can be accessed at
+    \htmladdnormallink{http://www.ietf.org/shadow.html}{%
+    http://www.ietf.org/shadow.html}.
+
+    Copyright (C) The Internet Society (\today).  All Rights Reserved.
 
 % \mathortext{--latex math or other stuff---}{--plain text approximation--}
 
@@ -147,17 +147,17 @@
 
 \begin{enumerate}
 \item
-The need to represent the routing policies of many
-organizations,
+There is a need to represent the routing policies of many
+organizations.
 \item
-CIDR and overlapping prefixes, the increasing complexity of routing
-policies and the needs of aggregation,
+CIDR and overlapping prefixes and the increasing complexity of routing
+policies and the needs of aggregation have introduced new requirements.
 \item
-the need to assure integrity of the data and delegate authority for
+There is a need to assure integrity of the data and delegate authority for
 the data representing specifically allocated resources to multiple
-persons or organizations,
+persons or organizations.
 \item
-the need to assure integrity of the data and distribute
+There is a need to assure integrity of the data and distribute
 the storage of data subsets to multiple repositories.
 \end{enumerate}
 
@@ -165,8 +165,8 @@
 Its predecessor, the PRDB, addressed the needs of a single
 organization, while the RIPE database was initially intended to
 address the needs of the European Internet community.  The RIPE
-database formats as described in \cite{rfc1786} are the basis of
-current IRR.
+database formats as described in \cite{rfc1786} were the basis of
+the original IRR.
 
 Routing protocols themselves provide no assurance that the origination
 of a route is legitimate and can actually reach the stated
@@ -180,30 +180,29 @@
 a very effective form of denial of service attack.
 
 The Routing Policy System Language (RPSL)
-\cite{rfc2280,draft-ietf-rps-appl-rpsl-01,draft-ietf-rps-extending-00}
+\cite{rfc2280,draft-ietf-rps-appl-rpsl-03}
 was a fairly substantial evolutionary step in the data representation
 which was largely targeted at addressing the second group of needs.
 The PRDB accommodated CIDR in 1993 \cite{rfc1482} and the RIPE database
 accommodated the entry of CIDR prefixes from inception, but RPSL
 provides many needed improvements including explicit support for
-aggregation.  Transition of the IRR to RPSL is expected to occur
-in late 1988 \cite{draft-ietf-rps-transition-02}.
+aggregation.
 
 This document addresses the third group of needs identified above.
 
 While the current implementation supporting weak authentication
-doesn't guarantee integrety of the data, it does provide extensive
+doesn't guarantee integrity of the data, it does provide extensive
 mechanisms to make sure that all involved parties get notified when a
 change is made to the database, whether the change was malicious or
-intended.  This provides inaddequate protection against additions.
+intended.  This provides inadequate protection against additions.
 Since the software is increasingly used to configure the major parts
 of the Internet infrastructure, it is not considered to be adequate
 anymore to know about and have the ability roll back unintended
 changes.  Therefore, more active security mechanism need to be
 developed to prevent such problems before they happen.
 
-A separate document addressing the fourth group of needs is also being
-written.
+A separate document addresses the fourth group of needs
+\cite{draft-ietf-rps-dist-00}.

 \section{Implicit Policy Assumptions}
@@ -215,7 +214,7 @@
 policy assumptions.
 
 \begin{enumerate}
-\item		Address numbers are allocated hierachically.  The IANA
+\item		Address numbers are allocated hierarchically.  The IANA
 		delegates portions of the address space to the
 		regional registries (currently ARIN, APNIC and RIPE),
 		which in turn delegate address space to their members,
@@ -224,7 +223,7 @@
 		blocks by registries.  Registries are allocated blocks
 		of AS numbers, thereby making the allocation
 		hierarchical.
-\item		Routes should only be anounced with the consent of the
+\item		Routes should only be announced with the consent of the
 		holder of the origin AS number of the announcement and
 		with the consent of the holder of the address space.
 \item		AS numbers and IP address registries may be different
@@ -479,7 +478,9 @@
 
 The encapsulation of registry transaction submissions, registry
 queries and registry responses and exchanges between registries is
-outside the scope of this document.
+outside the scope of this document.  The encapsulation of registry
+transaction submissions and exchanges between registries is covered in
+\cite{draft-ietf-rps-dist-00}.

 \section{Authentication Model}
@@ -496,13 +497,13 @@
 The maintainer contains one or more ``auth'' attributes.  Each
 ``auth'' attribute begins with a keyword identifying the
 authentication method followed by the authentication information
-needed to enforce that method.  For example, where the method is
-identified by the keyword ``pgp-key'' the authentication information
-is the PGP public key block in ASCII radix-64 format.
+needed to enforce that method.  The PGPKEY method is slightly
+syntactically different in that the method PGPKEY is a substring.
 
 Authentication methods currently supported include the following.
-Note that pgp-from is being replaced by the pgp-key (see
-Section~\ref{sec:formats}).
+Note that pgp-from is being replaced by the pgpkey (see
+Section~\ref{sec:formats} and
+\cite{draft-ietf-rps-dbsec-pgp-authent-00}).
 
 \begin{description}
 \item[mail-from]
@@ -526,25 +527,26 @@
 
 \item[pgp-from]
 
-This format is being replaced by the ``pgp-key'' so that the public
+This format is being replaced by the ``pgpkey'' so that the public
 key certificate will be available to remote repositories.  This is
 Merit's PGP extension.  The authentication information is a signature
 identity pointing to an external public key ring.  The maintainer is
 authenticated if the transaction (currently PGP signed portion of a
 mail message) is signed by the corresponding private key.
 
-\item[pgp-key]
+\item[pgpkey]
 
-The authentication information is a PGP public key block in ASCII
-radix-64 format.  The maintainer is authenticated if the transaction
-is signed by the corresponding private key.
+This keyword takes the form ``PGPKEY-hhhh'', where ``hhhh'' is the hex
+representation of the four bytes id of the PGP public key used for
+authentication.  The public key certificate is stored in a separate
+object as described in \cite{draft-ietf-rps-dbsec-pgp-authent-00}.
 
 \end{description}
 
 Repositories may elect to disallow the addition of ``auth'' attributes
 specifying weaker forms of authentication and/or disallow their use in
 local transaction submissions.  Repositories are encouraged to
-disallow the addition of ``auth'' attributes with the depricated
+disallow the addition of ``auth'' attributes with the deprecated
 ``pgp-from'' method.
 
 Any digital signature technique can be used for authentication.
@@ -571,41 +573,6 @@
 to control subdelegation.  Objects are also needed to provide query
 information for other repositories.
 
-A root repository must be agreed upon.  Ideally such a repository
-would contain only top level delegations and pointers to other
-repositories used in these delegations. It would be wise to allow only
-cryptographically strong transactions in the root repository. The
-following might be used to identify a repository (for formal
-description, see~\ref{sec:formats}).
-
-\begin{verbatim}
-  repository:         RIPE
-  query-address:      whois.ripe.net 43
-  response-auth-type: rsa-pubkey some-incredibly-long-public-key
-  response-auth-type: none
-  remarks:            you can request rsa signature on queries
-  submit-address:     mailto://[email-masked]
-  submit-address:     rps-query://whois.ripe.net:43
-  submit-auth-type:   pgp-key crypt-pw mail-from
-  remarks:            these are the authentication types supported
-  mnt-by:             maint-ripe-db
-  refresh:            3600
-  expire:             14400
-  remarks:            refresh and expire same as in DNS SOA
-  ...
-  remarks:            admin and technical contact, etc
-  source:             IANA
-\end{verbatim}
-
-In each repository there should be a special repository object named
-ROOT.  This should point to the root repository or to a higher level
-repository.  This is to allow queries to be directed to the local
-repository but refer to the full set of registries for resolution of
-hierarchically allocated objects.
-
-The ``repository'' object and its usage is described in greater detail
-in Section~\ref{sec:formats}.
-
 
 \subsection{Maintainer Objects}
 \label{sec:maint}
@@ -648,65 +615,20 @@
 of more specific routes.

-\subsection{The reclaim and no-reclaim attributes}
-\label{sec:reclaim}
-
-
-A reclaim attribute is needed in as-block, inetnum and route objects.
-The reclaim attribute allows a control to be retained over more
-specific AS, address or route space by allowing modify and delete
-privileges regardless of the mnt-by in the object itself.  
-
-The reclaim and no-reclaim attributes contain contain lists of objects
-subject to the reclaim and no-reclaim.  See Section~\ref{sec:formats}
-for a full description of the reclaim and no-reclaim attributes.
-
-The reclaim attribute provides the means to enforce address lending.
-It allows cleanup in cases where entities cease to exist or as a last
-resort means to correct errors such as parties locking themselves out
-of access to their own objects.  To allow finer control a set of
-prefixes can be specified.
-
-A no-reclaim attribute can be used to
-provide explicit exceptions.  
-A reclaim attribute can only be added to an existing object if the
-addition of the reclaim attribute does not remove autonomy of existing
-more specific objects that are covered by the new reclaim attribute.
-
-\begin{enumerate}
-\item		A reclaim attribute can be added to an existing object
-		if there are no existing exact matches or more
-		specific objects overlapped by the new reclaim
-		attribute, or
-\item		if the submitter is listed in the maintainer pointed
-		to be the mnt-by of the objects which are overlapped, or
-\item		if any overlapped object is listed in a no-reclaim
-		attribute in the object where the reclaim is being
-		added.
-\end{enumerate}
-
-Similarly a no-reclaim attribute cannot be deleted unless there are no
-overlapped objects for which the submitter is not listed in the
-maintainer pointed to be the mnt-by of the overlapped object.
-
-
-\subsection{AS-block and aut-num objects}
+\subsection{as-block and aut-num objects}

 An ``as-block'' object is needed to delegate a range of AS numbers to a
 given repository.  This is needed for authorization and it is needed
 to avoid having to make an exhaustive search of all repositories to find
 a specific AS.  This search would not be a problem now but would be if
-a more distributed routing repository is used.
+a more distributed routing repository is used \cite{draft-ietf-rps-dist-00}.
 
 The ``as-block'' object also makes it possible to separate AS number
 allocation from registration of AS routing policy.
 
-% \Red{@@ [Do we need a better AS example?] @@}
-
 \begin{verbatim}
   as-block:        AS1321 - AS1335
-  delegated:       ANS
   ...
 \end{verbatim}
 
@@ -739,16 +661,10 @@
 
 \begin{verbatim}
   inetnum:        193.0.0.0 - 193.0.0.255
-  delegated:      RIPE
   ...
   source:         IANA
 \end{verbatim}
 
-This inetnum simply delegates the storage of any more specific inetnum
-objects overlapping the stated range to the RIPE repository.  An exact
-match of this inetnum may exist in the RIPE repository to provide
-hooks for the attributes referencing maintainer objects.
-
 The ``inetnum'' exists to support address allocation.  For external
 number registries, such as those using ``[r]whoisd[++]'' the
 ``inetnum'' can serve as a secondary record that is added when an
@@ -763,22 +679,7 @@
 Currently there are a quite few route objects in more than one
 registry.  Quite a few are registered with origin AS for which they
 have never been announced.  There is a legitimate reason to be in more
-than one origin AS.  With the previous authorization restrictions,
-this could result in a route object for the same prefix in more than
-one database.  The example below is a route registered differently in
-two databases (and registered incorrectly).  This would now require a
-delegation attribute.
-
-\begin{verbatim}
-  route:          128.32.0.0/16
-  delegated:      MCI RADB
-\end{verbatim}
-
-The ``delegated'' attribute should be single valued for all objects
-except those that are granfathered due to addition prior to the use of
-these authorization rules.  This is to prevent race conditions
-involving mutually exclusive additions with the same origin AS in
-different repositories.
+than one origin AS.
 
 The ``route'' object is used to record routes which may appear in the
 global routing table.  Explicit support for aggregation is provided.
@@ -787,6 +688,53 @@
 (Section~\ref{sec:goals}) and to support network problem diagnosis.

+\subsection{reclaim and no-reclaim attributes}
+\label{sec:reclaim}
+
+
+A reclaim attribute is needed in as-block, inetnum and route objects.
+The reclaim attribute allows a control to be retained over more
+specific AS, address or route space by allowing modify and delete
+privileges regardless of the mnt-by in the object itself.  
+
+The reclaim and no-reclaim attributes contain contain lists of objects
+subject to the reclaim and no-reclaim.  See Section~\ref{sec:formats}
+for a full description of the reclaim and no-reclaim attributes.
+
+The reclaim attribute provides the means to enforce address lending.
+It allows cleanup in cases where entities cease to exist or as a last
+resort means to correct errors such as parties locking themselves out
+of access to their own objects.  To allow finer control a set of
+prefixes can be specified.
+
+A no-reclaim attribute can be used to
+provide explicit exceptions.  
+A reclaim attribute can only be added to an existing object if the
+addition of the reclaim attribute does not remove autonomy of existing
+more specific objects that are covered by the new reclaim attribute.
+
+\begin{enumerate}
+\item		A reclaim attribute can be added to an existing object
+		if there are no existing exact matches or more
+		specific objects overlapped by the new reclaim
+		attribute, or
+\item		if the submitter is listed in the maintainer pointed
+		to be the mnt-by of the objects which are overlapped, or
+\item		if any overlapped object is listed in a no-reclaim
+		attribute in the object where the reclaim is being
+		added.
+\end{enumerate}
+
+Similarly a no-reclaim attribute cannot be deleted unless there are no
+overlapped objects for which the submitter is not listed in the
+maintainer pointed to be the mnt-by of the overlapped object.
+
+If neither a reclaim or no-reclaim attribute is present, then more
+specific objects of a given object cannot be modified by the
+maintainer of the less specified object unless the maintainer is also
+listed as a maintainer in the more specific object.
+
+
 \subsection{Other Objects}
 \label{sec:other-objects}
 
@@ -807,9 +755,9 @@
 The first problem can be addressed by considering the name space for
 each of the ancillary objects to be unique only within the local
 database and to use explicit references to an external repository
-where needed.  A possible syntax is to precede the object key with the
-name of the repository and a delimiter.  For example, the delimiter
-``::'' can be used to form the NIC handle ``RIPE::CO19''.  Currently
+where needed.  The object key is preceded by the
+name of the repository and the delimiter ``::''.  For example a NIC
+handle may take the form ``RIPE::CO19''.  Currently
 there is a desire to keep NIC handles unique so the naming convention
 of appending a dash and the repository name is used.  Prepending the
 repository name provides the unique name space since an object in the
@@ -843,6 +791,27 @@
 other objects as needed and as authorization permits.

+\subsection{Objects with AS Hierarchical Names}
+\label{sec:hierarchical-names}
+
+
+Many RPSL objects do not have a natural hierarchy of their own but
+allow hierarchical names.  Some examples are the object types
+``as-set'' and ``route-set''.  An as-set may have a name corresponding
+to no naming hierarchy such as ``AS-Foo'' or it may have a
+hierarchical name of the form ``AS1:AS-Bar''.
+
+When a hierarchical name is not used, authorization for objects such
+as ``as-set'' and ``route-set'' correspond to the rules for objects
+with no hierarchy described in Section~\ref{sec:other-objects}.
+
+If hierarchical names are used, then the addition of an object must be
+authorized by the aut-num for the AS in the name of the object.  The
+authentication must be listed in a maintainer referenced by the
+mnt-lower attribute of the aut-num if present, or if absent, in a
+maintainer referenced by the mnt-by attribute for the aut-num.
+
+
 \subsection{Query Processing}
 \label{sec:query}
 
@@ -885,11 +854,11 @@
 \label{sec:add}

-The root repository must be initially populated at some epoch with a
-few entries.  An initial maintainer is needed to add more maintainers.
-The referral-by and referral-in attribute can be set to refer to itself
-in this special case (Section~\ref{sec:formats} describes the
-referral-by and referral-in).  When adding an inetnum or a route object
+The root repository \cite{draft-ietf-rps-dist-00} must be initially
+populated at some epoch with a few entries.  An initial maintainer is
+needed to add more maintainers.  The referral-by attribute can be set
+to refer to itself in this special case (Section~\ref{sec:formats}
+describes the referral-by).  When adding an inetnum or a route object
 an existing exact match or a less specific overlap must exist.  A
 route object may be added based on an exact match or a less specific
 inetnum.  The root repository must be initially populated with the
@@ -1022,34 +991,17 @@
 \subsection{Changes to the RIPE/RPSL Schema}

-Two object types are added to the RIPE/RPSL schema.  A few attributes
+One object type is added to the RIPE/RPSL schema.  A few attributes
 are added to existing object types.  There are significant changes to
 the rules which determine if the addition of an object is authorized.
 Additional keywords representing new authentication types are added to
 the semantics of the existing ``auth'' attribute.
 
-The new object types are listed below.  The first attribute listed is
+The new object type is listed below.  The first attribute listed is
 the key attribute and also serves as the name of the object type.
 
 \begin{verbatim}
-  repository      key  mandatory  single    unique
-  query-address        mandatory  multiple
-  response-auth-type   mandatory  multiple
-  submit-address       mandatory  multiple
-  submit-auth-type     mandatory  multiple
-  refresh              optional   single
-  expire               mandatory  single
-  descr                optional   multiple
-  remarks              optional   multiple
-  admin-c              mandatory  multiple
-  tech-c               mandatory  multiple
-  notify               optional   multiple
-  mnt-by               mandatory  multiple
-  changed              mandatory  multiple
-  source               mandatory  single
-
   as-block        key  mandatory  single    unique
-  delegated            optional   single
   descr                optional   multiple
   remarks              optional   multiple
   admin-c              mandatory  multiple
@@ -1060,54 +1012,14 @@
   source               mandatory  single
 \end{verbatim}
 
-In the above object types only a small number of the attribute types
-are new.  These are:
+In the above object type only the key attribute ``as-block'' is new:
 
 \begin{description}
-\item[repository]	This attribute provides the name of the
-			repository.  This is the key field for the
-			object and is single and must be globally
-			unique.  This is the same name used in the
-			source attribute of all objects in that
-			repository.
-\item[query-address]	This attribute provides a host name and a port
-			number used to direct queries.  Optional
-			fields may follow the port number at a later
-			time and should be ignored.  Alternately a URL
-			format may be used.  The special protocol
-			identified ``rps-query'' can be used in URL
-			format.
-\item[response-auth-type]  This attribute provides the authentication
-			   types that may be used by the repository
-			   when responding to queries.
-\item[submit-address]	This attribute provides a host name and a port
-			number used to submit objects to the
-			repository.  Optional fields may follow the
-			port number at a later time and should be
-			ignored.  Alternately a URL format may be used.
-			The special protocol identified ``rps-query''
-			can be used in URL format.
-\item[submit-auth-type]	This attribute provides the authentication
-			types that may be used by the repository when
-			responding to queries.
-\item[refresh]		Near real time flooding of repository updates
-			is recommended as a method of distributing
-			database changes.  The refresh suggests a time
-			interval for processing updates.  Time is in
-			seconds if expressed as an integer.
-			Alternately, the letters ``h'', ``m'', or
-			``s'' can be used to indicate hours, minutes,
-			and seconds.
-\item[expire]		If near real time flooding is temporarily not
-			operational, objects should be considered
-			non-authoritative after this interval, and
-			cannot be used for authorization purposes.
 \item[as-block]		This attribute provides the AS number range
-			for an ``as-block'' object.
-\item[delegated]	This attribute indicates that further searches
-			for object in the hierarchy must be made in one
-			or more alternate repositories.  The current
-			repository may be listed.
+			for an ``as-block'' object.  The format is two
+			AS numbers including the substring ``AS''
+			separated by a ``-'' delimiter and optional
+			whitespace before and after the delimiter.
 \end{description}
 
 In order to support stronger authentication, the following keywords
@@ -1117,10 +1029,9 @@
 \item[pgp-from]		The remainder of the attribute gives the
 			string identifying a PGP identity whose public
 			key is held in an external keyring.  The use
-			of this method is depricated in favor of
-			the ``pgp-key'' method.
-\item[pgp-key]		The remainder of the attribute provides a PGP
-			public key block in ASCII radix-64 format.
+			of this method is deprecated in favor of
+			the ``pgpkey'' method.
+\item[pgpkey]		See \cite{draft-ietf-rps-dbsec-pgp-authent-00}.
 \end{description}
 
 In order to disable authentication and give permission to anyone, the
@@ -1136,21 +1047,38 @@
 A few attributes are added to the schema.  These are:
 
 \begin{description}
-\item[mnt-routes]	The mnt-routes attribute may appear in an aut-num,
-			inetnum, or route object.  This attribute
-			references a maintainer object which is used
-			in determining authorization for the addition
-			of inetnum and route objects.  If a mnt-routes
-			object is absent, the mnt-by attribute is used
-			for this purpose.  The mnt-routes attribute is
-			optional and multiple.  the format is
-			identical the the exiting ``mnt-by'' but has
-			an additional optional range preceeding the
-			authorization information.  The syntax for the
-			range is the word ``range'' followed by a
-			prefix lists (as defined in RPSL) in curly
-			braces (``\{`` and ``\}'') as used elsewhere
-			in RPSL.
+\item[mnt-routes]	The mnt-routes attribute may appear in an
+			aut-num, inetnum, or route object.
+			When used with a aut-num, inetnum, or route
+			object, this attribute references a maintainer object
+			which is used in determining authorization for
+			the addition of route objects.  When placed in
+			a less specific inetnum it is used in
+			determining authorization for the addition of 
+			more specific inetnum objects.
+			After the reference to the
+			maintainer, an optional list of prefix ranges
+			(as defined in RPSL) inside of curly braces or
+			the keyword ``ANY'' may follow.  If a mnt-routes  
+			attribute is absent, the mnt-lower or mnt-by
+			mnt-by attribute is used for this purpose.
+			The mnt-routes attribute is optional and multiple.
+\item[mnt-lower]	The mnt-lower attribute may appear in an
+			inetnum, route, as-block or aut-num object.
+			This attribute references a maintainer object.
+			When used in an inetnum or route object the
+			effect is the same as a ``mnt-routes'' but
+			applies only to prefixes more specific than
+			the prefix of the object in which it is
+			contained.  In an as-block object, mnt-lower
+			allows addition of more specific as-block
+			objects or aut-num objects.  In an aut-num object
+			the mnt-lower attribute specifies a maintainer
+			that can be used to add objects with
+			hierarchical names as described in
+			Section~\ref{sec:hierarchical-names}.  If a
+			mnt-lower attribute is absent, the mnt-by
+			attribute is used.
 \item[reclaim]		The reclaim attribute may appear in as-block,
 			aut-num, inetnum, or route objects.  Any
 			object of the same type below in the hierarchy
@@ -1166,12 +1094,6 @@
 			negates any reclaim attribute it overlaps.
 			See Section~\ref{sec:reclaim} for restrictions
 			on deleting no-reclaim attributes.
-\item[delegated]	The delegated attribute is  allowed in any
-			object type with a hierarchy.  This attribute
-			indicates that further searches for object in
-			the hierarchy must be made in one or more
-			alternate repositories.  The current
-			repository may be listed.
 \item[referral-by]	This attribute is required in the maintainer
 			object.  It may never be altered after the
 			addition of the maintainer.  This attribute
@@ -1179,14 +1101,12 @@
 			maintainer.  It may be multiple if more than
 			one signature appeared on the transaction
 			creating the object.
-\item[referral-in]	This attribute may appear in a maintainer
-			object.  It is multiple.  Each time the
-			maintainer object is used to add another
-			maintainer, a referral-in referencing the new
-			maintainer is automatically added.
 \item[auth-override]	An auth-override attribute can be added,
 			deleted, or changed by a transaction submitted
-			by maintainer listed in the referal-by.  The
+			by maintainer listed in the referral-by.  An
+			auth-override can only be added to a
+			maintainer if that maintainer has been
+			inactive for the prior 60 days.  The 
 			auth-override attribute itself contains only
 			the date when the attribute will go into
 			effect which must be at least 60 days from the
@@ -1194,7 +1114,7 @@
 			authorization to modify the maintainer.  After
 			the date in the auth-override is reached,
 			those identified by the maintainer in the
-			referal-by have authorization to modify the
+			referral-by have authorization to modify the
 			maintainer.  This attribute exists as a means
 			to clean up should the holder of a maintainer
 			become unresponsive and can only take effect
@@ -1221,11 +1141,7 @@
 ``referral-by'' attribute is now mandatory in the ``maintainer'' object
 to keep a record of which maintainer made the addition and can never
 be changed.  Maintainers cannot be deleted as long as they are
-referenced by a ``referral-by'' attribute elsewhere.  In order to add a
-maintainer to another database, a ``referral-in'' attribute is needed,
-containing the name of the external database.  A ``referral-in''
-attribute cannot be deleted unless there are no ``referral-by''
-references to the maintainer in the named external databases.
+referenced by a ``referral-by'' attribute elsewhere.

 \appendix
@@ -1291,7 +1207,7 @@
 for existing maintainers.  The requirement then should be relaxed such
 that existing maintainers may remain but only existing maintainers
 that have a ``referral-by'' attribute can add maintainers.  The
-``referral-by'' and ``referral-in'' cannot be modified.  This
+``referral-by'' cannot be modified.  This
 requirement can be relax slightly so that a ``referral-by'' can be
 added to a maintainer by an existing maintainer with a ``referral-by''.
 This will allow the accountability trail to be added to existing
@@ -1502,17 +1418,9 @@
 Superaggregates of this type will generally be formed by topologically
 close entities who have also managed to draw adjacent address
 allocations.  In effect, the registry must give permission to form
-such as superaggregate by either giving permission to do so in an
-inetnum or by signing the submission along with the other parties.
-
-A more common case is where a more specific route object must be
-registered with a different AS than the aggregate due to the prefix
-being multihomed.  In this case, the maintainer of the aggregate can
-create a more specific route object with their own AS marked withdrawn
-so as not to be routable.  The new AS can be included in the
-maintainer solely for the purpose of allowing them to create a new
-route object with their own AS.  Again, alternately both parties can
-sign the submission for the addition with the new AS.
+such as superaggregate by either giving permission to do so in the
+mnt-routes of an inetnum or by signing the submission along with the
+other parties.

 \subsection{provider independent addresses and multiple origin AS}
@@ -1521,8 +1429,8 @@
 Provider independent addresses and multihoming arrangement using
 multiple origin AS present a similar problem to multihoming.  The
 maintainer of the address space and the maintainer of the AS is not
-the same.  Permission can be granted using additions to the maintainer
-or multiple signatures can appear on the submission.
+the same.  Permission can be granted using mnt-routes or multiple
+signatures can appear on the submission.

 \subsection{change in Internet service provider}
@@ -1531,11 +1439,8 @@
 A change in Internet service providers is similar to multihoming.  A
 minor difference is that the AS for the more specific route will be
 the AS of the new provider rather than the AS of the multihomed
-customer.  A provider may be hesitant to give permissions to their
-competitor to make additions with their AS.  There is no potential for
-harm in giving permission to a withdrawn exact match of the more
-specific so the maintainer of the aggregate could more easily in
-effect grant permission to the maintainers of the new AS.
+customer.  Permission can be granted using mnt-routes or multiple
+signatures can appear on the submission.

 \subsection{renumbering grace periods}
@@ -1677,7 +1582,9 @@
 
 This document draws ideas from numerous discussions and contributions
 of the IETF Routing Policy System Work Group and RIPE Routing Work
-Group.
+Group.  Earlier drafts of this document listed Carol Orange as a
+co-author.  Carol Orange made contributions to this document while at
+RIPE.

 % References
@@ -1688,9 +1595,9 @@
 \section*{Security Considerations}

-\Red{@@ This entire document is about security but at some point we
-need to figure out what belongs here in this case.  Maybe the Area
-Directors can provide some advice.}
+{\color{red} @@ This entire document is about security but at some
+point we need to figure out what belongs here in this case.  Maybe the
+Area Directors can provide some advice.}

 \section*{Author's Addresses}
@@ -1698,7 +1605,7 @@
 
 \begin{verbatim}
 Curtis Villamizar
-ANS Communications
+UUNET Network Architecture Group
 <[email-masked]>
 \end{verbatim}
 
@@ -1710,8 +1617,8 @@
 
 \begin{verbatim}
 David M. Meyer
-University of Oregon
-<[email-masked]>
+Cisco
+<[email-masked]>
 \end{verbatim}
 
 \begin{verbatim}
@@ -1720,10 +1627,32 @@
 <[email-masked]>
 \end{verbatim}
 
-\begin{verbatim}
-Carol Orange
-RIPE NCC
-<[email-masked]>
-\end{verbatim}
+\section*{Full Copyright Statement}
+
+    Copyright (C) The Internet Society (\today).  All Rights Reserved.
+
+    This document and translations of it may be copied and furnished
+    to others, and derivative works that comment on or otherwise
+    explain it or assist in its implmentation may be prepared, copied,
+    published and distributed, in whole or in part, without
+    restriction of any kind, provided that the above copyright notice
+    and this paragraph are included on all such copies and derivative
+    works.  However, this document itself may not be modified in any
+    way, such as by removing the copyright notice or references to the
+    Internet Society or other Internet organizations, except as needed
+    for the purpose of developing Internet standards in which case the
+    procedures for copyrights defined in the Internet Standards
+    process must be followed, or as required to translate it into
+    languages other than English.
+
+    The limited permissions granted above are perpetual and will not
+    be revoked by the Internet Society or its successors or assigns.
+
+    This document and the information contained herein is provided on
+    an ``AS IS'' basis and THE INTERNET SOCIETY AND THE INTERNET
+    ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
 \end{alltt}