Subject: Re: rps auth todo list

From: Curtis Villamizar <[email-masked]>
Date: Tue, 16 Feb 1999 22:01:27 -0500

Please review the preview at:

  http://engr.ans.net/rps-auth

Annotated diffs at the end of this message.

In message <[email-masked]>, Cengiz Alaettinoglu writes:
> 
> Curtis,
> 
> Here is a summary of our December WG discussion on rps-auth. Please
> make the appropriate changes to the document, and issue a WG last call 
> to move it to proposed standard:
> 
> - add syntax of mnt-routes which is:
> 	list of 1. <mntnr>
> 		2. <mntnr> KEYW_ANY
> 		3. <mntnr> { list of address prefix ranges }
> 
>    the 1 and 2 are equivalent in semantics. The syntax is negotiable
>    but needs to be explicit.

Please note that this was already in the draft.  The format was
slightly different than what you have listed above.  The following
text has been removed.

   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.

The entry now reads (latex source format):

  \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.  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
                        object is absent, the mnt-by attribute is used
                        for this purpose.  The mnt-routes attribute is
                        optional and multiple.

> - add mnt-lower: <list of maintainers>. 
> 
> - you may consider adding an early section which contains the syntax
>   and semantics of mnt-routes, mnt-lower, and mnt-by and states:
> 
> 	when authorizing a route object look at mnt-routes, if it does 
> 	not exist, look at mnt-lower, if that does not exist either look at
> 	mnt-by 
> 
> 	For all other objects loot at mnt-lower followed by mnt-by.

  \item[mnt-lower]      The mnt-lower attribute may appear in an
                        inetnum, route, or aut-num object.  This attribute
                        references a maintainer object.  Its effect in
                        an inet-num or route object is the same as a
                        ``mnt-routes'' but applies only to prefixes
                        more specific that the prefix of the object in
                        which it is contained.  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}.

> - delete referral-in (since it can be done by reverse lookup on
>   referral-by) 

Done.  All references to referral-in are gone.

> - I forgot what we agreed on what to do when authorizing a route
>   object r and we hit a less specific route object which has a hole
>   covering the route object r.

Holes are ignored.  They are a comment field only.

> - auth-override is only placable if there is no activity by the
> maintainer it is placed on in the last 60 days and it is only
> effective after 60 days.

The change to the existing spec is that auth-override cannot be added
if there has been any activity in the last 60 days.  This change has
been made.

> - decide the defualt of reclaim/no-reclaim, and make it explicit in
> the document

There was no response to my request for comment.

The default is the same as it is in the current database.  It is
no-reclaim.  Registries wishing to reclaim should do so by adding a
reclaim attribute to top level objects.

> - add as-set, route-set, rtr-set, filter authorization. These have
> names like AS1:as-foo. They authorized by the object whose key is the
> same name except the last part (already in rpsl document, same
> mnt-lower, mnt-by mechanism when the name is hierarchical).

Added:

  \subsection{Objects with AS Hierarchical Names}
  \label{sec:hierarchical-names}

  Many RPSL objects do not have a natural hierachy 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 by
  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.

> - delete the repository object and delegated attribute discussions and
> move them to the rps-dist document

This move has been done.  The original split up was all RPSL changes
go into rps-auth and the syntax of database exchange goes in rps-dist
but this separation of the two documents also makes sense.

There are still many references in rps-auth to the idea of having more
than one repository and issues that arise in the rps-auth document.
This has to remain since the authorization model reflects the needs of
distributing the repository.

> - move reclaim/no-reclaim/auth-overrride to the end of the document
> (they are not first things to implement).

Implementation order in BIRD should not dictate order in the document.

I moved these down past "as-block and aut-num objects", "inetnum
objects", and "route objects" but before "other objects" since
"reclaim and no-reclaim attributes" are applicable to as-block,
aut-num, inetnum, and route but not the other objects.

> Cengiz

I also changed the references to pgp-key to match the use of key-cert
and PGPKEY-<id> described in rps-dbsec-pgp-authent.

Curtis

ps- sections are now:

\section{Overview}
\section{Background}
\section{Implicit Policy Assumptions}
\section{Organization of this Document}
\section{Goals and Requirements}
\section{Data Representation}
\section{Authentication Model}
\section{Authorization Model}
  \subsection{Maintainer Objects}
  \subsection{as-block and aut-num objects}
  \subsection{inetnum objects}
  \subsection{route objects}
  \subsection{reclaim and no-reclaim attributes}
  \subsection{Other Objects}
  \subsection{Objects with AS Hierarchical Names}
  \subsection{Query Processing}
  \subsection{Adding to the Database}
  \subsection{Modifying or Deleting Database Objects}
\section{Data Format Summaries}
  \subsection{Changes to the RIPE/RPSL Schema}

\appendix
\section{Technical Discussion}
  \subsection{Relaxing requirements for ease of registry}
  \subsection{The address lending issue}
  \subsection{Dealing with non-conformant or questionable older data}
\section{Common Operational Cases}
  \subsection{simple hierarchical address allocation and route allocation}
  \subsection{aggregation and multihomed more specific routes}
  \subsection{provider independent addresses and multiple origin AS}
  \subsection{change in Internet service provider}
  \subsection{renumbering grace periods}
\section{Deployment Considerations}

Annotated diffs.  Diffs indented by 4 spaces.  Recover diffs only with:

  grep '^    ' | sed 's,^    ,,'

    Index: rps-auth.rfc
    ===================================================================
    RCS file: /usr/local/CVS-routing-dev/doc/ietf/rps-sec/rps-auth.rfc,v
    retrieving revision 1.13
    diff -u -r1.13 rps-auth.rfc
    --- rps-auth.rfc	1998/05/15 20:33:26	1.13
    +++ rps-auth.rfc	1999/02/17 01:59:17
    @@ -13,7 +13,7 @@
     \author{Carol Orange}
     \address{RIPE}
     \footer{Villamizar, et. al.}
    -\filename{draft-ietf-rps-auth-01}
    +\filename{draft-ietf-rps-auth-02-preview}
     \begin{document}
     \begin{alltt}
     \bibliographystyle{plain}

Filename change to 02-preview.

    @@ -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}

This is just making full sentences in the bullet list.  Editorial
change - it reads better.

    @@ -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

This assumes RPSL will be the basis of the IRR by the time this is
published.

    @@ -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}

draft-ietf-rps-extending-00 was folded into RPSL.  The transition doc
is going to vaporize so we can't cite it.  spell check changes.
Changed future tense to present tense.

    @@ -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,

Spell check.

    @@ -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

Spell check.

    @@ -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}

Cite rps-dist.

    @@ -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]

The pgp-key described in this draft is superceded by the PGPKEY-<id>
form described in rps-dbsec-pgp-authent.

    @@ -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.

Same - replace pgp-key with PGPKEY-<id> from rps-dbsec-pgp-authent.
Also another spell check catch.

    @@ -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}

Stuff moved to rps-dist.

    @@ -648,56 +615,14 @@
     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.

Subsection relocated a few subsections down.

    @@ -706,7 +631,6 @@
     
     \begin{verbatim}
       as-block:        AS1321 - AS1335
    -  delegated:       ANS
       ...
     \end{verbatim}
     
    @@ -739,16 +663,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

The "delegated" attribute is moved to rps-dist.

    @@ -763,22 +681,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.

The "delegated" attribute is moved to rps-dist.  With it goes this
point about grandfathering dual origin routes in different
repositories.

    @@ -787,6 +690,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}

Section was relocated from above.  Default is no-reclaim.

    @@ -807,9 +757,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

Changed this from a suggestion to the choice of syntax and delimiter.

    @@ -843,6 +793,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 by
    +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}

Added a subsection to handle the hierarchical naming in some objects.

    @@ -885,11 +856,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

Cited rps-dist since that is where "root repository" is described.

    @@ -1022,34 +993,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

The "repository" object was moved to rps-dist.

    @@ -1060,54 +1014,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

More deletions due to moving "repository" to rps-dist.

    @@ -1117,10 +1031,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

Drop pgp-key in favor of pgpkey from rps-dbsec-pgp-authent.

    @@ -1140,17 +1053,25 @@
     			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
    +			of inetnum and route 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  
     			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.
    +			optional and multiple.
    +\item[mnt-lower]	The mnt-lower attribute may appear in an
    +			inetnum, route, or aut-num object.  This attribute
    +			references a maintainer object.  Its effect in
    +			an inetnum or route object is the same as a
    +			``mnt-routes'' but applies only to prefixes
    +			more specific that the prefix of the object in
    +			which it is contained.  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}.
     \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

Changed mnt-routes syntax.  Added mnt-lower.

    @@ -1166,12 +1087,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

Moved "delegated" attribute to rps-dist.

    @@ -1179,14 +1094,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

Dropped referral-in.  Added limitation to only add auth-override if
the maintainer has been idle for 60 days.

    @@ -1194,7 +1107,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

Spell referral correctly.

    @@ -1221,11 +1134,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

Remove referal-in.

    @@ -1291,7 +1200,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

Remove referal-in.

    @@ -1502,17 +1411,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}

The "withdrawn" attribute has been withdrawn.

    @@ -1521,8 +1422,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}

Using mnt-routes is a better way to do this.

    @@ -1531,11 +1432,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}

The "withdrawn" attribute has been withdrawn.  Options are
straightforward.  Either use mnt-routes or everyone that needs to
grant authorization signs the addition before submitting.

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Thu, 18 Feb 1999 18:25:09 -0800 (PST)

Please dont forget to add:
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

Minor comment below. I will read the whole thing again but the diffs
looks satisfactory to me.

>                         of inetnum and route objects.  After the

addition of route objects only

>                         object is absent, the mnt-by attribute is used
 
s/object/attribute/

If a mnt-routes attribute is absent, the mnt-lower attribute, 
and if mnt-lower attribute is absent, the mnt-by attribute is used

>                         an inet-num or route object is the same as a

an inet-num, route or aut-num

>                         more specific that the prefix of the object in

s/that/than/

>                         the mnt-lower attribute specifies a maintainer

also specifies

>                         Section~\ref{sec:hierarchical-names}.

If a mnt-lower attribute is absent, the mnt-by attribute is used.

(i.e.
	for route authorization		mnt-lower in aut-num, route, inet-num
	for inet-num authorization	mnt-lower in inet-num
	for set authorization		mnt-lower in aut-num or other sets
	for as-block, aut-num auth      mnt-lower in as-block
basically, any time mnt-by would be consulted, consult mnt-lower if it 
exist)

>   authorized by the aut-num for the AS in the name of the object.  The

s/by/be/

If hierarchical names are used, then the addition of an object must be
authorized by the object whose name is the same except the last
suffix following ':' is dropped

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Feb 1999 13:27:04 -0500

> addition of route objects only

more specific inetnum if in an inetnum.

> an inet-num, route or aut-num

An aut-num does not have a prefix so the mnt-lower cannot carry the
meaning "more specific than this".

> >                         the mnt-lower attribute specifies a maintainer

A mnt-lower in an aut-num allows heirarchical names but does not allow
adding route objects.

> 	for route authorization		mnt-lower in aut-num, route, inet-num
                                                     ^^^^^^^ wrong
> 	for as-block, aut-num auth      mnt-lower in as-block

This now reads:

  \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.

> suffix following ':' is dropped

That object has to be an aut-num since these sets are used exclusively
to make it easier to express policy.  If not, we have another creeping
feature in RPSL with no purpose.

Curtis

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Thu, 11 Mar 1999 14:13:26 -0800 (PST)

Sorry for the late reply, I was away for a while.

> more specific inetnum if in an inetnum.

The name "mnt-routes" is not good then. 

I am not sure if this functionality is actually useful for inetnums.

> > an inet-num, route or aut-number
> 

"lower" does not necessarily mean "more specific". For example, 
AS1:AS-CUSTOMERS is under AS1's control. In my opinion this is lower.

It is also useful to check mnt-lower when mnt-routes was not specified.

I.e.

To authorize any object (except route objects) that depends on the
object at hand, use maintainers in mnt-lower, if none, use maintainers
in mnt-by.

To authorize a route object that depends on the object at hand, use
maintainers in mnt-routes, if none use maintainers in mnt-lower, if
none, use maintainers in mnt-by.

I think these two rules are simpler, more consistent and easy to
extend for future objects.

>                         more specific inetnum objects.

The last sentence depends on what we decide. It is kind of a
misnomer. See comment above.

>                         The mnt-routes attribute is optional and multiple.

You may want to make the new text more explicit that the fall back to
mnt-lower happens when mnt-routes is missing from inetnum, aut-num, or
route objects. Right now, it is not clear if this fall back is only
for inetnum or for all three object classes.

>                         mnt-lower attribute is absent, the mnt-by

This is OK.

> feature in RPSL with no purpose.

How about you wanted to create a set for each one of your customers?
	<youras>:<set name>:<customeras>
E.g.
	AS1:AS-Customer-Customers:AS2
as in
	from AS1:AS-CUSTOMERS import AS1:AS-Customer-Customers:PeerAS

(So AS1 does not rely on customer to populate AS2:AS-Customer, instead
it uses sets that it can control).

In this case RPSL says the maintainer should come from
AS1:AS-Customer-Customers.

With what you wrote in the draft, the maintainer comes from AS1.

Cengiz

-- 
Cengiz Alaettinoglu           Information Sciences Institute
http://www.isi.edu/~cengiz    University of Southern California

---

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

> I am not sure if this functionality is actually useful for inetnums.

Then we can bring it up in the meeting.  We can drop it (for inetnums)
before last call if there is agreement in the WG.

> AS1:AS-CUSTOMERS is under AS1's control. In my opinion this is lower.

I think you are arguing against the old text that I already agreed to
change.  Below you state that the mnt-lower definition is OK so I'll
assume we are in agreement on this.

> misnomer. See comment above.

Yep.

> for inetnum or for all three object classes.

OK.  Clarification needed.

> >                         mnt-lower attribute is absent, the mnt-by

Good.  The less change at this point, the better.

> AS1:AS-Customer-Customers.

This is a clear mistake in rps-auth.  My fault.

> With what you wrote in the draft, the maintainer comes from AS1.

I got it wrong.  Thanks.  I'll have to fix this before we go to last
call.  I need to fix the slides as well.

Curtis