AccessId Längd och format på fältet behöver utredas. Ska formatet vara valfritt för KO att bestämma?

Transkript

1 Remissammanställning 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

2 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

3 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

4 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

5 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

6 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: " FF0201FF; ". 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 option82- suboption. 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

7 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

8 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

9 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: 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 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

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

11 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