FYI: List of current proposals
- Previous message (by thread): FYI: List of current proposals
- Next message (by thread): FYI: List of current proposals
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Antonio_Blasco Bonito
bonito at nis.garr.it
Wed Jun 19 11:06:59 CEST 1996
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 ---------- ----------
- Previous message (by thread): FYI: List of current proposals
- Next message (by thread): FYI: List of current proposals
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]