To:
James Gould <jgould@verisign.com>
Cc:
"Hollenbeck, Scott" <shollenbeck@verisign.com>, <Chris.Newman@Sun.COM>, EPP Provreg <ietf-provreg@cafax.se>
From:
Patrik Fältström <paf@cisco.com>
Date:
Sat, 4 Apr 2009 09:34:46 +0200
Authentication-Results:
ams-dkim-2; header.From=paf@cisco.com; dkim=pass (sig from cisco.com/amsdkim2001 verified; );
DKIM-Signature:
v=1; a=rsa-sha256; q=dns/txt; l=3821; t=1238830488; x=1239694488;c=relaxed/simple; s=amsdkim2001;h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;d=cisco.com; i=paf@cisco.com;z=From:=20=3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D=20<paf@cisco.com>|Subject:=20Re=3A=20[ietf-provreg]=20RE=3A=20Standards=20Track=20Advancement=20Request=20for=20EPP=20RFCs|Sender:=20;bh=PM4XSg9SyTJG0C8w0gnhzzxSVnWmKtr14WX/V5j6sCc=;b=mALOpLofXXZYgxGekle97dp+nAO8LpXnq6x0MZBG8gIuczg3kmW8aXZ8hje6qy3wzaf0zLSZ0K293Sp30wbOFmAfxD4xdEfMrRcrNhh90TUqsWo9M0r+kHk8dJ1B6Elp;
In-Reply-To:
<C5FB87BA.31BCB%jgould@verisign.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
On 3 apr 2009, at 15.30, James Gould wrote:
> 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.
We should at the same time remember that they do not have to be
modified.
> 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.
Ok
> 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?
I can also envision you do not need host objects for external hosts.
> 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.
>
>> changing an external host object that has associations with objects
>> that are
>> sponsored by a different client. Attempts to update such hosts
>> directly SHOULD
>> 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.
Patrik
This is a digitally signed message part