update: minutes, DB-WG meeting, RIPE-23, Jan.96, Amsterdam

  This is the updated minutes of the RIPE-23, Jan.96, DB-WG meeting.

  Corrections submitted by David Kessens wrt 
  "network updates" and "security" have been included.

  Best regards,
  Wilfried.

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 	Draft Minutes: Database-WG, RIPE 23, Amsterdam, NL
	------------------------------------------------------

0.	Administrative stuff

  Kurt Kayser, ECRC, volunteered to take notes.

  The WG meeting was split into two sessions

    - part 1 to deal with currnt topic, problems and ideas

    - part 2 the more traditional stuff

  The proposed WG-agenda was accepted.


1.	Databases and registries

  B. Manning's review of the 192.0.0.0/8 address range prompted a brief
  discussion of where the authoritative information should be maintained.
  The general feeling was that networks used in Europe should be 
  documented in the RIPE-DB.
  
  [ 
    A comment was received after the WG-meeting to ask the Internic 
    (and other registries?) to expand the standard referral text ("The
    InterNIC Registration Services Host contains...") to include pointers
    to the RIPE-DB and maybe other registry sources.
  ]

  From the user's point of view it would be very convenient to send
  updates to a "local" database and have the software forward the
  message(s) to the appropriate database(s) according to the source:
  attribute.

  Currently the RIPE-NCC holds copies of the following databases: RA,
  MCI, APNIC, CA*Net - but NOT the InterNIC.
  
  While things are to improve with the introduction of the shadow-dbs,
  mirror copies are always sort of out-dated by definition. 
  RIPE intends to have a 10min delay.
  
  Other problems identified:

  - uniqueness of names / keys across different databases

  - lookup and processing of entries from more than one DB 
    (e.g.  evaluate AS-Macros from different DB...) 
    -> minority problem for the time being.

  - quality control on information, 
    . like duplicate entries alert,
    . automatic handle assignment, 
    . semantics for more than one person object for a given individual
    . Registry ID information is maintained manually, this might change
      by building links to objects in the public database.


2.      User interface(s)

  - access to the data in a more clever (selective) way by WAIS and/or
    WWW. 
    A. Blasco Bonito and Paolo Bevilacqua have a test-version available
    for a WWW interface that supports logical AND and OR of keys.

  - whois "help"
    gives on-line documentation
    hypertext version being considered
    
  - An on-line survey form is available via the RIPE-NCC web pages,
    you are invited to use it to describe your wishes for access to data
    kept at the RIPE-NCC.

  - RADB/Merit has a web interface for queries and updates, 
    although this obviously works for auth: NONE or MAIL-FROM only

  - proposal: put a pointer to whois "help" into ripe-104++
  

3.	Authorization and Security

  DFK reports that development work is on the action list (PGP facilities
  to be integrated) but there is still a severe lack of resources.
  Additional help is needed to make real progress, because design work is
  necessary first. Th Key management would most probably be done according
  to the Merit approach. We might benefit from (Euro-)CERT activities?

  In more general terms, if we want to see development progress faster
  than in the past, then we have to come up with clearly defined needs
  and a proposal for a devlopment project with additional resources.


4.	DB-SW report

  David Kessens offered the traditional database software report.
  The slides can be obtained from
  
ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DB-REPORT.ps.gz

  Another set of slides for the In-Addr-Check handling is available from
  
ftp://ftp.ripe.net/ripe/presentations/ripe-m23-david-DNS-INADDRCHECK.ps.gz

  - beta version V1.1 that allows (close to) real-time mirroring is
    available. At the time of writing these minutes (4-MAR-1996) the
    distribution is at
    
ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-1.1beta2.tar.gz

  - requests to run a mirror copy are to be sent to ripe-dbm at ripe.net

  - other changes include
    . support for the BSD DB package
    . a password controlled mechanism to overrule normal security
      mechanisms (e.g. for adding maintainers and the like)
    . "network updates" are now fully supported by the RIPE-DB SW.
      Fully supported means:
      	"If your address is in the RIPE-DB access list"
	However, this is a very powerful method and currently does not
	provide enough data for the logs to track down problems.
	For further study, before being made available to the community
	at large.
    . less memory consumption
    
  In conjunction with the mirror capability, the software has to keep
  track of individual object creations and updates. The mechanism that is
  currently used is not suitable for long-term consistency (because the
  sequntially increasing values are expected to suffer from wrap-around,
  eventually). 
  Thus a stored: attribute was proposed and accepted. 
  
	stored: <NEW | UPD> <Date> <Time> <Serial>

  Inclusion of the authorisation method used and the source of the update
  was then asked for. DFK is going to circulate a detailed proposal.
  
  In general the NCC proposes to use a keyword based mechanism on the
  subject: line of DB update messages to request special processing.
  This should eventually obsolete the multiple e-mail addresses, like
  auto-assign at ripe.net, which are not widely known and their use is not
  always properly enforced.


5.	Hierarchical authorization

  Implementation of hierarchical authorization is initially planned for
  . domain name space
  . IP-Address-Ranges for registries
  . origin AS for routes
  
  Moving the description of the hierarchy and the transactions allowed at
  a particular level to a maintainer object was preferred over an
  alternate method of using a scope: attribute.


6.	Handles, Object review

  Eventually the assignment of NIC-Handles (more precisely: RIPE handles)
  is being implemented. David shall circulate a propsal about the logic
  and the semantics to the mailing list.

  Reverse lookup (for person objects, at least) is being worked on.

  The country: attribute is being redefined to allow multiple lines with
  multiple values, to better reflect the real scope of an entity (like
  address blocks from a regional registry, AS numbers, etc.)
  
  The Role: or NOC: object needs more thought and detailed definition.
  There is still some uncertainty whether a full-blown new object (with a
  handle) is really needed, or whether the person object can be extended.
  Input was received from Michael H. Behringer that proposed a common
  format for describing contact information, coverage and emergency
  preocedures. This object is to be re-visited on the mailing list and a
  decision about implementation is being sought on the list.

  The proposal for an extension of the inet-rtr: object was briefly
  discussed. The original intent was to allow for a description of Mbone
  routers. However, extending the concept could be very useful for
  describing all sorts of peerings, like Mbone, IP-over-IP, IPnG, and the
  like. Due to the fact that there is already a couple of tools which
  read the peer: attributes, it might be wise to not change the peer:
  attribute as currently defined (but to eventually make it obsolete) and
  to invent a new attribute with the peering protocol ID as the first
  element, the address as the second element and then the specific
  information. To be discussed in more detail on the mailing list.

  url: it was agreed to add a new (optional) attribute to all objects to
  allow for inclusion of URLs. The details to be worked out after some
  more tests. Format could either be plain HTML or general URI syntax.
  

7.	Input from other WGs

  Already covered (see inet-rtr: for Mbone)
  

8.	AOB

  None. Meeting closed.
  
  ________________________________________________________________________________
  
List of new actions:

Daniel Karrenberg: To circulate a detailed proposal for the stored:
	attribute.

David Kessens: To circulate a detailed proposal for the automatic handle
	assignement.

Wilfried Woeber, Michael H. Behringer: To initiated discussion on the
	mailing list about the need and possible format for a role: or
	noc: object.

Wilfried Woeber: To initiated discussion on the mailing list about the
	extension of the inet-rtr: object.

WW, 21.3.96