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


To: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
CC: epp-rtk-devel@lists.sourceforge.net
From: Daniel Manley <dmanley@tucows.com>
Date: Fri, 15 Jun 2001 15:10:45 -0400
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9.1) Gecko/20010608
Subject: Re: [Epp-rtk-devel] RE: ROID Placement

Actually Scott,

Here's the situation:

Afilias/Liberty and the latest release of the java RTK is using a 
pre-release of 02 which still uses ROID as the only way of identifying a 
contact.  Getting the RTK up to the newest EPP is no big impact (changes 
to the IDLs and a couple of lines here and there), but the jump will 
impact current registrars for .info.  I'm not sure if the ietf-provreg 
group has to care about that, although it would be nice to take into 
consideration in the future (especially as more registries come online). 
 The registry upgrade and consideration of the impacts to the registrars 
should be important to registry operators (eg. Afilias, Neulevel, GNR, 
RegistryPro, etc...).

so....
    going from pre-02 to current 02 -- little changes to RTK, but 
noticeable impact to users of the RTK (limited to .info registrars only 
at this point?)
    going from current 02 to changes in ROID (or it's removal) -- nearly 
none (which goes back to my comment early about the ROID having almost 
no use to the registrar at that point anyhow)

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Eric Brunner-Williams in Portland Maine
>>[mailto:brunner@nic-naa.net]
>>Sent: Friday, June 15, 2001 11:02 AM
>>To: Hollenbeck, Scott
>>Cc: 'ietf-provreg@cafax.se'; epp-rtk-devel; brunner@nic-naa.net
>>Subject: Re: [Epp-rtk-devel] RE: ROID Placement 
>>
>
>[snip]
>
>>As Ayesha pointed out, the derivation is complicated by this change of roid
>>placement, and that alone should give pause. As you pointed out, this means
>>we delta the requirements draft, not a big deal, and get the roid
>>
>functionally
>
>>placed correctly. Clearly, from the registry use cases for requirements, a
>>global identifier is not optional.
>>
>
>A requirements change is needed only if we decide to remove ROIDs
>completely.  That's certainly an option, and maybe it's one we need to
>explore before re-examining the placement issue.
>
>Let's assume that we prefer to keep them.  Dan Manley, another implementer,
>didn't allude to any complications in his response sent yesterday.  I have a
>VeriSign implementer who also feels that it's not a problem.  However, if
>it's an issue for anyone it's a good topic for discussion.
>
>Would it be better if the only place a ROID was returned is in the object
>data returned in the response to an <info> command?  If so, I can live with
>that.
>
><Scott/>
>
>_______________________________________________
>Epp-rtk-devel mailing list
>Epp-rtk-devel@lists.sourceforge.net
>http://lists.sourceforge.net/lists/listinfo/epp-rtk-devel
>




Home | Date list | Subject list