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

Billing scheme
by postmaster 14 Oct '03

14 Oct '03

Hi There! We are ru.combellga Now I try to update our billing scheme from HALF-YEARLY to QUARTERLY. But I cann't find where can I do it... In our LIR Portal I find this option but it's not allowed to change! Pleace help with any advices -- Best Regards Dmitry N. Dmitrienko Combellga Internet Team (CIT)

1 0

Re: [ncc-services-wg] Reverse DNS Restructuring Project
by Bruce Campbell 08 Oct '03

08 Oct '03

On Wed, 8 Oct 2003, Olaf M. Kolkman wrote: > I agree "Clarity good, Confusion bad". I have not yet had the change > to study all implications of getting rid of the "rev-srv:". But we'll > look at this and get back on this issue; probably in the clean-up proposal > that is to follow or in a separate proposal. In the context of the above I have some additional data that we have extracted from the database. As the wider audience may be aware, the 'rev-srv' attribute in the inetnum (and inet6num) objects is the rather early predecessor of using the 'domain' object and its 'nserver' attributes to represent a reverse delegation. The 'rev-srv' attribute, while it has never been depreciated and is not used as a source for authoritative DNS data, is still able to be used as an informational attribute. For purposes of this discussion, I've compared the contents of the inetnum 'rev-srv' attribute with the domain 'nserver' attribute. For the comparison I also introduce the concept of 'derived delegation'. A 'derived delegation' is essentially working out which 'in-addr.arpa' delegation would best match the inetnum. Effectively, a /15 inetnum becomes two /16-level 'derived delegations', and a /17 inetnum becomes 128 /24-level 'derived delegations'. First the data for reverse delegation information in inetnum objects. Total number of inetnum objects: 879691 Total number of inetnum objects with rev-srv: 54921 (6%) Total number of derived delegations: 27804 (3%) The fact that the number of derived delegations is smaller than the number of objects with rev-srv attributes is accounted for by inetnums which either cover very large ranges (/8 and greater) or smaller ranges (/25 and lesser) which we do not delegate directly. Secondly, the data for reverse delegation information in domain objects. Total number of domain objects: 113153 Total number of valid reverse domain objects: 105785 A valid reverse domain object is one that makes sense within the DNS; it has a set of nservers, and refers to a possible delegation (ie, its within in-addr.arpa and has numbers between 0 and 255). Comparing the two sets of delegation information. Total number of domain objects that do NOT match any derived delegation: 95051 Total number of derived delegations that do NOT match any domain object: 16523 Total number of matches between derived delegations and domain object: 18011 The number of domain objects is larger as the NCC has been using them to represent authoritative reverse delegations during the recent (6 years?) growth period of the internet. The number of derived delegations without a matching domain object is non-zero for two reasons; The statistics script has calculated the 'best' delegation possible, and hasn't taken into account the possibility of a /16 inetnum being delegated to 255 /24-level domain objects (etc), or there are old inetnums which had their corresponding delegations created before the current system of using domain objects. We now compare the 18,011 domain objects that have a matching derived delegation, and cross checking the NS sets (as are intended to be published in the DNS) of each. Total number of mismatches in NS sets: 10734 Total number of exact matches in NS sets: 7277 In summary; - rev-srv attributes are used infrequently at the moment, and the information within them has a low accuracy. - There would be a large cleanup of inetnum objects required to ensure that the rev-srv attributes matched the delegations in the domain objects, and thus be usable for the creation of authoritative DNS delegations. - In the current proposal effort is needed to make sure that "legacy" reverse delegations that do exist in the DNS, have a corresponding rev-srv attribute, but do not have a DOMAIN object in the database, get fixed. -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security

1 0

RIPE NCC Regional Meeting, Middle
by Membership Liason Officer 08 Oct '03

08 Oct '03

East, Dubai, 7-9 December 2003 Message-Id: <20031008155822.0e2b8155.contact(a)ripe.net> Organization: RIPE NCC X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear Colleagues, The RIPE NCC is pleased to announce the RIPE NCC Regional Meeting, Middle East, to be held 7-9 December 2003 at the Metropolitan Palace Hotel, Dubai, U.A.E. Registration for the Regional Meeting opens 8 October 2003. 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/dubai-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? - Root name server operations: who is involved? - Domain Name management on the Internet; - The internationalisation of Domain Names. The Regional Meeting draft agenda can be found at: http://www.ripe.net/ripencc/regional-meetings/dubai-2003/plan.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 Middle East region. The current 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 Middle East. 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. Any further questions about the RIPE NCC Regional Meeting, Middle East can be sent directly to: <contact(a)ripe.net>. Regards, Sabrina Wilmot Membership Liaison Officer RIPE NCC

1 0

Re: [ncc-services-wg] ripe rejecting "valid" e-mail
by Wilfried Woeber, UniVie/ACOnet 08 Oct '03

08 Oct '03

> ... This goes back to my old example of "You must be >registered with your local Chamber of Commerce and send us a copy of the >certificate to join RIPE" arguement. This was changed - but only after many >years. Could you give us an example and/or timeframe for that? I am curious when/how/why an "organisation" (RIPE) - which doesn't have the concept of membership - would request any certificate. Puzzled... Regards, _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Never attribute to malice what can adequately be explained by incompetence.

2 2

ripe rejecting "valid" e-mail
by Peter Galbavy 08 Oct '03

08 Oct '03

I replied, in all innocence, to the recent e-mail from NCC about the change to allocation objects - commenting on how an LIR like me cannot actually update the object themselves. Don't point me to the LIR portal - without a working fax number I cannot get an account. Been there, done that. Anyhow, I get back: -- quote -- The RIPE-NCC hostmaster distribution robot has extracted the following additional information from it: RegID: No valid RegId found Ticket Number: NCC#2003101214 We will NOT handle this message. It is of type NOREGIDBOUNCE. It concerns an ongoing request. -- ... -- Er, when you have a valid ticket number *why the hell* do you need a regID as well ??? Some people really have too much spare time and write too much code that doesn't consider the real world. Anyone else object to the over-babying of inbound mail to the NCC ? The prices stay high, the work they are willing to do goes down. As usual. Peter

7 10

Re: [db-wg] Fw: FAILED:
by Katie Petrusha 06 Oct '03

06 Oct '03

On Sun, Oct 05, 2003 at 10:50:42AM +0100, benhadjira wrote: Dear Mourad, Your update failed because you didn't send any password in your update message. Your maintainer object BM-MNT has CRYPW-PW authentication, therefore the clear text password corresponding to crypt line should be presented when creating/deleting/updating any object protected by this maintainer. Add the line password: your_clear_text_pass to your update message and resend it to auto-dbm(a)ripe.net. You can also use Web interface for updating the RIPE Database: WebUpdates: https://www.ripe.net/perl/webupdates.pl In the future, please report problems/errors/questions to ripe-dbm(a)ripe.net. Katie Petrusha RIPE Database Administration. > Dear sir > > We have tried several times to add inetnum to the data-base, but > unfortunetely this is the error message we received every time . > Could you please give us some help & advices on how to do it ? > > Thanking you in advance > > Mourad > Techni-communication > > -------Original Message------- > > From: ripe-dbm(a)ripe.net > Date: samedi 4 octobre 2003 10:34:28 > To: benhadjira(a)techni-communication.com > Subject: FAILED: > > > > From: benhadjira(a)techni-communication.com > > Subject: > > Date: Sat, 04 Oct 2003 05:34:19 -0400 > > Reply-To: benhadjira(a)techni-communication.com > > Message-ID: <04df532f66b14c6c874ce4e412db3b3d(a)techni-communication.com> > > > SUMMARY OF UPDATE: > > Number of objects found: 1 > Number of objects processed successfully: 0 > Create: 0 > Modify: 0 > Delete: 0 > No Operation: 0 > Number of objects processed with errors: 1 > Create: 1 > Modify: 0 > Delete: 0 > Syntax Errors: 0 > > > DETAILED EXPLANATION: > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The following object(s) were found to have ERRORS: > > > --- > Create FAILED: [inetnum] 217.29.219.0 - 217.29.219.255 > ***Error: Authorisation failed > ***Info: Syntax check passed > > inetnum: 217.29.219.0 - 217.29.219.255 > netname: Techni-communication > descr: Techni-Communication - customer SEI.NET > country: DZ > admin-c: MA1973-ripe > tech-c: BM1974-RIPE > status: LIR-PARTITIONED PA > mnt-by: BM-MNT > mnt-lower: BM-MNT > mnt-routes: TACHYON-EU-MNT > changed: benhadjira(a)techni-communication.com 20031004 > source: RIPE > > ***Info: Authorisation for parent [inetnum] 217.29.208.0 - 217.29.223.255 > using mnt-lower: > not authenticated by: BM-MNT > > ***Info: Authorisation for [inetnum] 217.29.219.0 - 217.29.219.255 > using mnt-by: > not authenticated by: BM-MNT > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > The following paragraph(s) do not look like objects > and were NOT PROCESSED: > > -------------------------------------------------------------------- > mail2web.com - Check your email from the web at http://mail2web.com. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For assistance or clarification please contact: > RIPE Database Administration <ripe-dbm(a)ripe.net> > > > . -- Kind regards, Katje

1 0

Re: [ncc-services-wg] Reverse DNS Restructuring Project
by Olaf Kolkman 02 Oct '03

02 Oct '03

* >Where is Appendix 1? The appendix and the table were removed because I considered it was to much detail for this generic proposal and planned to publish it, after more detailed analysis, with the the forthcoming consistency/cleanup proposal. I forgot to remove the reference to it and did not catch that mistake in the final reviews. The original table, appendix 1, is included below. Apologies for the confusion. --Olaf Kolkman Appendix 1. Inconsistencies between the Zone files and Whois Database in August 2003 NET TOTAL-DNS TOTAL-DB IN-DNS-NOT-DB IN-DB-NOT-DNS NS-MISMATCH 62/8 11775 12083 341 844 296 80/8 5910 6098 98 412 158 81/8 6560 6213 31 106 71 82/8 376 281 4 4 1 188/8 2 1 1 0 1 193/8 5940 6918 1032 1072 353 194/8 7374 6780 1928 1302 477 195/8 14739 15493 1531 2354 1106 212/8 20734 22353 790 2626 1320 213/8 16281 17236 575 1498 480 217/8 6257 6631 109 741 154 TOTAL-DNS: total unique entries in the zone files TOTAL-DB: total entries in database IN-DNS-NOT-DB: missing entries in database IN-DB-NOT-DNS: missing entries in zone files NS-MISMATCH: entries with conflicting name servers Note that in the above table the difference between TOTAL-DNS and TOTAL-DB does not correlate with IN-DNS-NOT-DB, IN-DB-NOT-DNS and/or NS-MISMATCH. The reason is that DOMAIN object that contain syntax errors have not been taken into account in the calculation of IN-DNS-NOT-DB, IN-DB-NOT-DNS and NS-MISMATCH. Further analysis of the syntax errors will be performed as part of the cleanup process.

1 0

Re: [ncc-services-wg] Reverse DNS Restructuring Project
by Nick Hyrka 02 Oct '03

02 Oct '03

Hello Hank. At 20:35 01/10/2003 +0300, Hank Nussbacher wrote: >On Wed, 1 Oct 2003, Olaf M. Kolkman wrote: > > > Currently there is a set of zone files that is the authoritative > > source for the reverse tree. In addition there are DOMAIN objects > > in the database. Appendix 1 shows the number and nature of the > > inconsistencies. > >Where is Appendix 1? > > > > > The cleanup should not cause existing delegations to change > > i.e. the zone data has prevalence over Whois database information in > > case of inconsistencies. > > > > A somewhat more detailed cleanup plan will be presented to the > > DB-WG mailing list. > >Shouldn't this proposal: >http://www.ripe.net/reverse/proposal.html >be linked into the reverse page at: >http://www.ripe.net/reverse/ Thank you for your kind suggestion. We've relocated the page with a new link as a result of your input. Regards, Nick Hyrka Communications Manager RIPE NCC >-Hank

1 0

RIPE 46 Meeting Report
by Nick Hyrka 02 Oct '03

02 Oct '03

(Apologies for duplicate mails.) RIPE 46 Meeting Report Dear Colleagues: The RIPE 46 Meeting was held from 1 - 5 September 2003 at the Grand Hotel Krasnapolsky, Amsterdam, the Netherlands. There were a total of 307 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 46 included the open discussion on the services of the RIPE NCC during the first session of the RIPE NCC Services Working Group; a presentation on current RIPE NCC services and plans for 2004 by Axel Pawlik, Managing Director, RIPE NCC; an AfriNIC update; and an update on the changes to Test Traffic Measurement. The European Operators Forum (EOF) featured a full-day tutorial on Voice over Internet Protocol (VoIP) and ENUM that included an overview of current technologies and a focus on practical deployment aspects such as gateways, security, provisioning and use of the new ENUM standards. Geoff Huston, Telstra, gave a presentation on IPv4 Address Lifetime Expectancy. The RIPE NCC would like to thank SURFnet, BIT, FLAG Telecom and KPN EuroRings for the support they provided to the meeting. SUMMARY ======== ADDRESS POLICY ============== - Hans Petter Holen, Chair, requested community involvement to help revise ripe-152 ("Charging by Local Internet Registries") if necessary. - The RIPE NCC will resubmit the IPv4 policy document for community review. - There was a discussion on PI/PA issues and whether the distinction is still valid. - It was agreed that a more formal process was needed for the policy development process. Address Policy Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ap DATABASE ======== - Wilfried Woeber, Chair, will co-ordinate with the RIPE NCC to prepare a document summarising the basic assumptions about the use of the RIPE Database. - "status:" attribute values will change. Current efforts aim at consistency between the RIRs and having easy to understand values. - The organisation object proposal received positive feedback from the working group, with suggestions for other features. - The RIPE NCC will implement X.509 authentication before the next RIPE Meeting. Database Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#db TEST TRAFFIC MEASUREMENTS (TTM) ========================= - As of 1/1/2004 changes will be made to the TTM service contract: Fees will be lowered, all data will be made public with lightweight Acceptable Use Policy (AUP). - Bandwidth measurements: tests showed that results are not conclusive enough so the TTM service will wait before delivering this new product. TTM Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#tt ANTI-SPAM ========= - Rodney Tillotson, Chair, will post a proposal to the Anti-Spam mailing list regarding methods to improve finding abuse contacts in the RIPE Database. Anti-Spam Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#anti-spam IPv6 === - The 6BONE phase-out was discussed. The next milestone will be 01/01/2004 when new allocations stop. - Discussion on the separation of the identifier and locater functions of IP addresses in regards to IPv6 multihoming. IPv6 Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ipv6 TECHSEC ======== - Community feedback was requested on the requirements needed to secure large scale IP infrastructure especially around CLI interface requirements. - The RIPE NCC presented a report on DNSSec status, DISI achievements since RIPE 45 and the impact of signing on zone size. - George Jones, Mitre, gave a presentation on operational security requirements including the history and current status of the requirements, related work, next steps and milestones. - Baiba Kaskina, TERENA, gave a presentation on Euro CSIRT developments that included details on the CSIRT Task Force, the countries involved, the projects and deliverables. - NLNetLab presented an update on Fonkey and PKI-related developments in IETF. TechSec Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#techsec EIX == - Support was expressed for aligning and harmonising IPv6 address space policy regarding IXPs with other RIRs and existing IPv4 policies. - Reports were presented by 11 European IXPs in Europe that showed a trend of steady growth, use of GE instead of FE and wide deployment of IPv6. - Discussion of the Inter-Provider Traffic Analyzer that uses past data and statistical calculations to detect anomalies in traffic patterns. - EIX presentations were given on the anycast deployments of the "F" and "K" root servers by ISC and the RIPE NCC. EIX Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#eix DN* === - From the merging of the former DNS Working Group and DNR Forum it was concluded that one working group is sufficient to deal with everything related to Domain Names. A new name/charter will be discussed on the mailing list. - Jaap Akkerhuis, DN* Co-Chair, will organise a "DNS Related Issues" document. - Peter Koch, DN* Co-Chair, talked about how firewall vendors could make mistakes handling DNS communication issues. DN* Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#dn RIPE NCC SERVICES ================ - Axel Pawlik noted that the RIPE NCC will present more details in next year's RIPE NCC budget. - There were comments on the current RIPE NCC services, whether they benefit the entire community and whether a 'pay per service' system could be an option. - There was discussion about the need for a more transparent evaluation of RIPE NCC activities and how they benefit the community. RIPE NCC Services Working Group presentations can be viewed at: http://www.ripe.net/ripe/meetings/ripe-46/presentations/#ncc TUTORIALS ========= - The RIPE NCC staff 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-46/tutorials/ip-request/ - A full-day tutorial on VoIP and ENUM was presented during the European Operators Forum (EOF). For more information about the EOF at RIPE 46 see: http://www.ripe.net/ripe/meetings/ripe-46/eof.html RIPE MEETING WEBCASTING ======================= - The third phase of RIPE Meeting webcasting trials was held at RIPE 46. Recordings of certain sessions from RIPE 46, including the Plenary, have been archived and can be accessed at: http://www.ripe.net/ripe/meetings/ripe-46/webcast.html HOSTMASTER CONSULTATION CENTRE (HCC) ==================================== - The RIPE NCC Hostmaster Consultation Centre was open at RIPE 46, allowing RIPE NCC Members to discuss issues relating to their business directly with RIPE NCC Hostmasters. Later consultation hours, as introduced at RIPE 44, were continued. "MEET & GREET" =============== - The RIPE NCC's "Meet & Greet" was available for first-time RIPE Meeting attendees at RIPE 46. "Meet & Greet" introduces newcomers to the meetings, to key attendees of the RIPE community and to social events throughout the week. More information can be obtained by contacting the RIPE NCC's Pepa Tejedor Carnicero at <meet-greet(a)ripe.net>. RIPE 46 REFERENCE PAGE ====================== - A complete list of RIPE 46 sessions, tutorials and presentations can be found at: http://www.ripe.net/ripe/meetings/ripe-46/index.html RIPE NCC GENERAL MEETING ======================= - The RIPE NCC General Meeting 2003 was held Friday, 5 September 2003, adjacent to the RIPE 46 Meeting, at the Hotel Krasnapolsky in Amsterdam. For the highlights from the RIPE NCC General Meeting 2003, please see: http://www.ripe.net/ripencc/about/gm/gm2003/highlights.html RIPE 47 ====== - RIPE 47 will be held in Amsterdam, the Netherlands, from 26 - 30 January 2004. Information on RIPE 47 will soon be made available at: http://www.ripe.net/ripe/meetings/ripe-47/ NEW LOCAL INTERNET REGISTRIES (LlRs) - PLEASE NOTE LIRs who signed up after 1 January 2002 are entitled to two (2) free tickets to attend the next 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>. END

1 0

Re: [ncc-services-wg] New service: ip2asn
by Wilfried Woeber, UniVie/ACOnet 29 Sep '03

29 Sep '03

>I *assume* that the development of this service will be funded 100% by the >paying customers of the TTM and that any benefit that RIPE members will gain >will be as a pleasant and cost-free side effect ? > >If not, why not ? > >Peter As this is talking money, benefits (or not) and activities of the NCC again, could we/you please try to use the proper terms?! Otherwise we get more confusion that we can handle. - RIPE does not have members. RIPE is the vehicle to support participation of the community in actvities related to the Internet in our region. - the individuals participating in RIPE do _not_ pay anything (other than in relation to attending RIPE meetings). - the RIPE _NCC_ is a membership organisation. Members do have a service contract with the NCC and pay for _all_ services rendered by the NCC; i.e. including those which are available to the users and organisations on the Internet. Thanks for your consideration. Regards, _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3 2