inregistrare pe automat

[Flaviu]

Radu,

In cazul functionarii pe "automat", nu se poate face in 2 pasi? Pasul
1 rezervare, pasul 2 confirmare ? Te intreb asta pentru ca se poate
intampla urmatoarea situatie: Un comparator vine la noi pe site si
comanda un domeniu, acest domeniu este disponibil, noi ii trimitem
factura/instintare de plata, la noi ajung banii sa spunem a 2-a zi in
cel mai fericit caz. In aceasta perioada, domeniul este disponibil si
oricine altcineva il poate cumpara de exemplu chiar de la ROTLD cu
plata cash. In acel moment eu as putea fii in situatia in care am
vandut un domeniu unui client, i-am facturat si a platit si nu mai pot
inregistra domeniul pentru ca nu mai este disponibil. CLientul nu mai
vrea banii inapoi si spune de exemplu ca el a investit 20k euro in
materiale publicitare unde apare domeniul si ca pe el nu-l inetreseaza
ca eu nu mai pot inregistra domeniul, vrea 20k pentru aceasta
pierdere.

Poate este un exemplu exagerat, dar este posibil.

Flaviu

[Radu Boncea]

Flaviu, exista si contra-argumente. Modul ne-automat este foarte
costisitor ca si administrare din parte registrului, dar si a
registrarilor. Si o sa dau niste exemple.
Exista multi clienti care abuzeaza de rezervare pentru a tine blocate
sute, chiar mii de domenii. Un astfel de client inregistreaza domeniul
la un partener care nu este pe automat sau direct la ROTLD (nici ROTLD
nu este pe automat, dar lucram la a-l trece pe automat) si nu plateste.
Monitorizeaza whois-ul non-stop si cum vede ca s-a sters il
reinregistreaza...si tot asa.
Stergerea unui domeniu este foarte costisitoare deoarece stergerea se
face manual. De fapt nu stergerea in sine, dar procesul de stergere
necesita confirmari si verificari ale operatorilor. In plus lasa loc de
erori umane. Au fost cazuri in care s-au dat la stergere, de catre
partener, din greseala, inclusiv domenii platite. Iar domeniile au fost
sterse. Pana acum norocul a fost de partea noastra si nu s-a intamplat
ca aceste domenii sa fi fost inregistrate de altcineva in perioada cat
s-a remediat eroarea, dar nu ne putem baza pe noroc. Cel mai grav lucru
care se poate intampla pentru un registru este sa fie pus in fata unui
asemenea situatii, sa "confiste" un domeniu pentru a-l da altcuiva. La
fel de grav ar fi si pentru partenerul care a facut greseala, fiind la
fel de eligibil juridic ca si registrul.

Mai exista si o latura tehnica pentru care API-ul nu poate implementa
solutia ta. Sistemul nu diferentiaza un domeniu inregistrat de unul
rezervat. Exista doar domenii inregistrate. ROTLD a recurs la un
artificiu pentru a le diferentia totusi. Domeniilor "rezervate" li se
atribuie niste stari, UpdateProhibited (nu se pot modifica datele) si
Hold (nu intra in zona .ro). Aceste stari insa pot exista si pentru
domeniile platite (domenii blocate wipo sau prin mandat judecatoresc, in
stergere, etc) si doar o actiune umana poate determina exact starea de
"rezervare". Nu se pot automatiza asemena decizii, marja de eroare
fiind netolerabila.

In concluzie, ROTLD doreste sa incurajeze cu acest API trecerea pe
automat si, intr-un timp rezonabil, sa ii aducem pe toti registrarii sa
aibe aceleasi conditii contractuale, aceleasi responsabilitati si
accesul la aceleasi resurse intr-un mod nediferentiat. Consider totusi
ca scenariul prezentat de tine poate fi usor evitat modificand regulile
proprii astfel incat sa explici clar ca inregistrarea unui domeniu se
efectueaza doar dupa confirmarea platii. Nici implementarea tehnica nu
ar presupune dificultati, in loc sa trimiti cererea inainte o trimiti dupa.

Radu Boncea

__________ Informatii de la ESET NOD32 Antivirus, versiunea bazei de semnaturi 5151 (20100527) __________

Mesajul a fost verificat de ESET NOD32 Antivirus.

http://www.eset.ro

[Flaviu]

Radu,

Inteleg explicatiile tale, si pot sa le accept. As putea totusi sa fac
o recomandare in masura in care se poate implementa in masura in care
"systemul" permite.

Daca un domeniu este rezervat de un client in vederea inregistrarii si
nu este confirmata inregistrarea in maxim 5 zile, sa se deblocheze
automat (fara interventie umana). In cazul in care in perioada asta de
5 zile un alt om/registrar incearca sa inregistreze acelasi domeniu el
sa poata intra intr-o lista de asteptare si sa se rezerve/inregistreze
automat pe numele acestui nou cumparator atunci cand nu se confirma
inregistrarea celui de dinainte. In acest fel se poate scapa de
eroarea umana cat si de abuzuri.

Mentionez ca nu stiu cum ati facut implementarile acolo, dar presupun
ca se poate pune un fel de baza de date tampon care sa trateze
situatia propusa de mine"

Ce parere ai ?

> http://www.eset.ro- Ascundeţi textul citat -
>
> - Afişare text în citat -

[Radu Boncea]

:) Ideea principala ar fi ca ROTLD incearca sa simplifice procedurile de inregistrare si administrare, folosind cea mai simpla solutie posibila. Marea majoritate a registrilor, fie ca vorbim de ccTLD sau gTLD, merg pe comanda ferma pentru ca ofera cea mai simpla metoda de administrare si evitare a oricaror complicatii de ordin juridic.
Ideea ta ar presupune o cu totul alta filozofie, un acces concurential la inregistrarea domeniilor, lucru greu de implementat daca nu chiar imposibil. De exemplu, niste contra-argumente:

• cum ar trebuii sa functioneze whois-ul in acest caz? Sa arate un domeniu ca fiind disponibil pentru domeniile "rezervate"? In cazul asta multi ar inregistra acelasi domeniu si toti ar avea pretentia ca domeniul le apartine. O astfel de situatie nu ar putea fi moderata nici de WIPO, s-ar ajunge in instanta.
• cum s-ar garanta prioritatea in inregistrare? Ar trebuii sa existe un fel de layer-aplicatie intermediar care ar superviza intregul proces si ar semnaliza real-time tuturor aplicatiilor momentul in care un domeniu devine liber si semnalizarea noului candidat. Un simplu script cron nu ar rezolva lucrurile pentru ca ar exista riscul ca pana cron-ul sa reinregistreze domeniul pe numele primului candidat sa existe un partener care inregistreaza domeniul cu comanda ferma inaintea tuturor candidatilor.
  
• cum ar suna regulile ROTLD in acest caz? Ar trebuii schimbate asta-i clar. Ar suna probabil ceva de genul: este posibil sa va inregistram domeniul daca platiti. Nu garantam insa inregistrarea.
• cum ar functiona API-ul in acest caz? Un partener "rezerva un domeniu". Dupa o zi alt partener "rezerva" acelasi domeniu. Dupa 5 zile domeniul primului partener este sters si se reinregistreaza pe al doilea partener. API-ul ar trebuii sa notifice partenerii angajati real-time de astfel de modificari. Administrarea ar deveni anevoioasa.
• cele 5 zile nu ar fi suficiente. Desi in teorie avem si noi prevazute 5 zile lucratoare pentru plata, in sistemul nostru informatic cele 5 zile au devenit cam 30 de zile si asta pentru ca multiďż˝ nu platesc in cele 5 zile, de multe ori exista weekend-uri, sarbatori si decat sa returnam banii la 50% din clienti am preferat sa lungim perioada. Asa ca cele 5 zile ar putea deveni 30, iar in 30 de zile ar exista domenii cu mai multi pretendenti care ar face ca probleme ridicate la punctele anterioare sa devina o regula.

Sincer nu cred ca trebuie sa reinventam roata. Trebuie sa ne aliniem la practicile celorlalti registrii, mai ales registrii europeni unde se lucreaza la niste principii si practici comune.

Radu Boncea


Flaviu wrote:

Flaviu, exista si contra-argumente. Modul ne-automat este foarte
costisitor ca si administrare din parte registrului, dar si a
registrarilor. Si o sa dau niste exemple.
Exista multi clienti care abuzeaza de rezervare pentru a tine blocate
sute, chiar mii de domenii. Un astfel de client inregistreaza domeniul
la un partener care nu este pe automat sau direct la ROTLD (nici ROTLD
nu este pe automat, dar lucram la a-l trece pe automat) si nu plateste.
Monitorizeaza whois-ul non-stop si cum vede ca s-a sters il
reinregistreaza...si tot asa.
Stergerea unui domeniu este foarte costisitoare deoarece stergerea se
face manual. De fapt nu stergerea in sine, dar procesul de stergere
necesita confirmari si verificari ale operatorilor. In plus lasa loc de
erori umane. Au fost cazuri in care s-au dat la stergere, de catre
partener, din greseala, inclusiv domenii platite. Iar domeniile au fost
sterse. Pana acum norocul a fost de partea noastra si nu s-a intamplat
ca aceste domenii sa fi fost inregistrate de altcineva in perioada cat
s-a remediat eroarea, dar nu ne putem baza pe noroc. Cel mai grav lucru
care se poate intampla pentru un registru este sa fie pus in fata unui
asemenea situatii, sa "confiste" un domeniu pentru a-l da altcuiva. La
fel de grav ar fi si pentru partenerul care a facut greseala, fiind la
fel de eligibil juridic ca si registrul.

Mai exista si o latura tehnica pentru care API-ul nu poate implementa
solutia ta. Sistemul nu diferentiaza un domeniu inregistrat de unul
rezervat. Exista doar domenii inregistrate. ROTLD a recurs la un
artificiu pentru a le diferentia totusi. Domeniilor "rezervate" li se
atribuie niste stari, UpdateProhibited (nu se pot modifica datele) si
Hold (nu intra in zona .ro). Aceste stari insa pot exista si pentru
domeniile platite (domenii blocate wipo sau prin mandat judecatoresc, in
stergere, etc) si doar o actiune umana poate determina exact starea de
"rezervare". �Nu se pot automatiza asemena decizii, marja de eroare
fiind netolerabila.

In concluzie, ROTLD doreste sa incurajeze cu acest API trecerea pe
automat si, intr-un timp rezonabil, sa ii aducem pe toti registrarii sa
aibe aceleasi conditii contractuale, aceleasi responsabilitati si
accesul la aceleasi resurse intr-un mod nediferentiat. Consider totusi
ca scenariul prezentat de tine poate fi usor evitat modificand regulile
proprii astfel incat sa explici clar ca inregistrarea unui domeniu se
efectueaza doar dupa confirmarea platii. Nici implementarea tehnica nu
ar presupune dificultati, in loc sa trimiti cererea inainte o trimiti dupa.

Radu Boncea

__________ Informatii de la ESET NOD32 Antivirus, versiunea bazei de semnaturi 5151 (20100527) __________

Mesajul a fost verificat de ESET NOD32 Antivirus.

http://www.eset.ro- Ascunde�i textul citat -

- Afi�are text �n citat -
    

__________ Informatii de la ESET NOD32 Antivirus, versiunea bazei de semnaturi 5152 (20100528) __________

[Flaviu]

Eu vedeam lucrurile mai simple:

Cazul #1:

1) partenerul 1 face cerere de inregistrare a unui domeniu, cu toate
datele clientului
ROTLD pune domeniul in "rezervat"
2) partenerul 1 incaseaza banii de la client si instrinteaza ROTLD de
confirmarea inregistrarii domeniului
ROTLD marcheaza domeniul ca fiind inregistrat.

Pe perioada cat domeniul este in stadiul de "rezervat" se afiseaza
acest lucru la whois.

Daca partenerul 1 nu confirma domeniul in aceste 5 zile, atunci
domeniul redevine disponibil pentru toata lumea (fara interventie
umana).

Cazul #2

1) partenerul 1 face cerere de inregistrare a unui domeniu, cu toate
datele clientului
ROTLD pune domeniul in "rezervat"
2) partenerul 2 face o cerere de inregistrare a aceluias domeniu, cu
datele altui client. Avand obligatia sa spuna clientului ca domeniul
este rezervat de un alt cumparator si ca o sa fie pus pe o lista de
asteptare, in cazul in care domeniul redevine disponibil inregistrare
se va putea face automat daca clientul efectueaza plata. In cazul asta
obligatia restituirii banilor revine partenerilor ( eu mi-as asuma
aceasta obligatie )

ROTLD pune aceasta noua cerere intr-o lista de asteptare.
Daca partenerul 1 NU confirma inregistrarea atunci automat si fara
interventia umana datele de rezervare se schimba cu cele din cererea
partenerului 2. Partenerul 1 ne mai putand sa faca confirmare
inregistrari
Daca partenerul 1 confirma inregistrarea atunci partenerul 2 nu va mai
putea sa faca confirmarea inregistrari domeniului.

In acest caz la whois o sa apara ca domeniul este "rezervat".


Inteleg nevoia simplificarii procesului de inregistrare de domenii,
din pacate suntem in romania si lucrurile nu functioneaza asa cum
functioneaza in afara. Singura metoda de a cumpara domeniul pe
sistemul propus de tine este plata cu card. Din pacate la noi, mai
putin de 5 % platesc cu cardul , restul platind prin banca.

Nu este suficient sa scrii pe site sau in contract ca inregistrarea se
va face dupa ce ne intra banii in cont pentru ca nimeni nu poate sta
cu ochiiul pe intenret banking ( sau chiar mai rau sa scoata extrasul
din ora in ora de la banca ) pentru a putea face inregistrarea intr-un
timp cat mai scurt de la intrarea banilor in cont. In cazul in care
dai de un client car vrea sa-ti faca rau, si am vazut astfel de
clienti cu nemiluita, poate spune in orice moment (pe toate siteurile
posibile) ca i-ai furat domeniul ca iti placea cum se numea, ca etc si
iti scade credibilitatea foarte usor. Si din pacate atata timp ca
ROTLD vinde direct, aceste situatii nu vor impinge clientii decat
catre cumpararea de la ROTLD.

Cred ca este important ca ROTLD sa tina cont si de nevoile de business
ale partenerilor, si nu doar sa impuna. Vad si apreciez foarte mult ca
faceti niste pasi foarte importanti in a ajuta parteneri si chiar
doresc sa va multumesc pentru aceste eforturi.

[Radu Boncea]

Flaviu,

"Rezervarea" nu este o solutie. ROTLD este un ccTLD si participa la anumite conferinte, grupuri de discutii si grupuri de decizii unde ccTLD-isti si gTLD-istii au ajuns la un punct comun si o strategie cu care ROTLD a fost de acord, ca de altfel toti registrii: uniformizarea si standardizarea sistemului de inregistrare/administrarea de nume de domenii. Scopul final ar fi un ca registrar .de sa poata deveni registrar .ro usor, nemodificand decat superficial scripturile. Astfel s-au nascut niste standarde, EPP si extensiile EPP pe care ROTLD le-a adoptat si implementat in 2008. Aceste standarde impun un anumit comportament al domeniilor, anumite atribute si functionalitati. "Rezervarea" nu intra in aceasta schema. Faptul ca ROTLD permite in acest moment "rezervarea" prin niste artificii neortodoxe nu inseamna ca trebuie propovaduit acest reflex la nesfarsit, mai devreme sau mai tarziu oricum se va renunta complet la "rezervare". In Europa ROTLD este singurul registru care permite "rezervarea". Stiu ca hostway inregistreaza si alte domenii, in afara .ro, deci se poate si fara rezervare fara implicatii semnificative.

Sunt de acord ca ROTLD trebuie sa tina cont de interesele registrarilor. Pentru asta am creat EPP (neinspirat ce-i drept cata vreme nu avem domenii anuale) si REST care este conform cu princiile enuntate de EPP mai putin modul de implementare. Totusi ROTLD trebuie sa tina cont si de(mai ales) interesele utilizatorilor finali. Cu rezervarea exista dimpotriva mai multe probleme. Clienti care se plang la ROTLD ca domeniul a fost platit si dureaza prea mult confirmarea, clienti care nu inteleg ce este aia rezervare si cand vad in whois ca domeniul exista deja fie nu mai platesc fie suna la ROTLD pentru lamuriri. Si multe alte astfel de cazuri.

Pentru a automatiza procesul de inregistrare si administrare trebuie sa raspectam principiul conform caruia serviciul trebuie oferit 'as it is'...un domeniu este pur si simplu inregistrat, fara interpretari ca acel domeniu este pentru registru inregistrat, pentru partener rezervat iar pentru client si inregistrat si rezervat. Trebuie evitate stergerile de domenii. Trebuie evitate problemele de genul: un client si-a trecut din greseala datele de registrant la technical sau a gresit numele, iar ROTLD sa nu poata remedia problema si trebuie sa astepte ca domeniul sa fie sters, platit sau confirmat pentru a putea efectua corectiile, care corectii sustin o intreaga birocratie.

In concluzie, ROTLD nu doreste sa faca un compromis la un asemea nivel care modifica fundamental implementarea curenta si care este conforma unor standarde internationale. Desi problemele enuntate de tine o sa existe, sunt convins ca in timp, ele o sa dispara odata cu adaptarea romanului la noua ordine.

Flaviu, eu nu inteleg totusi ceva. Voi vreti introducerea taxei anuale. Iti dai seama totusi ca daca noi ne impiedicam in "detalii" cum ar fi rezervarea, la domeniile anuale o sa ne punem cenusa in cap...pentru ca asta este "rezervarea" pe langa introducerea taxei anuale...un detaliu mic.

2010/5/28 Flaviu <fla...@hostwaylab.ro>

--
Best Regards,

Radu Boncea

[Flaviu]

Ok, am inteles directia si motivele. Suntem ok cu propunerea voastra.

Am sa-ti raspund la intrebarea de mai jos.

> Flaviu, eu nu inteleg totusi ceva. Voi vreti introducerea taxei anuale. Iti
> dai seama totusi ca daca noi ne impiedicam in "detalii" cum ar fi
> rezervarea, la domeniile anuale o sa ne punem cenusa in cap...pentru ca asta
> este "rezervarea" pe langa introducerea taxei anuale...un detaliu mic.

Noi nu am cerut inregistrarea pe un an, noi am atras atentia ca nu
este sustenabila din punct de vedere economic nici pentru parteneri,
nici pentru ROTLD.

Singura problema pe care o avem legat de inregistrarea pe 1 an, asa
cum este acum implementata la voi, este ca nu pot inregistra domeniul
pe numele clientului. Din cauza asta avem foarte foarte multi clienti
care se plang ca noi am inregistrat domeniul abuziv pe numele nostru.
Si cu toate explicatiile noastre, ei tot considera ca suntem niste
tepari. Poti sa-mi spui daca se vor putea face acest inregistrari
anuale pe numele clientului?

[Radu Boncea]

Dap, contractul si introducerea acelui gen de domenii anuale s-a dovedit a fi cea mai neinspirata decizie ROTLD. A fost un compromis (un exemplu de ce ROTLD la anumite lucruri nu trebuie sa faca compromisuri). La vremea respectiva anumiti parteneri au cerut insistent domenii anuale care sa stea la baza unor pachete de servicii internet. De fapt contractul de domenii anuale se numeste "contract de parteneriat pentru inregistrare nume de domenii .ro livrate intr-un pachet de servicii Internet". Adica partenerul inregistra domeniul pe 1 an si ii oferea clientului un pachet de servicii care se bazau pe numele de domeniu. 

De ce s-a ajuns ca numele de domeniu sa fie pe numele partenerului?

Initial partenerii au cerut asa pentru a se asigura ca isi acopera cheltuiala. Si ROTLD-ului ii convenea dar din cu totul alte motive. Conform normelor ICANN, WIPO, UDRP etc un detinator de nume de domeniu are drepturi de utilizare asupra numelui de domeniu, drepturi care nu pot fi restranse sau sa existe constrageri de drepturi. Practic un detinator trebuie sa poata sa-si modifice rezolutia DNS sau, in cazul domeniilor anuale, sa poata sa ceara oricand transferul catre un alt registrar pentru a incuraja un mediu competitiv etc. Partea cu transferul insa nu poate fi pusa in practica, nu se poate transfera un domeniu cu taxa anuala la un registrar care nu poate sa aibe taxa anuala. Un astfel de detinator ar fi castigat la WIPO ca este musai sa fie transferat, moment in care am fi suflat a paguba. Domeniul ar fi trebuit trecut la domenii "pe viata" in mod gratuit. Toata lumea ar fi aflat si ar fi inregistrat numai domenii anuale dupa care ar fi cerut transferul gratuit.

Ca o scuza insa, acest tip de domenii a dus totusi la cresterea numarului de domenii. In plus asigura niste venituri clare. 

Domeniile cu taxa anuala nu se impaca insa cu cele fara taxa si au creat multe probleme. 

Din motivele de mai sus, nu, nu putem da voie ca numele detinatorului sa fie al clientului.

 

2010/5/28 Flaviu <fla...@hostwaylab.ro>