Subject: RPS WG Minutes

From: <[email-masked]>
Date: Wed, 4 Aug 1999 12:03:07 -0700 (PDT)

The presentation slides from our last meeting are at:
    ftp://ftp.isi.edu/rps/oslo-ietf

And here are the minutes:

RPS WG Minutes
Taken by Susan Harris & Curtis Villamizar

Cengiz:  Update on draft-ietf-rps-dist
--------------------------------------
Cengiz' presentation focused on changes made to the draft since the last
IETF.  These are mainly fairly minor syntax changes, as follows:
 
-Modifications to transaction submission encapsulation, with a submission
 defined as a collection of  RPSL objects.  It's now possible for
 submitters to add a timestamp meta-object, which can be used to guard
 against replay attacks.  This applies to local submissions, i.e.,
 submissions to a respository by a user or process.  A set of submission
 processing rules determined how these are handled by the respository.

-Modifications to transaction redistribution, which itself has two phases:
 preparing the redistributed text with the appropriate identification and
 authentication information, and preparing an on-the-wire representation
 of the transmitted text.  New  transaction labels contain information about
 the originating repository, the sequence number, repository timestamp,
 and, optionally, the transaction's authorization status.  Transaction
 labels are never modified by intermediate repositories. Before
 transmitting the redistributed text, the originating registry adds a
 (new) transaction-begin meta-object specifying the length of the redistributed
 text and encoding method.

New transaction processing rules outline the steps the repository must
take before registering the object. 

Useful new capabilities are available for requesting an exchange of
objects between two repositories.  A request can now specify something
like "I already have objects in sequence up to number xx -  send me any
additional records as they're submitted to you."   In this process, known
as flooding, the connection stays open so new objects can be transmitted.
New heartbeat messages containing the highest sequence number and
timestamp are used to resynchronize the two repositories after a restart
and to recognize partitioned registries. In one mode of operation a
sequence range (from xxx to yyy) is requested. 

Cengiz presented a proposal for an authorization hierarchy rooted at
ICANN.

  The public key of the hierachy root is distrubuted with the
  software.

  The root of the authorization hierarchy contains:
    a 0/0 intenum
    an as-block with 0-65,535
  ICANN needs to register and sign these.
  ICANN does not need to run a repository.

  To create other registories the following objects are needed:
    a repository object
    repository key certificate(s)
    repository maintainer object(s)
  These need to be signed by ICANN.

  Randy Bush pointed out that the IAB has an official relationship
  with IANA for operational issues such as this where ICANN is more of
  a policy making body.  After a bit of dicsussion there was consensus
  to change ICANN to IANA.

Joao presented a proposal to specify a common query language.

  In one of his slides Joao presented a table of current
  implementations.  There were 4 implementations in the table with 4
  query formats.

  Essentially a few questions were asked by the presentation:
    Is a common query language needed?
    Does anyone have any ideas as to what it should look like?
    Should it support the IRR needs only?
    Should it be separate from whois?
    Should there be a common subset with extensions for different
    uses?

  The following comments were made.  IRRd wants to be compatible with
  RIPE.  The RIPE query language doesn't adequately support queries
  needed for router configs.

  The final questions were: Should these query formats be compatible?
  Should they be be standardized?  

  Randy Bush commented that this should not be done in this group.
  Curtis and DAvid Kessens suggested that RIPE should be a good
  candidate.  Consensus seemed to be "yes" for both questions but a
  RIPE WG would be a better place to do the standardization than IETF.

Joao presented the RIPE database re-implementation.

  Performance is not what it should be in the current implementation.
  There are about 280,000 objects and a high query load.

  Code maintenance is also an issue.  The code has been evolving and
  is now difficult to maintain and extend.

  A block diagram was presented showing how the components of the
  current server fit together.

  A block diagram was presented showing the components of the new
  server.  The new implementation can be distributed over multiple
  machines.

  The new server is split by functionality, with a (commercial) RDBMS
  at bottom.  A lot of functional block are currently being
  implemented and will be tested in the end of July.  A test server
  should be available in August.

  For more info there is a mailing list under majordomo.  The
  information on this is at http://www.ripe.net/db.

  There are plans to implement the core part of rps-auth ASAP.  The
  non-core part of rps-auth may be implemented later.  There are no
  plans for rps-dist yet and no decision to go forward with rps-dist.
  RIPE needs proof that there is some gain to doing rps-dist.

Craig Labvitz presented the status of IRRd and Merit transition to
RPSL.  These were Gerald Winters' slides.

  There are two RIPE-181 machines, and one RPSL machine.

  Merit allows RPSL queries only today.  Merit will start allowing
  RPSL submissions RSN.

  On July 1st there were 35,307 connections, 262,049 queries using
  RIPE-181.  In four months there were 80,234 connections, 80,679
  queries.

  Craig asked if anyone minded if the default submission format was
  switched to RPSL.  There were no objections.

  Code is available for IRRd.  It is fast, etc.  Development of
  rps-auth is underway.  Development of rps-dist is on the back
  burner.

  There seem to be about 40 sites that are doing regular mass queries
  that may or may not be configuring routers.

  Cengiz commented that he sees a lot more usage of RaToolSet and bug
  reports on RaToolSet since MERIT went production on RPSL IRRd as
  opposed to the older non-supported server.

Cengiz gave a presentation on the status of BIRD.

  There is an alpha implementation available now.  The production
  release should be available at end of summer.  The URL is
  ftp://ftp.isi.edu/ra/BIRD.

  There are 2 parts to the software architecture.  The registrar
  handles registration.  The server handles queries.

  Berkeley DB was used.  Reasons include the following.  It is
  recoverable.  It supports a shared cache between processes
  implemented using mmap.  It offers superior performance to
  alternatives including RDBMS.  The latter conclusion was based on
  tests run against postgress and GDBM.

  Some key features of the server are, non-blocking, non-forking,
  cache, good indices (supports fast lookup, no computation).

  Some key features of the query language are the following.  an
  attempt was made to be like the RIPE server.  There is functionality
  missing from the RIPE query format that is needed to support tools.
  BIRD adds 4 queries (that begin with -bird is launched from whois).

  Key feature of the register include the following.  It supports all
  of RPSL.  The core rps-auth functionality is done.  The non-core
  will be done later.  All of rps-dist is done except snapshot.  BIRD
  also supports ftp transfer and ripe real time mirror.

  Performance is excellent except cold start which takes 4-5 hours.
  Cold start in this context means starting from initial ftp of
  repositories and only has to be done once ever.  There is no
  reindexing in this architecture.

  Some user tools are missing.  Tools for the registrar are email,
  web-cgi.  Both need to be written.  Tools for the server are
  RaToolSet and a web/cgi interface.  RaToolSet works.  The web/cgi
  needs to be written.

  The configuration supports general options, repositry configs,
  language extension options.

  Configuration is in RPSL format but is not stored in the database.

  The local repository configuration includes whether the repository
  is public or private and if public whether specific classes of
  objects are private.

  The remote repository configuration lists the remote repositories.
  Discovery can be enabled.  Discovery means an repository mirrored by
  a peer is mirrored.

  The legacy repository configuration includes whether the legacy
   repository can do ftp or real time mirror or both.  For example,
   you can mirror every 30 minutes and ftp once a day from a
   repository.  It automatically converts RIPE-181 to RPSL.

  The set of classes accepted is configurable.  The classes are
  extensible using the RPSL dictionary capability.

  BIRD implements rps-auth core now.  It does rps-dist replictation.
  It will do rps-dist snapshot soon.

Cengiz presented the work group document status and futures.

  RPSL has been PS.  It could be advanced to Draft
  status.  The applications doc is at -06.  It has passed the IESG
  review as an informational document and is thought to be in the
  rfc-editor hands.

  The were minor changes to rpsl-auth.  There were spelling errors and
  grammar errors.  There are now definitions of non-core and core
  functionality.

  The rpsl-dist document still needs at least one major revision.

  The rps-auth draft did not go into the internet drafts
  directory for some reason.  Curtis will resubmit as soon as IETF is
  over.  Most important is rps-auth -04 version.