Subject: Delegation Signer Document Done.

From: Olaf Kolkman <[email-masked]>
Date: Thu, 26 Jun 2003 15:35:19 +0200

Lectori Salutem,

With reference to draft-ietf-dnsext-delegation-signer-15.txt

After Olafurs message dd. May22, 2003 (see URL below) the draft has
been updated based on a number of comments directed to the author. 

Below is the summary of changes I identified (excluding minor style
and typo corrections) between the version that was in the repository the
22nd of May and the current version.

I am ready to inform the AD that the document is done and will do so
unless there are objections by Tuesday Jul 1 around noon CEST (Note
the timezone :-))

--Olaf

Changes 14->15 (Date: 2003-6-19)

 - Throughout the document a number of minor style and typo
   errors where corrected.

 - Included Table of content

 - In section 1: Added explicit reference to RFC3445 

 - In section 2.2.2.1 (Special processing for DS queries)

   "point and receives a query for the DS record at that name, it will
    return the DS from the parent zone.  This is true whether or not it
    is also authoritative for the child zone."
   
    was rewritten to:

   "point and receives a query for the DS record at that name, it MUST
    answer based on data in the parent zone, return DS or negative
    answer.  This is true whether or not it is also authoritative for
    the child zone."
   
   "MAY" was capitalized in the following sentence: 
   ".. DS record at the delegation point, or MAY return the DS record
   from its cache..."

  - In section 2.2.1.2 
    "When a server receives a query for (<QNAME>, DS, IN),"
    was replaced by:
    "When a server receives a query for (<QNAME>, DS, <QCLASS>),"

   -In section 2.2.1.3 

  "RFC2535 included rules to in add KEY records to additional section
   when SOA or NS records where included in an answer. The is was done
   to reduce round trips (in the case of SOA) and to force out NULL
   KEY's (in the NS case), as this document obsoletes NULL keys there
   is no need for the second case, the first case causes redundant
   transfers of KEY RRset as SOA is included in the authority section
   of negative answers.

   RFC2535 section 3.5 also included rule for adding KEY RRset to query
   for A and AAAA, as Restrict KEY[RFC3445] eliminated use of KEY RR by
   all applications therefore the rule is not needed anymore."

   was rewritten to: 
 
  "RFC2535 specified that KEY records be added to the additional
   section when SOA or NS records where included in an answer. This
   was done to reduce round trips (in the case of SOA) and to force
   out NULL KEYs (in the NS case).  As this document obsoletes NULL
   keys there is no need for the inclusion of KEYs with
   NSs. Furthermore as SOAs are included in the authority section of
   negative answers, including the KEYs each time will cause redundant
   transfers of KEYs.

   RFC2535 section 3.5 also included rule for adding the KEY RRset to
   the response for a query for A and AAAA types. As Restrict
   KEY[RFC3445] eliminated use of KEY RR by all applications this rule
   is no longer needed."

   - In section 2.2.2.
   "MAY" was capitalized in the following sentence:
   "for DNSSEC validation; local policy MAY override the standard policy."

   - In section 2.4:

   " For interoperability reasons, as few digest algorithms as possible
     should be reserved. The only reason to reserve additional digest
     types is to increase security."
 
    was reworded to:

    "For interoperability reasons, keeping number of digest algorithms
     low is strongly RECOMMENDED.  The only reason to reserve
     additional digest types is to increase security."

   - In section 2.6.2

     "enough change to cause a flag day."
     changed to:
     "enough change that a flag day is required."

Olafurs message can be found at:
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01130.html

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Jun 2003 09:45:00 +0200 (CEST)

Some quick review comments. If there are no comments requring changes from
the WG these comments can be addressed after the IETF last call is done.

Let me know when you want me to start the IETF last call.

      The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
 
There is no "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.

I'm concerned that implementors might not know how to format
such a response. (Is it a delegation up the tree? something else?)
I haven't seen a definition of a lame response in an RFC so
I think this needs to spell out more about the response to send.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Jun 2003 09:25:48 +0200 (CEST)

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

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

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