Re: [ietf-provreg] RE: Standards Track Advancement Request for EPPRFCs

[James Gould <jgould@verisign.com>]

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

Patrik,

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

-- 


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 <paf@cisco.com>
> Date: Thu, 2 Apr 2009 12:55:08 -0400
> To: James Gould <jgould@verisign.com>
> Cc: "Hollenbeck, Scott" <shollenbeck@verisign.com>, <Chris.Newman@Sun.COM>, 
> EPP Provreg <ietf-provreg@cafax.se>
> Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP 
> RFCs
> 
> On 2 apr 2009, at 15.44, James Gould wrote:
> 
>>> 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.
> 
> 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 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.  


>>> 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.
>> 
>> 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.
> 
> 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.
> 

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.   

>>> 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?
>> 
>> 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.
> 
> 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
>