From mpls_buchaill at zen.co.uk Thu May 19 13:21:20 2005 From: mpls_buchaill at zen.co.uk (Damien - MPLS Buchaill) Date: Thu, 19 May 2005 12:21:20 +0100 Subject: [ncc-services-wg] Application Policy Message-ID: Hi Guys, Can someone advise, when submitting an application, do RIPE encourage/ expect use of RFC1918 on internal links? I don't really want to kick off a debate on the rights and wrongs of using RFC1918 ! Just wondering is there an expectation to go down this route to conserve on address, or do RIPE assume you will use registered and allocate accordingly? Thank in advance Damien. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dr at cluenet.de Thu May 19 13:25:40 2005 From: dr at cluenet.de (Daniel Roesen) Date: Thu, 19 May 2005 13:25:40 +0200 Subject: [ncc-services-wg] Application Policy In-Reply-To: References: Message-ID: <20050519112540.GA25888@srv01.cluenet.de> Hi, On Thu, May 19, 2005 at 12:21:20PM +0100, Damien - MPLS Buchaill wrote: > Can someone advise, when submitting an application, do RIPE encourage/ > expect use of RFC1918 on internal links? Neither. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From gert at space.net Thu May 19 14:02:23 2005 From: gert at space.net (Gert Doering) Date: Thu, 19 May 2005 14:02:23 +0200 Subject: [ncc-services-wg] Application Policy In-Reply-To: References: Message-ID: <20050519120223.GM84850@Space.Net> Hi, On Thu, May 19, 2005 at 12:21:20PM +0100, Damien - MPLS Buchaill wrote: > Can someone advise, when submitting an application, do RIPE encourage/ > expect use of RFC1918 on internal links? > > I don't really want to kick off a debate on the rights and wrongs of using > RFC1918 ! Just wondering is there an expectation to go down this route to > conserve on address, or do RIPE assume you will use registered and allocate > accordingly? (Nitpicking: "RIPE" doesn't specifically do anything - "RIPE" is all of us, and what "we" want or do not want is written down in the policy documents. The RIPE NCC hostmasters enforce the policy that the community has agreed upon. If I write "RIPE" below, keep that in mind.) RIPE will not mandate RFC violations - and using RFC1918 space on links that generate externally-visible RFC1918-sourced packets (in response to traceroute, ICMP host unreachable, etc.) is *definitely* a RFC violation. If this is behind a NAT anyway, RIPE doesn't care. To make sure that this is not misunderstood: RIPE does *not* mandate the use of address translation and private/RFC1918 IPs. It is assumed that applicants have *considered* whether this might solve their address space needs, and if it doesn't (any reason, including "I don't want that" is ok!), RIPE has no problem with handing out official IP addresses. No matter how "important" or "unimportant" the hosts might be - one host warrants one uniqe IP address (at least). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 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: [ncc-services-wg] 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: [ncc-services-wg] Re: [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 ---