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

Updated Hostcount++ proposal
by Andrei Robachevsky 06 Oct '05

06 Oct '05

Dear Colleagues, Please find below an updated proposal for Hostcount++. Hostcount ++ is a set of enhancements to the hostcount service that the RIPE NCC has been running for 15 years. The Hostcount++ concept was presented at RIPE 50: http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-serv-hostcou… The general feedback was positive, and there were some follow-up discussions. For examples of these discussions see: http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2005/msg00046.h… http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2005/msg00051.h… The Hostcount ++ proposal has been refined based on this feedback. Your comments and suggestions are appreciated. The RIPE NCC will make a short update on this project at the RIPE NCC Services Working Group at RIPE 51. Best regards, Andrei Robachevsky RIPE NCC Hostcount++ for the RIPE NCC Service Region =========================================== Motivation ---------- Every month the RIPE NCC coordinates the collection of data from the DNS zones of ccTLDs in the RIPE NCC Service Region and publishes summary statistics derived from this data. The first hostcount was in October 1990 and involved 19 ccTLDs. Since then, the hostcount has expanded to include around 100 ccTLDs. The hostcount is provided as an informational service to the Internet community. The current implementation of the Hostcount has several problems: - Connectivity problems with certain hosts - Lack of data accuracy due to access policies of some ccTLD domains - The increasing number of domains There are also issues related to privacy and acceptable use of the results. Objectives and Deliverables --------------------------- 1) To increase the precision and reliability of data, especially for trend analysis, more sources will be added. Our final aim is to collect data from: - Forward DNS - Reverse DNS - BGP view on availability of prefixes 2) Re-designing the software to be more scalable is very important, since the amount of input to be analysed is already of considerable size and is increasing every day. 3) To protect the privacy of domain holders and data, the following changes will be made: - Use cases will be defined in more detail and "Acceptable Use Policy" documents will be written accordingly. - Raw data will not be made available. 4) The following information will be made available, via textual dumps and graphs and tables on the web site: - Average visibility of RIPE NCC allocations: Visibility will be calculated by the information provided from the Routing Information Service (RIS) project. - Number of hosts and Average number of hosts: Host information will be retrieved via zone transfers. If the zone transfers fail due to blocking, partial zone information will be generated from reverse scan. Blocked zone transfers will be constructed by enumeration of the zones. - Breakdown of DNS record types: This information will depend on zone transfers of each allocation. 5) Results will be sorted into: - visible/invisible: This is based on whether a given IP range has been announced in the preceding month for longer than a particular threshold. - ccTLDs: This is based on the ccTLDs in the RIPE NCC service region. - RIPE NCC allocations: These are the allocations made by the RIPE NCC for its members. - IANA allocations: These are the /8 ranges for IPv4, and /23 ranges IPv6, allocated to the RIPE NCC. 6) In addition, timestamps of the results will be more consistent. 7) Hostcounts for certain ccTLDs will be performed locally by contributors. We look forward to increasing the number of contributors to distribute the load of the overall process. 8) Resulting software will be open-source, enabling a do-it-yourself kit for local statistics gathering.

3 2

Improved wording for request forms
by Laura Cobley 05 Oct '05

05 Oct '05

Dear Colleagues, We are pleased to announce the publication of four updated RIPE documents. We have improved the wording of these documents without changing the actual content of the request forms. This will make the request forms easier to use. These changes are part of a project to improve the wording of all request forms and supporting notes. The following RIPE documents have been edited: ripe-354 AS Number Request Form ripe-355 Supporting Notes for the Autonomous System Number Request Form ripe-356 Provider Independent (PI) Assignment Request Form ripe-357 Supporting Notes for the Provider Independent (PI) Assignment Request Form You can find the Documents in HTML format at: http://www.ripe.net/docs/asnrequestform.html http://www.ripe.net/docs/asnsupport.html http://www.ripe.net/docs/pi-requestform.html http://www.ripe.net/docs/pi-requestsupport.html Regards, Laura Cobley Registration Services RIPE NCC

1 0

RIPE NCC Service Interruption on 29 September
by Ruud de Kooter 04 Oct '05

04 Oct '05

Dear Colleagues, As we announced on 29 September, there was an unexpected disruption to our whois and web services between 05:10 and 06:00 UTC. Our investigations have shown that the problem was caused by an increasing traffic load and a growing number of peers on one of our routers. We made some configuration changes to improve load balancing between our border routers. This should prevent any similar problems from occurring in the future. We apologise for any disruption or delay this may have caused. If you have any further questions about this matter, please send an e-mail to <ops(a)ripe.net>. Regards Ruud de Kooter RIPE NCC

1 0

Charging for PI space?
by Hank Nussbacher 02 Oct '05

02 Oct '05

I'd like renew the discussion of PI address space and how it affects ones' RIPE category: http://www.ripe.net/ripe/docs/ripe-331.html Suppose a LIR was asked by a customer to acquire PI address space (/22) and the customer had justification for requesting it. What do LIRs charge the customer for doing this work and therefore increasing their "billing score" for one year? Regards, Hank

1 0

RIPE NCC Service Interruption
by RIPE NCC Operations 30 Sep '05

30 Sep '05

[apologies for duplicate mails] Dear Colleagues, >From 07:00 until 08:00 GMT, the RIPE NCC experienced an unexpected disruption to services. Although this may have caused delays to updates to the RIPE Whois Database, these updates have been processed normally. The disruption may have also affected some of these RIPE NCC services: - whois.ripe.net - www.ripe.net - lirportal.ripe.net - ns*.ripe.net - ftp.ripe.net - www.aso.icann.org - www.nro.net - k.root-servers.org (Global node at the AMS-IX) - AS112.ripe.net We apologise for any interruption or delay to services. If you have any questions or concerns regarding this issue, please contact <ops(a)ripe.net>. Regards, RIPE NCC Operations

3 2

Re: [ncc-services-wg] Feature request
by Max Tulyev 19 Sep '05

19 Sep '05

> I think I misunderstood what you wanted when we spoke last week. I > thought you were looking for some kind of added granularity to the > maintainer system. However, reading your request again it looks more > like you want to be able to use the RIPE Database to enforce a > contract between you and your customers. Is that correct? Correct, but not exactly RIPE DB. Just have an ability (for example, through letter to Hostmaster) to have general control on the objects I registered. > Can I ask why you'd want to use the RIPE Database to do this rather > than use an alternative, like a debt collection agency, or an order > from a civil court? That's because it is not working fine here... -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

1 0

Feature request
by Max Tulyev 19 Sep '05

19 Sep '05

Hi! As I register a lot of PI/AS, there is a bit problem I often face to. My clients wants to have control on their objects I registered for them (i.e. have their mnt-by). But there is an agreement between us, and sometimes (due to payment problems, violating the agreement, spam, etc.) I need to suspend or even remove objects. Having my mntner inside users' objects is often not acceptable because of users wants to change objects by themself (and do that quickly and transparently). Also there is administrative reason ("Why we can't change our objects, why there is alien mntner?"). How I can shut down objects I registered as LIR, but don't maintain? Is there some special feature? Thank you. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

7 10

RIPE51 - NCC Services WG - Agenda Items
by Bijal Sanghani 19 Sep '05

19 Sep '05

Dear Colleagues, We are currently working on the draft agenda for the RIPE NCC Services Working Group for RIPE 51. If anyone would like to make a presentation or raise a topic for discussion please contact either Kurtis or myself and we'll arrange a slot on the agenda. Thanks, -bijal

1 0

Re: [ncc-services-wg] Feature request
by Max Tulyev 18 Sep '05

18 Sep '05

> Well, you are not supposed to sell/rent addresses, with the exception of > covering the administrative overhead. Which should be close to NIL if you > do not want to take care of that block (LIR-wise). So a simple approach > would be to hand out the addresses only after a reasonable once-off fee for > obtaining them has been paid. Heh... /22 PI is scored like 4 (FOUR) PA /20 block usually got by LIR at the beginning (but, of course, once). So I don't think it is "close to NIL". Often it is too expensive, especially in eastern Europe, especially to non-profit organization. So it is good to split payment for a chunks, not bill them once. Anyway, is there the deny to bill PI/AS on regular basis (not once)? Where? > Which agreements? As long as you provide connectivity to them, this is an > ISP operational issue. If they don't pay for those services they get > locked/cut. Then the holder of PI is free (by definition) to find another > provider. end story. If I am their service provider (btw, then they got PA) - I can cut their service. And if not? > Boring, yes, but I thought you want to see an on-going flow of money ;-) > What for? Where's the user friendlyness? So RIPE gives me a policy how to deal with my clients? ;) If yes, please show me the documents. If not - let me do that, and be LIR-friendly ;) > There should be a local legal envirnment available to enforce (resonable) > contracts. Yes. But, unfortunally, contracts sometimes violates, so I ask about technical resources to have users to be correct. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

3 3

Feature request
by Max Tulyev 16 Sep '05

16 Sep '05

> > But there is an agreement between us, and sometimes (due to payment > > problems, violating the agreement, spam, etc.) I need to suspend or even > > remove objects. > ...which means that you want to/have to keep responsibility to maintain the > data in the repository, right? Not right. User is keeping responsibility to maintain the data, so their mnt-by is in the objects. My aim is (at least) to bill user, and it can be done different ways (once, yearly, quarterly, by crediting user for sometime, whatever). And I need the mechanism to let that user have to pay ;) (and not to violate agreements by other ways) and remove objects if it doesn't - but NOT to keep information up to date in RIPE DB. > I don't understand this assertion, as long as there is a contractual > relationship with your LIR, there is no "alien maintainer". Please keep in > mind that an LIR is NOT required to provide PI assignment services. So if > those "customers" don't like your set of rules, they are free to find > another LIR which offers what they want. Ok, but if I want to be more user friendly than others? Or if I bored with making updates of my users' objects? > What you definitely _can_ do is add an _additional_ maintainer for your > user. Then having any credential as listed in _any_ of the maintainers > allows access. Evaluation of the auth: tags is done according to a LOGICAL > OR policy. From the beginning I said about "bad guys". If user really one - he just sends an update to remove my mntner - and I loose control on object completly. > Not to my knowledge. I think I suggested that before - in case you deploy > the multiple maintainer approch, you probably should enable the > notification mechanism(s) [in your maintainer] to each time get an alert > when your customer happens to change registration data. But notification comes a bit later, isn't it? ;) > And you may want to include an explicit provision in your contract that > prevents your customer from removing the link to _your_ maintainer object. If all users always do what is written in the contract - there was no deal about all of that at all. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

1 0