In message <e4ad7d21-995c-46b1-813e-70ca0919f...@hopcount.ca>, Joe Abley writes
:
>
> On 20 Aug 2014, at 17:48, Mark Andrews <ma...@isc.org> wrote:
>
> > You will give answers that validate as bogus in the stub resolver.
>
> This seems to be the crux of our differing world views.
>
> > A validating stub resolver
>
> Validating stub resolvers?
>
> In my own personal taxonomy a stub resolver doesn't validate. Validation
> signalling is available from a validating resolver (e.g. using the AD
> bit, of which I am not a fan), and that resolver (validating or not) is
> where I was suggesting the locally-relevant data would be served.
>
> (Note that I'm not saying that my own personal taxonomy is of any use to
> anybody apart from me; I'm just putting it out there by way of
> explanation of the current forehead wrinkles. I continue to think it
> would be good to have a common understanding of these overloaded terms.)
>
> Anyway, I'm not arguing against the idea of making certain delegations
> verifiably insecure. I think any of us could write up an I-D with an IANA
> Considerations section that specified the correct behaviour, if we want
> to do this properly with a documentation trail. (Maybe the nice IANA DNS
> Operations people could be convinced to make the change anyway without or
> in advance of documentation, but I tend to think that documentation is
> good in general.)
IANA should have enough from RFC6598 as it says that lookups shouldn't
go to the Internet and they only way for that to work with validating
resolvers is to break the DNSSEC chain of trust. It is a implict
instuction but it is a instruction.
Or we could finish !@$!#$!@#@R!EW!RQ@ processing this document and
IANA will follow the explict instructions in RFC6303. It has passed
wg last call on January 3rd, 2014 and stalled!
I don't see any Q@#R#!@##$ point in writing a third document.
Yes, I'm !@#RQWRET!$#R!@# annoyed.
"On Dec 7, 2013, at 5:59 AM, Tim Wicinski <tim.wicinski at teamaol.com> wrote:
We're kicking off the Working Group Last call on Adding 100.64.0.0/10 prefixes
to IPv4 Locally-Served DNS Zones Registry. The author believe that this
document has addressed all the issues raised on the document. The latest
version of the draft is available at:
http://www.ietf.org/id/draft-ietf-dnsop-rfc6598-rfc6303-00.txt
http://tools.ietf.org/html/draft-ietf-dnsop-rfc6598-rfc6303-00
Because of this last call is surrounded by the upcoming holiday season, we're
making this a four (4) week last call cycle.
Substantive comments and statements of support/opposition for advancing this
document should be directed to the mailing list. Editorial
suggestions can be sent directly to the authors. The chairs will send in their
comments as well during the last call period. This last call will
conclude on January 3rd, 2014."
I had a previous document stall for *years* after last call passed
with dnsop as Peter just didn't do the writeup. I don't wan't the
same thing to happening for this document as well.
> Joe
--
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
