On Wed, Oct 7, 2020 at 9:16 PM Barry Leiba via Datatracker
wrote:
>
> On Alissa’s first point — why publish this update now, rather than waiting
> until more things shake out and settle down — I basically agree, though I’m
> torn between thinking that waiting is better... and, on the other hand,
Barry Leiba has entered the following ballot position for
draft-ietf-dprive-rfc7626-bis-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
Alissa Cooper has entered the following ballot position for
draft-ietf-dprive-rfc7626-bis-06: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
On Wed, Oct 7, 2020 at 5:17 PM Warren Kumari wrote:
>
> The document is in IESG eval -- there is no more "eventually".
>
It can always be obsoleted. This one probably will be.
thanks,
Rob
___
dns-privacy mailing list
dns-privacy@ietf.org
On Wed, Oct 7, 2020 at 5:16 PM Peter Koch wrote:
>
> Hi Warren,
>
> On Wed, Oct 07, 2020 at 04:39:54PM -0400, Warren Kumari wrote:
>
> > 4.1. The Public Nature of DNS Data
> >
> >It is often stated that "the data in the DNS is public". This sentence
> >makes sense for an Internet-wide
Hi Warren,
On Wed, Oct 07, 2020 at 04:39:54PM -0400, Warren Kumari wrote:
> 4.1. The Public Nature of DNS Data
>
>It is often stated that "the data in the DNS is public". This sentence
>makes sense for an Internet-wide lookup system, and there
>are multiple facets to the data and
On Mon, Oct 5, 2020 at 2:42 PM Warren Kumari via Datatracker <
nore...@ietf.org> wrote:
>
> My DISCUS is specifically around the"The Alleged Public Nature of DNS
> Data" /
> "It has long been claimed that "the data in the DNS is public" section --
> it
> seems to be unnecessarily creating and
Warren
On Wed, Oct 7, 2020 at 4:40 PM Warren Kumari wrote:
> On Wed, Oct 7, 2020 at 3:29 PM Brian Haberman
> wrote:
> >
> > Hi Warren,
> > Thanks for the feedback. I have a couple of responses (as document
> > shepherd) inline...
> >
> > On 10/5/20 5:42 PM, Warren Kumari via Datatracker
On Wed, Oct 7, 2020 at 3:29 PM Brian Haberman wrote:
>
> Hi Warren,
> Thanks for the feedback. I have a couple of responses (as document
> shepherd) inline...
>
> On 10/5/20 5:42 PM, Warren Kumari via Datatracker wrote:
> > Warren Kumari has entered the following ballot position for
> >
Hi Warren,
Thanks for the feedback. I have a couple of responses (as document
shepherd) inline...
On 10/5/20 5:42 PM, Warren Kumari via Datatracker wrote:
> Warren Kumari has entered the following ballot position for
> draft-ietf-dprive-rfc7626-bis-06: Discuss
>
> When responding, please
Hi,
Some excellent and detailed responses to my questions from both you and
Christian. Thank you.
A CDN could aggregate both Content and DNS in a single channel as nothing in
the protocol(s) prevents this, correct?
While discovery might preclude this behavior from happening, ultimately
Vinny,
Christian makes a number of good points. I will just add that your original
question assumes that the client wishes to send most or all of its DNS
queries directly to the content provider it is talking to. The ADD working
group is founded on the concept of needing to discover recursive
There is indeed some extra per request overhead for Doh over HTTP3
versus Dns over QUIC, but I don't think that is the deciding factor. I
think that the two other decision factors are for the client the privacy
risks linked to cookies and other forms of HTTP tracking, and for the
server the
Hi Tommy,
Thanks for the response.
Would you envision the iOS / macOS implementation following the current model -
long term - of keeping DNS as an OS resolver function and hence independent?
I concur that applications like Browsers can multiplex this today with Content.
So the
DoH is designed to be multiplexed with other HTTP requests. This is already
possible with HTTP/2, and HTTP/3 carries on that ability. In order to take
advantage of multiplexing, even with QUIC, you need some application-layer
awareness of the content of the streams, which is why this is more
Tommy:
I suspect they are likely on list and can speak for themselves and do a
much better job of it, however aiui it was the absolute worst case where
QUIC connection setup was also included. This was a brief hallway
discussion back in Singapore so things may have progressed.
Vinny:
The
Hi,
What I am driving at in my original question is do we envision mixing Content
and DNS together in a multiplexed session or will DNS continue to be an
entirely independent channel (whether over HTTP/2 /3 Do53 DoQ DoH).
-Vinny
From: Tommy Pauly
Sent: Wednesday, October 7, 2020
Roman Danyliw has entered the following ballot position for
draft-ietf-dprive-rfc7626-bis-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
18 matches
Mail list logo
