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