Onderwerp: SIDN onze voorstellen

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.

Oorspronkelijk geplaatst door DennisWijnberg

- 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.

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.

Oorspronkelijk geplaatst door maxnet

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.

Oorspronkelijk geplaatst door WH-Tim

- 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.

Oorspronkelijk geplaatst door WH-Tim

- 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.

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

Oorspronkelijk geplaatst door WH-Tim

- (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!

Oorspronkelijk geplaatst door WH-Tim

- 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).

Oorspronkelijk geplaatst door DennisWijnberg

-

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?

Oorspronkelijk geplaatst door spininhetweb

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.

Oorspronkelijk geplaatst door spininhetweb

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?

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.

Oorspronkelijk geplaatst door spininhetweb

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.

Oorspronkelijk geplaatst door DennisWijnberg

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.

Oorspronkelijk geplaatst door DennisWijnberg

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.

Oorspronkelijk geplaatst door DennisWijnberg

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.