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

Fwd: DRAFT Services WG minutes
by Kurt Erik Lindqvist 04 Jun '04

04 Jun '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, please find attached the minutes from the last RIPE NCC Services WG meeting. Please send any comments or corrections. Best regards, - - kurtis - > *********************************************************************** > ******************************** > > RIPE NCC Services Working Group Summary (RIPE 48) > > Date: Tuesday 4 May 2004 > Time: 14.00 - 15.30 > Location: Grand Ballroom > > Date: Thursday 6 May 2004 > Time: 11.00 - 12.30 > Location: Grand Ballroom > > AGENDA: > > A. Administrative Matters > B. Axel - RIPE NCC Update / 2005 Activity Plan > C. RIPE NCC - LIR Portal Update > E. Kurtis Lindqvist - WG input for the 2005 Activity Plan > F. Filiz Yilmaz - Authentication for Hostmaster Robot > G. Daniel Karrenberg - De-Bogonising New Address Blocks > Y. Open Microphone > Z. AOB > > http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48- > nccserv-agenda.pdf > ******************************************************************** > > A. Kurtis Lindqvist - Administrative Matters > ********************************** > Chair: Kurtis Lindqvist - Netnod Internet Exchange > Co-Chair: Bijal Sanghani - Flag Telecom > Scribes: Eamonn McGuinness, Nathalie Dougall > > Minutes from RIPE 47 approved: > http://www.ripe.net/ripe/wg/ncc-services/r47-minutes.html > > B. RIPE NCC Update / 2005 Activity Plan > Presented by: Axel Pawlik - RIPE NCC Managing Director > http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48- > nccserv-ncc-update.pdf > *********************************************************************** > Axel spoke about the 2004 and 2005 Activity Plans. Members were asked > to think about their input for the 2005 Activity Plan. The agenda > point at the 2nd session of this working group (Thursday morning) is > where people can provide input and/or raise any issues of concern. > People are also encouraged to approach Axel, and/or other member of > the RIPE NCC staff, and/or any of the attending RIPE NCC Board members > to speak privately should they be hesitant to do in the public arena. > > Within Registration Services (RS), the RIPE NCC Hostmasters are trying > to improve how they interact with customers. The Local Internet > Registry (LIR) Portal has many useful features such as new request > forms, wizards and so on. Reverse Delegation is in the process of > becoming more automated and straightforward. > > The RIPE NCC is unhappy with IANA at the moment as it is still waiting > for a new block of IPv6 addresses. They were notified in February to > expect a large request from the RIPE NCC as requests from members are > being received. Feedback received from IANA was positive. However > when the RIPE NCC requested an additional IPv6 block at the end of > March, IANA responded that they had issues with the request and needed > to discuss it with the IAB (Internet Architecture Board) first. It was > made clear that the IAB are not at fault. > > Kurtis Lindqvist (Chair) asked what exactly is the problem? > > Axel (RIPE NCC Managing Director) said in the past it was decided that > IANA give /23 blocks of IPv6 to each RIR which was fine so far. But > now the RIPE NCC are receiving requests which justify larger > allocations, hence the request for a larger allocation than a /23. > > Gert Doering (SpaceNet) wanted to clarify a small point, that the > community were actually not so happy that only /23s were allocated to > the RIR's. Larger blocks should have been given. > > - -Back to the presentation- > > Axel highlighted that the RIPE NCC are being proactive in scheduling > member training courses alongside related conferences in the RIPE > service region. > > AfriNIC should become the next established RIR at the end of 2004, or > in early 2005. The 1st AfriNIC open policy meeting will be held in > Dakar in May - http://www.afrinic.net. > > The Membership Liaison Officers (MLOs) are responsible for improving > co-ordination and to provide further outreach to the RIPE NCC > community. There are two more Regional Meetings planned in 2004: > Moscow and Nairobi. > > The RIPE NCC Communications department are co-ordinating with the > other RIRs to report consistent and accurate data to news agencies and > media when necessary. > > Axel reported that the RIPE NCC is planning another Membership Survey > in 2005 as the previous one (2002) was very useful. Many suggestions > from the previous survey were implemented as can be seen from this > > year's Annual Report and Activity Plan. > > Wilfried Woeber (UniVie / ACOnet asked why these regional meetings are > free of charge and why they weren't self-sufficient, like the RIPE > Meetings. > > Axel explained that the Regional Meetings are RIPE NCC meetings, not > RIPE meetings. The difference is that the RIPE NCC goes out into a > specific region, meeting directly with the membership, according to > needs of that region. This is a different focus than the open process > of RIPE meetings. > > The 2002 Membership Survey and other sources expressed the opinion > that some parts of the RIPE region were unaware or unfamiliar with the > RIPE NCC and with general policies and procedures. Regional desks were > suggested, thus the MLO role was created within the RIPE NCC. The > first obvious region to meet was the Middle East, followed by Russia. > The goals of these meetings are to educate, increase knowledge and > allow the RIPE NCC to be more accessible to members in remote regions. > These meetings also afford us the opportunity to speak with > government agencies and so forth. > > C. RIPE NCC / LIR Portal Update > Presented by: Vesna Manojlovic - RIPE NCC Advanced Courses Trainer > http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48- > nccserv-lirportal.pdf > ******************************************************************** > Vesna began by asking how many of the present audience uses the LIR > Portal. Nearly everyone put their hand up. > > During the presentation Wilfried Woeber (UniVie / ACOnet) asked what > 'RSS' stands for? > > Vesna explained that RSS stands for 'Really Simple Syndication'. It is > a web syndication protocol used primarily by news websites and web > logs. > > Vesna reported how the tools on the LIR Portal are helping the RIPE > NCC's members acquire IP address resources quickly. This in turn > allows the RIPE NCC to concentrate more time assisting new and > inexperienced LIRs. Vesna concluded by saying that all feedback and > input from the membership is welcome and does make a difference. > > Andre Koopal (MCI) would like to be able to have access to the > messages in the Hostmaster tickets his LIR has with the RIPE NCC. > > Kurtis Lindqvist (Chair) ended the discussion reiterating the fact > that the original intention was for an LIR to give this presentation > but there were no volunteers. He would like to get a volunteer for the > next RIPE meeting in Manchester in September 2004. > > E. Kurtis Lindqvist (Chair) - WG input for the 2005 Activity Plan > *************************************************** > Kurtis reminded everyone why this working group was set up - to > provide input and dialogue to the Activity Plan of the RIPE NCC. The > work the RIPE NCC does should reflect the wishes and needs of the > community. > > When there was no response from the audience when asked if anyone gave > any feedback to the RIPE NCC about the Activity Plan for 2005, Kurtis > asked if everyone were happy for the RIPE NCC to take care of > compiling the Activity Plan on their own. Again there was no response. > > Axel Pawlik (RIPE NCC Managing Director) was not surprised, but still > a little disappointed at not receiving any feedback on this topic. He > will give a similar presentation (Agenda item B.) on Friday afternoon > during the RIPE NCC General Meeting (GM) where members will be > present. This therefore presents another formal opportunity for RIPE > NCC members to give input and thoughts on the AP. If Axel or the RIPE > NCC Board do not receive any feedback they will take this as approval > to go ahead with the plan. Axel reminded everyone that the Activity > Plan would be published to the RIPE NCC membership in August 2004, a > few weeks before the General Meeting at RIPE 49 in Manchester in > September 2004. > > Kurtis pleaded to the community to give input and feedback with > respect to the Activity Plan. If it is difficult to speak up at the > meeting, then emails to Axel and/or the RIPE NCC Board Members are > also an option. It is worrying that there appears to be silence on > this issue. > > F. Authentication for Hostmaster Robot > Presented by: Filiz Yilmaz - RIPE NCC Senior Hostmaster > http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48- > nccserv-hm-robot.pdf > ********************************************************************** > After Filiz gave her presentation, Gert Doering (SpaceNet) said that > in his opinion the problem with PGP is the key management (user keys, > Hostmaster key etc.) and the RIPE NCC have solved this now. He > suggested a script could be added to the LIR Portal for users who can > choose to have their e-mails encrypted or not. Then the RIPE NCC > Hostmasters can accept the e-mails as encrypted or not. > > Shane Kerr (RIPE NCC Software Manager) was more cautious as this > change would not come without complications. He explained how many LIR > Portal users lose their keys but the RIPE NCC cannot suddenly stop > communicating with LIRs in those cases. Signing is easier, as the > e-mail is visible and the user knows what the RIPE NCC is trying to > send them and vice versa. The RIPE NCC can look at their mail logs and > see what is going on there. There is already an infrastructure for key > management and recovery in place. > > Another problem Shane reported is that some communication is not only > "one-to-one", but also sometimes "one-to-many". This complicates the > picture quite a bit. All of the recipients have to read the e-mail and > if some do not have a PGP key or X.509 there is simply no way to > encrypt it for them. It was decided not to pursue the effort of going > into this issue in great detail before the last RIPE Meeting, because > of the complications it poses, therefore the RIPE NCC decided to focus > on verifying the correctness of the e-mail before starting to encrypt > it. > > Once this is done, the RIPE community will have to be asked if it is > worth the effort for the RIPE NCC to go over all of these issues and > put together a plan. > > Randy Bush (IIJ) asked, regarding automated software signing of > messages with PGP and X.509, how those keys are maintained and revoked > and so on. This is in light of the fact that if this process is being > done automatically, are there keys on a hard disk which may pose a > security risk? > > Shane (RIPE NCC Software Manager) responded by saying it is RIPE NCC's > policy to have extra secure hosts. These include CA and the RIPE NCC's > PGP signing box. There are two or three hosts, which have a limited > access and are connected directly to a single box, which is not on the > fabric of the RIPE NCC's network. The Operations Department of the > RIPE NCC can access most of the machines in the RIPE NCC. These boxes > have a smaller set of Administrators with access. The hosts are secure > so the keys are not generally available. > > The RIPE NCC takes security seriously. For PGP there is a key-signing > box and a set of procedures where the keys are changed regularly. Even > so, Shane admits the RIPE NCC has not published their old keys > recently and he promises to get that fixed shortly. > > Randy Bush (IIJ) asserted that presuming hosts are secure is a rather > weak assumption. > > Kurtis Lindqvist (Chair) asked Shane if there has there been any more > co-ordination work done with the other RIR's regarding X.509? > > Shane (RIPE NCC Software Manager) said the RIPE NCC is willing to make > a more detailed presentation on the underlining issues of PGP > encryption if the community wishes. The RIPE NCC put together this > presentation because they would like to start building it. Shane asked > the audience if the community were supportive of the proposal. There > were no objections to the proposal. > > ACTIONS > ******** > 48.1 RIPE NCC - To make a more detailed presentation on PGP encryption. > 48.2 RIPE NCC - To start implementing the key-signing proposal. > > G. De-Bogonising New Address Blocks > Presented by: Daniel Karrenberg - RIPE NCC Chief Scientist > http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48- > nccserv-debogon.pdf > ********************************************************************* > This presentation highlights the connectivity problems of LIR's who > receive address space out of very new /8's the RIPE NCC receive from > the IANA. The problem is that it takes too much time for all operators > to update their bogon filters. > > Geoff Huston (TELSTRA) pointed out that the address prefixes stated in > the presentation are taken from the RIPE whois database and not from > the delegated zone files of the RIPE NCC. The address prefixes stored > in the RIPE NCC's delegated files are more reliable as (a) handed out > officially by the RIPE NCC, (b) are in use and (c) can be routed. > > Geoff expressed his opinion regarding the necessity of using the > delegated files as authority if the community wants to be serious > about using correct bogon information. The Whois Databases should not > be relied upon, as they are problematic for all kinds of reasons. He > would not advise anyone doing real-live packet filtering to rely on a > Whois Database. > > Daniel Karrenberg (RIPE NCC Chief Scientist) agreed and said the RIPE > NCC will amend this procedure. > > The final slide of the presentation called for input from the audience > about this pilot. Would people like to see this make into a RIPE > document with the intention of becoming a regular RIPE NCC service? > > Geoff Huston (TELSTRA) asked for more granularity when producing > information on bogons. Addresses that have been allocated or assigned > but are in an "active" /8 make ideal bogons for miscreants. The RIPE > NCC should publish this information. > > Ruediger Volk (Deutsche Telecom) was next to say he would like the > RIRs to clarify what address space each has given out so far. This > would allow an understanding of what address space is in use and what > is not. > > Ruediger believes only the RIRs and IANA can and should do this. > > Andre Koopal (MCI) thinks the RIPE NCC should take the responsibility > of clarifying what they have allocated and what shouldn't be in the > bogon list. Additionally, he thinks that IANA should define the list > of where the real bogons are, not the RIPE NCC. > > Daniel Karrenberg (RIPE NCC Chief Scientist) reminded the audience > that the RIPE NCC started this de-bogonising pilot because of the many > complaints they received from LIRs. There was pressure for the RIPE > NCC to provide some relief, to be seen to do something to tackle the > problem. There have been mostly positive reactions to the pilot > although at this stage it is more ad hoc relief than an actual > solution. > > Andre Koopal (MCI) wishes to see the pilot become a permanent RIPE NCC > service. > > Randy Bush (IIJ) would like an effort made to look at the problems > from the front rather than using ad hoc relief. He agrees with Geoff > Huston that the underlying data is weak, not well defined and lacks > proper signed distribution. > > Geoff Huston (TELSTRA) specifies there are approximately 2,000 entries > (out of approximately 210,000) whose data are unclear, most of which > are /24 networks. It is not clear if those records have been allocated > or not. This kind of data needs to be accurate in order to have a > trustful bogon filter. > > Kurtis Lindqvist (Chair) asked if something is being done to prevent > similar problems happening in IPv6? > > According to Daniel Karrenberg (RIPE NCC Chief Scientist) and Gert > Doering (SpaceNet), these issues with IPv6 have not risen yet. It was > not specified as a requirement for this pilot. Gert stated people are > filtering far too loosely with IPv6 and the problem is not the > prefixes not propagating, but garbage propagating everywhere. There > does not appear to be a problem with non-reachability due to bogon > filters. He asserts the problems discussed here are not evident in > IPv6. IPv6 has other problems. > > Gert thinks there may be scientific interest to measure propagation, > especially to counter mistakes made in the past with IPv4. > > Kurtis Lindqvist (Chair) posed the question to the audience: Would > there be interest to give the RIPE NCC a task to go to IANA to try to > clean up the data? > > Daniel Karrenberg answered that all the RIR's have this task already. > > Geoff Huston (TELSTRA) spoke that as a customer of RIR data and as an > operator he needs to rely on accurate data. The IANA and the RIR's > need to fixed the current inconsistencies. Currently within the RIR > communities information is published about address space in a number > of different formats; delegated files, Whois, RIPE NCC documents. They > are not all drawn from the same underlining database, they cannot be > because there is inconsistency, he said. > > Geoff believes it is worth the RIR's effort to have an accurate and > consistent listing of what address space is in use and what is not, on > at least a 24-hour cycle. Then people will know what to expect in > their routers. IPv6 or IPv4 makes no difference. > > Shane Kerr (RIPE NCC Software Manager) addressed the WG to say the > RIPE NCC are aware and have foundation plans to improve consistency of > registration data across the RIR's and IANA. However the current plan > is to wait until the ERX (Early Registration Transfer Project: > http://www.ripe.net/ripencc/pub-services/db/erx.html) is finished. > This would allow the RIPE NCC to clean up the data it currently holds > first before addressing the inconsistency problem. > > Nevertheless the RIPE NCC wanted to use this pilot to gauge from this > working group about how much effort should be spend on this because it > will be expensive in terms of cost and time to pursue it further. It > will take time away from answering requests for new IP resources for > example and Shane does not have a good feeling yet how much time the > community wishes the RIPE NCC spend on addressing this data > consistency issue. > > Kurtis Lindqvist (Chair) asked Shane if the RIPE NCC is waiting for > the ERX to finish, and if anything was being done right now to clean > the data? > > Shane Kerr (RIPE NCC Software Manager) explained how historically it > used to be the case that anyone could register anything in the RIPE > Whois Database at any time. There was never an effort to clean up or > make the data consistent in the past in a systematic way. Right now, > as the ERX proceeds the RIPE NCC are cleaning up the data within each > /8 systematically and once the ERX is complete the RIPE NCC will be > able to know that at least the data from those /8 blocks is good. > Shane confirmed that most of the garbage left resides in the 192/8 > block. Historically this block is quite a mess. > > When the ERX project finishes the RIPE NCC would like to go back and > start looking at the data in the oldest blocks, 193/8, 194/8 & 195/8. > These are of the vintage 1993 - 1995 era. In order to do this however > it will take human beings going through old mail logs and files and so > forth. > > Geoff Huston (TELSTRA) felt it was worth the effort if the community > wants a secure routing system that is robust against determined and > professional attempts to abuse it. Filtering will not help. The data > must be trusted from the beginning. The people who can clarify what > address blocks have been allocated are the RIR's. > > Geoff went on to say the price of a secure routing system is > ultimately cleaning up the data first so reliable and trusted > attestations can be made about address space. > > Kurtis Lindqvist (Chair) agrees and sees this task as important as > making new delegations. The Bogon issue is important. It already > causes a lot of havoc, which amounts to cost to the LIRs. Kurtis > suggested it might be cheaper to clean the data up in the long run > than to leave it as it is at the moment. > > Leo Vegoda (RIPE NCC Registration Services Manager) explained that > some old last resort registries had passed their allocations to the > RIPE NCC. However, not all of them had passed the documentation for > the assignments they had made. This means that the RIPE NCC cannot > easily validate database entries. Cleaning things up will take > considerable input from the operator community as well as the RIPE > NCC. > > Daniel Karrenberg (RIPE NCC Chief Scientist) agrees with Leo and > although he is RIPE NCC staff he also agrees with Geoff Huston that > this is the RIR's core business and time should be spent on this task. > > Ruediger Volk (Deutsche Telecom) agrees the data needs to be cleaned > and recommended to quickly setup RS set names or something similar > without delay. > > Kurtis Lindqvist (Chair) asked the audience if they do NOT think the > RIPE NCC should spend time and effort to try to clean up the bogus > data? > > - -Silence from the audience- > > As there were no comments, Kurtis said that this is clear consensus. > The message (apparently) is that the community wants the RIPE NCC to > spend time and effort pursuing the goal to clean up the registration > data. He acknowledges it is probably going to cost some money so he > suggested to possibly making a standard reporting item on the RIPE NCC > to report on the progress of this task and then cost and plans can > come from there. > > 48.3 Chair - Add standard agenda item to report on progress of data > quality. > > Y. Open Microphone > > - -There were no Open Microphone discussions- > > Z. AOB > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQMC/3KarNKXTPFCVEQLNFACdGfVf5KT9P7sAUQdQDOa1GQsu1HcAoOrb 2txNFr61R2YAVI7WImSZHVX/ =3ujt -----END PGP SIGNATURE-----

1 0

RIPE 48 Meeting Report
by Nick Hyrka 27 May '04

27 May '04

[Apologies for any duplicate mailings.] RIPE 48 Meeting Report Dear Colleagues, The RIPE 48 Meeting was held from 3 - 7 May 2004 at the Grand Hotel Krasnapolsky, Amsterdam, the Netherlands. There were a total of 267 attendees comprised of the RIPE NCC membership, the RIPE community and government representatives. Attendees also included representatives from APNIC, ARIN, AfriNIC, LACNIC and ICANN. HIGHLIGHTS Highlights of RIPE 48 included an update on the Number Resource Organization from Axel Pawlik, Managing Director, RIPE NCC; an open discussion on the proposed Memorandum of Understanding (MoU) between the Number Resource Organization and ICANN; the community consensus to create an ENUM Working Group. J. Scott Marcus, Transatlantic Fellow, The German Marshall Fund of the United States, gave a presentation on the deployment challenges involved with evolving the core of the Internet. This presentation can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-plenary-marc… The European Operators Forum (EOF) featured presentations on lawful interception of IP traffic, managing a DoS attack, stable BGP routing, strategies for IP traffic engineering, analysing the Internet Routing Registries, IP Address Space and AS Number hijacking and applications of Bidirectional Forwarding Detection (BFD). EOF presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#eof The RIPE NCC, FLAG Telecom, Amsterdam Internet Exchange and Interoute are thanked for the support they provided to the meeting. Global Voice Networks are thanked for the provision of the meeting Internet connectivity. SUMMARY ADDRESS POLICY WORKING GROUP - It was agreed that the issue of worldwide "shopping" for address space needs to be carefully considered before adopting different IPv4 additional allocation procedures (i.e. HD Ratio) in each region. - There were calls for the clarification and review of the initial allocation criteria for IPv6 allocations. The RIPE NCC will propose a rewrite of the IPv6 policy after the issue has been discussed in more detail on the mailing list. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#ap DATABASE WORKING GROUP - It was agreed that the 'country:' attribute should be either removed or be optional. - It was decided that the default behaviour of the RIPE Database will be changed to return the Incident Response Team (IRT) object if available, in order to make it easier for users to find relevant security contact information. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#db TEST TRAFFIC MEASUREMENT (TTM) WORKING GROUP - Three presentations were given by Test Box users that offered useful tutorial information for all Test Box owners. - The Working Group Chair encouraged the RIPE NCC to investigate moving measurements into the O/S kernel and/or to hardware. - It was noted that the RIPE NCC has lowered the annual TTM service fee to 1000 euro/year for the first box, 500 euro/year for the second to ninth boxes and that a large company has offered to sponsor hardware for non-profit, research institutes. Test Traffic Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#tt ANTI-SPAM WORKING GROUP - The community was asked to look at the Anti-Spam Working Group charter and to suggest how it should be changed. - Fearghas McKay reported on the sender-pays stream and specifically on the 'camram' proposal which uses a well-documented system for generating cryptographic signatures ('hashcash'). - There was a proposal to establish a top level domain 'mail.' to be used as a type of DNS white-listing service. IPv6 WORKING GROUP - It was agreed that the Working Group Chair will seek consensus from the Working Group on whether the Minimum Technical IPv6 Peering Requirements (MIPP) document should become a RIPE document. - The community was asked to provide feedback on larger than default IPv6 allocations. - Pim van Pelt asked for members of the community who would like to run public 6to4 relays. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#ipv6 EIX WORKING GROUP - Kurtis Lindqvist presented his view from the IXP Customer View workshop. - Bijal Sanghani gave a presentation on the expectation an ISP has for an IXP. - European IXPs gave an update about the latest developments, including a presentation on the shared experience of engineers when they migrated their customers from one switch to another. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#eix DNS WORKING GROUP - It was agreed that the RIPE NCC will review the zone checks done by the reverse delegation robot. - DNS MODA was proposed by Jim Reid as a not-for-profit body to work on DNS protocol issues. - It was noted that the expansion of IPv6 makes the streamlining of IPv6 direct and reverse DNS even more necessary. DNS Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#dns ROUTING WORKING GROUP - It was agreed that the RIPE NCC should publish an IRR Toolset maintenance schedule. - There was a presentation on some of the technical issues of high-speed global roaming (flying an 802.11b wireless hot-spot at around 900 km/hr at altitudes around 10km). - There was a presentation on BGPlay, a tool that visualises Internet routing activity. Routing Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#routing RIPE NCC SERVICES WORKING GROUP - The RIPE NCC was asked to make a more detailed presentation on PGP encryption. - It was agreed that the RIPE NCC should start implementing the key-signing proposal. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#ncc-serv… TECHNICAL SECURITY WORKING GROUP - There was a presentation on security aware resolvers and discussion on the requirements for them. - There was discussion on 'server-side' protocol bits and the feeling that they are solid and ready for deployment; it was noted that validator/application communication and key-management issues need work. Technical Security Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-48/presentations/index.html#techsec TUTORIALS The RIPE NCC Training Team presented the RIPE NCC IP Request Tutorial. It explained address space assignment and allocation procedures in the RIPE NCC region: http://www.ripe.net/ripe/meetings/ripe-48/tutorials/ip-request/index.html RIPE 48 WEBCASTING AND ARCHIVES During RIPE 48, the RIPE NCC held trials in collecting feedback from participants watching the webcast. The mediums used for this were IRC and Jabber. Archives of presentations, webcasts and IRC/Jabber feedback from RIPE 48 are available at: http://www.ripe.net/ripe/meetings/ripe-48/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) The RIPE NCC Hostmaster Consultation Centre was open at RIPE 48, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. RIPE 48 REFERENCE PAGE A complete list of RIPE 48 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-48/index.html "MEET & GREET" The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 48. "Meet & Greet" introduces newcomers to the meetings, to key attendees from the RIPE community and to social events throughout the week. More information can be obtained by contacting: <meet-greet(a)ripe.net>. RIPE 49 RIPE 49 will be held in Manchester, the United Kingdom, from 20 - 24 September 2004. Information on RIPE 49 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-49/ NEW LOCAL INTERNET REGISTRIES (LIRs) Please note: New LIRs are entitled to two (2) free tickets to attend a RIPE Meeting. The tickets cover the meeting fee only and do not apply to the RIPE dinner, travel or hotel accommodation. More information on the new LIR tickets can be found at: http://www.ripe.net/ripe/meetings/new-lir.html For more information, contact <meeting(a)ripe.net>.

1 0

Reminder - RIPE NCC Regional Meeting, Moscow 16-18 June 2004
by Membership Liaison Officer 19 May '04

19 May '04

[Apologies for duplicate emails] Dear Colleague, We would like to remind you that the RIPE NCC Regional Meeting in Moscow will be held 16 - 18 June 2004 at the Hotel Metropol, Moscow, Russia. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible to cover their own travel and accommodation costs. REGISTRATION To register, please see: http://www.ripe.net/cgi-bin/moscow-reg Please note that registration closes on 7 June 2004. AGENDA The Regional Meeting draft agenda has been updated and can be found at: http://www.ripe.net/ripencc/regional-meetings/moscow-2004/agenda.html MORE INFORMATION More information about the RIPE NCC Regional Meeting, Moscow is available from: http://www.ripe.net/ripencc/regional-meetings/moscow-2004/ Any further questions can be sent directly to: <contact(a)ripe.net>. Regards, Nathalie Dougall Membership Liaison Officer RIPE NCC http://www.ripe.net

1 0

RE: RIPE 48 NCC-Services WG Agenda
by Sanghani, Bijal 05 May '04

05 May '04

Hi All, Apologies for the late update, the NRO update has now moved to the Opening Plenary. Please see proposed agenda below - Day 1: Tuesday, 4 May 2004, 14:00 - 15:30 Day 2: Thursday, 6 May 2004, 11:00 - 12:30 Room: Grand Ballroom Agenda: (Tuesday) A. Administrative Matters (5 min) - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 47: http://www.ripe.net/ripe/wg/ncc-services/r47-minutes.html B. Axel - RIPE NCC Update (10-15 min) / 2005 Activity Plan (10-15 min) C. RIPE NCC - LIR Portal Update (10-15 min) (Thursday) Distribute participants list E. Kurtis - WG input for the 2005 Activity Plan (10-15 min) F. Filiz Yilmaz - Authentication for Hostmaster Robot (10-15 min) G. Daniel Karrenberg - De-Bogonising New Address Blocks (10-15 min) Y. Open Microphone Z. AOB regards, Bijal ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

2 3

Request Forms: updated and available on LIR Portal
by leo vegoda 26 Apr '04

26 Apr '04

Dear Colleagues, The RIPE NCC is pleased to announce the release of version 1.1 of the IPv4, IPv6 and AS Number request forms. This update has been necessary in order to accommodate the new ORGANISATION object and "mnt-domains:" attribute. More detailed information about the new object and attribute has already been sent to this mailing list. Archived copies of the announcements can be found at: http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00006.html and http://www.ripe.net/ripe/mail-archives/ncc-services-wg/2004/ msg00104.html Following feedback from our members we have made other adjustments to the request forms. The main changes include the following: - The submission of network diagrams for IPv6 requests is now optional - The IPv4 First Allocation request form has been adapted to conform with the new minimum allocation policy. - The IPv4 Additional Allocation request form no longer has overall usage or allocation usage templates. - It is possible to use integers to describe the number of IP addresses used in subnets in IPv4 PA and PI assignment request forms During the transition period ending 19 July, 2004, both versions 1.0 and 1.1 of the request forms will be accepted and given the highest priority. After this date, version 1.0 request forms will be processed with a lower priority via the <lir-help(a)ripe.net> mailbox. Requests can be completed and submitted directly via the LIR Portal, which also provides real-time syntax checking and help. The LIR Portal can be found at: https://lirportal.ripe.net/ Text versions of the updated forms and their supporting notes (with examples of completed requests) are available for download from the RIPE Document Store found at: http://www.ripe.net/ripe/docs/internet-registries.html#request If you have any questions regarding the forms, please contact <lir-help(a)ripe.net>. Suggestions for improvements to the forms and the LIR Portal are welcome at <lirportal-feedback(a)ripe.net>. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC

1 0

New Policy and Procedures for Reverse DNS Requests
by Olaf Kolkman 26 Apr '04

26 Apr '04

Dear Colleagues, (Apologies for duplicate messages) The RIPE NCC has implemented a number of changes in the policy and procedures for requesting reverse delegation. This follows the effort to streamline reverse DNS operations [1] and make it easier for network administrators to manipulate related DOMAIN objects. You should be aware of the following changes: When users want to update their reverse DNS information, they send an e-mail to <auto-dbm(a)ripe.net> (formerly this mail was sent to <auto-inaddr(a)ripe.net>). The database update program will verify the DNS information and update the RIPE Database. The information will appear in the DNS after a short delay. The policy constraints have been reduced. Previously only space assigned to End Users could be reverse delegated in DNS. This caused administrative burden to LIRs, as every time space was assigned, reverse DNS had to be set up for that space. Now reverse DNS can be set up for an entire allocation. Documentation that details the new setup and authorisation can be found at: http://www.ripe.net/reverse/ More details on these developments is provided below. * The reverse DNS policy as proposed in [3] is published as ripe-xxx. The main change to the policy is the removal of the requirement for valid assignments. Reverse delegations can also be requested by non LIRs if an appropriate "mnt-domains:" attribute is in place in the corresponding INETNUM/INET6NUM object, when submitting requests to <auto-dbm(a)ripe.net>. * The <auto-inaddr(a)ripe.net> interface will be deprecated as of 1 July 2004. To allow for a graceful transition, the "mnt-domains:" based authorisation mechanism has not been implemented for the <auto-inaddr(a)ripe.net> interface. This will continue to use reg ID based authorisation. The "mnt-by:" attribute will become mandatory. However, the existence of the "mnt-by:" attribute in DOMAIN objects is not enforced when the object is submitted through the <auto-inaddr(a)ripe.net> interface. Please contact <inaddr(a)ripe.net> if you have further questions. Olaf Kolkman New Projects, RIPE NCC Can Bican Software Engineering Dept., RIPE NCC ---------------------------------------------------------------------- References: [1] Original RDNS Project Proposal http://www.ripe.net/reverse/proposal.html [2] "mnt-domains:" Attribute Proposal http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00007.html [3] Policy for Reverse Address Delegation of IPv4 and IPv6 Address Space in the RIPE NCC Service Region http://www.ripe.net/ripe/docs/rev-del.html [4] Webupdates http://www.ripe.net/perl/webupdates.pl [5] http://www.ripe.net/ripe/mail-archives/dns-wg/2004/msg00008.html

1 0

RE: RIPE 48 NCC-Services WG Agenda
by Sanghani, Bijal 23 Apr '04

23 Apr '04

Dear All, With the addition of the NRO update, I've updated the proposed agenda - (Tuesday) A. Administrative Matters -(5 mins) - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 47: http://www.ripe.net/ripe/wg/ncc-services/r47-minutes.html> B. Axel - RIPE NCC Update (10-15 mins)/2004 Activity Plan (10-15 mins) C. Number Resource Organization (NRO) Update (10-15 mins) D. RIPE NCC - LIR Portal Update and Members Feedback (10-15 mins) (Thursday) - Distribute participants list E. Axel - 2005 Activity Plan (10-15 mins) F. Kurtis - WG input for the 2005 Activity Plan (10-15 mins) G. Filiz Yilmaz - Authentication for Hostmaster Robot (10-15 mins) H. Daniel Karrenberg - De-Bogonising New Address Blocks (10-15 mins) Y. Open Microphone Z. AOB regards, Bijal -----Original Message----- From: Sanghani, Bijal [mailto:BSanghani@flagtelecom.com] Sent: Thursday, April 15, 2004 4:23 PM To: 'ncc-services-wg(a)ripe.net' Cc: 'webmaster(a)ripe.net'; 'meeting(a)ripe.net'; 'wg-chairs(a)ripe.net' Subject: RIPE48 NCC-Services WG Agenda Dear Colleagues, Below is the Proposed RIPE NCC Services WG Agenda - (Tuesday) A. Administrative Matters -(5 mins) - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 47: http://www.ripe.net/ripe/wg/ncc-services/r47-minutes.html> B. Axel - RIPE NCC Update (10-15 mins) C. Axel - 2004 Activity Plan (10-15 mins) D. RIPE NCC - LIR Portal Update and Members Feedback (10-15 mins) E. Filiz Yilmaz - Authentication for Hostmaster Robot (10-15 mins) (Thursday) - Distribute participants list F. Axel - 2005 Activity Plan (10-15 mins) G. Kurtis - WG input for the 2005 Activity Plan (10-15 mins) H. Daniel Karrenberg - De-Bogonising New Address Blocks (10-15 mins) Y. Open Microphone Z. AOB Best regards, Bijal Sanghani FLAG Telecom ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0

ORGANISATION objects in the RIPE Whois Database
by DB-News 19 Apr '04

19 Apr '04

Dear Colleagues, (apologies for duplicate messages) The RIPE NCC is pleased to announce that as of 17, April 2004, a new type of object, the ORGANISATION object, is available in the RIPE Whois Database. You can find more information about the ORGANISATION object at: http://www.ripe.net/db/organisation.html As part of the transition process, the RIPE NCC has: - created ORGANISATION objects for LIRs (around 4000 ORGANISATION objects) - updated LIR allocation objects to include "org:" attributes pointing to these new ORGANISATION objects (around 6500 INETNUM/INET6NUM objects) LIRs can update parts of their ORGANISATION objects through the ORGANISATION Object Editor available through the LIR Portal: https://lirportal.ripe.net/lirportal/index.html Please contact <ripe-dbm(a)ripe.net> for any questions. Best Regards, -- Engin Gunduz RIPE NCC Software Engineering Department

1 0

RIPE NCC Regional Meeting, Moscow, 16-18 June 2004
by Membership Liaison Officer 19 Apr '04

19 Apr '04

[Apologies for duplicate emails] Dear Colleagues, The RIPE NCC is pleased to announce the RIPE NCC Regional Meeting, Moscow, to be held 16 - 18 June 2004 at the Hotel Metropol, Moscow, Russia. Registration for the Regional Meeting opens 19 April 2004. Attendance to the RIPE NCC Regional Meeting is open and free of charge. However, attendees are responsible to cover their own travel and accommodation costs. To register, please see: http://www.ripe.net/cgi-bin/moscow-reg The RIPE NCC Regional Meeting will focus on Internet resource allocation and Internet management issues including: - How to participate in and influence IP address management policy-making; - The industry self-regulatory open structures and processes used by the RIPE NCC and the global Internet community; - Are we running out of IPv4 address space?; - An update on IPv6; - Local, Regional and Global Internet Working and Routing; - Domain Name management on the Internet; - Root Server Operations The Regional Meeting draft agenda can be found at: http://www.ripe.net/ripencc/regional-meetings/moscow-2004/agenda.html RIPE and the RIPE NCC will explain their roles in the administration of the Internet infrastructure as well as specific aspects in managing and operating the Internet infrastructure. The discussions will be directly related to the particular needs and concerns surrounding these issues in the region. The current draft meeting agenda reflects our intentions. However, it requires active participation from the local community to discuss specific issues of the region. The RIPE NCC has reserved several presentation opportunities for those with local knowledge of Internet management and operational issues affecting the region. If your organisation wishes to provide a presentation or suggest a relevant topic, please send your proposal by e-mail to: <contact(a)ripe.net> The RIPE NCC is one of four Regional Internet Registries (RIRs) that provide Internet resource allocation, registration services and co-ordination activities that support the operation of the Internet globally. The RIPE NCC is an independent, not-for-profit membership organisation that provides services to members in its service region currently covering Europe, the Middle East, Central Asia and African countries located north of the equator. Further information about the RIPE NCC and RIPE can be found at: http://www.ripe.net More information about the RIPE NCC Regional Meeting, Moscow is available from: http://www.ripe.net/ripencc/regional-meetings/moscow-2004/ Any further questions can be sent directly to: <contact(a)ripe.net>. Regards, Nathalie Dougall Membership Liaison Officer RIPE NCC

1 0

RIPE48 NCC-Services WG Agenda
by Sanghani, Bijal 15 Apr '04

15 Apr '04

Dear Colleagues, Below is the Proposed RIPE NCC Services WG Agenda - (Tuesday) A. Administrative Matters -(5 mins) - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 47: http://www.ripe.net/ripe/wg/ncc-services/r47-minutes.html> B. Axel - RIPE NCC Update (10-15 mins) C. Axel - 2004 Activity Plan (10-15 mins) D. RIPE NCC - LIR Portal Update and Members Feedback (10-15 mins) E. Filiz Yilmaz - Authentication for Hostmaster Robot (10-15 mins) (Thursday) - Distribute participants list F. Axel - 2005 Activity Plan (10-15 mins) G. Kurtis - WG input for the 2005 Activity Plan (10-15 mins) H. Daniel Karrenberg - De-Bogonising New Address Blocks (10-15 mins) Y. Open Microphone Z. AOB Best regards, Bijal Sanghani FLAG Telecom ********************************************************************** This e-mail message is confidential and is intended only for the use of the individual or entity named above and contains information which is or may be confidential, non-public or legally privileged. Any dissemination or distribution of this message other than to its intended recipient is strictly prohibited. You should not copy it or use it for any purpose nor disclose the contents to any other person. If you have received this message in error, please notify us by email to postmaster(a)flagtelecom.com immediately and delete the original message and all copies from all locations in your computer systems. This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG Telecom cannot accept liability for any damage which you may sustain as a result of software viruses. ********************************************************************** This message has been scanned for viruses by MailControl - www.mailcontrol.com

1 0