July 1996 - ripe-list - mailman.ripe.net

(no subject)
by Clizio Merli - 4U S.r.l. 30 Jul '96

30 Jul '96

subscribe Clizio Merli ********************************************* Master @ net4u.it (4U S.r.l. Vercelli) *********************************************

1 0

RIPE25: Announcement
by RIPE NCC Staff 29 Jul '96

29 Jul '96

(This is the only announcement that goes to <local-ir(a)ripe.net> as well. If you want to keep up to date with meeting information, please regularly check ftp.ripe.net/ripe/Next-Meeting, or subscribe to 'ripe-list' via <majordomo(a)ripe.net>. The meeting info is not yet available via the Web, but that will be worked on.) R I P E meeting announcement ============================ (This announcement can also be viewed using "finger meeting(a)ncc.ripe.net") This is to announce that the 25th RIPE meeting will take place: Dates: 23rd September, 1996 start: 10:00/14:00 (*) 24th September, 1996 25th September, 1996 end: 13:30/18:00 (*) * We're sorry not to be able to give better estimates until shortly before the meeting. Venue: CWI Kruislaan 413 1098 SJ Amsterdam The Netherlands Host: NIKHEF Registration: Please use the registration form (which will follow in a separate mail) to give notice of your coming as soon as possible. General meeting overview: ------------------------- - We assume that before the working group meetings, on Monday 23rd, there will be an EOF (European Operators Forum) meeting. The exact starting time will probably be known shortly before the RIPE meeting. It will end 12:30. - Monday 23rd, 14:00-18:00 and Tuesday 24th, 09:00-12:30, there will be various RIPE working groups sessions. The schedule of the previous meeting follows below for reference; the schedule of this meeting is not known yet. - Tuesday 24th, 14:00-18:00 and Wednesday 25th, 09:00- +/-15:30 (*), the plenary session will take place, with reports from the RIPE NCC, reports from the working group meetings and other presentations. General information: -------------------- Currency (checked 25 July 1996): 1 UK pound = Hfl 2.6 1 ECU = Hfl 2.1 1 US$ = Hfl 1.7 More information about Amsterdam: --------------------------------- Websurfers may take a look at: <> http://www.xxlink.nl/cities/amsterdam <> http://www.channels.nl/ Appended to this announcement: ------------------------------ <> directions to the meeting place Documents to follow (separate mail messages): --------------------------------------------- <> details of hotels in Amsterdam close to meeting venue <> registration form for attendance at the meeting <> getting visa for the meeting, if you need one ================================================================== Directions to meeting venue --------------------------- >From Amsterdam airport (Schiphol): o Take the train from the airport railway station to the Central Railway station. >From the Central Railway station: o Change to the stop train to Utrecht / Amersfoort / Lelystad. Next station is the 'Muiderpoort' railway station. or o Take bus 22 in the direction 'Indische Buurt' to the stop at the 'Muiderpoort Station'. or o Take tramway number 9 till the stop at the corner of Middenweg and Kruislaan (15 min ride) o Walk down the Kruislaan in the direction of the railway bridge. Cross under the bridge and continue. Take the 2nd entrance left and proceed to the RIPE meeting venue. (you'll see signs.) (15 min walk all together). >From the Muiderpoort Railway station: o Take bus 66 (5-10 minutes ride). At the exit of the railway station turn to the left, pass through the tunnel, turn left again and cross the street. The stop for bus 66 is there (behind the tram stop). The bus passes twice broad railway bridges. Get off at the second stop after the second passage, pass through the gate at the left, and proceed to the RIPE meeting venue. (you'll see signs.) Bus 66 is operated in conjunction with bus 61. Therefore the bus does not always show the correct linenumber. In case of doubt ask the driver or your fellow-passengers. Taxi from the airport: o 15 min ride o fl. 60 appr.

2 1

RIPE25: registration form
by RIPE NCC Staff 26 Jul '96

26 Jul '96

25th RIPE meeting Registration reservation form Amsterdam, The Netherlands September 23rd-25th, 1996 %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL meeting registrations is fully automated. To register for the meeting, please complete the registration form and send it to <meeting(a)ripe.net>. PLEASE FILL THIS OUT AS SPECIFIED. Please add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). Note this is what will be used for your badge if you have requested one and for the attendee list so please take care to fill it in correctly. You will receive a notification message that your request has been processed. If however, you have any questions about the meeting or your registration form, please send your completed form to <ncc(a)ripe.net>. ============================================================================== %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL (remember this is on list and badge) e.g. John Doe Mary-Beth Walton %NAME [ ] 2) I will need the RIPE NCC staff to come up with a badge for me (Fill in Y if you do not have a badge yet, or if you have given it to the NCC staff to keep until the next meeting. Fill in N if you will bring your old badge to the meeting yourself.) %BADGE [ ] 3) Your Organisation/Institution %ORG [ ] 4) Your e-mail address %EMAIL [ ] 5) Country code of organisation e.g. IT FR DE %CTRY [ ] %END

1 0

RIPE25: Visa
by RIPE NCC Staff 26 Jul '96

26 Jul '96

Dear RIPE meeting attendees, This letter is intended for all of you who need a visa to come to the Netherlands for the 25th RIPE meeting. Since getting visa takes generally more time than one expects, I would suggest you apply for a visum as fast as possible. On request, we can send you an invitation. If you want us to send an invitation, please tell us how many days and which days you are planning to stay. If, after the RIPE meeting, you want to stay some additional days we can invite you for some 'technical meetings' after the RIPE meeting ;-)). Furthermore, please give also your full name, birth date and passport number. If we mention these data in our invitation to you, it could facilitate getting visa. If you have any further questions, don't hesitate to contact us, preferrably at <ncc(a)ripe.net>.

1 0

RIPE25: Hotels
by RIPE NCC Staff 26 Jul '96

26 Jul '96

Hotel information Rooms have to be reserved by the participants themselves. Below you find a list of hotels you can contact to find a room. You can also: - for more information, look at http://www.nbt.nl/holland/hotels/ho-pa - contact: National Reservations Centre P.O. Box 404 NL-2260 AK LEIDSCHENDAM tel. +31 70 320 2500 fax +31 70 320 2611 -------------- <> All phone numbers below require the prefix 31 20 <quoted number>. <> All tram connections are from central station. <> Data are subject to change, please check first Low budget hotels (price range 90-120 Hfl): Name Adress Phone Fax Tram Barbacan Plantage Muidergracht 89 6236241 6272041 9 Lancaster Plantage Middenlaan 48 6266544 6226628 9 Somewhat more expensive but located near the Central Railway Station (price range 185-210 Hfl): Hotel Ibis Stationsplein 49 6383080 6200156 Recommended by Chris Jones: Mercure Arthur Frommer Noorderstraat 46 6220328 6203208 16/24/25 The following hotels can be booked at: AMS Booking Center P.O.Box 60011 1005 GA Amsterdam The Netherlands phone: 6831811 fax: 6160320 telex: 14275 single/ Phone Fax Tram double Museum *** 170/244 P.C. Hooftstraat 2 6621402 6733918 5 Trianon *** 170/244 J.W. Brouwerstraat 3-7 6732073 6738868 16 Terdam *** 170/244 Tesselschadestraat 23 6126876 6838313 5 Holland *** 170/244 P.C. Hooftstraat 162 6764253 6765956 5 Beethoven **** 190/280 Beethovenstraat 43 6644816 6621240 24 Lairesse **** 240/280 De Lairessestraat 5-7 6719596 6711756 16 Karena Hotels Group (all centrally located) ------------------- Doelen ) Caransa ) -- Central Reservation number 626 2922 626 6831 Rembrandt ) Schiller ) If RIPE people want to benefit from the cheap rate of NLG 170 at any of those four hotels, then they have to ask the TERENA Secretariat to make the reservation for them. The TERENA secretariat is reachable at : E-mail: secretariat(a)terena.nl tel: +31206391131

1 0

European Cache Coordination
by martin＠terena.nl 26 Jul '96

26 Jul '96

Apologies in advance for cross-posting. Analysis of network traffic on the Internet has shown that significant savings can be made if local caches are introduced and these are linked to form a "caching hierarchy". Much work has been carried out on the development of caching software and many institutions and networks already implement caching at various levels. It is vitally important to coordinate the construction and maintenance of these caching hierarchies and, after being approached by various bodies, TERENA has decided to investigate the possibility of setting up a caching task force. Note that the technology for caching is being developed elsewhere and is therefore not the subject of this initiative. Rather, TERENA intends to promote the usage and coordination of caching at the local, national and international level to produce a more efficient, cost-effective and above all reliable service for the users of research networks in Europe. The objectives of this task force are therefore initially: i promote and coordinate the deployment of caching hierarchies in Europe ii linking these with initiatives in the US (NLANR) iii coordination with other work on caching in Europe (DESIRE, INSIGHT, etc) iv providing documentation, information and assistance for those wishing to start a caching service though these are, of course, subject to change if the task force so decides. As a kick off, we have created a task force mailing list for those interested. If you would like to join, send a message to: mailserver(a)terena.nl containing only the text: subscribe tf-cache Your Real Name replacing "Your Real Name" as appropriate. Alternatively, if you already have a national-level mailing list and would prefer to add this, please send a message to tf-cache-request(a)terena.nl. TERENA task forces and working groups are open to all. Please contact me if you have any queries/comments or see http://www.terena.nl/tech/projects/choc/ for more details. Feel free to forward this to any parties you think might be interested. Regards, John Martin TERENA

1 0

New Document available: ripe-139
by RIPE NCC Document Annoucement Service 26 Jul '96

26 Jul '96

New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-139 Title: RIPE Network Coordination Centre Annual Report 1995 Author: C. Orange Date: 25 July 1996 Format: PS=94820 TXT=17716 bytes Obsoletes: Obsoleted by: Updates: Updated by: See also: ripe-113 Short content description ------------------------- The RIPE NCC Annual Report for 1995 has now been published. In this report, we provide a summary of our income, activities and expenditure during the 1995 calendar year. Carol Orange RIPE NCC FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-139.txt for the ASCII version ripe-139.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server(a)ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. SEND ripe/docs/ripe-139.txt

1 0

IAB/IESG Statement on Cryptography
by Daniel Karrenberg 25 Jul '96

25 Jul '96

Dear Colleagues, security and the use of cryptography is a major issue for further development of the Internet. The statement below is very well done and quite comprehensive. It should be distributed widely and especially to any policymaker you know. I also propose that RIPE formally endorse this statement as soon as possible. Daniel ------- Forwarded Message Date: Wed, 24 Jul 1996 08:21:59 +0200 (MET DST) From: Brian Carpenter CERN-CN <brian(a)dxcoms.cern.ch> Sender: ietf-request(a)ietf.org To: ietf(a)ietf.org Subject: IAB/IESG statement on cryptography IETF, FYI, the IAB and IESG have just requested the Internet Society to release the attached statement to the press on our behalf. (The copyright tag at the end is purely to protect the text against misuse.) We intend to publish this as an informational RFC for the record. Brian Carpenter - --- IAB and IESG statement on cryptographic technology and the Internet - ------------------------------------------------------------------- July 24, 1996 The Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG), the bodies which oversee architecture and standards for the Internet, are concerned by the need for increased protection of international commercial transactions on the Internet, and by the need to offer all Internet users an adequate degree of privacy. Security mechanisms being developed in the Internet Engineering Task Force to meet these needs require and depend on the international use of adequate cryptographic technology. Ready access to such technology is therefore a key factor in the future growth of the Internet as a motor for international commerce and communication. The IAB and IESG are therefore disturbed to note that various governments have actual or proposed policies on access to cryptographic technology that either: (a) impose restrictions by implementing export controls; and/or (b) restrict commercial and private users to weak and inadequate mechanisms such as short cryptographic keys; and/or (c) mandate that private decryption keys should be in the hands of the government or of some other third party; and/or (d) prohibit the use of cryptology entirely, or permit it only to specially authorized organizations. We believe that such policies are against the interests of consumers and the business community, are largely irrelevant to issues of military security, and provide only a marginal or illusory benefit to law enforcement agencies, as discussed below. The IAB and IESG would like to encourage policies that allow ready access to uniform strong cryptographic technology for all Internet users in all countries. The IAB and IESG claim: The Internet is becoming the predominant vehicle for electronic commerce and information exchange. It is essential that the support structure for these activities can be trusted. Encryption is not a secret technology monopolized by any one country, such that export controls can hope to contain its deployment. Any hobbyist can program a PC to do powerful encryption. Many algorithms are well documented, some with source code available in textbooks. Export controls on encryption place companies in that country at a competitive disadvantage. Their competitors from countries without export restrictions can sell systems whose only design constraint is being secure, and easy to use. Usage controls on encryption will also place companies in that country at a competitive disadvantage because these companies cannot securely and easily engage in electronic commerce. Escrow mechanisms inevitably weaken the security of the overall cryptographic system, by creating new points of vulnerability that can and will be attacked. Export controls and usage controls are slowing the deployment of security at the same time as the Internet is exponentially increasing in size and attackers are increasing in sophistication. This puts users in a dangerous position as they are forced to rely on insecure electronic communication. TECHNICAL ANALYSIS - -------------------------- KEY SIZE It is not acceptable to restrict the use or export of cryptosystems based on their key size. Systems that are breakable by one country will be breakable by others, possibly unfriendly ones. Large corporations and even criminal enterprises have the resources to break many cryptosystems. Furthermore, conversations often need to be protected for years to come; as computers increase in speed, key sizes that were once out of reach of cryptanalysis will become insecure. PUBLIC KEY INFRASTRUCTURE Use of public key cryptography often requires the existence of a "certification authority". That is, some third party must sign a string containing the user's identity and public key. In turn, the third party's key is often signed by a higher-level certification authority. Such a structure is legitimate and necessary. Indeed, many governments will and should run their own CAs, if only to protect citizens' transactions with their governments. But certification authorities should not be confused with escrow centers. Escrow centers are repositories for private keys, while certification authorities deal with public keys. Indeed, sound cryptographic practice dictates that users never reveal their private keys to anyone, even the certification authority. KEYS SHOULD NOT BE REVEALABLE The security of a modern cryptosystem rests entirely on the secrecy of the keys. Accordingly, it is a major principle of system design that to the extent possible, secret keys should never leave their user's secure environment. Key escrow implies that keys must be disclosed in some fashion, a flat-out contradiction of this principle. Any such disclosure weakens the total security of the system. DATA RECOVERY Sometimes escrow systems are touted as being good for the customer because they allow data recovery in the case of lost keys. However, it should be up to the customer to decide whether they would prefer the more secure system in which lost keys mean lost data, or one in which keys are escrowed to be recovered when necessary. Similarly, keys used only for conversations (as opposed to file storage) need never be escrowed. And a system in which the secret key is stored by a government and not by the data owner is certainly not practical for data recovery. SIGNATURE KEYS Keys used for signatures and authentication must never be escrowed. Any third party with access to such keys could impersonate the legitimate owner, creating new opportunities for fraud and deceit. Indeed, a user who wished to repudiate a transaction could claim that his or her escrowed key was used, putting the onus on that party. If a government escrowed the keys, a defendant could claim that the evidence had been forged by the government, thereby making prosecution much more difficult. For electronic commerce, non-repudiation is one of the most important uses for cryptography; and non-repudiation depends on the assumption that only the user has access to the private key. PROTECTION OF THE EXISTING INFRASTRUCTURE In some cases, it is technically feasible to use cryptographic operations that do not involve secrecy. While this may suffice in some cases, much of the existing technical and commercial infrastructure cannot be protected in this way. For example, conventional passwords, credit card numbers, and the like must be protected by strong encryption, even though some day more sophisticated techniques may replace them. Encryption can be added on quite easily; wholesale changes to diverse systems cannot. CONFLICTING INTERNATIONAL POLICIES Conflicting restrictions on encryption often force an international company to use a weak encryption system, in order to satisfy legal requirements in two or more different countries. Ironically, in such cases either nation might consider the other an adversary against whom commercial enterprises should use strong cryptography. Clearly, key escrow is not a suitable compromise, since neither country would want to disclose keys to the other. MULTIPLE ENCRYPTION Even if escrowed encryption schemes are used, there is nothing to prevent someone from using another encryption scheme first. Certainly, any serious malefactors would do this; the outer encryption layer, which would use an escrowed scheme, would be used to divert suspicion. ESCROW OF PRIVATE KEYS WON'T NECESSARILY ALLOW DATA DECRYPTION A major threat to users of cryptographic systems is the theft of long-term keys (perhaps by a hacker), either before or after a sensitive conversation. To counter this threat, schemes with "perfect forward secrecy" are often employed. If PFS is used, the attacker must be in control of the machine during the actual conversation. But PFS is generally incompatible with schemes involving escrow of private keys. (This is an oversimplification, but a full analysis would be too lengthy for this document.) CONCLUSIONS - -------------------------- As more and more companies connect to the Internet, and as more and more commerce takes place there, security is becoming more and more critical. Cryptography is the most powerful single tool that users can use to secure the Internet. Knowingly making that tool weaker threatens their ability to do so, and has no proven benefit. - ---- The Internet Architecture Board is described at http://www.iab.org/iab The Internet Engineering Task Force and the Internet Engineering Steering Group are described at http://www.ietf.org - ---- (C) Internet Society 1996. Reproduction or translation of the complete document, but not of extracts, including this notice, is freely permitted. (ends) ------- End of Forwarded Message

1 0

Re: Bit tax
by Dave Morton 24 Jul '96

24 Jul '96

Hmm - in the Group of Experts this Soete character is associated with - guess who..... Mr. Luc Soete MERIT Must be a different organistation that the MERIT we know :-) Dave

2 1

Bit tax
by Michael Walsh 24 Jul '96

24 Jul '96

The bit tax is not just evidence of Belgian ministerial sense of humour. Refer to the EU ISPO server for information on the recent advice to the EU on the matter. The report is at http://www.ispo.cec.be/hleg/hleg.html A recent edition of New Scientist did a 2 page spread on the subject, referencing European and US thinking, and noting some existing practices in the US, Canada and Germany. Regards, Michael Walsh. http://www.ispo.cec.be/hleg/bittax.html > Internet and its taxation > > Question: > > Dear Soete > my name Gabriel and I come from Italy. If you know the Italian > situation about Internet's phoenomenon, you'll comprehend the reason I > have had to write you. I think it isn't only a problem regarding our > Italians but even all the others and the same Internet. I have heard > you want to tax Internet providers and the eletronic mail. With all > honesty, I had imagined this thing; You'll have thought:" If people > use more fax and Internet e-mail to mail their letters and what must > be sent, we must tax Internet". I don't know if you'll have thought in > this way, but, even if it's true or false, this decision of taxing > Internet, is mistaken. > > Look at Internet and think about it; it's our future; a future made by > the digital era. Internet has grown for three reasons: its freedom, > its cheapness; and its confort. The most important factor is the > second; in fact it's enough if we must pay a provider and the phone; > if you'll tax Internet, there will be not many to have this privilege. > > If you'll tax e-mail there will be less people, and less letters, and, > on this way, less initiatives; Without these initiatives, at the end, > Internet will die and I don't think you want this. > > I want you think about your decision, because, even if you don't > believe it, Internet destiny is on your hands. > > Gabriel alopex(a)iol.it > > ---------------------------------------------------------------------- > > Asnwer: > > Dear Gabriele, > Thanks for your message. Obviously, I fully understand your concerns. > Let me simply explain what we are suggesting. First, we are not > proposing that a bit tax be introduced, only that one would study the > feasability of such a tax, the impact it would have on e.g. INTERNET > use, on competitiveness, etc. If having studied it, it looks as if any > form of bit tax would dramatically reduce use as you suggest is the > case, then of course one should refrain from introducing such taxing > system. In other words, we are keeping a completely open mind about > it, however, I cannot imagine why people would be against the idea of > studying its feasability and possible impact. > > Second, the reason why a bit tax might be an interesting new tax > concept is in the first instance based on the fact that more and more > economic activity is taking place through electronic transmission of > bits. In other words if society is moving into the direction of an > Information Society, the tax basis of society should also shift in > that direction. Otherwise we would have ended up today with only the > "corn tax" of 150 years ago to pay for all government expenditures. > > Third, as in the case of the environment (e.g. free clean air), there > will be in the case of "free" information, "negative externalities > under the form of "information pollution". Forcing the provider or > user of information to pay a small tax per bit, will force them to > generate at least some value, which might consequently reduce the > amount of overinformation. > > Fourth our proposal is to use the income generated through the bit tax > to reduce the cost of labour in the economy, e.g. through reducing the > employers social security contributions. The impact on growth and > employment will in all likelihood be substantial, which is at the > moment what frustrates us most, i.e. that the emerging Information > Society is creating so little value in our economies and so few jobs. > > Finally, let me add that with respect to education establishments, > hospitals, community services, etc., one could easily imagine that > those would all be excluded from having to pay a bit tax or > alternatively would get the amount back on the basis of some new > concept of unversal "community" service. In other words, the desire of > many users to use Internet to communicate cheaply would still be > maintained. However, they wouldn't be able to do this from their work, > home or commercial surroundings, but would have to go to their local > community service. > > I hope this clarifies my position, > with best regards, > Luc Soete

2 1

Re: Tools for managing IP address space
by Willi Huber 20 Jul '96

20 Jul '96

> >does anybody of you use some tool to managed IP address space in a classless > >environment for a bigger organization? > > Willi > have you seen Nigel Titley's 'tree' programme - it might > be what you want. Find it at > > ftp://ftp.bt.net/networking/tools/tree/tree-2.1.5.tar.Z > > Cheers. > > Mike Many thanks to all, that answered. I will have a look at Tree. Regards, Willi

1 0

Tools for managing IP address space
by Willi Huber 19 Jul '96

19 Jul '96

Hallo, does anybody of you use some tool to managed IP address space in a classless environment for a bigger organization? Any tips welcome. Regards, Willi Huber

4 3

The NCC Web Site
by Carol Orange 16 Jul '96

16 Jul '96

We'd like to take a minute to respond to the comments posted in the last few days about the new Web site. Some of the comments were not sent to the ripe-list, only to one or two people here. First of all, we want to thank those of you who have sent in comments for your interest in the site. We are sorry for the teething troubles and appreciative of your patience. 1. Access Although we chose to use frames in the browsers that support them, the web site was designed from the outset to be accessible by simple browsers such as Lynx. Unfortunately, the automatic selection had a flaw that prevented access by browsers which did not allow one to load another page directly. For those of you who could not reach the site because there was no support for no-frame browsers during the weekend, you might like to know that immediately following the launch, we were fair and impartial :-). Our web site was inaccessible regardless of your browser. At this point, the web site should be accessible with whatever browser you are using. Certainly there was never an intention to prevent access to the site with non-Netscape browsers. If at any point, you find you can't access our web site with an arbitrary browser, please let us know. It is most definitely not by design. 2. Content We are glad to hear that most people find the information available on the web site to be of use. We hope to keep it that way and hope that you won't hesitate to inform us when new information would be useful. 2.1 List of documents We've been asked to put titles next to the list of ripe-xxx document names. We've also been asked to list the documents in a table, so the entire list can be viewed without scrolling. Both of these views will be supported in the near future. 2.2 RFC Access There's been a suggestion that the RFCs should be accessible from our web site. While the RFC's are still accessible via our ftp server, we've not put pointers to them on our web site. This should not be difficult and we will be happy to do so if there is sufficient interest. Please send a note to webmaster(a)ripe.net if this service would be of use to you. 3. Frames/No Frames Controversy That is the question. The decision to incorporate the use of frames in the design of the RIPE NCC web site was based on carefully weighted user interface design principles. It was influenced by the response to the survey posted on our old web site in which the vast majority of respondents indicated that they would happily wait a little longer if it would result in a more easily navigated web site. Except for the trouble with moving between frames which works differently than moving between pages, we believed that using frames would enable easy navigation. Another principle applied throughout the design of the site was "keep it simple". The graphics are minimal and consistent throughout. This was so the web page would load quickly. The graphics that appear beyond the home page are the same as those on the home page, and are therefore only loaded when the site is first accessed. We also consider it essential that important information stand out rather than that our site be "glossy". Because the discussions on the ripe list in the last couple of days indicate that a number of people who access the site would greatly appreciate a more minimal design (e.g. the text only version), we will take steps to ease access to the no-frames version. In addition to a (to-be-included) no-frames button on the menubar of the site, the no-frames version of the site is now also available in: http://www.ripe.net/noframes.html This is for those who want the no-frames version when the automatic selection process would give them the framed version by default. As stated by Daniel in an earlier message: There were basically three choices we could make: 1) Determine the browser's capabilities and choose a version accordingly. 2) Always show a selection page for the user before showing the home page. 3) Always show the non-fancy home page with a selection button to choose the fancy version. In the coming months we will examine access statistics to find out how much different pages are accessed. In general, the results will be used to determine what modifications might make the site more useful. If the no-frames version of the home page is sufficiently popular, we will make it the default, and make the framed version accessible via a button on the home page and another URL. Anyone with views on this subject is encouraged to send them to webmaster(a)ripe.net. They will be collected and considered together with the statistics in the next couple of months. 4. Navigating in Frames As noted in other mails, the right mouse button can be used to move back in frames. As also noted, this does not work 100% of the time. 5. The Documents Currently we are still smoothing out some minor formatting problems in the document pages. Moreover, it seems the Reference section has been stripped off ripe-136. Both problems are being pursued at this time. That's it for now. Please keep us informed of any problems you have. Kind regards, Carol Orange - RIPE NCC Web Site Coordinator Lee Wilmot - RIPE NCC Web Master

1 0

Re: Web Site Launch
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 16 Jul '96

16 Jul '96

>Date: Mon, 15 Jul 1996 10:23:05 +0200 >From: Berthold Paffrath <bp(a)nic.dtag.de> > >My problem is, as with all these new frame-based web sites: If I follow >some links up to "Registries ordered by country code", then select one >of these - how do I go "one page back" to the overview? The "<-" button >of netscape just leads me to the previous non-framed web site... >This might be a netscape bug, but it seems that explicit "back" buttons >would be helpful until the bug gets fixed :-) My problem is, as with all these flame-based web sites ... Even http://www.netscape.com/ shows its home-page to poor man's browsers, why can't the RIPE-NCC ? I always thought the RIPE-NCC is a technical network coordination centre whose info's should be accessible as broadly as possible and not a shopping-mall for Netscape shareholders (sorry for this one ;-} Please make your info-site "Lynx"able again, and make all Java/Frames and other "kinky" features optional ! My personal opinion, anyway, always interested in others of course ! Christian

8 10

Re: Web Site Launch
by Denis.Russell＠ncl.ac.uk 15 Jul '96

15 Jul '96

At 9:22 am 15/7/96, Carl Malamud [IMS] wrote: >Folks ... >... >Seems to me that the secretariat worked very hard and did a >wonderful job.... Carl, You are absolutely right!! Nit picking is easy, but not nearly as easy as forgetting to say thanks for the work itself. All of us in various kinds of service organization *should* remember that, but I guess we each get trained in nit-picking by our "customers". :-( So, a big "Thankyou" for the new site. It is a job well done and I do appreciate it. Denis.

1 0

Re: Web Site Launch
by Denis.Russell＠ncl.ac.uk 15 Jul '96

15 Jul '96

At 10:23 am 15/7/96, Berthold Paffrath wrote: >... >My problem is, <...> - how do I go "one page back" to the overview?... I agree, and sent in a similar comment! Denis.

3 2

RE: Web Site Launch
by Christian Panigl, ACOnet/UniVie +43 1 4065822-383 15 Jul '96

15 Jul '96

Hi Daniel and Carol, first of all, thank you, it's working now ! I just tried it again with (some really outdated) Mosaic, EnhancedMosaic and Lynx versions and always got a nice and readable standard HTML-homepage ! >There were basically three choices we could make: > >1) Determine the browser's capabilities and choose a version accordingly. Nice, but didn't work properly until recently. It's OK now. >2) Always show a selection page for the user before showing the home page not very elegant >3) Always show the non-fancy home page with a selection button to choose > the fancy version. not very elegant either, however, preferrable over the other way around ;-) >You seem to favour option three. This one did not fall well with those that >argued our site should look flashy and we whould show off all the design >work we did. :-). I don't ! I'm just favouring reliably working solutions ! As long as option one is falling into this category it's perfectly OK with me ! Regards, Christian

1 0

Web Site Launch
by Carol Orange 15 Jul '96

15 Jul '96

*** Live from the edge of Amsterdam *** The new RIPE NCC Web Site http://www.ripe.net will be officially launched today July 12, 1996 at 16.00 hours! Have a look. Make yourself at home. As with any new Web Site, there are still a few rough spots. Please bear with us as we iron them out. We hope the new site makes information you need easily accessible. Your comments and suggestions are most certainly welcome. Please send them to: webmaster(a)ripe.net. Greetings from the staff of the RIPE NCC. -- Carol Orange

4 4

Re: Bitrate tax.
by Denis.Russell＠ncl.ac.uk 04 Jul '96

04 Jul '96

At 2:26 pm 12/6/96, Eric Luyten wrote: >(NOT a joke) > >The Belgian Minister for Telecommunications came up with the idea of >introducing a "bitrate tax" on information transmission. ... ><double sigh> >Eric. Communications Week International for 24th June runs the story in page 3: "Electric levy could mean a taxing time for Belgians" by Camille Mendler. The writer tries to fan the embers of a story into a fire by the likes of "...cynics contend that it is no coincidence that Di Rupo (credited with inventing the tax) is from the southern French-speaking region (...) the tax is simply a ruse to bring financial relief into the largely rural region". They clearly havn't heard of the *advantage* that telematics can bring to rural regions and that such regions are disadvantaged by high cost. Again "...analysts insist that monitoring data could be interpreted as an invasion of privacy under current EC laws". Clearly they havn't been following the attempts by the EC to insist on a Euro-Clipper chip. Ho hum. :-( Denis.

1 0

error in previous hostcount mail
by Mirjam Kuehne 03 Jul '96

03 Jul '96

Hi all, An error has crept in the hostcount I've just sent out: The SK domain showed 0 hosts (and even in the wrong column ;) I counted the SK again and the results had some influence on the totals. I'll attach the whole table again. The table now shows an increase since last month of over 170,000 (or 6.3%) to a total of over 2,900,000 hosts in the DNS in Europe. It also slipped my mind that we past another Quarter: During the last three month the number of hosts in the European showed a total increase of 17.1% If you have further questions (or spot more errors ;), please don't hesitate to contact me. Kind regards, Mirjam Kuehne RIPE NCC RIPE DNS Hostcount Previous Count : Fri May 31 1996 This Count : Mon Jun 30 1996 CY SOA COUNTED DUPL REAL CHANGE ============================================================ al 5 78 0 78 - 1 am 6 129 7 122 + 6 at 2174 80365 6611 73754 + 4303 az 3 16 0 16 0 be 2210 43946 1919 42027 + 2727 bg 94 2071 86 1985 + 151 by 14 128 2 126 + 27 ch 3287 107616 4403 103213 + 3809 cy 91 929 14 915 + 219 cz 816 33064 725 32339 + 1941 de 13424 603759 27463 576296 +32152 dk 1882 78554 3622 74932 + 5878 dz 2 18 0 18 + 2 ee 311 6617 203 6414 + 704 eg 25 834 9 825 + 22 es 2090 80537 1271 79266 + 2689 fi 2242 300397 4877 295520 +25211 fo 20 75 0 75 + 54 fr 3844 192085 5384 186701 +18671 gb 2 40 0 40 0 ge 10 114 1 113 + 21 gr 503 12846 727 12119 + 956 hr 277 3662 703 2959 - 239 hu 633 25733 547 25186 + 1505 ie 839 20933 331 20602 + 1877 il 1143 40092 2549 37543 - 1291 is 174 10476 95 10381 + 232 it 4957 121306 9643 111663 + 5207 li 36 124 16 108 + 27 lt 80 1259 9 1250 + 37 lu 158 2829 59 2770 + 288 lv 98 4482 111 4371 + 377 ma 12 345 10 335 - 2 md 10 10 0 10 + 2 mk 14 163 17 146 + 13 mt 32 473 86 387 + 29 nl 4540 214692 4419 210273 + 4885 no 3447 121776 4895 116881 + 5953 pl 1104 39947 1558 38389 + 1998 pt 507 15887 372 15515 + 1199 ro 275 3685 158 3527 + 259 ru 1225 32895 2404 30491 + 9071 se 6016 193416 8483 184933 + 6367 si 390 9475 785 8690 - 216 sk 200 4928 191 4737 + 73 sm 9 432 190 242 + 42 su 484 14331 692 13639 + 332 tn 3 45 4 41 - 5 tr 334 10998 285 10713 + 925 ua 182 4397 745 3652 - 506 uk 20219 619716 57062 562654 +32122 va 2 3 0 3 0 yu 53 1082 24 1058 + 949 ============================================================ 80510 3063810 153783 2910043 +171052

1 0

Hostcount for June 1996
by Mirjam Kuehne 03 Jul '96

03 Jul '96

Dear all, Here is the hostcount for June 1996. The table shows an increase since last month of over 160,000 (or 6.1%) to a total of over 2,900,000 hosts in the DNS in Europe. DE shows the highest increase for June with more than 32,000 hosts more than in May. The hostcount can also be found under ftp://ftp.ripe.net/ripe/hostcount. The graphical version of the hostcount can be found at ftp://ftp.ripe.net/ripe/hostcount/RIPE-Hostcount-{Mo,Qu}.eps The translation of the country codes can be found at ftp://ftp.ripe.net/iso3166-countrycodes I would like to thank all people who help me to create the hostcount every month by counting hosts locally: at Gerhard Winkler <winkler(a)cc.univie.ac.at> be Herman Moons <Herman.Moons(a)CS.kuleuven.ac.be> ch Christoph Graf <graf(a)chx400.switch.ch> cy Panagiotis Tzounakis <pj(a)ics.forth.gr> cz Jiri Orsag <Jiri.Orsag(a)eunet.cz> de Peter Koch <pk(a)TechFak.Uni-Bielefeld.DE> dk Robert Martin-Legene <robert(a)dknet.dk> es Jose Sanchez-Seco <jose.sanchez(a)rediris.es> fi Petri Ojala <ojala(a)eunet.fi> fr Annie Renard <Annie.Renard(a)inria.fr> gr Dimitris Zisiadis <zisiadis(a)forthnet.gr> hr Ivan Maric <Ivan.Maric(a)stribor.srce.hr> hu Gabor Kiss <kissg(a)sztaki.hu> ie Mike Norris <mnorris(a)dalkey.hea.ie> il Sason Levi <sason(a)NetVision.net.il> it Antonio_Blasco Bonito <bonito(a)nis.garr.it> no Havard Eidnes <Havard.Eidnes(a)runit.sintef.no> pl Irek Neska <irek(a)nask.pl> pt Armando Domingues <fccn(a)dns.pt> ru Andrey Dobrotsvetov <adbr(a)ripen.net> sk Ivan Lescak <Ivan.Lescak(a)Slovakia.EU.net> Lubos Elias <Lubos.Elias(a)uakom.sk> sm Antonio_Blasco Bonito <bonito(a)nis.garr.it> tr Yener Yigit <yener(a)knidos.cc.metu.edu.tr> uk Kevin Hoadley <K.Hoadley(a)nosc.ja.net> If you have any questions, please don't hesitate to contact me. Kind regards, Mirjam Kuehne RIPE NCC RIPE DNS Hostcount Previous Count : Fri May 31 1996 This Count : Mon Jun 30 1996 CY SOA COUNTED DUPL REAL CHANGE ============================================================ al 5 78 0 78 - 1 am 6 129 7 122 + 6 at 2174 80365 6611 73754 + 4303 az 3 16 0 16 0 be 2210 43946 1919 42027 + 2727 bg 94 2071 86 1985 + 151 by 14 128 2 126 + 27 ch 3287 107616 4403 103213 + 3809 cy 91 929 14 915 + 219 cz 816 33064 725 32339 + 1941 de 13424 603759 27463 576296 +32152 dk 1882 78554 3622 74932 + 5878 dz 2 18 0 18 + 2 ee 311 6617 203 6414 + 704 eg 25 834 9 825 + 22 es 2090 80537 1271 79266 + 2689 fi 2242 300397 4877 295520 +25211 fo 20 75 0 75 + 54 fr 3844 192085 5384 186701 +18671 gb 2 40 0 40 0 ge 10 114 1 113 + 21 gr 503 12846 727 12119 + 956 hr 277 3662 703 2959 - 239 hu 633 25733 547 25186 + 1505 ie 839 20933 331 20602 + 1877 il 1143 40092 2549 37543 - 1291 is 174 10476 95 10381 + 232 it 4957 121306 9643 111663 + 5207 li 36 124 16 108 + 27 lt 80 1259 9 1250 + 37 lu 158 2829 59 2770 + 288 lv 98 4482 111 4371 + 377 ma 12 345 10 335 - 2 md 10 10 0 10 + 2 mk 14 163 17 146 + 13 mt 32 473 86 387 + 29 nl 4540 214692 4419 210273 + 4885 no 3447 121776 4895 116881 + 5953 pl 1104 39947 1558 38389 + 1998 pt 507 15887 372 15515 + 1199 ro 275 3685 158 3527 + 259 ru 1225 32895 2404 30491 + 9071 se 6016 193416 8483 184933 + 6367 si 390 9475 785 8690 - 216 sk 197 4872 208 0 - 4664 sm 9 432 190 242 + 42 su 484 14331 692 13639 + 332 tn 3 45 4 41 - 5 tr 334 10998 285 10713 + 925 ua 182 4397 745 3652 - 506 uk 20219 619716 57062 562654 +32122 va 2 3 0 3 0 yu 53 1082 24 1058 + 949 ============================================================ 80507 3063754 153784 2905306 +166315

1 0