November 1999 - lir-wg - mailman.ripe.net

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '01

24 Jun '01

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

3 3

RIPE 34 LIR WG Draft Minutes 1.0
by hph＠a.sol.no 19 Dec '99

19 Dec '99

Thanks to Eamonn for poduccing detailed minutes from our last meeting. Please feel free to mail me or the list comments or clearifications. RIPE 34 LIR-WG DRAFT Minutes 1.0 Chair: Hans Petter Holen Scribe: Eamonn McGuiness Agenda 1. Admin scribe distribute participants list charter mailing lists 2. Additional agenda points 3. Introduction of the new Registration Service Manager, Nurani Nimpuno Meet the RIPE NCC hostmasters 4. RIPE 33 minutes actions 5. Reports from the Regional Internet Registries 6. The RIPE community policy making process (Mirjam Kuhne, RIPE NCC) Discussion: Is this well understood? 7. ICANN - ASO Current status, further work. Definition of the selection procedure for the address council 8. Auditing Results and experiences (Mirjam Kuhne, RIPE NCC) 9. Discuss an additonal value for inetnum status attribute (James Aldridge, EUnet) 10. PGP authentication of e-mails to and from hostmaster(a)ripe.net (Maldwyn Morris, RIPE NCC) 11. Release of rtt source code (Maldwyn Morris, RIPE NCC) 12. AOB 12.1 IPv6 policy matters (move to LIR WG?) 12.2 mnt-by from mandatory to optional (Wilfried Woeber, ACONET) 12.3 PI address assignments to end-users (Eyal Yaniv, Netvision Ltd.) 12.4 DB support for multiple Domain objects 1. Admin Eamonn McGuiness volunteered to take notes. The participant list was circulated and signed by approximately 89 attendees. The Working group web pages and mailing list were pointed at: Mailing list: lir-wg(a)ripe.net Archive: http://www.ripe.net/mail-archives/lir-wg/index.html Web pages: http://www.ripe.net/wg/lir/index.html The Local IR working group deals with issues that concern Local Internet Registries. For example, Local IR operation, and the local implementation of RIPE policies and procedures are discussed here. There was consensus that we may need a better formulated charter stating that the LIR-WG is the open forum where RIPE policy is made. ACTION LIR-34.1 on Chair to suggest clarification of WG charter. 2. Agenda The agenda previously circulated to the lir-wg list, was approved and the following items were added to Any Other Business: Wilfried Woeber: RIPE NCC Auditing Activity Eyal Yaniv: PI Assignments 3. Presentation of RIPE Hostmasters The new Registration Services Manager Nurani Nimpuno was introduced. Paula Caslav left the RIPE NCC to go back to the US. Also all hostmasters present at the meeting were introduced to the audience. 4. Actions All actions from RIPE 32 were done before RIPE 33. There were no additional action points from RIPE 33. The WG minutes (published as part of the plenary minutes) from RIPE 32 were approved. 5. Reports from the Regional Internet Registries 5.1. Report from the RIPE NCC Registration Services Activities (Mirjam Kuhne) See http://www.ripe.net/meetings/ripe/ripe-34/pres/ Some highlights of the developments since the last meeting: Beginning of the year almost 2 new members per calendar day. This has now slowed down, but is still higher than the last few years, approximately 1.5 new members per calendar day. Those new members tend to grow slower than members used to in the past. This means that the workload is not increasing proportionally to the number of new members. Due to automation and efficient procedures, there was no major staff increase even though the number of new members has grown. The RIPE NCC has started allocating IPv6 addresses, 6 sub-TLAs allocated so far, smooth start. The RIPE NCC proposes to change the procedures for reverse delegation such that only members can submit requests for reverse delegation. This would decrease the workload of the RIPE NCC and increase the quality of the DNS. This issue will further be discussed on the lir-wg mailing list to understand all aspects of such a change. This item was added to AOB for further discussion but due to time shortage it was concluded with the following action: ACTION LIR-34.2 on RIPE NCC to start discussion on changing the reverse delegation policies, and make sure all aspects of it are fully understood. The RIPE NCC is currently busy updating and improving the LIR Training Course material and delivery. This will be ready before the next RIPE Meeting. A few questions were raised after the presentation: Q: Is there a deadline for the change in procedure for reverse delegation? A: Before the end of the year: We are currently re-writing the inaddr robot and would like to implement this change at the same time. Comment: We need to think about the implications for address space originally assigned by last resort registries. Q: Test Traffic Measurement will be part of membership services in 2000. How will the RIPE NCC charge for it? A: It will be a different type of membership service than registration services, because the users are not necessarily the same. We are slowly moving TTM in this direction and need to further investigate an exact charging scheme for it. Q: Are all statistics shown during the presentation also visible on the web site and are they kept up to date? A: They will be stored on the web site as part of the presentation, but we will also put them on the statistics pages. ACTION LIR-34.3 RIPE NCC: store statistics on web site and keep them up to date. Q: Can we get support from the RIPE NCC for addresses that have been assigned by the InterNIC? A: Yes, you can, we currently provide administrative support for our members. We are also working on a more structural solution, so that the assignments are stored in the DB of the region the network is operated in, even if the addresses have been originally assigned by the InterNIC. We will also work together on a technical solution for a distributed reverse delegation. 5.2. Report from the APNIC (Kyoko Day) See http://www.ripe.net/meetings/ripe/ripe-34/pres/ Some highlights: IP distribution is growing in the region even though there was a dip due to the economic crisis in Asia. The growth during this year is mainly due growth in India and Australia. Priorities for the next period: review of the APNIC membership-charging scheme. Currently the categories Small, Medium, Large are self-determined (like the RIPE NCC charging scheme was before 1997). 5.3. Report from ARIN Unfortunately no one from ARIN could attend the Meeting. Mirjam Kuhne announces that ARIN will hold their AGM in October in conjunction with a first open policy meeting and the second meeting of ARIN WGs (18.10. - 20.10.1999) 5.4. Reports from other regions At the ICANN Meeting in Santiago in August ICANN welcomed the developments in Africa and Latin America. In Latin America various groups have been co-operating and form the LatinNIC, they proposed a draft paper, which they asked the existing RIRs to review. The Interim Board of the AfriNIC is currently reviewing proposals of potential AfriNIC hosts. 6. Policy Development in the RIPE community Mirjam Kuhne gave a presentation to describe how policy is developed in this region and how people can participate in this process. See http://www.ripe.net/meetings/ripe/ripe-34/pres/ for details. The process is simple, open to anyone and based on consensus. The WG Participants were in agreement that these are true open processes and that there is no need to change them. During the discussion that followed it became apparent that more effort must be spent to make the existence of RIPE known to the outside world and to clearly distinguish it from the RIPE NCC. A comment was made that the RIPE community and the RIPE NCC membership is mainly comprised of small ISPs and that the policies and guidelines are sometimes difficult to be implemented by larger ISPs. Hans Petter understands the concern, but has experienced that difficult or unusual cases were handled on a case by case bases usually solved in the end. The question was raised if there is a voting procedure to finalise agreements and policies? Hans Petter clarifies that there is normally general agreement and a voting procedure was not necessary. Someone thinks that people might be intimidated to speak up on the mailing list and that LIRs in particular might be afraid that their performance as LIR will be questions if they raise their opinion on the mailing list. Mirjam clarifies that the RIPE WG mailing lists are open and independent and not directly linked with the operations of the RIPE NCC and individual members. Maybe this needs to be made known more widely. ACTION LIR-34.4 on the Chair to form a Task Force to document and publish the current procedures for policy development. Volunteers to this task force were to contact the chair after the meeting. Further process will be: - announce the charter of the task force to the mailinglist - Interested parties may volunteer - A draft will be posted to lir-wg for discussion - A second draft will be based on that discussion - The document will be endorsed by consensus at RIPE 35 The outcome of this task force will be useful not only to the working group members but also externally to promote the openness of RIPE. 7. ICANN - ASO The LIR-WG needs to discuss and define the selection procedure for the RIPE region nominees of the ASO Address Council. The WG chair had asked Rob Blokzijl, the chair of RIPE, to chair this part of the discussion because the WG chair was among the nominees for the Address Council. This is the first time the RIPE community needs to define a procedure to select representatives to external bodies. This task is particularly difficult, because ICANN has introduced some time pressure: They would like to have ICANN directors elected by the beginning of October. As the ICANN directors are to be selected by the address council the address council needs to be selected at this very RIPE meeting. Therefor the carefully defined time schedules and deadline for the set up of the Address Council and the selection of the ICANN directors can not be followed. The RIPE community therefor needs to define an interim procedure for the initial set of Address Council members. In the time before the next RIPE meting the procedure needs to be revisited and refined. Each candidate submitted a paragraph to motivate why they think they are suitable for the Address Council. This has been made available on the RIPE Web pages and copied and distributed among the audience. 3 of the 8 nominees were present at the LIR-WG meeting. There was a discussion if the initial candidates should only serve one year or if they should be prepared to serve 1, 2 and 3 years as defined in the ASO MoU. The audience agrees that it would create instability if all members would change after one year and that they should serve 1, 2 and 3 years respectively. It was suggested that the address council at their own discretion may ask their seat to be reconfirmed by the procedures yet to be defined. This Q: Why was self-nomination was allowed. A: It is an open process, if a person believes he or she is a suitable candidate, why should he or she not nominate him or herself? Q: Can't we use the same procedure that is used for the RIPE NCC executive board? A: The problem is that the RIPE NCC membership is a clearly defined electorate, but in this case the electorate can not clearly be identified. The audience dismissed an e-mail selection process for many reasons. One was the time frame forced upon us, other being the too difficulty to verify correct votes. An attempt was made to find general criteria in order to make a possible pre-selection. Finally it was suggested to organise an open ballot at the plenary session. Gordon Lennox from DG-XIII, European Commission warned the WG not to fall into the trap of pure voting. He admires the open and transparent processes in the RIPE community and urges the audience to make sure to have some sort of consensus decision incorporated in the procedure, either before the voting or after to endorse the decision. ACTION LIR-34.5 on Rob Blokzijl to summarise this discussion and present it at the plenary session the following day. Several ideas for the final procedures were suggested: to look at USENET voting, the IETF procedures and the RIPE NCC Association procedures. These will be further discussed on the lir-wg list. ACTION LIR-34.6 on the Chair to form at task force to define final Address council selection procedure. 8. Auditing Activity at the RIPE NCC (Mirjam Kuhne) See http://www.ripe.net/meetings/ripe/ripe-34/pres/ Mirjam clarifies that this activity has been initiated by the LIR-WG in order to ensure fair distribution of address space. She shows statistics that have been derived after having performed this activity for more than a year now. In summary it can be noted that many LIRs are familiar with policies and procedures and apply them. One area of attention is the RIPE database. The RIPE NCC works together with LIRs to maintain and update the information in the database. There was some uncertainty regarding the role of the RIPE NCC member in this process. It was not clear to some attendees if the information provided by the end-user can or needs to be amended before passing on to the RIPE NCC. This is specifically related to documentation, which is provided in local language. After a short discussion it has been agreed that the RIPE NCC requires a certain set of documentation in English. It then depends on the service the LIR provides to their customers. Some LIRs may require their customers to provide the full set of documentation and in English, some LIR may just collect information from their customers (in the local language) and then amend and translate it if sent on to the RIPE NCC. ACTION LIR-34.7 on the RIPE NCC to document the audit procedure in more detail and to clarify the role of the NCC and the member during an audit process and what is expected from each party. 9. Additional value for the status attribute (James Aldridge) James suggests allowing for more hierarchy in the status attribute of the inetnum object. The rationale behind this is to allow "sub allocating" parts of a LIRs address blocks to "sub LIRs". This is important to large (multi national) ISPs. Also Wilfried Woeber is looking for additional values to indicate for instance returned address space that needs to be documented during transition to new. ACTION LIR-34.8 on James (and Wilfried) to write up a proposal and send it to the LIR-WG mailing list. 10. PGP authentication of mails to and from hostmaster(a)ripe.net (Maldwyn Morris, Software Manager RIPE NCC) The RIPE NCC would like to offer PGP authentication for mail sent to the hostmaster(a)ripe.net. In the first instance this will only be used for authentication, not for encryption. There is consensus in the WG that this would be a useful service. As other security mechanisms (e.g. in the RIPE DB) this will not be a requirement but optional. ACTION LIR-34.9 on RIPE NCC to proceed with plans to implement PGP as an option for hostmaster communication. 11. Release of rtt source code (Maldwyn Morris, Software Manager RIPE NCC) There is consensus in the LIR WG that the RIPE NCC may publish the source code of the rtt ticketing system software. ACTION LIR-34.10 on RIPE NCC Release source code to rtt due to demand. 12. Any Other Business 12.1 IPv6 policy matters In principle all address policy related matters should be handled in the LIR-WG. For this meeting the chair had decided not to include Ipv6 policy matters on the agenda, since the agenda already had possibly time-consuming items already. It was argued that participants interested in developing RIPE policy only should have to go to one working group. The chair agrees in principle, but also sees the advantages of keeping the policy discussions in the Ipv6 WG where Ipv6 expertise is sure to be present. It was questioned from the audience what the purpose of the Ipv6 WG would be if not to discuss Ipv6 policy. This was not made particularly clear, but a reference to the work division between the LIR-WG and the DB-WG was made: the policy discussions takes place in the LIR-WG while technical implementation details relating to the database takes place in the DB-WG and is implemented by the RIPE NCC. The chair feels it is premature to make a final decision on this, but senses coming consensus that LIR-WG should do policy development for IPv4 and IPv6. ACTION LIR-34.11 on Chair Discuss moving Ipv6 policy matters to lir-wg. 12.2 PI Assignments (Eyal Yaniv) Eyal wonders if end-users who require PI address space should become RIPE NCC members themselves in order to obtain address space directly from the RIPE NCC. Mirjam clarifies that although it is discouraged to assign PI addresses to end-users it is possible if technically required. These assignments should not be made out of the PA range allocated to the LIR; the RIPE NCC will make these assignments from a separate range in order to avoid holes in the PA range of the LIR. The desire to obtain PI addresses is not a reason in itself to become a RIPE NCC member and to obtain a separate allocation from the RIPE NCC. There was also a clarification to why use of PI addresses is discouraged: this relates to the additional burden that individual route entries for end-users create on the global Internet. The RIPE policy in this area has thus been carefully worded to promote PA addresses and CIDR. It is also worth noting that certain big US providers do not accept fragments of PA addresses from peering partners (but may do so in transit agreements). 12.3 Reverse delegation process -> discussion on lir-wg to fully understand all implications This came up during Mirjams report. Since we had no time left to further discuss the aspects of this it was added to the action list to conclude this discussion on the mailinglist. (See action LIR-34.3) 12.4 DB support for multiple Domain objects Was not discussed. It was suggested to move the discussion to the db wg. Actions: Action Owner Status Description LIR-34.1 Chair Suggest clarification of WG charter LIR-34.2 WG Reverse delegation process -> discussion on lir-wg to fully understand all implications LIR-34.3 NCC Store statistics on web site and keep them up to date. LIR-34.4 Chair Form a task force for documenting the existing policy process LIR-34.5 RB suggest a selection procedure for the plenary LIR.34.6 Chair Form a task force to define final Address council selection procedure LIR-34.7 NCC Clarify LIR-RIR expectations in the audit process LIR-34.8 JA additional value for the inetnum "status" field LIR-34.9 NCC Proceed with plans to implement PGP as an option for hostmaster communication LIR-34.10 NCC Release source code to rtt due to demand LIR-34.11 WG Discuss moving IPv6 policy matters to lir-wg Draft Agenda LIR WG RIPE 35 (as presented to the RIPE 34 plenary) 1. Admin scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters 4. RIPE 34 minutes actions 5. Reports from the Registries RIPE NCC APNIC ARIN Status of the Latin and AFRI NiCs 6. Report from the address council 7. The policy making process 8. Establish final selection procedure for the address council 9. Domain objects in the database 10. AOB

2 1

Top 100 Maintainers List 19991123
by RIPE Database Administration 23 Nov '99

23 Nov '99

1 0

RE: IP assignment for virtual webhosting
by Bhabuta, Denesh 23 Nov '99

23 Nov '99

> You also don't take notice of the fact that RIPE have stated > that they do > not want us to update the RIPE database with our Dial-Up IPs, > the majority > of what you continually show in your little table... I will agree with Sam's sentiments/comments here... RIPE indeed did say that and preferred to receive static verification tables once a week... well it was the case when I worked at Demon... Regards Denesh -- Denesh Bhabuta, AMISM European Internet Services Group Level (3) Communications Limited +44-20-7864-0498 ; denesh.bhabuta(a)level3.com

4 4

IP assignment for virtual webhosting
by Nurani Nimpuno 19 Nov '99

19 Nov '99

Dear LIR-WG, We would like to hear your opinions on the issue of IP assignments for virtual webhosting. The current policy is rather old and in the meantime a lot of things have changed; most importantly the market for webhosting products, as well as the development of the HTTP protocol and related software. TERMINOLOGY Before we begin, however, we would like to address the issue of terminology for this subject. The term 'virtual webhosting' is being used a lot but it is often not clear in which way it should be interpreted. We suggest the following terminology: Server: A physical computer with an operating system installed on it. This could be UNIX, Windows, Mac, or something else. The webserver runs as an application on this OS. Webserver: An application program that accepts connections in order to service requests by sending back responses. That is, a piece of software that runs on a physical server. Examples of webservers are Apache, IIS, and Stronghold. User agent / Client: The client that initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end-user tools. Hostname: A nameserver entry that resolves to an IP address. This could be an A or a CNAME record. Virtual host: A hostname resolving to the IP address of a server, the webserver of which handles several hostnames. IP-based virtual hosting: Many hostnames hosted on the same server, one IP address for each hostname. Namebased virtual hosting: Many hostnames hosted on the same server, all hostnames resolve to the same IP address. OUR SUGGESTION The RIPE NCC has followed the deployment of HTTP 1.1 closely over the past year. According to recent surveys, a vast majority of clients now support HTTP 1.1 (namebased HTTP requests). It is our belief that the majority of webserver applications support namebased webhosting as well. In recent years we have seen a boom in the registration of second-level domains. This has led to a great demand for webhosting services. Using one IP address per domain uses an enormous amount of IP addresses. With HTTP 1.1 this is no longer necessary. We therefore suggest to promote namebased webhosting and to change the current policy so that IP addresses can no longer be assigned for IP-based webhosting. Please provide us with any feedback or comments you might have. Kind regards, Nurani Nimpuno (Registration Services Manager) and Simon Skals (Hostmaster) RIPE NCC

17 17

Re: abusive changes of person handles (protect your maintainer!)
by Wilfried Woeber, UniVie/ACOnet 19 Nov '99

19 Nov '99

Hi Joao! >There are two issues here: >- The use of very weak protection methods (NONE and MAIL-FROM) (see *). wrt the "see *": I think they do have a point in principle. In reality (for many individuals, I suppose :-) it's still more staright-forward to fake a mail-from header than reverse-engineer a crypted password string in itself. However, given the fact that many operatinal environments these days require mail to be shipped multi-hop, the risk of disclosing the (clear text) password is greater than we might want to believe... >Would the community see this change in behaviour as a good thing? Definitely! Wilfried.

2 1

abusive changes of person handles (protect your maintainer!)
by Petra Zeidler 19 Nov '99

19 Nov '99

Hi, peruse the latest case of abusive changes of person handles: person: Thomas Heubach address: FICK-AG - Pornoproductions address: Nymphomanen Str. 37 address: D-80335 Muenchen address: Germany phone: +49 190 666666 nic-hdl: TH849 remarks: Wer Frauen liebt und Fotzen leckt, remarks: der mag auch HARIBOKONFEKT. Ich liebe remarks: Frauen und lecke Fotzen, doch Haribo remarks: find ich zum kotzen. mnt-by: DTAG-NIC changed: dbaier(a)www-service.de 19991109 source: RIPE person: Andreas Schoberth address: FICK-AG address: D-81925 Muenchen address: Germany phone: +49 190 332 332 nic-hdl: AS48-RIPE remarks: Wenn Dir ein Maedchen remarks: - pudelnackt - remarks: von hinten an die Nudel packt, remarks: wenn Dir also gutes widerfaehrt, remarks: dann ist das einen Asbach-Uralt wert. mnt-by: FR-NIC-MNT changed: chef(a)nic.de 19991109 source: RIPE (those two probably being affected due to being the contacts for viag.de) Judging from an earlier case, the handles weren't password protected, some "nice and intelligent person" changed the contents and then slapped a protected maintainer on it. I'm pretty sure the above is not unique; the case I know of also slandered the subject of the handle and got a XLINK-MNT put on (which it still keeps, together with a remark that Xlink doesn't appreciate abuse of our maintainer). Apart from the obvious (auth MAIL FROM and NONE ought to be considered deprecated, and every maintainer should have its password(s)), can we please find the perpetrators and scare them a bit? ;-) Oh, and also DTAG-NIC and FR-NIC-MNT will probably want to change the mnt-by: to ECRC-MNT. kind regards, Petra Zeidler -- i.A. Petra Zeidler, Neukundenanschluss Xlink Internet Service GmbH [X] zeidler(a)xlink.net [X] Tel: 0721/9652-220 [X] Fax: 0721/9652-209 [X] Geschaeftsfuehrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. [X] Auftraege erledigen wir zu unseren Allgemeinen Geschaeftsbedingungen.

2 1

Re: IP assignment for virtual webhosting
by Wilfried Woeber, UniVie/ACOnet 18 Nov '99

18 Nov '99

Dear Poul-Henning, =>Something along the lines of why static IP for the applicants web hosting =>product/services is absolutely necessary. => =>> start judging what =>> are "good" and "bad" applications ? => =>RIPE do that anyway! = =But we can add that quite a number of LIR's seem unaware of this =practice: = =You can find the entire list of offenders at: = = http://stat.cybercity.dk/ripe = =And a "Bad guys" list at: = = http://stat.cybercity.dk/ripe/bad.html = =#IPs LIR =----------------------- =11944 se.swipnet = = [ ... ] you seem to imply that the number of host addresses you see (from within address blocks that happen to have "inconsistencies" in the DB objects) is directly related to the number of addresses assigned for virtual applications? I'm lost... Wilfried.

3 2

RE: IP assignment for virtual webhosting
by Williams, Toby 18 Nov '99

18 Nov '99

In a sales environment, it would certainly be easier to enforce namebased virtual web-hosting if everyone had to play by the same rules. Currently being conciencous and telling a prospect they can't have the IP addresses for virtual web hosting gets the response "well ISP xxx will provide me with them". The importance of enforcing name-based hosting is high, but I also get the feeling the amount of wasted address space elsewhere on the Internet (/16s allocated to big institutions years ago that are firewalled other than a handful of /24s?) should be a higher priority - not saying that RIPE did these allocations of course! Toby > -----Original Message----- > From: Havard.Eidnes(a)runit.sintef.no > [mailto:Havard.Eidnes@runit.sintef.no] > Sent: 17 November 1999 17:10 > To: Sam.Bradford(a)demon.net > Cc: cor(a)xs4all.net; nurani(a)ripe.net; lir-wg(a)ripe.net > Subject: Re: IP assignment for virtual webhosting > > > > Although the amount of clients connecting with 1.0 may be very > > little in most cases, it does still happen. We have customers > > specifically state that they do not want to set up http 1.1 > > because at the end of the day, some people will not be able to > > view their (and/or their clients') web sites, which is fair > > enough. > > I hope this doesn't mean they don't deply http 1.1-capable > servers, but that they don't actually utilize the virtual hosting > functionality based on the Host: header in http 1.1? > > Not doing 1.1 server-side would be extremely bad for the http 1.1 > clients and the general health of the network. > > By the way, anyone want to take bets about when the next craze about > "always on" network service becomes significantly widespread, and > how that will affect IP address space consumption? ;-) (No, I'm not > an IPv6 advocate, if that's what you're thinking, just putting this > all in some larger perspective.) > > > - Håvard >

3 2

Re: IP assignment for virtual webhosting
by Wilfried Woeber, UniVie/ACOnet 17 Nov '99

17 Nov '99

Clive, =Eric said: => I'd rather see a very strict policy which basically => denies the use of IP addresses for that purpose unless a *very* good => explenation as to why is provided to the hostmaster. = =But what is a "very good explanation" ? Is RIPE going to start judging what =are "good" and "bad" applications ? good point! But even before going into technical or administrative details, could the NCC please provide us with - motivation and background for opening that issue - an educated guess about the absolute or relative impact on the amount of remaining unused IPv4 address space, both in prospect as well as in retrospect? Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________

1 0