From hank at mail.iucc.ac.il Tue Oct 12 09:06:07 2004 From: hank at mail.iucc.ac.il (Hank Nussbacher) Date: Tue, 12 Oct 2004 09:06:07 +0200 Subject: [ncc-services-wg] ASN request and org object Message-ID: <5.1.0.14.2.20041012090137.00ae8370@max.att.net.il> I recently requested a new ASN and was asked to submit an org object for the new ASN. When I looked at the v1.1 of the ASN request form at: http://www.ripe.net/ripe/docs/asnrequestform.html it lists the org object as optional and not mandatory. So I asked why it was requested? The response I got was: >The "org" line is optional in the RIPE DB; this is new attribute which was >introduced short time ago and it's absent in most objects. > >However we think it is important to know which company an ASN is assigned to >and this is why we are asking to create this object for every new >registration. If this is the case then I think the ASN request form should be updated to reflect that org is now mandatory and not optional. Regards, Hank From leo at ripe.net Tue Oct 12 09:39:15 2004 From: leo at ripe.net (leo vegoda) Date: Tue, 12 Oct 2004 09:39:15 +0200 Subject: [ncc-services-wg] ASN request and org object In-Reply-To: <5.1.0.14.2.20041012090137.00ae8370@max.att.net.il> Message-ID: <5.2.1.1.2.20041012093249.00b10b70@mailhost.ripe.net> Hi Hank, At 09:06 AM 10/12/2004 +0200, Hank Nussbacher wrote: [...] >>The "org" line is optional in the RIPE DB; this is new attribute which was >>introduced short time ago and it's absent in most objects. >> >>However we think it is important to know which company an ASN is assigned to >>and this is why we are asking to create this object for every new >>registration. > >If this is the case then I think the ASN request form should be updated to >reflect that org is now mandatory and not optional. You're right. The template shows the "org:" attribute as optional because it is not mandatory in the database. This is similar to the situation for "import:" and "export:" attributes. We have this comment in the form for those lines: % Please also note that although "import:" and "export:" % attributes for an "aut-num" object are optional in terms % of database software, they are mandatory in terms of RIPE % policies. This ensures that the AS Number requested is to % be multi-homed. We'll add something similar for "org:" lines when we next update the form. Thanks for the input. Best regards, -- leo vegoda Registration Services Manager RIPE NCC From leo at ripe.net Tue Oct 12 10:56:36 2004 From: leo at ripe.net (leo vegoda) Date: Tue, 12 Oct 2004 10:56:36 +0200 Subject: [ncc-services-wg] ASN request and org object In-Reply-To: <5.1.0.14.2.20041012090137.00ae8370@max.att.net.il> References: <5.1.0.14.2.20041012090137.00ae8370@max.att.net.il> Message-ID: <20041012085612.GA4086@ripe.net> Hi Hank, On Tue, Oct 12, 2004 at 09:06:07AM +0200, Hank Nussbacher wrote: [...] > >The "org" line is optional in the RIPE DB; this is new attribute which was > >introduced short time ago and it's absent in most objects. > > > >However we think it is important to know which company an ASN is assigned > >to > >and this is why we are asking to create this object for every new > >registration. > > If this is the case then I think the ASN request form should be updated to > reflect that org is now mandatory and not optional. Youu're right. The template shows the "org:" attribute as optional because it is not mandatory in the database. This is similar to the situation for "import:" and "export:" attributes. We have this comment in the form for those lines: % Please also note that although "import:" and "export:" % attributes for an "aut-num" object are optional in terms % of database software, they are mandatory in terms of RIPE % policies. This ensures that the AS Number requested is to % be multi-homed. We'll add something similar for "org:" lines when we next update the form. Thanks for the input. Regards, -- leo vegoda Registration Services Manager RIPE NCC From denis at ripe.net Wed Oct 13 18:38:12 2004 From: denis at ripe.net (Denis Walker) Date: Wed, 13 Oct 2004 18:38:12 +0200 Subject: [ncc-services-wg] Recent Database update changes Message-ID: <416D59F4.8060709@ripe.net> [ Apologies for duplicate messages ] Dear Colleagues, In preparation of a new release of the Whois software we have fixed several bugs and implemented some of the simple features asked for over the last few months for the update program, dbupdate. A brief description follows of the features implemented. 1) Change to the overall result of a mail update message. During the re-structuring of the dbupdate program we changed the way we report the overall result of a mail update. This caused some confusion and we have now returned to the behaviour of the previous version of dbupdate. To make this clear here are the outcomes we now report: A blank update message - FAILED: ANY object update failed - FAILED: Otherwise - SUCCESS: 2) Handling of keywords in the Subject: line of a mail update. Currently there are only two keywords used by dbupdate. These are NEW and HELP (HOWTO is also valid but taken to mean the same as HELP). NEW forces all objects found in the mail message to be treated as a creation request. Any object that already exists will result in an error. HELP returns help text. To use a keyword it has to be put in the Subject: line of the mail message, with NO other words present. If any other word is found for example Subject: NEW objects then none of the words are actioned as keywords and they are all reported in the acknowledgement reply as invalid keywords. In this context it is impossible for dbupdate to know if a word is a keyword. As many users often include their own reference in the Subject: line it means it is impossible for them to also use a keyword and they always get their references reported in the Warning messages af the acknowledgement. To overcome these problems we have introduced a KEYWORDS: tag. When this tag is found in a Subject: line all text up to and including this KEYWORDS: tag is ignored by dbupdate. Only what follows this tag is checked for valid keywords. The same rules apply as before. If a word is found after the KEYWORDS: tag that is not a valid keyword none of the words are actioned as keywords. In this case all the words following the KEYWORDS: tag are reported as invalid keywords in the acknowledgement reply. Adding the KEYWORDS: tag at the end of a Subject: line means that valid keywords can still be used with a users reference in the same line. By adding the KEYWORDS: tag at the end of the Subject: line with no keywords following it means that the users reference will not be reported as invalid keywords. The default behaviour is unaltered. A keyword can still be placed on a line with no other words and actioned. We could easily make another change, if users would prefer it, so that keywords will ONLY be accepted if they follow the KEYWORDS: tag. This would make the default behaviour ignore the whole Subject: line and not report any of it as errors if the KEYWORDS: tag is not found. This default behaviour may be more appropriate to the way the Subject: line is currently used in most cases. Please let us know if this is preferred. All keywords and the KEYWORDS: tag are case insensitive. 3) Differnce in notification messages We have been asked to highlight changes in the notification message between the old and new objects for a modification operation. This is particularly useful when "import:" and "export:" attributes are changed in large AUT-NUM objects. This has now been implemented as a selectable option. To request it the user includes the keyword DIFF. When this DIFF keyword is used each object in the notification message that is a modify operation will include a difference before the standard output of the old and new versions of the objects. So the output will have the difference listing followed by the old and new objects. For example, a new subject line may look like this Subject: changes to aut-num: as1234 KEYWORDS: DIFF The difference is the standard unix diff, but with one slight change. In our acknowledgement and notification messages we have used three dashes --- followed by a new line to signify the start of a section relating to an object. This is to make it easy to parse the output and find the start of each object in the message. Unfortunately diff also uses --- to seperate lines that have changed. So we have had to replace --- with === in the diff output. If the DIFF keyword is not used the output remains unchanged. Using a simple PERSON object as the example the new output is as follows: --- OBJECT BELOW MODIFIED: Differences in [person] TP10-DB-TEST 7c7,8 < notify: case040-1 at ripe.net === > changed: dbtest at ripe.net 20040101 > notify: case040-2 at ripe.net person: Test Person address: Singel 258 address: Amsterdam phone: +31 20 535 4444 nic-hdl: TP10-DB-TEST changed: dbtest at ripe.net 20020101 notify: case040-1 at ripe.net source: DB-TEST REPLACED BY: person: Test Person address: Singel 258 address: Amsterdam phone: +31 20 535 4444 nic-hdl: TP10-DB-TEST changed: dbtest at ripe.net 20020101 changed: dbtest at ripe.net 20040101 notify: case040-2 at ripe.net source: DB-TEST 4) Include person/role name in creation results. The last additional feature is to include the name of a PERSON or ROLE object in the acknowledgement output after a successful creation. Previously only the new nic-hdl was listed. For example, if two PERSON objects are created using AUTO- nic-hdls for Denis Walker and David Wilkinson the reply would only say DW23-RIPE and DW24-RIPE have been created. The user would then have to do a whois lookup to determine which was which. The reply now states: --- Create SUCCEEDED: [person] DW23-DB-TEST Denis Walker --- Create SUCCEEDED: [person] DW24-DB-TEST David Wilkinson Regards Denis Walker RIPE NCC Software Engineering Department. From marko.veelma at data.ee Wed Oct 13 19:23:35 2004 From: marko.veelma at data.ee (Marko Veelma) Date: Wed, 13 Oct 2004 20:23:35 +0300 (EEST) Subject: [ncc-services-wg] Recent Database update changes In-Reply-To: <416D59F4.8060709@ripe.net> References: <416D59F4.8060709@ripe.net> Message-ID: On Wed, 13 Oct 2004, Denis Walker wrote: > 2) Handling of keywords in the Subject: line of a mail update. > /----/ > > We could easily make another change, if users would prefer it, so that > keywords will ONLY be accepted if they follow the KEYWORDS: tag. This would > make the default behaviour ignore the whole Subject: line and not report any > of it as errors if the KEYWORDS: tag is not found. This default behaviour may > be more appropriate to the way the Subject: line is currently used in most > cases. Please let us know if this is preferred. I prefer the second option. We don't need these keywords very often but always use own keywords (ticket number, action, object name) so that reply from RIPE can be merged directly to ticketing system > 3) Differnce in notification messages I'd like to have an option to get unified diff. The context length might be even so big that you get full object together. Something like this: person: Test Person address: Singel 258 address: Amsterdam phone: +31 20 535 4444 nic-hdl: TP10-DB-TEST changed: dbtest at ripe.net 20020101 -notify: case040-1 at ripe.net +changed: dbtest at ripe.net 20040101 +notify: case040-2 at ripe.net source: DB-TEST Without any context it is anyway hard to understand the diff output sepcially in aut-num object where import and export entries may have more than one line. If you don't change the first line then you may loose the context and diff like this doesn't give you any information about what peer was actually changed. < accept ANY === > accept ANY AND NOT {0.0.0.0/0} -- Cougar Data Telecom O? Marko Veelma Laki 11B, 12915 Tallinn marko.veelma at data.ee Phone +372 881 0299 data telecom Phone +372 881 0289 Fax +372 654 2942 -------------- GSM +372 50 92042 From ncc at ripe.net Mon Oct 18 13:39:14 2004 From: ncc at ripe.net (Nick Hyrka) Date: Mon, 18 Oct 2004 13:39:14 +0200 Subject: [ncc-services-wg] RIPE 49 Meeting Report Message-ID: <5.2.1.1.2.20041018133513.042f04f8@mailhost.ripe.net> [Apologies for duplicate mails.] RIPE 49 MEETING REPORT Dear Colleagues, The RIPE 49 Meeting was held from 20 - 24 September 2004 at the Renaissance Hotel, Manchester, United Kingdom. There were 301 participants at the meeting. Attendees also included government representatives and representatives from AfriNIC, APNIC, ARIN, LACNIC and ICANN. HIGHLIGHTS Highlights of RIPE 49 included an update on the Number Resource Organization from Axel Pawlik, Managing Director, RIPE NCC; a discussion on the RIPE policy development process; a proposal to restructure RIPE Meetings into three days on operational/technical content followed by two days on policy related issues. The ASO held an election for a seat on the ASO Address Council. Hans Petter Holen was re-elected. Geoff Huston, APNIC, gave a report on the routing table status for IPv4 and IPv6. This presentation is available at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-plenary-bgp.pdf The European Operators Forum (EOF) featured presentations on peering and core network security. EOF presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/eof.html The RIPE NCC, LINX, TeleCity, Telecomplete and XChange Point Europe are thanked for the support they provided to the meeting. BT Net are thanked for the excellent provision of the meeting Internet connectivity. SUMMARY ADDRESS POLICY WORKING GROUP - It was agreed that IPv6 allocations from IANA to the RIRs had to be increased in terms of block size, and that /12 was the best allocation size to use. - RIPE Chair, Rob Blokzijl, announced that he would publish a draft of the policy development process for the RIPE region. - There was discussion on the usage of HD ratio for IPv4 and the forthcoming formal proposal regarding this. - The 200 End Users requirement for receiving an IPv6 allocation was discussed and it was agreed that a formal proposal to remove it should be sent to the community. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ap DATABASE WORKING GROUP - It was agreed that the RIPE NCC should implement the 'abuse-c:' attribute in the 'irt', 'person', 'role' and 'inet[6]num' object classes. - It was agreed that the RIPE NCC should implement the 'poem' object in the RIPE Database. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#db TEST TRAFFIC MEASUREMENT (TTM) WORKING GROUP - It was noted that ten test boxes, throughout the RIPE region, have been added to the RIPE NCC Test Traffic Measurements matrix in 2004. Test Traffic Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#tt ANTI-SPAM WORKING GROUP - A tutorial on message headers was given by Rodney Tillotson, Working Group Chair. - The group discussed the issue of improving the RIPE Database for abuse contacts. There was a majority support for a combination of 'irt' objects with some modifications, and for changes to the default Whois behaviour. Anti-Spam Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#anti-spam IPv6 WORKING GROUP - The RIPE NCC announced that K-root has been IPv6-enabled since August 2004. - Geoff Huston, APNIC, gave an update on multihoming in IPv6. - There was discussion about IPv6 glue for root name servers. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ipv6 EIX WORKING GROUP - It was noted that the switching wish list is in last call and that the final review will take place at the Euro-IX meeting in Athens (October 2004). - It was noted that an Inter Providers Traffic Analyzer tool is available from the Milan Internet Exchange. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#eix ENUM WORKING GROUP - There was a presentation from the United Kingdom's Department of Trade and Industry (DTI) on an ENUM Consultation regarding how ENUM should be operated in the UK. - There was a presentation on ENUM deployment in Sweden. ENUM Working Group Presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#enum DNS WORKING GROUP - It was agreed that the DNS Working Group should take up responsibility for documenting the issues around DNS server migration. - It was noted that the DNS Working Group Chair would collect requirements for the DNS samples and statistics. - It was noted that the DNS Working Group Chair would coordinate the production of a RIPE Document based on Fernando Garcia's DNS Server Migration document. DNS Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#dns ROUTING WORKING GROUP - It was announced that the maintenance of the IRR Toolset has been transferred from the RIPE NCC to the Internet Systems Consortium (ISC). - There was discussion on securing the network through hiding the core. - There was an overview of the RIS project and discussion on the various uses of the myASn BGP monitoring tool. Routing Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#routing RIPE NCC SERVICES WORKING GROUP - It was agreed that the RIPE Chair would look at the possibilities of reworking the framework of RIPE meetings, so that operational content would come at the beginning of the meeting week and policy discussions would come at the end of the week. - It was agreed that the RIPE NCC would generate statistics on the quantity of spam on the RIPE NCC servers. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ncc-services 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-49/lir-course/index.html RIPE 49 WEBCASTING AND ARCHIVES During RIPE 49, 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 49 are available at: http://www.ripe.net/ripe/meetings/ripe-49/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) The RIPE NCC Hostmaster Consultation Centre was open at RIPE 49, 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 49. "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 49 REFERENCE PAGE A complete list of RIPE 49 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-49/index.html RIPE 50 RIPE 50 will be held in Stockholm, Sweden from 2 - 6 May 2005. Information on RIPE 50 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-50/ If you have any questions about RIPE Meetings, please contact . -- end -- From ncc at ripe.net Mon Oct 18 13:39:14 2004 From: ncc at ripe.net (Nick Hyrka) Date: Mon, 18 Oct 2004 13:39:14 +0200 Subject: [ncc-services-wg] [address-policy-wg] RIPE 49 Meeting Report Message-ID: <5.2.1.1.2.20041018133513.042f04f8@mailhost.ripe.net> [Apologies for duplicate mails.] RIPE 49 MEETING REPORT Dear Colleagues, The RIPE 49 Meeting was held from 20 - 24 September 2004 at the Renaissance Hotel, Manchester, United Kingdom. There were 301 participants at the meeting. Attendees also included government representatives and representatives from AfriNIC, APNIC, ARIN, LACNIC and ICANN. HIGHLIGHTS Highlights of RIPE 49 included an update on the Number Resource Organization from Axel Pawlik, Managing Director, RIPE NCC; a discussion on the RIPE policy development process; a proposal to restructure RIPE Meetings into three days on operational/technical content followed by two days on policy related issues. The ASO held an election for a seat on the ASO Address Council. Hans Petter Holen was re-elected. Geoff Huston, APNIC, gave a report on the routing table status for IPv4 and IPv6. This presentation is available at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-plenary-bgp.pdf The European Operators Forum (EOF) featured presentations on peering and core network security. EOF presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/eof.html The RIPE NCC, LINX, TeleCity, Telecomplete and XChange Point Europe are thanked for the support they provided to the meeting. BT Net are thanked for the excellent provision of the meeting Internet connectivity. SUMMARY ADDRESS POLICY WORKING GROUP - It was agreed that IPv6 allocations from IANA to the RIRs had to be increased in terms of block size, and that /12 was the best allocation size to use. - RIPE Chair, Rob Blokzijl, announced that he would publish a draft of the policy development process for the RIPE region. - There was discussion on the usage of HD ratio for IPv4 and the forthcoming formal proposal regarding this. - The 200 End Users requirement for receiving an IPv6 allocation was discussed and it was agreed that a formal proposal to remove it should be sent to the community. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ap DATABASE WORKING GROUP - It was agreed that the RIPE NCC should implement the 'abuse-c:' attribute in the 'irt', 'person', 'role' and 'inet[6]num' object classes. - It was agreed that the RIPE NCC should implement the 'poem' object in the RIPE Database. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#db TEST TRAFFIC MEASUREMENT (TTM) WORKING GROUP - It was noted that ten test boxes, throughout the RIPE region, have been added to the RIPE NCC Test Traffic Measurements matrix in 2004. Test Traffic Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#tt ANTI-SPAM WORKING GROUP - A tutorial on message headers was given by Rodney Tillotson, Working Group Chair. - The group discussed the issue of improving the RIPE Database for abuse contacts. There was a majority support for a combination of 'irt' objects with some modifications, and for changes to the default Whois behaviour. Anti-Spam Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#anti-spam IPv6 WORKING GROUP - The RIPE NCC announced that K-root has been IPv6-enabled since August 2004. - Geoff Huston, APNIC, gave an update on multihoming in IPv6. - There was discussion about IPv6 glue for root name servers. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ipv6 EIX WORKING GROUP - It was noted that the switching wish list is in last call and that the final review will take place at the Euro-IX meeting in Athens (October 2004). - It was noted that an Inter Providers Traffic Analyzer tool is available from the Milan Internet Exchange. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#eix ENUM WORKING GROUP - There was a presentation from the United Kingdom's Department of Trade and Industry (DTI) on an ENUM Consultation regarding how ENUM should be operated in the UK. - There was a presentation on ENUM deployment in Sweden. ENUM Working Group Presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#enum DNS WORKING GROUP - It was agreed that the DNS Working Group should take up responsibility for documenting the issues around DNS server migration. - It was noted that the DNS Working Group Chair would collect requirements for the DNS samples and statistics. - It was noted that the DNS Working Group Chair would coordinate the production of a RIPE Document based on Fernando Garcia's DNS Server Migration document. DNS Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#dns ROUTING WORKING GROUP - It was announced that the maintenance of the IRR Toolset has been transferred from the RIPE NCC to the Internet Systems Consortium (ISC). - There was discussion on securing the network through hiding the core. - There was an overview of the RIS project and discussion on the various uses of the myASn BGP monitoring tool. Routing Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#routing RIPE NCC SERVICES WORKING GROUP - It was agreed that the RIPE Chair would look at the possibilities of reworking the framework of RIPE meetings, so that operational content would come at the beginning of the meeting week and policy discussions would come at the end of the week. - It was agreed that the RIPE NCC would generate statistics on the quantity of spam on the RIPE NCC servers. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ncc-services 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-49/lir-course/index.html RIPE 49 WEBCASTING AND ARCHIVES During RIPE 49, 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 49 are available at: http://www.ripe.net/ripe/meetings/ripe-49/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) The RIPE NCC Hostmaster Consultation Centre was open at RIPE 49, 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 49. "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 49 REFERENCE PAGE A complete list of RIPE 49 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-49/index.html RIPE 50 RIPE 50 will be held in Stockholm, Sweden from 2 - 6 May 2005. Information on RIPE 50 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-50/ If you have any questions about RIPE Meetings, please contact . -- end -- From ncc at ripe.net Mon Oct 18 13:39:14 2004 From: ncc at ripe.net (Nick Hyrka) Date: Mon, 18 Oct 2004 13:39:14 +0200 Subject: [ncc-services-wg] [local-ir@ripe.net]RIPE 49 Meeting Report Message-ID: <5.2.1.1.2.20041018133513.042f04f8@mailhost.ripe.net> [Apologies for duplicate mails.] RIPE 49 MEETING REPORT Dear Colleagues, The RIPE 49 Meeting was held from 20 - 24 September 2004 at the Renaissance Hotel, Manchester, United Kingdom. There were 301 participants at the meeting. Attendees also included government representatives and representatives from AfriNIC, APNIC, ARIN, LACNIC and ICANN. HIGHLIGHTS Highlights of RIPE 49 included an update on the Number Resource Organization from Axel Pawlik, Managing Director, RIPE NCC; a discussion on the RIPE policy development process; a proposal to restructure RIPE Meetings into three days on operational/technical content followed by two days on policy related issues. The ASO held an election for a seat on the ASO Address Council. Hans Petter Holen was re-elected. Geoff Huston, APNIC, gave a report on the routing table status for IPv4 and IPv6. This presentation is available at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-plenary-bgp.pdf The European Operators Forum (EOF) featured presentations on peering and core network security. EOF presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/eof.html The RIPE NCC, LINX, TeleCity, Telecomplete and XChange Point Europe are thanked for the support they provided to the meeting. BT Net are thanked for the excellent provision of the meeting Internet connectivity. SUMMARY ADDRESS POLICY WORKING GROUP - It was agreed that IPv6 allocations from IANA to the RIRs had to be increased in terms of block size, and that /12 was the best allocation size to use. - RIPE Chair, Rob Blokzijl, announced that he would publish a draft of the policy development process for the RIPE region. - There was discussion on the usage of HD ratio for IPv4 and the forthcoming formal proposal regarding this. - The 200 End Users requirement for receiving an IPv6 allocation was discussed and it was agreed that a formal proposal to remove it should be sent to the community. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ap DATABASE WORKING GROUP - It was agreed that the RIPE NCC should implement the 'abuse-c:' attribute in the 'irt', 'person', 'role' and 'inet[6]num' object classes. - It was agreed that the RIPE NCC should implement the 'poem' object in the RIPE Database. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#db TEST TRAFFIC MEASUREMENT (TTM) WORKING GROUP - It was noted that ten test boxes, throughout the RIPE region, have been added to the RIPE NCC Test Traffic Measurements matrix in 2004. Test Traffic Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#tt ANTI-SPAM WORKING GROUP - A tutorial on message headers was given by Rodney Tillotson, Working Group Chair. - The group discussed the issue of improving the RIPE Database for abuse contacts. There was a majority support for a combination of 'irt' objects with some modifications, and for changes to the default Whois behaviour. Anti-Spam Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#anti-spam IPv6 WORKING GROUP - The RIPE NCC announced that K-root has been IPv6-enabled since August 2004. - Geoff Huston, APNIC, gave an update on multihoming in IPv6. - There was discussion about IPv6 glue for root name servers. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ipv6 EIX WORKING GROUP - It was noted that the switching wish list is in last call and that the final review will take place at the Euro-IX meeting in Athens (October 2004). - It was noted that an Inter Providers Traffic Analyzer tool is available from the Milan Internet Exchange. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#eix ENUM WORKING GROUP - There was a presentation from the United Kingdom's Department of Trade and Industry (DTI) on an ENUM Consultation regarding how ENUM should be operated in the UK. - There was a presentation on ENUM deployment in Sweden. ENUM Working Group Presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#enum DNS WORKING GROUP - It was agreed that the DNS Working Group should take up responsibility for documenting the issues around DNS server migration. - It was noted that the DNS Working Group Chair would collect requirements for the DNS samples and statistics. - It was noted that the DNS Working Group Chair would coordinate the production of a RIPE Document based on Fernando Garcia's DNS Server Migration document. DNS Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#dns ROUTING WORKING GROUP - It was announced that the maintenance of the IRR Toolset has been transferred from the RIPE NCC to the Internet Systems Consortium (ISC). - There was discussion on securing the network through hiding the core. - There was an overview of the RIS project and discussion on the various uses of the myASn BGP monitoring tool. Routing Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#routing RIPE NCC SERVICES WORKING GROUP - It was agreed that the RIPE Chair would look at the possibilities of reworking the framework of RIPE meetings, so that operational content would come at the beginning of the meeting week and policy discussions would come at the end of the week. - It was agreed that the RIPE NCC would generate statistics on the quantity of spam on the RIPE NCC servers. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-49/presentations/index.html#ncc-services 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-49/lir-course/index.html RIPE 49 WEBCASTING AND ARCHIVES During RIPE 49, 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 49 are available at: http://www.ripe.net/ripe/meetings/ripe-49/sessions-archive.html HOSTMASTER CONSULTATION CENTRE (HCC) The RIPE NCC Hostmaster Consultation Centre was open at RIPE 49, 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 49. "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 49 REFERENCE PAGE A complete list of RIPE 49 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-49/index.html RIPE 50 RIPE 50 will be held in Stockholm, Sweden from 2 - 6 May 2005. Information on RIPE 50 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-50/ If you have any questions about RIPE Meetings, please contact . -- end -- From leo at ripe.net Thu Oct 28 15:49:20 2004 From: leo at ripe.net (leo vegoda) Date: Thu, 28 Oct 2004 15:49:20 +0200 Subject: [ncc-services-wg] IPv4 policy document and request forms updated Message-ID: <2B00253A-28E8-11D9-86EA-000A95DAB530@ripe.net> Dear Colleagues, The RIPE NCC has updated the policy document, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". This update documents the recent changes to the policy for allocation sizes as follows: - Minimum first allocation size is /21. - Minimum first allocation size for LIRs operating in Africa is /22. As a consequence of this update, and in order to incorporate other input, we have also updated the following documents: - Supporting Notes for the Provider Independent (PI) Assignment Request Form. - Provider Independent (PI) Assignment Request Form. - Supporting Notes for the IPv4 First Allocation Request Form. - Supporting Notes for the Autonomous System Number Request Form. - AS Number Request Form. There will be no change to the way you complete the request forms. As the updates to the forms listed above are purely textual, the version number of the forms will not change. Kind regards, -- leo vegoda Registration Services Manager RIPE NCC From kurtis at kurtis.pp.se Thu Oct 28 23:12:05 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 28 Oct 2004 23:12:05 +0200 Subject: [ncc-services-wg] Re: [local-ir@ripe.net]IPv4 policy document and request forms updated In-Reply-To: <2B00253A-28E8-11D9-86EA-000A95DAB530@ripe.net> References: <2B00253A-28E8-11D9-86EA-000A95DAB530@ripe.net> Message-ID: <04E1F41D-2926-11D9-BEFF-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Leo, On 2004-10-28, at 15.49, leo vegoda wrote: > Dear Colleagues, > > The RIPE NCC has updated the policy document, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region". This update > documents the recent changes to the policy for allocation sizes as > follows: > > - Minimum first allocation size is /21. > - Minimum first allocation size for LIRs operating in Africa is /22. > > As a consequence of this update, and in order to incorporate other > input, we have also updated the following documents: Wasn't the Africa /22 rule actually for "LIRs that will be migrated to AFriNIC services"? Or don't I remember correctly? Or doesn't that matter? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQYFgraarNKXTPFCVEQIA4QCfXDIVpqu6sgvHVPu9FRNn7Dui1BYAn1jz sUPk5iF2KJTsc1ILcFF2srJk =qc31 -----END PGP SIGNATURE----- From kurtis at kurtis.pp.se Thu Oct 28 23:12:05 2004 From: kurtis at kurtis.pp.se (Kurt Erik Lindqvist) Date: Thu, 28 Oct 2004 23:12:05 +0200 Subject: [ncc-services-wg] [address-policy-wg] Re: [local-ir@ripe.net]IPv4 policy document and request forms updated In-Reply-To: <2B00253A-28E8-11D9-86EA-000A95DAB530@ripe.net> References: <2B00253A-28E8-11D9-86EA-000A95DAB530@ripe.net> Message-ID: <04E1F41D-2926-11D9-BEFF-000A95928574@kurtis.pp.se> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Leo, On 2004-10-28, at 15.49, leo vegoda wrote: > Dear Colleagues, > > The RIPE NCC has updated the policy document, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region". This update > documents the recent changes to the policy for allocation sizes as > follows: > > - Minimum first allocation size is /21. > - Minimum first allocation size for LIRs operating in Africa is /22. > > As a consequence of this update, and in order to incorporate other > input, we have also updated the following documents: Wasn't the Africa /22 rule actually for "LIRs that will be migrated to AFriNIC services"? Or don't I remember correctly? Or doesn't that matter? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQYFgraarNKXTPFCVEQIA4QCfXDIVpqu6sgvHVPu9FRNn7Dui1BYAn1jz sUPk5iF2KJTsc1ILcFF2srJk =qc31 -----END PGP SIGNATURE----- From jwkckid1 at ix.netcom.com Thu Oct 28 23:15:04 2004 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Thu, 28 Oct 2004 14:15:04 -0700 Subject: [ncc-services-wg] Re: [address-policy-wg] IPv4 policy document and request forms updated References: <2B00253A-28E8-11D9-86EA-000A95DAB530@ripe.net> Message-ID: <41816155.6BA156AC@ix.netcom.com> Leo and all, Why would Africa's be different? Is there a rational for that? leo vegoda wrote: > Dear Colleagues, > > The RIPE NCC has updated the policy document, "IPv4 Address Allocation > and Assignment Policies for the RIPE NCC Service Region". This update > documents the recent changes to the policy for allocation sizes as > follows: > > - Minimum first allocation size is /21. > - Minimum first allocation size for LIRs operating in Africa is /22. > > As a consequence of this update, and in order to incorporate other > input, we have also updated the following documents: > > - Supporting Notes for the Provider Independent (PI) Assignment > Request Form. > - Provider Independent (PI) Assignment Request Form. > - Supporting Notes for the IPv4 First Allocation Request Form. > - Supporting Notes for the Autonomous System Number Request Form. > - AS Number Request Form. > > There will be no change to the way you complete the request forms. As > the updates to the forms listed above are purely textual, the version > number of the forms will not change. > > Kind regards, > > -- > leo vegoda > Registration Services Manager > RIPE NCC Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From ruud at ripe.net Fri Oct 29 10:38:40 2004 From: ruud at ripe.net (Ruud de Kooter) Date: Fri, 29 Oct 2004 10:38:40 +0200 Subject: [ncc-services-wg] RIPE NCC Website Downtime Message-ID: <5.2.1.1.2.20041029103652.0328dfe8@localhost> Dear Colleagues, On Thursday, 28th October, between 20:45 and 23:20 CET, the www.ripe.net website was unavailable, due to technical issues. We apologise for any inconvenience that this downtime may have caused to your operations. Regards, RIPE NCC Operations