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

[James Gould <[e-mail]>]

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
[e-mail]
Direct: 703.948.3271
Mobile: [phone]

 
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 <[e-mail]>
> Date: Thu, 2 Apr 2009 08:49:06 -0400
> To: "Hollenbeck, Scott" <[e-mail]>
> Cc: <[e-mail]>, EPP Provreg <[e-mail]>
> 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.

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.

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

> 
> 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
> 
> On 2 apr 2009, at 13.18, Hollenbeck, Scott wrote:
> 
>> (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: [e-mail] [mailto:[e-mail]]
>>> Sent: Tuesday, December 16, 2008 12:08 AM
>>> To: Hollenbeck, Scott; [e-mail]
>>> Cc: [e-mail]; [e-mail]
>>> Subject: RE: Standards Track Advancement Request for EPP RFCs
>>> 
>>> Two questions I missed:
>>> 
>>> --On October 17, 2008 8:28:31 -0400 "Hollenbeck, Scott"
>>> <[e-mail]> 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
>>> 
>>> 
>> 
>