Re: [ietf-provreg] EPP Operations

[Eugenio Pinto <eugenio.pinto@fccn.pt>]

Hi Klaus!

Thanks for your answer. It was all I need to know.

--eugenio


Klaus Malorny wrote:

> Jens-Uwe Gaspar wrote:
>
>> 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
>>>
>
>
> Hi all,
>
> just to clarify the term "implicit host creation": Readers of this 
> term might think that host objects (RFC 3732) would be created 
> implicitly with the host attributes. However, it is required that host 
> objects may not be used in parallel with the host attributes.
>
> Section 1.1 RFC 3731
>
>    »A server operator MUST use one name server
>    specification form consistently.  A server operator that announces
>    support for host objects in an EPP greeting MUST NOT allow domain
>    attributes to describe a name server host machine.  A server operator
>    that does not announce support for host objects MUST allow domain
>    attributes to describe a name server host machine.«
>
> regards,
>
> Klaus
>
>
> ___________________________________________________________________________ 
>
>      |       |
>      | knipp |                   Knipp  Medien und Kommunikation GmbH
>       -------                           Technologiepark
>                                         Martin-Schmeißer-Weg 9
>      Dipl. Inf. Klaus Malorny           44227 Dortmund
>      Klaus.Malorny@knipp.de             Tel. +49 231 9703 0
>
>