FYI: List of current proposals

Quoting from David.Kessens at ripe.net's message:
> 
> 
> 
> Dear all,
> 
> I have completed the action point of the RIPE database working group to
> make a list of active proposals. 
> 
> List of current proposals:
> 
> 1)  AUTO NIC handles (included in 2.00 release)
> 2)  Role object  (included in 2.00 release)
> 3)  AS macro syntax  (included in 2.00 release, if the minutes are published)
> 4)  inverse lookup
> 5)  whois -tv
> 6)  referral mechanism
> 7)  INADDR
> 8)  NEW
> 9)  stronger authorization
> 10) extended as-in
> 11) stored/processed attribute
> 12) name tag
> 13) url attribute
> 14) syntactic cleanup
> 
> You can find a more detailed description below. Please let me know if you
> know of any other proposals that I forgot about,

What about the WWW/WAIS interface to the database?

> 
> Kind regards,
> 
> David K.
> ----
> 
> 
> 1) AUTO NIC handles:
> 
>   Auto assignment of NIC handles
> 
>   Current state:   half way done
>   Time estimation: long, will be included in 2.00 release
> 
>   Syntax:
> 
>   nic-hdl: AUTO-#[Initials]
>     
>     where:  
>     
>        #         - is an arbritary identification 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 (that doesn't have a NIC
>     handle yet) 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. 
>     
>     Example:
>     
>     person:  NIC Handle
>     nic-hdl: AUTO-45NH
>     [... stuff deleted ... ]
>     
>     person:  Nick Hansson
>     nic-hdl: AUTO-3NH
>     [... stuff deleted ... ]
>     
>     inetnum: x.y.z.0 - x.y.z.255
>     admin-c: AUTO-45NH
>     tech-c:  AUTO-3NH
>     [... stuff deleted ... ]
>     
>     Will assign a NIC handle with Initials NH and the first free number
>     to 'NIC Handle' and NH and the next free number to 'Nick Hansson'. It
>     will also fill these NIC handles in the right attributes of the
>     objects.
>     
>     
>     
> 2) New role objects
>   
>   Current state:   half way done
>   Time estimation: medium, will be included in 2.00 release
>     
>     Syntax:
>     
>     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
>     
>     
>     
> 
> 3) AS macro syntax
> 
>   New syntax for community and AS macros
> 
>     Current state: nothing done, need approval of the RIPE minutes first
>     Time estimation: very short, will be included in 2.00 release if
>                      the database workinggroup minutes are approved in time
>     
>     
>     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.
>     
>     
> 4) inverse lookup
> 
>   Current state:   No proposal, nothing done
>   Time estimation: medium
>   
>   What is it?
>   
>   Inverse lookup makes it possible to find objects that match a certain
>   key in a specified attribute.
>   
>   Example:
>   
>   whois -i admin-c,tech-c,zone-c DK13-RIPE
>   
>   gives all objects that have DK13-RIPE as their admin-c, tech-c or
>   zone-c.
>   
> 
> 5) verbose templates/whois -tv
> 
>   Current state:   data collection (from the RIPE documents) started
>   Time estimation: short/medium, see note below
> 
>   Notes:
>   
>   - This will probably be a joint project with Merit.
>   - The data collection part takes most time but is needed for some other
>     projects anyway:
>   
>     We need documentation on all our objects for our own documentation, the
>     RPSL IETF working group and future work to get the InterNIC and RIPE
>     syntax synchronized.
>   
>   
>   What is it?
>   
>   Verbose templates are meant to give more information on object
>   templates then we give now. It is intended that 'whois -v -t inetnum'
>   will give the syntax of the attribute (as with 'whois -t'), a short
>   description of the attribute and a 'minimal' regular expression to give
>   a better idea on how the attribute should look like.
>   
>   
> 6) referral mechanism
> 
>   Current state:   No detailed proposal, nothing done
>   Time estimation: short/medium
>                    
>   Notes:
>   
>   This is not a agreed on proposal but is interesting to implement for
>   experimenting with the topic, although it is of use for the community
>   even in an experimental phase. More sophistacted designs might come up
>   that will need much more time to implement and can be regarded as
>   separate projects.
>   
>   
>   What is it?
>   
>   We want to have an automatic referral mechanism that will make it
>   possible that RIPE database objects refer to other whois servers and
>   your client can then search that servers automatically.
>   
>   Example:
>   
>   domain: NL
>   refer:  WHOIS domain-registry.nl
>   
> 7) INADDR 
>   
>   reverse delegation integration with the RIPE database
> 
>   Current state:   nothing done
>   Time estimation: short/medium
>   
>   This proposal will allow for sending your reverse delegation requests
>   directly to the RIPE database. The updated objects are sent to the
>   reverse delegation robot after the update succeeded if a special
>   keyword (INADDR?) is present in the Subject: line of your message.
> 
> 8) NEW
>   
>   Current state:   nothing done
>   Time estimation: short
>   
>   substitute the <auto-assign at ripe.net> mail box by the keyword NEW in
>   the update to the RIPE database. Only new objects will then be accepted
>   for addition to the RIPE daatabase.
> 
> 
> 9) stronger authorization
> 
>   Current state:   No proposals, nothing done, see note
>   Time estimation: ???
>   
>   Note:
>   
>   - Merit has a mechanism, but it is unclear if it is general enough and
>     might need too much human intervention when dealing with a database as
>     big as RIPE has. Also, import restrictions might disallow us to use
>     Merit's code.
>   
>   No proposals on how to do this exactly are available right now.
>   
> 
> 10) extended as-in
> 
>   extended as-in/as-out attribute
> 
>   Current state:   Proposal circulated, nothing done at RIPE, see note
>   Time estimation: ???, but probably not too long if Brian Renaud's
>                    implementation is good.
>   
>   Note: 
>   
>   - Brian Renaud (Merit) has made an implementation and has sent it in.
>     I haven't had time to really look at it.
>     
>     It looks promising. Previous concerns that I had because his
>     implementation required certain external tools seems like they have
>     been addressed
>   
>   
>   What is it?
>   
>   See proposal by Cengiz Alaettinoglu <cengiz at ISI.EDU> that is circulated
>   to the RPSL IETF working group mail list.
>   
>   
>   
> 11) stored/processed attribute
> 
>   Current state:   Proposal approved. Nothing implemented yet.
>   Time estimation: short/medium
>   
>   What is it:
>   
>   Attributes added to all objects that contain a time-stamp and serial
>   number. This allows for better knowledge on the history and age of
>   objects. The attributes will also make the near real time mirroring
>   more robust then it is now. In the future features like rolling back
>   and forth to certain database states can be supported but need to be
>   addressed in a separate project. A proposal has been circulated and
>   appoved to the RIPE database working group.
>   
>   
> 12) name tag
> 
>   handle (Full name of person) data in tech-c/admin-c/zone-c attributes
> 
>   Current state:   No detailed proposal has been made yet.
>   Time estimation: short/medium (might be more complicated then expected
>                    right now)
>                    
>   The proposal makes trouble shooting with disappeared person objects
>   easier (esspecially when person might be located in a different
>   database). The proposal als allows for non-recursive lookups in many
>   cases when the user has enough info when seeing the name only.
> 
> 
> 13) url attribute
> 
>   Current state:   No proposal yet
>   Time estimation: short
>   
>   What is it?
> 
>   Attribute that can be used in any database object for references to any
>   other site by using an url.
>   
>   No exact proposal has been made yet, but the idea seems to be very
>   useful.
>   
> 
> 14) Syntactic cleanup
> 
>    Current state:   Nothing done yet
>    Time estimation: short/medium
> 
>    It is perceived by the user community as well as by the software
>    developers for the routing registry that some of the syntax is
>    unecessary complicated and/or makes more confusion then it solves.
>    Therefor it was decided on the last RIPE meeting to remove the
>    following features:
> 
>     - 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.
> 
>   
> ========
> 


-- 
----------                                                     ----------
Antonio-Blasco Bonito                          E-Mail: bonito at nis.garr.it
GARR - Network Information Service      c=it;a=garr;p=garr;o=nis;s=bonito
c/o CNUCE - Istituto del CNR                           Tel: +39 50 593246
Via S. Maria, 36                                       Fax: +39 50 904052
I-56126 PISA                                        Telex: 500371 CNUCE I
Italy                   Url: http://www.nis.garr.it/nis/staff/bonito.html
----------                                                     ----------