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
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
participants (12)
-
Arnd Vehling -
DB-News -
Emma Apted -
Engin Gunduz -
Hans Petter Holen -
Joao Damas -
Joao Damas -
Peter Galbavy -
Randy Bush -
Rob Blokzijl -
Sanjaya -
Shane Kerr