1. No category

Remissammanställning 2015-04-15
Nedan följer en sammanfattning av de synpunkter som inkommit i samband remisser av förslag till
standard för adresser. Arbetsgruppen har analyserat synpunkterna och kommenterat synpunkterna.
Analysen och ställningstagandet ligger till grund för det reviderade förslaget till standard.
Remissammanställningen är en del av dokumentationen av standardiseringsarbetet.
Följande företag har lämnat synpunkter:
Sollentuna Energi, Netnordic, Umeå Energi, Bredband2, Stokab, Bostads AB Poseidon, Eklunds,
Umenet, Lunet, COS Systems, Sunbybergs stadsnät, Lantmäteriet, IP-Only, Kumbro, Netadmin,
Zemware, Stadsnät i Svealand, SABO och Fastighetsägarna.
Synpunkter
Fastighetsägare bör vara en part
Stokab framför att utöver NO, KO och TL bör även fastighetsägare vara en part när fastighetsägaren
själv ansvarar för fastighetsnätet. Fastighetsägaren bör då ansvara för informationen i fälten för
lägenhetsnummer, fastighetsägare och fastighetsbeteckning. Även Kumbro framför att
specifikationen bör skilja på om fastighetsägare eller NO ansvarar för informationen.
Arbetsgruppens kommentar och förslag: Det kan krävas flera nivåer av NO för att erbjuda
bredbandsaccess, exempelvis stadsnät, fastighetsägare och transportnätsleverantörer. KO kan avtala
med flera NO för att etablera ett nät alternativt ansvarar någon NO för andra underliggande nät t.ex.
fastighetsnät. KO ansvarar alltid för alla underliggande relationer i förhållande till TL. Arbetsgruppen
beslutade därför att inte införa fastighetsägare som en särskild typ av NO i standarden.
Unik identifierare för utbyte mellan NO och KO
AcessId är unik identifierare för kommunikation mellan KO och TL. Unik identifierare för
kommunikation mellan NO och KO saknas.
Arbetsgruppens kommentar och förslag: Det finns stora fördelar om NO har en unik identifierare för
avlämningspunkten hos slutkunden i form av outlet (uttagsid). Beslut om att införa outlet som
standard och helst med gemensamt format är ett beslut som måste tas av NO. Arbetsgruppen
rekommenderar att NO alltid har outlet som unik identifierare och inför ett gemensamt format.
Observera att outlet är obligatoriskt vid flera avlämningspunkter på samma adress.
AccessId
Längd och format på fältet behöver utredas. Ska formatet vara valfritt för KO att bestämma?
Arbetsgruppens kommentar och förslag: Olika format som omfattar numeriska värden och
kombinationer med bokstäver och siffror förekommer. Arbetsgruppen bedömer inte att det finns
förutsättningar för standardisering av format för acessId i nuläget. Införandet av fältet coId innebär
att risk för sammanblandning av accessId undviks.
Gatunamn
Bjärekraft. Streetname, det förekommer adresser på landsbygden som saknar både gatu-, gård- eller
byanamn. Därför bör fältet vara option om det inte finns.
Hur ska standarden hantera att postadress ibland skiljer sig från belägenhetsadress? Postadress kan
sakna gatunamn, t.ex. företag med eget postnummer. Alla bostadsentréer, verksamhetslokaler och
1
samlingslokaler har en belägenhetsadress med
gatunamn/byadressområde/gårdsadressområde/metertalsadressområde.
Hur ska standarden hantera accesser till t.ex. mobilbasstationer som endast har koordinater?
Arbetsgruppens kommentar och förslag: Syftet med adressen är att identifiera avlämningspunkt hos
slutkunden. För alla belägenhetsadresser finns information att ange i fältet Streetname. Om
postadressen avviker från belägenhetsadressen som exempelvis för företag med bara postnummer
eller boxadress är det upp till TL och NO att hantera detta separat.
För att hantera avlämningspunkter som saknar belägenhetsadress t.ex. vissa mobilbasstationer införs
fält för koordinater med format enligt SWEREF 99 som överensstämmer med koordinater som anges
i Ceasar 2.
StreetNumber och streetLittera
Både COSystem och Zemware påpekar att många idag har samma fält för gatunummer och littera.
Skillnaden mellan "24" och "25" är samma sak som skillnaden mellan "27 A" och "27 B".
Arbetsgruppens kommentar och förslag: Olika system hanterar idag gatunummer och littera olika.
Oavsett om informationen hanteras i ett eller två fält kommer konverteringar mellan olika system att
krävas. Arbetsgruppen föreslår att två olika fält bibehålls i standarden.
PremisesType
Eklunds. Fältet bör kompletteras med värdena Bostadsrättsförening, Samfällighet, Byalag och
Landsort. Säljprocessen ser helt olika ut för de olika kategorierna. I stan finns etablerade
villasamfälligheter och på landet hjälper ju en del stadsnät t o m i bildandet av byfibersamfälligheter.
Stadsnät arbetar med byalag och vill samla intresseanmälningar från adresser utanför tätorten i en
egen kategori som vi kallat "Landsort", av samma skäl, dvs att sälj- och anslutningsprocessen skiljer
sig.
Stadsnät i Svealand vill att man delar upp MDU_Apartment i BRF och Hyresrätt, samt att man delar
upp Residential_House i Villa och SMF (samfällighet). Uppdelningen motsvarar avtalsrelationen
mellan NO och KO och är viktig för att kunna följa upp statistik i relation till avtalen.
Arbetsgruppens kommentar och förslag: Arbetsgruppen ser inte behovet av att utöka premisesType
med dessa kategorier i kommunikationen mellan KO och TL. Det kan dock finnas behov av ytterligare
uppdelning mellan NO och KO i under kategorier till de redan definierade kategorierna.
Arbetsgruppens förslag är att använda suffix till de definierade kategorierna för att hantera
ytterligare uppdelning. Exempelvis MDU_Apartment_Rented (hyresrätt) respektive
MDU_Apartment_Co_operative (bostadsrätt)
Lägenhetsnummer
Bostads AB Poseidon anser att branschen bör frångå användningen av lantmäteriets
lägenhetsnummer eftersom de kan förändras över tiden. I fastigheterna finns både lägenheter och
lokaler. Lokaler har inte några lantmäterinummer. När lokaler blir en lägenhet eller tvärt om
förändras lantmäterinumret. Det tillkommer nummer för den nya lägenheten. Det kan även påverka
alla lantmäterinummer på hela våningsplanet eftersom lantmäterinummer beskriver lägenhetens
placering på våningsplanen.
Arbetsgruppens kommentar och förslag: Det är besvärligt att lantmäteriets lägenhetsnummer inte är
beständiga över tiden. Syftet med adressinformationen är att när slutkunden kontaktar TL kunna
identifiera ett outlet (avlämningspunkt). Eftersom det varierar vilken information slutkunden har
2
tillgång till behövs fortsatt båda fälten. Om NO alltid använder och märker upp uttag med outlet
(uttagsid/anläggningsid) skulle beroendet av lägenhetsnummer kunna minska.
MDU_Appartment och Residential_House
Lantmäteriet. Det finns fall när båda typerna är uppfyllda:
En lägenhet som är en ägarlägenhetsfastighet och ligger i en byggnad med många lägenheter?
Uppfyller både MDU_APPARTMENT och RESIDENTIAL_HOUSE
En lägenhet i ett radhus där de enskilda lägenheterna ligger på egna fastigheter? Uppfyller både
MDU_APPARTMENT och RESIDENTIAL_HOUSE
Hur bör standarden skilja på dessa typer?
(En ägarlägenhet är en tredimensionell fastighet - det vill säga en fastighet som i sin helhet är
avgränsad både horisontellt och vertikalt - som inte är avsedd att rymma annat än en enda
bostadslägenhet.)
Arbetsgruppens kommentar och förslag: Om det finns lägenhetsnummer (mduApartmentNumber
eller mduDistinguisher) ska premisesType anges till MDU_APPARTMENT. I fallet med ägarlägenheter
bör lägenhetsnummer finnas. I fallet med radhus saknas vanligtvis lägenhetsnummer och bör därför
definieras som RESIDENTIAL_HOUSE. Om lägenheter i villor har lägenhetsnummer ska de klassas som
MDU_APPARTMENT. Se även ovan om premisesType.
Fastighetsbeteckning
Behovet ifrågasätts.
Hur ska fältet hanteras när fastighetsbeteckning saknas? Provisoriska byggnader och byggbaracker.
Vissa byggnader berörs av tredimensionell fastighetsbildning (ägarlägenheter/3D-utrymmen). Detta
innebär att ni kan ha flera accesspunkter med samma adress, men olika fastigheter. Innebär det
något problem?
Arbetsgruppens kommentar och förslag: Även provisoriska byggnader är uppförda på en fastighet
varför fastighetsbeteckning alltid bör finnas. Tredimensionell fastighetsbeteckning är inget problem
men formatet för fältet behöver kunna hantera detta.
Fastighetsägare
Flera ifrågasätter behovet av fältet.
Ett förslag är att det bara är relevant om premisisType inte är ResidentialHouse.
StateOwner bör byta namn till propertyOwner
Fältet ska inte vara obligatoriskt. (Är inte föreslagit som obligatoriskt)
Stadsnät i Svealand anger endast en av fastighetsägarna om det tex. är villaägare.
Arbetsgruppens kommentar och förslag: Information om fastighetsägare är inte relevant när
premisesType är RESIDENTIAL_HOUSE. Fältet är inte obligatoriskt och det är upp till varje NO att
besluta om man väljer att tillhandahålla informationen. Om den tillhandahålls ska den dock hållas
uppdaterad.
3
Population
Motsvarar population ett avtal/prislista? En standardisering av omfattningen på population riskerar
att påverka affärsuppgörelser och hämma olika avtalstyper. Fältet bör därför inte standardiseras
närmare.
Stadsnät i Svealand använder ett separat fält Area som anger del av ort. Är inte kopplat till avtal eller
prislista. Områdesindelning enligt Lantmäteriet (Ex. Haga, Skälby, Irsta osv.)
Arbetsgruppens kommentar och förslag: Arbetsgruppen anser att indelningen i fältet kan variera
mellan olika nät och affärsuppgörelser. En tydligare standardisering bedöms inte möjlig i nuläget.
Däremot måste parterna ha viss eftertänksamhet vid avgränsning och användning av fältet.
Exempelvis:



Man bör undvika en geografisk benämning som kraftigt avviker från den plats där den
aktuella adressen är belägen.
Det är olämpligt att alla byanät i hela Sverige slås samman till en grupp.
Om fältet används för styrning av tjänsteutbud kan det få oönskade konsekvenser t.ex. vid
styrning av regionalt tv utbud.
Arbetsgruppen utökar inte standarden med fältet ”Area” för information om kommundel. Fältet
bedöms inte som nödvändig men kan frivilligt läggas till för de parter som så önskar.
Definition av services
Netnordic. Är det lämpligt att definiera tjänstetyper? Tjänster som t.ex. VoIP och IPTV är något som
TL erbjuder utifrån tekniska egenskaper som erbjuds på förbindelsen som t.ex. multicast och QoS.
Slutsatsen är alltså att istället för att definiera tjänstetyper, som kan variera, bör man istället
definiera ett antal tekniska capabilities istället.
Sundbyberg. När alla tjänster kan levereras på samtliga accesser bör det finnas ett värde som anger
detta.
IP-Only. Accessteknik bör vara ett eget fält om det överhuvudtaget är av relevans att ha med.
Tjänstenamn bör vara tex ”Internet 100/10” eller ”IPTV-VOD”. Huruvida tjänsten kan levereras till
privatperson/företag bör indikeras i separat fält. Vill man specificera detaljerade tekniska egenskaper
bör dessa hämtas genom annat API
Netadmin anser att specifikationen bör delas upp i två delar - adressinformation och levererbara
produkter/tjänster på adress. Vidare bör man överväga att istället för tekniska tjänster benämna
utbudet i form av produkter, för att på så vis särskilja produkten mot den tekniska tjänsten som
realiserar produkten. Detta möjliggör t.ex. att produkten ”Internet 10Mbit” i praktiken kan realiseras
med olika tekniker beroende på tillgängligheten på adressen och att det underliggande systemet
särskiljer mellan tekniska krav och affärsmässiga krav för att kunna leverera en produkt till
slutkunden.
Stadsnät i Svealand anser att detta bör delas upp i fler fält istället för att slå ihop allt i ett, det
underlättar vid export och för att bearbeta och filtrera data. Tex. Capacity (vilken maxkapacitet som
finns på porten), Nettype (vilken nättyp - Layer2 eller Layer3), Tv (vilken typ av Tv-lösning som kan
levereras på porten), Access (Koppar, Fiber, DSL - och då fram till överlämningspunkten, inte
fastighetsnätet för det har vi ingen information om).
Arbetsgruppens kommentar och förslag: I dag förekommer olika sätt att identifiera vilka tjänster som
kan erbjudas på en access. I vissa nät anges bara egenskaper, t.ex. värden för maximal hastighet på
4
access och CPE. Standarden tar sikte på att för varje access tydligt specificera vilka tjänster som
tillhandahålls. Services ska återspegla de tjänster som är avtalade mellan KO och TL. I avtalets
produktspecifikation ska de olika tjänsternas egenskaper framgå. Om olika tjänsteutbud erbjuds
företag och privatpersoner ska det framgå av fältet services vilket produktutbud som är tillgängligt på
aktuellt outlet (avlämningspunkt). Ett fält läggs till som anger vilket medium (koppar, fiber,
wireless…) som accessen levereras via. Information om media är viktig eftersom den underlättar
dialogen med slutkund och vanligtvis innebär olika produktutbud.
ServiceConnection
Eklunds. I marknadsdatabasen anges enbart adresser som är leveransklara. Finns svårigheter att
upprätthålla korrekt information under utbyggnad. Hur hanteras fältet vid ändrat datum för
leveransklar access?
Netadmin Bör inte endast inbegripa nya adresser. Det kan finnas god anledning att skilja på
levererbarhet av produkt/tjänst och levererbarhet på adress på ett tydligare sätt. En adress kan t.ex.
anges som aktiv fr.o.m. ett visst datum under planeringsstadiet av fiberaccess eller YES/NO. Denna
information bör i så fall tillhöra adressdelen och kan kommuniceras innan några produkter/tjänster
presenteras. Huruvida produkten/tjänsten kan levereras och när kan bero på en hel rad andra
tekniska faktorer.
Kopplat till produkten/tjänsten skiljer Netadmin på tidigast leveransdatum och antalet dagar som
krävs för leverans, som t.ex. kan bero på om installation/patchning krävs. Detta förenklar bl.a. för
beställaren att koordinera leveransen med sitt eget flöde. Detta kan även indirekt indikera den tid
som beställaren har på sig att förändra eller avbryta en lagd order.
Stadsnät i Svealand har idag ett datumfält som informerar om när adressen blivit ansluten, vi önskar
inte ändra datum till YES, (för då tappar vi informationen om när i tiden som adressen blivit ansluten)
utan vi tycker det är bättre att man bara fyller i anslutningsdatum.
Arbetsgruppens kommentar och förslag: Fältet anger information om och när tjänsteutbudet enligt
fältet Services kan tillhandahållas av KO till TL. Fältet ska hållas uppdaterat med aktuell information.
Värdet ”YES” anges bara om datum saknas d.v.s. fältet behöver inte byta värde till ”YES” när datum
passeras.
Som några företag indikerat finns kanske ett behov av ett motsvarande fält där NO anger status för
access fram till avlämningspunkt för att KO ska veta när en ny access blir tillgänglig. Efter kontakt
med några KO verkar det inte finnas något större behov och arbetsgruppen väljer att inte införa ett
fält för detta i standarden.
ServiceDisconnection
Netadmin anser i likhet med ServiceConnection att man bör skilja på adress och tjänst.
Arbetsgruppens kommentar och förslag: Se ServiceConnection.
Option82
Sollentuna Energi: I vårt nät produceras option 82-värdet av våra serviceroutrar. I den redundanta
setup vi har finns det två serviceroutrar, och vid failover kommer option 82-värden att produceras
med ett annat hostname från B-maskinen än vad som är normalfallet. Routrarna stödjer inte
möjligheten att båda enheter producerar samma värde i option 82. Möjliga vägar kan vara att 1)
dokumentera att detta kan förekomma i standarddokumentet och bara använda det ena namnet, 2)
definiera hur olika redundanta maskiner ska namnges (exempelvis så att de måste heta –a och –b på
5
slutet och att användaren trunkerar den verkliga strängen vid matchning mot listan) eller 3) ange
samtliga möjliga option 82-värden i fältet som en lista.
IP-Only. I detta förslag ligger option82 på adressnivå, Kan vi vara säkra på att alla KO har option82 per
adress. ComHem API ligger option82 per aktiverad tjänst.
Netadmin. I det typiska fallet skulle detta kunna tillhöra adressen men i det fall flera accesstekniker
kan tillhandahållas kan det ändå vara rimligt att ange detta för respektive produkten/tjänst.
Option82 skulle eventuellt kunna namngivas mer generellt för att täcka andra varianter av teknisk
identifierare.
Zemware. DHCP-Option-82 gäller normalt bara ipv4, då ipv6 normalt använder option-18 för
angivande av accessporten. Fältet ska kanske därför kallas exempelvis "dhcpOptions" istället.
Exemplet har skrivit in hela option82-optionen (inklusive nummer 82/0x52) som hex, vilket ju kan
vara ett lämpligt format för att ha möjlighet att ange andra option-nummer. Man skulle då även
kunna tillåta flera options, antingen lägger man dom bara packade efter varandra (för hex-koden
innehåller ju längd-info för varje option) eller så kanske man ska ha ";" som avskiljare. Då man anger
hex är det således [0-9A-F]+ (plus ev ";") som format, och fältet bör nog vara iallfall 516 tecken, så
ryms en 255-chars option. Jag vill minnas att jag råkat ut för fall där option-82 bara är unikt inom en
viss giaddr/relay-agent, så man kanske ska tillåta att man även anger en giaaddr/ip-adress, t.ex:
"52060101FF0201FF;10.0.0.10". Det kan dock hända att det inte är aktuellt i öppna nät, i så fall kan
man strunta i den möjligheten.
För nättyper där exempelvis bara suboption Remoteid är identifierare, och Circuitid i dhcp-paketet
innehåller tillfällig/föränderlig info (frekvens, signalstyrka etc) så antar jag att man helt enkelt skriver
in option82-hex-koden med endast den relevanta suboption:en angiven.
Arbetsgruppens kommentar och förslag: Fältet byter namn till dhcpOption i stället för Option82
enligt Zemwares förslag.
Idag förekommer att option82 värde tilldelas för varje enskild access eller för varje tjänst på en
enskild access. Arbetsgruppen rekommenderar att ett unikt värde för varje enskild access används.
Enskilda överenskommelser som avviker förekommer och arbetsgruppen bedömer att olika
implementeringar kommer att finnas kvar även i framtiden. Fältet anges därför inte som
obligatoriskt.
I det fall det är möjligt rekommenderar arbetsgruppen att accessId eller outlet anges i en option82suboption. Arbetsgruppen avråder från att använda Option82-värden vars uppbyggnad är hårt
knutna till tillverkare av utrustning.
I den situation som Sollentuna Energi beskriver bör alternativa värden vid ”failover” undvikas. Om KO
inte kan fastställa ett bestående option82 (t.ex. för att detta fastställs först vid tjänsteaktivering) bör
option82 utelämnas. KO och TL måste i dessa fall sinsemellan komma överens om hur denna
information utbytas.
Observera att information vid DHCP uppslag kan förekomma i Option82 även om informationen inte
kan användas.
Nya fält
Fält för kollektivanslutning. NetNordic påtalar att vissa stadsnät har fält för kollektivanslutning av
kunder. Finns behov av att överföra den här informationen till KO eller TL?
6
Arbetsgruppens kommentar och förslag: Efter utredning föreslår arbetsgruppen att ett fält för
kollektivanslutning läggs till i standarden, collectivServices. Fältet ska användas för alla typer av
kollektivanslutna tjänster, exempelvis internetaccess och tv. Alternativet vore att även
kollektivanslutna tjänster anges i fältet Services. För att öka tydligheten och underlätta processerna
vid merförsäljning respektive återgång till kollektivansluten tjänst finns behov av ett separat fält.
Exempelvis om en student i ett studentboende vill köpa en bättre internetaccess än den som ingår i
boendet eller återgå till den tjänst som ingår i boendet. Av benämningen av tjänsterna i fältet är det
önskvärt att det framgår vilken TL som är leverantör av den aktuella tjänsten.
NetType med värdena missing/ layer 1/ layer 2.
Arbetsgruppens kommentar och förslag: Ska framgå av produktspecifikationen.
Meida som anger anslutningsmedia till kundens uttag. Värden xDSL/fiber/WLL (Finns anledning att
skilja på fiber och cat5?)
Arbetsgruppens kommentar och förslag: Läggs till som ett nytt fält.
CapacityPort som anger kapacitet på kundens port t.ex. 100 Mb/s (önskas av flera)
Arbetsgruppens kommentar och förslag: Ska framgå av produktutbudet i fältet Services. Kan idag
finns behov av fältet om information om Services saknas. Om information i det obligatoriska fältet
Services anger vilka produkter som kan levereras saknas behov av ett fält som anger kapacitet på
porten.
CapacityCPE som anger kapacitet i kundens utrustning t.ex. 100 Mb/s. (önskas av flera)
Arbetsgruppens kommentar och förslag: Ska kunna härledas via cpeType. Även om maxhastighet
framgår av CPE specifikationen kan maxhastighet anges som ett suffix till CPE beteckningen om det
efterfrågas.
TvStatus som anger under vilka förutsättningar en tv-ström kan levereras eller ej.
Arbetsgruppens kommentar och förslag: Ska framgå av produktutbudet i fältet services i likhet med
förslaget om CapacityPort.
Acesstyp som eget fält i stället för del av services (Företag/Privat/Båda)
Arbetsgruppens kommentar och förslag: Ska framgå av produktutbudet i fältet services.
Building name. Används i det fall en SDP (adress) inte kan anges enbart med nummer utan kräver
namn på byggnad eller kombinationen av båda, exempelvis ”Tvättstugan” eller gårdsnamn.
Gårdsnamn kan även förekomma i kombination med metertalsadresser.
Arbetsgruppens kommentar och förslag: I det fall flera uttag finns på samma adress ska outlet
särskilja olika uttag (avlämningspunkter).
Level. Motsvarar våning eller motsvarande. Återfinns även hos Skanova för sökning av kopparaccess.
Exempelvis ”BASEMENT” eller ”F”.
Arbetsgruppens kommentar och förslag: I det fall flera uttag finns på samma adress ska outlet
särskilja olika uttag (avlämningspunkter).
Street type, Street suffix och Dependency street. Eventuellt inte fullt tillämpbara i det svenska
formatet. Kombinationen används internationellt för att beskriva bl.a. metertalsadresser eller
korsningar. Exempel: Street suffix=East (riktning) och Street number=240 (avstånd).
7
Arbetsgruppens kommentar och förslag: Arbetsgruppen har i samråd med NetAdmin, som föreslog
fältet, inte identifierar ett direkt behov att ange adresstyp för svenska adresser.
Andra fältnamn
services / connection och service /disconnection borde istället heta servicesConnection och
servicesDisconnection
koId bör byta namn till coId. Övriga fält har engelska namn.
Arbetsgruppens kommentar och förslag: Fältnamn ändras enligt förslag.
Leveranssätt för tjänst
Det finns inget fält som indikerar leveransmodell för tjänsterna; om det är free seating eller
portmappade accesser.
Arbetsgruppens kommentar och förslag: Införs som obligatoriskt fält. Free seating är en vanligt
förekommande benämning men bör snarare benämnas ASAP (Any Service Any Port)
Fält för landskod
Behövs fältet för landskod? Övriga adressfält är inte anpassade för att kunna hantera adresser i
andra länder. Exempelvis måste fältet för postkod vara längre.
Arbetsgruppens kommentar och förslag: Vissa system kräver information om landskod men fältet
ändras från obligatoriskt till frivilligt.
Hantering av uppdateringar
Hur bör uppdateringar av information hanteras? Enbart förändringar eller all information? Bör även
processen för uppdateringar standardiseras?
Sollentuna Energi producerar idag ”deltalistor”, d.v.s. utdrag ur vår adressdatabas på vad som har
förändrats sedan en tidigare körning. Dessa består av en adressrad samt en lista på vilka fält som har
uppdaterats sedan föregående körning. Detta har efterfrågats av operatörer som inte haft möjlighet
att läsa in hela adresslistan på nytt, format för detta kanske också är värt att lägga till i standarden?
Stokab ställer sig tveksam till SSnf´s förslag att den part som är ansvarig för informationen även ska
ha ett ansvar att meddela andra parter om informationen förändras och uppdateras med undantag
för uppgift ändras till följd av ändrad affärsrelation. Exempelvis byter fastigheter i Stockholm ofta
ägare utan att ansvar eller bredbandsleveransen påverkas. Stokab anser att ansvarsfrågor ska
utelämnas då ansvaret skiljer sig åt beroende på affärsmodell.
Netadmin anger för varje enskild adress när denna senast uppdaterades genom ett specifikt
datumfält. Detta möjliggör effektiv kommunikation av ändringar mellan parter eller interna system.
Vissa läsare har missuppfattat att all information ska utbytas mellan alla parter. Informationsflödet är
NO till KO, KO kommunicerar med TL respektive tvärt om.
Arbetsgruppens kommentar och förslag: Hur information ska uppdateras bör vara upp till varje
avtalsrelation och systemimplementation. Arbetsgruppen anser inte att standarden bör omfatta hur
information ska hållas uppdaterad.
För att underlätta implementering införs ett fält (lastUpdate) som anger när information senast
uppdaterades.
8
Införande av standard
Hur bör standarden införas?
Vissa obligatoriska fält kommer att ta längre tid än andra att uppdatera med information. Exempel på
sådana fält är lokaltyp, fastighetsbeteckning och lantmäteriets lägenhetsnummer.
Arbetsgruppens kommentar och förslag: Arbetsgruppen har förståelse för att införande av standard
och uppdatering av information kan ta tid. Införandet är upp till respektive avtalsrelation och
systemimplementation.
Frågor
1. I förslaget definieras vissa fält som obligatoriska och vilken part som ansvarar för
informationen. Ansvarig har även ett ansvar att meddela andra parter om informationen
förändras och uppdateras. Finns synpunkter på om fält ska vara obligatoriska eller ej? Är rätt
part utpekad som ansvarig?
Lunet. Hur ska outlet användas i framtiden med fiberbaserade lägenhetsnät? Påverkar detta
fältet.
Netadmin har generellt inga synpunkter på vilken part som ansvarar för olika information
med undantag för AccessID. NETadmin kommer dock alltid att tillhandahålla ett
automatgenererat unikt ID för varje enskild adress per system (installation). Detta ID kan
likställas med AccessID. I annat fall bör AccessID tillhandahållas av KO från
ursprungsdatabasen.
Arbetsgruppens kommentar och förslag: Fiberbaserade lägenhetsnät bör inte påverka fältet.
Det anger en förbindelse fram till en avlämningspunkt. Även vid fiberbaserade fibernät finns
troligen endast en avlämningspunkt i lägenheten.
2. Fråga till nätägare. Har ni ett i ert nät ett unikt accessid för access/avlämningspunkt/uttag
som är beständigt över tiden? Om det finns, vilket format har ert accessid?
Sollentuna Energi har ett accessid och använder ett löpnummer. Exempel: 1010304. Detta
löpnummer har genererats av en räknare och har inga kopplingar mot övriga system eller
verksamheter hos oss.
Bjärekraft, saknar accessid.
Umenet - anläggningsnummer i följande format 8-11 siffror t ex 20000011523. Bredband
börjar alltid på 2… och tv 25…..
Lunet - använder AdressID som accessID. Vårt AdressID är en unik identifierare per
levererbar adress. Består endast av siffror.
Kumbro, Förutom adressuppgift finns Id, ev Stativ, ODF, kontaktnr (ex: ID: AP-123, Stativ:
S02, ODF: M37, kontakt: 3+4, skrivs: AP123 S02 M37 3-4).
9
NETadmin tillhandahåller ett unikt ID för varje enskild adress per system/installation som är
beständigt över tiden. Detta format är ett numeriskt värde om 32 bitar. Detta är alltså inte
unikt per KO i det fall denna har flera installationer av NETadmin. Därför tillhandahåller
NETadmin andra fält som specifikt kan användas för unikt identifiera en adress i en KO:s
bestånd.
Zemware tycker att [0-9a-zA-Z.-]+ skulle kunna utökas med "_" underscore.
Arbetsgruppens kommentar och förslag: Se ovan om unik identifierare för utbyte mellan NO
och KO. Möjliga tecken utökas med ”_”.
3. Fält för streetName, streetNumber och streetLittera föreslås användas gemensamt för de
olika typerna av adresser; gatuadresser, byadresser, gårdsadresser och metertalsadresser.
Finns negativa effekter av att inte skilja på dessa adresstyper?
COS Systems – flera nätägare använder samma fält för streetNumber och streetLittera
Kumbro - Fångar man även t ex mobilsite placerad vid en större väg t ex E20, mitt uti skogen
på detta sätt? Ofta är dessa koordinatsatta och inte har någon gatuadress.
Netadmin bedömer att streetNumber kan inbegripa metertalsadresser i Sverige, t.ex. ”24-6”.
4. För fältet premisesType föreslås fem olika värden. Är förslaget väl avvägt?
Se ovan. Övriga som kommenterat ansett det väl avvägt.
Om värdena MDU_Technical eller OTHER borde kanske mduDistinguisher identifiera våning
eller motsvarande då det kan finns tekniska utrymmen på olika våningsplan i fastighet.
Netadmin har inga synpunkter på alternativen men noterar att typen av adress är kopplad till
krav på information som måste anges
Arbetsgruppens kommentar och förslag: Arbetsgruppen föreslår att olika uttag när
premisesType är MDU_Technical eller Other bör särskiljas via olika uttagsid.
5. Hur ser ni på behovet av fältet fastighetsägare (stateOwner)? Hur bör formatet utformas för
att hantera flera ägare till samma fastighet?
Sollentuna Energi, Bjärekraft – ser inget behov
COS Systems ser behov av fältet
Lunet. I NetAdmin finns endast ett fält för fastighetsägare. Vid fall av fler än en
fastighetsägare måste informationen in i samma fält. Frågan är också hur denna information
skall kunna hållas aktuell?
Kumbro - bör ej finnas med då det kan hämtas via fastighetsbeteckning
10
Arbetsgruppens kommentar och förslag: Se ovan under fastighetsägare.
6. Fältet population är avsett för att inom en kommunikationsoperatör hantera olika priser eller
styra kunder mot olika portaler. Ser ni ytterligare behov? Idag varierar hur grov eller fin
uppdelning NO eller KO använder. Hur bör en standard styra uppdelningen?
Sollentuna Energi – ser inget behov
Flera anser det svårt att standardisera och eventuellt även olämpligt eftersom det styrs av
affärsrelationer, se ovan.
Netadmin har förstått att fältet möjligtvis ger en något förenklad bild, då det kan finnas
avtalsrelaterad information kopplad till ett bestånd. Vi har dock inga direkta synpunkter på
hur indelningen ska se ut
Arbetsgruppens kommentar och förslag: Se ovan under population.
7. Fältet services är avsett att definiera vilka tjänster som kan tillhandahållas på den aktuella
accessen. Hur bör formatet på fältet utformas?
Kan standardkategorier definieras för att minska omfattningen på fältet?
Ibland kan fler än en teknisk tjänst erbjudas ex både fiber och DSL. Hur ska det hanteras?
Hur hanterar man välfärdsbredband(Larm, Omsorg mm), kapacitet(olika tjänster, MEF), olika
SLA mm. Blir en komplex matris för kombination av detta. I synnerhet om det levereras
tjänster i en switch/CPE i olika portar.
Arbetsgruppens kommentar och förslag: Se ovan under definition av services.
11