To:
Patrik Fältström <patrik@frobbit.se>
CC:
EPP Provreg <ietf-provreg@cafax.se>
From:
James Gould <jgould@verisign.com>
Date:
Fri, 11 Dec 2009 15:51:42 -0500
In-Reply-To:
<2B445758-604F-48DE-9FAD-8B7ECD0E2059@frobbit.se>
Sender:
owner-ietf-provreg@cafax.se
Thread-Index:
Acp6SjbgqUW4q0dXRlmP49eU9SEMogAWYcr3
Thread-Topic:
[ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted forReview
User-Agent:
Microsoft-Entourage/12.20.0.090605
Subject:
Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for Review
Patrik, Thanks for the feedback. The secDNS:chg should be able to handle the use case that you describe, since secDNS:chg is a full replace. Removing all existing and setting the new DS or Key Data is handled by secDNS:chg. The corner case that is not covered in the current schema is replacing all DS or Key Data with nothing, meaning remove all. I prefer that the client explicitly specify what should be added or removed via the secDNS:add and secDNS:rem, but the secDNS:chg could be updated to allow an empty secDNS:chg. Below is the schema update needed to allow secDNS:chg to be empty. This change is also backward compatible, so the question is whether it meets the need and whether it is a good practice to include in the draft? Any thoughts to this? <complexType name="chgType"> <choice minOccurs="0"> <element name="dsData" type="secDNS:dsDataType" maxOccurs="unbounded"/> <element name="keyData" type="secDNS:keyDataType" maxOccurs="unbounded"/> </choice> </complexType> <complexType name="updateType"> <choice> <element name="chg" type="secDNS:chgType"/> <sequence> <element name="add" type="secDNS:dsOrKeyType" minOccurs="0"/> <element name="rem" type="secDNS:remType" minOccurs="0"/> </sequence> </choice> <attribute name="urgent" type="boolean" default="false"/> </complexType> The sample command looks like: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd"> <command> <update> <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd"> <domain:name>example.com</domain:name> </domain:update> </update> <extension> <secDNS:update urgent="1" xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.0.xsd"> <secDNS:chg/> </secDNS:update> </extension> <clTRID>ABC-12345</clTRID> </command> </epp> -- JG ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior written consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Patrik Fältström <patrik@frobbit.se> Date: Fri, 11 Dec 2009 05:10:46 -0500 To: James Gould <jgould@verisign.com> Cc: EPP Provreg <ietf-provreg@cafax.se> Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-00.txt Submitted for Review On 8 dec 2009, at 16.01, James Gould wrote: > The draft meets the following goals that were previously sent to the list: > > 1. XML schema is backward compatible > 2. Support for add and rem in the same command > 3. Support for passing all four dsData attributes on a rem > 4. Support for a dsData and keyData primary interface. Only one primary > interface should be supported by the server. > 5. Remove support for the wildcard delete of dsData in the rem by just using > the keyTag with a clear statement (i.e. Server must return error if the > keyTag matches multiple DS records) in the specification. From my > perspective and I believe a couple others this is a key issue that must be > addressed. > 6. Clarity in the specification on the use of the chg as a replace or a > ³change all². > 7. Clarity around the corner case of a client attempting to add and remove > the same dsData or keyData in a single command. This must result in an > error from the server. Additionally an error must be returned if the client > tries to remove dsData or keyData that does not exist or tries to add dsData > or keyData that already exists. I think the draft is good, and clarifies a number of things. But, when adding things (as we are), I ask whether we can not add a feature to the protocol that we use in .SE that actually make things a bit easier: If a "rem" has a keytag of zero, then all keytags are removed. That eliminates some situations (specifically after a transfer to a gaining registrar) a number of info + multiple rem commands. One can "just" do "rem keytag=0" followed by the add of the new keys. And, it also makes life easier when doing a transfer to a registrar that do not support DNSSEC. They "only" have to be able to do rem, keytag=9 on the domains they gain. Patrik -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se