Subject: Delegation signer-12

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 18 Dec 2002 13:42:05 -0500

Version 12 addresses the ancestor problem,  by requiring the resolver to
detect this situation and recover by discovering the NS records for
the parent.
Versions 10 and 11 addressed the issue of return codes from child servers
when asked about the DS record.

This completes all outstanding issues that have been raised in the working
group, I hope the IESG will now process the document.

	Olafur (DS editor)

--
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: Edward Lewis <[email-masked]>
Date: Fri, 20 Dec 2002 21:07:56 -0500

I was staring at the new words on the handling of the DS RR in 
section 2.2.1.2 when I noticed this problem with the text:

# 2.2.2 Signer's Name (replaces RFC3008 section 2.7)
#
#   The signer's name field of a SIG RR MUST contain the name of the zone
#   to which the data and signature belong.  The combination of signer's

This is a very bad idea.

The signer's name had better remain as it is defined.  So much for my 
rule of thumb reaction.  Here are a laundry list of reasons why I 
have a problem with this section and idea:

1) The section has nothing to do with the DS RR definition.

2) There is no rationale presented for changing the syntactic 
definition of the SIG RR.

3) Reading between the lines, the author of the document seems to be either:

3a) trying to clean up something in 3008
or
3b) is trying to usurp the signer name to mean the authority name

If it is 3a - this is the wrong document.
If it is 3b - why do folks try to usurp fields for new purposes 
needlessly.  It's easy enough to discover the authority via SOA 
records in responses.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer