comments on dnssec-experiments

[Edward Lewis <[e-mail]>]

Pendantic comments left in just to show that I did review the doc. 
(Count me in, doc.)

Quoting from:
http://ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-experiments-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                                                [phone]
NeuStar

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

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>