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 ]
Job Snijders
job at ntt.net
Mon Aug 3 23:50:53 CEST 2015
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. > 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. 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. 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 ]