On Fri, Feb 03, 2017 at 08:54:59PM -0500, Ted Lemon wrote:
> On Feb 3, 2017, at 8:51 PM, Andrew Sullivan <a...@anvilwalrusden.com> wrote:
> > If the resolver "has a local zone for alt" -- I think this means it is
> > authoritative for that zone -- why would it a
ol uses that
do not rely on the DNS at all.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
tries for which they set the
policy.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
alt ends up in the 6761 special-use names registry, that seems a
reason for ICANN not to delegate the name. For adding something to
the 6761 special-use names registry removes it from the possible pool
of names that can be in the root zone.
Best regards,
A
--
Andrew Sullivan
a...@anvilw
ide the zone -- 'tis an empty / NXD answer, but still looks like
> shenanigans are happening...
>
If the resolver "has a local zone for alt" -- I think this means it is
authoritative for that zone -- why would it ask the root about it at
all?
A
--
Andrew Sull
community for them to do something following their processes, I have
no problem with it. But it's clearly outside IETF change control.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
mes at the root of
the namespace _is_ entirely on their turf, but actual data in the root
zone is quite different.)
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
changing a 30-ish year old DNS convention that has running
code basically on every computer in the known universe is something
that people with DNS operations experience might have some insight
about. (Which is not to say they're wrong.)
A
--
Andrew Sullivan
a...@anvilwalr
to see whether there are
more things not to include. (There is an argument to be made here
that the registry is insufficiently usable by machines, of course.
But we could fix that, too.)
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
On Mon, Mar 28, 2016 at 08:49:01PM -0700, David Conrad wrote:
>
> On Mar 28, 2016, at 8:36 PM, Andrew Sullivan <a...@anvilwalrusden.com> wrote:
> > But I think you're smuggling into your argument a claim that
> > they're potentially subject to the IPR and socio-economic i
based PDP were to
determine that they should be permanently reserved and that the
reservation ought to be sought in the 6761 registry.
Best regards,
A (as usual, for myself)
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ually had this
idea once before and chased that set of references and drew the same
conclusion. So much for relying on my memory, but thank you for
hitting me again with the clue-by-four. Maybe 3d time will be a
charm.
A
--
Andrew Sullivan
a...
ubject
to such a dispute.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
venom from the sting. In that context, let me ask whether
_alt or even _ would be better labels for this purpose. Part of the
goal has been to make these strings usable in applications (in "domain
name slots", as 5890 calls them). Would "_" work? Would "_alt"? I
have dou
I think that's right. It seems obvious to me that both local and
onoin met that test, because they both have a function of triggering
software to do something. I cannot say that I like this design
pattern, but it is well-established and it is clearl
this Section 4.
The question is whether the 6761 cases fall under "assigment of domain
names for technical uses". To me, the various questions in 6761
suggest that the answer is "yes", but you might disagree.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
__
than we might get by developing
this work here in DNSOP. The more signal we can get to suggest that
DNS actors are ok with the innovation, the lower I think that bar gets.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing l
at the new behaviour doesn't break
old-but-conforming implementations. That's how standards work.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
. End users are mostly going to do happy
eyeballs anyway, so if a recursive gets the with the A its own
load goes down because it can answer more stuff from cache.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
doesn't happy eyeballs do what is necessary here?
I think I'd feel a lot more comfortable with anything along these
lines if there were a signal from the resolver stating that it knows
what to do, but that still brings up server-side processing.
Best regards,
A
--
Andrew Sulliv
t I've been trying to suss out in this conversation is whether
there is any way to make that potential utility actual. Do you think
the repurposing you're mentioning is a realistic hope, or just a road
not taken?
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusd
sition is not important as such.
Thanks,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
me that there's a much
better way to lay this out. Thanks for the comments.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
nth, it's probably better
that I not form an opinion.)
Thanks for the correction.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
can start the label-by-label matching.
There is no guarantee that there's an answer in every class for a name
that is in one class. (If there were, the DNS would be broken today:
the root servers won't give you delegation information about non-IN
classes, as far as I can tell.)
Best regards,
A
-
lly interested in figuring out who is to blame, though.
I'm more worried that we have this quite old example sitting there
festering, and even it isn't handled right in the registries. What
hope does a new class have?
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.
ventions very similar to
traditional DNS.
I'll try to make all of this clearer in the next go-round. Thanks for
the comment!
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
putting anything in the registry is kinda awful, though. Certainly
another way in which classes appear to be loaded and aimed at feet.
Thanks for the reference!
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
y goal here
is to get a document out that effectively deprecates these bits, in an
effort to lay the ground for formal deprecation later and a possible
eventual re-use in some far off future. Before any of that can
happen, we have to admit we have a problem :)
A
--
Andrew Sullivan
a...@anvilwalrusd
g that this draft should be stronger, and recommend
closing the registry? That's how I started out, and I shied away
because it seemed like work for little benefit. But I could restore
that text :) It'd be a bigger deal, though, because it would then need
to update th
: internet-dra...@ietf.org
To: Andrew Sullivan <asulli...@dyn.com>
Subject: New Version Notification for draft-sullivan-dns-class-useless-01.txt
A new version of I-D, draft-sullivan-dns-class-useless-01.txt
has been successfully submitted by Andrew Sullivan and posted to the
IETF repository.
Author(s) : P. Hoffman, A. Sullivan, K. Fujiwara
> Category : INFORMATIONAL
> Source : Domain Name System Operations
> Area: Operations and Management
> Stream : IETF
> Verifying Party : IESG
>
--
Andrew Sullivan
Dyn
asulli...@dyn.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
le to make the Internet
better in an environment where we don't all agree about what "better"
is. I think many of us stand improvement (I here include myself) at
making our arguments less charged.
Best regards,
A (speaking, as usual, for
ts a need for
> clarification, regardless of what the clarification says.
For whatever it's worth, I had the same reaction. Probably I did a
bad job presenting the point.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://
tive advice about what should go into the
zone.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ill and Paul are right that if you're just trying to
publish "here's how we do it" without any helpful changes from the
IETF the ISE is the way to handle the document.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP
ot handle what is happening there.
Best regards,
A (emphatically, speaking for myself only)
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
etely new
publication mechanism for such specifications from ICANN.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ee no value in creating a new
publication path.
IMO, what is current practice, whatever it is, ought to be in the
document.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is definition, when I make a typo
> and type "hot.", and the root replies NXDOMAIN, "." is a
> pseudo-TLD ("A label that appears in a fully-qualified domain name in
> the position of a TLD, but which is not registered in the global
> DNS&qu
't care whether we remove it. Does anyone?
> I do not understand the sentence "The authors understand that there is
> much politics surrounding the delegation of a new TLD and thank the
> ICANN liaison in advance." Since this document does not ask for a
> delegation in the USG/IC
They certainly are domain names, and the text of 4.1 is quite clearly
needed under the rules of RFC 6761.
> On the Security Considerations (5) text:
>
> The text is unnecessarily speculative and the risk statement offered
> unranked compared to other well-known risks which are reflected in other
> "Security Considerations" texts.
Do you have specific changes you want to see?
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
nent.
I think the onion case is slightly more troublesome because of the
CA/B Forum decision. So that's a distinction that makes a difference.
No opinion, but I hope that's a useful observation.
Andrew (individual title only).
--
Andrew Sullivan
a...@anvilwalrusden.com
etf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
need? Especially when it's someone who hasn't
historically participated a lot here and who appears to be offering to
do free work?
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org
this is probably a gap in the
specification. It's hardly the first one in the DNS.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
in that respect,
because they're formally not part of the RRset but an RRSIG covers the
RRset and therefore has to travel with it.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
specified.
I'm not suggesting we try to invalidate lots of deployed software.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
. I think we agree about this
(since that's what you also said).
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
link
in the portion of the chain returned by the resolver.
This requirement is also interesting, because it's slightly different:
an ordering of different RRsets _of the same RRTYPE_, not of all the
RRsets.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
of this in RFC 1034 is quite long and never
actually offers the definition as such. So we want to note that the
label identifies one node in the sequence of nodes.
Does that work?
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP
the RRsets come in. Therefore any client that is
depending on an order has made a mistake.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
that
expectations of the old-fashioned Preferred Syntax from STD13 is all
over the place. Presumably, that's why people keep picking things
that sure look like domain names as identifiers; but we don't get to
have the advantages without all the built-in costs.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
hasn't decided to do that and I don't know whether it will.
Best regards,
A (for myself)
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
of the people who are proposing a registration
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
space is that people can do whatever they
want there, not that they can do what they want if they sign up for
such doing. We have no idea whether this will work, but it's worth a
try. I am strongly opposed to adding an IANA registry for alt.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
, forever?
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
idea? If we have an
IANA-maintained registry, why isn't that just an alternate TLD -- it
sounds just like a sponsored TLD to me.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
anything published because it wasn't perfect, and then
the number of recycles got high enough that nobody would review, so
the draft wasn't perfect, and so on. The editors will put their heads
together once more on the basis of the most recent comments.
A
--
Andrew Sullivan
Sorry for the top-post. As I understand things, this is more than a choice.
RFC 2181 requires it, I think, no?
--
Andrew Sullivan
Please excuse my clumbsy thums.
On Jul 15, 2015, at 06:00, John Dickinson j...@sinodun.com wrote:
On 14/07/2015 17:26, Casey Deccio wrote:
On Tue, Jul 14
things perfect.
I agree and acknowledge that there remain some definitions in there
that are contentious.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
be pleased to be wrong.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, but it didn't seem to work that way. So this
was not at least an oversight in my case.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
a bug in the
protocol, but it's a fact nevertheless. As a result, different
classes aren't really different namespaces.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
interoperability we have to cope with those facts.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
to stay back when you are neck deep in water is
not likely to work.
Therefore, I claim, we need to make some clear distinctions and
understand what has actually happened, and then adjust to the new reality.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
; but there are already rules for
that. But I think anyway that's a distraction. We don't need
uri-schemes to creep into this.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman
that we don't have the lexico-grammatical precision in English
that Latin does, but here we are.
Anyway, I hope this helps. If not, then perhaps I'm completely wrong
or perhaps I'm just doing a poor job explaining myself to you.
Best regards,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
this helps,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
in this document; I failed. If you
find some, that would be great.
If I recally correctly, it was excluded on socio-political grounds.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo
, and
then alt turns into RFC 1918 for DNS. (Although arguably we have that
with local anyway.)
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is not a static list. Please don't assume it is.
Seems like a lot of boilerplate for a two-sentence document, however.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
,
A
--
--
Andrew Sullivan
a...@anvilwalrusden.com
Awkward access to mail. Please forgive formatting problems.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, but I want to keep
testing it).
The distinction I'm making suggests why corp and onion seem different. They
are, in this fundamental resolution nature.
A
--
Andrew Sullivan
Please excuse my clumbsy thums.
On May 12, 2015, at 19:16, Ted Lemon ted.le...@nominum.com wrote:
On May 12
-use names if we have a valid
reason for doing so and there is no pre-existing conflict.
This is a bizarre argument. You don't get to kind-of delegate policy
authority this way. Authority was delegated, and if we don't like the
outcome we can go pound sand.
A
--
Andrew Sullivan
to be the same one. I don't feel strongly
about it, but fewer registries is probably better in this case.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
, 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 mailing list
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
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
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
___
DNSOP mailing list
DNSOP@ietf.org
https
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 d...@virtualized.org wrote:
I have never heard of ARPA being treated as a subclass
and not
protocol.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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
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
DNSOP@ietf.org
https
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
.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
is a descendant of the example.com
zone, both glue records are in-bailiwick.
In the last sentence both seems out of place, I think the would be
better.
Good catch, thanks.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
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.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org
-a
On 3/21/15, 11:12 PM, Andrew Sullivan a...@anvilwalrusden.com wrote:
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
.
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
it was not
necessary.
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
(which I elided).
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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
,
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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...@anvilwalrusden.com
___
DNSOP mailing list
DNSOP@ietf.org
https
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
101 - 200 of 398 matches
Mail list logo
