I'd like to encourage some discussion of the relative merits of the UPDATE
approach
http://www.ietf.org/id/draft-mekking-dnsop-auto-cpsync-00.txt
compared to the publication approach outlined in the recent draft at
http://www.ietf.org/id/draft-barwood-dnsop-ds-publish-00.txt
I haven't yet
Hi Goerge,
What I like about your approach is the fact that is takes advantage of
DNSSEC. My opinion is that if DNSSEC is so great it would be cool if we
can define an update mechanism that utilizes it. This could be the first
real world application for DNSSEC.
I would encourage some type of
- Original Message -
From: Stephan Lagerholm stephan.lagerh...@secure64.com
To: George Barwood george.barw...@blueyonder.co.uk; dnsop@ietf.org
Sent: Wednesday, June 30, 2010 2:25 PM
Subject: RE: [DNSOP] Fwd: New Version
Notificationfordraft-mekking-dnsop-auto-cpsync-00
I would
On Wed, 30 Jun 2010, Stephan Lagerholm wrote:
What I like about your approach is the fact that is takes advantage of
DNSSEC. My opinion is that if DNSSEC is so great it would be cool if we
can define an update mechanism that utilizes it. This could be the first
real world application for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephan,
There were acknowledged some drawbacks of using DNSSEC as the security
channel in this specific case. One is that you still do not cover
unscheduled key rollovers, as that event may occur as a result of a
compromised key. It is possible to
My apologies for cross-posting,
but this is inherently a cross-wg and cross-area topic:
The revised draft contains clarifications for DNS service discovery
using SRV RRs and suggests methods to deal with the restrictions
imposed by draft-ietf-tsvwg-iana-ports. It is intended that both
drafts
