Latest and hopefully last iteration of ripe-81++

=  * > ....
=  * > - 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.    

   ...Well no strong feelings about introducing a name atrtribute, but I
   don't see the need for it. It's very easy to spoil the first line for
   the description and it's comparably easy to spoil the value for a name
   attribute...

   I think the issue here is to make people aware that these strings
   (however they are stored) are used by software and shold give useful
   *and concise* information.
   
   Would some others, having strong feelings, please speak up?!

=  * > 
=  * > - 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 ?

   There are two aspects to it:
   
   - 1) do we need it? do we have to specify implementation?
   
   - 2) if we need it - what do we want?
   
   1) My personal opinion is (shaped by the experience of dealing
   regularly with a *very reliable* RIPE-DB implementation) that we don't
   need this gadget. Given the responsiveness of the overall system I
   won't come to think of submitting another update before I've checked
   the reply from the database! So I think it's an issue of trying to
   solve the problem only when we have proof that it is there.
   
   And - btw - I strongly advocate keeping the possibility to submit more
   than one update per day!!! I consider this a feature, not a bug.
   
   2) *IF* and when we decide to implement finer granularity, then I
   think wiring in the weirdness of timezones (to DST or not to DST :-)
   is definitely a *bad* idea! Do we really need time-information? If
   this is the case then we should agree on UTC.

   But I think what Laurent is perhaps advocating is something like an
   update sequence number. So my proposal would be to add an *optional*
   (positive, integer :-) sequence number with no other restrictions like
   being contiguous etc. much like the DNS serial numbers.
   
   Wilfried.
 --------------------------------------------------------------------------
  Wilfried Woeber                :  e-mail: Wilfried.Woeber at CC.UniVie.ac.at
  Computer Center - ACOnet       :  
  Vienna University              :  Tel: +43 1 4065822 355
  Universitaetsstrasse 7         :  Fax: +43 1 4065822 170
  A-1010 Vienna, Austria, Europe :  NIC: WW144
 --------------------------------------------------------------------------