Re: [ietf-provreg] EPP Operations

[Jens-Uwe Gaspar <jug@schlund.de>]

Dear Eugenio Pinto,

your understanding of host-attributes / host-objects is not accurate.

Let's assume the .pt-registry is using EPP1.0.

A registry decides which "host-concept" they want to use:

   a) host-objects, or else
   b) host-attributes

Let's consider this with an example: we want to create a domain with some
nameservers:

   create domain 'foo.pt' with:
     nameserver #1: 'ns.foo.pt'
     nameserver #2: 'ns.bar.pt'
     nameserver #3: 'ns.baz.com'

for (a):
   all nameservers must be created with an EPP create:host-command,
   nameserver #1 and #2 also need an IP because they are within the
   .pt-ZONE. After that you can create the domain using the created
   host-objects using <domain:ns>.

for (b):
   the nameservers are implicitly created given as parameter
   (attributes) to a create:domain-command using <domain:hostAttr>.
   Here only nameserver #1 needs an IP, because 'ns.foo.pt' is a
   subordinate or glue-nameserver for the domain 'foo.pt'.

That's only a short usage. There are other implications of using
host-objects or host-attributes. Read about them in the mail-archive
of the provreg-list as Scott already mentioned.

Hope this helps a bit.

PS: BTW, also DNSBE (registry for .be) are using host-attributes with EPP.

Kind regards,

Jens-Uwe Gaspar

Eugenio Pinto wrote:
> In Portugal (.pt) we are using host attributes for all domain delegations.
> 
> The EPP feature that Scott remembered:
> 
> "With host objects you can change an IP address, for example, without 
> having to update (a potentially large number of) domains individually."
> 
> turned us to the object concept of hosts.
> 
> Now, with the introduction of EPP, we will have 2 different concepts:
> 
> 1 - Internal hosts : objects with a "sponsoring client" witch is the "sponsoring client" of the superordinate domain name of that host
> 
> 2 - External hosts : it's only needed a <domain:hostAttr> element with no IP adresses
> 
> We were thinking about creating these external hosts as objects too. 
> As they don't have IP addresses it's not necessary to update them. 
> And we can just delete them if they are not associated with domain names anymore..
> 
> This would be an implicit creation of hosts at the domain creation (excluding the <host:create> operation) and could possibly be used to the other type of hosts.
> 
> Have you any comments about this implementation?
> 
> --eugenio
> 
> 
> 
> Hollenbeck, Scott wrote:
> 
>>>I am anyway questioning the usefulness of having host objects 
>>>in EPP at 
>>>all. IMHO the only purpose for a host object is for the 
>>>host-to-IP mapping 
>>>i.e. for the glue records. And glue records are only needed, if a 
>>>nameserver is resolving its own superordinate domainname 
>>>(neglecting the 
>>>crossover games and stuff, which anyway are hard to detect). With 
>>>host-as-attribute it is rather easy to require such a missing IP 
>>>(just reject a domain create/update request, if name server 
>>>attribute is 
>>>subordinate and has no IP). Therefore I also do not see, why external 
>>>hosts and internal hosts, which do not resolve the superordinate 
>>>domainname, are treated differently in EPP. Or did I miss 
>>>something here?
>>>    
>>>
>>
>>Bernie, given that this was discussed extensively on the provreg list
>>it's best if you review the provreg archives to get the scoop on the
>>rationale.  google can help find specific messages.  One benefit I
>>remember involved updates.  With host objects you can change an IP
>>address, for example, without having to update (a potentially large
>>number of) domains individually.
>>
>>Thanks for letting me know that you're using host attributes.  That's
>>just the kind of info that needs to be shared.
>>
>>-Scott-

________________________________________________________________________
Jens-Uwe Gaspar                              Schlund + Partner AG
E-Mail: jug@schlund.de                       Brauerstr. 48
Tel. +49-721-91374-50                        76135 Karlsruhe, Germany
Fax  +49-721-91374-20                        http://www.schlund.de