May 2005 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Deprecation of the NONE Authentication Scheme
by Ziya Suzen 08 Nov '05

08 Nov '05

Dear Colleagues, As announced at RIPE 47 the NONE authentication scheme will be deprecated. After 26 April 2004 the RIPE Whois Database will not accept updates using the NONE authentication scheme. If you have objects protected by a MNTNER object which has the NONE authentication scheme, please assign another authentication scheme or create another MNTNER object to protect these objects. If you are a RIPE NCC member you can create new MNTNER objects through the LIR Portal or send your update to <auto-dbm(a)ripe.net>. History and details: -------------------- 1. Motivation The RIPE Database protects data from unauthorised modification through the use of references to maintainer objects. The maintainer objects contain an "auth:" attribute which specifiy how a user is authenticated during updates to the database. One of the allowed authentication schemes is "NONE", which is actually not an authentication at all, but rather specifies that no authentication is necessary. NONE is intended to be used consciously, as a notification facility or as a means to tag objects. In April 2003, a proposal was sent to the Database Working Group by Hank Nussbacher: It has come lately to the attention in the Internet security realm that spammers as well as crackers are hijacking IP address space. One easy way to "steal" IP address space is via those that have auth=NONE on their objects. It is likely that in many cases NONE is used simply because it is easy. Currently approximately 500 maintainers use NONE - about 5% of all maintainers. 2. Plan Normally with a database cleanup effort, an announcement is sent to the appropriate mailing lists, posted to the RIPE web page, and also sent to the specific users affected. A period of time for cleanup is given. Finally, if the users have not fixed the data then it is modified. However, for the NONE deprecation, it is inadvisable to do this as it means announcing what is in effect a security vulnerability. Also, our operational experience with past cleanups shows that most users do not really participate through the phases of the effort. Therefore, the plan for MNTNER objects with the NONE authentication scheme is: o Announcement only to db-wg mailing list. (This announcement) o Remove "auth: NONE" attributes from all MNTNER objects, by changing them to a "remarks:" attribute with a URL explaining the change. o If that is the only authentication scheme, update the mntner objects, adding MD5-PW with a generated password. o E-mail the "admin-c:" and "tech-c:" of the objects, and the e-mail addresses listed in the "upd-to:" and "mnt-nfy:" attributes of the objects, explaining the change and including the new password if one is added. o Passwords can be requested via an e-mail to <ripe-dbm(a)ripe.net>. The reply with the password will be sent to the same contacts. After a certain period of time the service will be discontinued. Users wishing to use these maintainers may contact <ripe-dbm(a)ripe.net> for assistance. 3. RIPE-NCC-NONE-MNT A maintainer with NONE authentication, RIPE-NCC-NONE-MNT, was added to objects without any maintainer when the database was converted from RIPE-181 format to RPSL format in April 2001. There is a remark in these objects which includes the following: remarks: The RIPE NCC will never use this maintainer object to remarks: enforce any sort of control over user's objects. It is possible this could have been interpreted to mean that no restriction would ever be added to the object. One use of the RIPE-NCC-NONE-MNT has been to allow the creation of objects representing routing policy for resources not allocated or assigned by the RIPE NCC. This is done by using "mnt-routes: RIPE-NCC-NONE-MNT" or "mnt-lower: RIPE-NCC-NONE-MNT" as appropriate. A new maintainer object will be created for these cases, with a well- known password, published in the object: mntner: RIPE-NCC-RPSL-MNT descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. admin-c: RD132-RIPE upd-to: ripe-dbm-notify(a)ripe.net auth: MD5-PW $1$GUExyzzy$XQtbZHGVqy9GW8BiAckBV1 remarks: ******************************************************* remarks: * The password for this object is 'RPSL', without the * remarks: * quotes. * remarks: ******************************************************* mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20040301 source: RIPE The main use of this maintainer is for INETNUM objects. There are approximately 60000 such objects - about 6% of the inetnums. Updates for objects with RIPE-NCC-NONE-MNT are rare, less than 2% of all updates. For objects using RIPE-NCC-NONE-MNT: o If there are other "mnt-by:" attributes it will be changed to a "remarks:" attribute. o Otherwise, the "mnt-by:" will be changed to RIPE-NCC-LOCKED-MNT, which has a locked password (or PGP key). o A "remarks:" attribute will be added explaining how to generate a maintainer. o An e-mail will be sent to the "admin-c:" and "tech-c:" of the objects, and the e-mail addresses listed in the "notify:" attributes of the objects, explaining the change and giving a URL which will help to generate a new maintainer or assign another existing maintainer. o At the URL, the object will be automatically updated to have a new maintainer. o After a certain period of time the service will be discontinued. Users wishing to use these maintainers may contact ripe-dbm(a)ripe.net for assistance. 4. Other maintainers with "auth: NONE" The RIPE-NCC-PN-NONE-MNT was used to mark PERSON objects not to be deleted in the 2001 person cleanup. It can be removed and the maintainer deleted. The LIM-MNT is used for limericks. It will have a well-known password similar to the RPSL maintainer. It will also be maintained by another maintainer (not itself, as currently). -- Ziya Suzen RIPE NCC

4 5

irt object useless
by Andre Koopal 21 Jun '05

21 Jun '05

Last week we updated all our allocations with an IRT object. However, this ended out to be quite useless as the IRT object isn't shown in a default query, which 99% of joe-user will do, they don't know to specify -c. Another problem I noticed is that the irt-nfy isn't suppressed if you do specify -c. So I want to propose to show the IRT object in a default query and to also hide the irt-nfy attribute in that default query. Regards, Andre Koopal MCI

5 13

Implementation of POEM object
by Arife Vural 20 Jun '05

20 Jun '05

Dear Colleagues, [Apologies for duplicates] Following discussions in the Database Working Group, we have made changes to the whois server software. These are the proposed changes: - Add a new object POETIC-FORM that will contain the supported poem types. - Add a new object POEM that will hold the poem itself. - Add a new attribute "form:" that shows the type of poem. There is more information about this below. You can find more details about the discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00246.html We expect to put a new whois server on line with new object support on 3 May 2005 at 16:00 CET. - Add a new POETIC-FORM object: The POETIC-FORM object contains information about the poem type. This is an example of a LIMERICK object: poetic-form: FORM-LIMERICK descr: Poem type for Limerick admin-c: AMR68-RIPE mnt-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20050429 source: RIPE These objects will be maintained by RIPE DBM. You can send new POETIC-FORM objects to <auto-dbm(a)ripe.net>. - Add a new POEM object: A POEM object is similar to the LIMERICK object. Unlike the LIMERICK object, it will have a "form:" attribute that contains information about the poem type. This is an example of a simple POEM object: poem: POEM-NT13-1 descr: RIPE24 dinner text: At a RIPE Meeting, held in Berlin, text: The meal was unusual, the din text: Of the two serenades text: Whose repertoire made us text: All smile and want to join in form: FORM-LIMERICK admin-c: LIM1-RIPE author: NT13 mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE Add a new "form:' attribute: The "form:" attribute indicates the type of poem. - Changes to the default whois query interface: There will be no changes to the whois query interface. - Data transition All existing LIMERICK objects will will be converted to POEM objects. LIMERICK objects will appear in the database for a while, but we will eventually delete them. Here is an example of a LIMERICK object: limerick: LIM-NT13-3 text: The document RIPE-104 text: Goes on longer than ever before text: If you want an address text: And your network's a mess text: Then Daniel will get very sore admin-c: LIM1-RIPE author: NT13 remarks: Great limerick, but the draft document RIPE-104++ remarks: is now called RIPE-136... mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE Here is how it will appear with new object types: poem: POEM-NT13-3 text: The document RIPE-104 text: Goes on longer than ever before text: If you want an address text: And your network's a mess text: Then Daniel will get very sore form: FORM-LIMERICK admin-c: LIM1-RIPE author: NT13 remarks: Great limerick, but the draft document RIPE-104++ remarks: is now called RIPE-136... mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE - Object templates Here is the template for the POEM object: poem: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] form: [mandatory] [single] [inverse key] text: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] author: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] POETIC-FORM object template is: poetic-form: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Regards, Arife Vural RIPE NCC, SED

2 2

Changes for abuse
by Shane Kerr 07 Jun '05

07 Jun '05

Dear Colleagues, The RIPE NCC has implemented the proposed changes to the Whois server software. We will put the new software into production on Wednesday, 2005-04-27. ***************************************************************** These changes alter the default output of the Whois server. If you need the old output, you can get it by using the "-B" and "-G" flags, like this: whois -B -G 193.0.1.17 ***************************************************************** The current implementation is different from the original proposal in this way: - INETNUM and INET6NUM object types will *not* have the "abuse-mailbox:" attribute added. The reason for not adding the "abuse-mailbox:" attribute to the INETNUM and INET6NUM object types is that there was no consensus to add these. Some people supported it and some people did not. It is easier to add attributes than to delete them. Anyone in favour of adding this attribute can attempt to create consensus within the Database Working Group. We have also implemented the proposal to change the order of objects in query results. A revised proposal is attached. As well as the above change: - It explicitly states that "trouble:" will be deprecated. - Some templates and examples were not correct, and have been fixed. -- Shane Kerr Software Manager RIPE NCC The changes we propose are: o To hide attributes that contain e-mail addresses in the default output of queries. We will also provide an option to disable this feature, o To add a new "abuse-mailbox:" attribute to PERSON, ROLE, IRT, MNTNER, and ORGANISATION objects, o To provide an option to display only key attributes and abuse contacts, o To change the IRT object template so that the "signature:" and "encryption:" attributes are no longer mandatory, o To change the behaviour of the '-c' switch in whois queries. We will announce the changes on our website. We will also contact any third-party software developers who rely on the RIPE Database for abuse contact information. You can read the minutes from the Database Working Group discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00469.html (1) Adding the "abuse-mailbox:" Attribute We will add a new attribute to the following object types: PERSON ROLE IRT ORGANISATION MNTNER This optional attribute will contain at least one e-mail address. It will tell users where to send abuse complaints or queries. (The proposed templates for the above objects are at the end of this document.) The description of the new attribute will be the same in all objects: abuse-mailbox: Specifies the e-mail address to which abuse complaints should be sent. An e-mail address as defined in RFC 2822. There is currently a "trouble:" attribute in ROLE objects, which contains free text. We will update ROLE objects, so that any ROLE object that has a "trouble:" attribute that is an e-mail address as defined in RFC 2822, will be copied to the "abuse-mailbox:" attribute. Any other "trouble:" attributes will be converted to "remarks:". The "trouble:" attribute will be deprecated. As an example, see the following: role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info(a)example.com admin-c: TEST1-RIPE tech-c: TEST1-RIPE trouble: Please contact trouble: abuse(a)example.com trouble: for abuse reports, not info(a)example.com nic-hdl: TESTROLE1-RIPE changed: info(a)example.com 20050101 source: RIPE We will replace this with: role: Example Role address: Example Address phone: +11 22 33445 fax-no: +11 22 33445 e-mail: info(a)example.com admin-c: TEST1-RIPE tech-c: TEST1-RIPE remarks: "trouble:" converted on 2005mmdd remarks: Please contact abuse-mailbox: abuse(a)example.com remarks: for abuse reports nic-hdl: TESTROLE1-RIPE changed: info(a)example.com 20050101 source: RIPE (2) Hiding Attributes That Contain E-Mail Addresses Finding the right e-mail address for abuse reports can be confusing. There is currently no easy way to find this information in the RIPE Database. Users often send mail to every e-mail address they see in a query result. To avoid this, we will hide all attributes that contain e-mail addresses from the default output of a whois query for an address. When a user looks up an address, the results may include the following objects: INETNUM INET6NUM ROUTE ROUTE6 ORGANISATION PERSON ROLE By default, MNTNER objects are not shown, but they are often also queried to get contact information. For each of the object types, the following attributes contain e-mail addresses: INETNUM: notify, changed INET6NUM: notify, changed ROUTE: notify, changed ROUTE6: notify, changed ORGANISATION: e-mail, notify, changed PERSON: e-mail, notify, changed ROLE: e-mail, trouble, notify, changed For each address range returned, if there is at least one "abuse-mailbox:" attribute in any of the returned objects, the attributes mentioned above will be removed from the output. If there is no "abuse-mailbox:" attribute, only "notify:" and "changed:" attributes will be filtered out. If an attribute of an object is changed, a comment will be added, to avoid confusion. Users can turn off this suppression. To make this possible, we will implement a '-B' flag. As an example: $ whois 10.0.0.10 Might currently give the following result: inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE status: ALLOCATED PI mnt-by: I-MNT changed: ripe-dbm(a)ripe.net 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm(a)ripe.net nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm(a)ripe.net 20050101 source: RIPE After the change, the result will be: % Note: this output has been filtered. inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE status: ALLOCATED PI mnt-by: I-MNT source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 nic-hdl: ME1-RIPE mnt-by: I-MNT source: RIPE To see the unmodified result, users should type in: $ whois -B 10.0.0.10 (3) Adding 'abuse output' Option To help authors of tools or users who are only interested in the abuse contacts for IP addresses, we will implement a brief output mode. If a user types '-b' when querying the RIPE Database, they will only see the key attributes of address ranges and the "abuse-mailbox:" attribute. This switch will also imply '-c', which requests first level less specific INETNUM or INET6NUM objects with the "mnt-irt:" attribute. It will only work with address space related queries. Here is an example: $ whois 10.0.0.0 Returns: inetnum: 10.0.0.0 - 10.0.0.255 netname: HOME-NETWORK descr: Home Network country: ZZ admin-c: ME1-RIPE tech-c: ME1-RIPE status: ALLOCATED PI mnt-by: I-MNT mnt-irt: IRT-I changed: ripe-dbm(a)ripe.net 20050101 source: RIPE person: Me Myself and I address: Home Alone phone: +11 22 33445 fax-no: +11 22 33445 e-mail: ripe-dbm(a)ripe.net nic-hdl: ME1-RIPE mnt-by: I-MNT changed: ripe-dbm(a)ripe.net 20050101 abuse-mailbox: ripe-dbm-person(a)ripe.net source: RIPE So: $ whois -b 10.0.0.0 Will return: % Note: this output has been filtered. % Only primary keys and abuse contact will be visible. inetnum: 10.0.0.0 - 10.0.0.255 e-mail: ripe-dbm(a)ripe.net e-mail: ripe-dbm-person(a)ripe.net This output will not generate valid objects, and there will be no object separators. If two ranges are returned after making a query, an object separator will be inserted between groupings. Therefore, the output will look like this: inetnum: 10.0.0.0 - 10.0.0.255 e-mail: ripe-dbm(a)ripe.net e-mail: ripe-dbm-person(a)ripe.net (*) inetnum: 10.0.1.0 - 10.0.0.255 e-mail: ripe-dbm-person-2(a)ripe.net (*) Attributes marked by (*) are taken from the person object retrieved by a recursive lookup. (4) Modifications on the IRT Object We will change the template for the IRT object will be changed. You will no longer need a KEY-CERT object to create an IRT object. Currently, the template for the IRT object is: irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] "signature:" and "encryption:" attributes need existing key-cert objects. The Anti-spam Working Group asked us to make these objects optional. You can read an archive of this discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00452.html The template for irt objects will be: irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [optional] [multiple] [ ] encryption: [optional] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Therefore, the object below would be valid: irt: irt-someorg-zz address: address for the irt phone: +11 22 3344556 fax-no: +11 22 3344556 e-mail: contact(a)example.com admin-c: CONTACT1-RIPE tech-c: CONTACT1-RIPE auth: CRYPT-PW XXXXXXXXXXXXX mnt-by: mnt-someorg changed: someone(a)example.com 20050101 source: RIPE We will automate this process, so that help from the RIPE Database Management will no longer be necessary create IRT objects. (5) Changing the behaviour of '-c' option in whois queries Currently, the -c option requests first level less specific INETNUM or INET6NUM objects with the "mnt-irt:" attribute. It does not return any related IRT objects. This will change, so that -c will treat IRT objects as contacts and do recursive lookups on related IRT objects. Here is an example: $ whois -c 10.0.0.0 Returns: inetnum: 10.0.0.0 - 10.0.0.255 netname: TEST-NET descr: Test Net country: ZZ admin-c: TEST1-RIPE tech-c: TEST1-RIPE status: ASSIGNED PA mnt-by: TEST-MNT mnt-irt: IRT-TEST changed: info(a)example.com 20050101 source: RIPE person: TEST1-RIPE . . After the change, the result will be: inetnum: 10.0.0.0 - 10.0.0.255 netname: TEST-NET descr: Test Net country: ZZ admin-c: TEST1-RIPE tech-c: TEST1-RIPE status: ASSIGNED PA mnt-by: TEST-MNT mnt-irt: IRT-TEST changed: info(a)example.com 20050101 source: RIPE person: TEST1-RIPE . . irt: IRT-TEST . . (6) Modified Templates inetnum: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] org: [optional] [single] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-domains: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] inet6num: [mandatory] [single] [primary/look-up key] netname: [mandatory] [single] [lookup key] descr: [mandatory] [multiple] [ ] country: [mandatory] [multiple] [ ] org: [optional] [single] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] rev-srv: [optional] [multiple] [inverse key] status: [mandatory] [single] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] mnt-routes: [optional] [multiple] [inverse key] mnt-domains: [optional] [multiple] [inverse key] mnt-irt: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] person: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [mandatory] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [optional] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [inverse key] ** org: [optional] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] role: [mandatory] [single] [lookup key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] trouble: [optional] [multiple] [ ] abuse-mailbox: [optional] [multiple] [inverse key] ** org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] nic-hdl: [mandatory] [single] [primary/look-up key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [inverse key] ** signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [lookup key] org-type: [mandatory] [single] [ ] descr: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] abuse-mailbox: [optional] [multiple] [inverse key] ** org: [optional] [multiple] [inverse key] admin-c: [optional] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] mnt-ref: [mandatory] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] mntner: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] abuse-mailbox: [optional] [multiple] [inverse key] ** upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] referral-by: [mandatory] [single] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Rows that are marked with '**' are additions to the templates.

14 18

search by changed: attr
by Max Tulyev 26 May '05

26 May '05

Hello! How can I dump all objects I have changed (i.e. where is "changed: my(a)e.mail" attribute present)? -- WBR, Максим Тульев (MT6561-RIPE, 2:463/253@FIDO)

3 2

RIPE Whois Server version 3.3.0
by Can Bican 25 May '05

25 May '05

Dear Colleagues, We are pleased to announce the release of version 3.3.0 of the RIPE Whois server. Major changes to the software include the following: o People upgrading from 3.2.0 need to read the file UPDATE-DB-3.3.0. o The source tree has heavily been modified; build system now makes full use of autoconf/automake. o We have added new options to the configure script. You can choose RPSL variants during configure by using --with-rpslvariant. You can turn RDNS off or on by using the --with-rdns option. o The LIMERICK object type has been upgraded to more the general POEM and POETIC-FORM object types. You can find a complete description of this change at: http://www.ripe.net/ripe/maillists/archives/db-wg/2005/msg00073.html o We have added a Reverse DNS registry checking mechanism. Since this is a specialised requirement for the software, it is initially turned off by default. o We have included a Perl RPSL library in the distribution. o We have implemented abuse mailbox changes, by adding a few new query options and changes to the default output. You can see a full list of changes at: http://www.ripe.net/ripe/maillists/archives/db-wg/2005/msg00057.html o We have changed the name of the server binary: whois_rip is now whois-server. o We have included the ORGANISATION object type. o We have included RPSL-NG facilities in the main branch of the software. This conforms to the RFC at: ftp://ftp.ripe.net/rfc/rfc4012.txt o IRT and MNTNER object creation is now automatic. o dbupdate is now x-509 aware, along with the related KEY-CERT objects. You can find more information on the implementation at: http://www.ripe.net/ripe/maillists/archives/db-wg/2003/msg00144.html You can download this release by anonymous FTP from the following URL: ftp://ftp.ripe.net/ripe/dbase/software/whoisserver-3.3.0.tar.gz You can also check out the release from CVS, which includes test cases, using the following CVS commands: cvs -d :pserver:anonymous@cvs.ripe.net:/cvsroot login cvs -d :pserver:anonymous@cvs.ripe.net:/cvsroot co -r \ release_3_3_0 whoisserver If you have any questions, please contact <ripe-dbm(a)ripe.net>. Best regards, -- Can Bican RIPE NCC Software Engineering Department

1 0

abuse-mailbox
by Philippe Bourcier 25 May '05

25 May '05

Hi, I'm the author of the CyberAbuse whois, which is a tool that catches the "most suitable" abuse contact email for a specific IP/host by searching in the RIRs whois result. It's security and network abuse oriented... it's used in many CERTs or IRTs. I understand there's a new (and long waited for) abuse-mailbox field that my program should catch in the RIPE db. I'd like to know what would you recommend as the behavior for catching the "best possible" abuse-contact in the RIPE db. Here is how the cyberabuse whois used to work (for RIPE) : 1 - search for an IRT object (mnt-irt), if one exist, go catch the associated e-mail 2 - search for an email in all the remarks/trouble/descr fields with the abuse/security/cert/csirt string in it 3 - search for the admin-c's email, if any 4 - search for the tech-c's, if any 5 - search for the first email found I think I'm going to add a search for the abuse-mailbox field between (1) and (2). Is this how you would do it ? Any other comments/suggestions ? Sincerely, Philippe Bourcier

2 1

Re: [ipv6-wg@ripe.net] Re: [ncc-services-wg] RIPE 50 Report
by Shane Kerr 24 May '05

24 May '05

Daniel Roesen wrote: >On Tue, May 24, 2005 at 02:09:07PM +0200, Nick Hyrka wrote: > > >>IPV6 WORKING GROUP >> >>- It was decided that the RIPE Whois Database will continue to include more >>services that run in native IPv6. >> >> > >Hm? > > Right now the Whois server answers queries through a proxy. The server will answer IPv6 itself, and the proxy terminated. Also, there is no IPv6 mirroring facility. This will be added. -- Shane

2 1

Whois changes
by James A. T. Rice 13 May '05

13 May '05

I'm probably posting far too late about this, but: Much as I agree that the default removal of email addresses from the whois output is a good idea, the lack of a changed: field is very annoying. Its always good to know how out of date an object is - and one of the key parameters I've used to decide if the details in an object are likely to be correct (i.e. are they actively maintained). Any chance of having changed: with a date (not an email address) back in the default output? Regards James

4 4

Whois changes
by Erics 12 May '05

12 May '05

Hi, i think this is a good idea. The default output should show the last changed date. This could be very helpful for LIRs. Kind regards Eric

6 7

RE: [db-wg] Implementation of POEM object
by Titley, Nigel 12 May '05

12 May '05

Paul Wilson wrote: > Arife, > > i'm finding this discussion rather anglo-centric. was any > consideration given to a "language" descriptor in discussion of this > object. > > of course the official language of ripe ncc is english, but it's a bit > harsh to expect non-english speakers to contribute good verse in > other than their native language... > > :-) The poem object itself is language independent, although the naming of the poetry-form object is strongly anglo-centric. It was noted during the WG discussion that followed the original presentation that without multibyte character support in the RIPE database (and RPSL in general), the provision of a haiku type was something of an insult to Japanese literature. However, it was felt that the effort involved in making RPSL and the RIPE database fully multibyte compliant, solely to allow the storage of japanese language haikus, could be deferred to a later date. A subgroup of the Secret Cabal(TM), if such a thing were to exist, could of course, be set to work on this, if there were a means to contact them to give them the commission. -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

RE: [db-wg] Implementation of POEM object
by Titley, Nigel 12 May '05

12 May '05

Arife Vural wrote: >>> poetic-form: FORM-LIMERICK >>> descr: Poem type for Limerick >>> admin-c: AMR68-RIPE >>> mnt-by: RIPE-DBM-MNT >>> changed: ripe-dbm(a)ripe.net 20050429 >>> source: RIPE >> >> Slight problem with this example. I beleive we agreed that the >> description of the poetic form should be in the form of the poetic >> form itself. I gave a number of examples: limerick, haiku, prose, >> and english sonnet in my original presentation. This example does >> not comply with the requirement. > > You mean like that, right? > > descr: FORM-LIMERICK > > I got the requirements from DB-WG mailling list thread. From there it > was not so clear. If there would not be any objections, I could > replace those entries as you proposed. > > Arife No, not quite that. The requirements (which came at the end of the thread) suggested that the description of a limerick (for example) should be in the form of a limerick. The description of a haiku should be in the form of a haiku etc. An example for limerick was poetic-form: VERSE-LIMERICK descr: The object consists of a verse descr: in a format approaching the terse descr: The rhymes, very strict descr: Must be carefully picked descr: and it's funny and often perverse admin-c: LIM1-RIPE tech-c: LIM1-RIPE mnt-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20040401 source: RIPE Note the hierachical naming convention for poetic-form objects, all verse type forms should start "VERSE". Remember that not all poetry is verse. So another example would be poetic-form: PROSE descr: Don't let the structure tie your tongue; descr: if you hate the masochism of verse, Descr: remember that you can feel free to use prose, descr: and feel free because you are. admin-c: LIM1-RIPE tech-c: LIM1-RIPE mnt-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20040401 source: RIPE The poetic form names are hierachical so for example the English sonnet form could be Poetic-form: VERSE-SONNET-ENGLISH descr: The English sonnet poem's perfect peak descr: Doth sooth the senses with its gracious line descr: Full fourteen lines, five doubles stressed we seek descr: The first octet a single concept fine descr: Must introduce in argument aright descr: And when is unconcealed its notion hid descr: A pause, a breath must make a junction slight descr: Before the latter part its thought must bid. descr: The sextet takes us further in this scheme descr: Its rhymes EFEFGG march on descr: Alike yet different in their simple theme descr: To those that went before and build upon descr: Them, rearing up the mused-on lambent dream descr: To climax in a final couplet bare descr: That ends this form of verse which flows so fair. admin-c: LIM1-RIPE tech-c: LIM1-RIPE mnt-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20040401 source: RIPE Again, see my presentation for a number of examples. -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

6 5

abuse stuff implemented in the DB, and thanks
by Wilfried Woeber, UniVie/ACOnet 11 May '05

11 May '05

Dear WG Members, earlier today we had a very interesting presentation by Shane, summarizing the various changes in the DB machinery related to implementing the abuse-mailbox facilities. I'd like to take this opportunity to remind you about the availability of the presentation slides from the RIPE50 meeting pages on the web, AND to say "thank you" to everyone at the NCC involved in the implemenation. Looks like a job well done, and in time for review during this meeting! Wilfried.

2 1

RE: [db-wg] Implementation of POEM object
by Titley, Nigel 11 May '05

11 May '05

Olaf M. Kolkman wrote: >> Note the hierarchical naming convention for poetic-form objects, all >> verse > > I have a few maintenance questions. > > Although my colleagues are technically competent, they have > not been hired for their literary skills(*). So although the RIPE DB > staff will technically maintain the poetic-form: we still need a > mechanism to ensure the quality of the "poetic-form" objects. Agreed and it was always noted that this was a highly skilled job. > Will RIPE NCC staff need to contact a secret cabal for quality > control? Alternatively, will we skip quality control and act on first > come first served (serious security considerations: culprits might > specify a Haiku in the form of a Dada poem)? Or should a poetic-form > first be discussed by the db-wg? I would suggest that quality control should be managed by a secret cabal as at present with the limerick object. Secret cabals have a long and illustrous history on the internet and have usually resulted in fast, effective decision making albeit at the slight expense of annoying and upsetting large numbers of people (since my email is always bounced by Randy's "no legal disclaimer" filters, I feel perfectly safe in making this remark). > > I'd settle for the first option, a secret cabal... I may just know an > institution that could perform this task. I'm sure that they will prove themselves adequate to the task, even though I have no idea who they might be, or even if they exist. > > The classification scheme may also need some work. How do we classify > the different forms? Would the Aphorism have its own class or is it a > subclass of PROSE? > > In absence of the review process. Hereby a new proposal > > poetic-form: PROSE-APHORISM > descr: A database entry to be remembered by > admin-c: OK65-RIPE > tech-c: OK65-RIPE > mnt-by: RIPE-DBM-MNT As far as the name is concerned this would be perfectly correct, although ending a sentence with a preposition is perhaps to be regarded as slightly suspect style. (One must, though, remember Winston Churchill's comments on the matter). poetic-form: PROSE-APHORISM descr: A database entry by which to be remembered admin-c: OK65-RIPE tech-c: OK65-RIPE mnt-by: RIPE-DBM-MNT Might be slightly better stylistically. > > and > > poetic-form: VERSE-HAIKU > descr: The haiku object > descr: only seven syllables > descr: in its density > admin-c: OK65-RIPE > tech-c: OK65-RIPE > mnt-by: RIPE-DBM-MNT This is correct in all respects. > -- Olaf > > (*) I am sure I lost credit with my colleagues with this remark but > these are matters of high public interest. Of course. Perhaps we should include an examination of literary skill when engaging RIPE NCC staff. -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

3 2

RE: [db-wg] Implementation of POEM object
by Titley, Nigel 11 May '05

11 May '05

Niall O'Reilly wrote: > On 11 May 2005, at 11:43, Titley, Nigel wrote: > >> ending a sentence with a preposition is perhaps to be regarded as >> slightly suspect style. > > Not really. > > From the Oxford Dictionary of English, 2nd edition (ISBN > 0-19-8613474): > >> The superstition that a preposition should always precede the word >> it governs and should not end a sentence [...] is not based on a >> real appreciation of the structure of English [...]. I did say "perhaps". -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

RE: [db-wg] Implementation of POEM object
by Titley, Nigel 11 May '05

11 May '05

Arife Vural wrote: >> No, not quite that. The requirements (which came at the end of the >> thread) suggested that the description of a limerick (for example) >> should be in the form of a limerick. The description of a haiku >> should be in the form of a haiku etc. An example for limerick was >> >> poetic-form: VERSE-LIMERICK >> descr: The object consists of a verse >> descr: in a format approaching the terse >> descr: The rhymes, very strict >> descr: Must be carefully picked >> descr: and it's funny and often perverse >> admin-c: LIM1-RIPE >> tech-c: LIM1-RIPE >> mnt-by: RIPE-DBM-MNT >> changed: ripe-dbm(a)ripe.net 20040401 >> source: RIPE > > Those desc lines are much nicer than mine :-) > > By any chance you have pointer for the presentation. Yes indeed http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-db-poem.pdf -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

Abuse information: quick snapshot
by Shane Kerr 11 May '05

11 May '05

All, Just a quick update with counts of objects containing "abuse-mailbox:" PERSON objects: 108 of 1138186 0.0095% ROLE objects: 860 of 8662 9.9284% ORGANISATION objects: 19 of 19065 0.0997% IRT objects: 6 of 65 9.2308% MNTNER objects: 34 of 16354 0.2079% The ROLE objects are mostly because of the "trouble:" attribute conversion. The heavy use in the IRT objects is probably because people with IRT objects are especially clueful about the RIPE Database changes, and also concerned about making sure people get to the correct abuse contact. I expect to see ORGANISATION objects increase, especially after we fix the allocation editor on the LIR portal to allow allocations to have "abuse-mailbox:" entries (we expect to have this done today). -- Shane

1 0

RE: [db-wg] Implementation of POEM object
by Titley, Nigel 10 May '05

10 May '05

wrote: > Dear Colleagues, > > [Apologies for duplicates] > > Following discussions in the Database Working Group, we have made > changes to the whois server software. > > These are the proposed changes: > > - Add a new object POETIC-FORM that will contain the supported poem > types. > - Add a new object POEM that will hold the poem itself. > - Add a new attribute "form:" that shows the type of poem. > > There is more information about this below. > > You can find more details about the discussion at: > > http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00246.html > > We expect to put a new whois server on line with new object support > on 2 May 2005 at 16:00 CET. > > - Add a new POETIC-FORM object: > > The POETIC-FORM object contains information about the poem type. > > This is an example of a LIMERICK object: > > poetic-form: FORM-LIMERICK > descr: Poem type for Limerick > admin-c: AMR68-RIPE > mnt-by: RIPE-DBM-MNT > changed: ripe-dbm(a)ripe.net 20050429 > source: RIPE Slight problem with this example. I beleive we agreed that the description of the poetic form should be in the form of the poetic form itself. I gave a number of examples: limerick, haiku, prose, and english sonnet in my original presentation. This example does not comply with the requirement. -- Nigel Titley Peering Coordinator, FLAG Telecom +44 20 8564 5812 ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

2 1

RIPE50 DB-WG Draft Agenda V1
by Wilfried Woeber 04 May '05

04 May '05

Dear DB-WG folks, Chairs, Meeting! Here is the 1st draft of an agenda for the DB-WG later this week. Comments and additional topic proposals requested. Wilfried. ________________________________________________________________________ A. Administrative Matters - scribe - list of participants - agenda - minutes - "remote participation" coordination (if needed) B. DB Update (Shane K., RIPE NCC) [~15 min] C. Changes in the DB for "abuse" stuff (Shane K., RIPE NCC) [~15 min] Y. Input from other WGs - "whois2005" from Address Policy? Z. AOB

1 0

Implementation of POEM object
by Arife Vural 04 May '05

04 May '05

Dear Colleagues, [Apologies for duplicates] Following discussions in the Database Working Group, we have made changes to the whois server software. These are the proposed changes: - Add a new object POETIC-FORM that will contain the supported poem types. - Add a new object POEM that will hold the poem itself. - Add a new attribute "form:" that shows the type of poem. There is more information about this below. You can find more details about the discussion at: http://www.ripe.net/ripe/maillists/archives/db-wg/2004/msg00246.html We expect to put a new whois server on line with new object support on 2 May 2005 at 16:00 CET. - Add a new POETIC-FORM object: The POETIC-FORM object contains information about the poem type. This is an example of a LIMERICK object: poetic-form: FORM-LIMERICK descr: Poem type for Limerick admin-c: AMR68-RIPE mnt-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20050429 source: RIPE These objects will be maintained by RIPE DBM. You can send new POETIC-FORM objects to <auto-dbm(a)ripe.net>. - Add a new POEM object: A POEM object is similar to the LIMERICK object. Unlike the LIMERICK object, it will have a "form:" attribute that contains information about the poem type. This is an example of a simple POEM object: poem: POEM-NT13-1 descr: RIPE24 dinner text: At a RIPE Meeting, held in Berlin, text: The meal was unusual, the din text: Of the two serenades text: Whose repertoire made us text: All smile and want to join in form: FORM-LIMERICK admin-c: LIM1-RIPE author: NT13 mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE Add a new "form:' attribute: The "form:" attribute indicates the type of poem. - Changes to the default whois query interface: There will be no changes to the whois query interface. - Data transition All existing LIMERICK objects will will be converted to POEM objects. LIMERICK objects will appear in the database for a while, but we will eventually delete them. Here is an example of a LIMERICK object: limerick: LIM-NT13-3 text: The document RIPE-104 text: Goes on longer than ever before text: If you want an address text: And your network's a mess text: Then Daniel will get very sore admin-c: LIM1-RIPE author: NT13 remarks: Great limerick, but the draft document RIPE-104++ remarks: is now called RIPE-136... mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE Here is how it will appear with new object types: poem: POEM-NT13-3 text: The document RIPE-104 text: Goes on longer than ever before text: If you want an address text: And your network's a mess text: Then Daniel will get very sore form: FORM-LIMERICK admin-c: LIM1-RIPE author: NT13 remarks: Great limerick, but the draft document RIPE-104++ remarks: is now called RIPE-136... mnt-by: LIM-MNT changed: limerick-wg(a)ripe.net 19960529 source: RIPE - Object templates Here is the template for the POEM object: poem: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] form: [mandatory] [single] [inverse key] text: [mandatory] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] author: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] POETIC-FORM object template is: poetic-form: [mandatory] [single] [primary/look-up key] descr: [optional] [multiple] [ ] admin-c: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] Regards, Arife Vural RIPE NCC, SED

1 0