From Marten.Terpstra at ripe.net Thu Feb 3 11:09:58 1994 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 03 Feb 1994 11:09:58 +0100 Subject: Guarded Attributes (IMPORTANT) Message-ID: <9402031009.AA05158@ncc.ripe.net> [Apologies for wide distribution, think it is important though] Folks, Please find below a slightly updated version of the guarded attribute procedure document. For those of you who manage an AS, please not that starting coming Monday, the aut-sys field in the network object will become guarded, and can only be updated thru the procedure described below. We have created accounts for all ASes we currently see routed in Europe, and if you do not have your account yet, please come and get it as soon as possible and check out the files we have created for you. Please send requests for these accounts to . Also if you know some of your AS neighbors have not got their account yet, and are perhaps not on any of these lists, pass this message. If you have questions, send them to ripe-dbm at ripe.net as well, or directly to me. -Marten Support of Guarded fields within the RIPE Database * FINAL DRAFT * Tony Bates Document-ID: ripe-1nn 1. Introduction The RIPE database contains several significant attributes which make it well suited for use as part of operational procedures and confi- guration. Most significantly are the attributes which make up the RIPE Routing Registry (RR) as specified in RIPE-81 [1][2], namely the "aut-sys" and "comm-list" attributes. For these attributes to be of use to service providers they must be: o Properly authorised. o Efficient for both maintainers of the attributes and the main- tainers of the whole database. This document describes an overview of the RIPE database attributes which are guarded, the procedure for updating these guarded attri- butes and the general use of "guarded" fields within the RIPE data- base. 2. The Database Guarded Attributes All the guarded attributes currently supported in the RIPE database are contained within the "inetnum" or network object. However, the association corresponds to their relevant guarded database objects. If we look at a simple example this becomes clear: inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra connect: RIPE NSF WCW ripe-1nn.txt February 3, 1994 - 2 - aut-sys: AS1104 comm-list: SURFNET ias-int: 192.87.45.80 AS1104 ias-int: 192.87.45.6 AS2122 ias-int: 192.87.45.254 AS2600 rev-srv: ns.ripe.net rev-srv: ns.eu.net notify: ops at ripe.net changed: tony at ripe.net 940110 source: RIPE This shows that the RIPE-NCC network belongs to autonomous system 1104 and is in a community known as SURFNET. This is valuable infor- mation that could easily be used for example for routing policy pur- poses (as well as other operational uses). Currently support for the following set of guarded attributes is implemented: aut-sys The "aut-sys" attribute has a direct mapping to "aut-num" objects as defined in RIPE-81. That is the Autonomous System (AS) that the network number is a part of. As defined in RIPE- 81, a network can only belong to one AS and hence the "aut-sys" attribute can only contain one AS number. The syntax of the "aut-sys" attribute is: AS (1). i.e. AS1104 comm-list The "comm-list" attribute has a direct mapping to "community" objects as defined in RIPE-81. A network can belong to more than one community. The syntax of "comm-list" is: Multiple text strings which cannot start with "AS" or any of the KEYWORDS defined in RIPE-81. routpr-l (2) The "routpr-l" attribute has a direct mapping to "rout-pr" objects as defined in RIPE-60 [4]. Networks can belong to more than one routing privilege. The list of networks within a rout- ing privilege represents the group of networks accepted/allowed by a set of routers described by the information in the "rout- pr" object. The syntax for "routpr-l" is as follows: _________________________ (1) This represents a change from RIPE-50 [3] where the "aut-sys" attribute was defined to be a positive integer only, not containing the string "AS" at the start. This change has been made to be consistent with the "aut-num" object syntax. ripe-1nn.txt February 3, 1994 - 3 - Multiple text strings representing the routing privilege. bdrygw-l The "bdrygw-l" attribute has a direct mapping to "bdry-gw" objects as defined in RIPE-60 [4]. Networks can belong to more than one boundary gateway. The list of networks within a boun- dary gateway represents the group of networks advertised by a set of routers described by the information in the "bdry-gw" object. The syntax for "bdrygw-l" is as follows: Multiple text strings representing the boundary gateways iden- tification. As these attributes are tightly coupled to their associated objects it makes sense for these attributes to be updated not by the network maintainer but by the maintainer of the referenced object(s). The basic premise behind this is that these attributes should be used for various operational procedures such as setting routing policy, accounting and so on. For these attributes to be used by network operators for day to day operations they need to be guarded in such a way that can be trusted and are guaranteed to be unique - with any conflicts quickly and easily resolved. The procedure for achieving this is detailed below. 3. The Basic Procedure For each of the guarded attributes detailed above, a list of all networks having this attribute is kept separately from the general database itself. These lists (also called `guarded files') will be maintained and be served as the `only' source of membership informa- tion used in the database. Normal database updates `never' change these attributes. If an update includes such an attribute and a discrepancy between the values in the update and those in the data- base is found, a diagnostic message will be sent to the originator of the update and the guarded value(s) will not be affected. The attributes as defined in these files are incorporated in the data- base once a day. To ensure proper control and authorisation, these lists will be maintained at the RIPE NCC on the same machine that contains the RIPE database. The "guardians" of the corresponding database objects will have to maintain their own guarded files. The guardians are provided with individually assigned login accounts at the RIPE NCC. The guardians can themselves decide in what manner they want to update their file. The NCC will offer interactive logins, ftp logins or any other means that might be deemed useful. _________________________ (2) It should be noted that both "routpr-l" and "bdrygw-l" attributes have been agreed to be phased out in preference of the "aut-sys" and "comm-list" attri- butes as soon as the `guarded field' mechanism is in place. ripe-1nn.txt February 3, 1994 - 4 - 3.1. Some Details As stated each guardian will be issued with an account on the cen- tral NCC machine known as `guardian.ripe.net'. This account will contain a `restricted' environment which will allow the guardian of the relevant object to update their associated guardian file (3). Wherever possible the account name issued to the guardian will be the same as the object name. For example, the guardian of the AS1104 aut-num object will receive an account known as "AS1104". With each guardian account the corresponding file will be parsed at each update run (once a day). This file will contain the list on networks associated with the object. See appendix A for details of the format and syntax of the guardian files. A tool will also be provided within the restricted environment to syntax check the guarded file to avoid against possible typos and errors. With each account, an electronic mail address (this is a mandatory attribute for all guarded objects) will be used by the NCC and data- base software. To make this flexible for the guardian a ".forward" file with the account which can be change when required. This will mean mail sent to will go the to correct guardian. 3.2. How does it work ? For each of the guarded files found on `guardian.ripe.net' the data- base software will load any guarded attribute value(s) for the net- work object(s) listed in the guarded file. This will take place at the same time as the database is garbage collected (currently at 0500 MET). If a conflict is found (i.e if more than one entry exists for an attribute which can only contain one entry, currently only "aut-sys" contains this property), the current value will remain unchanged and all guardians involved in the conflict will be sent an electronic mail message informing them of the conflict. See Appendix B for an example. If no conflict is found the attribute will be updated with the guarded value. Correspondingly, to remove a guarded attribute just remove the net- work entry from the relevant guarded file and it will be deleted at the next update run. To be notified of this delete the "notify" attribute should be used. _________________________ (3) As stated, the mechanism for updating the guardi- an file will initially be by interactive login or file transfer. However, this doesn't preclude other mechan- isms in the future. ripe-1nn.txt February 3, 1994 - 5 - If a guardian file contains an entry which is not in the database then the guardian will be notified as part of the conflict handling procedure. If an update is sent to the database software using another mechan- ism (i.e. mail to auto-dbm at ripe.net) that contains a guarded attri- bute, this will not be allowed to change the guarded attribute. If the value of the attribute is the same as what is currently registered in the database then no warnings will be given. However, if the update contains a value for a guarded attribute that is dif- ferent to that registered in the database, a warning will be sent to the originator and the guarded value will remain unchanged. Any changes of other (unguarded) fields in the update will be checked for syntactic correctness and if they pass will go through to the database irrespective of any conflicts for the guarded fields. When through the normal database update procedure an object with guarded attributes is deleted, the guardians of these guarded attri- butes will be notified of this deletion. Only deletions will be notified in this way to guardians. For normal changes the "notify" attribute of the database should be used. Although the guarded process will run once a day as part of the database garbage collection procedure it will also be possible to, "on request to the NCC", run an emergency guarded update process for a particular guarded object. To have complete guardian accounts removed from the NCC machine, and thus all references to this guarded value, please contact the RIPE NCC at . Removing an account and the guardian file that goes with it means that this guarded value will not be added any longer to any of the objects in the database. 4. Getting it started As this is a new (and much needed, especially for the "aut-sys" attribute) mechanism, a degree of `bootstrapping' is needed to make it easier for network providers and IRs to transition to using the guarded file procedure. The NCC has built an automated generation scheme for attributes that are known to be in use (currently, this means AS numbers). For all the AS numbers seen to be routed in Europe, accounts for the guardians have already been put in place having the guardian's mailbox point to a mailbox at the RIPE NCC. For these ASs currently guarded files are generated on a daily basis by analyzing European full routing tables. This means there could (and almost certainly will) be some conflicts within the generated guardian files. As soon as the account is handed over, the auto-generation for that guardian account stops and the mailbox is changed to the correct guardian mailbox. Guardians can of course make use of the auto- generated guarded files if they wish to check against their own records. From the moment of `hand-over' it is now the guardians responsibility to make sure their associated network(s) get the ripe-1nn.txt February 3, 1994 - 6 - correct guarded attributes by listing them in the guarded files. The advantage of having this `bootstrap' method is that it will allow population of the guarded "aut-sys" attribute to take place immediately this functionality is enabled in the RIPE database software. It also acts as an incentive for networks operators and local IR's to transition to the guarded file procedure as soon as possible. 5. Conclusion The update procedure as detailed above has the following advantages: o Authorisation of adding/deleting is guaranteed. o No need for mailing back and forth of authorisation messages. o Simple procedure for both database maintainers and guardians. o Guardians keep full control of their attribute. It allows for the addition of any number of guarded attributes in the future. It describes a simple but effective procedure for main- taining the guarded files whilst not precluding alternate mechanisms in the future. 6. References [1] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P., Terpstra, M., "Representation of IP Routing Policies in the RIPE Database", RIPE-81, February 1993. [2] Bates, T., Karrenberg, D., "Description of Inter-AS Networks in the RIPE Routing Registry", RIPE-103, December 1993. [3] Karrenberg, D., "RIPE Database Template for Networks", RIPE-50, April 1992. [4] J.-M. Jouanigot, "Policy based routing within RIPE", May 1992. ripe-1nn.txt February 3, 1994 - 7 - Appendix A - Format of Guardian Files. We propose to keep the file format as simple as possible. The name of the file is identical to the name of guarded object. The format used within the file is kept simple. It allows lines to be either comments or the actual object entry that is to be guarded. A comment must contain either a semi-colon (;) or hash (#) at the beginning of the comment line. The object name entries must be exactly the same as they are in the database. Currently, the only object containing guarded attributes is the "inetnum" object so the file can contain either the `well-known' dotted quad network notation or RIPE dotted quad range notation. Here is a simple example of what the AS1104 guarded file would look like. The file would be stored in the home directory of the AS1104 account on guardian.ripe.net and be called AS1104 (told you it was simple). It would contain something like the following: # # File : AS1104 # ; An alternate comment format ; ; This file was updated jan.dijkstra at gouda.nl ; on 940109 ; 192.16.183.0 192.16.185.0 - 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 Empty lines in the file are also ignored but you are encouraged to keep the file as concise as possible. As stated above, a tool known as `checkguard' will be available to make it simple to check the syntax of the guarded file. ripe-1nn.txt February 3, 1994 - 8 - Appendix B - Example of conflict handling If a conflict occurs (e.g. by listing the same network number in more han one AS guarded file), then each of the guardians involved will be notified on the conflict by electronic mail. Let's look at a simple example. Suppose the guardians for AS1104 and AS2122 update their relevant guardian files and create a conflict by having the same network in them. For this example he network in question is "192.16.183.0". Here is the AS1104 guardian file: # 192.16.183.0 192.16.185.0 192.16.186.0 192.16.194.0 192.16.199.0 192.87.45.0 And here is the AS2122 guardian file: # 192.16.183.0 193.0.0.0 - 193.0.7.0 As you can see "192.16.183.0 exists in both files. At update time the following mails are generated. Firstly, to the guardian of AS2122. Date: Fri, 14 Jan 1994 13:22:43 +0100 Message-Id: <9401141222.AA07125 at ns.ripe.net> From: RIPE Database Conflict Handler Subject: Guarded attributes conflicts found To: as2122 at ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS1104 And similarly to the AS1104 guardian. ripe-1nn.txt February 3, 1994 - 9 - Date: Fri, 14 Jan 1994 13:22:42 +0100 Message-Id: <9401141222.AA07121 at ns.ripe.net> From: RIPE Database Conflict Handler Subject: Guarded attributes conflicts found To: as1104 at ripe.net Dear Guardian, One or more conflicts have been found regarding guarded attributes in the RIPE database. Some of the conflicts concern the guarded values you are a guardian for. Please verify and correct the conflicts below. The guarded values for objects below have been set to the value they had in the database before this guarded attributes run. Kind Regards, RIPE Database Conflict Department ------ "192.16.183.0" also appears in guardian files: AS2122 >From this you can see conflict can be quickly and easily resolved, assuming good collaboration between the guardians. The existing database entry will of course not be changed with regard to the guarded attribute) as long as there exists a conflict. ripe-1nn.txt February 3, 1994 From Daniel.Karrenberg at ripe.net Wed Feb 9 16:28:09 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 09 Feb 1994 16:28:09 +0100 Subject: Draft Minutes of the meeting at RIPE 17 Message-ID: <9402091528.AA07606@reif.ripe.net> Folks, this will be part of the RIPE 17 minutes. Comments to me please. Daniel ---------------------- Local-ir Working Group Minutes from RIPE 17 Chair: Daniel Karrenberg Scribes: Geert Jan de Groot, Daniel Karrenberg 12.1.1. Reports for Information DE-NIC in Dortmund shut down, the DE-NIC is now in University of Karlsruhe. The registries in Europe totally assign 100 C's per day on the average. With 80 IR's, this comes close to 1 C/IR/day. A list of local-IR's has been published [RIPE-101]. It was agreed that this information should be made available via the RIPE database Daniel Karrenberg agreed to write a proposal and submit it to the local-ir and database working groups. Action: xx.1 Daniel Karrenberg Propose (guarded) RIPE database object representing a local registry, mail to local-ir and db wg. 12.1.2. Local Registry Procedures The address space assignment procedures have been revised as agreed at the last meeting and during subsequent e-mail exchanges. The new document is ripe-104. Most important changes: in case of a request for a block >= 32C's, 2nd opinion of the RIPE NCC is recommended, less reser- vation of address space recommended. Question: How about requests having 16C and ask for 16 more? Answer: Use your judgement (as always). It was observed that frequently organisations asking for space already have some without knowing it. All registries are reminded to cross-check this for all requests from large organisations. If there is ay doubt, the WAIS server of the database is a good source of information. The NCC observed that more and more individual assignments are not reported back via the data- base in a timely fashion. The group confirmed the wording of "immediately but certainly not later than one working day after assignment". Local registries are reminded to adhere to this. The NCC will perform more stringent checks whenever the delegation of additional address space is requested by a local registry. Address space reservation strategies were briefly discussed. It was agreed not to reserve big blocks of address space (>8 Cs) as a matter of general policy. It was felt that the real CIDR gains from such a reservation policy are minimal. After some reservations about this expressed by Yves Devillers it was decided to discuss this further and to gather some data about assignments and res- ervations from blocks delegated by the NCC. It was agreed that reservations should not be stored in the database but reported separately to the NCC. Willi Huber volunteered to produce a format for representing assignment/reservation status of address space from delegated blocks. The NCC will collect this data and make it available to all European Internet Registries. The data will be restricted to the European Internet Registries for the time being. Generally customers should not get this information because they easily get the impression that reserved blocks have been allocated to them. Action: xx.2 Willi Huber Propose a representation address space assignment/reservation status. It was suggested to produce a tool showing assignment/reservation status graphically. Willi Huber volunteered to propose a representation with help from Wilfried Woeber. Action: xx.3 Willi Huber Propose a graphical representation address space assignment/reservation status. Q: Are IR's required to use 193-reserved space before asking for new 194-block? A:NO, but review the reservation after 24months. It is up to the local IR to contact the customer on this. Autonomous System number assignment procedures are explained in the application form (Docu- ment ripe-097). the most important criterion for an AS-number assignment is that the AS number is actually used in external routing on the Internet. A secondary criterion is that the organisation should be multi-homed. AS-numbers do not need to be assigned because router configurations seem to require globally unique numbers. A need is felt to set aside some AS numbers for use in local internets not connected to the Internet. Action: xx.4 Daniel Karrenberg Ask IANA for a default range (65530-65535 or so) in the line of the network-10 pro- posal Reverse Name Service The "Procedures for DNS Delegation in the in-addr.arpa Domain" (ripe-105) was briefly reviewed. i 12.1.3. Proxy Network Entries in RIPE Database After two reminders on the list no input was received from the proponents of proxy registration. It was the general feeling of the meeting that proxy entries should not allowed mainly for operational reasons but also to make the address space delegation process transparent. The action item to produce a recommendation was dropped. The current recommendation that the organisation address space has been assigned to has to be registered in the database. 12.1.4. Any other business A large amount of address space currently applied for will never be connected to the Internet (inter- nal networks). A proposal is being made to have these cases use network10.0.0.0, which cannot be connected to the Internet (this will be an RFC soon). There were some drawings on this proposal which are difficult to reflect in ASCII. Q: Is there a procedure to stop a local-IR if found necessary? A: There is a hook to have it return the non-allocated address space per RIPE-104. Communication between local IR's and last resort IR is sometimes poor. This needs to be sorted out locally (mailinglist).If need be, a mailing list ir-@ripe.net can be set up. A local-ir workshop will be held at next meeting: half day, May 16th, 10.00 am. Action: xx.5 NCC To organise local-ir workshop for the 18th RIPE meeting From HANK at VM.BIU.AC.IL Thu Feb 24 13:15:11 1994 From: HANK at VM.BIU.AC.IL (Hank Nussbacher) Date: Thu, 24 Feb 94 13:15:11 IST Subject: Charging for allocations Message-ID: <9402241116.AA00245@ncc.ripe.net> For two years Israel has been handling "allocations" in a free fashion. Lately, as I am sure with everyone, the burden of registering IP class C networks, domain names, contact people, inverse domain names, and routing updates is taking more and more of our time, personnel and our national DNS primary CPU. It is not uncommon for sites that have no Internet connectivity to request IP numbers for their private networks. It is not uncommon for local dialup (SLIP) service providers asking for us to register domain names on their behalf and then charging their customers a monthly fee for the "privilege" of owning their own "DNS" entry. When the entire matter was on a one or two request per month basis, the university non-profit consortium was able to handle the requests on a volunteer basis. This is no longer the case. We have no NSF to fund a scaled down Internic (which handles requests free of charge since it is government funded) on a national scale and since RIPE NCC charges its member countries an annual fee we have to find a "fair" way to recover not only the RIPE NCC costs but also the local manpower and computing costs. We are planning on implementing the following surcharges: - Any organization wanting a class C IP network will be charged $xx per class C network assigned. - Any organization wanting a domain name assigned in the .il domain will be charged $xx. - Any organization that wants ILAN to handle inverse domain name registration will be charged $xx. - Any organization that wants its IP network to be routed globally will be charged $xx. I would like to hear what other countries who are in a similar position are doing in this area. Should we already start discussing numbers? Thanks, Hank From mnorris at dalkey.hea.ie Thu Feb 24 13:30:10 1994 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Thu, 24 Feb 94 12:30:10 +0000 Subject: Charging for allocations In-Reply-To: Your message of "Thu, 24 Feb 94 13:15:11 +0700." <9402241116.AA00245@ncc.ripe.net> Message-ID: <9402241230.AA27541@dalkey.hea.ie> Hank I don't know whether we're in a similar position here, except that I understand what you're saying and have a lot of sympathy for your proposal. I'd make one suggestion about the tariffs you mention. In addition to once-off charges, there should be recurrent charges. These would be planned to cover ongoing maintenance costs. They would also encourage customers to use the resource prudently. These charges should be small but noticeable. For example, if an organisation is paying $yy a year for the use of a Class C network, then it will be quick to hand it back when it no longer needs it for any reason. Perhaps you meant that the charges proposed by recurrent. If so, sorry for wasting the time of the list. Cheers. Mike From HANK at VM.BIU.AC.IL Thu Feb 24 14:32:36 1994 From: HANK at VM.BIU.AC.IL (Hank Nussbacher) Date: Thu, 24 Feb 94 14:32:36 IST Subject: Charging for allocations In-Reply-To: Message of Thu, 24 Feb 94 12:30:10 +0000 from Message-ID: <9402241237.AA00317@ncc.ripe.net> On Thu, 24 Feb 94 12:30:10 +0000 you said: >Hank > I don't know whether we're in a similar position here, >except that I understand what you're saying and have a lot >of sympathy for your proposal. > >I'd make one suggestion about the tariffs you mention. In >addition to once-off charges, there should be recurrent charges. >These would be planned to cover ongoing maintenance costs. They >would also encourage customers to use the resource prudently. >These charges should be small but noticeable. > >For example, if an organisation is paying $yy a year for the >use of a Class C network, then it will be quick to hand it back >when it no longer needs it for any reason. > >Perhaps you meant that the charges proposed by recurrent. If so, >sorry for wasting the time of the list. No, I am totally against recurrent charges. I don't feel that the nature of registration (IP, domains, etc.) at the present time is one that is dynamic. You get an IP net and you keep it. I just don't see people handing back class C nets after having paid for them just because we charge for them a small yearly maintenance fee. Routing updates might be dynamic but I would suggest to price the one-time cost to cover 3 years of updates rather than send a customer a bill for $10-$30 per year for "routing update maintenance". > >Cheers. > >Mike Hank From mnorris at dalkey.hea.ie Thu Feb 24 14:01:27 1994 From: mnorris at dalkey.hea.ie (Mike Norris) Date: Thu, 24 Feb 94 13:01:27 +0000 Subject: Charging for allocations In-Reply-To: Your message of "Thu, 24 Feb 94 14:32:36 +0700." Message-ID: <9402241301.AA27647@dalkey.hea.ie> Hank while IP networks are quite like tins of beans, they are not exactly so. There is some maintenance involved on the part of the IR after the goods leave the shop. This is small but it is there; one place you'll see it is in the RIPE Quarterly reports, in the tables on allocated networks. Maybe your three-year license would be better than generating small annual bills. Whatever, the scheme should be scalable and that means that all ongoing costs, however insignificant, must be factored in. Cheers. Mike From poole at eunet.ch Thu Feb 24 14:06:07 1994 From: poole at eunet.ch (poole at eunet.ch) Date: Thu, 24 Feb 1994 14:06:07 +0100 (MET) Subject: Charging for allocations In-Reply-To: <9402241116.AA00245@ncc.ripe.net> from "Hank Nussbacher" at Feb 24, 94 01:15:11 pm Message-ID: <199402241306.OAA05408@eunet.ch> > > For two years Israel has been handling "allocations" in a free > fashion. Lately, as I am sure with everyone, the burden of > registering IP class C networks, domain names, contact people, > inverse domain names, and routing updates is taking more and > more of our time, personnel and our national DNS primary CPU. > Naturally you took this on on a purely voluntary base (nobody forced you to do it). I would consider it to be very improper to start charging "users" without a clear consenus in your country on how the various registration issues etc. should be handled and if they want your organisation to continue with this role in the first place. The current German solution seems to be very good and would seem to avoid the obvious conflict of interest issues that immediately arise if non-neutral organisations provide these services. Simon From Daniel.Karrenberg at ripe.net Fri Feb 25 09:01:00 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 25 Feb 1994 09:01:00 +0100 Subject: Charging for allocations In-Reply-To: Your message of Thu, 24 Feb 1994 14:06:07 MET. <199402241306.OAA05408@eunet.ch> Message-ID: <9402250801.AA03675@reif.ripe.net> > poole at eunet.ch writes: > > The current German solution seems to be very good and would seem > to avoid the obvious conflict of interest issues that immediately > arise if non-neutral organisations provide these services. Just to explain for those who do not know: In Germany the major Internet service providers got together (in spite of serious historical antagonism I might add) and formed a consortium which funds and supervises the DE-NIC. DE-NIC offers both DNS and address registration services. This is paid and controlled by the members of the consortium who in turn pay it from the revenue from their customers. Providing service to not connected organisations is seen as an investment in future customers. I do not know how the consortium deals with new service providers which are not yet a paying member. But I guess they will suggest they become a member. The operation of the DE-NIC was awarded to the comp centre at Karlsruhe University after a public call for tender by the consortium. As long as DE-NIC serves everyone in Germany I consider this is an excellent way to solve the problem. Daniel From Daniel.Karrenberg at ripe.net Fri Feb 25 09:10:38 1994 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 25 Feb 1994 09:10:38 +0100 Subject: Charging for allocations In-Reply-To: Your message of Thu, 24 Feb 1994 13:15:11 +0700. <9402241116.AA00245@ncc.ripe.net> Message-ID: <9402250810.AA03697@reif.ripe.net> Folks, I know that some local registries are actually charging for registrations although they do not discuss this publicly since doing it is frowned upon by the RIPE community and especially by those providing free last-resort registry services. I think it is time to discuss this issue openly and come to a consensus on how to handle this which will be written up as a RIPE recommendation. Some input for a discussion can be found in: Ref: ripe-084 Title: RIPE NCC Funding Author: Rob Blokzijl, Daniel Karrenberg Date: 25 March 1993, updated May 1993 Format: PS=41337 TXT=17835 bytes Daniel From poole at eunet.ch Fri Feb 25 10:04:02 1994 From: poole at eunet.ch (poole at eunet.ch) Date: Fri, 25 Feb 1994 10:04:02 +0100 (MET) Subject: Charging for allocations In-Reply-To: <9402250810.AA03697@reif.ripe.net> from "Daniel Karrenberg" at Feb 25, 94 09:10:38 am Message-ID: <199402250904.KAA08652@eunet.ch> > > I know that some local registries are actually charging for registrations > although they do not discuss this publicly since doing it is frowned > upon by the RIPE community and especially by those providing free last-resort > registry services. > The question is not if charging is acceptable or not, but far more a) by what process are the organisations selected that provide these services. b) what the duties and rights of the registries are (for example do top level domain registries "own" the domains they are administrating?). c) by what process is the cost recovery method for the organisation selected in a) decided. a) and b) tend to not be an issue as long as the services are free, as soon as you start asking for money, all kind of issues turn up. Alas, all attempts I've followed to define a) and b) seem to have been dismal failures. Simon