The New "organisation object" Proposal
Dear Colleagues, [apologies for duplicate messages] Following discussions at the RIPE NCC about a new Whois Database object, the organisation object, we have modified the previous proposal that you can find at: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00013.html The main changes from the previous proposal are: - a "country:" attribute is added. - "org-type:" and "org-name:" attributes are added, and "organisation:" attribute is now a NIC handle, which will be automatically assigned during the creation of the object. The motivation for this is explained in Section 3 of the proposal. - Hierarchical names can be removed, mainly for simplicity. - Differing query results on the whois server introduced in section 5. According to this, the relevant organisation objects are appended to the query results (because the organisation that holds the resource is at least as important as the person/role objects mentioned in the resource object). Please let us know your comments and concerns about the new proposal attached to this mail. Thanks for your time and best regards, -- Engin Gunduz RIPE NCC Database Group An organisation object in the RIPE Database -------------------------------------------- 1. Motivation ------------------- Currently the RIPE Database stores two main types of contact information: person and role objects. The person and role objects provide a way to contact people responsible for operations or usage of the resources represented in the RIPE Database (IP blocks, autonomous systems, and domain names). However, none of these provide an easy way of mapping resources to a particular organisation. A user must first find an object containing contact information for that organisation. Then, assuming all of the organisation's objects refer to this contact information, the user must perform an inverse query to obtain a list of objects referencing the specified person or role. This indirect process can be somewhat obscure and therefore a request for a more direct way of attaching an object to an organisation is seen as a useful addition to the RIPE Database. This document is a proposal for an organisation object in the RIPE Database and the necessary database functionality. 2. The organisation object ----------------------- The organisation object provides information identifying an organisation such as a company, charity or university, that is a holder of a network resource whose data is stored in the RIPE Database. The organisation object is identified by a unique ID specified in the "organisation:" attribute which is the primary key. An organisation object can be referenced from other types of objects using an "org:" attribute. All objects associated with a particular organisation can be retrieved by performing an "inverse query" for the organisation's ID (handle) used in the "org:" attribute of database objects. Following is a template for the proposed organisation object and an example. All attributes except the "ref-nfy:", "organisation:", "org-name:" and "org-type:" have their usual meanings. organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [look-up key] org-type: [mandatory] [single] [ ] descr: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 3. New attributes ---------------------- "organisation:" Specifies the ID of an organisation object. An organisation ID is made up of 'ORG-' prefix, followed by 2 to 4 letters, digits, a dash and is followed by the database source (in the RIPE Whois Database this is 'RIPE'). For example: ORG-RT34-RIPE Note that all parts are mandatory, thus ORG-RT-RIPE would be an invalid ID as it is missing the numeric part. Organisation object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. The user has to specify the ID of an organisation object as ORG-AUTO-<digit> during creation of the object, then it will be assigned an appropriate ID. The organisation ID is assigned using the "org-name:" attribute of the object. The user can specify the letter combination he/she prefers. For example if the user wants TTR as the letter combination, in the organisation ID, then ORG-AUTO-1TTR should be put into "organisation:" attribute during the creation of the object. The organisation ID cannot be reused. If an organisation ID was used in the past by an organisation object and then deleted, this ID cannot be used in new organisation objects. The auto-generation of organisation IDs and preventing reuse of them simplifies the external references. Note that when an organisation changes name, the "org-name:" can be modified accordingly. There is no need to change the organisation ID. "org-name:" Specifies the name of the organisation that this organisation object represents in the whois database. This is an ASCII-only text attribute. The restriction is because this attribute is a look-up key and the whois protocol does not allow specifying character sets in queries. The user can put the name of the organisation in non-ASCII character sets in the "descr:" attribute if required. "org-type:" Specifies the type of the organisation. The possible values are 'IANA' for Internet Assigned Numbers Authority, 'RIR' for Regional Internet Registries, 'NIR' for National Internet Registries, 'LIR' for Local Internet Registries, and 'NON-REGISTRY' for all other organisations. "ref-nfy:" Specifies the e-mail address to be notified when a reference to the organisation object is added or removed. An e-mail address as defined in RFC 2822. [This functionality is used in the "irt-nfy:". The name of this attribute is more neutral allowing reuse in other object types.] "country:" Specifies the two-letter ISO3166 country code of the country where this organisation resides. "address:" Specifies the address of the organisation. This is a free-text attribute. "org:" May be included in any other object type. It points to an existing organisation object representing the entity that holds the resource. The value of this attribute is the ID of the organisation object. It is mandatory in the aut-num objects, and inetnum and inet6num objects with "ALLOCATED-BY-IANA", "ALLOCATED-BY-RIR", "ALLOCATED-BY-RIR NON-PORTABLE", "ALLOCATED-BY-RIR PORTABLE" and "ALLOCATED-BY-RIR UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects. 4. Authorisation checks ---------------------------------- When modifying an organisation object the update must pass authorisation checks specified by one of the mntners listed in the "mnt-by:" attributes of the organisation object. When adding an "org:" attribute to an object, the update of the object should pass the following authorisation checks: - from one of the maintainers of the organisation object - from one of the maintainers of the object being updated 5. Query changes ---------------- If a whois query returns an object with an "org:" attribute, the organisation object mentioned in this attribute is also appended to the query results. This behaviour can be disabled by using the '-r' flag in the query. 6. Examples ------------ A basic organisation object: organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. city: Amsterdam country: NL phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact@example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE notify: ripe-mailbox@example-org.net ref-nfy: ripe-mailbox@example-org.net mnt-by: EXAMPLE-MNT changed: someguy@example-org.net 20030121 source: RIPE A network that references an organisation object: inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE status: ALLOCATED-BY-RIR PORTABLE mnt-by: EXAMPLE-MNT mnt-lower: EXAMPLE-MNT changed: someguy@example-org.net 20030122 source: RIPE A query for this inetnum object: % whois 192.168.86.251 inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network org: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE [...] source: RIPE organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. address: The Netherlands phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact@example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE [...] source: RIPE person: John Example nic-hdl: JE1-RIPE [...] source: RIPE person: John Example Jr nic-hdl: JE2-RIPE [...] source: RIPE
I think this proposal is very good. On Monday, Aug 25, 2003, at 12:27 Europe/Amsterdam, DB-News wrote:
Dear Colleagues,
[apologies for duplicate messages]
Following discussions at the RIPE NCC about a new Whois Database object, the organisation object, we have modified the previous proposal that you can find at:
http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00013.html
The main changes from the previous proposal are:
- a "country:" attribute is added. - "org-type:" and "org-name:" attributes are added, and "organisation:" attribute is now a NIC handle, which will be automatically assigned during the creation of the object. The motivation for this is explained in Section 3 of the proposal.
A very welcome modification. The last thing the RIPE DB needs to get dragged into are trade mark disputes about object names. Could it be made a bit stricter and allow only for auto-generation of organisation NIC handles?
- Hierarchical names can be removed, mainly for simplicity.
I got lost on this one. Do you mean "can be removed" or "have been removed"?
- Differing query results on the whois server introduced in section 5. According to this, the relevant organisation objects are appended to the query results (because the organisation that holds the resource is at least as important as the person/role objects mentioned in the resource object).
This is good. Also being able to disable it with '-r'. Will the database enforce any restrictions on the assignment of org-types, so that new IANAs and new RIRs can't be created, with potential for introducing confusion? I think this is a good proposal for an organisation object in the RIPE Database, Joao
Hi Joao, On 2003-08-25 14:34:18 +0200, Joao Damas wrote:
I think this proposal is very good.
On Monday, Aug 25, 2003, at 12:27 Europe/Amsterdam, DB-News wrote:
Dear Colleagues,
[apologies for duplicate messages]
Following discussions at the RIPE NCC about a new Whois Database object, the organisation object, we have modified the previous proposal that you can find at:
http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00013.html
The main changes from the previous proposal are:
- a "country:" attribute is added. - "org-type:" and "org-name:" attributes are added, and "organisation:" attribute is now a NIC handle, which will be automatically assigned during the creation of the object. The motivation for this is explained in Section 3 of the proposal.
A very welcome modification. The last thing the RIPE DB needs to get dragged into are trade mark disputes about object names. Could it be made a bit stricter and allow only for auto-generation of organisation NIC handles?
Yes, this is actually the case. Quoting from Section 3 of the proposal: Organisation object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. The user has to specify the ID of an organisation object as ORG-AUTO-<digit> during creation of the object, then it will be assigned an appropriate ID. The organisation ID is assigned using the "org-name:" attribute of the object. The user can specify the letter combination he/she prefers. For example if the user wants TTR as the letter combination, in the organisation ID, then ORG-AUTO-1TTR should be put into "organisation:" attribute during the creation of the object.
- Hierarchical names can be removed, mainly for simplicity.
I got lost on this one. Do you mean "can be removed" or "have been removed"?
Oops, it's meant to be "have been removed". Sorry for that...
- Differing query results on the whois server introduced in section 5. According to this, the relevant organisation objects are appended to the query results (because the organisation that holds the resource is at least as important as the person/role objects mentioned in the resource object).
This is good. Also being able to disable it with '-r'.
Right, this is also in the proposal: "This behaviour can be disabled by using the '-r' flag in the query." in Section 5.
Will the database enforce any restrictions on the assignment of org-types, so that new IANAs and new RIRs can't be created, with potential for introducing confusion?
Although this is not mentioned in the proposal, yes, the DB software will enforce restrictions. organisation objects with type IANA, RIR, NIR and LIR can only be created by the NCC.
I think this is a good proposal for an organisation object in the RIPE Database, Joao
Thanks a lot for feedback, Best regards, -- Engin Gunduz RIPE NCC Database Group
Engin,
A very welcome modification. The last thing the RIPE DB needs to get dragged into are trade mark disputes about object names. Could it be made a bit stricter and allow only for auto-generation of organisation NIC handles?
Yes, this is actually the case. Quoting from Section 3 of the proposal:
Organisation object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. The user has to specify the ID of an organisation object as ORG-AUTO-<digit> during creation of the object, then it will be assigned an appropriate ID. The organisation ID is assigned using the "org-name:" attribute of the object. The user can specify the letter combination he/she prefers. For example if the user wants TTR as the letter combination, in the organisation ID, then ORG-AUTO-1TTR should be put into "organisation:" attribute during the creation of the object.
Yes, I read it, what I mean is whether you would consider eliminating the part about choosing letters. This is only an identifier and it would be good if people could think about it as just that, with no naming implications.
Will the database enforce any restrictions on the assignment of org-types, so that new IANAs and new RIRs can't be created, with potential for introducing confusion?
Although this is not mentioned in the proposal, yes, the DB software will enforce restrictions. organisation objects with type IANA, RIR, NIR and LIR can only be created by the NCC.
Cool. One more question, though it is really not DB related in itself, but more policy: Will org objects be created when LIRs are created? If so, will existing LIRs automatically get an org object? Joao
Hi, On 2003-08-25 14:58:47 +0200, Joao Damas wrote: [...]
Will the database enforce any restrictions on the assignment of org-types, so that new IANAs and new RIRs can't be created, with potential for introducing confusion?
Although this is not mentioned in the proposal, yes, the DB software will enforce restrictions. organisation objects with type IANA, RIR, NIR and LIR can only be created by the NCC.
Cool. One more question, though it is really not DB related in itself, but more policy: Will org objects be created when LIRs are created? If so, will existing LIRs automatically get an org object?
Yes, this is the idea. When organisation object is deployed, all LIRs will get an organisation object automatically (but the details must be worked out) and the new LIRs will get an organisation object as well, when they become an LIR (or, if already exists, their organisation object will be modified to have "LIR" in 'org-type:' attribute). Regards, -- Engin Gunduz RIPE NCC Database Group
Hi Joao, On 2003-08-25 14:58:47 +0200, Joao Damas wrote: [...]
using the "org-name:" attribute of the object. The user can specify the letter combination he/she prefers. For example if the user wants TTR as the letter combination, in the organisation ID, then ORG-AUTO-1TTR should be put into "organisation:" attribute during the creation of the object.
Yes, I read it, what I mean is whether you would consider eliminating the part about choosing letters. This is only an identifier and it would be good if people could think about it as just that, with no naming implications.
As the first thought, I liked the idea of eliminating the part about choosing letters. However there can be a valid use case for it: the user might want to have a specific letter combination other than the software assigns, because the latter might mean something "inappropriate" in some language by coincidence. -engin -- Engin Gunduz RIPE NCC Database Group
As the first thought, I liked the idea of eliminating the part about choosing letters. However there can be a valid use case for it: the user might want to have a specific letter combination other than the software assigns, because the latter might mean something "inappropriate" in some language by coincidence. -engin
-- Engin Gunduz RIPE NCC Database Group
I'd like to second this position. There are cultures that don't like certain numbers (witness the missing floor numbers in your hotel if you go to certain countries :-) Cheers, Sanjaya Sr. Project Mgr., APNIC Secretariat
Hi all,
Specifies the ID of an organisation object. An organisation ID is made up of 'ORG-' prefix, followed by 2 to 4 letters, digits, a dash and is followed by the database source (in the RIPE Whois Database this is 'RIPE'). For example:
ORG-RT34-RIPE
Note that all parts are mandatory, thus ORG-RT-RIPE would be an invalid ID as it is missing the numeric part.
While we understand the need for strict naming convention to avoid name disputes, may I request that the rules and convention will not be hard coded in the software but put in a customisable config file. As a user of RIPE's whois software, APNIC might want to have a slightly different naming convention & rules :-)
May be included in any other object type. It points to an existing organisation object representing the entity that holds the resource. The value of this attribute is the ID of the organisation object. It is mandatory in the aut-num objects, and inetnum and inet6num objects with "ALLOCATED-BY-IANA", "ALLOCATED-BY-RIR", "ALLOCATED-BY-RIR NON-PORTABLE", "ALLOCATED-BY-RIR PORTABLE" and "ALLOCATED-BY-RIR UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects.
As we're talking about the use of the organisation object, can we use it to show delegation path (instead of overloading the status attribute above) in a resource object (i.e. aut-num, inetnum and inet6num). For example, if querying an inetnum, you get this response: % whois 192.168.86.251 inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network registry: ORG-RIPE1-RIPE custodian: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE [...] source: RIPE organisation: ORG-RIPE1-RIPE org-name: RIPE NCC Operations org-type: RIR address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands country: NL phone: +31 20 535 4444 fax-no: +31 20 535 4445 e-mail: ops@ripe.net admin-c: AP110-RIPE tech-c: OPS4-RIPE [...] source: RIPE organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. address: The Netherlands phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact@example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE [...] source: RIPE person: John Example nic-hdl: JE1-RIPE [...] source: RIPE person: John Example Jr nic-hdl: JE2-RIPE [...] source: RIPE Cheers, Sanjaya ______________________________________________________________________ Senior Project Manager <sanjaya@apnic.net> Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 ---_____________________________________________________________________ _
Sanjaya, On Thursday, Aug 28, 2003, at 09:22 Europe/Amsterdam, Sanjaya wrote:
May be included in any other object type. It points to an existing organisation object representing the entity that holds the resource. The value of this attribute is the ID of the organisation object. It is mandatory in the aut-num objects, and inetnum and inet6num objects with "ALLOCATED-BY-IANA", "ALLOCATED-BY-RIR", "ALLOCATED-BY-RIR NON-PORTABLE", "ALLOCATED-BY-RIR PORTABLE" and "ALLOCATED-BY-RIR UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects.
As we're talking about the use of the organisation object, can we use it to show delegation path (instead of overloading the status attribute above) in a resource object (i.e. aut-num, inetnum and inet6num). For example, if querying an inetnum, you get this response:
as a user of the DB, though I see the theoretical beauty of your proposal, I would rather have a concise definition in the inetnum object status attribute than a heap of output that will take some time to make sense of, not to mention having to scroll back and forth just to see the answer to a simple question. So I prefer the proposal as it is in this respect. Joao
% whois 192.168.86.251
inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network registry: ORG-RIPE1-RIPE custodian: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE [...] source: RIPE
organisation: ORG-RIPE1-RIPE org-name: RIPE NCC Operations org-type: RIR address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands country: NL phone: +31 20 535 4444 fax-no: +31 20 535 4445 e-mail: ops@ripe.net admin-c: AP110-RIPE tech-c: OPS4-RIPE [...] source: RIPE
organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. address: The Netherlands phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact@example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE [...] source: RIPE
person: John Example nic-hdl: JE1-RIPE [...] source: RIPE
person: John Example Jr nic-hdl: JE2-RIPE [...] source: RIPE
Cheers, Sanjaya ______________________________________________________________________ Senior Project Manager <sanjaya@apnic.net> Asia Pacific Network Information Centre (APNIC) Tel: +61-7-3858-3100 PO Box 2131 Milton, QLD 4064 Australia Fax: +61-7-3858-3199 --- _____________________________________________________________________ _
Joao Damas wrote:
as a user of the DB, though I see the theoretical beauty of your proposal, I would rather have a concise definition in the inetnum object status attribute than a heap of output that will take some time to make sense of, not to mention having to scroll back and forth just to see the answer to a simple question.
I would suggest that the organisation object would not be shown as default if referenced. Actually i would like to see "-r" option behaviour as the default for the whois-server. I know that everyone can setup an alias for "whois" or modify the c-client but i think the whois-server should be tuned to the use of the every-day users of the database. Hence the ouput of referenced organisation and person objects doesnt make sense. Only show this objects of specifically requested by a user. best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av@nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Köln Fax : +49 221 8809212
At 09:32 28/08/2003, Arnd Vehling wrote:
if referenced. Actually i would like to see "-r" option behaviour as
I would suggest that the organisation object would not be shown as default the default
for the whois-server.
I agree with this. When I first starting using more arguments for "whois" I found it surprising that "-r" turned *off* recursion rather than turning it on. Don't most other UNIX programs work that way? However some people use whois to find out contact details in the event of spam complaints. We'd need to ensure the correct abuse email addresses were in the first main object returned by a query or advertise the "-r" option in more places. Emma -- Emma Apted Peering Co-ordinator, Engineering & Standards PSINet Europe
"ALLOCATED-BY-IANA", "ALLOCATED-BY-RIR", "ALLOCATED-BY-RIR NON-PORTABLE", "ALLOCATED-BY-RIR PORTABLE" and "ALLOCATED-BY-RIR UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects.
As we're talking about the use of the organisation object, can we use it to show delegation path (instead of overloading the status attribute above) in a resource object (i.e. aut-num, inetnum and inet6num). For example, if querying an inetnum, you get this response:
as a user of the DB, though I see the theoretical beauty of your proposal, I would rather have a concise definition in the inetnum object status attribute than a heap of output that will take some time to make sense of, not to mention having to scroll back and forth just to see the answer to a simple question. So I prefer the proposal as it is in this respect.
Joao
Thanks Joao. After thinking about it, I agree that it is more important to have a concise whois response. It's just the *-BY-IANA/RIR/LIR in the status attribute that bugs me as we have the org-type attribute in the organisation object that 'begs' to be used :-) But that's a minor point really. I'm happy to support the proposal. Cheers, Sanjaya
Sanjaya, Sanjaya wrote:
While we understand the need for strict naming convention to avoid name disputes, may I request that the rules and convention will not be hard coded in the software but put in a customisable config file. As a user of RIPE's whois software, APNIC might want to have a slightly different naming convention & rules :-)
It should be fairly straightforward to modify the rules. However, without seeing specific requirements it is hard to be certain! ;)
May be included in any other object type. It points to an existing organisation object representing the entity that holds the resource. The value of this attribute is the ID of the organisation object. It is mandatory in the aut-num objects, and inetnum and inet6num objects with "ALLOCATED-BY-IANA", "ALLOCATED-BY-RIR", "ALLOCATED-BY-RIR NON-PORTABLE", "ALLOCATED-BY-RIR PORTABLE" and "ALLOCATED-BY-RIR UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects.
As we're talking about the use of the organisation object, can we use it to show delegation path (instead of overloading the status attribute above) in a resource object (i.e. aut-num, inetnum and inet6num). For example, if querying an inetnum, you get this response:
% whois 192.168.86.251
inetnum: 192.168.86.0 - 192.168.86.255 netname: EXAMPLE-NET-86 descr: Sample network registry: ORG-RIPE1-RIPE custodian: ORG-RSIS54-RIPE country: NL admin-c: JE1-RIPE tech-c: JE2-RIPE [...] source: RIPE
organisation: ORG-RIPE1-RIPE <snip/>
This is indeed our thinking, or something very similar. However, we want to do one step at a time. We would like to add the organisation object first, and then introduce a new "status:" attribute and inetnum template to include a new reference to responsible organisation(s). I think this is especially important given the input from the community that we need to make these changes as useful as possible to the users. Getting a 10 page proposal with 3 or 4 big changes makes it difficult to see the important details, at least for me. :) -- Shane Kerr RIPE NCC
While we understand the need for strict naming convention to avoid name disputes, may I request that the rules and convention will not be hard coded in the software but put in a customisable config file. As a user of RIPE's whois software, APNIC might want to have a slightly different naming convention & rules :-)
It should be fairly straightforward to modify the rules. However, without seeing specific requirements it is hard to be certain! ;)
Thanks Shane, we can discuss the specific requirements off the list, and we'd be happy to be involved in the design & development of the code.
This is indeed our thinking, or something very similar. However, we want to do one step at a time. We would like to add the organisation object first, and then introduce a new "status:" attribute and inetnum template to include a new reference to responsible organisation(s).
I think this is especially important given the input from the community that we need to make these changes as useful as possible to the users. Getting a 10 page proposal with 3 or 4 big changes makes it difficult to see the important details, at least for me. :)
I see your point. No worries, we can discuss this later. We're quite happy with the proposal as it is :-) Cheers, Sanjaya
In several countries there is allready a pulic registry of organisations with an existing organisation-number scheme. Would it be an idea to add an (optional) attribute to the object to include this number ? As an example Tiscali AS in Norway has the Organisation number 980616088 In Norway you could then do a lookup of the public http://www3.brreg.no/oppslag/enhet/detalj.jsp?orgnr=980616088 to track down the organisation/search for more updated inforamation. -hph
Hi Hans Petter, On 2003-08-29 14:41:03 +0200, Hans Petter Holen wrote:
In several countries there is allready a pulic registry of organisations with an existing organisation-number scheme.
Would it be an idea to add an (optional) attribute to the object to include this number ?
I think that this is something too specific to have its own attribute. "remarks:" attribute can be used for this I guess, just like it can be used to point users to web pages etc. Regards, -engin
As an example Tiscali AS in Norway has the Organisation number 980616088
In Norway you could then do a lookup of the public http://www3.brreg.no/oppslag/enhet/detalj.jsp?orgnr=980616088 to track down the organisation/search for more updated inforamation.
-hph
-- Engin Gunduz RIPE NCC Database Group
I think that this is something too specific to have its own attribute. "remarks:" attribute can be used for this I guess, just like it can be used to point users to web pages etc.
I dont agree: the point about the attribute would be to uniquely identify the organisation within a country. I am quite shure all countries within the EU has this concept of org-number/vat number or public registry number. The good thing is that it stays unique and lives trough name changes. Hans Petter
On Fri, 29 Aug 2003, Hans Petter Holen wrote:
I think that this is something too specific to have its own attribute. "remarks:" attribute can be used for this I guess, just like it can be used to point users to web pages etc.
I dont agree: the point about the attribute would be to uniquely identify the organisation within a country. I am quite shure all countries within the EU has this concept of org-number/vat number or public registry number. The good thing is that it stays unique and lives trough name changes.
Idon't agree. Probably it is tru for the 15 EU countries. Wether it is true for the 91 countries in the RIPE NCC region - I don't know. Rob
Hans Petter
At 08:57 29/08/2003, Rob Blokzijl wrote:
I am quite shure all countries within the EU has this concept of org-number/vat number or public registry number. Idon't agree. Probably it is tru for the 15 EU countries. Wether it is true for the 91 countries in the RIPE NCC region - I don't know.
In that case, we could leave the field as [optional], so those organisations in countries with such a system can use them and the others don't need to. Best regards, Emma Apted Peering Co-ordinator, Engineering & Standards PSINet Europe
I dont agree: the point about the attribute would be to uniquely identify the organisation within a country. I am quite shure all countries within the EU has this concept of org-number/vat number or public registry number.
most countries in the world do. randy
Hans Petter Holen wrote:
I dont agree: the point about the attribute would be to uniquely identify the organisation within a country. I am quite shure all countries within the EU has this concept of org-number/vat number or public registry number. The good thing is that it stays unique and lives trough name changes.
No, that is incorrect. In the UK (certainly England) you do *not* have to register or have a license to trade as an organisation as long as you do not trade in a deceptive way; i.e. I can set myself up now (without asking anyone for permission) to trade as "The Small Fluffy Kitten Consulting Company" and then I am done. For tax purposes I am then classed as a "sole trader". No other differences. I (and others) have been having this argument with RIPE (hi Daniel...) for many years - in the "old" days you had to provide a copy of your "Chamber of Commerce certificate". Er, closed box thinking ? Peter
Given all the different possibilities regarding unique national identifiers for organisations in different places of the world, would it be an option to start by having a RIPE doc "The organisation object" with the current proposal, task the RIPE NCC with researching the field a bit more on the VAT, chamber of commerce, etc part, and then have a new RIPE doc "Extending the organisation object" in a few months? Experience with the use of the object is likely useful right now and would provide input for future fine tuning. Joao On Friday, Aug 29, 2003, at 19:17 Europe/Amsterdam, Hans Petter Holen wrote:
I think that this is something too specific to have its own attribute. "remarks:" attribute can be used for this I guess, just like it can be used to point users to web pages etc.
I dont agree: the point about the attribute would be to uniquely identify the organisation within a country. I am quite shure all countries within the EU has this concept of org-number/vat number or public registry number. The good thing is that it stays unique and lives trough name changes.
Hans Petter
Hello,
"org:"
[ .... ] UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects.
This Restriction may be reasonable for 'ressources' but for persons/roles beeing single does not make sense to me, because a person can belong to more than one organisations. if it was single I'd have to duplicate the object just to reflect that.
4. Authorisation checks ----------------------------------
When modifying an organisation object the update must pass authorisation checks specified by one of the mntners listed in the "mnt-by:" attributes of the organisation object.
When adding an "org:" attribute to an object, the update of the object should pass the following authorisation checks:
- from one of the maintainers of the organisation object
Ihis might be problematic as well, because. There are situations where an organisation is not maintaining it's own org-object (e.g. LIR-Organisations). So if I want to reference the object in the new staff-member's person object, i'd have to go to whoever maintains the org-object. In that case the Ripe-NCC (could not chech wether this person really belongs to my organisation)[1], therefore they would just say yes (or no?) so the idea would be to seperate the reference authorisation from the object-maintainer. Like in the irt-object one could introduce an 'auth:' attribute to check the tagging. Apart from that it sounds confusing to me to introduce different behavouurs for simmilar things (reference irt: compared to reference org:)
- from one of the maintainers of the object being updated
btw. speaking of irt-objects: might we want to think about adding the mnt-irt: to the organisation as well (reflecting a different constituency model: being responsible for an organisation as compared to being responsible for a ressource). i hope this makes sense lG uk [1] Or do we want the NCC to perform these checks?! -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network/Security Universitaetsstrasse 7, 1010 Wien, Austria eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 Fax: (+43 1) 4277 / 9140
Hi Ulrich, On 2003-09-03 16:12:49 +0200, Ulrich Kiermayr wrote:
Hello,
"org:"
[ .... ] UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects.
This Restriction may be reasonable for 'ressources' but for persons/roles beeing single does not make sense to me, because a person can belong to more than one organisations. if it was single I'd have to duplicate the object just to reflect that.
I think it makes sense to make it multiple-valued in person/roles, and perhaps in some object types. We need to think a little more.
4. Authorisation checks ----------------------------------
When modifying an organisation object the update must pass authorisation checks specified by one of the mntners listed in the "mnt-by:" attributes of the organisation object.
When adding an "org:" attribute to an object, the update of the object should pass the following authorisation checks:
- from one of the maintainers of the organisation object
Ihis might be problematic as well, because. There are situations where an organisation is not maintaining it's own org-object (e.g. LIR-Organisations). So if I want to reference the object in the new staff-member's person object, i'd have to go to whoever maintains the org-object. In that case the Ripe-NCC (could not chech wether this person really belongs to my organisation)[1], therefore they would just say yes (or no?)
so the idea would be to seperate the reference authorisation from the object-maintainer. Like in the irt-object one could introduce an 'auth:' attribute to check the tagging.
OK, that makes sense too. How about introducing "mnt-ref:" attribute for this purpose? That is, "mnt-by:" will protect/control the organisation object itself. And, "mnt-ref:" will control the references to this organisation object. Thus, an LIR org object might be: organisation: ORG-AA11-RIPE [...] org-type: LIR mnt-by: RIPE-NCC-HM-MNT mnt-ref: LIR-MNT mnt-ref: RIPE-NCC-HM-MNT Here, we have "mnt-ref: RIPE-NCC-HM-MNT" because RIPE NCC hostmaster will need to add references to this organisation object when creating/modifying allocation inetnums and aut-nums. The problem with introducing 'auth:' attribute would be that, this (multiple-valued) attribute would need to contain the RIPE NCC hostmaster's PGP key as well (or whatever auth method is used), as explained above, but when RIPE NCC hostmaster changes the PGP key, all LIR org objects would need to be modified accordingly, which is not practical. Hence we would propose "mnt-ref:". To maintain consistency, perhaps we could do the same in irt objects: Change the "auth:" attr into "mnt-ref:" and have mntner names in it (rather than auth methods directly). Also, "irt-nfy:" might be changed into "ref-nfy:", again for consistency. But perhaps this is out of scope... Thanks for great feedback. -engin
Apart from that it sounds confusing to me to introduce different behavouurs for simmilar things (reference irt: compared to reference org:)
- from one of the maintainers of the object being updated
btw. speaking of irt-objects: might we want to think about adding the mnt-irt: to the organisation as well (reflecting a different constituency model: being responsible for an organisation as compared to being responsible for a ressource).
i hope this makes sense lG uk
[1] Or do we want the NCC to perform these checks?! -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network/Security Universitaetsstrasse 7, 1010 Wien, Austria
eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 Fax: (+43 1) 4277 / 9140
-- Engin Gunduz RIPE NCC Database Group
Hi Engin,
so the idea would be to seperate the reference authorisation from the object-maintainer. Like in the irt-object one could introduce an 'auth:' attribute to check the tagging.
OK, that makes sense too.
How about introducing "mnt-ref:" attribute for this purpose? That is, "mnt-by:" will protect/control the organisation object itself. And, "mnt-ref:" will control the references to this organisation object. Thus, an LIR org object might be:
organisation: ORG-AA11-RIPE [...] org-type: LIR mnt-by: RIPE-NCC-HM-MNT mnt-ref: LIR-MNT mnt-ref: RIPE-NCC-HM-MNT
This makes a lot of sense as well.
To maintain consistency, perhaps we could do the same in irt objects: Change the "auth:" attr into "mnt-ref:" and have mntner names in it (rather than auth methods directly). Also, "irt-nfy:" might be changed into "ref-nfy:", again for consistency. But perhaps this is out of scope...
Hmm, if we waht to change the behaviour for consistency, we should do it now, when the irt is not to widely used. If we agree on this more generic solution, we could extend this behavior to other Objects that can be referenced as well. e.g. for mntner: itself. this would be a way tho prevent anyone from putting my mntner ont oan object. (This would solve the issue discussed in the context of the IRT Object - where the mntner of the object should be a proof of authenticity as well) other possible objects are persons, roles, key-certs, .... basically any object that can be referenced in an other object. But e.g. in person this could be optional as compared to irt where it is mandatory. also the ref-nfy: would be handy in all of these objects. The advantage would be to have a consistent behavior within all the referencing processes. Hope this makes sense. lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network/Security Universitaetsstrasse 7, 1010 Wien, Austria eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 Fax: (+43 1) 4277 / 9140
Hi, One thing (too early to think about all at once)
If we agree on this more generic solution, we could extend this behavior to other Objects that can be referenced as well. e.g. for mntner: itself. this would be a way tho prevent anyone from putting my mntner ont oan object. (This would solve the issue discussed in the context of the IRT Object - where the mntner of the object should be a proof of authenticity as well)
This idea is good by means of consistency, BUT it would be weaker than the auth: in the IRT, because there are only PGP keys allowed, whereas in a mntner anything is possible. lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network/Security Universitaetsstrasse 7, 1010 Wien, Austria eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 Fax: (+43 1) 4277 / 9140
On 2003-09-04 09:22:56 +0200, Ulrich Kiermayr wrote:
Hi,
One thing (too early to think about all at once)
If we agree on this more generic solution, we could extend this behavior to other Objects that can be referenced as well. e.g. for mntner: itself. this would be a way tho prevent anyone from putting my mntner ont oan object. (This would solve the issue discussed in the context of the IRT Object - where the mntner of the object should be a proof of authenticity as well)
This idea is good by means of consistency, BUT it would be weaker than the auth: in the IRT, because there are only PGP keys allowed, whereas in a mntner anything is possible.
Actually, you can use any "auth:" type in the IRT (even NONE!!!). But don't do that. :-/ -- Shane Kerr RIPE NCC
Shane Kerr wrote:
On 2003-09-04 09:22:56 +0200, Ulrich Kiermayr wrote:
Hi,
One thing (too early to think about all at once)
If we agree on this more generic solution, we could extend this behavior to other Objects that can be referenced as well. e.g. for mntner: itself. this would be a way tho prevent anyone
from putting my mntner ont oan object. (This would solve the issue
discussed in the context of the IRT Object - where the mntner of the object should be a proof of authenticity as well)
This idea is good by means of consistency, BUT it would be weaker than the auth: in the IRT, because there are only PGP keys allowed, whereas in a mntner anything is possible.
Actually, you can use any "auth:" type in the IRT (even NONE!!!). But don't do that. :-/
`,:-] hmm interesting, well then, it mnt-ref and auth are of the same quality in irt as well. lG uk, who slowly starts to wake up :-) -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network/Security Universitaetsstrasse 7, 1010 Wien, Austria eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 Fax: (+43 1) 4277 / 9140
Dear Colleagues, To be consistent with the new organisation object's schema, we'd propose to change the schema of irt object in the following way: - Replace "irt-nfy:" with "ref-nfy:" attribute. The syntax and semantics do not change, only the name of the attribute changes. - Replace "auth:" with "mnt-ref:" attribute. Currently "auth:" attribute in irt object is used to authorise adding references to the irt object from other objects. Its syntax is the same as "auth:" attribute of mntner objects. The proposed "mnt-ref:" contains references to mntner objects, instead of directly specifying the auth methods. Thus, the proposed change adds one more redirection to mntner objects. Although the syntax of "mnt-ref:" is different than that of "auth:", its functionality is the same. With the proposed changes, the new schema of irt object would be: irt: [mandatory] [single] [primary/lookup key] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] mnt-ref: [mandatory] [multiple] [ ] ref-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] You can find the current irt object document at http://www.ripe.net/ripe/docs/irt-object.html Please let us know about your comments. Best regards, Engin Gunduz RIPE NCC Database Group On 2003-09-04 09:54:33 +0200, Ulrich Kiermayr wrote:
Shane Kerr wrote:
On 2003-09-04 09:22:56 +0200, Ulrich Kiermayr wrote:
Hi,
One thing (too early to think about all at once)
If we agree on this more generic solution, we could extend this behavior to other Objects that can be referenced as well. e.g. for mntner: itself. this would be a way tho prevent anyone
from putting my mntner ont oan object. (This would solve the issue
discussed in the context of the IRT Object - where the mntner of the object should be a proof of authenticity as well)
This idea is good by means of consistency, BUT it would be weaker than the auth: in the IRT, because there are only PGP keys allowed, whereas in a mntner anything is possible.
Actually, you can use any "auth:" type in the IRT (even NONE!!!). But don't do that. :-/
`,:-] hmm interesting, well then, it mnt-ref and auth are of the same quality in irt as well.
lG uk, who slowly starts to wake up :-) -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network/Security Universitaetsstrasse 7, 1010 Wien, Austria
eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104
Hi Engin,
Dear Colleagues,
To be consistent with the new organisation object's schema, we'd propose to change the schema of irt object in the following way: - Replace "irt-nfy:" with "ref-nfy:" attribute. The syntax and semantics do not change, only the name of the attribute changes. - Replace "auth:" with "mnt-ref:" attribute. Currently "auth:" attribute in irt object is used to authorise adding references to the irt object from other objects. Its syntax is the same as "auth:" attribute of mntner objects. The proposed "mnt-ref:" contains references to mntner objects, instead of directly specifying the auth methods. Thus, the proposed change adds one more redirection to mntner objects. Although the syntax of "mnt-ref:" is different than that of "auth:", its functionality is the same.
With the proposed changes, the new schema of irt object would be:
irt: [mandatory] [single] [primary/lookup key] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] mnt-ref: [mandatory] [multiple] [ ] ref-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]
Yes, looks good :-) and I think if it works out it is expandable ... I Resent your message to the tf-csirt mailinglist, to get comments from the CSIRT community as well, because they are the ones using that most atm. If we'd even come up with a clever way to reformat those without to much intervention, like autocreating the appropriate mntner from the data in the irt-object, I see no problem changing it. lG uk -- ------------------------------------------------------------------------ Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network Security Universitaetsstrasse 7, 1010 Wien, Austria ------------------------------------------------------------------------ eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 Hotline: security.zid@univie.ac.at Fax: (+43 1) 4277 / 9140 Web: http://www.univie.ac.at/zid/security.html ------------------------------------------------------------------------ GPG Key fingerprint = BF0D 5749 4DC1 ED74 AB67 7180 105F 491D A8D7 64D8
Hi *,
organisation: ORG-AA11-RIPE [...] org-type: LIR mnt-by: RIPE-NCC-HM-MNT mnt-ref: LIR-MNT mnt-ref: RIPE-NCC-HM-MNT
Here, we have "mnt-ref: RIPE-NCC-HM-MNT" because RIPE NCC hostmaster will need to add references to this organisation object when creating/modifying allocation inetnums and aut-nums.
Related to this Point from an experience I had this week: In this context it would also be worth rethinking the behaviour of changed: I wanted to add a mnt-irt to our inet6num, so I added that line to the object, signed it and sent it tothe mostmasters. Ingrid came back to me with the request to add the appropriate changed-line, to reflect the changed line and resign/submit it. I have no idea for a solution (apart from documenting the fact somewhere). lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network/Security Universitaetsstrasse 7, 1010 Wien, Austria eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 Fax: (+43 1) 4277 / 9140
Good morning, On 2003-09-06 11:49:59 +0200, Ulrich Kiermayr wrote:
Hi *,
organisation: ORG-AA11-RIPE [...] org-type: LIR mnt-by: RIPE-NCC-HM-MNT mnt-ref: LIR-MNT mnt-ref: RIPE-NCC-HM-MNT
Here, we have "mnt-ref: RIPE-NCC-HM-MNT" because RIPE NCC hostmaster will need to add references to this organisation object when creating/modifying allocation inetnums and aut-nums.
Related to this Point from an experience I had this week: In this context it would also be worth rethinking the behaviour of changed:
Just FYI, In the past there has been some proposals and attempts to change the "changed:" attribute, like making it an auto-generated attribute, or getting rid of it altogether. However, they were all turned down, sometimes because the users have found another use of the attribute beyond the intended use, and sometimes because of privacy issues. As it stands now, "changed:" attributes can be deleted/added to objects on demand, with a few restrictions. However, the user is not forced by the whois software to add a new "changed:" attribute when it is modified. Thus, the last "changed:" attribute may not actually reflect the date it has been last changed. This is misleading. Secondly, the query users do not really know what "changed:" attribute means. Normally the e-mail box in these attributes specify who performed the changes to the objects, and they are not necessarily responsible for the resources that the objects represent. For example, the email addresses in the "changed:" attributes of an inetnum object are not necessarily the email addresses of the network administrator, so they should not be used to report abuse. However most users and automated tools pick anything that resembles an email address in the whois query result and send them abuse complaints. Regards,
I wanted to add a mnt-irt to our inet6num, so I added that line to the object, signed it and sent it tothe mostmasters. Ingrid came back to me with the request to add the appropriate changed-line, to reflect the changed line and resign/submit it.
I have no idea for a solution (apart from documenting the fact somewhere).
lG uk -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network/Security Universitaetsstrasse 7, 1010 Wien, Austria
eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 Fax: (+43 1) 4277 / 9140
-- Engin Gunduz RIPE NCC Database Group
At 08/09/2003 10:56 +0200, Engin Gunduz wrote: [Ulrich Kiermayr]:
Related to this Point from an experience I had this week: In this context it would also be worth rethinking the behaviour of changed:
Engin says two separate things. 1.
... change the "changed:" attribute, ...
This first one is about the internal characteristics of "changed:"; how it is generated, formatted, authenticated and perhaps stored. 2.
Secondly, the query users do not really know what "changed:" attribute means. ... most users and automated tools pick anything that resembles an email address in the whois query result and send them abuse complaints.
The question here is about external presentation; who sees "changed:", what they are looking for when they see it, what they think it means and what they do with it. The anti-spam WG is preparing a broad proposal, but one early thought is to provide different database views for the different classes of user. Casual users looking for contact information in the default output are an important class, probably not the most well-informed or patient, and it may be worth suppressing "changed:" in the view they get. This applies whatever decisions we make about the internal behaviour or the way LIRs will use the attribute. Rodney Tillotson, JANET-CERT +44 1235 822 255.
user. Casual users looking for contact information in the default output are an important class, probably not the most well-informed or
Unfortunately they use ``clever'' and ``enhanced'' tools.
patient, and it may be worth suppressing "changed:" in the view they get. This applies whatever decisions we make about the internal
That was tried before in 1998 (to be overridden by the "-c" switch), but then changed back. I don't remember the reason. -Peter
On Monday, September 8, 2003, at 04:31 PM, Peter Koch wrote:
user. Casual users looking for contact information in the default output are an important class, probably not the most well-informed or
Unfortunately they use ``clever'' and ``enhanced'' tools.
patient, and it may be worth suppressing "changed:" in the view they get. This applies whatever decisions we make about the internal
That was tried before in 1998 (to be overridden by the "-c" switch), but then changed back. I don't remember the reason.
People who use a query/copy/paste/modify/send cycle to maintain the DB data were hit when they forgot to include the -c flag, loosing the chain of changed: attributes forever. Joao
On Mon, Sep 08, 2003 at 03:21:20PM +0100, Rodney Tillotson wrote:
2.
Secondly, the query users do not really know what "changed:" attribute means. ... most users and automated tools pick anything that resembles an email address in the whois query result and send them abuse complaints.
The question here is about external presentation; who sees "changed:", what they are looking for when they see it, what they think it means and what they do with it.
The anti-spam WG is preparing a broad proposal, but one early thought is to provide different database views for the different classes of user. Casual users looking for contact information in the default output are an important class, probably not the most well-informed or patient, and it may be worth suppressing "changed:" in the view they get. This applies whatever decisions we make about the internal behaviour or the way LIRs will use the attribute.
That seems like a good idea. Many casual users of the RIPE database do not query it directly, rather through a small number of web-based gateways. Would it be worth asking the owners of those gateways to filter out the changed field now, to see what effect that has? Cheers, Steve
participants (17)
-
Arnd Vehling -
DB-News -
Emma Apted -
Engin Gunduz -
Hans Petter Holen -
Joao Damas -
Joao Damas -
Joao Luis Silva Damas
-
Peter Galbavy -
Peter Koch -
Randy Bush -
Rob Blokzijl -
Rodney Tillotson -
Sanjaya -
Shane Kerr -
Steve Atkins -
Ulrich Kiermayr