From joao-ripe at c-l-i.net Wed May 4 14:29:52 2005 From: joao-ripe at c-l-i.net (=?ISO-8859-1?Q?Jo=E3o_Damas?=) Date: Wed, 4 May 2005 14:29:52 +0200 Subject: Updated agenda for routing-wg Message-ID: <8AD21393-7F33-4AC6-8E8D-4DA6FD5E6E25@c-l-i.net> Thursday, May 5, 9:00-10:30, Plenary room - Administrativia: Minutes of previous meeting, Appointment of scribe, review of open actions, attendee list - Discussion space for the topics covered in talks: Open floor, seeking input and discussion on: - Traffic engineering and the effect of business practices on the routing table - Route flap damping today - DDoS Detection & Mitigation Experience using Arbor/Peakflow & Cisco/Guard - Watch your Flows with NfSen and NFDUMP - Traffic Anomaly Detection, DDoS Mitigation, Coordinated Attack Fingerprinting - Thoughts about recommendations for BGP filters for IPv6 Presentation: - Active BGP probing. Lorenzo Colitti, RIPE NCC and University of Rome Tre Introduction/abstract: I and my colleagues at Roma Tre University have developed techniques that ISPs can use to find out how their prefixes could be announced in case of network faults and how other ASes treat their prefixes. Our techniques are based on active BGP probing and announcing large AS-sets, and have been successfully tested in the IPv6 Internet. Our subsequent announcement of tests on the IPv4 network caused a bit of a stir on nanog [1]. The tests were cancelled and we said we would first come out with a document explaining what we do and how we do it and then continue the discussion. A technical report is almost ready and we would like to get the discussion going. From hpholen at tiscali.no Wed May 4 18:30:25 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 04 May 2005 18:30:25 +0200 Subject: Policy Development Process - last call In-Reply-To: References: Message-ID: <4278F8A1.3080901@tiscali.no> I think the timeline pdf attachment needs to reflect the process. From the graphics I dont understand how the review phase works. The policy text reads 2.3 Review Phase Following the conclusion of the comment period the RIPE Working Group Chair determines whether the working group has reached consensus. If consensus has not been reached then the proposer may decide to withdraw the proposal. Alternatively, a new round of discussion and documentation may occur. But the graphics says "Comment and Review" with a suggested timeline of 4 weeks and an additional 1 week to make a desicion ? I propose that the graphics is updated to reflect the text in 2.3. -hph Rob Blokzijl wrote: >Dear colleagues, > > please find attached the latest version of the Policy Development >Process document. This is a last call - final remarks either to this >mailing list, or at the RIPE meeting next week. > > Closing date: May 10. > >Regards, > > Rob > > > >------------------------------------------------------------------------ > > > > > Policy Development Process in RIPE > > R.Blokzijl > 15 March 2005 > Version 2 > > > > > 1. Introduction > > Since its creation in 1989, RIPE has from time to time agreed on common > practices. These common practices may come in different forms and/or under > different names: > - best common practice (or BCP), > - recommendations to the community, > - requests to the RIPE NCC, > - recommendations to the RIPE NCC, > - or just policy. > > In this document they are all called 'Policy'. > > The process that results in a policy has a few important and fundamental > principles: > > a. it is open to all. Everyone interested in the > wellbeing of the Internet may propose a policy, and take part in > the discussions. > > b. it is transparent. All discussions and results are documented and > freely available to all. > > c. conclusions are reached by consensus. > > This process has worked quite well over the years. This document does not > seek to change that. > > What this document does try to accomplish is a description of the process > that will improve its management. > > > 2. The Process. > > In the process of developping a policy several distinct phases are > identified: > > 1. Proposal Phase > > 2. Discussion Phase > > 3. Review Phase > > 4. Concluding Phase > > Each of these phases are detailed below. > > The whole process is summarised in a diagram, attached as Appendix A. > This diagram contains timelines for the various stages of the process. > These timelines are meant as defaults, or minimum timelines: individual > proposals may define their own timelines. > > In this process the RIPE NCC (the RIPE community's secreteriat) gives > administrative support, such as: > > - administering proposals > - publication on relevant web pages > - tracking deadlines > > 2.1 Proposal Phase > > Discussions may be started by anyone at any time. Participants are > welcome to discuss broad ideas as well as make detailed policy > proposals. Proposals are made using a Policy Proposal template > [TEMPLATE Appendix B]. > The template forms a structure for the proposal. It details the > reason for the proposal and any perceived consequences of the > proposal. > > A proposal is usually submitted via the chair of the relevant > working group of RIPE. In case a working group can not easily be > identified, the proposal may be submitted to the RIPE Chair. > > The RIPE NCC identifies proposals with a number and publishes them > in the appropriate section of the relevant working groups web pages. > The page will indicate the version history and status of proposals: > - Open for Discussion; > - Agreed or > - Withdrawn. > > The RIPE NCC will also maintain a web page with an overview of all > outstanding policy proposals. > > Anyone that wants to draft a policy proposal may seek assistance > from the RIPE NCC. The RIPE NCC will provide relevant facts, > statistics and an assessment of the work involved in implementation > of a proposal. The RIPE NCC will also assist with the drafting of > text if its editorial services are required. > > > 2.2 Discussion Phase. > > Once a proposal has been submitted it will be announced on a > dedicated mailing list to which anybody can subscribe: > . This announcement will also indicate > where discussion on this proposal will take place. Usually this will > be the relevant working group mailing list. > > Where a policy change would result in an amendment to a published > policy document, the textual changes are initially published as a > draft document for community review and comment. There may be multiple > iterations of a draft document if there is significant comment and > change suggested. > > The discussion phase will have a limited time period, but not less > then four weeks. > > > 2.3 Review Phase > > Following the conclusion of the comment period the RIPE Working > Group Chair determines whether the working group has reached > consensus. If consensus has not been reached then the proposer may > decide to withdraw the proposal. Alternatively, a new round of > discussion and documentation may occur. > > > 2.4 Concluding Phase > > When the RIPE Working Group Chair determines that the working group > has reached a consensus, s/he moves the proposal to a Last Call for > comments. The Last Call announcement is posted to the working group > mailing list, the Last Call announcements mailing list and Chairs of > all working groups. At the end of the Last Call period the working > group chairs will decide together whether a consensus has been > achieved > > If a consensus has been achieved, the RIPE NCC will announce the > decision of the RIPE Working Group Chairs and implement the policy, > if needed. > > If consensus has not been achieved the proposer (or anyone else) is > free to return the proposal to the working group for further > discussion. > > > > 3. Appeal Process > > [Having a documented process in place creates the need for an oversight > function. In case there excists doubt wether the process has been > followed, there is a need for an appeal procedure. > > Input is sought on how to implement this.] > > > >[TEMPLATE Appendix B] > >1. Number (assigned by the RIPE NCC) >2. Policy Proposal Name: >3. Author > a. name: > b. e-mail: > c. telephone: > d. organisation: >4. Proposal Version: >5. Submission Date: >6. Suggested WG for discussion and publication >7. Proposal type: > a. new, modify, or delete. >8. Policy term: > a. temporary, permanent, or renewable. >9. Summary of proposal >10. Policy text > a. Current (if modify): > b. New: >11. Rationale: > a. Arguments supporting the proposal > b. Arguments opposing the proposal > > > > From pk at DENIC.DE Wed May 4 21:45:27 2005 From: pk at DENIC.DE (Peter Koch) Date: Wed, 4 May 2005 21:45:27 +0200 Subject: Policy Development Process - last call In-Reply-To: References: Message-ID: <20050504194527.GA15359@denics7.denic.de> Hi, > Policy Development Process in RIPE > Version 2 short note/warning: the website still points to the 1st version only at > The whole process is summarised in a diagram, attached as Appendix A. > This diagram contains timelines for the various stages of the process. > These timelines are meant as defaults, or minimum timelines: individual > proposals may define their own timelines. For the sake of easier reading the timelines should appear in the text as well. > 2.1 Proposal Phase > > Discussions may be started by anyone at any time. Participants are > welcome to discuss broad ideas as well as make detailed policy > proposals. Proposals are made using a Policy Proposal template > [TEMPLATE Appendix B]. > The template forms a structure for the proposal. It details the > reason for the proposal and any perceived consequences of the > proposal. The introductory text suggested that also "recommendations to the community" would fall in the "policy" category. Thinking of various precedent in the DNS WG, should this process now be the only way to publish a RIPE document? > draft document for community review and comment. There may be multiple > iterations of a draft document if there is significant comment and > change suggested. > > The discussion phase will have a limited time period, but not less > then four weeks. Does this mean every single, all or the latest version of the document must be up for >= 4 weeks? Also the diagram suggests that a document only appears at the end of the Discussion Phase, making that a time where the WG decides to "adopt" the proposal as a work item. > 2.3 Review Phase > > Following the conclusion of the comment period the RIPE Working The term "comment period" has not yet been defined. Is it the first 4 weeks of the Review Phase? > Group Chair determines whether the working group has reached Here and in the diagram it says "Chair" where the plural might be more appropriate at least for some groups. > consensus. If consensus has not been reached then the proposer may > decide to withdraw the proposal. Alternatively, a new round of > discussion and documentation may occur. How far back in the diagram would that point? I guess "documentation" means that before further "comment" there needs to be "discussion" to produce a new draft version. Should there be a limit for the number of iterations or at least a chair's (or chairs') judgement on this - to prevent resource exhaustion? > 2.4 Concluding Phase > > When the RIPE Working Group Chair determines that the working group > has reached a consensus, s/he moves the proposal to a Last Call for > comments. The Last Call announcement is posted to the working group > mailing list, the Last Call announcements mailing list and Chairs of > all working groups. At the end of the Last Call period the working > group chairs will decide together whether a consensus has been > achieved I suggest that there be a way to fold in last call comments without reiterating the whole process ... > 3. Appeal Process > > [Having a documented process in place creates the need for an oversight > function. In case there excists doubt wether the process has been > followed, there is a need for an appeal procedure. > > Input is sought on how to implement this.] ... which will be helpful in this particular case. The default RIPE Last call period should be 4 weeks IMHO. -Peter From hpholen at tiscali.no Wed May 11 02:02:49 2005 From: hpholen at tiscali.no (Hans Petter Holen) Date: Wed, 11 May 2005 02:02:49 +0200 Subject: Policy Development Process - last call In-Reply-To: References: Message-ID: <42814BA9.1070403@tiscali.no> There is a language inconcistency in the document: > 2.3 Review Phase > > Following the conclusion of the comment period the RIPE Working > > The term "comment period" should be changed to "Discussion Phase" to be concistent with paragraph 2 and 2.2 From ncc at ripe.net Tue May 24 14:09:07 2005 From: ncc at ripe.net (Nick Hyrka) Date: Tue, 24 May 2005 14:09:07 +0200 Subject: RIPE 50 Report Message-ID: <5.2.1.1.2.20050524134842.0402ae48@mailhost.ripe.net> [Apologies for duplicate e-mails.] RIPE 50 Report Dear Colleagues, The RIPE 50 Meeting took place from 2 - 6 May 2005 at the Clarion Hotel, Stockholm, Sweden. There were over 375 participants at the meeting. Attendees also included government representatives and representatives from AfriNIC, APNIC, ARIN, LACNIC and ICANN. HIGHLIGHTS Highlights of RIPE 50 included: - The successful implementation of the new RIPE Meeting format into three days on operational and technical content followed by two days on policy related issues. - An update on the ICANN ASO Address Council. This presentation is available at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-fri-ac.pdf - A commentary on the ITU-T Proposal for National Address Registries for IPv6 by Geoff Huston, APNIC. This presentation is available at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-itu-ipv6-proposal.pdf - Final discussion on the RIPE Policy Development Process. More information about this will appear on www.ripe.net shortly. Afilias, Arbor Networks, Cisco Systems, Force10 Networks, Netnod, NIKHEF, Nokia, TeliaSonera and the RIPE NCC are thanked for the support they provided to the meeting. TeliaSonera are thanked for the provision of the meeting Internet connectivity. PRESENTATIONS All the Plenary and Working Group presentations from RIPE 50 can be viewed at: http://www.ripe.net/ripe/meetings/ripe-50/presentations/index.html SUMMARY ADDRESS POLICY WORKING GROUP - It was agreed that the Address Policy Working Group Chairs will make a formal proposal that global policies should go through the RIPE Policy Development Process. - There was discussion on the TLD anycast allocation policy proposal, the IPv6 proposal to remove the 200 customers requirement, the proposal for removal of the Africa Special Policy, the proposal to add regional boundaries to policy documents and the IPv4-HD-Ratio proposal. ANTI-SPAM WORKING GROUP - There was discussion on whether ripe-206 should be revised to reflect the updates to the LINX BCP document that was used as the base for the original ripe-206. - There was discussion about anti-spammers sometimes behaving worse than spammers, and action placed on the Working Group Chair to start work on a document for best practise for spam complaints. DATABASE WORKING GROUP - It was agreed that a proposal on the "country:" attribute should be prepared. This will be done by the RIPE NCC. - It was noted that changes to the RIPE Database for abuse are now in production. DNS WORKING GROUP - It was agreed that the DNS Working Group Chair will produce a proposal to solve the problem that changes to reverse DNS nameservers cannot have multiple names. - There was discussion on whether the DNS Working Group should take over the work to produce a RIPE Document on AAAA resolution issues. - It was agreed that the RIPE NCC will produce statistics on anycast placement for K-root and the RIPE region Hostcount in time for RIPE 51. - It was noted that DNSSEC RFCs have been published, and that DNSSEC is being tested in Sweden in the .se domain. EIX WORKING GROUP - It was noted that the Switching Wish-List Version 3.0 will be published soon by Mike Hughes, and that version 3.1 will be published after RIPE 51. - There was discussion about public versus private peering. ENUM WORKING GROUP - It was agreed that Niall O'Reilly and Carsten Schiefner will be the new ENUM Working Group Chairs. - It was noted that the IETF is continuing work on ENUM standards. - It was agreed that the ENUM Working Group will continue to work as it has in the past, with an emphasis on the exchange of operational experience. IPV6 WORKING GROUP - It was decided that the RIPE Whois Database will continue to include more services that run in native IPv6. - It was agreed that the community needs to produce a revised Internet draft before RIPE 51 to formally address the demands of RFC3177, particularly the /48 recommendation. - It was noted that the IPv6 Working Group needs to decide where it wishes to house the new, operational IPv6 mailing list. RIPE NCC SERVICES WORKING GROUP - There was discussion on the value of the Hostcount. It was agreed that the RIPE NCC should continue working on this, and that the RIPE NCC should write and put a new Hostcount into service. ROUTING WORKING GROUP - There was discussion on route flap damping and de-aggregation practices raised by Philip Smith in the RIPE 50 Plenary. - Lorenzo Colliti (RIPE NCC) presented the research work of Roma Tre University on active BGP probing to discover AS level topology of the Internet. TEST TRAFFIC WORKING GROUP - It was agreed that the community should provide a proposal on how TTM infrastructure could be used to certify the quality of service provided by ISPs and to verify Service Level Agreements. - Henk Uijterwaal gave an update on the status of the TTM project - Thomas Wana presented work done to improve the accuracy of TTM time measurements and a proposal to create even greater accuracy by using DAG cards for measurement. - There was discussion on the future directions for the TTM project and it was agreed that the TTM infrastructure and measurements could be leveraged to certify the quality of service provided by ISPs. The Working Group agreed that the RIPE NCC, as a trusted third party, could perform the measurements and publish the results. CO-LOCATED PEERING BoF Netnod, LINX and AMS-IX hosted a peering BoF co-located at RIPE 50 on Sunday, 1 May, where peering policies were presented. CO-LOCATED LOBSTER TUTORIAL A tutorial entitled "Passive Network Traffic Monitoring" was organised on Friday, 6 May, by the consortium of LOBSTER, a European IST Project on Large-Scale Monitoring of Broadband Internet Infrastructures. RIPE 50 WEBCASTING AND ARCHIVES During RIPE 50, the RIPE NCC collected feedback from participants watching the webcast and listening to the audiocasts. The mediums used for this were IRC and Jabber. Archives of presentations, webcasts and IRC/Jabber feedback from RIPE 50 are available at: http://www.ripe.net/ripe/meetings/ripe-50/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) The RIPE NCC Hostmaster Consultation Centre was open at RIPE 50, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. "MEET & GREET" The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 50. "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 . RIPE 50 REFERENCE PAGE A complete list of RIPE 50 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-50 RIPE 51 RIPE 51 will be held in Amsterdam, the Netherlands from 10 - 14 October 2005. Information on RIPE 51 is available at: http://www.ripe.net/ripe/meetings/ripe-51 If you have any questions about RIPE Meetings, please contact . From david.kessens at nokia.com Wed May 25 00:52:00 2005 From: david.kessens at nokia.com (David Kessens) Date: Tue, 24 May 2005 15:52:00 -0700 Subject: [address-policy-wg] RIPE 50 Report In-Reply-To: <5.2.1.1.2.20050524134842.0402ae48@mailhost.ripe.net> References: <5.2.1.1.2.20050524134842.0402ae48@mailhost.ripe.net> Message-ID: <20050524225200.GB7177@nokia.com> Nick, I just sent a mail to the ipv6 wg list with some comments on this summary. I am going to cause some duplication with that other mail, but I believe it is important to keep the record straight. Please follow up on the ipv6 wg mailing list only to avoid further duplication. On Tue, May 24, 2005 at 02:09:07PM +0200, Nick Hyrka wrote: > > IPV6 WORKING GROUP > > - It was decided that the RIPE Whois Database will continue to include more > services that run in native IPv6. We did not make such a decision. We as the working group have no authority to tell the RIPE NCC what to do or not to do. At best we can recommend to the RIPE NCC to take a certain approach and this approach will in general be followed if there is no/little funding required, or otherwise, *if* the RIPE NCC membership agrees on funding such work. We discussed the issue and some people expressed their opinion that we want more than just a proxy service but we did not formally adopted a recommendation (since nobody asked to formally adopt such a recommendation). I am personally glad to hear that the RIPE NCC decided to make the mirroring service available in ipv6 though! Also, I appreciate that we don't have to formally adopt such recommendations as I think it makes for a much better working relationship where the RIPE NCC takes the initiative and picks up on ideas and discussions that happen in the working group without having to formally request the RIPE NCC to do so (policy issues are obviously a completely different matter!). > - It was agreed that the community needs to produce a revised Internet > draft before RIPE 51 to formally address the demands of RFC3177, > particularly the /48 recommendation. This is not what was agreed. It was agreed that it would be useful if an internet draft would be written that potentially could update rfc 3177. We did not discuss a specific timeline (but I don't think anybody would object if it would happen rather sooner than later). In addition, the text 'to formally address the demands of RFC3177' doesn't make any sense to me. I have no idea what that means as rfc 3177 didn't contain any demands. It was expressed by many that the /48 recommendation in rfc 3177 is perhaps a bit too generous and that this could potentially be addressed by adding another category smaller than a /48. However, we started the discussion to make it very clear that we were not going to make decisions during this meeting. It was solely intended to test the waters and get some general idea where people stand at this point in time. In addition, the discussion provided useful input so that a first draft would not be way out of line with current thinking of the RIPE community. > - It was noted that the IPv6 Working Group needs to decide where it wishes > to house the new, operational IPv6 mailing list. Again, the working group didn't decide this. It was brought up that a new mailing list was formed and we received several comments on this topic. Among others that it might not be ideal to have such a list being run by an enthiustic individual as it is important to keep mailarchives preserved even if the individual moves on to pursue other interests. However, this was a comment from the audience, not a decision by the working group. In relation to this topic, I just noticed that the working group website page now mentions: > There is also a global mailing list (not regional RIR/NOG) dedicated > to operational matters of the global IPv6 (production, not 6BONE) > Internet at: > > http://lists.cluenet.de/mailman/listinfo/ipv6-ops/ > > If you are taking part in IPv6 BGP or are interested in global IPv6 > operational matters, please join the list. The purpose is to foster > exchange of experience and resolve problems which require non-local > coordination. The list is also available to discuss problems people > face while deploying IPv6. I did not request the RIPE NCC to put this information on the website neither did the working group endorse this mailing list in any form or way. David Kessens ipv6 wg chair ---