DNSSEC EPP Extension (RFC 4310) Usability Question

RE: DNSSEC EPP Extension (RFC 4310) Usability Question

Re: DNSSEC EPP Extension (RFC 4310) Usability Question

Draft about client side implementation experiences

(Sorry if you get multiple versions of this announcement, I seem to
trigger some mailing-list server rules working against me)

Hello,

I hope the time for this is right.

I would like to give you notice of a draft I've written with my
experiences as implementor of EPP client side, and specifically on
many extensions done by registries now switching over to EPP.

The document is available here for now:
http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt

If anyone thinks this work is useful and should be pursued, I will
work more on it to polish it, add all references and so on at which
time all suggestions would be welcome, including on structure since
that would be my first I-D.

For now, I'm more expecting general comments, here or in private,
if the timeframe as well as the structure and objectives 
of this document are right or not.

Thanks in avance for your possible review and feedback.

--

-- 
Patrick Mevzek

RE: DNSSEC EPP Extension (RFC 4310) Usability Question

Re: DNSSEC EPP Extension (RFC 4310) Usability Question

On 2008-12-09 20:07, Hollenbeck, Scott wrote:
> Ah, but there's a significant difference: adding and removing the same
> status or name server produces no change in end state. The order in
> which a keyTag is changed and removed in one command significant. It can
> either produce an error (remove followed by change) or a state change
> (change followed by remove). That seems like a bad situation that the
> protocol should prevent.
>
> -Scott-
>

Hi Scott,

being nitpicky, adding and removing the same status value in one request is 
actually undefined, since the status value not only consists of its name, but of 
a human readable text also. So if there is a status

   <status s="serverHold">put on hold because of name infringement</status>

and I submit an update request containing

   <add>
     <status s="serverHold">put on hold because of excessive spamming</status>
   <add>
   <rem>
     <status s="serverHold"/>
   </rem>

what shall the result be? It is undefined to which of the two (the existing or 
added status value) the removal applies to and which shall survive.

For that reason, our EPP implementation generally disallows the addition and 
deletion of the very same name server/status/IP address or whatever in one 
request. The respective DNSSEC EPP Extension could handle this in the same way, 
i.e. a certain key tag may appear only in one of the three sections within one 
request, otherwise the request would fail. Although I don't think there is a 
need to update RFC 4310, I think such kind of constraints in the EPP specs 
should be a little bit more relaxed to make it more flexible. I just want to 
remind of the issue in RFC 3731, where the requirement of the domain:update 
request to have at least one <add>, <rem> or <chg> element caused either 
headaches or protocol bending in the context of EPP extensions (fortunately, 
this was later fixed in RFC 4931).

Regards,

Klaus

Re: DNSSEC EPP Extension (RFC 4310) Usability Question

On 9 dec 2008, at 18.56, Gould, James wrote:
> Scott,
>
> I believe that would be up to the server policy to define the mix of  
> updates that are valid. The protocol could support a mix unless  
> there is some specific reason why it shouldn't. A similar use case  
> could apply to the domain mapping where an update includes an add  
> and remove of the same status or name server.
>
In Sweden I have either done just add and remove. Never mixed. That  
seems to me be a possible source for confusion.

    Patrik
>
>
> Jim
> James F. Gould
>
> Pricipal Software Engineer
> VeriSign Inc.
>
>
> From: Hollenbeck, Scott
> To: Gould, James; ietf-provreg <at> cafax.se
> Sent: Tue Dec 09 12:49:04 2008
> Subject: RE: [ietf-provreg] DNSSEC EPP Extension (RFC 4310)  
> Usability Question
>
> Jim, I think I might have just remembered a use case that makes the  
> <sequence> a problem.  Imagine if it were possible to create a  
> command that looks like this:
>
> <secDNS:update
>    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:rem>
>      <secDNS:keyTag>12345</secDNS:keyTag>
>    </secDNS:rem>
>    <secDNS:chg>
>      <secDNS:dsData>
>        <secDNS:keyTag>12345</secDNS:keyTag>
>        <secDNS:alg>3</secDNS:alg>
>        <secDNS:digestType>1</secDNS:digestType>
>        <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
>      </secDNS:dsData>
>    </secDNS:chg>
> </secDNS:update>
>
> Is the server supposed to remove or change the data associated with  
> keyTag 12345?  With the existing schema there's no ambiguity.
> -Scott-
>
>
>
> From: owner-ietf-provreg <at> cafax.se [mailto:owner-ietf- 
> provreg <at> cafax.se] On Behalf Of James Gould
> Sent: Tuesday, December 09, 2008 12:04 PM
> To: ietf-provreg <at> cafax.se
> Subject: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability  
> Question
>
> In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one  
> usability issue that I would like to get feedback from the existing  
> implementations of the extension.
>
> The specification allows adding (<secDNS:add>), removing  
> (<secDNS:rem>), and changing (<secDNS:chg>) DS data, but according  
> to the XML schema they can’t be done at the same time.  Below is  
> from the RFC 4210 XML schema for the <secDNS:update>:
>
>     <complexType name="updateType">
>       <choice>
>         <element name="add" type="secDNS:dsType"/>
>          <element name="chg" type="secDNS:dsType"/>
>          <element name="rem" type="secDNS:remType"/>
>       </choice>
>       <attribute name="urgent" type="boolean" default="false"/>
>      </complexType>
>
> To allow for a mix of add, chg, and rem, should the XML schema model  
> in the Domain Mapping (RFC 4931) updateType XML schema definition be  
> used?  I updated the DNSSEC XML schema below to match the definition  
> of the Domain Mapping, to support the mix of add, chg, and rem:
>
>       <complexType name="updateType">
>       <sequence>
>         <element name="add" type="secDNS:dsType" minOccurs=”0” />
>          <element name="chg" type="secDNS:dsType" minOccurs=”0” />
>          <element name="rem" type="secDNS:remType" minOccurs=”0” />
>       </sequence>
>       <attribute name="urgent" type="boolean" default="false"/>
>      </complexType>
>
> Has any of the current implementations come across this issue?
>
> -- 
>
>
> JG
>
> -------------------------------------------------------
> James F. Gould
> Principal Software Engineer
> VeriSign Naming Services
> jgould <at> 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.

Re: Draft about client side implementation experiences

Patrick Mevzek <provreg <at> contact.dotandco.com> 2008-12-09 19:46
> I would like to give you notice of a draft I've written with my
> experiences as implementor of EPP client side, and specifically on
> many extensions done by registries now switching over to EPP.
> 
> The document is available here for now:
> http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt

I forgot to mention that the presentation I've done in ICANN Caïro
ccNSO technical day meeting may be useful, at least the first part
dealing with EPP, its deployment, and various local registry
extensions.

You can see an outline of it at
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-icann-cairo-ccnso-techday-200811.pdf
Presentation itself at
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-icann-cairo-ccnso-techday-200811.html
(needs Javascript, as it is done with S5)

--

-- 
Patrick Mevzek

Re: DNSSEC EPP Extension (RFC 4310) Usability Question

James Gould <jgould <at> verisign.com> 2008-12-09 18:29
> In reviewing the DNSSEC EPP Extension (RFC 4310) I noticed one usability
> issue that I would like to get feedback from the existing implementations of
> the extension.  
> 
> The specification allows adding (<secDNS:add>), removing (<secDNS:rem>), and
> changing (<secDNS:chg>) DS data, but according to the XML schema they can¹t
> be done at the same time.  Below is from the RFC 4210 XML schema for the
> <secDNS:update>:

As others have said I think the whole "issue" is the same for all
update operations on various objects, not only DNSkey materials.

I think that by allowing more flexibility with all operations
possible at the same time, it only create confusion with no big
benefit at the end.

Specifically, I think the most frequent use case for DNS material
would be to add *OR* remove a key, and not at the same time if we are
after smooth transitions.
Change of a key detail may be useful but should not happen too often
in practice.

So having only either one add or one chg or one rem block in a
domain:update for DNSkey material seem fine to me, and I would not be
in favor of mixing.

I also observe (without hard numbers) that use cases depend on object
types.
I would say that for status values it seems more logical to have
mainly add and rem operations (and again probably very few with add
and rem together in a single call), where for nameservers the chg
operation may be more frequent (even if not possible by core EPP
RFCs, it is done by some registries).
As for contact, I would say that it derives a lot from the fact that
very few registries seem to allow really multiple contacts of the
same type, and if they do I think very few registrars use that
feature. Hence in that case add or rem operations are probably the
more logical one for contacts during domain update.

For me, no mix at all would be the simpler case, both on registry
side and registrar side: that way there is nothing to think about
what will happen if we do add+rem at the same type for the same info
(otherwise it depends on registry policies and in some case it will
be a noop as add+rem will be seen as opposite, where sometimes in
other registries or other cases it will be a removal since it comes
last), and registrars still have all power to do what they want, they
just, if really needed, do multiple domain:update calls one after the
following and each one with either an add, a rem or a chg. And this
can be encapsulated on their side as a global operation in an higher
API.

I also observe that, for the same object types, some registries allow
*only* chg, others allow *only* add and/or rem and some allow all
3 ... which create even more confusion.

--

-- 
Patrick Mevzek

Re: DNSSEC EPP Extension (RFC 4310) Usability Question

On 12/10/2008 02:16 AM, Patrick Mevzek wrote:

> For me, no mix at all would be the simpler case, both on registry
> side and registrar side: that way there is nothing to think about
> what will happen if we do add+rem at the same type for the same info
> (otherwise it depends on registry policies and in some case it will
> be a noop as add+rem will be seen as opposite, where sometimes in
> other registries or other cases it will be a removal since it comes
> last), and registrars still have all power to do what they want, they
> just, if really needed, do multiple domain:update calls one after the
> following and each one with either an add, a rem or a chg. And this
> can be encapsulated on their side as a global operation in an higher
> API.
>
> I also observe that, for the same object types, some registries allow
> *only* chg, others allow *only* add and/or rem and some allow all
> 3 ... which create even more confusion.
>

Just my two cents: I personally want to have as few calls as possible, so I like 
being able to do additions and removals at the same time. Generally speaking, 
the design question is whether the "add/remove" approach is the preferable 
solution, or whether it is better to choose a "replace all" approach, 
especially, as the number of items (status values, contact reference, IP 
addresses etc.) are rather small. So a client side application would either 
determine the desired state from its own storage and submit it to the registry 
or would query the current state from the registry, alter the state at its own 
discretion and submit it as a whole to the registry. Our experience with such an 
approach in other protocols is rather good, although we discovered the need to 
select which part of the data shall be updated. If one only wants to change the 
name servers of a domain but not the contacts, it could be regarded as a burden 
if the submission of the contact data would be also required.

Regards,

Klaus