This is a discussion on comments on dnssec-experiments - DNS ; Pendantic comments left in just to show that I did review the doc. (Count me in, doc.) Quoting from: http://ietf.org/internet-drafts/draf...riments-02.txt # DNSEXT D. Blacka # Internet-Draft Verisign, Inc. # Expires: August 27, 2006 February 23, 2006 # # DNSSEC Experiments ...
Pendantic comments left in just to show that I did review the doc.
(Count me in, doc.)
# DNSEXT D. Blacka
# Internet-Draft Verisign, Inc.
# Expires: August 27, 2006 February 23, 2006
# DNSSEC Experiments
# In the long history of the development of the DNS security extensions
#  (DNSSEC), a number of alternate methodologies and modifications
# have been proposed and rejected for practical, rather than strictly
# technical, reasons. There is a desire to be able to experiment with
# these alternate methods in the public DNS. This document describes a
# methodology for deploying alternate, non-backwards-compatible, DNSSEC
# methodologies in an experimental fashion without disrupting the
# deployment of standard DNSSEC.
I think abstracts can be free of references (the "" thing).
# 1. Definitions and Terminology
# The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
# "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
# document are to be interpreted as described in RFC 2119 .
Reference 5 ought to be normative then, right?
# 4. Method
# While this behavior isn't strictly mandatory (as marked by MUST), it
# is unlikely that a validator would not implement the behavior, or,
# more to the point, it will not violate this behavior in an unsafe way
# (see below (Section 6).)
Please restate this with fewer negatives. "It is likely that a validator
would implement" for example. Makes reasoning easier.
(Yes - an extremely pedantic comment...)
# 5. Defining an Experiment
# In general, however, resolvers involved in the experiment are
# expected to understand both standard DNSSEC and the defined
# experimental DNSSEC protocol, although this isn't required.
A resolver can also understand *multiple* experiments as well as stock DNSSEC.
# 6. Considerations
# 2. It will not be possible for DNSSEC-aware resolvers not aware of
# the experiment to build a chain of trust through an experimental
"not be possible" & "not aware."
# 8. Security Considerations
# Zones using this methodology will be considered insecure by all
# resolvers except those aware of the experiment. It is not generally
# possible to create a secure delegation from an experimental zone that
# will be followed by resolvers unaware of the experiment.
Hmmm. While I think that establishing an experiment in this way looks
promising, the teardown might be problematic. (Maybe we need an exit
(Section 7, elided, is on transitions. Haven't thought what to say
Edward Lewis +1-571-434-5468
Nothin' more exciting than going to the printer to watch the toner drain...
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.