- Test - lists.nanog.org

Re: 206.82.160.0/22
by John Riordan 24 Sep '95

24 Sep '95

> Sprint wanted nothing to do with it, and referred to the Internic. > I specifically requested this allocation (for a mere /20 to satisfy the > slow-start policy) as permanent, not as a recyclable temporary assignment. > Everything I ever tried...and non-cooperation out of political motives For what it is worth... I must say I sympathize with Kai. While it looks like our clients may come out ok in all this (I hope), we have had similar problems trying to grow and operate as a small niche provider. It all seems to stem from the understandable fact that the larger providers are trying to look out for the interests of Internet as a whole as well as themselves. If the small niche providers suffer it may, or may not, be a small price to pay. However, I feel (granted I'm biased) that a competitive market place which allows small niche providers to compete will benefit the Internet in the long run. Before I launch into my story I just want to say that while I welcome sympathy for our predicament, I'm not particularly looking for it in this case. We knew full well that the allocations we received from the Internic may not be usable going forward, strange as that notion may seem to those receiving them. We felt it was still the best route to go. A few months ago we went looking for a /18 from the Internic for reassignment to our clients. After about a month of discussion with the Internic, we were unequivocally told we had to make due with a /19. A /19 was all we could justify, and we do understand the need for such justifications - we needed to show that we could make good use of the /19 before they would consider talking with us further on the issue. Furthermore, we had to make a decision or stop taking on new customers at that point, so we took the /19 from the Internic and went ahead with business. We went to the Internic looking for an /18 allocation instead of Sprint or MCI for a handfull of reasons, including: 1) Sprint and MCI (our two providers) were unwilling to provide us with a portable allocation. We do understand the rational behind this - we don't provide portable allocations to our clients either. However, we didn't want to be locked into a supplier - our clients would never understand being told they need to renumber if we ever did away with, or replaced, one of our suppliers. Furthermore we don't want to go punching holes in the large providers aggregations for, what I think, are obvious reasons. 2) While we could only justify a /19, we were rather worried about what was going to happen with the /19's. We were well aware of Sean's opinions on filtering at the /18 and /19 level and his influence in issues such as this. He has the power to affect change in a way few others do. However, based on what we knew from forums like this and talking with people at Merit and elsewhere, we felt that it was likely that the /19's would go unfiltered so we took the risk. 3) Being multi-homed, it seemed to make sense to announce an independent address blocks so as to avoid whatever complications that might arise in the future from the announcing of address blocks belonging to one provider into another provider at our level. So now Sprint went ahead and filtered our /19 as they hear it from MCI. They also hear it from us, so except for our loss of a backup route to Sprint through MCI, we are ok. It looks like Sean will make, if he has not already, an exception in our case - I hope all this doesn't change his mind. I'm not so sure he will make exception in Kai's case or other people in similar situtations. However, if the other major providers follow suit on filtering the /19s on an incoming basis (outgoing filtering I don't have an issue with), we will have a good bit of damage control to do - some warning would have been nice. If we were not Sprint clients, Sprint's action would have had a serious impact on our business, of course arguably our own fault. Going forward, my concern arises because it is not clear to me how a policy which only enables organizations able to justify /18 portable independent allocations for reassignment (at the moment I don't believe you can even buy your way into such an assignment) will provide a competitive environment which includes small niche providers. I don't think an environment which locks small players into a supplier is competitive from anyones vantage point. Maybe I'm missing something, maybe all this is being taken care of as I write this (I did see some good suggestions floating around), or maybe the Internet would be better off without all the small niche providers. My hope is that those parties who do influence policy creation will leave room for small niche players players to compete when they do come to agreement on this and future issues. Also I hope that those same parties are cognizant of the fact that actions they take to further their goals can have a serious impact the small players out there. All this being a case in point. While a little bit of incoming filtering by Sprint may have next to no impact on the ability of Sprint to do business, it could devastate a small niche provider someplace who has to say to their clients, "Sorry, we are only able to provide you with partial Internet service at the moment because Sprint doesn't like the addresses we assigned you". Now that I've had my say, I'm going back to the sideline. John Riordan Vice President Interport Communications Corp. 1133 Broadway New York, NY 10010 212-989-1128

2 1

Re: 206.82.160.0/22
by Sean Doran 24 Sep '95

24 Sep '95

John - Like many others here and in private email, you make excellent points, and were influential in helping move towards allowing /19s in 206/8 on the grounds that many people honestly (mis-)understood comments about indecision with respect to /19s vs /18s and noises about possibly re-evaluating things in the future to be a guarantee of routability of /19s in the 206/8 range. I also agree with your points that encouraging the growth in the number of providers, particularly small providers, is very important to the evolution of the ubiquitous Internet, and that anything that holds back the growth of the number of small and mid-size providers should be avoided. Unfortunately, I don't think that we can adopt a policy of "should be avoided at all costs", because one such cost is having large segments of the Internet stop working. Consequently, there are a number of people at work on preventing further increases in the size of routing tables. While I do agree with Dave Crocker et al. that strict nonportable address allocation does make it difficult for small and mid-size providers to change connectivity to some degree, I believe that for the moment this is unavoidable, no matter that I wish that it was, or that I could put some of my efforts off any longer than I already have. However, with respect to the difficulties that inflexible minimum sizes on portable allocations (i.e., those that are likely to be routable throughout the entire Internet) and limits on routability of long prefixes, most things would be made much easier on small and mid-size providers if sufficiently good renumbering technology existed for small-i internets. Therefore I make the economic argument to workstation, operating-system and router vendors that it is in their interests to develop easy-to-use or (semi-) automatic renumbering tools for all their products, and to participate in the development of protocols that allow these tools to cooperate in the process of renumbering even sizeable small-i internets. I assert (wearing a price-theorist's hat) that such a technology will lower the costs of providing big-I Internet services significantly, and that this cost-savings will allow for a reduction in pricing due to competitive pressures, and, caeteris paribus, will lead to further growth of the Internet and consequently more sales of "Internet-ready" workstations, operating-systems, and routers. Sean. - -- Sean Doran <smd(a)sprint.net>

2 1

multicast and smd's brain-damage
by Sean Doran 23 Sep '95

23 Sep '95

Urgh, I was just reminded of my ongoing and seemingly incurable brain-damage concerning 224/8 - 239/8... I'm grateful to the person who pointed this out with: "... And God help any of them who are expecting to announce anything between 224/8 and 239/8." Sean.

1 0

access-list 112
by Sean Doran 23 Sep '95

23 Sep '95

This is probably ugly and difficult to read. It also can be trimmed, but has been left overly-long and overly-paranoid for readability when using "show access-list 112" and because the IOS 10.3 distribute-list caching doesn't seem to mind the extra deny clauses all that much. Sean. - -- ! list 112 - deny more specifics of some prefixes ! ! IMPORTANT-TO-REMEMBER SYNTAX FOR BGP distribute-list! ! access-list <#> <permit|deny> ip <prefix> <don't care bits> <mask> <don't care bits> ! ! clear old list ! no access-list 112 ! ! this was originally ordered A, B, C and side-effects, but ! what we really want to do is put the permit clauses up front ! starting with the swamp, as this will match the most prefixes ! !!!!! START ! !!!! PERMITs ! !!! C space !! permit /24s in 192/8-205/8. ! (192==1100 0000, 205==1100 1101) ! ! allow M =< /24 in 1100 xx0x * ! (allow mask bits in first three octets) ! 1100xx0x == {192,193,196,197,200,201,204,205} ! access-list 112 permit ip 192.0.0.0 13.255.255.255 0.0.0.0 255.255.255.0 ! ! ! allow M =< /24 in 1100 {0010,0011,0110,0111,1010,1011} ! (which really means 1100 {001x,011x,101x}, ! which in turn is really 1110 {x01x,011x}} ! 1100x01x == {194,195,202,203} ! 1100011x == {198,199} ! access-list 112 permit ip 194.0.0.0 9.255.255.255 0.0.0.0 255.255.255.0 access-list 112 permit ip 198.0.0.0 1.255.255.255 0.0.0.0 255.255.255.0 ! ! !! hack - allow M =< /19 in 206/8 ! access-list 112 permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0 ! ! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *) ! (allow mask bits in first 18 bits) ! 1100111x == {206,207} ! 1110xxxx == {208-239} ! access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 239.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 ! ! !!! B space !! permit /16s in old B-space ! 10xx xxxx * ! (we don't care what bits are in the first two octets ! of the mask; the second two octets must be 0) ! access-list 112 permit ip 128.0.0.0 63.255.255.255 0.0.0.0 255.255.0.0 ! ! !!! A space !! permit /8s and shorter prefixes in old A-space ! 0xxx xxxx * would be simple but unsafe from 0/8 POV, so ! we make sure that there is at least one 1 bit in the first ! octet's last seven bits, and that the first bit is 0; ! we don't care what bits are set in the mask, because ! we assume IOS won't present us with a prefix with ! bits set in the prefix's first octet but not in the mask, ! unless it's a long mask... ! ! 126=01111110 (IOW, CddddddC C==CARE, d=don't care) ! 125=01111101 ! ... ! 95=01011111 ! 63=00111111 ! access-list 112 permit ip 1.0.0.0 126.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 2.0.0.0 125.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 4.0.0.0 123.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 8.0.0.0 119.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 16.0.0.0 111.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 32.0.0.0 95.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 64.0.0.0 63.0.0.0 0.0.0.0 255.0.0.0 ! ! !! permit 9.20.0.0/18 and 9.2/16 by exact match ! (both IBM early birds wrt subnets of As) ! access-list 112 permit ip 9.2.0.0 0.0.255.255 255.255.0.0 0.0.0.0 access-list 112 permit ip 9.20.0.0 0.0.255.255 255.255.192.0 0.0.0.0 ! !! permit exp39 /24s and shorter prefixes only ! (no ones set in the fourth octet) ! access-list 112 permit ip 39.0.0.0 0.255.255.255 0.0.0.0 255.255.255.0 ! ! !!!! DENYs ! ! This is super paranoia. At this point we have permitted ! all valid unicast prefixes and masks. ! In theory, we could end right here with a ! ! access-list 112 deny ip any any ! ! but this section below offers some degree of clarity ! policy-wise... (at least to me, but I'm weird -- smd) ! ! we also could have done a quick deny after each permit ! to catch any prefixes which didn't pass the permit filters, ! however, as noted below, I am superparanoid about ! funny, noncontiguous masks and other weirdnesses, and ! would like to be able to see them being caught, if ! they ever get as far as the access-list. ! !!! A space !! deny 0/(9-15) - 127/(9-15) ! deny subnets in old-style class A space, first octet ! (if any bit set in bit 8-15 (second octet), deny) ! ! this is a paranoid way of writing this out; ! less paranoia would let us write: ! ! ... deny ip 0.0.0.0 127.0.0.0 0.0.0.0 255.128.0.0 ! ! because we believe in contiguous netmasks; so we would ! never have a /18 if we block /17. ! ! However, better safe than sorry... ? ! ! 0xxx xxxx * ! access-list 112 deny ip 0.0.0.0 127.255.255.255 0.128.0.0 255.127.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.64.0.0 255.191.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.32.0.0 255.223.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.16.0.0 255.239.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.8.0.0 255.247.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.4.0.0 255.251.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.2.0.0 255.253.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.1.0.0 255.254.255.255 ! !!! B space !! deny 0-127/16, 0-(17-23) - 191/(17-23) ! deny subnets in old-style class-B space ! and second octet of class A space. ! (first two bits will be 00 or 10; so x0xx xxxx; 191==10111111) ! (if any bit set in 16-23, deny) ! we also need to zap 0xxx xxxx * /16 ! access-list 112 deny ip 0.0.0.0 127.255.255.255 0.0.0.0 255.255.0.0 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.128.0 255.255.127.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.64.0 255.255.191.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.1.0 255.255.254.255 ! ! !!! C space !! deny 206/(19-23) - 239/(19-23) ! block prefixes longer than /18 in 207/8-239/8 ! no < /18 in 1100 1110 *, 1100 1111 *, 1110 xxxx * ! ! we block all M => /24 below and we did /17-/23 for 0/8-191/8 above, ! so we only need to worry about 19-23 for 207/8-239/8 ! ! first, in 1100 111x (206/8, 207/8) ! (if mask has 1 bits in third octet (bits 18-23), deny) ! access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255 ! ! next in 1101 xxxx (208/8-239/8) ! (if mask has 1 bits in third octet (bits 18-23), deny) ! access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255 ! !!! all UNICAST space !! deny ANY/24, ANY/(25-32) ! now we block the final octet for 0/8-239/8 ! (because we specifically allowed /24s in 192/8-205/8, we can ! just block everything in xxxx xxxx * that has any 1 bits in 4th octet) ! access-list 112 deny ip 0.0.0.0 255.255.255.255 255.255.255.0 0.0.0.0 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.128 255.255.255.127 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.64 255.255.255.191 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.32 255.255.255.223 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.16 255.255.255.239 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.8 255.255.255.247 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.4 255.255.255.251 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.2 255.255.255.253 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.1 255.255.255.252 ! !!! all IP space !! deny 240/(4-32), 0/(8-32) ! finally, we get rid of any announcements that are bogons ! 240/8-255/8 and 0/8 ! 1111 xxxx * and 0000 0000 * (any mask) ! we can leave this last as it's likely almost never to happen ! access-list 112 deny ip 255.0.0.0 15.255.255.255 0.0.0.0 255.255.255.255 access-list 112 deny ip 0.0.0.0 0.255.255.255 0.0.0.0 255.255.255.255 ! !!!!! END end

1 0

206.0.0.0/8 and /19s
by Sean Doran 23 Sep '95

23 Sep '95

After much discussion with many different people, including some at registries, I have modified our filter-list to accept /19s in the 206.0.0.0/8 block. The change will take effect upon the next clearing of exterior BGP sessions with our various neighbours. Note that there will be no further relaxtion of the /19 limit, and that the principal reasoning behind the change from /18 to /19 for this block is as follows: -- a miscommunication between me and various registries several months ago which led to registries and perhaps some providers handing out some /19s that they honesty expected would pass through the filters; the fact that they did, to some extent, due to the minor implementation glitch on this side, exacerbated the problem. -- several people have aggregated long prefixes into /19s (thank you) and find that they cannot reasonably do further aggregation to /18s due to various allocation policies. This change increases the number of prefixes AS1239 will route towards by 129, all of which are /19s, and many of which can and should be aggregated into even shorter prefixes. Note that this will not help anyone who is announcing anything longer than a 19-bit prefix in the 206.0.0.0/8 range, nor anyone who is expecting to be able to announce /19s in 207.0.0.0/8 - 239.0.0.0/8. At this time, I don't intend to have AS1239 routers accept /19s in those blocks from its external peers, nor do I expect to increase the maximum length of the prefixes accepted from 206.0.0.0/8 beyond that which registries were allocating as part of their slow-start scheme with the expectation that /19s probably were short enough that they would stay routable everywhere. Sean. - -- Sean Doran <smd(a)sprint.net>

1 0

Re: Authority over IANA & IP #s was Re: 206.82.160.0/22
by Guy T Almes 23 Sep '95

23 Sep '95

Mike, Nice paper, but I think you're seriously off on the recompete of the NIC. It was more like 1992 rather than '88 as you write. Given the way the Internet changes character each year, that was quite a difference. Note one parallel with the current DNS fee debate: during the period (roughly) 1987 to 1993, the NSFnet EDU community depended on a NIC that was accountable to the DoD. There were examples of friction that resulted, but things were mostly quite amacable. Now the private-sector COM/ORG community is having to put up with vestigial accountability structure oriented around the NSF. There will be some friction, and there will be some patience, and there will be progress. -- Guy At 07:33 PM 9/22/95 -0400, you wrote: >Generally, we like to keep a low profile - unless there's a problem. HWB's >basically correct about the history. Let me explain my current >understanding of where everything sits. Keep in mind at least parts of >this have been disputed even within the US feds. Also, the dates and >details may be a little off. > >The number space began life as a part of the ARPA "toy" internet. The >number space was managed by the NIC at SRI under a contract with the >Defense Communications Agency (which was managing the ARPANet under an >agreement with ARPA) until that contract was recompeted in '88. At that >time the numberspace management was transfered to the Internic under a >contract (cooperative agreement) with NSF. At this point the DOD basically >transfered "ownership" of the number to the Federal Networking Council >(actually, it may have been to its predecessor the FRICC - I don't remember >the timing). The understanding was that the DOD would continue to have >first call on the number space IF they needed it, but that block and other >delegations would be done by the Internic in consultation with the IANA, >EOWG, IEPG etc. As new schemes have come into being (e.g. subnetting, >CIDR) the gov't folks have basically ratified (mostly by silence) the use >of the space. The deal with the DOD having first call on the space was to >ensure that the DOD didn't give away the space and then have to start >paying for it. The deal today is that the FNC (as the representative US >organization) continues to own the space, but chooses to limit its control >over the space to issues (e.g. paying for numbers) that it considers >critical. Although the Internic performs the registrar function it does >this as an agent of the US Gov't and does not own the space nor does it own >the registration data. The registration function (at the top level >delegation) for numbers has been funded by the US Gov't since its inception >- first by ARPA and DOD, then by NSF. > >The name space is another matter. In approx 1986, as a result of the >growth of the HOSTTABLE (can you believe all the names on the used to fit >into one file?) the Internet began the deployment of the DNS system. (The >internet at this time was about 50 networks total). At this time of its >life, the majority of hosts on the internet were still connected through >either the ARPANet or the MILNet - the growth of the NSFNet centric >internet was yet to come. The initial DNS deployment was limited to the >non-country TLDs (e.g. MIL, COM, GOV, EDU, NET, ORG - INT came later) - >this was corrected rapidly with the introduction of the country TLDs. All >of the TLDs were considered "undelegated" at the time. Shortly after this >deployment started, I wrote the policies for the .MIL domain which limited >registrations to the US DOD and described the rules for second level >registrations (e.g. independent service or agency such as ARMY or Joint >Chiefs of Staff - JCS) - this was the first delegation of the non-country >TLDs. Keep in mind, the registration function was still vested at the SRI >NIC which was being paid for mainly by the Defense Data Network program at >DCA with some contributions from ARPA related to ARPANet operational costs. >Its unclear whether DCA or ARPA would claim ownership of the root domain, >but it definitely vested within the US DOD. Ownership of the root domain >was transfered to the FNC at the same time as the numberspace was >transfered and upon recompetition of the NIC contract the registration >function for root and the undelegated TLDs was transfered to the Internic. >Registrations within .MIL transfered at the same time, but this was due to >the fact the DDN NIC contract was won by the same organizations. > >The third delegation of a TLD was made circa '88 - EDU to the NSF (INT was >made to ARPA previous to this, but that's a very long story) in keeping >with its mission and connections program goals. .GOV was also delegated at >this time - to the US Gov't. The FNC finally issued a policy RFC covering >the .GOV registrations this year. At this time, COM, ORG and NET remain >undelegated at this time which basically places policy control for them >under the root authority which remains with the FNC. The notes above about >ownership of the Internic database etc apply here as well. > >I was a program analyst at the Defense Data Network Program Management >office at DCA from 85 to 89. As such, I was responsible for the NIC >contract and directing the technical work there. The GOV, EDU, MIL and INT >domains were delegated at my direction at that time - Steve Wolff at NSF >agreed to accept policy control over EDU at NSF at that time. I currently >sit on the FNC exec committee. > >All of the above notwithstanding the general mode of operation has been to >let the community work out the issues as they occur. Unfortunately, >sometimes the gov't has had to make decisions and give directions to its >contracts, either without community input or against community >recommendations due either to legal, financial or other issues. The feds >continue to fund the Internic and the IANA and have fiduciary and program >responsibilities due to this. > >Please! Take all of the above with a grain of salt - my general feeling is >that the feds feel they are holding the numbers and namespace in trust for >the community and really do have the internets best interests (e.g. >continued operation) at heart. > > > >Mike > > > >At 14:04 9/22/95, Gordon Cook wrote: >>Well I am pleased to see this from Hans Werner too -- especially the >>lines of historical authority ..... >> >>he said: >> >>formally I guess one would claim that the >>Internet address space is the personal property of the IANA instrument >>of the United States Department of Defense, if that is what you like. >>I would prefer to think that the Internet evolved so much over the last >>ten years or so into the public realm, that the address and naming >>spaces have become public property. Instead of bitching about the >>InterNIC, NSF, ARPA, IANA, whoever, you guys should thank them for how >>far they got things driven, and whet they fostered and allowed to >>transition to the international private sector. [end of Hans Werner quote] >> >>Cook speaking: >> >>Are we hearing then that **ARPA has given up any and all of its authority >>over IANA**? That DOD no longer claims to own IP numbers? Hans Werner, >>I'd prefer for you to be precisely correct in your assertion about the >>public property nature of IANA, IP numbers etc. I'd love to thank Arpa >>for giving freedom to IANA and DOD for doing the same to IP numbers. But >>I have not seen any evidence that they have indeed done this. If they >>have perhaps the relevant people at ARPA and DOD would come out and >>confirm just exactly what they consider their current authority over IANA >>and IP numbers to be? >> > >ARPA pays the IANA bills - NSF pays the Internic bills; we have "authority" >but generally choose not to exercise it. Jon has a responsibility to "do >the right thing" and we let him alone to do that. > >Mike > >

2 1

NIC switchover dates
by Dave O'Leary 23 Sep '95

23 Sep '95

I'm pretty sure that NSI started doing the NIC stuff in 1991, it certainly wasn't 1992, but it might have been as early as 1990. It was definitely before I left SURAnet. It would be trivial to go back and see which IETF plenaries were devoted to the initial CERFnet/AT&T/NSI presentations and then the later thrashings of Scott Williams (who was the mgr at NSI in the beginning of the project). dave

1 0

Re: Authority over IANA & IP #s was Re: 206.82.160.0/22
by Dave Crocker 23 Sep '95

23 Sep '95

At 4:33 PM 9/22/95, Michael StJohns wrote: >Please! Take all of the above with a grain of salt - my general feeling is >that the feds feel they are holding the numbers and namespace in trust for >the community and really do have the internets best interests (e.g. Mike, the secrecy and lack of public review and consensus-building that has accompanied recent DNS-related decisions by NSI do not look like the handling of a public trust. For that matter the nature of the conflict-resolution rules and the nature of the charges imposed on new domain names are fundamentally off the mark. Purity in the minds of those making the decisions and, for that matter, seriousness of immediate financial and legal problems, do not make the current style or details of these decisions acceptable. As I said earlier, in one of the various threads on this topic, NSF (and of course ARPA) deserve much and great credit for the creation and nurturing. But I agree with the view that this is a public resource -- a global resource -- and we need to treat it accordingly. Control over these resources needs to rest with a global Internet resource. The IANA is already integrated into the Internet structure. What's missing, of course, is non-governmental funding. In general it does not look as if the community is resisting imposition of fees, though it sure would have been better for the details of the funding debate to take place before imposition by fiat. In any event, we need funding to be done via a public agency, but not a government agency. Using U.S. constructs, a 501(c)(3) non-profit corporation acting as a public trust for IANA/Internic/IETF/... funding would seem to make the most sense. In particular, the funding activity needs to be handled by an agency which is independent of any particular administrator of Internet functions. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker(a)brandenburg.com

1 0

Proposed State & Federal Regulations for the INTERNET!
by Politics＠usa.com 23 Sep '95

23 Sep '95

My name is Scott Glasrud, and I am running for the New Mexico State Senate during the 1996 elections. One of the reasons I have chosen to run is to combat the proposed state and federal regulations of the Internet. As you know, the Internet was never designed to be regulated! It was designed to allow communications in the event of anuclear war or a major catastrophe. I OPPOSE REGULATION, and if elected will fight to preserve your constitutional rights. HOWEVER, I NEED YOUR HELP! I am asking each person who reeives this message to send $5.00 to the Scott Glasrud Campaign Committee. If we pull together, we CAN protect our first amendment rights! HELP ME show the politicians the POWER behind this important NETWORK. Please send contributions to: The Scott Glasrud Campaign Committee 11024 Montgomery Blvd. NE, Suite 179 Albuquerque, New Mexico 87111 Thank you!

1 0

RE: Sprint violations
by Robert A. Rosenberg 23 Sep '95

23 Sep '95

At 16:36 9/22/95, Mathew Lodge wrote: >Well, no, actually. Customers don't care who's fault it is -- as far as >they're concerned, it's broken. I had a similar situation impressed on me >today: one of our customers wants to send e-mail with MIME attachments to >one of his customers who has a CompuServe account. The attachments never >make it through the CompuServe e-mail gateway. > >Now, we know that this is not a problem with our TCP/IP network and SMTP >implementation -- it's a problem at the CompuServe end. The customer knows >nothing about e-mail gateways, and nor does he care. As far as he's >concered, it doesn't work. And Omnes, as his solutions provider, had better >fix it. > >I still haven't worked out how to appease this particular individual: but >my point is that customers dislike "finger pointing" when it comes to >resolving a problem. It won't wash. There is NO problem sending MIME Email with attachments to Compuserve accounts (I do it all the time). The only requirement (until Compuserve rolls out their promised MIME-Aware Gateway and support) is that the user must save the message as a Text File and then pass it through Mpack to do the actual MIME Extraction. If the customer needs handholding, pass him/her my Email address and I'll provide Step-by-Step instructions (for both the sender and recipient).

1 0