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,
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(a)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(a)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.
========
