Remissvar IIS 2006-R1, Nytt Produktionssystem

The II-Foundation that is responsible for the .SE domain has requested input on some questions. Unfortunately the questions and therefore my response are in Swedish. Interested people can though find the questions here and my response below.

Härmed svaras på remiss 2006-R1, Nytt Produktionssystem

Först vill jag tacka IIS för den nya öppna remissprocessen vilken jag är säker till kommer leda till dels en för domännamnsinnehavarna ökad tillit till .SE, dels möjlighet för IIS att få in synpunkter från de för IIS okända kunniga som finns i Sverige.

Sedan till remissen i sig.

Till att börja med anser jag att den copyright som finns på dokumentet är olycklig:

Detta innebär för mig att det är svårt att tipsa om detta till de som inte känner till remissomgången. Att IIS dessutom skriver:

Innehållet i detta dokument kan ändras utan föregående meddelande. II-stiftelsen ansvarar inte för eventuella felaktigheter i detta dokument.

Det gör det ännu mer “intressant” vad gäller möjligheten att svara och senare försvara sina åsikter.

Jag föreslår en mjukare copyright, och ett tydligare ställningstagande att just remissdokument 2006-R1 aldrig kommer att ändras. Om en ny version behövs kan det ha ett annat namn. Annars blir hänvisningen till dokument svår.

I avsnitt 1.1 skriver ni:

Observera att de parametrar (antal dagar, veckor, maxantal och liknande) som anges under respektive avsnitt enbart är förslag och kan komma att ändras.

Innebär detta att synpunkter på dessa värden inte kommer beaktas, att ni har en annan process för att bestämma dessa, eller? Det är förvirrande att ni samtidigt vill ha in synpunkter på innehållet i 2006-R1 som ni säger att parametrar kan ändras “hur som helst”. Dessa är vid drift av DNS minst lika viktiga som andra delar av processen, och bör alltså inte särbehandlas. Det gör det dessutom svårt att svara på frågor som 4.2 om remissbegäran inleds med text som denna.

I avsnitt 1.2 använder ni flera olika ord för samma betydelse. Tex Registrant och Innehavare. Ni bör använda enbart en term, och då den som ni anser vara den mest vedertagna. Annat exempel på förvirring är NSP, Name Service Provider och DNS-Operatör.

I avsnitt 1.3 beskriver ni att IIS har hand om registrering av “Internetdomännamn”. Är det något annat än “domännamn” vilket är en liknande term som finns i andra delar av dokumentet?

Fråga 2.1: Ser ni något problem med att II-stiftelsen hanterar personuppgifter för privatpersoner och enskilda firmor på ovanstående sätt?

Nej, jag ser inga problem med detta.

Fråga 2.2: Har ni några synpunkter på det föreslagna förfarandet med hänvisning till webbapplikation för att få utförligare information?

Nej, om hänvisningen sker på ett sätt som överrensstämmer med det sätt som hänvisningar sker i andra TLD-innehavares whois-tjänster baserade på whois-protokollet. Speciellt som hur hänvisningar ska ske inte finns som del i whois-protokollet. Det är viktigt att meta-whois-tjänster fortfarande kommer fungera.

Fråga 2.3: Anser ni att en captcha-lösning är en lämplig metod för att försvåra automatisk nerladdning av registret?

Ja, vid “web”-access. Den enda fungerande framtida lösningen är dock att gå över till CRISP och tex protokollet IRIS.

Fråga 2.4: Vilka för- respektive nackdelar ser ni med förslaget?

Det är viktigt att de tekniska parametrar som behövs för DNS-drift, vilket inkluderar information om huruvida domännamn är registrerat (och delegerat) eller inte alltid finns åtkomligt i maskinläsbart format.

Annars inga ytterliggare kommentarer.

Fråga 3.1: Har ni några synpunkter på att II-stiftelsen går från kontroll av DNS-data vid nyregistrering och ändring till mer löpande och kontinuerliga kontroller?

Det verkar som om IIS ska gå ifrån kontroll vid registrering och ändring, och detta anser jag INTE ska ske. Istället bör ändringarna ökas till att även inkludera kontroller under normal drift.

Fråga 3.2. Har ni några andra synpunkter på att II-stiftelsen hanterar DNS-data enligt det förslag som beskrivs ovan?

Nej, men det är viktigt att det diskuteras vilka tester som ska göras, och vilka regler som ska gälla för bedömningen som IIS gör.

Fråga 3.3: Vilka för- respektive nackdelar ser ni med förslaget?

Detta kommer leda till högre kvalitet på information i .SE vilket är bra.

Nackdelar har att göra med vilka tester som görs, och vilka följderna blir om inte förslag till ändringar görs.

Fråga 4.1: Vad anser ni om att ta bort karantänsperioden och förlänga deaktiveringsperioden enligt ovanstående förslag?

Bra förslag.

Fråga 4.2: Är den föreslagna längden för deaktiveringsperioden rimlig?

Ingen åsikt.

Fråga 4.3: Vilka för- respektive nackdelar ser ni med förslaget?

Att ha färre antal tillstånd ger ökad tydlighet, vilket IIS redovisar.

Fråga 5.1: Anser ni att den föreslagna tjänsten har förutsättningar att uppfylla syftet och leda till bättre service till privatpersoner?

Nej.

Fråga 5.2: Vad anser ni om tjänsten Bokning enligt den föreslagna modellen?

Ytterst dålig. Den innebär i praktiken att IIS åtar sig hålla kredit för ombuden, en funktion som jag inte anser att IIS ska ikläda sig. Istället är detta en tjänst som ombuden redan kan ge domännamnsinnehavarna, och flertalet redan ger dem.

Det ökar risken för ohederlig hantering av domännamn från ombudens sida, då bokning och senare avbokning kan användas på ett sätt som det inte ursprungligen var tänkt.

Fråga 5.3: Anser ni att de föreslagna tidsfristerna maximal bokningstid 14 dagar respektive 30 dagar spärr för ny bokning är rimliga?

30 dagar spärr för ny bokning kommer i praktiken ej gå att kontrollera, och därför bör bokningsfunktion ej implementeras. Om bokningsfunktion implementeras bör det ej finnas en spärr för ny bokning.

Fråga 5.4: Anser ni att det är rimligt med en maxgräns för antalet samtidigt bokade domäner per ombud? Hur stor anser ni att den maxgränsen bör vara?

Då det inte kommer att gå att implementera en maxgräns i praktiken anser jag någon sådan ej ska införas om bokning ska införas. Men, detta är dock ytterliggare en anledning till att bokning som tjänst ej ska införas.

Fråga 5.5: Vilka för- respektive nackdelar ser ni med förslaget?

Enbart nackdelar. Se ovan.

Fråga 6.1: Har ni några synpunkter på de rättigheter som de olika kontakterna tilldelas enligt ovanstående förslag?

Först och främst är det viktigt att objekten som motsvarar dessa roller kan “logga in” och se information om alla de domännamn som de tex är Admin-C för. Som idag att behöva ändra kontaktuppgifter för sig som innehavare av domännamn på ett ställe för varje domän visar sig inte fungera i praktiken.

DNS-Operatör finns inte med i tabellen. Anser ni detta vara samma sak som Tech-C eller ytterliggare en roll? Detta måste klargöras.

Admin-C bör kunna göra en förnyelse av domän.

Fråga 7.1: Har ni några synpunkter på att inloggningsuppgifter för kundkonton hanteras enligt beskrivningen ovan?

Användaren kan också välja att få inloggningsuppgifterna skickade via post till angiven adress.

A. Vad menas med “angiven adress” i denna mening? Är det information som redan finns i IIS register, eller en adress som anges på webbsida?

Om e-postadressen dit inloggningsuppgifterna skickas av någon anledning inte längre är aktuell kan kontohavaren uppdatera den genom att fylla i och underteckna en särskild blankett framtagen för ändamålet.

B. Kan denna skickas via mail? Faxas?

För att nå en högre säkerhetsnivå föreslås en kontakt också ha möjlighet att använda sig av certifikatbaserad inloggning. Väljer användaren certifikat ersätter det användarnamn och lösenord.

Hur hanteras ändring av mailadress men fortfarande fungerande certifikat? Vilket har företräde? Hur hanteras utgånget certifikat men fungerande mailadress? Kan detta certifikat även användas vid mailkonversation? Kommer även IIS använda certifikat vid kommunikation med kontakt? Vilka CA kommer användas? Kommer både X.509v3 och PGP hanteras? Kommer IIS själva ställa upp som CA resp. signerare av PGP-nyckel? Finns det möjlighet att själv få signera IIS PGP-nyckel?

Fråga 7.2: Vilka för- respektive nackdelar ser ni med förslaget?

Generellt en ändring i bra riktning, men en tydligare beskrivning behövs för att göra (tekniska) bedömningar av förslaget.

Fråga 8.1: Har ni några synpunkter på vilken metod som är den mest lämpade för hantering vid frisläppande av domännamn?

Då de olika förslagen ej är beskrivna går det ej att göra en bedömning av dem.

Generellt kan sägas att först till kvarn ihop med en förlängd inledning med inslag av lotteri och tystnadsperiod är det enda som visat sig fungera internationellt. Så, detta är det som jag föreslår.

Fråga 8.2: Ett auktionsförfarande kan förväntas generera ett överskott. Vad anser ni att ett sådant eventuellt överskott bör användas till?

Detta är en av anledningarna till att auktion ej bör användas.

Patrik Fältström