This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] db 1.86 and descr objects
- Previous message (by thread): [db-wg] db 1.86 and descr objects
- Next message (by thread): [db-wg] db 1.86 and descr objects
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Peter Hessler
phessler at theapt.org
Tue Apr 19 12:54:35 CEST 2016
On 2016 Apr 15 (Fri) at 08:03:54 -0700 (-0700), Job Snijders wrote: :On Thu, Apr 14, 2016 at 02:14:58PM +0200, Peter Hessler wrote: :> And worse, it only affected some of our objects, not all of them as I :> would have expected. IMHO, the worst part is the "last-modified" :> field was not updated, nor was a "your object has changed" email :> generated. : :This is useful feedback, arguments for both updating "last-modified" and :not updating "last-modified" can be made. The mechanics for this type of :operation are not well established. It appears that adding things to :RPSL is quite trivial, (the RFC even specifies "just ignore what is new :and you dont understand"), but deprecating or changing existing I think that if there is a last-modified field, it should always be accurate. And, since the objects were modified, that should have updated the fields. I'm torn on the notify emails, though. I can see they would create an immense amount of support tickets, but on the other hand, as a producer of db objects I want to know what changed in my objects _especially_ when I didn't change them myself. :attributes continues to pose a challenge: Not everyone reads the same :news outlets, we have no programmatic way to signal to data :producers/consumers that a change is coming. : Should there be a db-announce@ list then? I don't know how much that will help the producers, but consumers of the db can get the changes summarized without having to follow the whole discussion. :> Many people use the descr field for things, as an example: the "name" :> attribute at bgp.he.net. When browsing through the ASes in Germany, I :> noticed many companies that were likely hit by this (they showed a :> partial or complete address in the "name" field, instead of the name :> of the company), including one of the largest ISPs in Germany. : :I recommend that developers of tools such as database analytics follow :the "org:" attribute and use the content of the "org-name:" when it :concerns RIPE objects instead. I would argue that the developer of such :a tool has a duty to try and stay current on any changes concerning the :data sources the tool uses. : Yes and no. Not everything should be called by the org name. E.g. If an org has 15 ASNs, they can be labeled for their purpose, instead of the org name. descr: makes sense to me. :> I was unable to find a discussion of the _clean-up_ in the WG archives. :> Why was it decided not to inform the affected members, or even all :> members via the announce mailing list? Is that a standard policy? : :In August and October 2015 there was discussion :(https://www.ripe.net/ripe/mail/archives/db-wg/2015-August/thread.html :look for the word "descr"), in January 2016 :https://www.ripe.net/ripe/mail/archives/db-wg/2016-January/004970.html :the chairs pulled the trigger and now its been implemented. : Thanks for these. When I looked, I didn't go back far enough in the archives. :The proposal mentioned that an announcement would be send to the :ncc-announce at ripe.net list, but I fear there has been an oversight and :this has not happened. Point taken. : :Kind regards, : :Job -- Sure, Reagan has promised to take senility tests. But what if he forgets?
- Previous message (by thread): [db-wg] db 1.86 and descr objects
- Next message (by thread): [db-wg] db 1.86 and descr objects
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]