Subject: [ietf-provreg] EPP Operations

From: Eugenio Pinto <[email-masked]>
Date: Wed, 3 Aug 2005 18:25:20 +0200 (MEST)

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:
<blockquote
 cite="[email-masked]"
 type="cite">
  
    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-

---

From: Jens-Uwe Gaspar <[email-masked]>
Date: Wed, 3 Aug 2005 19:25:41 +0200 (MEST)

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

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

---

From: Jens-Uwe Gaspar <[email-masked]>
Date: Wed, 3 Aug 2005 20:03:34 +0200 (MEST)

Dear Eugenio Pinto,

apologies, forget my previous mail, your understanding of host-attr/objects
is correct. I didn't correctly catch your "main question".

If you want internally use host-objects as you described, it's totally
normal to implicitly create objects for it in your repository.
IMHO in mostly every database-model used to describe domains with host-
attributes you need some kind of "host-objects" in your database.

You may get problems when you treat your "db-host-objects" as real
"host-objects" linking them also to other domains, because to other
domains the "host-object" with IP is a host WITHOUT IP (e.g. 'foo.pt' with
ns 'ns.foo.pt' and an IP <=> 'bar.pt' with same ns has no IP, because it's
not a glue).
That should be avoided. It could lead to a problem when deleting
domains. You can create separate "host-objects" in your database when
used with other domains, or use some (complex) logic to remove the IPs
from the host when deleting its parent domain.

To which fields you are mapping the values from an EPP-domain-request
with hosts (with or without IPs) is up to you. You don't even need
to store the "sponsoring-client" for a host (it's implicitly defined
by the relationship to the domain).

Kind regards,

Jens-Uwe Gaspar

Jens-Uwe Gaspar wrote:
>...

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 3 Aug 2005 20:21:16 +0200 (MEST)

Jens-Uwe Gaspar wrote:

>> 1 - Internal hosts : objects with a "sponsoring client" witch is the 
>> "sponsoring client" of the superordinate domain name of that host
>>
>> 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.
>>

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
      [email-masked]             Tel. +49 231 9703 0

---

From: Eugenio Pinto <[email-masked]>
Date: Wed, 3 Aug 2005 20:37:26 +0200 (MEST)

Hi!

Thanks for your answer. I have some comments inside it.

--eugenio

> from the host when deleting its parent domain.

I think it's not so complex..

--eugenio

> by the relationship to the domain).

Yes, we are doing it but for the superordinate domain.

--eugenio

>>> "With host objects you can change an IP address, for example, 
>>> without having to update (a potentially large number of) domains 
>>> individually."
>>>
>>> (excluding the <host:create> operation) and could possibly be used 
>>> to the other type of hosts.
>>>
>>>>> 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?
>>>>>   
>>>>
>>>>

---

From: Eugenio Pinto <[email-masked]>
Date: Wed, 3 Aug 2005 20:41:30 +0200 (MEST)

Hi Klaus!

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

--eugenio

Klaus Malorny wrote:

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