In message <6fe949c2-18f3-432d-ab75-f66e71570...@hopcount.ca>, Joe Abley writes : > Hi all, > > The only suggestion I have heard relating to this draft is that if we supplie > d custom software to synthesise answers we could avoid the overly-broad SOA R > R returned with the NXDOMAIN. > > (My personal opinion is that this leads us down a path of needing to develop, > publish and support particular software for AS112 servers, presumably on eve > ry platform that anybody might imagine using to run an AS112 server, and that > this is a non-starter if for no better reason that there is no clear "we", h > ere.) > > Apart from that nothing much, which means one or more of (a) I missed some co > mments, (b) nobody cares, or (c) the draft is perfect as-is, in decreasing or > der of probability. > > Another specific question, then: should the working group adopt this document > ? Possible fodder for answers, PROVIDED AS-IS WITHOUT ANY EXPRESS OR IMPLIED > WARRANTIES: > > - everybody should just follow RFC 6303, if they did the AS112 project would > be superfluous > - apparently not everybody follows RFC 6303, e.g. <http://dns.icann.org/cgi- > bin/dsc-grapher.pl?plot=bynode&server=as112>
RFC 6303 was published less than a year ago. There really hasn't been time to see much RFC 6303 deployment yet to measure its impact. Now if we had data going back several years available to look at we might even see if the load is going up, down or staying steady. If you look at the classification graph[1] just talking to a single organisation will kill a lot of the traffic. 8.0.0.0 is a single organisation yet it is the third largest /8. [1] http://dns.icann.org/cgi-bin/dsc-grapher.pl?binsize=60&window=2592000&plot=client_subnet2_accum&server=as112 I personally think a vendor education campain would be more productive. We can't do much about already deployed servers but we can make sure the next major release supports RFC 6303 by default. > - we do need some mechanism to delegate (e.g.) zones under IP6.ARPA correspo > nding to the various v6 analogues of 1918 Do we have data that says we need to? Remember RFC 6303 style support for ULA was permitted a long time ago. ISC added it to named in 9.4.0. Full RFC 6303 support, to cover the RFC 1918 reverses, was only added in 9.9.0 the first major release after RFC 6303 was published. > - AS112 servers were previously specified in a document which was a product > of this wg, so subsequent guidance should properly do likewise > - this idea should properly be reviewed by this working group if it is to pr > oceed at all > - it would be just as good for this document to proceed as an individual sub > mission, since it will see dns directorate review anyway and hence all bases > will be covered > - this wg already has enough trouble processing the documents it has, we don > 't need more > - this is a bad idea, we should just let it die > > Adopt this doc? > > > Joe > > On 2012-06-12, at 10:40, Warren Kumari wrote: > > > Hi there all, > > > > So, back in (AFAIR) Taipei I proposed making AS112 instances simply be auth > oritative for *everything*, and then simply delegating and undelegating thing > s to it as appropriate (this would make things much simpler as there would be > very little coordination needed). At the time I realized that this would req > uire synthesizing answers (always a bit of a controversial topic), but it tur > ns out that there are a number of other things that may be equally contentiou > s, such as (thanks to Joe for this partial list): > > > > - assignment of new address space to separate omniscient and existing AS112 > nodes > > - v6 transport for omniscient AS112 servers > > - naming the omniscient servers under as112.net > > - reduced focus on the reverse tree (we could delegate anything we liked to > the omniscient servers) > > - unusual NXDOMAIN responses (the included SOA will be for a fake root zone > , not the enclosing zone) > > There are probably a bunch of other "interesting" implications... > > > > So, do any of these things sound like topics that might interest you? A goo > d chance to get annoyed / irritated? > > > > If so, here is the draft: http://tools.ietf.org/html/draft-wkumari-dnsop-om > niscient-as112-00 > > If not, well, feel free to say that too :-P > > > > W > > > > P.S: This is already being (slightly) discussed on the AS112 ops list, but > having all of the discussions (hint hint) in one place would be good. Oh, I'l > l be asking for consideration as a WG doc soon... > > > > -- > > Consider orang-utans. > > In all the worlds graced by their presence, it is suspected that they can t > alk but choose not to do so in case humans put them to work, possibly in the > television industry. In fact they can talk. It's just that they talk in Orang > -utan. Humans are only capable of listening in Bewilderment. > > -- Terry Practhett > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
