On 7/6/2018 8:13 PM, Tim Wicinski wrote:
Tim Wicinski has requested publication of
draft-ietf-dnsop-rfc5011-security-considerations-12 as Proposed Standard on
behalf of the DNSOP working group.
Please verify the document's state at
All,
We feel that the authors have addressed all outstanding issues, and this
document is ready to move forward. Also, the chairs wanted to kick off
this Working Group before Montreal so if there are any issues that need
some face time, we'll have it.
One thing which arose early in the
We've had some interest in moving this document forward, and the chairs
wanted to kick off this Call for Adoption before Montreal so if there
are concerns there will be some meeting time to address.
This document is label as: Informational. The document is attempting
to document operational
Tim Wicinski has requested publication of
draft-ietf-dnsop-rfc5011-security-considerations-12 as Proposed Standard on
behalf of the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/
On Fri, Jul 06, 2018 at 08:22:41AM +0200, Matthijs Mekking wrote:
> Me too :)
>
> https://github.com/each/draft-aname/pulls
Yes, sorry, my bad. I'll try to address the pull requests next week.
Should've done ages ago.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
On Fri, 6 Jul 2018, Dave Crocker wrote:
Translator's note: change this to "left most" when translated
to Arabic or Hebrew.
in rtl contexts, domain names are shown with the root at the left???
If they're IDNs in rtl languages, apparently so. If they're a mix, or all
ltr, it's anyone's
On 7/6/2018 9:35 AM, John Levine wrote:
Translator's note: change this to "left most" when translated
to Arabic or Hebrew.
in rtl contexts, domain names are shown with the root at the left???
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 7/6/2018 8:39 AM, Dave Crocker wrote:
Editorial: 'that is they are the "top" of a DNS branch, under a
"parent" domain name.' I assume that "top" is used instead of "apex"
because the sentence does not always refer to the top of a zone?
'zone' is almost certainly not the term to apply here.
John Levine wrote:
>
> You're probably right, but I think that ANAME would need as many
> upgrades, just in slightly different places.
ANAME should work without upgrades, because A and queries will get
the answers they expect. ANAME support is just a performance optimization
when the ANAME
In article <349edb95-48ff-41a2-4cda-1c9ed44f7...@bbiw.net> you write:
>> Editorial: I would prefer all occurrences of "right-most" to be
>> replaced by "most general", to emphasize that it is not the position
>> which matters, it is the closeness to the root.
>
>So let's start by making sure we're
In article <5b3e8242.1010...@redbarn.org> you write:
>i think you will find that there is no dnssec-compatible way to solve
>this problem without upgrades to both authority AND recursive AND stub
>dns agents, AND to the getnameinfo-or-similar API. if i'm right, it'll
>be necessary to make hard
Stephane, thanks for the comments.
Inline...
On 7/6/2018 8:22 AM, Stephane Bortzmeyer wrote:
On Mon, Jun 25, 2018 at 12:27:17PM +0200,
Benno Overeinder wrote
a message of 27 lines which said:
This starts a Working Group Last Call for draft-ietf-dnsop-attrleaf
I've read -10 and it
On Mon, Jun 25, 2018 at 12:27:17PM +0200,
Benno Overeinder wrote
a message of 27 lines which said:
> This starts a Working Group Last Call for draft-ietf-dnsop-attrleaf
I've read -10 and it seems OK. It solves a real issue, and does it
properly.
Editorial: I would prefer all occurrences of
On Fri, Jul 6, 2018 at 9:06 AM Bob Harold wrote:
>
> On Tue, Jul 3, 2018 at 12:36 PM Ben Schwartz 40google@dmarc.ietf.org> wrote:
>
>> Thanks for improving the clarity of this draft.
>>
>> Could you provide an example of a use case where the baseline DOH
>> behavior is not sufficient, to
On Tue, Jul 3, 2018 at 12:36 PM Ben Schwartz wrote:
> Thanks for improving the clarity of this draft.
>
> Could you provide an example of a use case where the baseline DOH behavior
> is not sufficient, to motivate the "proto" parameter? The text mentions a
> "transparency principle" as
> On 6 Jul 2018, at 6:59 pm, Philip Homburg wrote:
>
> In your letter dated Fri, 6 Jul 2018 18:50:44 +1000 you wrote:
>> All it does is ensure that the DNS queries get to the DNS64 server.
>
> The way RFC 7050 works that you send queries to your local recursive
> resolver. The problem there
Tim Wicinski has requested publication of draft-ietf-dnsop-refuse-any-06 as
Proposed Standard on behalf of the DNSOP working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
___
DNSOP mailing
In your letter dated Fri, 6 Jul 2018 18:50:44 +1000 you wrote:
>All it does is ensure that the DNS queries get to the DNS64 server.
The way RFC 7050 works that you send queries to your local recursive
resolver. The problem there is that if the user manually configured
a public recursive resolver
All it does is ensure that the DNS queries get to the DNS64 server.
--
Mark Andrews
On 6 Jul 2018, at 18:33, Philip Homburg wrote:
>> Most of the special
>> handling could be avoided if IANA was instructed to run the servers
>> for ipv4only.arpa on dedicated addresses. Hosts routes could
> Most of the special
> handling could be avoided if IANA was instructed to run the servers
> for ipv4only.arpa on dedicated addresses. Hosts routes could then
> be installed for those address that redirect traffic for ipv4only.arpa
> to the ISPs DNS64/ipv4only.arpa server.
>
> Perhaps 2 address
On 07/05/2018 06:15 PM, Tony Finch wrote:
Tim Wicinski wrote:
The chairs have decided to set aside some time in Montreal and see if we
can work through this problem. We've asked Ondřej from ISC and Willem
from NLnetLabs to help guide the talk.
I was hoping that there would be another
21 matches
Mail list logo
