Ted Lemon wrote on 2019-04-03 15:34:
Paul, it might be worth asking whether you believe that isps should be
selling eyeballs. If you think they should, then your argument makes
sense. It’s the same argument isps give for charging me for service and
then charging Netflix for access to me.
If
On Wed, Apr 3, 2019 at 6:34 PM Ted Lemon wrote:
> Paul, it might be worth asking whether you believe that isps should be
> selling eyeballs. If you think they should, then your argument makes sense.
> It’s the same argument isps give for charging me for service and then
> charging Netflix for acc
Paul, it might be worth asking whether you believe that isps should be
selling eyeballs. If you think they should, then your argument makes sense.
It’s the same argument isps give for charging me for service and then
charging Netflix for access to me.
If you don’t agree with this model, then your
i had to think about this for quite a long time. i've trimmed the cc
headers.
Christian Huitema wrote on 2019-03-12 20:39:
On 3/12/2019 7:56 PM, Vittorio Bertola wrote:
...
The mirror image of that statement is, "when did intermediaries get
a mandate to filter content?"
it was rarely a man
On 3/13/19 6:17 PM, Stephen Farrell wrote:
> Those seem like unrelated (and repetitive) points, except for your
> attempt to try equate (I assume) a browser using DoH with malware.> That's
> the kind of overblown statement that detracts from any other
> reasonable points you may make (for me a
Hi,
On 14/03/2019 00:07, Michael Sinatra wrote:
> On 3/13/19 1:43 PM, Stephen Farrell wrote:
>>
>> (dropping dprive list at WG chair request)
>>
>> Hiya,
>>
>> On 13/03/2019 20:29, Brian Dickson wrote:
>>> The starting place for the conversation needs to acknowledge this, and
>>> accommodate it.
On 3/13/19 1:43 PM, Stephen Farrell wrote:
>
> (dropping dprive list at WG chair request)
>
> Hiya,
>
> On 13/03/2019 20:29, Brian Dickson wrote:
>> The starting place for the conversation needs to acknowledge this, and
>> accommodate it. It is entirely possible that a DoH client that doesn't do
On Wed, Mar 13, 2019 at 1:43 PM Stephen Farrell
wrote:
>
> (dropping dprive list at WG chair request)
>
> Hiya,
>
> On 13/03/2019 20:29, Brian Dickson wrote:
> > The starting place for the conversation needs to acknowledge this, and
> > accommodate it. It is entirely possible that a DoH client th
(dropping dprive list at WG chair request)
Hiya,
On 13/03/2019 20:29, Brian Dickson wrote:
> The starting place for the conversation needs to acknowledge this, and
> accommodate it. It is entirely possible that a DoH client that doesn't do a
> minimum level of getting user acknowledgement before
All,
I am saying this with my dprive WG chair hat on...
As Eliot points out, this conversation has deteriorated beyond
repair. I will now politely ask that these non-technical discussions
cease on the dprive mailing list. I would recommend that everyone
document their concerns with DoH a
On Tuesday, 12 March 2019 23:12:37 UTC Brian Dickson wrote:
>...
> I think there is a way to use technical design(s) to split hairs, i.e. I
> think the side meeting
> has the possibility of bearing fruit which is palatable enough for all
> parties.
i hope so. i will only be in prague from saturday
On 3/12/2019 9:25 PM, Vittorio Bertola wrote:
>> Il 13 marzo 2019 alle 4.39 Christian Huitema ha
>> scritto:
>>
>> On 3/12/2019 7:56 PM, Vittorio Bertola wrote:
>>> The reaction I got from some policy people when I mentioned this kind of
>>> arguments going on here is "when did the IETF get the
On 3/12/2019 7:56 PM, Vittorio Bertola wrote:
> The reaction I got from some policy people when I mentioned this kind of
> arguments going on here is "when did the IETF get the mandate to decide for
> everyone that content filtering by intermediaries is always bad? This is
> matter for competi
> Il 13 marzo 2019 alle 3.20 Raymond Burkholder ha
> scritto:
>
> It appears to me that there is considerable support for DoH, meaning
> there is support for non-interference.
I think there is support within the IETF, but "non-interference" on DNS has
lots of implications at the legal, busine
Hiya,
On 13/03/2019 01:04, Paul Wouters wrote:
> RPZ allows filtering answers which would turn into BOGUS for
> DNSSEC validating clients.
Could well be my terminology was imprecise. What I recalled
from some discussion a year or more ago was that RPZ MUST NOT
change a DNSSEC-signed answer that
On Tue, 12 Mar 2019, Paul Vixie wrote:
i don't like the chinese government's rules for the great firewall. so, i keep
my visits to that otherwise-great country short. this hurts me, and maybe
hurts them also. but, it's their country, and i will obey their laws when i am
using their network. and
On Wed, 13 Mar 2019, Stephen Farrell wrote:
Hmm. Not sure what to make of that. DNSSEC presumably makes it
possible to detect interference, and yet RPZ (IIRC) calls for
not changing DNSSEC-signed answers. I don't get why an inability
to change is ok for the RPZ/DNSSEC context but not for DoH.
On Tue, Mar 12, 2019 at 3:51 PM Paul Vixie wrote:
> On Tuesday, 12 March 2019 21:38:44 UTC Stephen Farrell wrote:
> > On 12/03/2019 21:11, Paul Vixie wrote:
> > > ...
> >
> > There are reasons to want confidentiality for DNS queries
> > and answers, and access patterns, for which the IETF has
> >
18 matches
Mail list logo
