Bekijk Volledige Versie : SIDN onze voorstellen
DennisWijnberg
26/02/09, 17:08
Hallo allemaal,
Oxilion is een van de grotere providers van Nederland (#53 op de SIDN-lijst) en krijgt daarmee dus ook zo nu en dan een bezoek van de relatiebeheerder van de SIDN.
1) De kortingen.
Veel over gezegd, de meningen verdeeld. Maar wij hebben inhoudelijk gekeken naar de argumenten van de SIDN, en distilleren daaruit dat de korting wordt gegeven omdat ze "minder werk hebben aan de grote providers". Oftewel; de korting wordt verschaft omdat ze minder werk hebben aan deze providers.
Maar, dat is natuurlijk niet per definitie waar, het kan ook zijn dat een kleine provider (ook in verhouding) veel minder werk oplevert.
Daarom zou ons voorstel zijn om de korting af te laten hangen van de accreditatie, en daar bijvoorbeeld 3 niveaus in aan te brengen en per niveau eisen te stellen.
Niveau 1 is een standaard accreditatie met als gevolg; geen korting. Over de andere twee niveaus kan je eisen verdelen, een paar voorbeelden.
- Altijd nog netjes twee weken secundaire DNS draaien.
- Maximaal 1% fouten in DNS-records
- Maximaal x-keer ten onrechte bezwaar (of helemaal niet)
- Auth-ID netjes binnen 1 werkdag verstrekken (auth-id's niet verstrekken omdat er niet betaalt is, is helemaal uit den boze)
- (of tot die tijd) Verhuisverzoeken binnen 1 werkdag verwerken
- Proeve van bekwaamheid voor alle SIDN-procedures
(Bel je hier dan wel over, dan accreditatie kwijt)
Op basis van deze eisen ken je dan de korting toe. Deze, geaccrediteerde, bedrijven zorgen namelijk echt voor minder werk.
2) DRS / EPP
Ons tweede voorstel was om DRS / EPP open source te maken. Op die manier kan iedereen zelf de known-errors oplossen waarbij de SIDN natuurlijk wel eisen kan stellen aan de code (bepaalde standaarden, naamconventie etc.).
Op die manier kan iedereen zelf zijn/haar steentje bijdragen en werken we met z'n allen aan een totaalproject. Kostenbesparend en super voor de kwaliteit.
Uiteraard is het contribute-only en mag het systeem (licentietechnisch) niet voor een andere TLD worden gebruikt (dat merk je echt snel genoeg).
Aanstaande maandag krijg ik de reactie van de SIDN, ik ben ook nieuwsgierig naar de reacties van jullie want we moeten het met elkaar doen.
Vanuit hier een goed idee, even een agendapuntje voor vrijdag voor ons. ;)
Ben op zich voorstander van het belonen van kwaliteit, echter lijkt het me lastig om hier criteria aan te hangen.
- Altijd nog netjes twee weken secundaire DNS draaien.
- Maximaal 1% fouten in DNS-records
Je gaat er hier vanuit dat de deelnemer tevens altijd de hoster is.
Indien je niet aan koppelverkoop doet, en je klanten toestaat een domein te registreren, om deze vervolgens aan de nameservers van een andere provider te koppelen, heb je als deelnemer geen invloed op de kwaliteit van de DNS.
- Auth-ID netjes binnen 1 werkdag verstrekken (auth-id's niet verstrekken omdat er niet betaalt is, is helemaal uit den boze)
Een andere optie zou zijn om de provider de code bij de registratie van het domein al naar de klant te laten sturen, of op de factuur te vermelden.
===
Uiteraard is het contribute-only en mag het systeem (licentietechnisch) niet voor een andere TLD worden gebruikt (dat merk je echt snel genoeg).
Zou er niets op tegen hebben als andere TLDs het wel zouden gebruiken.
Hoe meer registries met dezelfde EPP variant werken, hoe beter.
Levert je als provider een tijd- en kostenbesparing op, op het moment dat je de andere TLD ook aan je eigen systeem wilt toevoegen.
martysmarty
26/02/09, 18:09
Heel goed voorstel, vooral nummer 1.
Laat je ons de reactie van SIDN weten?
- Auth-ID netjes binnen 1 werkdag verstrekken (auth-id's niet verstrekken omdat er niet betaalt is, is helemaal uit den boze)
Is niet haalbaar, een welles-nietes situatie.
- (of tot die tijd) Verhuisverzoeken binnen 1 werkdag verwerken
Scheelt dat geld?
- Proeve van bekwaamheid voor alle SIDN-procedures
(Bel je hier dan wel over, dan accreditatie kwijt)
Dat is wel weer erg rigoreus. Dan krijg je dus deelnemers die hun klanten onzin gaan vertellen gewoon om de korting te verkrijgen, want kennis dateert ook en accreditatie/toetsingen kosten geld, en dat willen ze hiermee nou just besparen.
DennisWijnberg
26/02/09, 22:56
Een andere optie zou zijn om de provider de code bij de registratie van het domein al naar de klant te laten sturen, of op de factuur te vermelden.
Super, nog beter!
Laten we nou niet roepen dit kan niet en dat kan niet, maar laten we roepen wat er wel kan en hoe het beter zou kunnen.
- Auth-ID netjes binnen 1 werkdag verstrekken (auth-id's niet verstrekken omdat er niet betaalt is, is helemaal uit den boze)
Is niet haalbaar, een welles-nietes situatie.
Prima haalbaar zonder welles-nietus spelletje. De provider moet gewoon altijd de code verstrekken.
- Proeve van bekwaamheid voor alle SIDN-procedures
(Bel je hier dan wel over, dan accreditatie kwijt)
Dat is wel weer erg rigoreus. Dan krijg je dus deelnemers die hun klanten onzin gaan vertellen gewoon om de korting te verkrijgen, want kennis dateert ook en accreditatie/toetsingen kosten geld, en dat willen ze hiermee nou just besparen.
Wordt aan gewerkt. Via je branchevereniging of de SIDN heb je hier al iets over vernomen als het goed is. Een en ander is verder nog niet publiek, dus ga ik hier niet posten.
spininhetweb
02/03/09, 09:25
Als kleine SIDN-deelnemer voelen we ons vooral nogal vaak overvallen door dit soort zaken. Hoewel wij als kleintje het voordeel van flexibiliteit hebben vallen wijzigingen ons meestal ook extra rauw op ons dak.
Het lijkt me zeer redelijk om inderdaad uit te gaan van kwaliteitseisen. Sommige zaken in jullie voorstel(len) zijn misschien niet helemaal goed haalbaar, maar het idee is goed.
Wel levert het trouwens een nieuwe dimensie op in de onderlinge concurrentie. "Spin in het Web - SIDN level 3 geacrediteerd, kom daar maar eens om bij domeinnamenvoorweinigmaartochgoed.nl". De wenselijkheid daarvan zou meegenomen moeten worden in de discussie. Als kwaliteitsdeelnemer zien wij het wel met vertrouwen tegemoet ;-)
Open source is ook een goed idee, de reactie van SIDN op dit idee laat zien aan welke kant van de lijn zij ergens staan. Ze vergeten wel eens dat .NL van ons is (van "Nederland"), en niet van hen.
Indien je niet aan koppelverkoop doet, en je klanten toestaat een domein te registreren, om deze vervolgens aan de nameservers van een andere provider te koppelen, heb je als deelnemer geen invloed op de kwaliteit van de DNS.
Volgens mij is het momenteel een harde eis aan deelnemers dat ze de kwaliteit van DNS garanderen. Als je klanten toestaat een bij jou geregistreerde domeinnaam in een andere DNS te zetten (wat wij ook doen), dan moet je bij die klanten diezelfde kwaliteitseisen afdwingen.
Tot zover mijn € 0,02
DennisWijnberg
02/03/09, 09:31
- (of tot die tijd) Verhuisverzoeken binnen 1 werkdag verwerken
Scheelt dat geld?
- Nee, maar het is wel goed voor de eindgebruiker. Je mag ook best wat doen voor je korting!
- Proeve van bekwaamheid voor alle SIDN-procedures
(Bel je hier dan wel over, dan accreditatie kwijt)
Dat is wel weer erg rigoreus. Dan krijg je dus deelnemers die hun klanten onzin gaan vertellen gewoon om de korting te verkrijgen, want kennis dateert ook en accreditatie/toetsingen kosten geld, en dat willen ze hiermee nou just besparen.
Ik weet niet of jullie een helpdesk hebben zitten. Als je de kosten van een helpdesk-bezetting afzet tegen de kosten van een proeve van bekwaamheid (kan gewoon online), dan is de laatste toch echt veel goedkoper.
Met betrekking tot dateren, bij elke ingrijpende DRS-versie kan je een nieuwe proeve van bekwaamheid doen (met als aanvulling de veranderingen).
spininhetweb
02/03/09, 10:05
-
Met betrekking tot dateren, bij elke ingrijpende DRS-versie kan je een nieuwe proeve van bekwaamheid doen (met als aanvulling de veranderingen).
Hoe zou zo'n proeve er dan uitzien? Een multiple-choice testje?
Het probleem is dat je dat zou willen automatiseren. Je zou kunnen denken: tel de fouten in de DRS-communicatie. Hoe minder fouten, hoe bekwamer de deelnemer. En dan blijkt het nogal eens voor te komen dat de SIDN degene is die de proeve niet doorstaat. Ik noem alleen het probleem met hele lange domeinnamen in e-mailformulieren. De domeinnaam zelf pikken ze, postmaster@diezelfdehelelangedomeinnaam niet.
Wanneer is een deelnemer 'bekwaam'?
Ik denk dat SIDN ook maar eens moet laten zien waar dat geld heengaat. Ik lees hier net nog dat ze dus relatiemanagers de hele tijd over de vloer laten komen bij de grotere deelnemers? Waarom dan? Wat doen die dan? Ze moeten toch alleen maar in een lijstje schrijven wie welke domeinnaam heeft? Lijkt me niet het moeilijkste karweitje. Moet daar iemand regelmatig voor op de borrel komen?
DennisWijnberg
02/03/09, 10:20
Hoe zou zo'n proeve er dan uitzien? Een multiple-choice testje?
Het probleem is dat je dat zou willen automatiseren. Je zou kunnen denken: tel de fouten in de DRS-communicatie. Hoe minder fouten, hoe bekwamer de deelnemer. En dan blijkt het nogal eens voor te komen dat de SIDN degene is die de proeve niet doorstaat. Ik noem alleen het probleem met hele lange domeinnamen in e-mailformulieren. De domeinnaam zelf pikken ze, postmaster@diezelfdehelelangedomeinnaam niet.
Wanneer is een deelnemer 'bekwaam'?
Ja, een MC-test zou prima kunnen, mits goed uitgeschreven. Je kunt helaas niet alleen op basis van het aantal DRS-fouten iets bepalen, dit kan wel meespelen in of de beoordeling mijnsinziens.
Ik denk dat SIDN ook maar eens moet laten zien waar dat geld heengaat. Ik lees hier net nog dat ze dus relatiemanagers de hele tijd over de vloer laten komen bij de grotere deelnemers? Waarom dan? Wat doen die dan? Ze moeten toch alleen maar in een lijstje schrijven wie welke domeinnaam heeft? Lijkt me niet het moeilijkste karweitje. Moet daar iemand regelmatig voor op de borrel komen?
ot:
Je doet echt verschrikkelijke aannames in het laatste gedeelte. Waarom?
FYI: Ze komen eens tot maximaal twee keer per jaar langs om ons te informeren en wat casussen waar het niet goed is gegaan door te nemen. Met een uurtje รก 1,5 uur zijn ze weer buiten. Ze komen over de vloer bij providers, zodat ze feeling krijgen met hun klanten (deelnemers).
Verder wil ik hier niet op in gaan. Dit topic is niet bedoeld om SIDN te bashen maar samen te kijken naar hoe het beter kan.
Volgens mij is het momenteel een harde eis aan deelnemers dat ze de kwaliteit van DNS garanderen. Als je klanten toestaat een bij jou geregistreerde domeinnaam in een andere DNS te zetten (wat wij ook doen), dan moet je bij die klanten diezelfde kwaliteitseisen afdwingen.
Vindt dat je daarbij wel praktisch moet blijven.
Als een klant graag zijn .nl domein dat hij bij ons geregistreert heeft, aan de nameservers van bijvoorbeeld een Amerikaanse hoster wilt koppelen, moet dat gewoon zonder beperkingen kunnen.
Wij gaan niet tegen die klant zeggen dat dat alleen mag als het een door ons goedgekeurde "kwaliteitshoster" is, waar we van te voren afspraken mee hebben gemaakt over zaken als "twee weken secondary draaien bij verhuizing".
Ook over de DNS configuratie zelf, en hoe letterlijk je de aanbevelingen uit de verschillende RFCs moet nemen, kunnen de opvattingen verschillen.
Bij sommige TLDs hebben ze bijvoorbeeld de regel dat een CNAME niet naar een andere CNAME mag wijzen.
Maar diensten als "Google Apps" maken daar wel op grote schaal gebruik van, zonder dat dit problemen oplevert.
2) DRS / EPP
Ons tweede voorstel was om DRS / EPP open source te maken. Op die manier kan iedereen zelf de known-errors oplossen waarbij de SIDN natuurlijk wel eisen kan stellen aan de code (bepaalde standaarden, naamconventie etc.).
Op die manier kan iedereen zelf zijn/haar steentje bijdragen en werken we met z'n allen aan een totaalproject. Kostenbesparend en super voor de kwaliteit.
Het lijkt me erg lastig voor SIDN om hun EPP implementatie open source te maken. EPP maakt een webservice naar buiten beschikbaar, maar intern moet het communiceren met het bestaande DRS systeem. Dat zou beteken dat DRS compleet opensource zou moeten worden.
Wat ik me wel kan voorstellen is om een EPP client die kan communiceren met de SIDN EPP service open source te maken. De EPP specificatie voorziet niet in alle berichten, SIDN zal daarom ook custom EPP berichten moeten toevoegen. Dit betekent dat om te kunnen communiceren met een SIDN EPP service, een aangepaste EPP client vereist is.
Ik weet niet of jullie een helpdesk hebben zitten. Als je de kosten van een helpdesk-bezetting afzet tegen de kosten van een proeve van bekwaamheid (kan gewoon online), dan is de laatste toch echt veel goedkoper.
Inderdaad, Microsoft doet dit ook gewoon online. Ik ben voorstander hiervan.
1. Altijd nog netjes twee weken secundaire DNS draaien.
2. Maximaal 1% fouten in DNS-records
3. Maximaal x-keer ten onrechte bezwaar (of helemaal niet)
4. Auth-ID netjes binnen 1 werkdag verstrekken (auth-id's niet verstrekken omdat er niet betaalt is, is helemaal uit den boze)
5. (of tot die tijd) Verhuisverzoeken binnen 1 werkdag verwerken
6. Proeve van bekwaamheid voor alle SIDN-procedures
(Bel je hier dan wel over, dan accreditatie kwijt)
1. Goed plan
2. Als je daarmee doelt op resultaten uit het SIDN DNS verhaal: laat ze dan maar eerst met een goede lijst komen van domeinen met problemen, normaal zag je alleen lame delegations, die hebben wij inmiddens niet meer, maar nog wel 7 minor errors en 39 warnings (directadmin servers), die zou ik ook graag willen oplossen, maar dat is nergens inzichtelijk.
3. Eensch.
4. Onmogelijk: het welles nietes verhaal daargelaten, wat gebeurd er wanneer iemand zegt de houder te zijn, maar dit niet binnen 1 werkdag kan bewijzen (en de registrar dus niet weet of hij het wel of niet is). Daar heb je je 1e uitzondering al.
5. Draagt niet bij aan de kwaliteit/kostenbesparing van SIDN
6. Proef is goed idee, 1x bellen en alles kwijt niet. Zal niet de 1e keer zijn dat SIDN een procedure wijzigt en niemand hier over inlicht.
Dennis, Ik waardeer jullie benadering zeer.
Goede aanpak om op deze manier tot een goede dialoog en kwaliteitsproces te komen. Waarschijnlijk beter dan zo nu en dan "algemene vergadering" met mededelingen over nieuwe regels.
Misschien nu niet te grote stappen zetten nu (moet immers ook haalbaar zijn) maar in ieder geval iets met:
- kwaliteit van het product (dat is wat de eindgebruiker er van merkt)
- kwaliteit van het proces (sneller en efficienter is voor allen goedkoper)
- kwaliteit van de proffesionaliteit (laten zien dat je weet en doet hoe het moet).
Ben heel benieuwd wat er uit gaat komen.
Vr.gr. Eef
Eerste gedeelte wat je noemt: top!
Verder:
Ons tweede voorstel was om DRS / EPP open source te maken. Op die manier kan iedereen zelf de known-errors oplossen waarbij de SIDN natuurlijk wel eisen kan stellen aan de code (bepaalde standaarden, naamconventie etc.).
Prima plan, maar dit zie ik nog niet zo snel gebeuren. Hou er rekening mee dat SIDN veel geld heeft betaald om het systeem te laten ontwikkelen, en wellicht zijn zij daarnaast niet de enige licentiehouder. Natuurlijk werkt het wel kostenbesparend, maar ik denk dat SIDN wel meer dan enkel dat argument zal willen horen om dit daadwerkelijk door te voeren.
Het zou natuurlijk geweldig zijn als het open source zou worden, maar gelet op de werkwijze en houding van SIDN, zie ik dit niet daadwerkelijk gebeuren.
Het zou natuurlijk geweldig zijn als het open source zou worden, maar gelet op de werkwijze en houding van SIDN, zie ik dit niet daadwerkelijk gebeuren.
Het het lijkt me een illusie om te denken dat SIDN de software opensource zal maken, ook al zijn ze zelf volledig de eigenaar van de code.
Dat het opensource maken per definitie zorgt voor kostenbesparing ben ik niet met je eens.
Ook als de software open source zou worden, moet er projectleiding zijn, moet er een infrastructuur opgezet worden, moet er aan ontwikkeld worden, moet de software getest worden enz. Naast de SIDN heeft niemand belang bij de software, de kans dat er externe ontwikkelaars zullen gaan ontwikkelen zal daarom nihil zijn. Daar komt nog eens bij dat de software ontzettend complex is. Er zijn vergelijkbare projecten, zoals bijvoorbeeld het OpenOffice.org project. Dit is ook opensource, maar bijna alle ontwikkeling wordt nog steeds door Sun zelf gedaan.
Als buitenstaander vraag ik me wel af waarom altijd alles zo ingewikkeld moet, waarom niet gewoon een GOED werkend systeem zoals .be en .eu overnemen ipv. constante aanpassingen aan een eigen systeem ?
Het opensource maken van het DRS lijkt me niet geheel verstandig en zal vermoed ik ook weinig bijdragen aan dan wel de kwaliteit dan wel een kostenbesparing, gezien externe code-submits nog altijd gereviewed dienen te worden (quickfix of robuuste fix).
Wat daarentegen veel interessanter is, is om een volledige integratie testsuite te maken, op basis waarvan de koppeling getest kan worden (denk aan hoe dit bijv. voor iDEAL is gedaan). Dit eventueel in samenwerking met default client implementaties in een aantal standaard programmeertalen (hier kunnen brancheverenigingen of providers zelf in springen).