[nc-org] RE: protocol specification in the policy
Thanks for copying me in on the correspondence on this issue.
I would like to re-iterate my original comments. Registrars do not want to
develop yet another interface to a different protocol, and do not want a
lower grade of service for their customers than what they currently have.
I can accept removal of specific protocol names, but the "policy" principles
(1) The ".org" registry should match or improve on the performance
specifications of the current ".org" registry
(2) The registry-registrar protocol should either remain the same as the
current ".org" registry, or it should match the new international standard
for registry-registrar protocols being developed in the Internet Engineering
The current text that talks about "good" service - relative to what? - is
too vague, and the statement to minimise transitional expenses for
registrars is a good aim, but I would like more precise wording.
The whole point of registrar input is to provide some more detail to the
original proposal from the registrar perspective.
We wasted alot of time on the protocol issue in the recent ".au" tender RFP
(the RFP was put out for comment and after strong lobbying from registrars
and potential registrars - it eventually specifically included the
requirement for the new EPP protocol).
You have been quite specific on other areas of the policy, so it would be
appropriate to be equally specific in the technical policy.
I will review your wording and suggest some alternative wording for your
> In this case, the prior draft's mention of specific
> protocols was criticised by both Louis Touton and Cary
> Karp as being unnecessary. The objection was that that
> level of detail should be left to the RFP. This is a policy
> document, not an RFP.
> It was agreed without objection to remove that
> language. You were on the call at the time, Ken.
> As a substitute and protection, I took it upon myself
> to add language specifying that costs to registrars
> should be minimized. (You're welcome — oh, that's right,
> you never did thank me.)
> I have no objection to keeping that language in
> or taking it out. (I was the one who put it in there
> to begin with, based on comments from Bruce Tonkin.
> And by the way, I found those comments on my own,
> you never forwarded them to the TF list. You're
> welcome, again.)
> If you think it should remain in this draft, take it up
> with Louis and Cary. Personally, I believe that
> you can trust ICANN to include appropriate
> language in the RFP.
> I think the more fundamental issue here is how
> we go about reaching an agreement we call all live with.
> Disorganized and haphazard objections based on a poor
> understanding of processes that _you took part in_
> are not a good way to do it.
> >>> "Ken Stubbs" <email@example.com> 01/04/02 04:10PM >>>
> fellow TF members...
> the current draft reads:
> " Any entity chosen by the TLD delegee to operate the .org
> registry must
> function efficiently and reliably and show its commitment to
> a high quality
> of service for all .org users worldwide, including a
> commitment to making
> registration, assistance and other services available in
> different time
> zones and different languages. The price of registration
> proposed by the new
> entity should be as low as feasible consistent with the
> maintenance of good
> quality service. Protocols used by the new registry should minimize
> transitional expenses for registrars."
> the original draft stated that :
> Applicants should meet the current performance specifications from the
> Verisign .org agreement. The new .org registry should either use the
> existing .org registry/registrar protocol (RRP), or be
> compliant with the
> EPP protocol of the IETF "provreg" working group.
> why was it subsequently revised ?
> we have had specific concerns express by registrars that
> these specific
> protocols be specified as they are consistant with current
> ICANN - registrar
> protocols in use or proposed to be used in the near future.
> can we please take the wording back to where it was before ?
> ken stubbs