Just quickly go through the draft.
One question: Is it worthwhile to let sub-resolver to know that the answer is
stale. It is true that “stale bread is better than no bread” on the recursive
server’s point of view. But it may be not true for sub-resolver or measurement
probes .
The user
I just notice it asks for "Standards Track" document. If it aims to
introduce a special use of resolver to achieve some features for their
users' benefit, I think informational document may be more appropriate ? I
guess, like what RFC7706 does.
Davey
> -邮件原件-
> 发件人: DNSOP [mailto:dnsop-b
> ATR make Authoritative Servers send normal big response packet before they
> try to send TC response for large RRsets ?
No. big response packet first, then TC response.
Davey
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listi
Sorry, You are right.
> -邮件原件-
> 发件人: Davey Song(宋林健) [mailto:ljs...@biigroup.cn]
> 发送时间: 2017年9月13日 17:56
> 收件人: 'Lanlan Pan'; 'Davey Song'
> 抄送: 'dnsop'
> 主题: 答复: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt
>
>
>
Thank you.
The large DNS response in IPv6 is a real problem. ATR is one option to adopted
in authoritative server alone. If someone or party have more influence on both
resolver and authoritative side (cloud and app provider who can choose their
own DNS resolution path), Mukund’s proposal
月21日 12:50
> 收件人: "Davey Song(宋林健)"
> 抄送: 'Davey Song'; 'dnsop'; 'william manning'
> 主题: Re: [DNSOP] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt
>
>
>
> Davey Song(宋林健) wrote:
> > Thank you.
> >
> > The
OK. I finally understand the context of the word " Darwinism " in many IETF
discussion and slides. Haha~
Davey
> -邮件原件-
> 发件人: Jim Reid [mailto:j...@rfc1035.com]
> 发送时间: 2017年9月21日 15:22
> 收件人: "Davey Song(宋林健)"
> 抄送: Paul Vixie; dnsop WG
> 主题: a
+1
DNS privacy is an important issue. I support this adoption. And I’m willing to
review it.
Davey
发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Tim Wicinski
发送时间: 2018年7月25日 0:33
收件人: dnsop
主题: [DNSOP] Call for Adoption: draft-bortzmeyer-rfc7816bis
We discussed this and there app
Hi Mukund，
Thank you for proposing here for comments and discussion. I would like to
share more background on this if people are interested.
Actually I was inspired by several sources. One is the Multisignature
(https://en.bitcoin.it/wiki/Multisignature ) concept from Bitcoin which help
to reduc
I also ask the same question and look for solutions. I do find a statement from
a paper (The Honey Badger of BFT Protocols@ CCS 2016) that " if an trusted
party is unavailable, then a distributed key generation protocol could be used
instead (c.f., Boldyreva [11])."
[11] A. Boldyreva. Threshold
Thanks for all commenter's, I appreciate your frankness and vote based on your
technical sense. I understand your push back especially considering the DNS
camel stuff. I try to reply some of comments here.
Some people argues on the problem statement of this draft.
> Peter: Meanwhile, we have no
Hi Brian,
Thanks for your questions. Reply inline
>(1) Has your testing revealed *where* the IPv6 fragmentation is occurring?
>IIRC, IPv6 requires the originating host to do so. And originating UDP packet
>size will be the smaller of the authority servers' configs and the EDNS
>bufsize on the
Thanks Benno. Thanks all reviewers for your time reviewing ATR draft. I'm
sorry it is not adopted in WG but I still think the draft and the peer
reviews help us to understand the problems better.
Davey
> -邮件原件-
> 发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Benno Overeinder
> 发送时间: 2019年2
Note that the **Session 2** is in Friday (10:00-12:00) not
Wednesday(10:00-12:00). It is wrong in the attached file
dnsop-ietf95-agenda.txt.
-邮件原件-
发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Tim Wicinski
发送时间: 2016年4月3日 5:28
收件人: dnsop
主题: [DNSOP] New Agenda Uploaded
All,
After som
It’s interesting idea. We have not discuss that before. I’m not sure the impact
of bad HTTP proxies to this protocol. Anyway it is not free to register a new
head filed. I will discuss with co-author about delivering the TCP/UDP massage
via other meta format. Thanks for your interest and commen
I think the major benefit from this proposal is to make the upper layer(http
layer) unaware the DNS data inside. So we do not need to consider the
checksum-like mechanism , special authentication for DNS stub, and do keep
truncation logic. I accept your idea that a new head filed Proxy-DNS-Tran
When I first looked into DNS, I was recommended with a complex figure of DNS
protocol family describing the dependency and activeness of many RFC
documents. I'm wondering if it is possible to attach versions to DNS
protocol similar like IPv4 and IPv6, http/1.1 and HTTP/2 which can give
clear path o
+1, there is enough room for us to improve.
When I first drafted some idea, I was told that the IETF work is driven by
the community. It's good. As one of the co-authors, I'm fairly open for
suggestions. But for experimental draft, I'm not sure whether we should
stick to the scope of original exp
Hi Tim,
Thanks for the chair's work. If there is any editing suggestion from HTTPbis
WG, please let the us know.
Davey
-邮件原件-
发件人: DNSOP [mailto:dnsop-boun...@ietf.org] 代表 Tim Wicinski
发送时间: 2016年8月3日 16:39
收件人: dnsop
主题: Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
Hi
Hi Warren
It's good idea that the authority DNS be smart enough to predict or
configured to package all the information for a URL as a whole object (like
a webpage). It will reduce the latency for user.
As to the draft itself, there are two questions:
First, for a same transaction, the cost fro
the network successfully.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
---
Davey Song(宋林健)
BII Lab
ljs...@biigroup.cn
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ub.com/shane-kerr/DNSoverHTTPinGO/tree/ietf96hackathon.
>
> It will be merged into the main DNS over HTTP in Go repository soon.
>
> See you at the dnsop session soon! :)
>
> --
> Shane
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf
22 matches
Mail list logo
