- ncc-services-wg - mailman.ripe.net

Re: [ncc-services-wg] Reverse DNS Restructuring Project
by Olaf Kolkman 02 Oct '03

02 Oct '03

* >Where is Appendix 1? The appendix and the table were removed because I considered it was to much detail for this generic proposal and planned to publish it, after more detailed analysis, with the the forthcoming consistency/cleanup proposal. I forgot to remove the reference to it and did not catch that mistake in the final reviews. The original table, appendix 1, is included below. Apologies for the confusion. --Olaf Kolkman Appendix 1. Inconsistencies between the Zone files and Whois Database in August 2003 NET TOTAL-DNS TOTAL-DB IN-DNS-NOT-DB IN-DB-NOT-DNS NS-MISMATCH 62/8 11775 12083 341 844 296 80/8 5910 6098 98 412 158 81/8 6560 6213 31 106 71 82/8 376 281 4 4 1 188/8 2 1 1 0 1 193/8 5940 6918 1032 1072 353 194/8 7374 6780 1928 1302 477 195/8 14739 15493 1531 2354 1106 212/8 20734 22353 790 2626 1320 213/8 16281 17236 575 1498 480 217/8 6257 6631 109 741 154 TOTAL-DNS: total unique entries in the zone files TOTAL-DB: total entries in database IN-DNS-NOT-DB: missing entries in database IN-DB-NOT-DNS: missing entries in zone files NS-MISMATCH: entries with conflicting name servers Note that in the above table the difference between TOTAL-DNS and TOTAL-DB does not correlate with IN-DNS-NOT-DB, IN-DB-NOT-DNS and/or NS-MISMATCH. The reason is that DOMAIN object that contain syntax errors have not been taken into account in the calculation of IN-DNS-NOT-DB, IN-DB-NOT-DNS and NS-MISMATCH. Further analysis of the syntax errors will be performed as part of the cleanup process.

1 0

Re: [ncc-services-wg] Reverse DNS Restructuring Project
by Nick Hyrka 02 Oct '03

02 Oct '03

Hello Hank. At 20:35 01/10/2003 +0300, Hank Nussbacher wrote: >On Wed, 1 Oct 2003, Olaf M. Kolkman wrote: > > > Currently there is a set of zone files that is the authoritative > > source for the reverse tree. In addition there are DOMAIN objects > > in the database. Appendix 1 shows the number and nature of the > > inconsistencies. > >Where is Appendix 1? > > > > > The cleanup should not cause existing delegations to change > > i.e. the zone data has prevalence over Whois database information in > > case of inconsistencies. > > > > A somewhat more detailed cleanup plan will be presented to the > > DB-WG mailing list. > >Shouldn't this proposal: >http://www.ripe.net/reverse/proposal.html >be linked into the reverse page at: >http://www.ripe.net/reverse/ Thank you for your kind suggestion. We've relocated the page with a new link as a result of your input. Regards, Nick Hyrka Communications Manager RIPE NCC >-Hank

1 0

RIPE 46 Meeting Report
by Nick Hyrka 02 Oct '03

02 Oct '03

(Apologies for duplicate mails.) RIPE 46 Meeting Report Dear Colleagues: The RIPE 46 Meeting was held from 1 - 5 September 2003 at the Grand Hotel Krasnapolsky, Amsterdam, the Netherlands. There were a total of 307 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, AfriNIC, LACNIC and ICANN. HIGHLIGHTS ========== Highlights of RIPE 46 included the open discussion on the services of the RIPE NCC during the first session of the RIPE NCC Services Working Group; a presentation on current RIPE NCC services and plans for 2004 by Axel Pawlik, Managing Director, RIPE NCC; an AfriNIC update; and an update on the changes to Test Traffic Measurement. The European Operators Forum (EOF) featured a full-day tutorial on Voice over Internet Protocol (VoIP) and ENUM that included an overview of current technologies and a focus on practical deployment aspects such as gateways, security, provisioning and use of the new ENUM standards. Geoff Huston, Telstra, gave a presentation on IPv4 Address Lifetime Expectancy. The RIPE NCC would like to thank SURFnet, BIT, FLAG Telecom and KPN EuroRings for the support they provided to the meeting. SUMMARY ======== ADDRESS POLICY ============== - Hans Petter Holen, Chair, requested community involvement to help revise ripe-152 ("Charging by Local Internet Registries") if necessary. - The RIPE NCC will resubmit the IPv4 policy document for community review. - There was a discussion on PI/PA issues and whether the distinction is still valid. - It was agreed that a more formal process was needed for the policy development process. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ap DATABASE ======== - Wilfried Woeber, Chair, will co-ordinate with the RIPE NCC to prepare a document summarising the basic assumptions about the use of the RIPE Database. - "status:" attribute values will change. Current efforts aim at consistency between the RIRs and having easy to understand values. - The organisation object proposal received positive feedback from the working group, with suggestions for other features. - The RIPE NCC will implement X.509 authentication before the next RIPE Meeting. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#db TEST TRAFFIC MEASUREMENTS (TTM) ========================= - As of 1/1/2004 changes will be made to the TTM service contract: Fees will be lowered, all data will be made public with lightweight Acceptable Use Policy (AUP). - Bandwidth measurements: tests showed that results are not conclusive enough so the TTM service will wait before delivering this new product. TTM Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#tt ANTI-SPAM ========= - Rodney Tillotson, Chair, will post a proposal to the Anti-Spam mailing list regarding methods to improve finding abuse contacts in the RIPE Database. Anti-Spam Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#anti-spam IPv6 === - The 6BONE phase-out was discussed. The next milestone will be 01/01/2004 when new allocations stop. - Discussion on the separation of the identifier and locater functions of IP addresses in regards to IPv6 multihoming. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ipv6 TECHSEC ======== - Community feedback was requested on the requirements needed to secure large scale IP infrastructure especially around CLI interface requirements. - The RIPE NCC presented a report on DNSSec status, DISI achievements since RIPE 45 and the impact of signing on zone size. - George Jones, Mitre, gave a presentation on operational security requirements including the history and current status of the requirements, related work, next steps and milestones. - Baiba Kaskina, TERENA, gave a presentation on Euro CSIRT developments that included details on the CSIRT Task Force, the countries involved, the projects and deliverables. - NLNetLab presented an update on Fonkey and PKI-related developments in IETF. TechSec Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#techsec EIX == - Support was expressed for aligning and harmonising IPv6 address space policy regarding IXPs with other RIRs and existing IPv4 policies. - Reports were presented by 11 European IXPs in Europe that showed a trend of steady growth, use of GE instead of FE and wide deployment of IPv6. - Discussion of the Inter-Provider Traffic Analyzer that uses past data and statistical calculations to detect anomalies in traffic patterns. - EIX presentations were given on the anycast deployments of the "F" and "K" root servers by ISC and the RIPE NCC. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#eix DN* === - From the merging of the former DNS Working Group and DNR Forum it was concluded that one working group is sufficient to deal with everything related to Domain Names. A new name/charter will be discussed on the mailing list. - Jaap Akkerhuis, DN* Co-Chair, will organise a "DNS Related Issues" document. - Peter Koch, DN* Co-Chair, talked about how firewall vendors could make mistakes handling DNS communication issues. DN* Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#dn RIPE NCC SERVICES ================ - Axel Pawlik noted that the RIPE NCC will present more details in next year's RIPE NCC budget. - There were comments on the current RIPE NCC services, whether they benefit the entire community and whether a 'pay per service' system could be an option. - There was discussion about the need for a more transparent evaluation of RIPE NCC activities and how they benefit the community. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ncc TUTORIALS ========= - The RIPE NCC staff presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/ripe-46/tutorials/ip-request/ - A full-day tutorial on VoIP and ENUM was presented during the European Operators Forum (EOF). For more information about the EOF at RIPE 46 see: http://www.ripe.net/ripe/meetings/ripe-46/eof.html RIPE MEETING WEBCASTING ======================= - The third phase of RIPE Meeting webcasting trials was held at RIPE 46. Recordings of certain sessions from RIPE 46, including the Plenary, have been archived and can be accessed at: http://www.ripe.net/ripe/meetings/ripe-46/webcast.html HOSTMASTER CONSULTATION CENTRE (HCC) ==================================== - The RIPE NCC Hostmaster Consultation Centre was open at RIPE 46, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. Later consultation hours, as introduced at RIPE 44, were continued. "MEET & GREET" =============== - The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 46. "Meet & Greet" introduces newcomers to the meetings, to key attendees of the RIPE community and to social events throughout the week. More information can be obtained by contacting the RIPE NCC's Pepa Tejedor Carnicero at <meet-greet(a)ripe.net>. RIPE 46 REFERENCE PAGE ====================== - A complete list of RIPE 46 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-46/index.html RIPE NCC GENERAL MEETING ======================= - The RIPE NCC General Meeting 2003 was held Friday, 5 September 2003, adjacent to the RIPE 46 Meeting, at the Hotel Krasnapolsky in Amsterdam. For the highlights from the RIPE NCC General Meeting 2003, please see: http://www.ripe.net/ripencc/about/gm/gm2003/highlights.html RIPE 47 ====== - RIPE 47 will be held in Amsterdam, the Netherlands, from 26 - 30 January 2004. Information on RIPE 47 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-47/ NEW LOCAL INTERNET REGISTRIES (LlRs) - PLEASE NOTE LIRs who signed up after 1 January 2002 are entitled to two (2) free tickets to attend the next RIPE Meeting. The tickets cover the meeting fee only and do not apply to the RIPE dinner, travel or hotel accommodation. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/new-lir.html For more information, contact <meeting(a)ripe.net>. END

1 0

Re: [ncc-services-wg] New service: ip2asn
by Wilfried Woeber, UniVie/ACOnet 29 Sep '03

29 Sep '03

>I *assume* that the development of this service will be funded 100% by the >paying customers of the TTM and that any benefit that RIPE members will gain >will be as a pleasant and cost-free side effect ? > >If not, why not ? > >Peter As this is talking money, benefits (or not) and activities of the NCC again, could we/you please try to use the proper terms?! Otherwise we get more confusion that we can handle. - RIPE does not have members. RIPE is the vehicle to support participation of the community in actvities related to the Internet in our region. - the individuals participating in RIPE do _not_ pay anything (other than in relation to attending RIPE meetings). - the RIPE _NCC_ is a membership organisation. Members do have a service contract with the NCC and pay for _all_ services rendered by the NCC; i.e. including those which are available to the users and organisations on the Internet. Thanks for your consideration. Regards, _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2

Re: [ncc-services-wg] New service: ip2asn
by Joe St Sauver 27 Sep '03

27 Sep '03

Hi, #3) "Routeviews project now has a test/static asn zone up that you can try" # # % dig @archive.routeviews.org 13.142.223.128.asn.routeviews.org txt # # comments: interesting idea but at the time it was still under # development. It's a production service now, and gets rebuilt and reloaded twice a day; DMM announced it on NANOG, for example. The comment was also offered: # strange replies on non-matched IPs, e.g. try # host -t txt 7.227.290.195.asn.routeviews.org Zen-like question: for dotted quads not in the routing table, what *should* be returned? One postulated answer: 4294967295 ==> "route not in table" You could pick some other "magic" number, but I think this one should serve the purpose just fine. :-) Regarding the other ip2asn methods, I'm happy having a thousand methods bloom, so long as they enhance the ability of folks to tie dotted quads to a relevant responsible entity. :-) Regards, Joe P.S. Also note that in addition to the asn zone, an aspath zone is also available, provided in part to deal with any attempt to interpose "throw away" stub ASNs to shelter "real" ASNs; it is available by querying host -t txt $revip.aspath.routeviews.org Be sure to anticipate and plan for the possibility of multiple aspath txt records being returned in response to a query.

1 0

Re: [ncc-services-wg] Incident Response Service (IRS) [was: Unneeded RIPE tasks] (fwd)
by Henk Uijterwaal (RIPE-NCC) 25 Sep '03

25 Sep '03

Dear Wilfried, Hank, On Fri, 22 Aug 2003, Wilfried Woeber, UniVie/ACOnet wrote: > >Section 5: > >"Incident Response Service (IRS) > >Procedures will be set up to quickly provide RIPE NCC members, the Internet > >community and the general public with authoritative data about unusual > >events on the Internet, such as DDoS on the RIPE NCC." I wrote this sentence and the paragraphs before them and, with all due respect, but I think that Hank cut away too much text here. > 1) can we have a more elaborate description from the NCC of what > activities are expected to be performed under this headline? These lines are part of a larger piece of text describing the Information Services (IS) activity. The goal of the IS activity is to collect statistical data on the Internet, ranging from individual providers (for example, RIS and TTM) via policy making groups (AP-WG on usage of resources), the Internet community (for example: number of AS's and prefixes seen) to the general public. Collecting the data alone is not sufficient, of course, we also want to make sure that the statistics we collect reaches the appropriate people in a timely manner. A subset of the IS activity is therefore to have procedures in place to distribute reports on data (analysis) quickly if the need arises. It is obviously not a goal to repeat what others are already doing quite well. However, the RIPE NCC has data that others do not have, and this we want to distribute. For example, earlier this year, we published a report on the impact of the sapphire worm on the Internet. Another example is a recent discussion on heise.de, on the unreachability on the .at ccTLD from the Telecom Austria network, involving some fingerpointing. NIC.AT already published the plots, but this could have been another case where we'd publish our data in order to (in)validate a claim. > 2) is there any WG which could be polled or which has "adopted" this > activity for definition and development (or is expected to do so)? As soon as the AP2004 is approved, we (Daniel K and myself) will write an implementation document, describing the activities proposed under section 5 in more detail. This document will be circulated to, I'd guess, the services-WG and discussed there. Cheers, Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(a)ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC)

11 21

Organisation Object Proposal, version 3
by DB-News 22 Sep '03

22 Sep '03

Dear Colleagues, [apologies for duplicate messages] After the discussions we had in the RIPE 46 Meeting and in the WG mailing lists, we have incorporated agreed modifications into organisation object proposal, which you can find below. This is the Version 3 of the proposal. You can find the first version at http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00013.html the second version at http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00159.html and a summary of discussions on the second version at http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00213.html Thank you very much for your input on the issue. 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 objects using an "org:" attribute. All objects associated with a particular organisation ID can be retrieved by performing an "inverse query" for this ID 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:", "mnt-ref:", "organisation:", "org-name:", "org-type:" and "org:" have their usual meanings. organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [look-up key] org-type: [mandatory] [single] [ ] descr: [optional] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [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] [ ] 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. "mnt-ref:" Specifies the maintainer objects that are entitled to add references to the organisation object from other objects. "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 object type. It points to an existing organisation object representing the entity that holds the resource, in the cases where the whois DB object represents an Internet resource. In other objects, it can be used to specify the business relations. The value of this attribute is the ID of the organisation object. It is mandatory in the 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. "org:" attribute is single-valued in the inetnum, inet6num and aut-num objects, and it is multi-valued all other objects. The "org:" attribute is used to specify the holder of a resource in inetnum, inet6num and aut-num objects, thus it must be single-valued in them. In other objects, it specifies business relations (like in a person object, where it can be used to specify whom the person works for) it can be multiple (in the person object example, a person might work for several companies). 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 in the "mnt-ref:" attributes of the organisation object - from one of the maintainers in the "mnt-by:" attributes 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. country: NL phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(a)example-org.net admin-c: EXAM1-RIPE tech-c: EXAM2-RIPE notify: ripe-mailbox(a)example-org.net ref-nfy: ripe-mailbox(a)example-org.net mnt-ref: EXAMPLE-MNT mnt-by: EXAMPLE-MNT changed: someguy(a)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(a)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(a)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

1 0

Proposed change of "mnt-lower:" behaviour: procedure and timelines
by Katie Petrusha 18 Sep '03

18 Sep '03

[Apologies for duplicate messages] Dear colleagues, In March 2003, the RIPE NCC circulated the proposal to change the behaviour of the "mnt-lower:" attribute in inetnum, inet6num and domain objects. Currently, if the "mnt-lower" attribute of a parent object is absent, anybody can create more-specific objects. The goal is to change this behaviour to a more secure Routing Policy System Security (RPSS) style scheme. In RPSS, objects use "mnt-lower:" to specify a maintainer which has the ability to authorise the creation of more-specific objects. If a "mnt-lower:" attribute is not present, then the "mnt-by:" of the less-specific object is used. A similar scheme is already used for route object creation ("mnt-routes:" attribute). As inetnum objects representing allocations are maintained by the RIPE NCC, deployment of this scheme may not allow LIRs to create assignments from their allocation if the LIR does not have a "mnt-lower:" attribute pointing to the LIR's maintainer. To solve this problem, allocation objects have to be modified to include a "mnt-lower" attribute. We have applied certain heuristics to determine the most suitable maintainer for an allocation. If there is no maintainer, a new maintainer will be generated. Details about project assumptions and heuristics were presented at RIPE 46: http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46-db-allocatio… The initial proposal was sent in March 2003: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00033.html The RIPE NCC suggests the following implementation plan: Step 1. Distribute this plan for approval. Time: 2 weeks Step 2. Notify contacts whose allocations need to be modified Wait for feedback and people making updates themselves Time: 1 month Step 3. RIPE NCC will check all affected allocations again and update the ones still requiring modification, generating necessary maintainers and notifying contacts. Time: 1 day Step 4. Passwords for generated maintainers made available through the LIR Portal. Wrong modifications can be corrected through the LIR Portal as well. Time: 1 day Step 5. Deploy the change in the RIPE Whois Database Software to support new scheme. Time: to be announced Any suggestions or comments on this plan are welcome. If your allocation doesn't have a "mnt-lower:" attribute, we encourage you to update it as soon as possible through the LIR portal. If you don't have a "mnt-lower:" after this proposal has been implemented, you won't be able to create any new assignments for your allocations. We believe that this change will be beneficial for all RIPE Whois Database users and we hope the migration will go as smoothly as possible. Thanks for your co-operation. Katie Petrusha Database Group RIPE NCC

1 0

Re: [dns-wg] Re: dnsmon / .org
by Daniel Karrenberg 15 Sep '03

15 Sep '03

Jim, [I agree it would be better to have this discussion (again) in ncc-services. I have copied it there and encourage people to reply there only.] I could write a reply rant about the individual points in your rant but the main difference of opinion we have is about the mission of the RIPE NCC. This mission is broader than just being a RIR: "The mission of the RIPE NCC is to perform activities for the benefit of the membership, primarily activities that the members need to organise as a group, although they may be competing with each other in other areas. While an activity may result in services being provided to an individual member, performing the activity as a whole must benefit the RIPE NCC membership as a group. Membership is open to anyone using the RIPE NCC services. The activities and services of the RIPE NCC are defined, performed, discussed and evaluated in an open manner. In all of its activities, the RIPE NCC observes strict neutrality and impartiality in regard to individual members." Monitoring DNS and gathering Internet statistics has always been a part of these activities from the very first activity plan in 1991. See ftp://ftp.ripe.net/ripe/docs/ripe-035.txt Of course the activities themselves come and go and those that stay change shape. However the NCC is, and has always been, more than a place that just registers numbers. Daniel ------ Ah, well I'll rant back just for the heck of it. My main point is above. read on at your own risk. Rant-Warning: Moderate to Severe from Varying Directions On 10.09 12:01, Jim Reid wrote: > > To be honest Daniel, I think your mail indicates the way RIPE NCC > seems to have lost sight of its raison d'etre. Why is an RIR -- whose > main (only?) job is to hand out IP addresses and AS numbers -- getting > into other areas that are clearly outside its core business? See above. The NCC is not getting into them it has been there all the time. It is not the RIPE NCC that is changing but it is *you* proposing a change. > ARIN and > APNIC are providing that core service to their regions with a fraction > of the staff that the NCC has. Fraction yes, but not a very small one and not orders of magnitude. Also it appears to me after a quick glance at the ARIN and APNIC web sites that the RIPE NCC fees are very comparable to the fees of the other RIRs, actually slightly lower in many categories. > IMO, there must be complete transparency about non-core activities at > the NCC. I agree completely. > These things should be seen to be self-funding or else making > a profit to reduce the costs of the core services and/or membership > fees. If they're not, there will be a suspicion that it's the other > way round. ie Income from the NCC's monopoly operations are > cross-subsidising these non-core activities. For maximum independence the membership fees should cover all activities. > Now I know you'll say that NCC does these other things as "a benefit > to the community" and "the membership has approved them". I'm not so > sure that either of these things are really true. Has a majority of > the *membership* -- not those who turn up for the AGM or take the time > to vote -- ever approved the activity plan? I beg to disagree. Opener than RIPE NCC and RIPE is hardly possible. If people choose not to participate there is little one can do. One of my major frustrations, past and present. > Has the activity plan ever > said something like "non-core activity X costs Y. If it is dropped. > the membership fees can be reduced by Z. Do you want to pay for X?"? This is very hard to do since activities are so interdependent. The budget gives a general idea of the relative sizes though. > Take DNS hosting for instance. RIPE NCC provides free service to any > TLD that asks. That's fine for poor countries with weak infrastructure. > Nobody should dispute that helping them is a good and noble thing and > that NCC should be doing that. But serving anyone else means those > TLDs are conditioned into getting something for nothing. They get into > a mindset that they shouldn't have to pay for DNS service or arrange > proper contracts, set up SLAs, put servers in decent IXPs, etc. In > short, they don't need to take their responsibilities seriously. That > has to be a Very Bad Thing in the long run. Then there's the issue > about having so much important DNS stuff on ns.ripe.net. That's a Very > Bad Thing too, though I know you disagree with me on this. I see your point and I actually agree, but you have to put it into historic perspective too. There were no commercial offerings when we started this and none were expected any time soon. This activity has helped DNS stability enormously over a long period. And what about our rescue of ns.eu.net? As a matter of fact most bigger TLDs are no longer using either. So the market works. We are not marketing or improving it. But does that mean we have to shut this down now? When? > Here's another example of how NCC crossed the line IMO. The NCC was > involved in the development of NSD. Fair enough, you might think. The > gene pool of DNS software is too small. So having another DNS > implementation is good, so this was/is a benefit to the community. > However one of the NCC's members -- my former employer, Nominum -- > was/is selling its own DNS implementation. So Nominum's money in > membership fees was and is used to fund the NCC to develop software > that competed with and undercut Nominum's product. This cannot be > right. [As it turns out Nominum doesn't consider NSD to be a credible > competitor or a revenue threat to its software, but that's another > story.] We needed this to responsibly operate k.root-servers.net in the light of extremely serious concerns about server software diversity combined with the requirement for open source. We have helped with the design because that is the best way to get one's requirements met. We have helped with the testing because we had to test thoroughly anyway before using it on K. So the additional effort was not that big and the Internet is now a safer place. And we have done all this *extremely* openly. You could say that I came close to bragging about it ;-). > There may well be further examples of this sort of thing in > the other non-core activities of RIPE NCC. Why would anyone pay for a > place on my DNSSEC training course (if I was selling one) when NCC is > offering their course for free? Who is selling DNSSEC courses? The whole point of DISI is to kick-start deployment of something that makes the Internet infrastructure more secure in the absence of clear economic drivers. We have done this before, remember CIDR? > I fear that your plans for DNS monitoring will similarly distort the > market. Firstly, potential customers -- TLDs, regulators, etc -- will > expect to get this type of service for free instead of paying for it > as they really should. Secondly, it will prevent commercial operators, > some of whom could well be NCC members, from providing this kind of > service. Who can compete with free? Yes, but is there a market? And can this be done independently and neutrally for a fee? Again we needed this for k.root-servers.net operations. > That brings up the concerns about > monopolies and cross-subsidies again. Thirdly, this service could > become a bottomless pit for NCC resources. What are the current and > projected costs and how are they covered? My estimate of the incremental cost of developing it so far are about 1-2 weeks of a network engineer, and 5 weeks of a chief scientist. However it is based on the network of test boxes and on the RIPE NCC web presence. How do you account for that? Difficult. We also needed something like this for operating k.root-servers.net responsibly. One could argue that the incremental cost to that is even less. But again: This helps DNS stability and Internet self-regulation. If there is another viable business model to do this at the required quality and neutrality I am all for it. I just do not see that. > of NCC extending itself well beyond its core function. Finally, > incrementally adding these sorts of non-core services doesn't just > entrench the NCC monopoly: it embraces and extends it. See above. DNS monitoring is an NCC activity since 1991. > Another point. The internet and telecommunications industry has been > suffering in the last few years. Budgets have been cut and companies > have downsized or gone bust. At this time NCC should be seen to be > tightening its belt, not adding new non-core activities. The RIPE NCC is another kettle of fish than a commercial company. You need stability and neutrality and that has its price! What if you lean it until it falls over at the most inconveient time? Talking about fairness: The RIPE NCC does not have stock options either. Yes I have a relatively secure job, but that's because I think the RIPE NCC is important for the Internet in Europe and I chose for it *in good times* when there were *a lot* more interesting offers in terms of remuneration. Daniel

16 27

Re: dnsmon / .org
by Wilfried Woeber, UniVie/ACOnet 12 Sep '03

12 Sep '03

I fail to see an "obvious", structural relationship between a LIR and the parties responsible for the reliable operation of a ccTLD name service? Wilfried. ______________________________________________________________________ >At 11:36 AM 10-09-03 +0200, Daniel Karrenberg wrote: >>On 10.09 12:18, Hank Nussbacher wrote: >> >> > RIPE NCC should only monitor those ccTLDs that are LIRs or that their LIR >> > is willing to endorse. -Hank >> >>I like the principle. However .... >> >>How would this endoresement be determined? > >Each LIR would be entitled to one ccTLD to be monitored. Most won't need >it. Assuming there are about 50 countries in the RIPE area, and about 3500 >LIRs, I am sure that one can find a LIR to support a ccTLD to be >monitored. That means that the other countries in ARIN/APNIC/LACLIC would >have to fund their own service. > >-Hank >LIR: il.iucc

1 0