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] NCC still enforcing descr: content
- Previous message (by thread): [db-wg] NCC still enforcing descr: content
- Next message (by thread): [db-wg] NCC still enforcing descr: content
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ingrid Wijte
ingrid at ripe.net
Fri Aug 7 12:56:22 CEST 2015
Hi Job and others, The reason we suggested a clean up was because it's an opportunity to get rid of cruft. This is not just good housekeeping, but primarily because maintaining the data comes with certain expectations from the people who use it, which are often the result of habits that go back years. If we quietly stop enforcing the contents of descr: and don't clean up anything, we are concerned this will lead to the confusion that was outlined in the original post with the three alternatives: "names left there will start to differ from the names in the referenced organisation objects - which are enforced by RIPE NCC. It may not be clear to users where to look for this information and where to change it. And it may lead to situations where people wrongfully assume that the RIPE NCC is still enforcing the "descr:" line." This is why we think option B is the clearest approach, taking all users – both those who enter and use data – into account. We can start with a clean slate and send a clear message to every user. Kind regards Ingrid Wijte Registration Services Assistant Manager RIPE NCC On 04/08/15 01:49, Job Snijders wrote: > On Tue, Aug 04, 2015 at 01:33:05AM +0200, denis wrote: >> First of all [...] > Thank you for the historical context. > >> On 03/08/2015 23:50, Job Snijders wrote: >>> On Mon, Aug 03, 2015 at 11:18:09PM +0200, Sander Steffann wrote: >>>>> option B seems like a cleaner long term fix. >>>> I agree. I think leaving descr: mandatory will lead to confusion. >>> I disagree, the only confusion so far as been that that attribute's >>> value cannot be a description but in the past had to be the 'proper' >>> company name. >> This is not quite right. Only the first description line had to be the >> company name. Other descriptions could have been added and in many >> cases probably have been. > I stand corrected. > >>>> Some descr: will refer to an organisation, some will not, some will >>>> refer to a different organisation than org:, and for new objects >>>> some content for descr: will have to be invented not because there >>>> is any useful information but just because the field is mandatory... >>>> >>>> If we clean this up I think we should do it properly. >>> To me the "descr:" attribute is an easy to parse component of an IRR >>> object, there is only one "descr:" line, and it is mandatory >>> according to RFC. >> Not according to the RIPE Database implementation. It is a multiple >> attribute in all operational objects. When you say "easy to parse" I >> presume you mean by a human reading the data. Free text is never easy >> to parse by software. > Yes, I meant fit for human consumption (freetext), but easy to find for > the parser. "descr:" to me is different then "remarks:", in general I > found that "remarks:" is too elaborate while "descr:" is nicely terse. > >>> If I look at organisations that have multiple ASNs the "descr:" >>> attribute can be an informative hint which department or thingy you are >>> dealing with. Semantically "descr:" is an easy place to look for a short >>> summary of what the object is about. >>> >>> A parser can follow the "org:" object for a degree of legal validity, >>> and use "descr:" for an informal, informative textual representation of >>> what the object might be. >> Many objects probably already have these descriptions. So if you make >> it optional and remove the first "descr:" attribute, which is the one >> that was enforced to be a copy of the org name, then you have what you >> are asking for. > I am hestitant to remove existing attributes, and would prefer that > people remove them when they deem fit (for instance, after they upgraded > their software). > > To me, RIPE NCC finally to stop enforcing the very contents of "descr:" > was all that was requested, not a 'clean-up' of sorts. > > Kind regards, > > Job >
- Previous message (by thread): [db-wg] NCC still enforcing descr: content
- Next message (by thread): [db-wg] NCC still enforcing descr: content
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]