Subject: [dnsop] EPP-DNSSEC Document Updates

From: "Scott Hollenbeck" <[email-masked]>
Date: Wed, 19 Jan 2005 08:00:03 -0500

My document describing provisioning of DNSSEC data via EPP was updated
yesterday.  The new version is available here:

http://www.ietf.org/internet-drafts/draft-hollenbeck-epp-secdns-06.txt

I've made changes to the protocol based on review comments provided by this
working group (thanks!).  These include:

- DS provisioning is now a MUST implement feature, DNSKEY is OPTIONAL.
- I've added support for an OPTIONAL client-requested TTL.
- I've added response elements that allow the server to note how optional
elements provided by the client will be processed by the server.
- Changed some text to better explain (I hope) what the <secDNS:vInterval>
is all about.

Anything else?  If not, I think the document is ready to move ahead.

-Scott-

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 21 Jan 2005 12:02:30 +0100

Scott,

Since the <sDate> and <eDate> elements (start and end date for the use of 
provided data in the parent zone) are only hints - though mandatory, what 
about providing a way to let the client know whether the parent honored 
this information? (the same mechanism already introduced for vInterval, 
ttl and keyData).

Nitpicking:

Section 2.1: s/published by the server/published by a DNS server/ 
(otherwise misleading because the last paragraph was talking about an EPP 
server)
Section 2.1: s/KEY/key/
Section 2.5: What about typing TTL as a schema's positiveInteger for 
simplicity, instead of restricting int?
Section 7: s/DNSSIG/RRSIG/

Nothing else from my side, I think the document can move forward.

Best regards,
Marcos
.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 21 Jan 2005 09:45:49 -0500

>this information? (the same mechanism already introduced for vInterval,

Do you think that this could be worked into the <secDNS:statusData> element?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"A noble spirit embiggens the smallest man." - Jebediah Springfield
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 21 Jan 2005 17:05:39 +0100

> Do you think that this could be worked into the <secDNS:statusData> 
element?

Yes. But only the "accepted" and "ignored" conditions will apply as 
possible answers. "Missing" will never be possible, for the schema makes 
the sDate and eDate elements mandatory.

Best,
Marcos
.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 21 Jan 2005 11:09:10 -0500

>the sDate and eDate elements mandatory.

Is "ignored" sufficient for what you've described?  I mean, is that 
all that is necessary to return to the client?

Not being an XML expert, I'll leave it to Scott to address whether 
it's a problem that missing would be syntactically correct but not 
semantically correct for this.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Fri, 21 Jan 2005 17:13:29 +0100

> all that is necessary to return to the client?

Yes, "accepted" or "ignored" are IMHO enough.

Best,
Marcos
.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Fri, 21 Jan 2005 10:44:02 -0500

> simplicity, instead of restricting int?

positiveInteger doesn't allow zero [1].  It doesn't have an upper limit,
either.  I had to derive a type to match the upper and lower limits
described in Section 8 of RFC 2181.

-Scott-
[1]
http://www.w3.org/TR/xmlschema-2/#positiveInteger

.