Fwd: Re: About db-wg minutes

  Dear all !
  
  As you might know, we lost the notes for the Berlin DB-WG meeting due to 
  a nasty act of theft. So much for the hospitality of a university...
  
  I think (hope) that the notes provided by David Kessens have already been
  circulated. Unfortunately I'm under too much pressure these days to do a
  thorough investigation. Thus, just to make sure, here it is (again?).

  Thanks David !
  
  See you next week in Amsterdam,
  Wilfried.

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

I include below my draft for the minutes. Feel free to change them
according to your personal needs (we talk later about the bribes),

See you,

David K.
----

Database Working Group

Chair: Wilfried Woeber
Scribe: Hans Petter Holen

1.  Administrative stuff

    Hans Petter Holen volunteered to take notes on his notebook. However
    his notebook computer was stolen right before he was able to E-mail
    the minutes to the chairman. Therefore the minutes are reengineered
    as best as possible by Wilfried Woeber and David Kessens.
    
    The proposed WG-agenda was accepted.

    
2.  DB-SW report

    David Kessens offered the traditional database software report. The
    slides of the presentation can be obtained from:

    ftp://ftp.ripe.net/ripe/presentations/
    ripe-m24-david-DB-REPORT.ps.gz
       
    The database has grown by 25 % in 3 months time. A new more powerfull
    1.1 version is ready although not published yet since it still lacks
    some small pieces before it can be released as a non-beta version.
    
    Most interesting new features in addition to the already known
    new features are:

    - Hierarchical authorization for the creation of 'domain:' and 'inetnum:'
      objects

    - the extended country attribute syntax is implemented
    
    - inetnum objects can finally be sent in prefix notation
    
    - line continuation with a '\' is supported
    
    - many changes to ease installation
    
    - many bug fixes
    
    
    The hierarchical authorization needed some decisions to be taken by
    the community on how the hierarchy of the objects would be defined:

    The following was decided:
    
    For 'domain:' objects:
    
    - creation of TLD domain objects need intervention of the RIPE NCC
    
    - the parent object is the biggest domain that still completely
      matches the domain of the object to be added.
      
    For 'inetnum:' objects:
    
    - objects can be created automatically if no parent object could be
      found
    
    For 'route:' objects:
    
    [ Wilfried, I need some help here, my notes are not clear ... ]
    
    No final decisions were made since all proposals had disadvantages
    
    - Do the authorization as specified in the 'mnt-by:' attribute in the
      origin AS of the route object.
      
      Problem:
      
      People can still create route objects with other origin ASs
      
    It seems that we need some more thinking before we can come up with a
    nice solution.
    
    
    Automatic NIC handle generation:
    
    A proposal was done with special keywords AUTO and a different syntax
    for more experienced users that would want to have a bit more
    control. It was perceived that this was unnecessary complicated. We
    finally found a solution that provides a single mechanism for dealing
    with all easy and more complicated cases:

    nic-hdl: AUTO-#[Initials]
    
    where:  
    
       #         - is a random number
       
       Initials  - optional, advises the database software to use
                   initials for the generation of the NIC handle.
                 
    
    will cause NIC handles to be generated automatically.
    
    The number is needed to give the possibility for autogenerating and
    referencing more then one person object under every condition in one
    RIPE database update.

    AUTO is used as a prefix to avoid any confusion between real NIC
    handles and requests for auto generating NIC handles. 
    
    
    Role objects
    
    We finally reached agreement on the role object.
    
    The definition of the object:
    
    - name will be 'role:'
    
    - will have the same attributes as a person object
    
    - will have a 'tech-c:' and 'admin-c:' attribute
    
    - A NIC handle will be generated just as with person objects
    
    
    How to reference the object:
    
    - The object can be referenced from 'tech-c' and 'zone-c:' attributes
      only
      
    - recursive lookups go only one level deep
    
    
    Finally we decided on a proposal by Cengiz to clean up some syntactic
    problems in the routing registry part of the software:

    - the ripe-181 line continuation will no longer be supported.
      People that used it will be asked to update their objects.
      
    - The syntactic sugar words will always be mandatory to avoid all
      kind of interesting problems (for example with deletions). The raw
      database file will also contain the syntactic sugar.
      
      We will announce this change long in advance to the proper lists to
      give people the chance to make changes to their software if
      necessary.
    

3.  RADBServer report by Gerald Winters
    
    [ for wilfried or Gerald Winters <gerald at merit.edu>,
      his slides were not on the Merit ftp server ]


4.  Extended syntax for communities and as macros

    [ Wilfried: please check the conditions,
                I was not sure if we decided on a minimal length of the
                string ]
                
    Recently Brian Renaud posted a proposal to the RIPE database working
    group on an extension of the possible characters that could be used
    for communties and as macros. Gerald Winters presented the proposal
    to the RIPE database working group and asked for input of the working
    group on some unresolved minor issues. The working group found
    consensus on the following new syntax:

    community:
      
      Format:
    
      <string>
    
      The <string> must satisfy the following constraints and the
      constaints for as macros (see below):
      
      +    It must not start with the any upper or lower case
           permutations of the character "A" followed by the character
           "S". That is, the pattern "[Aa][Ss]" is not legal at the start
           of a community name.
               
      +    It must not be the same as any of the routing policy
           expression keywords. (See RIPE-181, Appendix A for a complete
           list of these keywords.)
                              
           It can expected that the keywords that the IETF Routing Policy
           System (RPS) working group defines for RPSL will be added to
           this list of keywords.
    
    
    as-macro:
    
      Format:
    
      AS-<string>
              
      The <string> must satisfy the following constraints:

      +    It must be at least two characters long.
          
      +    It must contain only  upper  case  letters, lower case  letters,
           digits, or dashes (underscores (_) were dropped to avoid
           confusion between dashes and underscores)
                              
      +    It must start with a letter
      
      +    It must end with a letter or digit
    
      
    All comparisons will be case insensitive.
    

    The slides of the presentation can be obtained from:
    
    ftp://ftp.ripe.net/ripe/presentations/
    ripe-m24-renaud-DB-syntax.ps.gz
            



5.  www interface based on WAIS by Antonio Blasco Bonito 
    
    Blasco presented a new user interface for the world wide web
    developed at GARR-NIS. The underlying technology was based on WAIS.
    
    The interface provides interesting features that are not
    possible with the current 'whois' or WAIS interface like looking up
    arbitrary strings but with a higher level of granularity then we
    are used to; per object type and OR'ed and AND'ed searches are
    possible. Furthermore, the software automatically detects URL's in
    the objects and generates a pointer to the site in the URL. The
    slides can be obtained from:

    ftp://ftp.ripe.net/ripe/presentations/
    ripe-m24-bonito-DB-waisinterface.ps.gz
    
    The community expressed their interest in the interface and asked the
    RIPE NCC to implement this software as soon as possible even when the
    interface would not always be consistent with the layout of the new
    RIPE web interface. Carol Orange told that the RIPE NCC would try to
    integrate the interface with the new web site, but that the resources
    are very limited and that the interface would need to wait until the
    launch of the new RIPE website.
    

6.  Review of active proposals and priorities

    David Kessens showed a slide on the proposals that were done in the
    past. Since the meeting was running out of time, it was then decided
    that David would send a list of active proposals to the mailing list
    and to provide a mechanism for the community to decide on the
    priorities.


7.  AOB

    None. Meeting closed.
    
    
    List of new actions:
        
    Action 24.? on David Kessens
         
         Implement the automatic NIC handle assignment in the RIPE
         database with the syntax as decided as decided on during this
         working group session.
         
         
    Action 24.? on David Kessens
         
         Send a list of active proposals to the mailing list and provide
         a mechanism for the community to decide on the priorities
         
         
--------------------------------------------------------------------------------