[db-wg] db 1.86 and descr objects

Dear working group,

First of all. We just sent an email to ncc-announce to alert people to the intended clean-up and ongoing discussion in this group.

Secondly. We have a tentative date that we can run the clean-up again: 9 May. But, we will only do so on the basis of consensus called in this working group by the co-chairs. RIPE NCC originally suggested that a clean-up would be useful (more on that below), but the working group can also decide to postpone, or cancel the clean-up.

That being said, please allow me to give our perspective on some of the issues below.

> On 19 Apr 2016, at 12:54, Peter Hessler <phessler at theapt.org> wrote:
> 
> 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.

In our understanding "last-modified:" should indicate when a user last made a semantically important change, because it can be interpreted as an indication of how well maintained an object is. Therefore we thought that in this case it was better not to update it. I can't remember exactly where this was said before, but I believe this intent was discussed as part of the "last-modified:" change.

In short this was in no way meant to hide the fact that an update had happened, and the actual update is visible in history.

If the working group feels that "last-modified:" should be updated in this clean-up then we can certainly do so. Also as Job indicates, this is probably a question that should be addressed explicitly whenever we have bulk update (or clean-up) tasks - unless of course there is consensus that it should always be updated.

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

Given the number of objects it's not feasible to notify all individually.

> :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.

I believe it would be better that we always inform ncc-announce at ripe.net of changes like this.


> :> 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.

The intent of the clean up was to have a clean starting point. The "org:" reference is authoritative w.r.t. the organisation name, and the "descr:" attribute can be used for anything else. In addition removing the organisation names from "descr:" would leave the objects in a state where "descr:" was completely controlled by the holder of the resource object.

That said it seems that at least some people want to keep using their organisation name here. However, because of the number of objects it is not feasible to pro-actively contact all object holders beforehand and give people an option to exempt their objects from the update. And more fundamentally I believe that this would defeat the purpose of doing the clean-up in the first place. If a significant number of resource holders want to keep their organisation name in the "descr:" field, then confusion about where the organisation name should be found and updated remains.

There are arguments in favour of doing the clean-up (most importantly clean state, one clear source for org name), and there are arguments against (most importantly silent updates). Making the call which is the greater good is not trivial. RIPE NCC argued for the clean-up case and earlier there was consensus on this, but if the working group now decides against it then we have peace with that too.

Kind regards,

Tim Bruijnzeels


> :> 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?
>