September 2003 - ncc-services-wg

Fwd: RIPE 46 - Minutes of Ripe NCC Services WG
by Kurt Erik Lindqvist 21 Jan '04

21 Jan '04

Please send corrections / comments. Best regards, - kurtis - Begin forwarded message: > From: Sabrina Wilmot <sabrina(a)ripe.net> > Date: mån sep 29, 2003 13:06:11 Europe/Stockholm > To: Kurt Erik Lindqvist <kurtis(a)kurtis.pp.se> > Subject: RIPE 46 - Minutes of Ripe NCC Services WG > > Hi Kurtis, > > Please find below the minutes of the Ripe NCC Services WG at RIPE 46. > > Regards, > Sabrina > RIPE NCC > > >> RIPE 46, Amsterdam >> >> Working Group: Ripe NCC Services >> Chair: Kurt Erik Lindqvist >> Scribe: Isabel Pinto Coelho Sena >> >> Agenda: >> >> Slot 1, Tuesday 2/9 14.00-15.30 >> >> 1. NCC Services WG Charter (Kurtis) >> 2. RIPE NCC Services Direction (Axel Pawlik) >> Service level and activities 2004 >> 3. RIPE NCC Information Services >> 4. Discussion & input time / Open Mic session >> >> Slot 2, Thursday 4/9 11.00-12.30 >> >> 5. Presentation on X.509 and certificates (Dirk-Willem van >> Gulik). >> Discussions around the x.509 implementation of the RIPE NCC >> and what other RIRs have done. >> 6. DNS Services - Modification Plans >> 7. Proposals from the community >> 8. Discussion & input time / Open Mic session >> X. AOB >> Z. Close >> ________________________________________________________________ >> >> 1. NCC Services WG Charter >> >> WG Charter presented. No objections were made to it's content. >> >> 2. RIPE NCC Services Direction (Axel Pawlik, Managing Director >> RIPE >> NCC) >> Service level and activities 2004 >> >> See Axel's presentation at >> >> http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46- >> nccserv-ncc-services.pdf >> >> Kurtis Lindqvist : Who has read/seen the Member Update? >> [~20 people raised their hands] >> Kurtis Lindqvist : Who here are Members? >> [~60 people raised their hands] >> >> 3. RIPE NCC Information Services >> >> See Axel's previous presentation from slide 27 onwards >> >> http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46- >> nccserv-ncc-services.pdf >> >> 4. Discussion & input time / Open Mic session >> >> >> Kurtis Lindqvist : Are there any questions for Axel? >> [No one had questions] >> >> Kurtis Lindqvist : I have one myself: You spoke of the data you have >> that can be used to educate journalists, where do you want to push >> them, just as a general awareness? >> >> Axel Pawlik (MD RIPE NCC): We want them to know that we are working >> well, we want the industry to tell them "do not interfere, they work >> well". As an example: name servers >> >> Kurtis Lindqvist: Any other questions? >> [None were raised] >> >> Kurtis Lindqvist : please register for the GM >> >> Axel Pawlik : there was a heated discussion on the mailing lists? >> None now? >> [None responded] >> >> Rob Blokzijl (RIPE Chairman): I'm surprised that there is no one that >> is willing to discuss the issues off the mailing-list, so I will bring >> up 2 issues that were often discussed. First one is: Whether all these >> services that the RIPE NCC offers are needed? I would like also to >> point that there was no discussion on whether they are _useful_ >> however. Then there was the issue of a flat free financial >> contribution versus a supermarket scenario? Meaning that one could >> pick and choose the services one is willing to pay and have use for. >> >> Wilfried Woeber (Vienna University - ACOnet): I've observed through >> the years another organization where the same discussion was going on >> for years, started out as a flat free and then some started to object >> to this model. In the end, they found the most reasonable solution: >> you buy all or nothing. It is difficult to find out which activities >> are optional and which mandatory. Individual amount, increasing the >> administration overhead that goes along with keeping up with this >> supermarket model, this will not come for free... The complexity that >> we might inject into the subject is not going to be easy. It also >> splits the RIPE Community into 2 / 3 / 4 camps. Copyrighting on >> certain Services, making people pay for copies. It will de-stabilise >> the RIPE NCC and the Community. >> >> Kurtis Lindqvist: Well, a number of people are questioning the order >> and priority of the activities. >> >> Rob Blockzijl (RIPE Chair): I hope that one of the results of having >> this WG is to make people remember why certain services were created >> in the past, as the NCC did not just came up on a idle afternoon with: >> "let's create an activity". The NCC has always listened to the >> Community's input. It might not have been clear as to where and when >> the decisions were taken, that's why I'm glad we have this WG. Having >> it, it is possible to revisit the past and re-evaluate current >> services, although it might be more constructive to look at the future >> and we can improve. >> >> Kurtis Lindqvist : How many of you have read the Activity Plan? >> [~10 max raised their hands] >> I'm concerned because some people on the mailing list indicated that >> they can not influence the AP, but most here have not read it. >> >> Kurtis Lindqvist : If there are no other questions I'll see you all on >> Thursday. >> >> FINISH >> >> NO ACTIONS >> >> _______________________________________________________________ >> >> Slot 2, Thursday 4/9 11.00-12.30 >> >> 5. Presentation on X.509 and certificates (by >> Dirk-Willem van Gulik - apache) >> Discussions around the x.509 implementation of the RIPE NCC >> and what other RIRs have done. >> 6. DNS Services - Modification Plans (Olaf Kolkman) >> 7. Proposals from the community >> 8. Discussion & input time / Open Mic session >> X. AOB >> Z. Close >> >> ________________________________________________________________ >> >> 5. Presentation on X.509 and certificates (by >> Dirk-Willem van Gulik - apache) >> Discussions around the x.509 implementation of the RIPE NCC >> and what other RIRs have done. >> >> Kurtis Lindqvist: As there were quite a lot of questions on the >> mailing list about X.509, we will have a presentation about it and >> also invite the other RIRs to explain what they are doing in their >> region. Also, at the last session I forgot to mention that we might >> require a co-chair, as it is mentioned in the charter. >> >> Dirk-Willem van Gulik: This presentation focuses mainly on the issue >> of trust, not as much on the technical aspects of X.509 >> >> http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46- >> nccserv-pki-x509.pdf >> >> Kurtis Lindqvist : any questions ? >> [None] >> >> Presentation by Andrei Robachevsky, Chief Technical Officer, Ripe NCC >> >> "PKI development at the RIPE NCC" >> http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46- >> nccserv-pki.pdf >> >> Kurtis Lindqvist: any questions? >> >> Taiji Kimura from JPNIC: are there plans for non-repudiation of the >> query, validate queries to the DB? >> >> Andrei Robachevsky : no, this is not about the DB itself, but more >> about correspondence with the NCC. >> >> Wilfried Woeber (DB WG Chair): We have been discussing whether we want >> to introduce a system to tag objects in the DB with the auth method >> that was used for the last update of the object. This is an idea that >> we have been playing with, if the community wants this, then please >> come forward with a plan. >> >> Wilfried Woeber: About integrating a Certification Authority across >> RIRs, I would recommend to first try it in our region, find out if it >> works well. I'm not a fan of having hierarchy in the trust >> model. Individual registries should do it in their region, then we >> find out what we need to cross the borders. I would not like RIRs to >> all go to Verisign for instance. >> >> Janos Zsako (RIPE NCC Executive Board): about message signing, we live >> with the assumptions that the db is in a secure server, so whether >> after the modification/update with PKI the data is still stable is >> questionable. We can store the update method, again assuming that the >> db cannot be corrupted in the mean time. So we need a system that >> verifies that the db has not been corrupted. >> >> Kurtis Lindqvist: in conclusion, issue is if queries and/or DB entries >> must be signed, and whether the content of the DB is secure, but this >> is maybe more a topic for the DB WG. >> >> ARIN - Ginny Listman: >> >> http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46- >> nccserv-arin-x509.pdf >> >> APNIC - Anne Lord: we are doing the same as Ripe NCC, issuing >> certificates for our equivalent of the LIR Portal, MyApnic. We have >> issued 500 certificates so far. >> >> LACNIC Raul Echeberria: we would like to implement a certification >> system before 2004. Right now we are still working on the budget that >> would be needed for it. >> >> Kurtis Lindqvist: Thank you all. >> >> 6. DNS Services - Modification Plans (Olaf Kolkman) >> >> http://www.ripe.net/ripe/meetings/ripe-46/presentations/ripe46- >> nccserv-rdns.pdf >> >> Kurtis Lindqvist : I like the idea, any questions ? >> [None] >> >> 7. Proposals from the community >> 8. Discussion & input time / Open Mic session >> >> Kurtis Lindqvist: Now we have the open mike session: floor is open. In >> future sessions I would like to have people's presentations or >> proposals in writing on the mailing list before they are presented at >> RIPE Meetings >> >> Hank Nussbacher (IUCC): I have been asked by many people to speak up >> during this WG as I have sent some emails to the mailing list. My view >> is that a lot of the members had their budget cut and the NNC has not >> had their budget cut in the same fashion. We are apathetic, 2250 euro >> is not that much to warrant that people can spend 250 euro/1 hour of >> their time on the mailing list. There are many good things in the NCC: >> DB group is the world leader. But to evaluate how the NCC is spending >> their money we need a more transparent Activity Plan. For instance for >> the trainings, they are free of charge. I would like to know the >> budget and man-power needed for these free trainings. Instead, it's >> budget is incorporated in the RS budget, there is no way to know how >> much of that is used for the trainings, there is no break-down of the >> costs. The TTM group, IRT - there has been nothing mentioned about it >> at this meeting BTW - there is nothing about it in the AP, therefore >> we do not know the manpower and budget it needs, the only way to know >> for the membership is to have a break-down and it does not exist. 10 >> to 20 people have responded to my mails, which is not really enough to >> know what the majority of the community thinks about these issues. >> >> Kurtis Lindqvist : yes, people do not care, like we saw at the last >> session on Tuesday, that only a handful read the AP. I guess the >> majority is happy, but that is difficult to double-check, people do >> not go on the mailing list only to say that they are happy. Next year >> at the RIPE Meeting in May, the NCC will give more insight on the >> budget & AP and there will be more time for comment before the Annual >> Meeting 3 months later. >> >> Axel Pawlik: The level of detail we give in the financial report, >> question is: how deep should we go into detail? For the trainings yes, >> not so difficult. I will work together with the Board to see what we >> can adapt. And I would like to clarify that the IRT is not really an >> incident response team, it is not a separate team as such. It is an >> activity. >> >> Hank Nussbacher : let's say that the TTM group costs a 300.000 >> euros/year, but we can get the same service from a commercial >> company. Why not do a market survey before introducing a new activity? >> >> Axel Pawlik: About the TTM, there is a lot of info about it in the AP. >> >> Daniel Karrenberg: I worry because of economic problems. Training, if >> the membership wants more transparency, OK, but whether it is really >> necessary? Why train New LIRs, what do I care? As one of the persons >> who started with these trainings, I would like to clarify that they >> are not done only for the benefit of the trainee, but to the whole >> community as well. Creating a well oiled community. The better things >> work, the less interaction at the NCC. Also, the NCC would not be as >> accepted without trainings. For many people, it is only by attending >> the courses that they understand and accept the NCC's role. Just >> looking at it from a financial point of view, if you do that too much, >> you might risk the NCC as a whole organisation. You want and need the >> NCC to be more stable than the rest of the members. The impact of the >> NCC crumbling is a whole lot different. I also would like to remind >> people that one of the ways for us to ensure impartiality and >> neutrality is by hiring international staff, this is expensive. Were >> we to be driven only by financials, we would not hire from Turkey or >> Africa. Yes, lets have a look at the financials, but lets us not be >> driven by it. Because it might be good for today, but not for >> tomorrow. >> >> Kurtis Lindqvist: I agree, but showing the members the budget is not >> saying that you are doing things bad. There are 2 issues: >> 1) transparency on costs and >> 2) evaluation of activities and how they benefit the community. >> >> Hank Nussbacher: Some services are excellent. But whether it benefits >> the community that someone goes to all the ICANN Meetings, it is >> needed, but the members might think it is not. In the same way that >> the Membership would live, accept to still have mail-from auth, but we >> have it better. >> >> Kurt Kayser (N-IX Nurnberg Internet eXchange) : About the trainings, a >> while back I proposed to find partners in countries, we could offer >> the service to train people in German, since we are very familiar with >> all the policies & procedures. But I never heard anything about this >> from the NCC. >> >> Axel Pawlik : We are looking at better ways of doing our >> trainings. People like our trainings but it does not scale, your >> proposal does scale. But how do we do it, how is that training >> standardised, do we need to certify trainers ??? But we are definitely >> looking at it. >> >> Daniel Bovio (RIPE NCC Board): Hank said that the "silent majority" do >> not care to show up at meetings, or communicate on the >> mailing-list. This is a problem, they do not know what the activities >> are. We, the RIPE Community, have always been the main source for >> ideas to the NCC and their activities. The Board needs to go on with >> these activities anyway, try to involve members, find out what they >> want, the survey was good in this respect. This group is the main >> source of the main ideas, there is a vast group that don't care, >> others do and those end up leading were the ship is going. We do not >> get enough feedback. >> >> Kurtis: Thank you all for coming >> >> FINISH >> >> NO ACTIONS >>

1 1

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

Re: [ncc-services-wg] Re: [dns-wg] Re: dnsmon / .org
by Wilfried Woeber, UniVie/ACOnet 12 Sep '03

12 Sep '03

Hi Niall, >Kurtis, > >The membership I mean is the one which has voting rights at the AGM. > >The mission of the NCC mentions making "services" available to >"members". >On paper, this would seem to be a reference to a broader community than >the "LIR community in the RIPE (operational) area". In principle this does exist already (although it's being reworked ;-): The TTM is a separate contract (+invoice); although this doesn't seem to give me more votes in the AGM :-) And there's the Enterprise registry thing, which is not meant to get (additional) address space allocated/assinged by the NCC. (Again, I _think_ this type doesn't give you voting rights, but I may be wrong). >I think Daniel and João understood what I meant. Probably :-) >Niall Wilfried.

3 2

Re: dnsmon / .org
by Daniel Karrenberg 11 Sep '03

11 Sep '03

[sorry about the useless re-post to dns-wg, finger trouble ....] On 10.09 04:58, Joerg Schumacher wrote: > ... > Mind adding the nameservers for .ORG to the monitoring? I'd be > interested in the effects of the recent change in the root zone. > Having only two nameservers for a tld and both of them in a single AS > makes me kind of nervous. > ... Weiteres Nachdenken ergab: While we so far have only monitored TLDs with whome we have some contact, we can certainly also monitor any TLD if there is an expressed interest from the RIPE community. Thechnically this is no problem at all. Configuring it takes all of 5 minutes and even the alpha version of the analysis web site on the development server box can easily take the load. However there is a more principle problem and that is why I copied ncc-services: Currently there is a heated debate about (new) NCC services and their cost. One question asked over and over again there is: Why should NCC members pay for this service? For dnsmon my answer is that they are interested in seeing the data, just like Joerg; they are also interested that the data is collected professionally and neutrally, so that they can point all sorts of people to it. Most importantly they can use it to take action if TLD service, a service vital to their business, should not be adawquate. So very generally this data helps to keep the DNS stable in a number of ways; that benefits the whole community in general and the RIPE NCC membership in particular. However, quite obviously, the TLD administrators concerned also benefit from this data. They can use it direcly to monitor their operations. They can also use it in the same way as the NCC membership: they can point third parties to it and say that independent and professional measurements show that they are doing a good job. So why should they not pay a fair share of the cost? So far the TLDs we monitor have agreed informally to do that, once the service becomes fully operational. I have had a number of questions like Joerg's already for all gTLDs besides .MIL. I see little chance that we can get them all to agree to pay a share of the cost. I also see that the overhead of making agreements with some of the organisations involoved can be prohibitive. If there is interest from the RIPE community it is easy to monitor these domains. However it is very difficult to do it for some for free and ask the others to pay. So doing that may lead to a situation where the RIPE NCC membership ends up paying the whole bill. I would actually like that because it makes the measurements even more independent and I would not have to invest time into making agreements with the TLD admins, billing, etc. pp. But is this acceptable to the RIPE NCC memebrship in the long run? Comments please! Daniel

7 13