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 >