At 22:30 29/04/2009, Paul Hoffman wrote:
At 8:13 PM +0200 4/22/09, Peter Koch wrote:
Please review the draft and send comments and/or statements of support or
non-support to the WG mailing list.
There will be a five reviewer threshold.
I support the publication of this document. Some comments:
At 1:48 PM -0400 5/12/09, Olafur Gudmundsson wrote:
At 22:30 29/04/2009, Paul Hoffman wrote:
At 8:13 PM +0200 4/22/09, Peter Koch wrote:
Please review the draft and send comments and/or statements of support or
non-support to the WG mailing list.
There will be a five reviewer threshold.
I support
At 14:45 22/04/2009, Edward Lewis wrote:
At 20:13 +0200 4/22/09, Peter Koch wrote:
this is to initiate a working group last call on
DNSSEC Trust Anchor Configuration and Maintenance
draft-ietf-dnsop-dnssec-trust-anchor-03.txt
ending Friday, 2009-05-08, 23:59 UTC. The tools site
On Tue, 12 May 2009, Olafur Gudmundsson wrote:
Section 3: Priming can occur when the validating resolver starts, but a
validating resolver SHOULD defer priming of individual trust anchors until
each is first needed for verification. I disagree with this as a SHOULD;
may want to is much more
On Tue, May 12, 2009 at 04:28:01PM -0400, Paul Wouters wrote:
On Tue, 12 May 2009, Olafur Gudmundsson wrote:
Section 3: Priming can occur when the validating resolver starts, but a
validating resolver SHOULD defer priming of individual trust anchors
until each is first needed for
At 14:08 -0400 5/12/09, Olafur Gudmundsson wrote:
We are trying to say that the key can be both KSK and ZSK but does not
have to be.
Oh...
How about: this DNSKEY might also be a zone signing key?
Yeah.
Well RFC5011 requires you scan at least once a month, and recommends higher
frequency,
I'll pass on my comments on the draft. I've removed my comments that
were duplicates of those submitted by Ed and Paul W.
I'm not an English language expert (even though it is my first and
primary language; I just defer to those with better knowledge than I),
but I did find the draft well
On Thu, 23 Apr 2009, Joe Abley wrote:
[ enabling DNSSEC from stale install media that has an old trust anchor ]
I don't like the idea of incorporating magic numbers (e.g. nine months)
algorithmically when trying to determine suitability of an old trust anchor.
I don't like it either, but
At 8:13 PM +0200 4/22/09, Peter Koch wrote:
Please review the draft and send comments and/or statements of support or
non-support to the WG mailing list.
There will be a five reviewer threshold.
I support the publication of this document. Some comments:
Section 2: Using a DS format is also
I have read the doc and support it. Some minor comments/suggestions
based on Ed's message:
Edward Lewis wrote:
At 20:13 +0200 4/22/09, Peter Koch wrote:
this is to initiate a working group last call on
DNSSEC Trust Anchor Configuration and Maintenance
On 22-Apr-2009, at 15:17, Paul Hoffman wrote:
Yes. For example, Ubuntu server long term stable releases are only
put out every few years. If you pick one of them, you start off with
an old image, then *hopefully* update as soon as you install. But,
if you just turn on some services, this
On 22-Apr-2009, at 14:13, Peter Koch wrote:
this is to initiate a working group last call on
DNSSEC Trust Anchor Configuration and Maintenance
draft-ietf-dnsop-dnssec-trust-anchor-03.txt
ending Friday, 2009-05-08, 23:59 UTC. The tools site gives easy
access to
diffs and
At 2:45 PM -0400 4/22/09, Edward Lewis wrote:
I keep forgetting this bit of document jockeying - can an Informational use
RFC 2119 terms in a normative way?
Unfortunately, yes. When I have pointed out that it a semantic layer violation,
the response is usually along the lines of oh, you
On Wed, 22 Apr 2009, Peter Koch wrote:
Please review the draft and send comments and/or statements of support or
non-support to the WG mailing list.
It seems a comma is missing between Scott's name and mine.
One issue came up recently with the dnssec-conf package related
to Section 4,
At 3:05 PM -0400 4/22/09, Paul Wouters wrote:
If an OS ships with preloaded trust anchors, and the medium is
used over a year after it was created, eg an old CD/DVD copy, it
might cause DNS to complete fail due to loading rolled over
trust anchors. This DNS failure will prevent it from obtaining
15 matches
Mail list logo
