applications are the only way to do this? If so, then
you're right that it needs adjustment.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
over, it demonstrates that onion queries
will leak to the public DNS if such special software is not in place.
I think this shows that appelbaum-dnsop-onion is in fact correct.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mail
at _my_ employer, but I can imagine such a case
without trouble.)
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
-names registry by different
criteria than the protocol-shift cases. The latter all fit neatly
into 6761's "7 questions", but policy-based ones sort of don't.
Anyway, that's a suggestion.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
__
I didn't send additional comments when the
document didn't get broken up, becuase I said in the first place that
I thought it was a fatal flaw.
> I'm looking forward to break this opportunistic behavior to play
> politics and satisfy administrative formalities
I think that's just an _ad hominem_ argument. There are good reasons
for the changes in appelbaum-dnsop-onion as compared to p2pnames, as
outlined above.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Since I already said I was ok with the addition, can we just stipulate that I'm
wrong and move along with it?
A
--
Andrew Sullivan
Please excuse my clumbsy thums.
> On May 6, 2015, at 17:06, David Conrad wrote:
>
> I have never heard of ARPA being treated as a su
in the terminology document,
I'm worried about document bloat, but I'm not unalterably opposed to
this.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
o well-known that some widely-deployed systems that rely on DNS
names interpret a label with a high bit as UTF-8. And such uses are
entirely in keeping with STD 13.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DN
rs about those other categories.
Even around ICANN policy discussions everything that isn't a ccTLD is
treated as a subclass of gTLD.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e that it's a matter of policy and not
protocol.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
standing to have a ccTLD.
There's already text in there for this.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
label" language.
But it's pretty hard to understand, and still faintly circular.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ardless of what the child
> "thinks."
Well, effectively maybe not. If a resolver "sticks" on the child,
then the delegation won't move regardless.
> #Referrals -- ... Historically, many
> #authoritative servers answered with a referral to the root zone when
> #querie
ight reply with glue records for ns.child.example.com.
>Because the child.example.com zone is a descendant of the example.com
>zone, both glue records are in-bailiwick.
>
>
> In the last sentence "both" seems out of place, I thi
ct a
logical point in the tree, and the zone origin is the implementation
of that. I think that is just entailed by the way STD13 is written.
I think errata would be incorrect: if this is a change, it's a clarification,
not an erratum in any previous document.
k the thing is you can have multiple masters, but for years
people referred to one of them as the "primary master" i.e. the one
you _actually_ changed before changing everything else.
I guess that has faded over time.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
__
sed complex situation in a sane manner; an example of this might
> be http://en.wikipedia.org/wiki/Tor2web
>
> -a
>
>
> On 3/21/15, 11:12 PM, "Andrew Sullivan" wrote:
>
> >In section 4, 3-5, what if a "synthetic" NXDOMAIN gets generated and
> >
ually not in the DNS as
it shows up in the domain name slot.
In section 4, 3-5, what if a "synthetic" NXDOMAIN gets generated and
cached? Will that have any effect on .onion resolution? If this is
explained in detail in some thing I've failed to follow, a simple
reference would be e
hought it was not
necessary.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
viously not exhibit the new behaviour.
What's the problem?
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
.com's NTA need not (MUST NOT?)
affect .net or example.net or lower.example.net or even example2.com.
Respectfully submitted,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
which the name server answering is not
> authoritative for an ancestor of the owner name of the record.
>
Given the previous discussion about glue, that word seems especially
fraught here.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
like the proposed alternative text (which I elided).
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
h is a good reason not to do that.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ot
to give you a response anyway so it's just pollution traffic. But do
not delude yourself into thinking that adding stuff to the special
names registry will do anything to prevent leaking. It will not.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
l draft is, as I've pointed out more than once, that it
treats a bunch of rather different cases as though they're the same.
They're different in detail, and therefore they ought to be split up
and processed independently.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusde
should say
so and be done with it.
In any case, I don't like all this conditional logic around ANY. It
seems to me likely to make code bases brittle and hard to change, new
implementations to be hard to get right, and to make operations
troubleshooting much harder because you have to cov
at the moment, which makes
me think it probably happened on namedroppers@ and not on dnsext@.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
er should have made it to the Net in the first place.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
arbage
Or arbitrary UTF-8 strings. There are systems that use them,
including some from the small vendors called "Apple" and "Microsoft".
(I don't think we're saying anything different; just trying to point
out this isn't theore
too). This is an operational
convention, not something that flows from the name "domain", and I
don't think we should define anything such that it depends on the
nature of domains.
a
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP m
tly, I suggest, you're not
implementing DNS.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
should be IDNA-conformant"? If so,
underscore labels are out, and that seems like it'd suck.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
be
tidier than having people doing it in the root zone.
Thanks,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ult. The proposal
to use a widespread configuration of RPZ to chip away at the
legitimate answers from root name servers strikes me as a rather
dangerous arrogation of control over the root zone and contrary to the
observations in RFC 2826.
Best regards,
A
--
Andrew Sulli
x27;d like one of these documents
to go ahead.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
up-thread that that isn't quite true.
I understood him to mean that what you're really doing with those
other protocols is tunneling them inside Tor. I guess I can see an
argument that we don't use such scheme identifiers for other tunnels,
so we wouldn't in this case either.
Bes
ly be susceptible to a different URI
scheme whereas others don't work that way. I'm sorry I mentioned
classes; it's a distraction.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the namespace as a clue that the protocol has shifted.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e else. When that top-level
name space was entirely stable, hiving out new chunks did not present
inter-community risks, but now that the space is not so stable the
technical and administrative risks are greater.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the
IETF has in fact delegated the responsibility of managing the root
zone to IANA, and the IANA operator is ICANN. Having made that
delegation, it seems rather arbitrary of us to come along and yank
back chunks of it for political reasons. Hence my concern.
Best regards,
A
--
Andrew Sulliv
r to facilitate that.
That doesn't mean that the namecoin system shouldn't be supported.
But it seems to me that there's a difference between registering a
special name for this, and registering it such that we alter the size
of the root namespace.
Best regards,
A
--
Andrew
proceed until either
bit is removed from it, or a justification for the registration of bit
is added to the document.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I really like this approach. Thanks!
--
Andrew Sullivan
Please excuse my clumbsy thums.
> On Nov 30, 2014, at 9:02, Tony Finch wrote:
>
> Andrew Sullivan wrote:
>>> On Sat, Nov 29, 2014 at 12:06:28PM +1100, Mark Andrews wrote:
>>>
>>> A iterati
hifts modes. And if you use the
policy-implementing resolver, then it's consensual: you selected it.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
13, which is at least as confusing).
But I think Paul put his finger on the problem with that text: there's
no way to know in advance what sort of server you're querying.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ie
The case you describe is "consensual", because you can change it. A
non-consensual case would be the one where all traffic to port 53 at anything
other than the operator's resolver is blocked.
A
--
Andrew Sullivan
Please excuse my clumbsy thums.
On Nov 28, 2014, at 16:22
rom 2006-2008. We went through a
lot about these use cases then. You can reach back further if you
like -- the draft's filename once contained the word "required", which
is I suspect part of what hurt it so much.
Best regards,
A
--
Andrew Sull
(Full disclosure: I'm on the
IAB now, but I wasn't when that was written. I'm not, as usual,
writing with an IAB hat on.)
> Yes, but with changes explicitly limited to the NS RRset, and not
> affecting any delegation content.
Because we
change other records too? And who gets to control this other zone?
It's no longer "the root zone", by definition. It's an alternative
zone, it seems to me.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ely demonstrated the
utility of saying "here's what you should do with the reverse tree".
No consensus will be reached.
"How it works and what happens if you don't pay attention?" Yes. I
already volunteered upthread, if people think they actually want that.
get for those who want things to be different than
what's in the "official" root? That is, in effect, isn't this a plain
old alternative root?
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Thu, Nov 06, 2014 at 09:41:57AM -0800, Paul Hoffman wrote:
> Do we know whether typical PTR checks look for existence or matching?
It depends. (We covered this to some extent in that failed
reverse-tree draft.)
A
--
Andrew Sullivan
a...@anvilwalrusden.
ar! No reason it shouldn't in this case!
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
er, in cases where address block holders fail to
properly configure reverse mapping, users of those blocks are
penalized.
Re-reading it today, it seems to me the text was altogether milquetoast.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
s to
try to find consensus has declined in the intervening years: I just
don't think there _is_ a consensus on this.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
it's important that those
interested take the idea seriously and not just dismiss it as
unworkable in the general case. It might not be a general-case tool,
but one that needs to be carefully circumscribed for certain uses (if
that is even possible).
Best regards,
A
--
Andrew Su
On Fri, Oct 31, 2014 at 05:28:40PM +0100, Stephane Bortzmeyer wrote:
> something that is "against the rules laid out by the standard".
"Nonconforming", then. I have to agree that "illegal" is wrong.
There are no DNS cops, despite what many people woul
ue is actually "query maximization". If one called it "query
disclosure minimization" or something like that it'd be closer to
describing what happens.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP ma
t;No, not like that." I am
increasingly convinced that this feature is one of those well-known
ponies.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
100% uptime from
their DNS as a matter of course, and they don't care about anycast for
that reason. They care about performance of page loads, and nothing
else.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSO
ing client has to do its own recursion, lest it trut something
without basis. Is that what you're suggesting? I'm not opposed, but
let us be clear.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
http
Right now,
_nobody_ who doesn't already know what a DNSOP is will know about this
draft. At least if we publish it, there's some hope people will find
it when searching for relevant RFCs.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
__
idence about what to improve.
Please publish it.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
from the dead, it was
supposed to issue a whole bunch of such clarifications, but little
actual work got done. Perhaps a document just on terminology would be
a good start, because a little less ambitious.
A
--
Andrew Sullivan
a...@anvilwalr
loads. If the proposals in this draft are widely adopted, that will
by definition change the profile of the traffic the root servers see,
and that will mean that such potential traffic will not be considered
in the planning by root server operators. This may not be a fatal
flaw (probably it
te that this means that DANE type approaches won't work reliably
with ENAME until everyone has upgraded validators.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
opportunities.
> Would people be interested in attending such a meeting?
>
I'd certainly show.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e this, because it's still a one-way pointer.
One of the ideas I originally had for the SOPA record I proposed is
that you'd be able to extend it to include this sort of variant-policy
mechanism, and it's designed to be a two-way link. So far, however,
I've had pretty nega
do that, which I took to be evidence that we did it too
slowly. Perhaps this is an opportunity for those who think I was too
keen to prove what a jerk I am. That oughta be incentive ;-)
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
__
are, you
> guessed it, "not allowed" to make that design assumption.
These are both "not allowed" in the sense of "I'm in charge here, and
I scold you." That's not what I meant. These cases are not
entailments of the very definition of the system, but instead a
e side anyway. I
think that's out of scope for this document, though I'm certainly
prepared to work on another doc that talks about these issues.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
eople who have no clue
will make more "improvements".
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
draft, and I think it ought to go
ahead. It does alter the DNS protocol, so DNSOP is not the WG for it.
I have included the DNSEXT mailing list, which is supposed to be where
we discuss such changes, though I confess I have faint hope we'll
actually do that.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
u're
in. And so on. I dearly wish you were right that controversial
techniques always fail or get an AS.
Anyway, I think I should be embarrassed to have a meta-argument about
whether we even ought to work on a draft. Those of us who think
edns0-client-subnet ought to be documented can wo
ws the
actual protocol specification could use some attention).
If this were not the case, then in fact we'd have had to discuss the
entire architectural context of any DNS feature. It only seems like
the DNS RFCs are infinitely long.
Best,
A
--
Andrew Sulli
published or
else publish it on the Independent stream) that said, "Wide Area
Recursive DNS Considered Harmful." I think that's a separate question
from, "How to deliver topological information from a recursive server
to an authoritative?&quo
On Wed, May 07, 2014 at 07:06:34PM +0200, P Vixie wrote:
> If ietf documents client-subnet then it should be an FYI.
Can't do that. https://tools.ietf.org/html/rfc6360, "Conclusion of FYI RFC
Sub-Series".
A
--
Andrew Sullivan
a...@
can only
learn about by hanging out on secret-handshake mail lists.
Moreover, we edns0-client-subnet has a code point in the EDNS0 OPT
registry. Doug's argument seems to be, "Let's have that code point
and let it be mysterious." I think that would be a perverse outco
to deny TCP/53 as a matter of course
ought to have his or her Internet license revoked.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
then new measurements and new estimates will have to be made.
suggests that re-measurement is necessary in the face of IDNA. Does
this mean it's time to do that measurement, since in fact we have a
number of IDNA TLDs now?
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
ages, and how they will interact moving forward. Work in a
>liaison capacity to ICANN to assist in this.
Given that "liaison" is a term of art around the IETF, perhaps the
latter sentence needs to be phrased another way? I'm not sure exactly
what you have in mind, o
that we do not have a common
meaning of "easiest". Perhaps you could say more.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ix the internationalization issues. We could
ditch UDP and in a single blow eliminate a major source of DDoS on the
Internet. And so on.
The only problem is getting everyone to upgrade. No?
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
that under some use cases the recursive server will
provide better results if it validates, which is subtly different from
what you say there. "Need to" is too strong. "Undesirable things
happen if not" might be true.
Best regards,
A
--
peek at RFC 6840, especially section 5.9
and Appendix B.
None of this, AFAICT, helps us at all with the 1024/2048 choice.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
st, but I think hindsight may be
different than foresight.
I don't think you can make the argument that the root zone is not
signed now, because if you do then in some future when 2048 bit RSA
turns out to be vulnerable, you'll have to repeat the argument. That
seems absurd (it devolves to
On Fri, Mar 21, 2014 at 09:49:46AM -0400, Tim Wicinski wrote:
> But I understand what you mean here, and I was thinking it was a
> logical extension.
Since the expansion of the term is "The DNS Security Extensions", it
is indeed a natural extension at least.
A
--
A
rust.
But to start that discussion, we first have to figure out from whom we
are protecting ourselves.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
in some sense
because it's clarifying the meaning of the protocol, we can send it up
via AD sponsorship or run it through the INT area WG or whatever. I
think it's very valuable to get some clear idea of what we think
first, though.
Best regards,
A
--
And
; name looks like shouldn't matter.
Are NetBIOS names domain names? How about mDNS names? I think yes,
but neither is part of the DNS as such.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Fri, Feb 28, 2014 at 10:43:00AM -0500, John R Levine wrote:
> I suppose Bonjour is a reasonable way for the router and the PC to
> fine each other, haven't looked at the details.
This entire discussion sure looks like something that ought to inform
homenet and dnssd, no?
A
looks like DNS, so it should be
swatted over to the DNS weenies" ones.
If the goal is a "Get off my lawn" working group, then big generic
questions are in order. But I think we can do better.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
_
> But that's a fairly artificial point to be making, so argue away! :)
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
Andrew Sullivan
a...@anvilwalrusden.com
_
irst place?
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ion of the public DNS.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the grothoff draft; see my earlier review.
Best,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
e rather emotionally charged and
dismissive of any pointy question or suggestion that the interests of
the rest of the DNS (including the root management regime) need to be
taken into consideration as well. It seems to me that you could read
with a more generous application of the prin
and it appears to be
purely a local-resolution-only one -- that is, always "protection of
the DNS" because of de facto resolution and security decisions
deployed on the Net. I haven't read it closely enough to decide
whether this is true for every label in the list.
Best,
A
--
Andr
201 - 300 of 532 matches
Mail list logo
