Re: [Isis-wg] Latitude/Longitude Granularity in

"Acee Lindem (acee)" <> Thu, 24 August 2017 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1573613295E for <>; Thu, 24 Aug 2017 06:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BccAOL3eACtL for <>; Thu, 24 Aug 2017 06:33:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04597132944 for <>; Thu, 24 Aug 2017 06:33:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7480; q=dns/txt; s=iport; t=1503581608; x=1504791208; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JPWuVPOROBcFqAaNAWpuwwZ5q7WGys7f1VRobT0yz4s=; b=FtoO3RYptgnp/A1QwCX/e0aFu2skYI/qVgHSW/4WgyiOoAgSMlb07UN0 EjqFMq9Csl84r9pXNhmreDk52HDoAyZ+R2HwxmxcaovcVJAsEZX8X807m AuodqDx0zLhL1fvF0Ejcd2kHchu79PXbnRKxM72vMzXGRKUmuLphG1YgD g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.41,421,1498521600"; d="scan'208";a="290446659"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Aug 2017 13:33:27 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v7ODXRlZ005218 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Aug 2017 13:33:27 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 24 Aug 2017 09:33:26 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 24 Aug 2017 09:33:26 -0400
From: "Acee Lindem (acee)" <>
To: Peter Lothberg <roll@Stupi.SE>
CC: "" <>
Thread-Topic: Latitude/Longitude Granularity in
Thread-Index: AQHTHB7+oNaPq5QcWkq+45hfgHbw2KKTgtsA
Date: Thu, 24 Aug 2017 13:33:26 +0000
Message-ID: <>
References: <> <CMM.>
In-Reply-To: <CMM.>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Isis-wg] Latitude/Longitude Granularity in
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Aug 2017 13:33:31 -0000

Hi Peter, 

Thanks for your detailed response. One thing we decided since my original
query was to move the YANG geo-location type out of the
ietf-routing-types.yang model since we thought that we didn’t have enough
review and experience to model it correctly. We are going to put it in a
separate YANG model and, based on your response, there may be more than
one YANG type. 

We will be discussing this in the future.


On 8/23/17, 10:40 AM, "Peter Lothberg" <roll@Stupi.SE> wrote:

>I missed this message as it was just text encoded, no attachments, my
>obsolete mail ui can't handle it...
>>Hi Peter,
>>We wanted to assure that milliseconds of latitude/longitude offer
>>enough granularity for your applications. This slightly more than 3
>>cm granularity for latitude and slightly less the 3 cm granularity
>>for longitude. 
>We have Geo coordinates to form a graph over the network, from cables
>and ducts in the ground to the wiring inside a CO/POP/Datacenter.
>As Vint Cerf says we need to bring IPv6 to the planet as soon as
>March, what we need to future proof this is a format that allows for
>the following;
>([Galaxy,Solar System,Planet],)* [Operator], [World], [Lat, Long,
>Height], [Time of Observation UTC in MJD with decimals]
>  (MJD - Modified Julia Date)
>  (Operator is the originator/maintainer of the data.)
>The proposal is a good start but you lack some important things;
> - You need to be ale to express arbitrary resolution for Lat/Long.
>   Depending on the use, you might want to truncate the resolution to
>   not reveal the exact location of infrastructure, and then again you
>   may want to express exactly where things are.
>   You need to be able to express what we can measure for lat/long
>   as an example, so you have to be able to represent this in your
>   format:
>      LAT 59.317647949 North
>      LON 18.023390835 East
>- When it comes to height, we really have a problem;
>  - Different countries have different ways of measuring the "sea
>    level".
>  - The sea level are rising
>  - The land is also rising, like our Stockholm location is moving
>    about 11mm up and 7mm NE in average every year, so you need to
>    have a date on the observation of the position.
>  - The local observations have different ages
>  - GPS presented height is done with a theoretical model of the earth
>    and calculated based on the distance from the GPS satellite.
>   (Neighboring countries in some cases have more than 100cm
>    difference in their definition of sea level.)
>Height is a signed value, 1mm resolution, with a source identifier
>(you need way to add new identifiers for the future);
>       - WGS84
>       - Local official survey
>       - Local height (maybe from basement of building)
>       - Local sequence number
>- In some cases you want to describe something other than the natural
>  itself. e.g., a VPN described as a flat plane, or military / private
>  tectical graph that is a different "plane" / "overlay" etc.
>  So we ended up with a Integer that represents the "world" you are
>  describing and the vale of 0 represent the natural world we all live in
>  and have as a common reference.
>(*) - The astronomers refers to planets in our solar system with a
>coordinate system with the sun as 0,0,0. Everything moves, continental
>drift to ephemerides of planets and satellites. I chose to leave those
>models out of scope as there is enough data in the proposed format to
>go to other sources and augment the positions.
>> --_000_D576E8B0B65A3aceeciscocom_
>> Content-Type: text/plain; charset="utf-8"
>> Content-Transfer-Encoding: base64
>> DQoNClRoYW5rcywNCkFjZWUNCg==
>> --_000_D576E8B0B65A3aceeciscocom_
>> Content-Type: text/html; charset="utf-8"
>> Content-ID: <>
>> Content-Transfer-Encoding: base64
>> bD4NCg==
>> --_000_D576E8B0B65A3aceeciscocom_--