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
# draft-ietf-dnsext-dnssec-experiments-02
# Abstract
# In the long history of the development of the DNS security extensions
# [1] (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 "[1]" 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 [5].

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.

(Right?)

# 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
# zone.

"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
strategy. )

(Section 7, elided, is on transitions. Haven't thought what to say
about that.)

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: