Latest and hopefully last iteration of ripe-81++

 bonito at nis.garr.it (Antonio_Blasco Bonito) writes:
  * > 
Firstly,
	this is just my opinion.. it is up to the working group chairs
to decide any new extensions here. I am just `trying' to complete the
action for ripe-81++ from the last meeting. The points you raise are
more general (esp. the time related one). However, find below my
personal view on this.

  * > 	Ok, here are my last comments again (seens that last time they
  * > went directly to /dev/null). I won't accept a document which does not
  * > allow more than 1 update of an object per day.
  * > 		Laurent
  * > 
  * >         A few things i'd like to propose:
  * > 
  * > - A route/AS name attribute. You currently use the first line of the 'des
  * c'
  * > attribute to generate a name (with prtraceroute for instance). Having
  * > a separate name attribute can make the query of the server (whois or what
  * ever)
  * > easier since it doesn't require any parsing.
  * 
  * I strongly agree.
  *
Umm... do not see the need for routes to have names - doesn't effect
prtraceroute or any other tool for that matter. Whats to parse in
description ? It is there in the aut-num object so a tool uses it..and
works as far as I can tell ?

However, if the groups want this fine by me. Just I didn't hear any
other votes for this until now.    
  * > 
  * > - Include the time (hour, min, second) in the "changed" attribute. This i
  * s
  * > in case of several changes in the same day. Proposed syntax
  * > (compatible with the older one):
  * > 
  * > 	changed: <email> YYMMDD [hh:mm:ss] [+oo]
  * > 
  * > If hh:mm:ss is missing we assume 00:00:00 +00 ???
  * > +oo if the offset from GMT. (i know, we have to deal with the times
  * > zones :-)
  * 
  * I agree not because I think that frequent updates are necessary but because
  * including the time zone better identifies the exact time of the update.
  * 

Makes no odds to me either way. The software allows more than one
update a day so this is a misnomer from Laurent. 
However, this is VERY much a general database issue and not at all in 
context with the ripe-81++ proposal I am afraid. DB chair what say you ?

		--Tony.