> On 15 Nov 2016, at 07:53, Viktor Dukhovni wrote:
>
> If, while adding two new algorithms, we in parallel deprecate four
> old ones, then we're making progress.
Maybe we should have a one-in, one-out rule for DNSSEC algorithms? :-)
___
DNSOP mailin
On Tue, Nov 15, 2016 at 12:22:18AM +0100, Ondřej Surý wrote:
> a new version of EDDSA for DNSSEC has been posted
> that resolves most if not all comments received
> during WGLC in curdle. This is one last chance
> to review the document, so don't miss it! :)
My only comment is that I very much h
Did you consider columnar storage formats like Apache Parquet + Snappy
compression?
It would be an interesting to compare this to cbor-dns.
https://parquet.apache.org/
https://github.com/google/snappy
> Op 15 nov. 2016, om 07:18 heeft Sara Dickinson het
> volgende geschreven:
>
>
>> On 15 No
On Mon, Nov 14, 2016 at 7:52 AM, Patrick McManus
wrote:
> Our Bar BOF will be Tuesday evening at 6:45 in Studio 7 on the 6th Floor
> of the Conrad. See you there!
I should have mentioned - plan on a duration of 1 hour.
___
DNSOP mailing list
DNSOP@ie
Hi,
On 11/15/16 06:18, Sara Dickinson wrote:
>
>> On 15 Nov 2016, at 14:59, George Michaelson wrote:
>>
>> Terry clarified, the 30% size compression is not from uncompressed,
>> but is the comparision with compressed gzip pcap.
>>
>> So, compressed DNS-CBOR is *significantly* smaller than pcap.g
> On 15 Nov 2016, at 14:59, George Michaelson wrote:
>
> Terry clarified, the 30% size compression is not from uncompressed,
> but is the comparision with compressed gzip pcap.
>
> So, compressed DNS-CBOR is *significantly* smaller than pcap.gz
Yup - sorry if I wasn’t clear in the presentation
Hi Colleagues,
I would like to take some time slot to introduce the DNS wireformat draft.
https://tools.ietf.org/html/draft-song-dns-wireformat-http-04
And I also would like to ask the impact of cache impact of the DNS over HTTP
path. I mean the cache in the middle may mis-interpret and block
Terry clarified, the 30% size compression is not from uncompressed,
but is the comparision with compressed gzip pcap.
So, compressed DNS-CBOR is *significantly* smaller than pcap.gz
-G
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/
- Original Message -
> From: "神明達哉"
> To: "Ondřej Surý"
> Cc: "Stephane Bortzmeyer" , "Bob Harold"
> , "dnsop"
> Sent: Tuesday, 15 November, 2016 03:40:56
> Subject: Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
> At Tue, 15 Nov 2016 03:12:43 +0100 (CET),
> Ondřej Surý wrote:
>
At Tue, 15 Nov 2016 03:12:43 +0100 (CET),
Ondřej Surý wrote:
> > Yes, it is. Otherwise, what would be the point of using the NS in the
> > parent instead of the authoritative one?
>
> Let me rephrase it, the assumption here is that parent NS are:
> "as good as they get to resolve the names undern
- Original Message -
> From: "Stephane Bortzmeyer"
> To: "Ondřej Surý"
> Cc: "Bob Harold" , "dnsop"
> Sent: Tuesday, 15 November, 2016 01:55:50
> Subject: Re: draft-fujiwara-dnsop-resolver-update-00
> On Thu, Nov 10, 2016 at 08:46:55PM +0100,
> Ondřej Surý wrote
> a message of 32 line
Dear Jim Hague, John Dickinson, Sara Dickinson, Terry Manderson, John Bond:
An IPR disclosure that pertains to your Internet-Draft entitled "C-DNS: A
DNS Packet Capture Format" (draft-dickinson-dnsop-dns-capture-format) was
submitted to the IETF Secretariat on and has been posted on the "IETF Pa
On Thu, Nov 10, 2016 at 08:46:55PM +0100,
Ondřej Surý wrote
a message of 32 lines which said:
> > There seems to be an assumption in this draft that the parent NS
> > records are always correct, but I would argue that this is not the
> > case.
>
> Nope, I don't think this is an assumption of
On Fri, Nov 11, 2016 at 02:08:54AM +0900,
fujiw...@jprs.co.jp wrote
a message of 41 lines which said:
> > 2) It will make debugging more difficult. With your two-caches
> > system, "dig @myresolver NS foobar.example" will retrieve the data
> > in foobar.example, while the resolver will use, wh
On Fri, Nov 11, 2016 at 04:33:54PM +0200,
Andreas Gustafsson wrote
a message of 22 lines which said:
> A resolver that receives an RD=0 query for a name that is not
> present in the cache should respond with a referral. In a two-cache
> resolver, the natural place to look for the data to incl
Hello Dear Jerry;
I'm starting to test to code and I think the following package is required for
Debian :)
# sudo apt-get install dh-autoreconf
I added notes to the README.md file but I couldn't push it, I don't have access.
Line (to README.md)
# Debian Notes
for install Debian, please insta
Dear all,
a new version of EDDSA for DNSSEC has been posted
that resolves most if not all comments received
during WGLC in curdle. This is one last chance
to review the document, so don't miss it! :)
Cheers,
--
Ondřej Surý -- Technical Fellow
CZ.NI
Hi Ozgur,
On 11/14/16 21:21, Ozgur Karatas wrote:
> I'm starting to test to code and I think the following package is required
> for Debian :)
>
> # sudo apt-get install dh-autoreconf
Thanks for testing, have you tried `sh autogen.sh` before `configure`
and `make` ?
I believe this won't requir
On 11/14/16, 20:10, "Olafur Gudmundsson" wrote:
>On Nov 14, 2016, at 5:01 PM, Ondřej Surý wrote:
>
>>Are they? What is child-NS needed for?
>
>That is what the NS set that the resolver should
>use, the one in parent is just a hint.
>
>All good resolvers should use the Parent as hint
>as to find
The DNSOP WG has placed draft-muks-dnsop-dns-catalog-zones in state
Candidate for WG Adoption (entered by Tim Wicinski)
The document is available at
https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-catalog-zones/
___
DNSOP mailing list
DNSOP@ietf
The DNSOP WG has placed draft-wallstrom-dnsop-dns-delegation-requirements
in state
Candidate for WG Adoption (entered by Tim Wicinski)
The document is available at
https://datatracker.ietf.org/doc/draft-wallstrom-dnsop-dns-delegation-requirements/
___
Hi all,
I have been fiddling around with CBOR while reading the C-DNS draft and
there have been a couple of concerns that I wanted to solve such as:
- representing broken DNS
- being able to stream the format
- data degradation/quality
- support non-DNS information
And what better way to do it th
On Fri, Nov 11, 2016 at 10:13 PM, bert hubert wrote:
Bert Huber wrote:
> Also, should we work with companies attempting to hinder progress by
> clinging to patents which are no longer enforceable?
Hm. First, I tend to agree with you that the IETF should not work
with companies that attempt to h
On Tue, Nov 15, 2016 at 04:58:43AM +0900, Ted Lemon wrote:
> On Fri, Nov 11, 2016 at 10:13 PM, bert hubert
> wrote:
> Bert Huber wrote:
> > Also, should we work with companies attempting to hinder progress by
> > clinging to patents which are no longer enforceable?
>
> Hm. First, I tend to agr
On Mon, Nov 14, 2016 at 12:05 AM, Warren Kumari wrote:
> Hi all,
>
> I have just submitted "Stretching DNS TTLs"
> (draft-wkumari-dnsop-ttl-stretching-00).
>
> The very high level overview is:
> If you are doing something like HAMMER / pre-fetch, and cannot reach
> the authoritative server when t
> On Nov 14, 2016, at 5:01 PM, Ondřej Surý wrote:
>
>
> - Original Message -
>> From: "Edward Lewis"
>> To: "Ondřej Surý"
>> Cc: "dnsop"
>> Sent: Monday, 14 November, 2016 08:31:51
>> Subject: Re: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00
>
>> I'm a little confus
- Original Message -
> From: "Edward Lewis"
> To: "Ondřej Surý"
> Cc: "dnsop"
> Sent: Monday, 14 November, 2016 08:31:51
> Subject: Re: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00
> I'm a little confused to the feedback, so I'm asking for some clarification.
>
> On 1
27 matches
Mail list logo
