I support the WG adopting this draft, and will review it actively.
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I have some small concerns on 5.4. Consideration on TTL
I think the language needs to be clearer that if you are in the
position of reading the NSEC3 state and the TTL you receive is value
that the TTL you assert cannot be longer than and needs very
probably to be minus some period of time.
t
Hi,
I read the document and I believe that the document goes to far
to recommend the vendors how to implement the knobs in their
software here:
It is recommended that resolvers that implement Aggressive Negative
Caching provide a configuration switch to disable the feature.
Separate conf
Dear colleagues
This version addresses all the outstanding requests for changes.
The editors believe this version is ready for WGLC.
thanks
Olafur
On Wed, Nov 16, 2016 at 2:44 PM, wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a wo
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.
Title : Providing Minimal-Sized Responses to DNS Queries with
QTYPE=ANY
Authors : Joe Abley
Thanks, i did not saw it. This is explicitely mentioned.
Yours,
Daniel
On Nov 16, 2016 1:45 PM, "Ondřej Surý" wrote:
> draft-irft-cfrg-eddsa states in Section 5.2:
>
>Value of context is set by signer and verifier (maximum of 255
>octets, the default is empty string) and has to match oct
draft-irft-cfrg-eddsa states in Section 5.2:
Value of context is set by signer and verifier (maximum of 255
octets, the default is empty string) and has to match octet by octet
for verification to be successful.
So in fact, the default context for Ed448 is "empty string".
Cheers,
Ondrej
my understanding is that ed448 does not specify default values for the
context and i have not seen in the current draft a specification of the
context. Shouldn't we explicitly mention that the context is empty?
Yours,
daniel
On Nov 16, 2016 2:44 AM, "Dick Franks" wrote:
> My mistake. Apologies.
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.
Title : Aggressive use of NSEC/NSEC3
Authors : Kazunori Fujiwara
Akira Kato
On 15 November 2016 at 17:09, tjw ietf wrote:
> All
>
> The response from the room today was pretty positive this draft was worth
> adopting and pursuing. We felt their was little benefit in waiting to
> begin this Call for Adoption.
>
> This starts a Call for Adoption for draft-dickinson-dnsop
> On Nov 15, 2016, at 3:09 AM, tjw ietf wrote:
>
> All
>
> The response from the room today was pretty positive this draft was worth
> adopting and pursuing. We felt their was little benefit in waiting to begin
> this Call for Adoption.
>
> This starts a Call for Adoption for draft-dicki
I support adoption of this draft.
-G
On Tue, Nov 15, 2016 at 7:16 PM, Maarten Wullink
wrote:
> +1 for adoption.
>
> A format like this will help with retrieving data from (anycast) locations
> with limited resources.
>
> I’m willing to contribute/review.
>
>
>> Op 15 nov. 2016, om 09:09 heeft t
In message <20161116000530.19ed4...@pallas.home.time-travellers.org>, Shane
Kerr writes:
> Dan,
>
> At 2016-11-15 12:41:01 +
> Dan York wrote:
> > The draft is at either of:
> >
> > https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-cryptoalgs/
> > https://tools.ietf.org/html
At Tue, 15 Nov 2016 04:21:05 +0100 (CET),
Ondřej Surý wrote:
> > I'm not sure how you can be so sure about the author's assumption when
> > the draft itself doesn't explicitly clarify the assumption (maybe
> > based on an off-list conversation with Fujiwara-san?), but if that's
> > actually the a
My mistake. Apologies.
I also had draft-wouters-sury-dnsop-algorithm-update-02
on screen. That has the registry table with same TBDs.
Starting at 04:30 dulls the brain.
Dick Franks
On 15 November 2016 at 17:05, Ondřej Surý wrote:
> The IANA Considerations Sections sa
The IANA Considerations Sections says:
This document updates the IANA registry "Domain Name System Security (DNSSEC)
Algorithm Numbers".
And I believe that's the correct language according to
https://tools.ietf.org/html/rfc5226#section-5.1
Cheers,
Ondrej
--
Ondřej Surý -- Technical Fellow
-
Ondrej
The document calls up two TBD code points for the EDDSA algorithms, but the
IANA Considerations section places no action on IANA to assign these and
add them to the registry.
Other than that, seems ok.
Dick Franks
On 14 November 2016 at 23:22, Ondřej Surý wrot
Hi Jerry,
On Tuesday, 15 November 2016 15:50:31 GMT Jerry Lundström wrote:
> On 11/15/16 15:09, Jim Hague wrote:
> > $ /usr/bin/time xz -9
>
> Was -9 also used when comparing compression?
For the numbers I posted in the table in response to your message, yes.
Generally when comparing compressi
Hi Jim,
On 11/15/16 15:09, Jim Hague wrote:
> $ /usr/bin/time xz -9
Was -9 also used when comparing compression?
Cheers,
Jerry
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Tuesday, 15 November 2016 07:51:21 GMT Maarten Wullink wrote:
> 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
I did look briefly a
On Tuesday, 15 November 2016 07:09:13 GMT Jerry Lundström wrote:
> On 11/15/16 06:18, Sara Dickinson wrote:
> > - It requires around an order of magnitude less CPU to compress the C-DNS
> > file.
> Can you clarify this, do you mean that it takes longer to compress PCAP
> then C-DNS? If so, do you
Dan,
At 2016-11-15 12:41:01 +
Dan York wrote:
> The draft is at either of:
>
> https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/
> https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04
>
> Please send any comments to the list or to us as
As mentioned at the very end of DNSOP, Olafur Gudmundsson, Ondrej Sury, Paul
Wouters and I have a draft published that aims to document the steps involved
with deploying a new cryptographic algorithm for DNSSEC. The overall goal is to
make it easier to get new DNSSEC crypto algorithms deployed,
+1 for adoption.
A format like this will help with retrieving data from (anycast) locations with
limited resources.
I’m willing to contribute/review.
> Op 15 nov. 2016, om 09:09 heeft tjw ietf het volgende
> geschreven:
>
> All
>
> The response from the room today was pretty positive this
> On 15 Nov 2016, at 08:09, tjw ietf wrote:
>
> The response from the room today was pretty positive this draft was worth
> adopting and pursuing. We felt their was little benefit in waiting to begin
> this Call for Adoption.
>
> Please review this draft to see if you think it is suitable f
All
The response from the room today was pretty positive this draft was worth
adopting and pursuing. We felt their was little benefit in waiting to
begin this Call for Adoption.
This starts a Call for Adoption for
draft-dickinson-dnsop-dns-capture-format
The draft is available here:
https://d
https://tools.ietf.org/html/draft-wouters-sury-dnsop-algorithm-update-02
Paul
Sent from my iPhone
> On Nov 15, 2016, at 16:53, Viktor Dukhovni wrote:
>
>> 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 mos
27 matches
Mail list logo
