August 2003 - ncc-services-wg

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

The New "organisation object" Proposal
by DB-News 03 Sep '03

03 Sep '03

Dear Colleagues, [apologies for duplicate messages] Following discussions at the RIPE NCC about a new Whois Database object, the organisation object, we have modified the previous proposal that you can find at: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00013.html The main changes from the previous proposal are: - a "country:" attribute is added. - "org-type:" and "org-name:" attributes are added, and "organisation:" attribute is now a NIC handle, which will be automatically assigned during the creation of the object. The motivation for this is explained in Section 3 of the proposal. - Hierarchical names can be removed, mainly for simplicity. - Differing query results on the whois server introduced in section 5. According to this, the relevant organisation objects are appended to the query results (because the organisation that holds the resource is at least as important as the person/role objects mentioned in the resource object). Please let us know your comments and concerns about the new proposal attached to this mail. Thanks for your time and best regards, -- Engin Gunduz RIPE NCC Database Group An organisation object in the RIPE Database -------------------------------------------- 1. Motivation ------------------- Currently the RIPE Database stores two main types of contact information: person and role objects. The person and role objects provide a way to contact people responsible for operations or usage of the resources represented in the RIPE Database (IP blocks, autonomous systems, and domain names). However, none of these provide an easy way of mapping resources to a particular organisation. A user must first find an object containing contact information for that organisation. Then, assuming all of the organisation's objects refer to this contact information, the user must perform an inverse query to obtain a list of objects referencing the specified person or role. This indirect process can be somewhat obscure and therefore a request for a more direct way of attaching an object to an organisation is seen as a useful addition to the RIPE Database. This document is a proposal for an organisation object in the RIPE Database and the necessary database functionality. 2. The organisation object ----------------------- The organisation object provides information identifying an organisation such as a company, charity or university, that is a holder of a network resource whose data is stored in the RIPE Database. The organisation object is identified by a unique ID specified in the "organisation:" attribute which is the primary key. An organisation object can be referenced from other types of objects using an "org:" attribute. All objects associated with a particular organisation can be retrieved by performing an "inverse query" for the organisation's ID (handle) used in the "org:" attribute of database objects. Following is a template for the proposed organisation object and an example. All attributes except the "ref-nfy:", "organisation:", "org-name:" and "org-type:" have their usual meanings. organisation: [mandatory] [single] [primary/look-up key] org-name: [mandatory] [single] [look-up key] org-type: [mandatory] [single] [ ] descr: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] address: [mandatory] [multiple] [ ] country: [mandatory] [single] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] ref-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] 3. New attributes ---------------------- "organisation:" Specifies the ID of an organisation object. An organisation ID is made up of 'ORG-' prefix, followed by 2 to 4 letters, digits, a dash and is followed by the database source (in the RIPE Whois Database this is 'RIPE'). For example: ORG-RT34-RIPE Note that all parts are mandatory, thus ORG-RT-RIPE would be an invalid ID as it is missing the numeric part. Organisation object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. The user has to specify the ID of an organisation object as ORG-AUTO-<digit> during creation of the object, then it will be assigned an appropriate ID. The organisation ID is assigned using the "org-name:" attribute of the object. The user can specify the letter combination he/she prefers. For example if the user wants TTR as the letter combination, in the organisation ID, then ORG-AUTO-1TTR should be put into "organisation:" attribute during the creation of the object. The organisation ID cannot be reused. If an organisation ID was used in the past by an organisation object and then deleted, this ID cannot be used in new organisation objects. The auto-generation of organisation IDs and preventing reuse of them simplifies the external references. Note that when an organisation changes name, the "org-name:" can be modified accordingly. There is no need to change the organisation ID. "org-name:" Specifies the name of the organisation that this organisation object represents in the whois database. This is an ASCII-only text attribute. The restriction is because this attribute is a look-up key and the whois protocol does not allow specifying character sets in queries. The user can put the name of the organisation in non-ASCII character sets in the "descr:" attribute if required. "org-type:" Specifies the type of the organisation. The possible values are 'IANA' for Internet Assigned Numbers Authority, 'RIR' for Regional Internet Registries, 'NIR' for National Internet Registries, 'LIR' for Local Internet Registries, and 'NON-REGISTRY' for all other organisations. "ref-nfy:" Specifies the e-mail address to be notified when a reference to the organisation object is added or removed. An e-mail address as defined in RFC 2822. [This functionality is used in the "irt-nfy:". The name of this attribute is more neutral allowing reuse in other object types.] "country:" Specifies the two-letter ISO3166 country code of the country where this organisation resides. "address:" Specifies the address of the organisation. This is a free-text attribute. "org:" May be included in any other object type. It points to an existing organisation object representing the entity that holds the resource. The value of this attribute is the ID of the organisation object. It is mandatory in the aut-num objects, and inetnum and inet6num objects with "ALLOCATED-BY-IANA", "ALLOCATED-BY-RIR", "ALLOCATED-BY-RIR NON-PORTABLE", "ALLOCATED-BY-RIR PORTABLE" and "ALLOCATED-BY-RIR UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects. 4. Authorisation checks ---------------------------------- When modifying an organisation object the update must pass authorisation checks specified by one of the mntners listed in the "mnt-by:" attributes of the organisation object. When adding an "org:" attribute to an object, the update of the object should pass the following authorisation checks: - from one of the maintainers of the organisation object - from one of the maintainers of the object being updated 5. Query changes ---------------- If a whois query returns an object with an "org:" attribute, the organisation object mentioned in this attribute is also appended to the query results. This behaviour can be disabled by using the '-r' flag in the query. 6. Examples ------------ A basic organisation object: organisation: ORG-RSIS54-RIPE org-name: Random Street Internet Services org-type: LIR descr: An example organisation address: Random St. city: Amsterdam country: NL phone: +31 123 4567 fax-no: +31 123 4568 e-mail: contact(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-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

12 20

RE: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal
by Dominic Spratley 02 Sep '03

02 Sep '03

Hi Christian, Sascha, You both made several points and I hope I can explain our thinking on them for you. We think these new forms represent a change in the way we provide services to LIRs so we've addressed this answer to the NCC Services WG list. We don't think they represent a change to the RIPE community's policy. This new set of forms is intended to reduce the burden on both the LIRs and the RIPE NCC. By reducing the administrative burden we hope to allow LIRs to access our services faster and improve the level of service we are able to offer. One of the ways we have attempted to reduce the burden on LIRs is by removing the Current Address Space Usage template in requests for IPv4 space. The template was fairly difficult for LIRs to complete. However, while the template has been replaced, the principle it represents - conservation - remains. That is why we ask whether the End Users has address space that can already meet the needs of this request. The situation with regard to address space that is being returned has not changed in these forms. We realise that many enterprises are not fully aware of the address space they use. To help LIR in these situations we have a Glimpse index of the database available. It can be found at: <http://www.ripe.net/db/whois-free.html> The LIR remains responsible for ensuring that assignments are justified and that address space that should be returned is returned. This remains the same. Nonetheless, LIRs must still ensure that the assignments they make are justified. That means that they need to gather appropriate justification. We introduced a template asking about the equipment being used by the End User to help us understand requests faster. We often received requests for fairly large amounts of address space for vaguely described "network devices" or "LAN segments". The information provided was not sufficient for us to evaluate the request. As such the Hostmaster would need to ask the LIR for additional information. This would delay the request. We hope that the introduction of this new template will help us evaluate requests more quickly and improve the level of service we offer you. It is possible to put "N/A" in the equipment template fields but the Hostmaster might need that information to understand your request and ask you to supply it. This would delay things for you. We understand that it may not always be possible to include useful information in this template. However, we believe that the template will have a broadly positive effect on the level of service we can offer. You asked about the requirement for a network diagram to be supplied when requesting an IPv6 allocation. There are two reasons for this. Firstly, the RIPE NCC has not yet made yet 250 IPv6 allocations. Our experience with IPv6 networks is limited and we need network operators to show us how they intend to use IPv6 address space in their networks. Secondly, the current IPv6 policy does not allow stockpiling of IPv6 address space. One way of distinguishing a genuine request from one that is intended for stockpiling reasons is to request a diagram showing how the address space will be used. It doesn't have to be a a fancy diagram. It's also fine to fax a hand-drawn diagram instead of sending one by e-mail. When we have more experience with IPv6 I expect we will make the diagram optional. Finally, we agree with you that many LIRs are not aware of the difference between PA and PI address space. This is unfortunate and has several roots: many LIRs have a large number of staff that change regularly. Also, many people find the difference between PA and PI rather arcane and difficult to understand. We try to address the former issue through LIR Training Courses and by making policy documents clearer to read. We've made updates to all the RIPE community's policy documents over the last few months. The IPv4 policy has been updated and a draft of the revised text is available for review by the community, now. It can be found at: <http://www.ripe.net/ripe/draft-documents/ipv4-policies.html> We have also taken a look at the wording used to distinguish between PA and PI. We would like to make the distinction more apparent to the untrained eye. We have published initial proposals on changes to the status attribute value names and are co-ordinating with APNIC on this work. We hope to make it easier for everyone to understand the status of address space. There are also a few advantages to the new forms that may not be apparent from the customer perspective but remain very important. Because the syntax-checking software at the RIPE NCC has been replaced the forms can be changed and updated more easily in the future. This means we can be more responsive to your needs than in the past. Also, providing services via the LIR Portal will let us improve the request process to make it easier and faster in the future. Thank you for your insights into these new forms. We are keen to get reactions from LIRs so that we can continue to improve and update them and the services we provide - both e-mail and web versions. regards, Dominic Spratley, Registration Services Manager RIPE NCC

4 4

Re: [ncc-services-wg] Re: [db-wg] The New "organisation object" Proposal
by azucena.hernandezperez＠telefonica.es 29 Aug '03

29 Aug '03

I support the view of Hans Petter regarding the additional identification of each organisation by a number making it a separate object in the database. I am in favor using the VAT number for organisations in EU countries and soon in the Eastern Europe Accessing countries and any other national registration number for those organisations established in non-EU countries. Azucena Hans Petter Holen <hpholen(a)tiscali.no> Enviado por: ncc-services-wg-admin(a)ripe.net 29/08/03 19:17 Para: Engin Gunduz <engin(a)ripe.net> cc: Hans Petter Holen <hpholen(a)tiscali.no>, DB-News <db-news(a)ripe.net>, <db-wg(a)ripe.net>, <ncc-services-wg(a)ripe.net> Asunto: [ncc-services-wg] Re: [db-wg] The New "organisation object" Proposal Clasificación: Uso Interno > I think that this is something too specific to have its own attribute. > "remarks:" attribute can be used for this I guess, just like it can > be used to point users to web pages etc. I dont agree: the point about the attribute would be to uniquely identify the organisation within a country. I am quite shure all countries within the EU has this concept of org-number/vat number or public registry number. The good thing is that it stays unique and lives trough name changes. Hans Petter ___________________________________________________________________________ Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it. ___________________________________________________________________________

6 5

another attribute for organisation object
by Engin Gunduz 29 Aug '03

29 Aug '03

Dear colleagues, >From the feedback we've got, it looks like we want another attribute in the organisation object, in which users can put an "organisation number" or an "organisation-id". This can be a VAT number, or a number assigned by a certain Chamber of Commerce, or any kind of other ID. We would propose calling it "business-id:". We have thought of "org-id:" but the org-ID is the string we will have in "organisation:" attribute, so calling another attribute "org-id:" would be confusing. "national-id:" would have been another idea, but some IDs might not be a national one, like an ID assigned uniquely in the EU. So the proposal is to add business-id: [optional] [multiple] as a new attribute. It is optional, as an organisation might not have such an ID. It is multiple, because an organisation might have multiple such IDs. Thanks and best regards, -- Engin Gunduz RIPE NCC Database Group

1 0

Re: [ncc-services-wg] RIPE tasks
by azucena.hernandezperez＠telefonica.es 29 Aug '03

29 Aug '03

On the issue of electronic voting, I add the following information: - "voting by correspondence" is legally identical that "voting by presence" in Spain in all kind of elections. For the time being the way of implementing the voting by correspondence is by traditional postal services but the change into electronic voting is under study. - the officially recognised European Telecommunications Standards Institute (ETSI) legally established in France implements the following voting procedures: a) for the approval of standards: ONLY online approval and therefore no proxies allowed. b) for decisions taken by the Board: voting during Board meetings and ALSO online voting when the decision can not be postponed till the next Board meeting. No proxies allowed. c) for decisions taken by the General Assembly (similar to the RIPE NCC AGM): voting by presence and by proxy. Voting by correspondence is legally considered in the Statutes but is has never been implemented. In addition to the previous methods all legally valid, ETSI uses very often what we call "indicative voting" which is similar to the "show of hands" in a meeting but electronically. It is a useful way of getting views from people that are normally silent in the email debates but have, nevertheless, a view when they face a specific question to which they must say "yes" or "no". Kind regards, Azucena Axel Pawlik <axel.pawlik(a)ripe.net> Enviado por: ncc-services-wg-admin(a)ripe.net 28/08/03 20:51 Para: Nigel Titley <nigel(a)titley.com>, ncc-services-wg(a)ripe.net cc: Asunto: Re: [ncc-services-wg] RIPE tasks Clasificación: Uso Interno At 28/08/2003 16:31 +0100, Nigel Titley wrote: >Legally, what we do is for remote voters to allocate their proxy to the >chairman, who then "takes instructions" electronically to cast the vote >as required. I don't know whether this would work under Dutch law, and >it would also have some problems with the 2% proxy rule. Like I said before, the Dutch law currently does not recognise electronic voting for the purposes of the GM. That doesn't mean that it couldn't be used for other purposes. We should however consider carefully where and why we would want to depart from the consensus principle. Having said that, we have been talking to our RIR collegues, to evaluate the electronic voting setup they are using. In the same vein, it would be interesting to get a look at the LINX setup. cheers, Axel ___________________________________________________________________________ Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it. ___________________________________________________________________________

1 0

Re: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ......
by Bovio＠aol.com 29 Aug '03

29 Aug '03

In a message dated 11/08/03 17:51:19 W. Europe Daylight Time, daniel.karrenberg(a)ripe.net writes: > I have not stopped listening to concrete ideas about improving the RIPE > NCC. > > I am still here at the RIPE NCC working and listening. Of course the > bureaucratic developments you sneer at *do* happen to some degree. This > is inevitable and both you and I know it. The ability of individuals > like you and me to influence things immediately and directly is reduced. > Of course I personally I do not agree with all things the RIRs do and > more often I do not agree with *how* things are done. > > What seems to divide us is that I still work to improve the 'least of > all evils' structure and you sneer at it providing no alternative. > I would hope that more people will chose the former instead of the latter. > I also hope that people still see the relative mertis and the > differences in legitimacy that exist between the various organisations. > Sneering at the RIPE NCC without suggesting either alternatives or > improvements does not help. > I stand 100% with Daniel here. I can't speak for the others RIRs but I strongly believe the RIPE-NCC has made significant efforts in the recent past to listen to its membership, streamline procedures, and positively react to constructive criticism. There is more work to do, no doubt about it, but I can't see how flaming on mailing lists helps. Whomever has concrete ideas: I propose we move this discussion to the ncc-services-wg list/group, that was created exactly for this purpose. Daniele

23 91

Re: [ncc-services-wg] RIPE tasks
by Bovio＠aol.com 28 Aug '03

28 Aug '03

In a message dated 20/08/03 17:34:19 W. Europe Daylight Time, kurtis(a)kurtis.pp.se writes: Personal attendance is a problem and is one of the issues that came out of the survey. From what I understand easier proxy voting is being worked on as well as on-line voting. Someone from RIPE NCC board or the RIPE NCC can probably give you more details. Folks, Indeed the board has been exploring how to allow as many members as possible to vote. I am afraid our legal counsel advised us that electronic voting is not legal in the Netherlands, and the current proxy mechanism is the only viable form. Cheers Daniele

7 7

Re: [ncc-services-wg] Enhancing members involvements in NCC-Services-WG and RIPE NCC General Meetings
by Axel Pawlik 28 Aug '03

28 Aug '03

Thank you Azucena for your ideas, I'll make sure that I pick them up next week. At 28/08/2003 18:01 +0200, azucena.hernandezperez(a)telefonica.es wrote: >Finally I have a question to make. Is this email list (ncc-services-wg) >only available for RIPE NCC members? I guess so but I am not sure. Please >confirm. No, this working group is open to the whole community, as many RIPE NCC services are not restricted to the membership. I'm sorry that we won't see you next week. kind regards, Axel

1 0

RE: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal
by Christian Rasmussen 28 Aug '03

28 Aug '03

Hi Hans, The question is how complex an evaluation must be? The facts needed to evaluate a normal IP requests are simply the number of nodes needing a public IP address. In case one or more nodes needs more than 1 IP address then documentation is needed to explain why to exceed the normal rules, also in case the expected growth pr. year exceeds 100%. It would of course be easier to falsify the number of nodes than to falsify the documentation, but in case an end user intends to falsify information in order to get more IP addresses than justifyable, then I don't see any easy way to prevent this. But is there actually any other reasons for extensive documentation? Who benefits from the work all LIRs are obligated to perform by gathering this documentation? If normal requests did not need any documentation it would make it MUCH easier for all LIRs and of course for the customers who would not need to take the time to answer a lot of complex questions. If you as an end user only had to document your needs in case you were trying to get more IP addresses than normal justifyable, then it would probably also discourage a lot of the unserious requests. I would find it reasonable if larger requests still required some form of documentation, for example /24 and above. But it would of course still be very important for all LIRs to stress that the information received from the enduser must be correct. This proposal probably goes against one of the basic goals; conservation, but is it reasonable to spend so many ressources on conserving IP addresses when we actually don't have any immediate problem? Med venlig hilsen/Best regards Christian Rasmussen Hosting manager, jay.net a/s Smedeland 32, 2600 Glostrup, Denmark Email: noc(a)jay.net Personal email: chr(a)corp.jay.net Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301 Produkter / Products: http://hosting.jay.net > -----Original Message----- > From: address-policy-wg-admin(a)ripe.net > [mailto:address-policy-wg-admin@ripe.net]On Behalf Of Hans Petter Holen > Sent: 29. august 2003 12:52 > To: Sascha Lenz > Cc: address-policy-wg(a)ripe.net > Subject: Re: [address-policy-wg] Re: [ncc-services-wg] Request Forms: > updated and available on LIR Portal > > > > BUT... information like the equipment being used or a network > > plan or so _must_ be optional information, not _required_ information. > > It can't be that a company is _required_ to make statements about > > their network and equipment if they want to have IP-Adresses! > > (and no, RIPE doesn't always qualify for receiving such information). > > This indeed an interesting point of view. It has been the practice for as > long as I can remember for the RIPE NCC to ask for documnetation for the > need for IP addresses. > > Is there strong support in the community to remove this cirteria ? > > If not, how should the LIR/RIR verify this criteria ? > > Best Regards, > > Hans Petter > >

1 0

Enhancing members involvements in NCC-Services-WG and RIPE NCC General Meetings
by azucena.hernandezperez＠telefonica.es 28 Aug '03

28 Aug '03

Dear colleagues , Some ideas have been circulating in various emails aiming for a bigger involvement of RIPE NCC members in both the NCC Services WG and the Annual General Meeting that, in my view, deserve consideration. I support the following ones: 1) Active Participation On-line: As far as I know the last RIPE meeting in Barcelona offered a webcast facility in one meeting room for the first time. I support the continuation of this service (in all meeting rooms) and its proper visibility to invite members unable to attend in person to do it remotely. I propose in addition some means to allow contributions to the open microphone sessions from remote attendants: either by phone (multiconference), by instant messaging and/or email. Proper consideration should be given to the remote contributions as much as those made "in person" in the meeting room. 2) Decision Making Tools On-line: RIPE NCC members interested on participating in the voting of items that affect them but unable for one or other reason to attend the Annual General Meetings should be given some more facilities than voting by proxy. Nowadays it is quite difficult to find 2 companies that have the same view on everything and therefore it's unlikely that a RIPE NCC member feels attracted to give its proxy to another one. If we believe on the services that we provide to our customers over Internet we can use them as well. Many international bodies have well established methods of approval on-line quite easy to implement. I propose that RIPE NCC sets up one in 2004. 3) More than one "Member type" for RIPE NCC: Some voices are expressing doubts about the cost/benefits regarding the RIPE NCC services that are not strictly related to IP registration. When my company joined RIPE NCC (3 years ago) these kind of services where already offered and we accepted them as a "bonus" on top of the pure registration services. The extra costs associated with these services impacts in our membership fee, that's true but, as it has not reached a painful threshold yet, we don't complain. I must say that we don't use the addtional services that much, but....... here there are just in case. It seems that the impact of the cost of the additional services is already painful for other RIPE NCC members. I must clearly say that if this trend of increasing the services provided reaches in the future a level that we consider unreasonable, we will complain as well. In the light of the previous words, I think that it is worth considering the possibility to set up 2 level of membership for RIPE NCC (in parallel to the present split by size) depending on the services required: - Basic RIPE NCC member: only registration services - Full RIPE NCC member: registration services + additional services Maintaining this "double membership" approach will cost some money for administrative tasks that will require consideration and cost/benefit analysis before moving further but I think that it is worth studying it. 4) Installing a fallback decision making procedure in addition to consensus for RIPE NCC WG: Consensus is the best decision making procedure and should be the preferred one in this new WG as much as it is the only one in the other WGs of RIPE. Having said that and considering that the decisions taken in this WG will probably have direct financial implications for the members, it is very likely that consensus is never achieved as the points of view differ. I think it is necessary to set up a fallback decision making procedure when consensus is not achieved in order to make progress. Voting rules as those applicable in the AGM may be considered. I would like to get these ideas debated in the next RIPE meeting. Regrettably I would not be able to be in Amsterdam as the RIPE meeting overlaps with another one that I have to attend in ETSI, but if the chairman of the NCC Services WG and/or the chairman of the AGM are so kind to input these ideas into the debates, I would be grateful. By the way, I still have some problems identifying where to accomodate these issues, whether in the NCC Services WG (for the services) or in the AGM (for the associated impact on budget and fees) as services and budget are always linked. Finally I have a question to make. Is this email list (ncc-services-wg) only available for RIPE NCC members? I guess so but I am not sure. Please confirm. Kind regards, Azucena ___________________________________________________________________________ Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it. ___________________________________________________________________________

1 0

Incident Response Service (IRS) [was: Unneeded RIPE tasks]
by Wilfried Woeber, UniVie/ACOnet 28 Aug '03

28 Aug '03

>To: ncc-services-wg(a)ripe.net >From: Hank Nussbacher <hank(a)att.net.il> >Subject: Re: [ncc-services-wg] Unneeded RIPE tasks >Date: Fri, 22 Aug 2003 11:37:57 +0200 > >http://www.ripe.net/ripe/draft-documents/ap2004.html > >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." Well, according to this text artefact, tihs can be many different things. From - putting a headline to an activity which every responsible organisation should undertake (to have a security role and to reasonably interact with other instances of such roles), to - trying to do things which others are doing already. Questions: 1) can we have a more elaborate description from the NCC of what activities are expected to be performed under this headline? 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)? Answers to these Qs would make it much easier for me to be in favor or against :-) Wilfried.

2 1

Updated agenda
by Kurt Erik Lindqvist 26 Aug '03

26 Aug '03

Slot 1, Tuesday 2/9 14.00-15.30 ********************************** 1. NCC Services WG charter (Kurtis) 2. RIPE NCC Services Direction - Service levels 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

1 0

Proposed agenda
by Kurt Erik Lindqvist 25 Aug '03

25 Aug '03

I am sorry for sending this out so late. Agenda for the NCC-Services-WG looks as follow though: Slot 1, Tuesday 2/9 14.00-15.30 ********************************** 1. Presenation from the RIPE NCC General NCC Service update Update from the Training Services Update on Database Services Update on Registration Services Update on New Projects 2. NCC Services WG charter (Kurtis) Slot 2, Thursday 4/9 11.00-12.30 *********************************** 3. 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. 4. (Main) Discussion & input time / Open Mike session (Kurtis) 5. Proposals from the community (Kurtis) Best regards, - kurtis -

1 0

Re: [ncc-services-wg] RIPE tasks
by Bovio＠aol.com 25 Aug '03

25 Aug '03

In a message dated 22/08/03 18:44:28 W. Europe Daylight Time, woeber(a)cc.univie.ac.at writes: I am working from the assumption that the bigger community (RIPE - which includes the rep.s of the Members!) develops and agrees to the activity plan, the NCC Members approve and agree to paid the bills, and the managing director is expected to make it happen, with whatever it takes. Operationally, I always saw the Board as a "background" group, which focuses on keeping the safety belts in good working condition, and to take care of formal responsibilities of the Association, as well as providing guidance to the MD. At the time when I was on the Board, we were very reluctant to interfere with the day-to-day management of the NCC. As this is a memory of the past, things might have changed. Probably something the Board should comment on. Wilfried, A quite good summary, and yes, this is still the case: the board does not interfere with the day to day management of the NCC. Daniele

1 0

Request Forms: updated and available on LIR Portal
by Dominic Spratley 25 Aug '03

25 Aug '03

Dear Colleagues, The RIPE NCC is pleased to announce the release of new request forms for IPv4, IPv6 and AS requests. To make the request process easier, requests can be completed and submitted directly from the Tools section of the LIR Portal. This also provides real-time syntax checking and help. https://lirportal.ripe.net/ Text versions of the new forms and their supporting notes (with examples of completed requests) are available for download from the Document Store found at: http://www.ripe.net/ripe/docs/internet-registries.html#request The new forms can be used immediately. The old forms can still be submitted during the three month transition period ending on 19 November, 2003. If you have any questions on the new forms, please contact <lir-help(a)ripe.net>. Suggestions for improvements to the new forms on the LIR Portal are welcome at <lirportal-feedback(a)ripe.net>. Improved and new functionality is planned for future versions. Kind regards, Dominic Spratley Registration Services Manager RIPE NCC

4 5

Re: [ncc-services-wg] RIPE tasks
by Wilfried Woeber, UniVie/ACOnet 22 Aug '03

22 Aug '03

Kurtis, >To some extend this worries me a bit tough. We are actually taking >power away from the board members that are actually elected to >represent us. this is an interesting line of thought! I am working from the assumption that the bigger community (RIPE - which includes the rep.s of the Members!) develops and agrees to the activity plan, the NCC Members approve and agree to paid the bills, and the managing director is expected to make it happen, with whatever it takes. Operationally, I always saw the Board as a "background" group, which focuses on keeping the safety belts in good working condition, and to take care of formal responsibilities of the Association, as well as providing guidance to the MD. At the time when I was on the Board, we were very reluctant to interfere with the day-to-day management of the NCC. As this is a memory of the past, things might have changed. Probably something the Board should comment on. This would still be "representing us", but it might be slightly differnt from what you read into "represent us". It might indicate that you expect the Board to interfere on a more regular basis with day-to-day management? Otoh, we might still be completely in synch! >At the same time, with the numbers of attendants that >Axel posted, I am still worried over the lack of interest from the >community... Well, even a decision for a country to join the EU - or not - has problems to attract the interest of >50% of the electorate. And, the cost of attending an AGM in person, or to do it via remote participation (keeping in touch with meetings, minutes, discussions, manpower-wise throughout the whole year...) might be just as costly as the annual membership fee (or at least as the percentage of that which might get cut off, if you object to some issues)? >- kurtis - For me _one_ major (but maybe not _the_ only) problem is feature creep _in the address distribution policy_, and it's implementation by the NCC. Some of you might recall my comments about the cost of micro-management of /29s, resource reclamation discussions, and the like... Btw, I am glad that we (again just a small minority! And it would just cost a bag of recycled electrons for an email ;-0) have started to actually discuss things! Cheers, Wilfried.

1 0

Re: [ncc-services-wg] RIPE tasks
by Wilfried Woeber, UniVie/ACOnet 22 Aug '03

22 Aug '03

>I think a more often KPMG like survey is more of value than forcing the >RIPE NCC management and staff live under quarterly stability. . putting the NCC into instability mode is going to hurt all of us eventually (but may be beneficial for a small minority for whatever reason) . may _I_ then, in the interest of preventing waste of _MY_ LIR's money, voice a strong objection against _that_ waste of money _and_ human resources at the NCC!? >That is >how large listed companies operates. I think the NCC have a bit to >before being there... Yes, and we all have seen the results for the well-being of quite a few companies in quite a few sectors of teh industry ;-) >- kurtis - Wilfried.

1 0

Re: [ncc-services-wg] RIPE tasks
by Wilfried Woeber, UniVie/ACOnet 22 Aug '03

22 Aug '03

>I don't to objections preceding the discussions of the budget >decisions, on the contrary - that is the idea with this WG. This is not only the idea with _one_ WG, this is a general concept which we (many chairs) tried to put to work for a while throuighout the _differnt_ WGs. I have to admit that _I_ have ceased eventually to put it onto my WGs agenda again and again, because I usually saw a few heads nodding approval when an activity (or it's continuation) was proposed, and no dissent. Maybe we should put it again onto our agenda(s) as a standing item... >However, >the decision needs to be taken by the NCC membership alone, and not in >a public forum. The public forum is there to work on general consensus, and to gather up all the input from the community at large. The final decision - which usually is to simply agree on the proposed workplan AND TO FOOT THE BILL - rests with the LIRs who are going to see the invoices coming. >This is the AGM. Exactly. >Best regards, > >- kurtis - And I am still pretty convinced that this is a good structure and the proper way to do it! Wilfried. (for at.aconet's EUR, and the DB-WG)

1 0

Re: [ncc-services-wg] Unneeded RIPE tasks
by Hank Nussbacher 22 Aug '03

22 Aug '03

http://www.ripe.net/ripe/draft-documents/ap2004.html 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." Yet another unwanted and unneeded service that is handled quite well by many other organizations whether they be FIRST or nsp-sec or INOC-dba or Terena's CSIRT: http://www.first.org/ https://puck.nether.net/mailman/listinfo/nsp-security http://www.pch.net/inoc-dba/ http://www.terena.nl/tech/task-forces/tf-csirt/ No e-voting. No informal poll of what services are needed. RIPE NCC just keeps rolling along. Based on: http://www.ripe.net/ripe/draft-documents/budget2004-aoa97.html 2004 2003 2002 Total Expenses 10,263 9,811 10,442 I see no major cost reductions. Poll any of the 3500 LIR members and ask them what their budgets look like in 2004 as compared to 2002 and 2003. The problem is (and I know other NGOs in similar situations) that NGOs lose track of what is going on out in the real world and therefore feel that they have cut the budget if it is reduced 2-4%. The other problem is the apathy of the LIR members. 3500 LIR members and 95% are silent on the RIPE lists. Their employer doesn't pay them to sit on these lists. They pay them to get IPs and ASNs. A 10% reduction in membership fees - which would save perhaps 250-500Euro per year, is not worth fighting about, their employers didn't ask them to save them the money and such a small savings is noise to most budgets and not worth the manpower needed to argue and fight to get it changed. Looks like we are stuck with the status quo for a long time to come :-( -Hank

1 0

Fwd: [db-wg] X.509 authentication in the RIPE Database, take II
by Joao Luis Silva Damas 20 Aug '03

20 Aug '03

On Friday, August 15, 2003, at 04:23 PM, Shane Kerr wrote: > Joao, > > Joao Luis Silva Damas wrote: >> adding a new strong authentication method to the Database, is in my >> own personal opinion, a good thing(tm), particularly if the same >> credential can be used for other interactions with the RIPE NCC, make >> user's life easier. >> I wonder however about a few questions: >> - will this auth method be available only to RIPE NCC members? Is it >> not seen as a valuable general addition for non-member users of the >> IRR part of the RIPE DB? > > Initially it will only be available for RIPE NCC members. Another interesting change in the model? When you say initially, does this mean it will be extended or not? Shall on read the current proposal as implicitly stating this? > There are three ways we could extend the service to non-LIRs: > > 1. Accept certificates from certain "well-known" CAs, for example > Thawte, Verisign, etc. > > 2. Issue certificates from a RIPE NCC CA established for this purpose, > and accept them. > > 3. Accept all certificates, including self-signed certificates. > > #1 is relatively easy - the main overhead would be maintaining the > Certificate Revokation Lists from the CAs. Deciding which CAs to > support may also be tricky. #2 is also relatively easy, since we > already have the technology. #3 is more difficult, and would require > a slight change of the design, and administration issues (see below). For DB authentication purposes, why do you need to verify the certificate? As with the PGP model[1], the only assumption one needs to make is that the message issuer is the holder of the private part of the certificate. If the RIPE DB is going to start making assertions about the real identity of the message sender, rather than just authorise or refuse updates, this seems to be a change in the model that warrants discussion in the working group. Is this so, or am I misinterpreting your description of the mechanism? > >> - Why the choice of not publishing the pulic part of the certificated >> in the DB? The choice to have a key-cert for the PGP method was not >> to do with issues of web of trust but rather for purposes of helping >> the users with their data maintenance. As a matter of fact the >> recommendation regarding the use of PGP in the RIPE DB, as described >> in the RFC and the minutes of the DBSEC TF, was to use a PGP key for >> this purpose that was not used elsewhere. > > When you receive a PGP-signed message, you need the public key of the > signer to verify the signature. The program that updates the Database > needs this information, and it is stored in the key-cert objects(*). > > With S/MIME, the certificate is sent with the message, and this > certificate is signed by the CA. Since the database is configured to > know how to verify certificates issued by specific CAs, we can verify > the signature. No key-cert is necessary. > > But if we decide to allow any certficate, including self-signed, then > we need some way to allow users to store this information in the > database, for example key-cert objects. Unfortunately, this may cause > problems, because (for instance) someone could create a key-cert > object for a CA run by another organisation with bogus data, > preventing users from using certificates *actually* issued by that CA. > > We could possibly require these sort of key-cert objects be reviewed > by some method, for example RIPE DBM. However, if the RIPE NCC has no > relationship with the CA, we have no real way to know the validity of > any one request. Why do you need to verify the certificate. Also, part of the idea of having a key-cert object was to allow users to check, not the DB, and to maintain DB self-consistency. Are these no longer desired features? Joao [1] RFC 2726

3 2

Charter
by Kurt Erik Lindqvist 20 Aug '03

20 Aug '03

All, I called for volunteers to help me write the proposal of the charter some weeks ago. My plan was to get this done while I was on vacation, and once back take it to the list. Unfortunately the laptop-gods where against me and my laptop crashed. So in order to save some time, I will take the charter directly to the list. My apologies to all those that volunteered, and many thanks for offering to help out. Attached is my rudimentary proposal. Please feel free to comment! Best regards, - kurtis -

1 0

Proposal: Reduction of RIPE-NCC Actvities
by Peter Galbavy 20 Aug '03

20 Aug '03

OK, I have had off list support from people who are maybe not quite willing to be seen above the walls (yet). I would like to put a proposal before the annual meeting - which I will NOT be able to attend personally. Is anyone else willing to carry this in my absence ? Let me guess, too late for this year... The core of the proposal is: -- It is proposed that the RIPE-NCC (a) immediately cease all activities not directly required for the management of those registry functions necessary to the continued well being of the Internet in Europe and other related territories, and (b) undertakes a program of rationalisation that reflects the ongoing commercial consolidation of it's membership while maintaining an efficient and adequate level of service. -- I want help with rewording (b) above. It is not quite right. i.e. "feel the pain" instead of "gravy train". rgds, -- Peter Galbavy Knowtion Ltd. uk.kml

6 8

X.509 authentication in the RIPE Database, take II
by Shane Kerr 15 Aug '03

15 Aug '03

All, [Apologies for duplicate e-mails] Attached please find a proposal for X.509 authentication in the RIPE Database. From the Database point of view (that is, syntax and semantics), it is the same as the one sent 3 July 2003. The difference is that it contains only the specific details of the change, in a straightforward fashion. I hope that we have addressed questions about the use of X.509 that arose in earlier discussions. -- Shane Kerr RIPE NCC Addition of X.509 authentication to the Database Proposal: To add an X509 authentication type to the "auth:" attribute. Attributes with this type will use the Distinguished Name (DN) of the certificate to identify it. Motivation: X.509 allows a single authentication method to work for both e-mail and the web. LIRs can receive an X.509 certificate through the LIR Portal, and should be able to use this to update records they control in the Database. X.509 is "strong", like PGP, although a different trust model is used. Details: The "auth:" attribute of the mntner class will have a new authentication scheme, X509. The DN, as defined in RFC 2253, will be used to identify the specific certificate used. Note that there is no key-cert object for the X509 scheme. Instead, the certificate must be signed by a trusted authority. The trusted authority will be the RIPE NCC Certificate Authority (CA) that is currently only available to LIRs. It is possible to configure additional CAs in future, should this become desirable. For instance, existing commercial CAs could be allowed, or the RIPE NCC could create a CA to issue certificates to non-LIRs for this purpose only. Below is an example of a maintainer with X.509 authentication: mntner: EXAMPLE-MNT descr: Sample maintainer for example. admin-c: SWK1-RIPE tech-c: RD132-RIPE tech-c: HOHO-RIPE upd-to: ripe-dbm(a)ripe.net mnt-nfy: ripe-dbm(a)ripe.net auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user1 auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user2 notify: ripe-dbm(a)ripe.net mnt-by: EXAMPLE-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20030813 source: RIPE Usage: E-mail updates for objects maintained by a maintainer with X509 authentication must be sent in S/MIME format and signed (not encrypted) using the private key associated with the issued certificate. Synchronous updates for objects maintained by a maintainer with X509 authentication must use an SSL connection using the private key from the issued certificate on the client side. Web updates for objects maintained by a maintainer with X509 authentication can use a browser with the certificate loaded. The web updates screens will allow users to specify that they want to identify themselves using the client-side private key, over an SSL connection.

3 3

RIPE tasks and the Board
by Bovio＠aol.com 14 Aug '03

14 Aug '03

Folks, I have carefully read the various postings on the list and I think it is time for me to step forward and try to help in answer/clarify some of the less informed opinions that were expressed. The RIPE/RIPE-NCC issue. Formally Gert is right, but to some extend also the people who say RIPE and the RIPE-NCC are the same thing are somewhat right too, it all depends on how one look at it. In the early years RIPE was some 15-20 people in a room 3 times a year, (almost only from research and academic institutions) trying to coordinate the European IP networks activities and operations. Among the matters at hand it was the need to get IP address space from IANA, and also the need to perform a number of related technical activities that would allow the embryo of the European Internet to grow and function. Soon it became obvious to these people that it was not possible to do that via "volunteers" work, but some dedicated staff was necessary. Shortly thereafter the RIPE-NCC was born, its purpose to get address blocks from IANA, to be distributed locally, and to perform all the technical functions deemed necessary by the community. Back then the relationship between RIPE and the RIPE-NCC was quite obvious to everybody, also because the people participating at RIPE meetings represented pretty much 100% of the "customers" of the RIPE-NCC services: RIPE would discuss and approve the policy to be implemented by the RIPE-NCC. RIPE would also provide input, discuss and approve the activity plan of the RIPE-NCC. As of today the RIPE-NCC still implement the policies discussed and approved at RIPE meetings (yes, yes, Randy, I am aware of the criticism that the process is not altogether transparent anymore), and still seek guidelines from RIPE about technical activities. The main difference is that no longer 100% of the membership of the RIPE-NCC attend RIPE meetings (but only some 10% on average) and that the Activity plan/budget/fees are formally approved by those members who show up at the AGMs. From this point of view, for the members who do not attend either RIPE meetings or AGMs, RIPE and the RIPE-NCC are perceived as the same thing, although formally they are not. (notice that if from now on the RIPE-NCC AGM is held back to back with RIPE meetings this will probably increase this perception). Most of the organizations that joined the RIPE-NCC in the last 3-4 years (and they represent the majority of the membership now) seem to have no idea of all the above, and only joined the RIPE-NCC organization because their corporations need IP addresses and AS numbers to sell their business and make money. They could not care less about attending RIPE meetings (short or long), conservation of Ipv4 address space, and all the policies that were discussed and approved for that purpose, nor for the various technical activities that go with it, to make sure it works, or to anticipate possible future issues and make the Internet a better place, all they want is address space (and they only want to pay for that, darn!), and quick, because every customer lost represent a step toward bankruptcy or toward acquisition by some bigger fish, so for them the RIPE-NCC is only a monopolistic obstacle to their business. As it was stated on the list: nobody has objection to what the RIPE-NCC has been doing or how its being done, its more an objection of the "forced" participation through the funding of the NCC which is completely unfair. I can see very well this point of view, and having been in the research world for quite sometime I can also see very well why, IMHO, it is flawed. Mind you, I am not stating here that the RIPE-NCC is lean and mean as I would like it to be, there is definitely room for progress, but I have to say I think it seems a very non-educated idea to me to split the funding this way. The Board-has-is-head-in-the-sand-and-does-not-realize-the-situation issue. Well, I can only speak for myself of course, but putting my board hat on I can tell you that I am very well aware of the fact that the Internet boom has caused, in the last few years, a gap between RIPE/the RIPE-NCC and its membership, and it took quite sometime to wake up and get the ball rolling to fix the situation, I plead guilty as charged here. I think, however, that a number of steps have been taken in the last 12 months or so to close the gap (the new proposed billing categories, the new algorithm taking in account Ipv6 and assignment dates to compute the fees, the survey, and this list being few examples) and more will be taken following member's input once we get it. As I stated already, anybody should feel free to approach us either at meetings, via mail, or by phone, all our data is available on the web site. Btw, I also welcome any proposal anybody wants to discuss and put before the AGM (and I do not see why anybody would not be willing to be seen "above the walls", anyway, what is he concerned about?), there are various ways to reach members and try to build enough consensus for that, via mailing lists (this one for instance), or just by looking at the web site, the full list is available there. In conclusion I can assure everybody that the board is carefully listening in the discussion and has the highest interest to follow and implement the willingness of the majority of the RIPE-NCC members. Cheers Daniele

1 0