Subject: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 2 Apr 2009 07:18:56 -0400

(trimming the recipients a bit)

It's been 3 months since I last heard from anyone who had any concerns
with moving forward, so I'm going to get moving.  I have copies of the
XML source files for the current RFCs to use as a basis for new I-Ds.  I
intend to update references in RFCs 4930-4934 as needed.  I will add
text to 4934 to better describe the TLS usage profile as noted by Chris.

-Scott-

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, December 16, 2008 12:08 AM
> To: Hollenbeck, Scott; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: Standards Track Advancement Request for EPP RFCs
> 
> Two questions I missed:
> 
> --On October 17, 2008 8:28:31 -0400 "Hollenbeck, Scott" 
> <[email-masked]> wrote:
> > 4291: is its status a show-stopper for advancement?  I'd 
> like to have 
> > that question answered before I invest a lot of time in making any 
> > document updates to address the TLS topics you noted.
> 
> This is a case for RFC 3967, IMHO.  While I can't predict how 
> the rest of the IETF will behave on this point, the only 
> alternative would be to rip
> IPv6 support out of the base spec into a separate extension 
> that doesn't advance on the standards track.  I would find it 
> quite surprising if the IETF/IESG choose that alternative to RFC 3967.
> 
> > Can you point me to another specification that includes a TLS usage 
> > profile that addresses the features you described?  I'd 
> like to see an 
> > example that has recently passed muster with the IESG.
> 
> The most recent is:
>   <http://tools.ietf.org/html/draft-ietf-syslog-transport-tls>
> 
> 		- Chris
> 
>

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 2 Apr 2009 14:49:06 +0200

Hmm....in this time period you talk about, I have implemented epp from  
the beginning -- twice -- and got quite some experience. There are a  
few things that would be good to clarify, although they to some degree  
have to do with the database management and structure and not so much  
the actual protocol.

Then small things that could have been better I think, but I guess  
everyone have implemented this already, so to make the changes might  
be wrong at this point (and not necessary).

On the first, I see differences on how transfers of domains and  
"attached objects" work. Some registries require explicit transfer of  
contacts, which imply one (as I think) might as registrar have access  
to the domain object, but not contact. Other registries do clone the  
contact object when a domain is transferred, and the clone get a new  
contact-id (which imply the number of contact objects in the database  
increase, and the contact-id of holder change in the domain when the  
transfer happens.

Maybe some clarification about "contact id" is needed?

On the second, I look specifically at the DNSSEC extension, RFC4310,  
where the update command is inconsistent. This is something that  
programmers more than myself has missed, and that required some extra  
hours of debugging.

a)

> The <secDNS:add> element is used to add DS information to an  
> existing set. The <secDNS:add> element MUST contain one or more  
> <secDNS: dsData> elements as described in Section 3.1.2.

b)

> The <secDNS:rem> element contains one or more <secDNS:keyTag>  
> elements that are used to remove DS data from a delegation. The  
> <secDNS:keyTag> element MUST contain a key tag value as described in  
> section 5.1.1 of RFC 4034 [6]. Removing all DS information can  
> remove the ability of the parent to secure the delegation to the  
> child zone.

Note that the format inside the <secDNS:add> and <secDNS:rem> is  
different. The rem element "directly" include the keytag element while  
the add element include dsData (that in turn include the keytag).

Why is there not a dsData wrapper around the keytag element for the  
rem command?

c)

.SE have added a feature in the update command, and that is that the  
keyID in a rem update can use the specific key tag "0" that imply all  
keys are to be removed.

Are these things that could be interesting to discuss, and if so,  
should I send text somewhere?

    Patrik

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 02 Apr 2009 09:33:16 -0400

Patrik,

Where ever you do send it, please copy me.

Eric

Patrik Fältström wrote:
>> The <secDNS:add> element is used to add DS information to an existing 
>> set. The <secDNS:add> element MUST contain one or more <secDNS: 
>> dsData> elements as described in Section 3.1.2.
>
> b)
>
>> section 5.1.1 of RFC 4034 [6]. Removing all DS information can remove 
>> the ability of the parent to secure the delegation to the child zone.
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 2 Apr 2009 09:36:39 -0400

Patrik,

I'm open to clarifying protocol text and I'll work with Chris to make sure that any proposed changes stay in scope.  Sending specific text changes/additions would be appreciated.

I'm not planning to touch 4310.  I've heard enough about that spec from different people with operational experience to make me think that it needs a respin at Proposed with either protocol updates or a complete re-write.  I don't have time to take on that work, so I've offered to give up the editing pen to others that have asked about it privately.  Consider this a public offer.

-Scott-

> From: Patrik Fältström [mailto:[email-masked]] 
> Sent: Thursday, April 02, 2009 8:49 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]; [email-masked]
> Subject: Re: [ietf-provreg] RE: Standards Track Advancement 
> Request for EPP RFCs
> 
> Hmm....in this time period you talk about, I have implemented 
> epp from the beginning -- twice -- and got quite some 
> experience. There are a few things that would be good to 
> clarify, although they to some degree have to do with the 
> database management and structure and not so much the actual protocol.
> 
> Then small things that could have been better I think, but I 
> guess everyone have implemented this already, so to make the 
> changes might be wrong at this point (and not necessary).
> 
> On the first, I see differences on how transfers of domains 
> and "attached objects" work. Some registries require explicit 
> transfer of contacts, which imply one (as I think) might as 
> registrar have access to the domain object, but not contact. 
> Other registries do clone the contact object when a domain is 
> transferred, and the clone get a new contact-id (which imply 
> the number of contact objects in the database increase, and 
> the contact-id of holder change in the domain when the 
> transfer happens.
> 
> On the second, I look specifically at the DNSSEC extension, 
> RFC4310, where the update command is inconsistent. This is 
> something that programmers more than myself has missed, and 
> that required some extra hours of debugging.
> 
> a)
> 
> > set. The <secDNS:add> element MUST contain one or more

---

From: James Gould <[email-masked]>
Date: Thu, 02 Apr 2009 09:44:12 -0400

Patrik,

I provide feedback to the items that you bring up based on my experience of
building Registries below.

One additional item that I noticed with a recent re-review of RFC 4932 (EPP
Host Mapping) is the following verbiage:
 
> Host name changes can have an impact on associated objects that refer to the
> host object. A host name change SHOULD NOT require additional updates of
> associated objects to preserve existing associations, with one exception:
> changing an external host object that has associations with objects that are
> sponsored by a different client. Attempts to update such hosts directly MUST
> fail with EPP error code 2305. The change can be provisioned by creating a new
> external host with a new name and needed new attributes and subsequently
> updating the other objects sponsored by the client.

Have any Registries implemented to this?  We¹ve implemented external hosts
in two different ways:

1. External hosts per Registrar, where an association from domains to
external hosts of another client (Registrar) is not allowed.
2. External hosts per Registry, where updates are allowed to be made by the
sponsoring Registrar independent of the associations to the domains.

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
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 <[email-masked]>
> Date: Thu, 2 Apr 2009 08:49:06 -0400
> To: "Hollenbeck, Scott" <[email-masked]>
> Cc: <[email-masked]>, EPP Provreg <[email-masked]>
> Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP
> RFCs
> 

JG - We've treated contacts as first class objects, where a domain transfer
doesn't do anything with the contacts.  If the gaining Registrar needs to
make updates to the contact records, new contacts can be assigned after the
transfer or the Registrar can request the transfer of the contacts.

> Why is there not a dsData wrapper around the keytag element for the

JG - Since we're discussing RFC 4310, I have to bring up the past thread on
the inability to use a combination of <secDNS:add>, <secDNS:rem>, and
<secDNS:chg> in a single domain update since updateType is defined as a
choice instead of a sequence with minOccurs="0" for each element.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Apr 2009 10:27:17 -0400

FWIW, we found that RFC 4310 in it's current state to be quirky but workable.

I would prefer that we not redefine what's in 
4310, although if we want to improve on it we 
create a new extension (which has less quirks).

At 9:36 -0400 4/2/09, Hollenbeck, Scott wrote:
>Patrik,
>
>I'm open to clarifying protocol text and I'll 
>work with Chris to make sure that any proposed 
>changes stay in scope.  Sending specific text 
>changes/additions would be appreciated.
>
>I'm not planning to touch 4310.  I've heard 
>enough about that spec from different people 
>with operational experience to make me think 
>that it needs a respin at Proposed with either 
>protocol updates or a complete re-write.  I 
>don't have time to take on that work, so I've 
>offered to give up the editing pen to others 
>that have asked about it privately.  Consider 
>this a public offer.
>
>-Scott-
>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Getting everything you want is easy if you don't want much.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 2 Apr 2009 18:56:19 +0200

On 2 apr 2009, at 16.27, Edward Lewis wrote:

> I would prefer that we not redefine what's in 4310, although if we  
> want to improve on it we create a new extension (which has less  
> quirks).

I agree with this.

The only thing I ask for is maybe some more words so that the reader  
catches the quirks.

    Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 2 Apr 2009 18:55:08 +0200

On 2 apr 2009, at 15.44, James Gould wrote:

> Have any Registries implemented to this?  We’ve implemented external  
> hosts
> in two different ways:
>

In .SE the host object is subordinate the domain object, and therefore  
MUST have the same sponsoring client as the domain object. A host  
object is transferred with the domain object, and is because of that  
not transferrable.

> transfer or the Registrar can request the transfer of the contacts.

So what I call "cloning" is then something the gaining registrar have  
to do manually? Do you separate those changes of holder from a  
"normal" change of holder, i.e. restart the payment cycle etc? Do you  
keep track of the now two contact records be the "same" contact be  
represented by two records? You as registry that is.

> choice instead of a sequence with minOccurs="0" for each element.

True, that should be clarified as well. .SE changed and do the rem  
first, and then the add. That should be the explicit order to do the  
updates in epp I think.

    Patrik

---

From: James Gould <[email-masked]>
Date: Thu, 02 Apr 2009 13:30:13 -0400

Patrik,

My responses are below, prefixed with "JG - ".

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

> Date: Thu, 2 Apr 2009 12:55:08 -0400
> To: James Gould <[email-masked]>
> Cc: "Hollenbeck, Scott" <[email-masked]>, <[email-masked]>,
> EPP Provreg <[email-masked]>
> not transferMy resprable.
> 

JG  You are referring to internal hosts that are subordinate to a domain in
the case of the host ns.foo.se and domain foo.se, but how do you handle
external hosts like ns.bar.net that is not subordinate to any domain in .se?
In our Registries, child hosts of a domain (ns.foo.se for foo.se) are also
transferred along with the domain and the sponsoring client must be the
same.  Since there is no parent domain for an external host (ns.bar.net in
.se) you can¹t include the same type of validation.  The specification says
that ³changing an external host object that has associations with objects
that are sponsored by a different client should result in a EPP error code
2305², which means that if one client references an external host sponsored
by a different client, that the host can not be changed.  Does this apply to
any change or just a change like changing the host name?  This statement
means for a Registry with many domains and external hosts, that there is
much more work required by the sponsoring client to create a new host and
update all of their domains that link to the host to reference the new host.
Implementing this represents a substantial change to the way that Registrars
manage external hosts, at least in our Registries, unless the first approach
is implemented where each client has it¹s own list of external hosts.  The
.name Registry implements the first option.

> represented by two records? You as registry that is.

JG -  Yes, if the Registrar wants to update the contact information linked
by the domain than they have to either request a transfer of the contacts or
manually create or reuse an existing contact record to link to the domain.
Updating the transferred domain to reference new contact data is handled in
the same way as any domain update.  There is no side effects associated with
billing, since the billable action was transferring the domain and the
contact information can be changed at any time.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 2 Apr 2009 20:31:52 +0200

On 2 apr 2009, at 19.30, James Gould wrote:

> JG – You are referring to internal hosts that are subordinate to a  
> domain in
> .se) you can’t include the same type of validation.  The  
> specification says
> that “changing an external host object that has associations with  
> objects
> 2305”, which means that if one client references an external host  
> sponsored
> is implemented where each client has it’s own list of external  
> hosts.  The

.SE transfer the host object together with the domain it belongs to.  
host objects outside of .se have no sponsoring clients.

That is the explanation (and there are no more words), and when  
reverse engineering what has actually been implemented, I found that  
the best I can do is to always try to create the host object when I  
have some operation to do on a domain object, and more or less ignore  
the error code...

Not fun, but there are tons of similar situations (regarding  
validation of attribute values) that also lack documentation (and lack  
of specification in the epp spec), so "to make things work", there is  
a lot of "trial and error" in the actual algorithm implemented on top  
of the epp protocol.

> contact information can be changed at any time.

In .SE there is a difference. Changing the holder do have legal  
impact, and the registry require paperwork etc. So changing that  
attribute value is a "special" operation. What is interesting though  
is that .SE is themselves as registry cloning the holder and updates  
the holderid when a transfer happens. That implies that if you track  
domains in .SE, you will see a change of holder(-id) when a transfer  
happens even though there was no change in holder. Yes, that implies  
creation of many many many contact objects over time. Contacts have to  
be deleted manually by the registrar.

I do not like it, but that is how they have implemented contacts.

    Patrik

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 02 Apr 2009 18:40:02 -0400

> a lot of "trial and error" in the actual algorithm implemented on top 

Yup. So the baggage that (modernly) goes with "standards track" and the 
specification experience, and the contractual regime which existed when 
we started are at odds, and the awkwardness isn't diminished, in my 
opinion, by the present changes to the contractual regime.

If we were specifying something as generic as a provisioning protocol 
for arbitrary registries, rather than the past, or currently 
contemplated ICANN contracting gTLDs, augmented by some ccTLDs, to which 
those special cases would tastefully decorate with their special 
extensions, then the (modern) standards track requirements wouldn't seem 
so otherworldly.

I'll send implementation comments separately, eventually. Remind me if I 
haven't by Stockholm.
 
Eric

---

From: James Gould <[email-masked]>
Date: Fri, 03 Apr 2009 09:30:34 -0400

Patrik,

Interesting that there is another model that you're taking for external
hosts.  So to summarize, the following models exist for the management of
external hosts:

1. External hosts don¹t have a sponsoring client, meaning once they are
created they can¹t be modified.  This sounds like the model taken by .se.
2. Each Registrar has its own set of external hosts that can be
independently managed by the Registrar.  This is what was defined in an
earlier version of the EPP, which was implemented by .name.
3. There is one set of external hosts for the Registry with the client that
created them as the sponsoring client.   The sponsoring client can update
the external host independent references to the host by domains.  The
external host can not be deleted if it¹s being used as a delegating name
server of a domain.  This is what is implemented in .com  and .net.

Are there any other models implemented by Registries?

RFC 4932 sort of indicates that external hosts do have a sponsoring client,
so that could be a conflict with model #1.  RFC 4932 does not prohibit model
#2, but model #2 does not seem to be very popular with the Registrars.  RFC
4932 has the verbiage ³changing an external host object that has
associations with objects that are sponsored by a different client. changing
an external host object that has associations with objects that are
sponsored by a different client. Attempts to update such hosts directly MUST
fail with EPP error code 2305. The change can be provisioned by creating a
new external host with a new name and needed new attributes and subsequently
updating the other objects sponsored by the client.  This verbiage really
applies to model #3, but it doesn¹t sound like any Registries implementing
model #3 have implemented to this verbiage.  Changing to this model for .com
and .net would have major issues with Registrars, since they don¹t seem to
be a big fan of model #2 and a modified model #3 according to RFC 4932
represents a huge management burden for changing external hosts.

If there is an opportunity to change the wording, I would prefer to change
the MUST to a SHOULD in the RFC 4932 paragraph as shown below to support
existing implementations and to not require this behavior.

> sponsored by a different client. Attempts to update such hosts directly SHOULD

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

> Date: Thu, 2 Apr 2009 14:31:52 -0400

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 4 Apr 2009 09:34:46 +0200

On 3 apr 2009, at 15.30, James Gould wrote:

> 1. External hosts don’t have a sponsoring client, meaning once they  
> are
> created they can’t be modified.  This sounds like the model taken  
> by .se.

We should at the same time remember that they do not have to be  
modified.

> earlier version of the EPP, which was implemented by .name.

Ok

> external host can not be deleted if it’s being used as a delegating  
> name

I can also envision you do not need host objects for external hosts.

> 4932 has the verbiage “changing an external host object that has
> applies to model #3, but it doesn’t sound like any Registries  
> implementing
> and .net would have major issues with Registrars, since they don’t  
> seem to

    Patrik