From bound at zk3.dec.com Mon Dec 1 18:08:32 1997 From: bound at zk3.dec.com (bound at zk3.dec.com) Date: Mon, 01 Dec 1997 12:08:32 -0500 Subject: (IPng 4984) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of "Wed, 26 Nov 1997 18:05:00 +0100." <9711261705.AA03735@ncc.ripe.net> Message-ID: <199712011708.AA06362@wasted.zk3.dec.com> Daniel, Have you or someone from RIPE participated on the IPng mailing list? Have you or someone from RIPE participated in the IPng WG meetings at the last three IETF meetings? The reason I ask is because we have done technical analysis on this and have had much discussion. I think discussing the reason for going with a 13bit TLA needs to be brought out more and doing and checking that is prudent. But the architecture and reasoning has had many technical discussions. I would like to understand as a WG member if you or RIPE did not agree with the results (which I would think we would have heard before now) or if you or RIPE have not been part of these open public discussions. It could be we need to point to the mail archives and the GSE reasoning paper done by Thomas Narten, Lixia Zhang, et al from whence this essential proposal came from based on a WG meeting in Mountain View about a year ago? I am trying to understand if this is an educational effort on our part as a WG group? thanks /jim From Daniel.Karrenberg at ripe.net Mon Dec 1 20:19:01 1997 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 01 Dec 1997 20:19:01 +0100 Subject: (IPng 4984) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of Mon, 01 Dec 1997 12:08:32 EST. <199712011708.AA06362@wasted.zk3.dec.com> References: <199712011708.AA06362@wasted.zk3.dec.com> Message-ID: <9712011919.AA09965@ncc.ripe.net> Quick answer: > bound at zk3.dec.com writes: > Daniel, > > Have you or someone from RIPE participated on the IPng mailing list? > > Have you or someone from RIPE participated in the IPng WG meetings at > the last three IETF meetings? Yes we have. I personally have not been in Memphis, hoever none of us was able to be at the interim meeting. To my knowledge the draft under discussion was written less than two IETFs ago. I personally was not able to be at all IPnG meetings at the last few IETFs because of conflicts with other things. I have however voiced my concerns about this particular issue to Miek O'Dell while the discussion was going on. But all that is besides the point really. > The reason I ask is because we have done technical analysis on this and > have had much discussion. I have seen some of this discussion. I am afraid I have seen no documented discussion revealing the reasoning behind fixing the TLA length and fixing it at 13 bits. Frankly I have been surprised by the sudden speed of the provider based addressing standardisation. What I have voiced are concerns based on our experience with setting up and operating address space registries as well as providing coordination services to ISPs. My main point is that fixing the TLA length and fixing it at 13 bits has such far-reaching consequences that it needs to be supported by a solid technical argument which I cannot find in the drafts nor in any other source available to me. I think the draft should at least point to a solid reference supporting this. I expect a lot of entropy down the road if this is not supported well. > I think discussing the reason for going with a 13bit TLA needs to be > brought out more and doing and checking that is prudent. But the > architecture and reasoning has had many technical discussions. I would > like to understand as a WG member if you or RIPE did not agree with the > results (which I would think we would have heard before now) or if you > or RIPE have not been part of these open public discussions. It could > be we need to point to the mail archives and the GSE reasoning paper done > by Thomas Narten, Lixia Zhang, et al from whence this essential proposal > came from based on a WG meeting in Mountain View about a year ago? > I am trying to understand if this is an educational effort on our part > as a WG group? It is both educational and principal. Major design decisions should be somewhat transparent to a wider audience. Standardising TLA length in fact puts significant constraints on operations, business models and address space allocation policies just to name a few issues. This needs to be justified somewhat more than just saying "it is standardised like this". The reasons have to be accessible more widely than just the IPnG WG. Note that I am not at issue with the underlying architecture. It is about fixing the boundary and fixing it at a particular value. If there is a solid technical reason for it, then document it. Documenting it will make the standard a stronger document and will prevent a lot of discussion about the repercussions. If there is no solid technical reason to do so then then do not fix these values. If a (proposed) standard does not document this reasoning or at least points to it, it is seriously flawed. This is not a definition of a type field in some application protocol header. It is much more critical. Does that answer your question? Daniel From sob at harvard.edu Mon Dec 1 20:58:03 1997 From: sob at harvard.edu (Scott Bradner) Date: Mon, 1 Dec 1997 14:58:03 -0500 (EST) Subject: (IPng 4984) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard Message-ID: <199712011958.OAA08069@newdev.harvard.edu> Daniel said: I have seen some of this discussion. I am afraid I have seen no documented discussion revealing the reasoning behind fixing the TLA length and fixing it at 13 bits. Frankly I have been surprised by the sudden speed of the provider based addressing standardisation. last year in regards to what is now RFC 2050 I asked the lawyers that do work for the IESG what restrictions in flexibility we (the IETF) have in the area of defining rules and technology that restricts ISP practices. I was told that the only time we can be restrictive is when there is no other technically reasonable option - I support Daniel here, if this field is to be restricted to a specific length then we must have very good technical reasons for doing so. Scott From bound at zk3.dec.com Mon Dec 1 21:02:06 1997 From: bound at zk3.dec.com (bound at zk3.dec.com) Date: Mon, 01 Dec 1997 15:02:06 -0500 Subject: (IPng 4984) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of "Mon, 01 Dec 1997 20:19:01 +0100." <9712011919.AA09965@ncc.ripe.net> Message-ID: <199712012002.AA18962@wasted.zk3.dec.com> Daniel, Good answer. I agree. Be helpful in the future if you would state your concerns to the WG directly as we may have been able to have done this before going to the IESG. I recall no mail from Mike O'dell to this list on the TLA issue. But we need to address your concern for sure. I have had many ask about the 13 bit issue and figured that would pop up. thanks /jim From huitema at bellcore.com Mon Dec 1 21:47:42 1997 From: huitema at bellcore.com (Christian Huitema) Date: Mon, 1 Dec 1997 15:47:42 -0500 (EST) Subject: (IPng 4997) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Scott Bradner "(IPng 4997) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard" (Dec 1, 2:58pm) References: <199712011958.OAA08069@newdev.harvard.edu> Message-ID: <971201154741.ZM3212@seawind.bellcore.com> Daniel, There were two basic arguments for limiting the length of the TLA prefix: 1) Routing table size. All TLA have to be in all tables in all defaultless routers. Thus, the number of TLAs becomes a minorant of the size of the tables. 2) Address space size. The current document only specifies 1/8th of the address space. If it turns out that there is a need for many more TLA's in three years, it will actually be possible to make some. The particular value chosen, 13 bits, as only one advantage. The combination of format and TLA fits in 16 bits, which provides for easy writing of routing prefixes. The point that you note re: allocation practices is, however, perfectly true. ISPs should not receive a TLA 'a priori", they should graduate to it. If I remeber correctly, an ISP that starts operating in Europe today receives a /19, and will gradually receive more space as it connects more customers. An ISP that starts operating with IPv6 should receive one or several NLAs from established transit providers; it should only receive a global entry in the routing tables once it has passed some "graduation" criteria. -- Christian Huitema From brian at hursley.ibm.com Tue Dec 2 03:39:00 1997 From: brian at hursley.ibm.com (Brian E Carpenter) Date: Tue, 02 Dec 1997 02:39:00 +0000 Subject: (IPng 4997) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard References: <199712011958.OAA08069@newdev.harvard.edu> Message-ID: <348374C4.15BC@hursley.ibm.com> Try "The length of the TLA field is fixed at a relatively small size so as to guarantee that the default-free routing table is certain not to exceed a size known to be technically feasible." If that is untrue, then we can't justify the fixed size. Brian Carpenter >-- Scott Bradner wrote: > > Daniel said: > I have seen some of this discussion. I am afraid I have seen no > documented discussion revealing the reasoning behind fixing the TLA > length and fixing it at 13 bits. Frankly I have been surprised by the > sudden speed of the provider based addressing standardisation. > > last year in regards to what is now RFC 2050 I asked the lawyers that > do work for the IESG what restrictions in flexibility we (the IETF) have > in the area of defining rules and technology that restricts ISP practices. > I was told that the only time we can be restrictive is when there is > no other technically reasonable option - I support Daniel here, if this > field is to be restricted to a specific length then we must have > very good technical reasons for doing so. > > Scott > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo at sunroof.eng.sun.com > -------------------------------------------------------------------- From mo at UU.NET Tue Dec 2 13:11:00 1997 From: mo at UU.NET (Mike O'Dell) Date: Tue, 02 Dec 1997 07:11:00 -0500 Subject: (IPng 4997) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of "Tue, 02 Dec 1997 02:39:00 GMT." <348374C4.15BC@hursley.ibm.com> Message-ID: brian's reason is exactly the goal which was in mind: to bound the maximum complexity of the default-free region at values believed to be viable with some margin. the margin is important because even routers normally though to be "default-free" will probably carry a significant number of more-specific prefixes for optimizing paths, both internal to a TLA and between TLAs. and note, once again, the issue is not the size of the default-free region, but the complexity of the topology, which determines how many copies of the full default-free region one must examine before arriving at the forwarding table with one entry per TLA. it is now routine to see an announced prefix 15 times via different paths, only one of which must be selected for use. the complexity of the topology is only expected to increase, both internally and externally, so it is not unreasonable to attempt to bound the size of the set as that is the only parameter which is in any sense "tunable". as for 13 - anything smaller was felt to be clearly too small, and it becomes harder and harder to argue for bigger numbers in light of the complexity management which is mandatory. if anyone expects a magic formula which says "13" and not something else, you won't get it. what is very clear is that it is pretty easy for it to to "too big", and then it eats into the other topology bits which have their own set of long arguments. would 14 work - certainly. Like everything else, 13 is an engineering compromise - chosen to balance one set of considerations against a bunch of others, and after ruminating over it a long time, the consensus was 13 was the best choice. and as someone else pointed out, the TLA space can be expanded laterally into other reserved areas, so there are more available. now, to look at things from a different vantage point.... I think one deep issue here is that the IPv6 address design, in some sense, appears to threaten the existing registries. the design assumes that each TLA act as a registry for its region of the address space, leaving the registries to only allocate TLAs, which will be infrequent. just so. but given the work required to run a registry, existing registries with good track records would be in an excellent position to compete for the right to provide registration services for *any* TLA or delegation within a TLA, not just ones they assigned. this is a natural fall-out of attempting to provide an addressing structure which can pave the way for making the network self-organizing. if that were really the case, unlike today, there would be little need for registry organizations (little - not "no", but little) which use humans clerical workers to execute a simple resource allocation algorithm for the world's largest distributed computer. -mo From bmanning at ISI.EDU Tue Dec 2 13:48:36 1997 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 2 Dec 1997 04:48:36 -0800 (PST) Subject: (IPng 5000) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: from "Mike O'Dell" at Dec 2, 97 07:11:00 am Message-ID: <199712021248.AA04171@zed.isi.edu> Before we wander too far down this path, there was a very interesting paper at the last sigcom in which the authors managed to shrink the size of the then current routing table (~40k routes) into less than 200K of memory. In short, I differ from Mike in that my values for "believed to be viable" differ, apparently wildly, from his and brians. I'm unconvinced that this will remain a true, long term technological argument. I'd like to see something besides, "too hard with 1990's technologies". "Long time" ought to have a better spec than say, Internet Dog Years? > > brian's reason is exactly the goal which was in mind: > > to bound the maximum complexity of the default-free region > at values believed to be viable with some margin. > > Like everything else, 13 is an engineering compromise - chosen > to balance one set of considerations against a bunch of others, > and after ruminating over it a long time, the consensus was > 13 was the best choice. > -- --bill From mo at UU.NET Tue Dec 2 15:12:49 1997 From: mo at UU.NET (Mike O'Dell) Date: Tue, 02 Dec 1997 09:12:49 -0500 Subject: (IPng 5000) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of "Tue, 02 Dec 1997 04:48:36 PST." <199712021248.AA04171@zed.isi.edu> Message-ID: bill, i'm surprised by your remark. i thought you have been around long enough to understand this. we've been over all this before. the problem is not now, nor has it ever been, the size of the forwarding table measured in any unit - routes, bytes, feet, or kilograms. (yes, there have been a few episodes where gross inadequacies of popular hardware created *serious* tactical headaches, but don't confuse that with the underlying problem.) the fundamental problem is the complexity of the computation which produces the forwarding table from many, many of copies various subsets of the global routing information. the complexity of that computation is driven by two things - the cardinality of the set of visible nodes in the global topology graph, and the complexity of the topology connecting those nodes. (note that "node" here does not imply a router but whole networks). of these two things, we cannot readily control the edge topology of the graph, so we are only left with controlling the cardinality of the node set of the graph if we wish to influence that complexity. of course, you can argue that we don't need to care about the problem - that somehow processors will keep getting fast enough fast enough to retain reasonable convergence times. but then you are betting on a race between two exponentials - and are making the bet that the smaller exponent will win. i know *i* don't want to wager the future on that bet. -mo From bmanning at ISI.EDU Tue Dec 2 16:08:28 1997 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 2 Dec 1997 07:08:28 -0800 (PST) Subject: (IPng 5000) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: from "Mike O'Dell" at Dec 2, 97 09:12:49 am Message-ID: <199712021508.AA13335@zed.isi.edu> > > > bill, > > i'm surprised by your remark. > i thought you have been around long enough to understand this. > we've been over all this before. > > the complexity of that computation is driven by two things - > the cardinality of the set of visible nodes in the global topology graph, > and the complexity of the topology connecting those nodes. > (note that "node" here does not imply a router but whole networks). > > of these two things, we cannot readily control the edge topology of the > graph, so we are only left with controlling the cardinality of the node set of > the graph if we wish to influence that complexity. > > of course, you can argue that we don't need to care about the problem - > that somehow processors will keep getting fast enough fast enough to > retain reasonable convergence times. > > but then you are betting on a race between two exponentials - > and are making the bet that the smaller exponent will win. > > i know *i* don't want to wager the future on that bet. > > -mo My argument is that the basic premise that the assumptions wrt the cardinality of the set of visable nodes in the topology graph -may- be wrong. Other than that, I agree with you. Chalk it up to a fit of Noel-Stev syndrome. With a bit of rest, I'm sure it will pass. (and I do recommend "Small Forwarding Tables for Fast Routing Lookup" from SigCom'97, which is one more reason why I think these arguments just might be off) -- --bill From huitema at bellcore.com Tue Dec 2 16:28:16 1997 From: huitema at bellcore.com (Christian Huitema) Date: Tue, 2 Dec 1997 10:28:16 -0500 (EST) Subject: (IPng 5002) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: bmanning@isi.edu "(IPng 5002) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard" (Dec 2, 4:48am) References: <199712021248.AA04171@zed.isi.edu> Message-ID: <971202102814.ZM3751@seawind.bellcore.com> On Dec 2, 4:48am, bmanning at isi.edu wrote: > In short, I differ from Mike in that my values for "believed to be viable" > differ, apparently wildly, from his and brians. I'm unconvinced that > this will remain a true, long term technological argument. I'd like to > see something besides, "too hard with 1990's technologies". "Long time" > ought to have a better spec than say, Internet Dog Years? Bill, What you say is true. Technology is going to progress, and at some point in the future we may convince ourselves that we can safely handle 1,000,000 TLAs instead of 10,000. However: 1) We are not there yet. Andrew Brodnik et al demonstrated that one can efficiently compress today's routing tables in the cache of a Pentium chip. But their algorithm has yet to be implemented in commercial routers. 2) There is more to scaling than routers' caches. Compressing the tables in cache memory mainly allows you to switch packets faster than if your tables were kept in a slow RAM. It does not reduce route flaps, or the complexity of the topology. 3) In any case, we are taking decision today based on today's technology. As I pointed out, there is plenty of address space reserved for further use. If the technology does evolve, then it will be time to open more space. In short, limiting the size of TLA to 13 bits looks like a reasonable cut, today. -- Christian Huitema From mo at UU.NET Tue Dec 2 16:31:43 1997 From: mo at UU.NET (Mike O'Dell) Date: Tue, 02 Dec 1997 10:31:43 -0500 Subject: (IPng 5000) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of "Tue, 02 Dec 1997 07:08:28 PST." <199712021508.AA13335@zed.isi.edu> Message-ID: i've read Pink, et al. it has to do with quick forwarding, not the computation which decides what goes in the forwarding table given all the possibilities to chose from. (longest match covering, AS path selection, etc, etc, etc) and i would love to be wrong - but even being wrong by a lot doesn't change the number of bits by a large amount given the way the size participates in the compuations. -mo From bmanning at ISI.EDU Tue Dec 2 16:46:51 1997 From: bmanning at ISI.EDU (bmanning at ISI.EDU) Date: Tue, 2 Dec 1997 07:46:51 -0800 (PST) Subject: (IPng 5002) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: <971202102814.ZM3751@seawind.bellcore.com> from "Christian Huitema" at Dec 2, 97 10:28:16 am Message-ID: <199712021546.AA27737@zed.isi.edu> > 1) We are not there yet. Andrew Brodnik et al demonstrated that one can > efficiently compress today's routing tables in the cache of a Pentium > chip. But their algorithm has yet to be implemented in commercial > routers. True. But how far off can that be? :) > 2) There is more to scaling than routers' caches. Compressing the tables > in cache memory mainly allows you to switch packets faster than if your > tables were kept in a slow RAM. It does not reduce route flaps, or > the complexity of the topology. One of the interesting side effects from the paper is the construct that appears to allow the creation of a true default free router i.e. one that has the ability to carry the total IPv4 space as host routes. a 13bit TLA does not reduce route flap nor moderate the complexity of the topology, which appear to have moved into the critical path. a 13bit TLA does give some breathing room by sanctioning a level of proxy aggregation. This method allows ISPs to lie to each other about the stability of their internal infrastructure, which is the current model for reducing the dynamics of the routing system. (Is it just me or is there really a joke being perpetrated by the attempts to present a stable routing infrastructure with dynamic routing protocols? :) > 3) In any case, we are taking decision today based on today's technology. > As I pointed out, there is plenty of address space reserved for further > use. If the technology does evolve, then it will be time to open > more space. Fine. Then this might be best served as a BCP and not standards track? Or are the concerns rasied by everyone but me strong enough to push this into the standards track? What I find interesting is that this particular addressing scheme has had less field time than the previous addressing scheme. Will there be yet another scheme fall out of the woodwork? Is there a reason why these schemes can't co-exist? And I'm not sure that the extra space will be available. Are you? > > In short, limiting the size of TLA to 13 bits looks like a reasonable cut, > today. Ok. I just thought I'd say my piece. > > -- > Christian Huitema > -- --bill From bound at zk3.dec.com Thu Dec 4 17:40:09 1997 From: bound at zk3.dec.com (bound at zk3.dec.com) Date: Thu, 04 Dec 1997 11:40:09 -0500 Subject: (IPng 5006) Re: Last Call: IP Version 6 Addressing Architecture to Proposed Standard In-Reply-To: Your message of "Tue, 02 Dec 1997 10:28:16 EST." <971202102814.ZM3751@seawind.bellcore.com> Message-ID: <199712041640.AA17250@wasted.zk3.dec.com> >In short, limiting the size of TLA to 13 bits looks like a reasonable cut, >today. I want to add that for the TLA and AAAA record discussion I see nothing wrong with having a stage 1 solution and then stage 2 and we create the backwards compatibility as implementors. I realize we need to provide the best solution for dynamic addressing and for ISPs. But right now real customers want IPv6 on "Intranets", or private enterprises. We will see several products this year and customers will be able to start deploying IPv6 from vendors. Many customers do not want to move to private addresses and a total v4 NAT solution who need addresses today. They want to move to IPv6 and have a plan to participate on the Internet even before the ISPs start supporting their needs for IPv6. I will also say that Europe and Asia appear to be moving much faster than the U.S. ISPs to be IPv6 ready. The point of this mail is that we implementors of IPv6 can absorb updates to the Address Architecture and AAAA records and we have changed the addr arch twice and once enough where we updated our code on the 6bone, and are using the new specs. The implementors will do the changes we develop and that should not be a fear of anyone IMO. The essential architecture of IPv6 is done and most of us have our code base prep'd to support the evolutionary IPv6 fine tuning by this working group. It is not difficult to move forward here with changes. One of the things that has always driven the IETF processes is the "market". There is now a market for IPv6 and they want it right now. We need to give it to them as vendors, and I hope we view that need in our deliberations. Also we have some new players at the UNH bake-off this week and one of them is Microsoft. This is really good. /jim From mnorris at hea.ie Wed Dec 17 13:14:16 1997 From: mnorris at hea.ie (Mike Norris) Date: Wed, 17 Dec 97 12:14:16 +0000 Subject: numbers for in-addr Message-ID: <199712171214.MAA05093@dalkey.hea.ie> The quality of the reverse DNS is something the LIR WG has discussed before, so I enclose for information Bill Manning's summary report. Apologies if you'se seen it already. Mike ------- Forwarded Message From: bmanning at ISI.EDU Posted-Date: Tue, 16 Dec 1997 13:54:52 -0800 (PST) Message-Id: <199712162154.AA29738 at zed.isi.edu> Subject: numbers for in-addr To: iepg at iepg.org Date: Tue, 16 Dec 1997 13:54:52 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-eof-list at ripe.net Precedence: bulk Status: RO As per previous notice, here are the results of the in-addr audits for 1997. I like the positive trend. :) Errors were generally related to the following conditions: - delegation to the host level e.g. 2.2.0.192.in-addr.arpa. - use of slashes e.g. 0/2.2.0.192.in-addr.arpa. - alpha strings e.g. test.2.0.192.in-addr.arpa. - other non-numberics e.g. #???.2.0.192.in-addr.arpa. - failure to fully qualify zones, e.g. the missing "." The no-server numbers is the total of the refused, error, and other columns. inital zone runtime total# #correct no-svr refused error other 3q97 97667 657 h 380021 220030 57.9% 159991 26335 90832 42824 4q97 99587 654 h 478311 281368 58.8% 196861 26871 103108 66882 I'd be happy to entertain questions. - --bill ------- End of Forwarded Message From phk at critter.freebsd.dk Wed Dec 17 13:56:41 1997 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 17 Dec 1997 13:56:41 +0100 Subject: numbers for in-addr In-Reply-To: Your message of "Wed, 17 Dec 1997 12:14:16 GMT." <199712171214.MAA05093@dalkey.hea.ie> Message-ID: <1974.882363401@critter.freebsd.dk> Does this survey alert the technical contact for the domains about the errors found ? Poul-Henning In message <199712171214.MAA05093 at dalkey.hea.ie>, "Mike Norris" writes: > >The quality of the reverse DNS is something the >LIR WG has discussed before, so I enclose for >information Bill Manning's summary report. Apologies >if you'se seen it already. > >er > >3q97 97667 657 h 380021 220030 57.9% 159991 26335 90832 428 >24 >4q97 99587 654 h 478311 281368 58.8% 196861 26871 103108 668 >82 -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." From Daniel.Karrenberg at ripe.net Wed Dec 17 19:38:51 1997 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 17 Dec 1997 19:38:51 +0100 Subject: numbers for in-addr In-Reply-To: Your message of Wed, 17 Dec 1997 12:14:16 GMT. <199712171214.MAA05093@dalkey.hea.ie> References: <199712171214.MAA05093@dalkey.hea.ie> Message-ID: <9712171838.AA09288@ncc.ripe.net> > "Mike Norris" writes: > > The quality of the reverse DNS is something the > LIR WG has discussed before, so I enclose for > information Bill Manning's summary report. Apologies > if you'se seen it already. I have asked Bill (a number of times) for a breakdown by /8. He will do it whan he gets time. Daniel From phk at critter.freebsd.dk Wed Dec 17 13:56:41 1997 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 17 Dec 1997 13:56:41 +0100 Subject: numbers for in-addr In-Reply-To: Your message of "Wed, 17 Dec 1997 12:14:16 GMT." <199712171214.MAA05093@dalkey.hea.ie> Message-ID: <1974.882363401@critter.freebsd.dk> Does this survey alert the technical contact for the domains about the errors found ? Poul-Henning In message <199712171214.MAA05093 at dalkey.hea.ie>, "Mike Norris" writes: > >The quality of the reverse DNS is something the >LIR WG has discussed before, so I enclose for >information Bill Manning's summary report. Apologies >if you'se seen it already. > >er > >3q97 97667 657 h 380021 220030 57.9% 159991 26335 90832 428 >24 >4q97 99587 654 h 478311 281368 58.8% 196861 26871 103108 668 >82 -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop."  From Daniel.Karrenberg at ripe.net Wed Dec 17 19:38:51 1997 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 17 Dec 1997 19:38:51 +0100 Subject: numbers for in-addr In-Reply-To: Your message of Wed, 17 Dec 1997 12:14:16 GMT. <199712171214.MAA05093@dalkey.hea.ie> References: <199712171214.MAA05093@dalkey.hea.ie> Message-ID: <9712171838.AA09288@ncc.ripe.net> > "Mike Norris" writes: > > The quality of the reverse DNS is something the > LIR WG has discussed before, so I enclose for > information Bill Manning's summary report. Apologies > if you'se seen it already. I have asked Bill (a number of times) for a breakdown by /8. He will do it whan he gets time. Daniel