[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Jordyn A. Buchanan" <jordyn@register.com>
CC: "Hollenbeck, Scott" <shollenbeck@verisign.com>, ietf-provreg@cafax.se
From: Daniel Manley <dmanley@tucows.com>
Date: Tue, 18 Dec 2001 08:21:18 -0500
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.5) Gecko/20011011
Subject: Re: "External" hosts in EPP

yes, that's a good argument that we don't consider enough.  At what 
point does EPP have a little too much of the "E"?  I'll take back my 
previous statement, but do consider that this is an extensible protocol. 
 What's stopping every registry from extending in such different 
directions that interoperability is still lost?

Dan


Jordyn A. Buchanan wrote:

> As I indicated in Salt Lake, I'm not a very big fan of "freedom of 
> expression" for freedom of expression's sake.  This is the sort of 
> option that makes it harder to interoperate and doesn't gain any 
> additional functionality.
>
> If someone (Cathy, Klaus?) has any reasons why it is actually 
> beneficial to have the name server as an attribute as opposed to an 
> object, I'll reconsider my stance.  I think all I've heard to this 
> point is "that's how some registries do it already".  That's not 
> really an argument to explain whether it's good behavior, though. Some 
> registries allow out-of-zone glue, which we decided was a bad idea 
> long ago.  The change to EPP is already going to require some change 
> in how registrars interact with registries; I simply don't get how the 
> requirement to create a host object before using it is particularly 
> damaging.
>
> On the flip side, if some registries require host object creation and 
> some don't, this means registrars have to create substantially 
> different logic for how they register domains in some TLDs (or IP 
> registries) than they do in others.  That's not good.
>
> Jordyn
>
>
> At 6:51 PM -0500 12/17/01, Daniel Manley wrote:
>
>> For the sake of freedom of expression, I guess it wouldn't hurt, but 
>> we would probably not use it -- there's too many advantage to using 
>> host objects.
>>
>> Dan
>>
>> Hollenbeck, Scott wrote:
>>
>>>> -----Original Message-----
>>>> From: Jordyn A. Buchanan [mailto:jordyn@register.com]
>>>> Sent: Monday, December 17, 2001 5:38 PM
>>>> To: wessorh@ar.com; Hollenbeck, Scott
>>>> Cc: ietf-provreg@cafax.se
>>>> Subject: RE: "External" hosts in EPP
>>>>
>>>>
>>>> At 11:58 AM -0800 12/17/01, wessorh@ar.com wrote:
>>>>
>>>>> Scott,
>>>>>
>>>>> I'd agree that Asbjorn's proposal is reasonable one. OTOH, creating
>>>>> objects for non-glue hosts seem counterintuitive, I'd prefer
>>>>
>>>> that we did
>>>>
>>>>> not have too. If others favor consistency, i'll drop my objection.
>>>>>
>>>> Consistency is nice.  Asbjorn's proposal has the added advantage of 
>>>> making it much easier to change from a host without glue to an 
>>>> in-zone host with glue by simply updating the object as opposed to 
>>>> changing each and every domain that you have associated with a 
>>>> particular out-of-zone host.
>>>>
>>>
>>> OK, then, last concern:  I think I said something bogus when talking 
>>> about
>>> this at SLC.  I believe it was Sheer who asked if the intention was 
>>> to allow
>>> mixing of host-object and no-host-object modes, and I think I said 
>>> "yes".
>>> If I did, that's not what I meant to say.  My intention was to 
>>> provide the
>>> choice in the domain mapping such that a server could choose to 
>>> implement
>>> host objects (now with Asbjorn's suggested fix that some of you vaguely
>>> remembered at the end of the discussion), or a server could choose 
>>> to NOT
>>> implement host objects and do delegations using name server info as 
>>> domain
>>> attributes.
>>>
>>> Does anyone see any value in offering this choice?  Is anyone 
>>> interested in
>>> implementing a no-host-object server?  If not, it doesn't seem worth 
>>> adding
>>> the choice.
>>>
>>> -Scott-
>>
>
>




Home | Date list | Subject list