Hi all,

The only suggestion I have heard relating to this draft is that if we supplied 
custom software to synthesise answers we could avoid the overly-broad SOA RR 
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 every 
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", here.)

Apart from that nothing much, which means one or more of (a) I missed some 
comments, (b) nobody cares, or (c) the draft is perfect as-is, in decreasing 
order 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>
 - we do need some mechanism to delegate (e.g.) zones under IP6.ARPA 
corresponding to the various v6 analogues of 1918
 - 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 
proceed at all
 - it would be just as good for this document to proceed as an individual 
submission, 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 
> authoritative for *everything*, and then simply delegating and undelegating 
> things 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 require synthesizing answers (always a bit of a controversial topic), 
> but it turns out that there are a number of other things that may be equally 
> contentious, 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 good 
> chance to get annoyed / irritated?
> 
> If so, here is the draft: 
> http://tools.ietf.org/html/draft-wkumari-dnsop-omniscient-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'll 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 
> talk 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

Reply via email to