Delegation Signer (DS) Resource Record (RR)
draft-ietf-dnsext-delegation-signer-15

I'm a YES on this one.
Still - nits, section 2.2.1.

      Each DS RRset stored in the parent zone MUST be signed by at least
      one of the parent zone's private keys. The parent zone MUST NOT
      contain a KEY RRset at any delegation point. Delegations in the
      parent MAY contain only the following RR types: NS, DS, NXT and SIG.

I think this was intended to say "MAY contain NS, DS, NXT and SIG, and MUST NOT contain other types". With 2119 meaning of MAY (can choose to do so or can choose not to do so), this is unclear.

.....
      A secure zone MUST contain a self-signed KEY RRset at its apex.  Upon
      verifying the DS RRset from the parent, a resolver MAY trust any KEY
      identified in the DS RRset as a valid signer of the child's apex KEY
      RRset. Resolvers configured to trust one of the keys signing the KEY
      RRset MAY now treat any data signed by the zone keys in the KEY RRset
      as secure.

Query: Is it intentional that this allows resolvers to consider the data insecure, even when it's signed?
I think that's reasonable (the resolver may know of a key compromise), but want to make sure that's what the WG intended.

Date: Fri, 27 Jun 2003 09:25:48 +0200 (CEST)
From: "Erik Nordmark"
Subject: Re: Delegation Signer Document Done.
To: "Olaf Kolkman"
Cc: namedroppers@ops.ietf.org


Some quick comments. If there aren't more substantial comments from the WG
these can be fixed after the IETF last call.

  1.2 Reserved Words

      The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",

There is no such thing as "MAY NOT" in RFC 2119.

      5) If the server is not authoritative for any part of the QNAME, a
      response indicating a lame server for QNAME is given.

Is the format of a response indicating a lame server well defined?
Well known? I haven't seen an actual definition in a RFC.
Or does it make sense to spell out what the response will contain?

  Erik


--
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:

State Changes to Wait for Writeup                                  from Last Call Issued                                  by scoya

State Changes to Last Call Issued                                  from Last Call Requested                              by jhargest

State Changes to Last Call Requested                              from AD Evaluation                                    by nordmark