Re: Latest and hopefully last iteration of ripe-81++
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 'desc' attribute to generate a name (with prtraceroute for instance). Having a separate name attribute can make the query of the server (whois or whatever) easier since it doesn't require any parsing. - Include the time (hour, min, second) in the "changed" attribute. This is 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 :-) Laurent -- Laurent Joncheray, E-Mail: lpj@merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM
Laurent Joncheray <lpj@merit.edu> writes * 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. * 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 :-) This is not for us to decide. The database working group should decide on this. However, your statement that the document only allows one update per day is wrong. The current database can take as many updates per day for one object as you like. Implementation matter. -Marten
- Include the time (hour, min, second) in the "changed" attribute. This is 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 :-)
Why do you need that sort of resolution? Unless it would serve a real purpose I really don't see the need for this -- it's just one more creeping feature to have to implement and maintain. - Håvard
Laurent Joncheray <lpj@merit.edu> writes: 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.
This is a general RIPE db question which should be treated for all objects, like authentication, and other such issues applicable to all objects. Thus it is outside the scope of RIPE-81++. It is inside the scope of the database working group. To explain my very firm point of view here let me explain that this document needs to be stable for both the RIPE database implementation work and adaption of the PRIDE tools. Both activities are also already a little behind shedule. Further delays present the real danger that it will be next year before any of this is operational. We cannot wait any more. The absolute deadline is the RIPE meeting but preferably this should be done earlier. Laurent and Jessica had agreed on June 3d to provide pieces of text for this draft, especially for the interas-in and interas-out attributes. When we had not received anything but a repeat of their syntax proposals, Tony and I wrote it up ourselves again in order to get the draft out now, weeks after schedule. Daniel
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 'desc' attribute to generate a name (with prtraceroute for instance). Having a separate name attribute can make the query of the server (whois or whatever) easier since it doesn't require any parsing.
I strongly agree.
- Include the time (hour, min, second) in the "changed" attribute. This is 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.
Laurent
-- Laurent Joncheray, E-Mail: lpj@merit.edu Merit Network Inc, 1071 Beal Avenue, Phone: +1 (313) 936 2065 Ann Arbor, MI 48109, USA Fax: +1 (313) 747 3745 "This is the end, Beautiful friend. This is the end, My only friend, the end" JM
---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@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 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------
participants (5)
-
bonito＠nis.garr.it -
Daniel Karrenberg -
Havard Eidnes -
Laurent Joncheray -
Marten Terpstra