A new Request for Comments is now available in online RFC libraries.
RFC 8198
Title: Aggressive Use of DNSSEC-Validated Cache
Author: K. Fujiwara,
A. Kato,
W. Kumari
Status: Standards Track
Str
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
my next draft will definitely include "I'd like to thank Mark
Andrews for hitting me with a cluestick repeatedly WAIT WAIT WHY IS
THE ORCHESTRA STARTING OH MAN"
On Wed, Jul 26, 2017 at 10:11 AM, Mark Andrews wrote:
>
> In message
> , George
> Michaelson writ
> es:
>> read, support adopt
In message
, George
Michaelson writ
es:
> read, support adoption.
>
> suggest that favourite band sections be marked 'RFC-ED REMOVE' because
> the last time somebody thanked their mother, the backing band, their
> agent, the producers, the other candidates for award... it wound up on
> the ietf
read, support adoption.
suggest that favourite band sections be marked 'RFC-ED REMOVE' because
the last time somebody thanked their mother, the backing band, their
agent, the producers, the other candidates for award... it wound up on
the ietf list and we don't want to go there.
I am unsure about
JINMEI-san, all,
With reference to:
https://mailarchive.ietf.org/arch/msg/dnsop/zy86pvg139PaKFXo-BO6SPUfh3k
> I've reviewed the 04 version. I still do not think it's ready to move
> forward as it still abuses HINFO. I understand some other people
> don't care about this point, and some other
Hi Petr, all,
With reference to:
https://mailarchive.ietf.org/arch/msg/dnsop/lZDnD1kCZQ1Zvm0YF6wbWtg
> 1. The casse QTYPE=RRSIG should be made more prominent so it is
> understood and not misused as ANY. There are implementations like Knot
> Resolver which are work around missing RRSIG rec
Salut Stephane, tout le monde,
With reference to:
https://mailarchive.ietf.org/arch/msg/dnsop/wwQV0yUMdx1mwO8ig9UyNbMMMWI
> My personal nits, only editorial:
>
> > "ANY Query" refers to a DNS meta-query
>
> meta-query is not defined in this document, in RFC 1034, 1035 or
> 7719. Opinion: jus
Hi Richard, all,
I foolishly allowed Tim to pay for lunch and therefore have been tricked into
doing actual work. There are a couple more of these inbound to the list, one
for each of the e-mails containing points that were found not to have been
addressed in -04. My goal is to identify some ki
Paul Vixie wrote:
> Paul Wouters wrote:
> > On Tue, 25 Jul 2017, Paul Vixie wrote:
> >
> > > users believe that the recursive name server operator has aligned
> > > interests, and for that reason one shouldn't say "it's easy to bypass"
> > > but rather "end-user cooperation is required."
> >
> >
I have read the draft and support adoption. I plan to review and
contribute.
Peter
On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf wrote:
> This draft was the only one which seemed to have broad support in some
> form during the meeting last week.
>
> This starts a Call for Adoption for draft-wkuma
Paul Wouters wrote:
On Tue, 25 Jul 2017, Paul Vixie wrote:
users believe that the recursive name server operator has aligned
interests, and for that reason one shouldn't say "it's easy to bypass"
but rather "end-user cooperation is required."
So if 8.8.8.8 and your local ISP's nameserver do
I also support adoption. Current SERVFAIL messaging provides too little
information for interested parties and makes debugging problems
difficult.
On 25 Jul 2017, at 15:29, Bob Harold wrote:
On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf wrote:
This draft was the only one which seemed to have b
On 07/25/2017 01:07 AM, Paul Vixie wrote:
> i think content blocking is a reach -- in your interpretation.
>
> this is about CDN. as in, how to decide which address record set to
> give a dns client, given that all you know is the recursive server
> address, yet you're trying to implement policy fo
On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf wrote:
> This draft was the only one which seemed to have broad support in some
> form during the meeting last week.
>
> This starts a Call for Adoption for draft-wkumari-dnsop-extended-error
>
> The draft is available here:
> https://tools.ietf.org/html
The DNSOP WG has placed draft-wkumari-dnsop-extended-error in state
Call For Adoption By WG Issued (entered by Tim Wicinski)
The document was previously in state Candidate for WG Adoption
The document is available at
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-extended-error/
_
This draft was the only one which seemed to have broad support in some form
during the meeting last week.
This starts a Call for Adoption for draft-wkumari-dnsop-extended-error
The draft is available here:
https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02
Please review this draft
The DNSOP WG has placed draft-wkumari-dnsop-extended-error in state
Candidate for WG Adoption (entered by Tim Wicinski)
The document is available at
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-extended-error/
___
DNSOP mailing list
DNSOP@ietf.
> 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
darn, I keep reading 'client-id' as 'client subnet' :( back in my hole I go.
On Tue, Jul 25, 2017 at 9:53 AM, Christopher Morrow wrote:
>
>
> On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon wrote:
>
>> On Jul 24, 2017, at 8:59 PM, Christopher Morrow
>> wrote:
>>
>> and at the cache->auth layer it's
On Tue, Jul 25, 2017 at 5:55 AM, Ted Lemon wrote:
> On Jul 24, 2017, at 8:59 PM, Christopher Morrow
> wrote:
>
> and at the cache->auth layer it's potentially the case that the provider
> can say: "use precision of /24" or "use precision of /17" ? So, there's
> really not much "pii" that can be
On Jul 24, 2017, at 8:59 PM, Christopher Morrow wrote:
> and at the cache->auth layer it's potentially the case that the provider can
> say: "use precision of /24" or "use precision of /17" ? So, there's really
> not much "pii" that can be worried over at the provider-cache-resolver (they
> alr
On Tue, 25 Jul 2017, Paul Vixie wrote:
users believe that the recursive name server operator has aligned interests,
and for that reason one shouldn't say "it's easy to bypass" but rather
"end-user cooperation is required."
So if 8.8.8.8 and your local ISP's nameserver do this to track you, wh
Jacob Hoffman-Andrews wrote:
I agree: The EDN0 Client ID draft seems quite bad from a privacy
perspective, and I believe it should not be adopted.
More broadly, enforcing content blocks with DNS is an anti-pattern. If
we're assuming that the entity doing the content blocking has
administrative
I agree: The EDN0 Client ID draft seems quite bad from a privacy
perspective, and I believe it should not be adopted.
More broadly, enforcing content blocks with DNS is an anti-pattern. If
we're assuming that the entity doing the content blocking has
administrative access to DNS clients, they can
And then there are mobile phones with wifi and LTE tracking, already massively
abused by AP's and companies like Apple are randomising macs.
This draft is good for the ad business, not good for the enduser.
Paul
Sent from my iPhone
> On Jul 25, 2017, at 02:59, Christopher Morrow wrote:
>
>
26 matches
Mail list logo
