On Tue, Jun 15, 2010 at 02:32:54PM +1000, Mark Andrews wrote:
Probably true, but not relevant to the discussion. The idea is to force
imple
menters to look at the registry so that they see *future* additions to it,
ev
en if they get there from reading this RFC-to-be.
You can't
Dear WG,
DNSSEC Key Timing Considerations, draft-morris-dnsop-dnssec-key-timing-02.txt,
and its predecessors were presented to the working group in Anaheim the
last time. There was discussion on the document itself as well as its
relation to draft-ietf-dnsop-rfc4641bis. The authors asked for
Edward,
Not necessarily. What I mean is that it is up to the multi-homed
device to decide what interfaces are candidates (for the pending data
transmission) and consult the DNS on each interface. However, what
Yes, but how to decide that? Some information is required, and this draft
Hi,
Obviously I'm interested in this work as well.
If chairs approve, I would like to present the
draft-savolainen-mif-dns-server-selection at dnsop's IETF#78 meeting. As a
starting point for this discussion, or separately.
Teemu
-Original Message-
From: dnsop-boun...@ietf.org
On Thu, Jun 17, 2010 at 01:15:06PM +0200, Peter Koch wrote:
(2) is covered in the IANA considerations section but while that section
refers to a formal policy it does not offer guidance for review.
We should capture the considerations from the most recent as well as
previous
On Thu, Jun 17, 2010 at 02:19:57PM +, bmann...@vacation.karoshi.com wrote:
ANY TIME?? ever?
how about ... deletions from the registry will allow the domain
names to be resolved on the public Internet at some reasonable
time after removal from the registry.
Currently section 3 of the document mandates that all zones be signed
using the KSK+ZSK model, I content this is outdated advice.
Background #1: Why bring this up now
While reviewing draft-ietf-dnsop-dnssec-dps-framework I found myself
loving certain sections of the document and hating other
On Thu, Jun 17, 2010 at 2:15 PM, Olafur Gudmundsson o...@ogud.com wrote:
Background #3: Key strengths and life time
RSA and DSA algorithms have the interesting property that the number of bits
in the key can be selected, by adding bits to the key the key gets stronger.
Stronger keys can be
On 17/06/2010 5:34 PM, Eric Rescorla wrote:
On Thu, Jun 17, 2010 at 2:15 PM, Olafur Gudmundssono...@ogud.com wrote:
Background #3: Key strengths and life time
RSA and DSA algorithms have the interesting property that the number of bits
in the key can be selected, by adding bits to the key the
