Thanks for the comments, Sam. More below. -Scott-
> -----Original Message----- > From: Samuel Weiler [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 26, 2004 11:34 AM > To: [EMAIL PROTECTED] > Cc: Scott Hollenbeck > Subject: Re: [dnsop] DNSSEC and EPP Review Request > > > Comments on draft-hollenbeck-epp-secdns-03.txt: > > Perhaps I'm missing something, but Section 2.2 and Section 7 (security > considerations) both refer to sending signatures, presumably over EPP, > yet I see no mention of those data elements in the schema. Which is > correct? I suspect it's sufficient to say "you need to authenticate > this somehow", which section 7 does. Section 4, this element: <element name="sigVal" type="secDNS:keySigType"/> > In section 3.1.2, the nxt attribute implies the use of opt-in. This > should probably be removed or discussed only as a "future extension" > bit. Also s/NXT/NSEC/. Thanks for catching this. It's an artifact of older thinking. > There are elements for start/end dates on publication, but nothing for > sig lifetime. It may be useful for a client to be able to request a > sig lifetime much shorter than the EXPECTED key publication interval. > If the start/end dates are meant to be that, this needs to be > clarified. OK, what's really useful from a deployment perspective? Are the start-end dates good enough, or is something else needed? What are the implications of the sig lifetime and start-end dates being different? I'm open to ideas. > The startDate/endDate elements appear to be part of dsData but not key > (they're in keyData, but not key). The rem element requires either a > key or dsData. Hence, rem'ing a dsData appears to require sending > those dates. It may not be wise to require the registrar to remember > what start/end dates it (or another registrar) originally requested in > order to remove a DS record. Clients don't have to remember the dates. They can be retrieved via an <info> query. The text makes that clear, but I suppose the example could be better. > Also: can you remove something created > as keyData by removing dsData? Or the other way around? I'm surprised > that rem requires recitation of the entire old dsData when chg does > not. Nope, there's a one-for-one relationship. > Formats of data: the date field formats aren't specified. For other > fields, refer specificallly to the "presentation formats" in 2535 (and > successor docs). Consider whether you need any further escaping or > other encoding for each field. Date field formats are specified in the schema using the XML Schema "dateTime" data type. Other field formats *are* referenced to draft-ietf-dnsext-dnssec-records. Did I miss something somewhere? > Update the doc to reference DNSSECbis. Where (section 1 maybe?) and in what context? There is no outdated reference to replace. -Scott- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
