To:
Eugenio Pinto <eugenio.pinto@fccn.pt>
CC:
"Hollenbeck, Scott" <shollenbeck@verisign.com>, Bernie Hoeneisen <bhoeneis@switch.ch>, tech@lists.centr.org, ietf-provreg@cafax.se
From:
Jens-Uwe Gaspar <jug@schlund.de>
Date:
Wed, 03 Aug 2005 20:03:32 +0200
In-Reply-To:
<42F0FE13.2000706@schlund.de>
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050324 Debian/1.7.6-1
Subject:
Re: [ietf-provreg] EPP Operations
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: > Dear Eugenio Pinto, > > your understanding of host-attributes / host-objects is not accurate. >... > 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