> On Mar 8, 2019, at 3:00 PM, 神明達哉 wrote:
>
> At Mon, 4 Mar 2019 19:45:02 -0500,
> Tom Pusateri mailto:pusat...@bangj.com>> wrote:
>
> > Thanks to the great feedback, we were able to update the document to
> > better match the preferences of the working group and address the
> > outstanding
On 08/03/2019 18:33, 神明達哉 wrote:
For example, assume that an operator uses dnsdist as a DNS load
balancer and BIND 9 as backend servers with RRL, and the operator
wants to trust particular clients (identified by their IP addresses)
and bypass RRL for them. How can we expect off-the-shelf
Thank you very much for the feedback, Jinmei.
Combined with previous changes we made following the other messages on
the draft we expect to republish it before the Monday IETF 104
submission deadline, after one last review by all of the co-authors.
Jinmei:
>> The definition of TTL in [RFC1035]
At Mon, 4 Mar 2019 19:45:02 -0500,
Tom Pusateri wrote:
> Thanks to the great feedback, we were able to update the document to
> better match the preferences of the working group and address the
> outstanding concerns.
> > A new version of I-D, draft-pusateri-dnsop-update-timeout-02.txt
> > has
At Fri, 8 Mar 2019 12:03:27 -0500 (EST),
Paul Wouters wrote:
> [my last email in this thread. I don't think we are progressing and I'd
> like to give others a chance to participate in this thread. But feel
> free to reply]
>
> >> But assigned and left completely opague is not really
On Fri, 8 Mar 2019, Ray Bellis wrote:
[my last email in this thread. I don't think we are progressing and I'd
like to give others a chance to participate in this thread. But feel
free to reply]
But assigned and left completely opague is not really suitable for
"heterogenous off-the-shelf
On 08/03/2019 14:28, Paul Wouters wrote:
But assigned and left completely opague is not really suitable for
"heterogenous off-the-shelf software". These different vendors must
understand the meaning of the opaque data even if their functionality
can be non-standard.
No, it does *not* require
On Fri, 8 Mar 2019, Ray Bellis wrote:
I have some generic use cases in mind (subject to the existing cautions about
bilateral agreements, consenting adults, etc) and also a very specific use
case.
I have customers that want to tag a packet received by a DNS load-balancer
and then on the
Hello Ray,
On 8 Mar 2019, at 11:33, Ray Bellis wrote:
On 08/03/2019 03:58, Paul Wouters wrote:
If you have a specific use case, get a code point for that specific
use
case. Than you know for sure what the blob means and that it will be
interpreted by all parties in the same standard RFC
On 08/03/2019 03:58, Paul Wouters wrote:
If you have a specific use case, get a code point for that specific use
case. Than you know for sure what the blob means and that it will be
interpreted by all parties in the same standard RFC way.
I have some generic use cases in mind (subject to the
On Fri, 8 Mar 2019 at 03:58, Paul Wouters wrote:
8<
You are suggesting to introduce an option code point to convey blobs in
> DNS. So different parties can send and receive blobs. You think or hope
> that these parties will interpret this blob the same. But you have no
> guarantee this is true.
Folks,
We have a new version of our draft:
https://www.ietf.org/id/draft-moura-dnsop-authoritative-recommendations-02.txt
We will present it for the first time to the WG in Prague.
As always, feedback is much appreciated.
Major changes:
- 's/anycast site/anycast instance/g' to conform to
12 matches
Mail list logo
