> On Jul 25, 2017, at 8:53 PM, Christopher Morrow
> wrote:
>
> I don't believe the goal of the draft is to enable filtering.
The goal of the draft is to provide options. How those options are deployed is
between the customer and the operator as defined by their contract.
signature.asc
Descr
The irony to the privacy and client-id discussion is that we have another “DNS
Privacy” WG which gives me wonderful ID from the crypto termination on the
resolver.
The reality with client ID is just like RPZ adoption. Operators need
flexibility to face reality. If the DNSOP’s choice is to not
+1
> On Sep 6, 2017, at 1:04 PM, Jared Mauch wrote:
>
> I support adoption of the document.
>
> - Jared
>
>> On Sep 5, 2017, at 3:25 PM, tjw ietf wrote:
>>
>> August is over and my self-imposed holiday is over, so it's time to get busy
>> again. We have this document marked as a candidate
> On Jan 1, 2017, at 6:00 AM, Ted Lemon wrote:
>
> There is no _way_ to make it easier for said outside forces to pressure
> providers. They have the force of law on their side. What we do makes no
> difference in that arena. The arena in which it _does_ make a difference is
> protectin
> On Jan 8, 2017, at 6:54 AM, Scott Schmit wrote:
>
> Eventually, if DNSSEC verification on endpoints becomes widespread,
> operators will need to turn to other means or break DNSSEC in these
> cases (but redirection will stop working).
Bad guys are not going to take the time to use DNSSEC to b
> On Mar 13, 2017, at 4:11 AM, Paul Wouters wrote:
>
> The draft breaks DNSSEC
The draft does not break DNSSEC. How version of DNS software implement RPZ can
have issues with DNSSEC. There are some software that can inject a RPZ feed and
not break DNSSEC.
Paul - changes to existing practice is a _new_ document. You take the existing,
coded, and deployed specification in as an informational RFC. Then you start a
new working group document for the full “IETF version.”
We’ve done this for many other protocols over the last several decades. Why the
Hello Yu Fu,
I was not at the workshop. Warren already mentioned some issues. I second what
he is saying in a stronger terms:
+ What you are proposing has no value for optimizing content delivery on the
Internet. Physical location and the topology of content delivery do not match.
Also, Anycas
> On Mar 21, 2017, at 11:38 PM, Lanlan Pan wrote:
>
> However, if you know about the geolocation , you can
> make a better response, most of time, is the best response too.
Your statement is not matching the operational realities I live in. I
understand how mapping is done in my current envi
> On Mar 28, 2017, at 12:31 PM, Peter van Dijk
> wrote:
>
> Please note that neither draft handles the use case of also passing the port
> number, which in a world of growing CGN deployment, may soon prove quite
> important.
Can you elaborate?
___
10 matches
Mail list logo
