Subject: [geonet/its] challenges proposed by Dimitri

From: <[email-masked]>
Date: Mon, 6 Jan 2014 10:21:17 +0000

Hi Dimitri,

Thank you very much!
The questions that you have listed below are very useful and therefore I am forwarding your email to the its list!

Actually, I agree with the challenges that you described and I will try to integrate them in what we have up to now:

1. How can a geographic area be "represented", since several IP locators can give access to it.

2. which resolution mechanism can be used at the source node e.g. Geo-locator (name)/ Geo-Physical coord.(addr.) to IP locator

3. which resolution mechanism can be used at IP locator (or edges) if packets would have to transit non IP islands e.g. Geo-locator (name) to Geo-Physical coord.

4. what is the rate and size of the records populating the resolution database

5. at which level of "stack" this information has to be inserted such that intermediate nodes can successfully reach the destination as expected by the source.

Best regards,
Georgios

From: Papadimitriou, Dimitri (Dimitri) [mailto:[email-masked]]
Sent: zaterdag 14 december 2013 23:56
To: Karagiannis, G. (EWI)
Subject: RE: the uncrisp problem

Hello,

Reading all the discussions, I wonder why there is no item discussing the following points:

At the network wide level

- Geo-locators (naming the geographic area) vs Geo-physical coordinates (the actual coordinates of that area)

Have the same relationship as

- IP network locators vs none (known as of today)

Note however at the local level there is distinction between IP address (logical) and e.g. MAC address (physical)

Thus there is first a question 1. what a geographic area "represents" because several IP locators can give access to it.

Then the "base" problem stems as follows

2. which resolution mechanism at the source node e.g. Geo-locator (name)/ Geo-Physical coord.(addr.) to IP locator

3. which resolution mechanism at IP locator (or edges) if packets would have to transit non IP islands e.g. Geo-locator (name) to Geo-Physical coord.

4. what is the rate and size of the records populating the resolution database

5. at which level of "stack" this information has to be inserted such that intermediate nodes can successfully reach the destination as expected by the source.

Thanks,
-dimitri.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Jan 2014 12:33:46 +0100

Hi Georgios,

You are asking for feedback.

I have some thoughts on this.  Far from me any intention to complexify
things.

I will be happy to read others' remarks.

Le 06/01/2014 11:21, [email-masked] a écrit :
> Hi Dimitri,
>
> Thank you very much!
>
> The questions that you have listed below are very useful and
> therefore I am forwarding your email to the its list!
>
> Actually, I agree with the challenges that you described and I will
> try to integrate them in what we have up to now:
>
> 1. How can a geographic area be “represented”, since several IP
> locators can give access to it.

An area could be represented by the coordinates of some of the points on
its perimeter, or other description of point coordinates and shape
identifier.  A volume description would have more possibilities.  One
should also consider maybe the projection alternatives.

> 2. which resolution mechanism can be used at the source node e.g.
> Geo-locator (name)/ Geo-Physical coord.(addr.) to IP locator

Yes, resolution mechanism may be needed.

But, we currently know two kinds of resolution:
- IP address <-> MAC address (ND)
- IP address <-> name (DNS)

With geonet we'd talk new identifiers like geographical coordinates.  If
we talked only one such coordinate (say 'latitude'), then we'd need 3
new resolution mechanisms:
- IP address <-> latitude (protocol IPL)
- MAC address <-> latitude (protocol MACL)
- name <-> latitude (protocol NL).

Maybe the latitude is not sufficient, so we'd need longitude and
altitude as well.  This would give a total of 9 new resolution protocols.

On another hand, one may think of combining the lat/long/alt into a
single identifier.  That may appear simple at first sight, but may have
its own difficulties, one of which being the necessity of the
representation of precision (HDOP, VDOP).

Not to mention the difficulty of coming up with an agreed way of
representing one single geographical coordinate (it's not because
everybody talks GPS now that someone will not talk Baidou tomorrow, as
an example).  If I want to locate all the IP sensors of water level
measurements where I live I am not able to use the GPS coordinates, I
must use coordinates using the Lambert projection (just another example).

Yes, I am told conversion tools exist (e.g. same GNSS chipset outputs
both GPS and Galileo data, using an internal conversion).  But then the
question is whether we need conversion tools or resolution tools
(protocols).

Alex

> 3. which resolution mechanism can be used at IP locator (or edges)
> if packets would have to transit non IP islands e.g. Geo-locator
> (name) to Geo-Physical coord.
>
> 5. at which level of “stack” this information has to be inserted
> such that intermediate nodes can successfully reach the destination
> as expected by the source.
>
> Best regards,
>
> Georgios
>
> *From:*Papadimitriou, Dimitri (Dimitri)
> [mailto:[email-masked]] *Sent:* zaterdag
> 14 december 2013 23:56 *To:* Karagiannis, G. (EWI) *Subject:* RE:
> the uncrisp problem
>
> Hello,
>
> - Geo-locators (naming the geographic area) vs Geo-physical
> coordinates (the actual coordinates of that area)
>
> Note however at the local level there is distinction between IP
> address (logical) and e.g. MAC address (physical)
>
> Thus there is first a question 1. what a geographic area
> “represents” because several IP locators can give access to it.
>
> Then the “base” problem stems as follows
>
> 2. which resolution mechanism at the source node e.g. Geo-locator
> (name)/ Geo-Physical coord.(addr.) to IP locator
>
> 3. which resolution mechanism at IP locator (or edges) if packets
> would have to transit non IP islands e.g. Geo-locator (name) to
> Geo-Physical coord.
>
> 5. at which level of “stack” this information has to be inserted
> such that intermediate nodes can successfully reach the destination
> as expected by the source.
>
> Thanks,
>
> -dimitri.
>
>
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 8 Jan 2014 09:23:12 -0700

Alex -

A very common practice in the land management community is to create a 
unique parcel identifier based on the coordinates of the centroid of the 
parcel. The approach generates a single PIN based on lat/long, which in the 
use case below reduces the number resolution mechanisms.

http://www.hendersoncountync.org/ca/howpins.html

Shows an example. They use state-plane but a similar approach could be used 
for lat/long coordinates.

And you also raise the question of coordinate reference systems (CRS) and 
the requirements perhaps to transform between CRS (also known as 
re-projection). Regardless of the approach this group decides to follow, at 
a minimum the documentation needs to be very clear on the CRS of the 
coordinate(s) being used. Simply stating lat/long is unclear and can 
actually result in significant absolute location errors depending on the 
geoid used for a given lat/long pair. The existing location object (LO) 
definition used in PIDF and a number of other RFCs very clearly states the 
relevant EPSG code for the CRS being used. The approach for specifying a CRS 
is defined by ISO and the OGC in a variety of documents.

The above may seem a trivial point, but ambiguity in the specification of 
the CRS for a coordinate set can lead to a number of issues in terms of 
visualization, analysis, fusion, analytics and so forth.

Cheers

Carl

-----Original Message----- 
From: Alexandru Petrescu
Sent: Wednesday, January 08, 2014 4:33 AM
To: [email-masked] ; [email-masked]
Cc: [email-masked]
Subject: Re: [geonet/its] challenges proposed by Dimitri

Hi Georgios,

Alex

> [email-masked] https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/its

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 8 Jan 2014 10:33:14 -0800

Yes, but in this case, you need some other value to determine boundary. Because the center of your property can include me your neighbor if you don't have that other boundary. So radius, triangulation, or four sets of geo-coordinates are necessary. 

And I would argue some properties are not just hexagons, but octigons or nonagons as well. Depends on the granularity you want or need.

Dino

On Jan 8, 2014, at 8:23 AM, Carl Reed <[email-masked]> wrote:

> Alex -
> 
> A very common practice in the land management community is to create a unique parcel identifier based on the coordinates of the centroid of the parcel. The approach generates a single PIN based on lat/long, which in the use case below reduces the number resolution mechanisms.
> 
> Shows an example. They use state-plane but a similar approach could be used for lat/long coordinates.
> 
> And you also raise the question of coordinate reference systems (CRS) and the requirements perhaps to transform between CRS (also known as re-projection). Regardless of the approach this group decides to follow, at a minimum the documentation needs to be very clear on the CRS of the coordinate(s) being used. Simply stating lat/long is unclear and can actually result in significant absolute location errors depending on the geoid used for a given lat/long pair. The existing location object (LO) definition used in PIDF and a number of other RFCs very clearly states the relevant EPSG code for the CRS being used. The approach for specifying a CRS is defined by ISO and the OGC in a variety of documents.
> 
> The above may seem a trivial point, but ambiguity in the specification of the CRS for a coordinate set can lead to a number of issues in terms of visualization, analysis, fusion, analytics and so forth.
> 
> Cheers
> 
> Carl
> 
> 
> -----Original Message----- From: Alexandru Petrescu

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 8 Jan 2014 16:44:21 -0700

Dino -

Thanks.

I was suggesting an approach to uniquely identify a location without having 
to use lat-long coordinates. The issue of a "boundary" is different. FYI, a 
boundary of three of more non-intersecting sides/edges (in GIS) is a 
polygon. All treated the same. ISO 19107:Spatial Schema provides a set of 
mathematical definitions for various types of 2d and 3d geometry. We use 
these definitions in the OGC - as does OASIS, NENA, and a number of other 
standards organizations that work with geometry and location.

Cheers

Carl

-----Original Message----- 
From: Dino Farinacci
Sent: Wednesday, January 08, 2014 11:33 AM
To: Carl Reed
Cc: Alexandru Petrescu ; Georgios Karagiannis ; 
[email-masked] ; <[email-masked]>
Subject: Re: [geonet/its] challenges proposed by Dimitri

Yes, but in this case, you need some other value to determine boundary. 
Because the center of your property can include me your neighbor if you 
don't have that other boundary. So radius, triangulation, or four sets of 
geo-coordinates are necessary.

And I would argue some properties are not just hexagons, but octigons or 
nonagons as well. Depends on the granularity you want or need.

Dino

On Jan 8, 2014, at 8:23 AM, Carl Reed <[email-masked]> wrote:

> parcel. The approach generates a single PIN based on lat/long, which in 
> the use case below reduces the number resolution mechanisms.
>
> re-projection). Regardless of the approach this group decides to follow, 
> at a minimum the documentation needs to be very clear on the CRS of the 
> relevant EPSG code for the CRS being used. The approach for specifying a 
> CRS is defined by ISO and the OGC in a variety of documents.
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 8 Jan 2014 16:34:55 -0800

Then I am not following. Your URL reference illustrates to use a coordinate system that North Carolina uses. GPS coordinates are global, why would you want to use something else?

Dino

On Jan 8, 2014, at 3:44 PM, Carl Reed <[email-masked]> wrote:

> Dino -
> 
> Thanks.
> 
> I was suggesting an approach to uniquely identify a location without having to use lat-long coordinates. The issue of a "boundary" is different. FYI, a boundary of three of more non-intersecting sides/edges (in GIS) is a polygon. All treated the same. ISO 19107:Spatial Schema provides a set of mathematical definitions for various types of 2d and 3d geometry. We use these definitions in the OGC - as does OASIS, NENA, and a number of other standards organizations that work with geometry and location.
> 
> Cheers
> 
> Carl
> 
> 
> -----Original Message----- From: Dino Farinacci
> Cc: Alexandru Petrescu ; Georgios Karagiannis ; [email-masked] ; <[email-masked]>

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 8 Jan 2014 18:06:36 -0700

Dino -

I am not suggesting using the coordinate system (state plane) used in NC. NC 
is just an exemplar of how to generate a unique identifier based on a 
coordinate for a geographic feature. There are other algorithms that allow 
similar computation of coordinate based unique identifiers.

Of course, lat-long coordinates are not unique :-) 
http://www.ogcnetwork.net/node/338

This is why the other part of my email was about making sure that the proper 
information is provided related to the lat/long coordinates being used.

Cheers

Carl

-----Original Message----- 
From: Dino Farinacci
Sent: Wednesday, January 08, 2014 5:34 PM
To: Carl Reed
Cc: Alexandru Petrescu ; Georgios Karagiannis ; 

Then I am not following. Your URL reference illustrates to use a coordinate 
system that North Carolina uses. GPS coordinates are global, why would you 
want to use something else?

Dino

On Jan 8, 2014, at 3:44 PM, Carl Reed <[email-masked]> wrote:

> Dino -
>
> Thanks.
>
> I was suggesting an approach to uniquely identify a location without 
> having to use lat-long coordinates. The issue of a "boundary" is 
> different. FYI, a boundary of three of more non-intersecting sides/edges 
> (in GIS) is a polygon. All treated the same. ISO 19107:Spatial Schema 
> provides a set of mathematical definitions for various types of 2d and 3d 
> geometry. We use these definitions in the OGC - as does OASIS, NENA, and a 
> number of other standards organizations that work with geometry and 
> location.
>
> Cheers
>
> Carl
>
>
>> definition used in PIDF and a number of other RFCs very clearly states 
>> the relevant EPSG code for the CRS being used. The approach for 
>> specifying a CRS is defined by ISO and the OGC in a variety of documents.
>>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 8 Jan 2014 19:16:08 -0800

Then I think we love the discussion on what accuracy levels we really need. 

Dino

> On Jan 8, 2014, at 5:06 PM, "Carl Reed" <[email-masked]> wrote:
> 
> Dino -
> 
> I am not suggesting using the coordinate system (state plane) used in NC. NC is just an exemplar of how to generate a unique identifier based on a coordinate for a geographic feature. There are other algorithms that allow similar computation of coordinate based unique identifiers.
> 
> Of course, lat-long coordinates are not unique :-) http://www.ogcnetwork.net/node/338
> 
> This is why the other part of my email was about making sure that the proper information is provided related to the lat/long coordinates being used.
> 
> Cheers
> 
> Carl
>

---

From: <[email-masked]>
Date: Thu, 9 Jan 2014 09:12:10 +0000

Hi Carl,

Thanks,
Is it then possible to describe this issue in such a way that we can include it as a challenge/work item in the charter and/or in the problem statement draft?
Please take into account the comments of Dino!

Best regards,
Georgios

> From: Carl Reed [mailto:[email-masked]]
> Sent: woensdag 8 januari 2014 17:23
> To: Alexandru Petrescu; Karagiannis, G. (EWI); dimitri.papadimitriou@alcatel-
> lucent.com
> Cc: [email-masked]
> the requirements perhaps to transform between CRS (also known as re-
> projection). Regardless of the approach this group decides to follow, at a
> minimum the documentation needs to be very clear on the CRS of the
> coordinate(s) being used. Simply stating lat/long is unclear and can actually
> result in significant absolute location errors depending on the geoid used for
> a given lat/long pair. The existing location object (LO) definition used in PIDF
> and a number of other RFCs very clearly states the relevant EPSG code for
> the CRS being used. The approach for specifying a CRS is defined by ISO and
> the OGC in a variety of documents.
> 
> The above may seem a trivial point, but ambiguity in the specification of the
> CRS for a coordinate set can lead to a number of issues in terms of
> > The questions that you have listed below are very useful and therefore
> > I am forwarding your email to the its list!
> >
> An area could be represented by the coordinates of some of the points on its
> perimeter, or other description of point coordinates and shape identifier.  A
> volume description would have more possibilities.  One should also consider
> maybe the projection alternatives.
> 
> With geonet we'd talk new identifiers like geographical coordinates.  If we
> talked only one such coordinate (say 'latitude'), then we'd need 3 new
> resolution mechanisms:
> Maybe the latitude is not sufficient, so we'd need longitude and altitude as
> well.  This would give a total of 9 new resolution protocols.
> 
> On another hand, one may think of combining the lat/long/alt into a single
> identifier.  That may appear simple at first sight, but may have its own
> difficulties, one of which being the necessity of the representation of
> precision (HDOP, VDOP).
> 
> representing one single geographical coordinate (it's not because everybody
> talks GPS now that someone will not talk Baidou tomorrow, as an example).
> If I want to locate all the IP sensors of water level measurements where I live
> I am not able to use the GPS coordinates, I must use coordinates using the
> Lambert projection (just another example).
> 
> Yes, I am told conversion tools exist (e.g. same GNSS chipset outputs both
> GPS and Galileo data, using an internal conversion).  But then the question is
> whether we need conversion tools or resolution tools (protocols).
> 
> Alex
> 
> > 3. which resolution mechanism can be used at IP locator (or edges) if
> > packets would have to transit non IP islands e.g. Geo-locator
> > 5. at which level of "stack" this information has to be inserted such
> > that intermediate nodes can successfully reach the destination as
> > expected by the source.
> >
> > Best regards,
> >
> > Georgios
> >
> > Thus there is first a question 1. what a geographic area "represents"
> > because several IP locators can give access to it.
> >
> > 5. at which level of "stack" this information has to be inserted such
> > that intermediate nodes can successfully reach the destination as
> > expected by the source.
> >
> > Thanks,
> >
> > -dimitri.
> >
> >
> >

---

From: <[email-masked]>
Date: Thu, 9 Jan 2014 10:29:15 +0000

Hi Dimitri,

Thanks, so you mean that among others we should focus on:

How could a locator could be mapped to a geographic area, and vice versa, when a m:n relationship exists between locators and geographic areas? 
The m:n relationship exists when a locator can provide access to m geographic areas and on the other hand a given geographic area could provide access to n locators.

Best regards,
Georgios

> Sent: donderdag 9 januari 2014 11:12
> Subject: RE: [geonet/its] challenges proposed by Dimitri
> 
> Hello,
> 
> Well the question doesn't stem from the representation itself (they exist and
> IETF is not the place to standardize them --at best detail their succintness vs.
> precision knowing that our recording format might be constraining) but more
> importantly from the relationship (and implication) to associated locators.
> 
> In the general case we would have to deal with a m:n relationship (n locators
> can provide access to a given geographic area and on the other hand a given
> locator could provide access to m geographic areas).
> 
> Thanks,
> -dimitri.
> 
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Thursday, January 09, 2014 10:12
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]; Papadimitriou, Dimitri
> > (Dimitri); [email-masked]
> > Subject: RE: [geonet/its] challenges proposed by Dimitri
> >
> > Hi Carl,
> >
> > Thanks,
> > Is it then possible to describe this issue in such a way that we can
> > include it as a challenge/work item in the charter and/or in the
> > problem statement draft?
> > > A very common practice in the land management community is to create
> > > a unique parcel identifier based on the coordinates of the centroid
> > > of the parcel. The approach generates a single PIN based on
> > > lat/long, which in
> > the
> > > And you also raise the question of coordinate reference systems
> > > (CRS)
> > and
> > > projection). Regardless of the approach this group decides to
> > > follow, at
> > a
> > actually
> > > result in significant absolute location errors depending on the
> > > geoid
> > used for
> > > a given lat/long pair. The existing location object (LO) definition
> > > used
> > in PIDF
> > > and a number of other RFCs very clearly states the relevant EPSG
> > > code
> > for
> > > the CRS being used. The approach for specifying a CRS is defined by
> > > ISO
> > and
> > > The above may seem a trivial point, but ambiguity in the
> > > specification
> > of the
> > > I have some thoughts on this.  Far from me any intention to
> > > complexify things.
> > >
> > > > Actually, I agree with the challenges that you described and I
> > > > will try to integrate them in what we have up to now:
> > > >
> > its
> > we
> > > talked only one such coordinate (say 'latitude'), then we'd need 3
> > altitude as
> > single
> > > identifier.  That may appear simple at first sight, but may have its
> > > own difficulties, one of which being the necessity of the
> > everybody
> > > If I want to locate all the IP sensors of water level measurements
> > > where
> > I live
> > > I am not able to use the GPS coordinates, I must use coordinates
> > > using
> > the
> > both
> > > > 5. at which level of "stack" this information has to be inserted
> > > > such that intermediate nodes can successfully reach the
> > > > destination as expected by the source.
> > > >
> > > > Best regards,
> > > >
> > > > Georgios
> > > >
> > > > 5. at which level of "stack" this information has to be inserted
> > > > such that intermediate nodes can successfully reach the
> > > > destination as expected by the source.
> > > >
> > > > Thanks,
> > > >
> > > > -dimitri.
> > > >
> > > >
> > > >

---

From: <[email-masked]>
Date: Thu, 9 Jan 2014 11:02:01 +0000

Hi Dimitri,

Okay, your provided description of the issue is more accurate:

Representation of geographic area into locators (and vice versa) infer an important  trade-off between  succinctness (memory space) vs. precision (success rate).
As we are dealing with indirect access to this information (via locators) the fundamental question becomes how to translate this information in resolution records in case multiple representation are considered.

Best regards,
Georgios

> Sent: donderdag 9 januari 2014 11:54
> It is important to observe that:
> 
> Representation (of geographic area) show the following tradeoff between
> succintness (memory space) vs. precision (success rate).
> 
> As we are dealing with indirect access to this information (via locators) the
> fundamental question becomes how to translate this information in
> resolution records in case multiple representation are considered.
> 
> Thanks,
> -dimitri.
> > Sent: Thursday, January 09, 2014 11:29
> > To: Papadimitriou, Dimitri (Dimitri)
> > Cc: [email-masked]
> > How could a locator could be mapped to a geographic area, and vice
> > versa, when a m:n relationship exists between locators and geographic
> areas?
> > The m:n relationship exists when a locator can provide access to m
> > geographic areas and on the other hand a given geographic area could
> > provide access to n locators.
> >
> > Best regards,
> > Georgios
> >
> >
> > > From: Papadimitriou, Dimitri (Dimitri)
> > [mailto:dimitri.papadimitriou@alcatel-
> > > lucent.com]
> > > precision knowing that our recording format might be constraining)
> > > but
> > more
> > > can provide access to a given geographic area and on the other hand
> > > a
> > given
> > > > Cc: [email-masked]; [email-masked]; Papadimitriou,
> > > > Dimitri (Dimitri); [email-masked]
> > > > Is it then possible to describe this issue in such a way that we
> > > > can include it as a challenge/work item in the charter and/or in
> > > > the problem statement draft?
> > > > > A very common practice in the land management community is to
> > > > > create a unique parcel identifier based on the coordinates of
> > > > > the centroid of the parcel. The approach generates a single PIN
> > > > > based on lat/long, which in
> > > > the
> > > > > re- projection). Regardless of the approach this group decides
> > > > > to follow, at
> > > > a
> > > > > a given lat/long pair. The existing location object (LO)
> > > > > definition used
> > > > in PIDF
> > > > > the CRS being used. The approach for specifying a CRS is defined
> > > > > by ISO
> > > > and
> > > > > CRS for a coordinate set can lead to a number of issues in terms
> > > > > of visualization, analysis, fusion, analytics and so forth.
> > > > >
> > > > > Cheers
> > > > >
> > > > > Carl
> > > > >
> > > > >
> > > > > volume description would have more possibilities.  One should
> > > > > also
> > > > consider
> > > > > talked only one such coordinate (say 'latitude'), then we'd need
> > > > > 3 new resolution mechanisms:
> > > > > identifier.  That may appear simple at first sight, but may have
> > > > > If I want to locate all the IP sensors of water level
> > > > > measurements where
> > > > I live
> > > > > GPS and Galileo data, using an internal conversion).  But then
> > > > > the
> > > > question is
> > > > > > 3. which resolution mechanism can be used at IP locator (or
> > > > > > edges) if packets would have to transit non IP islands e.g.
> > > > > > Geo-locator
> > > > > > 5. at which level of "stack" this information has to be
> > > > > > inserted such that intermediate nodes can successfully reach
> > > > > > the destination as expected by the source.
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Georgios
> > > > > >
> > > > > > Note however at the local level there is distinction between
> > > > > > IP address (logical) and e.g. MAC address (physical)
> > > > > >
> > "represents"
> > > > > > 2. which resolution mechanism at the source node e.g.
> > > > > > 3. which resolution mechanism at IP locator (or edges) if
> > > > > > 5. at which level of "stack" this information has to be
> > > > > > inserted such that intermediate nodes can successfully reach
> > > > > > the destination as expected by the source.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > -dimitri.
> > > > > >
> > > > > >
> > > > > >

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 17:31:46 +0100

Le 09/01/2014 00:44, Carl Reed a écrit :
> different. FYI, a boundary of three of more non-intersecting
> sides/edges (in GIS) is a polygon. All treated the same. ISO
> 19107:Spatial Schema provides a set of mathematical definitions for
> various types of 2d and 3d geometry. We use these definitions in the
> OGC - as does OASIS, NENA, and a number of other standards
> organizations that work with geometry and location.

Carl - that sounds interesting.

I wonder whether there exist some RFC or draft that tells how to encode
or transmit geographical coordinates?  We could look at the proposed
way, and try to understand it?

Alex

>
> Cheers
>
> Carl
>
>
> -----Original Message----- From: Dino Farinacci Sent: Wednesday,
> January 08, 2014 11:33 AM To: Carl Reed Cc: Alexandru Petrescu ;
> Georgios Karagiannis ; [email-masked] ;
> <[email-masked]> Subject: Re: [geonet/its] challenges proposed by
> Dimitri
>
> Yes, but in this case, you need some other value to determine
> boundary. Because the center of your property can include me your
> neighbor if you don't have that other boundary. So radius,
> triangulation, or four sets of geo-coordinates are necessary.
>
> And I would argue some properties are not just hexagons, but octigons
> or nonagons as well. Depends on the granularity you want or need.
>
> Dino
>
>> create a unique parcel identifier based on the coordinates of the
>> centroid of the parcel. The approach generates a single PIN based
>> on lat/long, which in the use case below reduces the number
>> resolution mechanisms.
>>
>> (CRS) and the requirements perhaps to transform between CRS (also
>> known as re-projection). Regardless of the approach this group
>> decides to follow, at a minimum the documentation needs to be very
>> clear on the CRS of the coordinate(s) being used. Simply stating
>> lat/long is unclear and can actually result in significant absolute
>> location errors depending on the geoid used for a given lat/long
>> pair. The existing location object (LO) definition used in PIDF and
>> a number of other RFCs very clearly states the relevant EPSG code
>> for the CRS being used. The approach for specifying a CRS is
>> defined by ISO and the OGC in a variety of documents.
>>
>> specification of the CRS for a coordinate set can lead to a number
>> of issues in terms of visualization, analysis, fusion, analytics
>> and so forth.
>>
>> Cheers
>>
>> Carl
>>
>>
>> -----Original Message----- From: Alexandru Petrescu Sent:
>> Wednesday, January 08, 2014 4:33 AM To: [email-masked] ;
>> [email-masked] Cc: [email-masked] Subject:
>> Re: [geonet/its] challenges proposed by Dimitri
>>
>> Hi Georgios,
>>
>> An area could be represented by the coordinates of some of the
>> points on its perimeter, or other description of point coordinates
>> and shape identifier.  A volume description would have more
>> possibilities.  One should also consider maybe the projection
>> alternatives.
>>
>>> 2. which resolution mechanism can be used at the source node
>>> e.g. Geo-locator (name)/ Geo-Physical coord.(addr.) to IP
>>> locator
>>
>> But, we currently know two kinds of resolution: - IP address <->
>> MAC address (ND) - IP address <-> name (DNS)
>>
>> With geonet we'd talk new identifiers like geographical
>> coordinates.  If we talked only one such coordinate (say
>> 'latitude'), then we'd need 3 new resolution mechanisms: - IP
>> address <-> latitude (protocol IPL) - MAC address <-> latitude
>> (protocol MACL) - name <-> latitude (protocol NL).
>>
>> On another hand, one may think of combining the lat/long/alt into
>> a single identifier.  That may appear simple at first sight, but
>> may have its own difficulties, one of which being the necessity of
>> the representation of precision (HDOP, VDOP).
>>
>> everybody talks GPS now that someone will not talk Baidou tomorrow,
>> as an example).  If I want to locate all the IP sensors of water
>> level measurements where I live I am not able to use the GPS
>> coordinates, I must use coordinates using the Lambert projection
>> (just another example).
>>
>> Yes, I am told conversion tools exist (e.g. same GNSS chipset
>> outputs both GPS and Galileo data, using an internal conversion).
>> But then the question is whether we need conversion tools or
>> resolution tools (protocols).
>>
>> Alex
>>
>>> Geo-locator (name) to Geo-Physical coord.
>>>
>>> [mailto:[email-masked]] *Sent:*
>>> zaterdag 14 december 2013 23:56 *To:* Karagiannis, G. (EWI)
>>> *Subject:* RE: the uncrisp problem
>>>
>>> Hello,
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 09 Jan 2014 17:35:29 +0100

Let me try to understand this.

What is a locator?  Could it be 'latitude'?  Or could it be an IP address?

(because in LISP/FI terminology this term is used in the dichotomy 
address/locator of an IP address: it could itself be both).

Alex

Le 09/01/2014 11:29, [email-masked] a écrit :
> areas? The m:n relationship exists when a locator can provide access
> to m geographic areas and on the other hand a given geographic area
> could provide access to n locators.
>
> Best regards, Georgios
>
>
>> -----Original Message----- From: Papadimitriou, Dimitri (Dimitri)
>> [mailto:dimitri.papadimitriou@alcatel- lucent.com] Sent: donderdag
>> 9 januari 2014 11:12 To: Karagiannis, G. (EWI) Subject: RE:
>> [geonet/its] challenges proposed by Dimitri
>>
>> Hello,
>>
>> Well the question doesn't stem from the representation itself (they
>> exist and IETF is not the place to standardize them --at best
>> detail their succintness vs. precision knowing that our recording
>> format might be constraining) but more importantly from the
>> relationship (and implication) to associated locators.
>>
>> In the general case we would have to deal with a m:n relationship
>> (n locators can provide access to a given geographic area and on
>> the other hand a given locator could provide access to m geographic
>> areas).
>>
>> Thanks, -dimitri.
>>
>>> -----Original Message----- From: [email-masked]
>>> [mailto:[email-masked]] Sent: Thursday, January 09, 2014
>>> 10:12 To: [email-masked] Cc: [email-masked];
>>> [email-masked]; Papadimitriou, Dimitri (Dimitri);
>>> [email-masked] Subject: RE: [geonet/its] challenges proposed
>>> by Dimitri
>>>
>>> Hi Carl,
>>>
>>> Thanks, Is it then possible to describe this issue in such a way
>>> that we can include it as a challenge/work item in the charter
>>> and/or in the problem statement draft? Please take into account
>>> the comments of Dino!
>>>
>>> Best regards, Georgios
>>>
>>>
>>>> -----Original Message----- From: Carl Reed
>>>> [mailto:[email-masked]] Sent: woensdag 8 januari 2014
>>>> 17:23 To: Alexandru Petrescu; Karagiannis, G. (EWI);
>>> dimitri.papadimitriou@alcatel-
>>>> lucent.com Cc: [email-masked] Subject: Re: [geonet/its]
>>>> challenges proposed by Dimitri
>>>>
>>>> Alex -
>>>>
>>>> And you also raise the question of coordinate reference
>>>> systems (CRS)
>>> and
>>>> the requirements perhaps to transform between CRS (also known
>>>> as re- projection). Regardless of the approach this group
>>>> decides to follow, at
>>> a
>>>> minimum the documentation needs to be very clear on the CRS of
>>>> the coordinate(s) being used. Simply stating lat/long is
>>>> unclear and can
>>> actually
>>>> result in significant absolute location errors depending on
>>>> the geoid
>>> used for
>>>> and a number of other RFCs very clearly states the relevant
>>>> EPSG code
>>> for
>>>> the CRS being used. The approach for specifying a CRS is
>>>> defined by ISO
>>> and
>>>> CRS for a coordinate set can lead to a number of issues in
>>>> terms of visualization, analysis, fusion, analytics and so
>>>> forth.
>>>>
>>>> Cheers
>>>>
>>>> Carl
>>>>
>>>>
>>>> Wednesday, January 08, 2014 4:33 AM To: [email-masked]
>>>> ; [email-masked] Cc: [email-masked]
>>>>> Actually, I agree with the challenges that you described and
>>>>> I will try to integrate them in what we have up to now:
>>>>>
>>>> points on
>>>> But, we currently know two kinds of resolution: - IP address
>>>> <-> MAC address (ND) - IP address <-> name (DNS)
>>>>
>>>> coordinates. If
>>>> talked only one such coordinate (say 'latitude'), then we'd
>>>> need 3 new resolution mechanisms: - IP address <-> latitude
>>>> (protocol IPL) - MAC address <-> latitude (protocol MACL) -
>>>> name <-> latitude (protocol NL).
>>>>
>>>> identifier.  That may appear simple at first sight, but may
>>>> have its own difficulties, one of which being the necessity of
>>>> Not to mention the difficulty of coming up with an agreed way
>>>> of representing one single geographical coordinate (it's not
>>>> because
>>> everybody
>>>> talks GPS now that someone will not talk Baidou tomorrow, as
>>>> an
>>> example).
>>>> I am not able to use the GPS coordinates, I must use
>>>> coordinates using
>>> the
>>>> outputs
>>>>> "represents" because several IP locators can give access to
>>>>> it.
>>>>>
>>>> _______________________________________________ its mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/its
>

---

From: Carl Reed <[email-masked]>
Date: Thu, 9 Jan 2014 19:07:48 -0500 (EST)

Alex -

Depends on your requirements - such as types of geometry required (such as point, linestring, polygon, circle, etc), requirement for "compactness", and so forth. Also, does the encoding need to be binary or is XML or JSON OK. 

The best way to start is to define a content model that is encoding agnostic and then provide encodings. Check out georss.org for an example. There is also the GeoPriv geodetic encoding (Location Object): portal.opengeospatial.org/files/?artifact_id=21630‎ . This is an XML encoding based on GML.

I am out of the office for a couple of days. More later.

Cheers

Carl

----- Original Message -----
From: "Alexandru Petrescu" <[email-masked]>
To: "Carl Reed" <[email-masked]>, "Dino Farinacci" <[email-masked]>
Cc: "Georgios Karagiannis" <[email-masked]>, "dimitri papadimitriou" <[email-masked]>, [email-masked]
Sent: Thursday, January 9, 2014 9:31:46 AM
Subject: Re: [geonet/its] challenges proposed by Dimitri

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 17:39:47 +0100

I have been clarified in private that 'locator' in the below discussion
is the 'locator' as we typically use in the discussion about attachment
points.

So the statement the challenge from Georgios/Dimitri is really how could
an IP address (a 'locator') be mapped into a geographic area?

(where 'mapped' also means mapped like in relating a parameter to
another, not necessarily like maps on a 2D board).

Alex

Le 09/01/2014 17:35, Alexandru Petrescu a écrit :
>> versa, when a m:n relationship exists between locators and
>> geographic areas? The m:n relationship exists when a locator can
>> provide access to m geographic areas and on the other hand a given
>> geographic area could provide access to n locators.
>>
>> Best regards, Georgios
>>
>>
>>> -----Original Message----- From: Papadimitriou, Dimitri
>>> (Dimitri) [mailto:dimitri.papadimitriou@alcatel- lucent.com]
>>> Sent: donderdag 9 januari 2014 11:12 To: Karagiannis, G. (EWI)
>>> Well the question doesn't stem from the representation itself
>>> (they exist and IETF is not the place to standardize them --at
>>> best detail their succintness vs. precision knowing that our
>>> recording format might be constraining) but more importantly from
>>> the relationship (and implication) to associated locators.
>>>
>>> In the general case we would have to deal with a m:n
>>> relationship (n locators can provide access to a given geographic
>>> area and on the other hand a given locator could provide access
>>> to m geographic areas).
>>>
>>> Thanks, -dimitri.
>>>
>>>> [mailto:[email-masked]] Sent: Thursday, January 09,
>>>> 2014 10:12 To: [email-masked] Cc: [email-masked];
>>>> [email-masked]; Papadimitriou, Dimitri
>>>> (Dimitri); [email-masked] Subject: RE: [geonet/its]
>>>> Thanks, Is it then possible to describe this issue in such a
>>>> way that we can include it as a challenge/work item in the
>>>> charter and/or in the problem statement draft? Please take into
>>>> account the comments of Dino!
>>>>
>>>> Best regards, Georgios
>>>>
>>>>
>>>>> [mailto:[email-masked]] Sent: woensdag 8 januari
>>>>> 2014 17:23 To: Alexandru Petrescu; Karagiannis, G. (EWI);
>>>>> A very common practice in the land management community is
>>>>> to create a unique parcel identifier based on the coordinates
>>>>> of the centroid of the parcel. The approach generates a
>>>>> single PIN based on lat/long, which in
>>>> the
>>>>> Shows an example. They use state-plane but a similar
>>>>> approach could be used for lat/long coordinates.
>>>>>
>>>>> the requirements perhaps to transform between CRS (also
>>>>> known as re- projection). Regardless of the approach this
>>>>> group decides to follow, at
>>>> a
>>>>> minimum the documentation needs to be very clear on the CRS
>>>>> of the coordinate(s) being used. Simply stating lat/long is
>>>>> unclear and can
>>>> actually
>>>>> [email-masked] Cc: [email-masked]
>>>>>> The questions that you have listed below are very useful
>>>>>> and therefore I am forwarding your email to the its list!
>>>>>>
>>>>>> Actually, I agree with the challenges that you described
>>>>>> and I will try to integrate them in what we have up to
>>>>>> now:
>>>>>>
>>>>>> 1. How can a geographic area be "represented", since
>>>>>> several IP locators can give access to it.
>>>>>
>>>>> perimeter, or other description of point coordinates and
>>>>> shape
>>>> identifier.  A
>>>>> volume description would have more possibilities.  One
>>>>> should also
>>>> consider
>>>>>> 2. which resolution mechanism can be used at the source
>>>>>> node e.g. Geo-locator (name)/ Geo-Physical coord.(addr.) to
>>>>>> IP locator
>>>>>
>>>>> have its own difficulties, one of which being the necessity
>>>>> of the representation of precision (HDOP, VDOP).
>>>>>
>>>>> Not to mention the difficulty of coming up with an agreed
>>>>> way of representing one single geographical coordinate (it's
>>>>> not because
>>>> everybody
>>>>> GPS and Galileo data, using an internal conversion).  But
>>>>> then the
>>>> question is
>>>>>> 3. which resolution mechanism can be used at IP locator
>>>>>> (or edges) if packets would have to transit non IP islands
>>>>>> e.g. Geo-locator (name) to Geo-Physical coord.
>>>>>>
>>>>>> inserted such that intermediate nodes can successfully
>>>>>> reach the destination as expected by the source.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Georgios
>>>>>>
>>>>>> zaterdag 14 december 2013 23:56 *To:* Karagiannis, G.
>>>>>> (EWI) *Subject:* RE: the uncrisp problem
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> - Geo-locators (naming the geographic area) vs
>>>>>> Geo-physical coordinates (the actual coordinates of that
>>>>>> area)
>>>>>>
>>>>>> Note however at the local level there is distinction
>>>>>> between IP address (logical) and e.g. MAC address
>>>>>> (physical)
>>>>>>
>>>>>> "represents" because several IP locators can give access
>>>>>> to it.
>>>>>>
>>>>>> packets would have to transit non IP islands e.g.
>>>>>> inserted such that intermediate nodes can successfully
>>>>>> reach the destination as expected by the source.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -dimitri.
>>>>>>
>>>>>>
>>>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 10 Jan 2014 17:46:26 +0100

Le 10/01/2014 01:07, Carl Reed a écrit :
> Alex -
>
> Depends on your requirements - such as types of geometry required
> (such as point, linestring, polygon, circle, etc), requirement for
> "compactness", and so forth.

Makes sense.  Also I think we'd need to decide that these are
three-dimensional volumes from the start, not just 2D.  For example when
many highways branches pass one under another, their RSUs would be
visible from up above of the other way.

> Also, does the encoding need to be binary or is XML or JSON OK.

Right, I wonder whether any draft or RFC offers XML or JSON
representations of geography concepts at IETF.

> The best way to start is to define a content model that is encoding
> agnostic and then provide encodings.

I agree, it's a good distinction.  The content model could be something
like "GPS coordinates with WGS-84", and the encoding could be "XML".

> Check out georss.org for an example. There is also the GeoPriv
> geodetic encoding (Location Object):
> portal.opengeospatial.org/files/?artifact_id=21630‎ . This is an XML
> encoding based on GML.

Thanks.

Is this an IETF document?  (I did click on it, but I can't understand).

Thanks,

Alex

>
> Cheers
>
> Carl
>
>
> ----- Original Message ----- From: "Alexandru Petrescu"
> <[email-masked]> To: "Carl Reed"
> <[email-masked]>, "Dino Farinacci" <[email-masked]>
> Cc: "Georgios Karagiannis" <[email-masked]>, "dimitri
> papadimitriou" <[email-masked]>,
> [email-masked] Sent: Thursday, January 9, 2014 9:31:46 AM Subject: Re:
>> I was suggesting an approach to uniquely identify a location
>> without having to use lat-long coordinates. The issue of a
>> "boundary" is different. FYI, a boundary of three of more
>> non-intersecting sides/edges (in GIS) is a polygon. All treated
>> the same. ISO 19107:Spatial Schema provides a set of mathematical
>> definitions for various types of 2d and 3d geometry. We use these
>> definitions in the OGC - as does OASIS, NENA, and a number of
>> other standards organizations that work with geometry and
>> location.
>
> I wonder whether there exist some RFC or draft that tells how to
> encode or transmit geographical coordinates?  We could look at the
> proposed way, and try to understand it?
>
> Alex
>
>>
>> Cheers
>>
>> Carl
>>
>>
>> And I would argue some properties are not just hexagons, but
>> octigons or nonagons as well. Depends on the granularity you want
>> or need.
>>
>> Dino
>>
>>> decides to follow, at a minimum the documentation needs to be
>>> very clear on the CRS of the coordinate(s) being used. Simply
>>> stating lat/long is unclear and can actually result in
>>> significant absolute location errors depending on the geoid used
>>> for a given lat/long pair. The existing location object (LO)
>>> definition used in PIDF and a number of other RFCs very clearly
>>> states the relevant EPSG code for the CRS being used. The
>>> approach for specifying a CRS is defined by ISO and the OGC in a
>>> variety of documents.
>>>
>>> specification of the CRS for a coordinate set can lead to a
>>> number of issues in terms of visualization, analysis, fusion,
>>> analytics and so forth.
>>>
>>> Cheers
>>>
>>> Carl
>>>
>>>
>>> points on its perimeter, or other description of point
>>> coordinates and shape identifier.  A volume description would
>>> have more possibilities.  One should also consider maybe the
>>> projection alternatives.
>>>
>>> may have its own difficulties, one of which being the necessity
>>>  representing one single geographical coordinate (it's not
>>> because everybody talks GPS now that someone will not talk
>>> Baidou tomorrow, as an example).  If I want to locate all the IP
>>> sensors of water level measurements where I live I am not able to
>>> use the GPS coordinates, I must use coordinates using the
>>>> 5. at which level of “stack” this information has to be
>>>> 5. at which level of “stack” this information has to be

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 10 Jan 2014 10:13:19 -0800

> representations of geography concepts at IETF.

There's a parallel discussion in PAWS.

PASW = mechanism for white space management.  

In US, the FCC has historically cared about antenna location and height,
but for aircraft clearance reasons.  Now we're entering on a much larger
frequency reuse exercise so more sophistication regarding emitter
location is needed.  I can't recite all the discussion but there was a
fair amount going by and some of the terms look familiar.  Agree with
you're instincts -- reuse rather than reinvent.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 10 Jan 2014 11:53:03 -0900

> representations of geography concepts at IETF.

I don't believe so, and it's also my impression that while
there are open specifications for the representation of
polygons in geospatial data it's largely the case that
representations tend to be implementation-driven.  I've
asked someone who works in remote sensing and who does a
lot of computation if she'd be willing to write something
up on what's out there.

Melinda

---

From: <[email-masked]>
Date: Sun, 12 Jan 2014 09:05:08 +0000

Hi Dimitri,

Yes, that is also what I had in mind about what the locator represents!

Best regards,

Georgios

________________________________
Van: Papadimitriou, Dimitri (Dimitri) [[email-masked]]
Verzonden: donderdag 9 januari 2014 18:20
To: Alexandru Petrescu
Cc: Karagiannis, G. (EWI)
Onderwerp: RE: [geonet/its] challenges proposed by Dimitri

The term "locator" refered in the below statement is taken out of the value space associated to the "network attachment" points; this value space could be e.g. Provider Allocatable IP addresses.

The term "locator" is generic; its inception precedes by decades its particular use in the LISP context; for instance, a locator (in the "geographic domain") would take its value out of e.g. geographic coordinate space.

Hope this clarifies,
-dimitri.

> From: its [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Thursday, January 09, 2014 17:35
> To: [email-masked]
> >> [<about:blank>mailto:dimitri.papadimitriou@alcatel- lucent.com] Sent: donderdag

---

From: "Carl Reed" <[email-masked]>
Date: Sun, 12 Jan 2014 16:02:56 -0700

Melinda -

A bit of back ground and a longish answer.

There is an ISO standard titled ISO 19107: Spatial Schema. This 
international standard specifies conceptual schemas for describing the 
spatial characteristics of geographic features (including geometries), and a 
set of spatial operations consistent with these schemas. It treats vector 
geometry and topology up to three dimensions.. Geometries range from point, 
multipoint, to polygon, to Bezier curves, to Clothoids. The OGC is currently 
revising 19107 as a joint project with ISO TC 211.

19107 is the basis for defining geometry in numerous implementation 
standards. The idea is by referencing a conceptual model for geometry, then 
implementations are consistent and not implementation driven other than 
perhaps the actual encoding mechanism.

The first implementation instance of ISO 19017 is OGC Simple Features and 
OGC Well Known Text (WKT). Also known as ISO 19125, SF describes the common 
architecture for simple feature geometry. Each Geometry Type has a 
Well-known Text Representation that can be used both to construct new 
instances of the type and to convert existing instances to textual form for 
alphanumeric display. (http://en.wikipedia.org/wiki/Well-known_text)

The most widely implementation instance is SF SQL. This second part of 
Simple Features Access (SFA), also called ISO 19125, is to define a standard 
Structured Query Language (SQL) schema that supports storage, retrieval, 
query and update of feature collections via the SQL Call-Level Interface 
(SQL/CLI) (ISO/IEC 9075-3:2003).

WKT and SF SQL are  very widely implemented, including in most (if not all) 
commercial and open source data base apps that handle geodata.

Another major implementation instance of 19107 (and other ISO conceptual 
models) is the OGC Geography Markup Language (GML). GML is an XML grammar 
defined by the OGC to express geographical features. GML serves as a 
modeling language for geographic systems as well as an open interchange 
format for geographic transactions on the Internet. Note that the concept of 
feature in GML is a very general one and includes not only conventional 
"vector" or discrete objects, but also coverages (see also GMLJP2) and 
sensor data.

Over the years, groups have defined numerous profiles and application 
schemas of GML. In 2007, IETF participants (GeoPriv) defined a GML 
application schema titled, "GML 3.1.1 PIDF-LO Shape Application Schema for 
use by the Internet Engineering Task Force (IETF)". This app schema is now 
widely used in the IETF and referenced in numerous RFCs.  Other standards 
organizations have developed their own profiles and app schemas of GML.

Finally, there are two simple encodings: GeoRSS and GeoJSON. Both implement 
a limited subset of geometries as defined in 19107. In GeoRSS, location 
content consists of geographical points, lines, and polygons of interest and 
related feature descriptions. (www.georss.org). GeoJSON is a format for 
encoding a variety of geographic data structures. (www.geojson.org). GeoJSON 
is being considered as an RFC.

AS you can see, there is considerable implementation experience and maturity 
in using an international standard for modeling geometry that is both vendor 
and data neutral.

I hope this information helps!

Regards

Carl Reed, PhD
CTO
OGC

-----Original Message----- 
From: Melinda Shore
Sent: Friday, January 10, 2014 1:53 PM
To: [email-masked]
Subject: Re: [geonet/its] challenges proposed by Dimitri

Melinda

---

From: Melinda Shore <[email-masked]>
Date: Sun, 12 Jan 2014 15:34:37 -0900

> A bit of back ground and a longish answer.

That's extremely helpful - many thanks.

Melinda

---

From: <[email-masked]>
Date: Tue, 14 Jan 2014 12:22:14 +0000

Hi all,

I have used the discussions that we have had up to now and updated the "Geonet" problem statement, challenges, requirements and assumptions.

Please note that we need to have a new version of the problem statement draft ready before the 17th of January! 
Alex, Melinda is this right?

For this purpose, I have used the discussions that the following people have had in the geonet/its mailing list:
Alexandru Peterscu, Melinda Shore, Dino Farinacci, Brian Dickson, Dimitri Papadimitriou, Carl Reed, , Rex Buddenberg, Alison Chaiken, Georgios Karagiannis.

Please note that we need volunteers to complete some issues associated with the description of use cases and with the differences between Geonet and other IETF working groups:
(1)   ecrit, (2) LISP and (3) geopriv. Need volunteers for this!
Regarding the use cases I have assigned some volunteers (I hope that this is acceptable):

o) Dissemination to a particular area: 
Volunteer: Georgios (old use cases that were described in v.01 of the problem statement draft, rewritten in few paragraphs)

o) Goods Tracking
Volunteer: Dino Farinacci?

o) Traffic Safety and Traffic Efficiency and Traffic Management
Volunteer: Georgios

o) Mobile RSU
Volunteer: Brian Dickson?

o) Identification of originating area (network operator, CDN)
Volunteer: needed?

Below you can find all these descriptions:

Geonet Problem:
=============

Mechanisms and IETF Standardized  protocol(s) is/are needed to allow source  nodes anywhere in the Internet to disseminate packets to all/any node(s) using geographical area information, such as (1) geo-locators (names) and/or (2) geographic (physical) coordinates, within a specified  target geographic area.

Geonet Challenges/Open issues:
===============

o) Mechanisms and/or protocol network layer solutions are needed for the accurate representation of geographic areas using (1) geo-locators (names) and/or (2) geographic (physical) coordinates.

o) Mechanisms and/or protocol network layer solutions are needed to ensure that geographical area information (geo-locators (names) and/or geographic (physical) coordinates) is accurately mapped to an IP locator, e.g., an IP address. Mapping data bases can be maintained at the source nodes, IP locator nodes, or intermediate nodes (e.g., edge nodes).

o) Mechanisms and/or protocol network layer solutions are needed to ensure that an IP locator, e.g., an IP address can be accurately mapped to a geographic area information (geo-locators (names) and/or geographic (physical) coordinates). Mapping data bases can be maintained at the source nodes, IP locator nodes, or intermediate nodes (e.g., edge nodes).

o) Mechanisms and protocol network layer solutions are needed to ensure that data packets generated by source nodes placed anywhere in the Internet can be forwarded over multiple hops by using, where possible, geographic physical coordinates of (1) the destination node(s) and/or (2) the intermediate nodes for the routing decisions, instead of using their IP addresses.
(Note that in order to solve the above challenge it is NOT mandated that all nodes located on the path from source to destination nodes are able to forward packets using the  geo-coordinates of (1) the destination node(s) and/or (2) the intermediate nodes for the routing decisions. This is emphasized by using the words "where possible".)

Geonet Requirements
===========

The specified mechanisms and protocol solutions:
o) SHOULD ideally support IPv4 and IPv6
o) MUST at a minimum support IPv6
o) MUST be able to use and insert geographic area information at the network layer.
o) MUST be able to disseminate the information from senders to the destination nodes located in the target/destination geographic area in a point to multipoint manner.
o) SHOULD be able to be scalable and maintain its performance to acceptable levels even it is applied to: (1) global coverage with small target/destination geographic areas, (2) large traffic volumes (large flows), (3) large number of active sources
o) MUST be able to provide accurate representation of geographic areas using (1) geo-locators (names) and/or (2) geographic (physical) coordinates.
o) MUST be able to ensure that geographical area information (geo-locators (names) and/or geographic (physical) coordinates) is accurately mapped to an IP locator, e.g., an IP address, even if the relation between geographical area information and IP locator is not a one-to-one relationship.
o) MUST be able to ensure that an IP locator, e.g., an IP address can be accurately mapped to a geographic area information (geo-locators (names) and/or geographic (physical) coordinates), even if the relation between locator and geographical information is not a one-to-one relationship.
o) MUST be able to ensure that the used mapping data bases of IP locators to a geographic area information are up to date.
o) MUST support security and privacy: Given the sensitivity of location data and the possibility of the technology being used in emergency and/or road traffic management scenarios we will pay particular attention to security and privacy.  A thorough threat analysis will be conducted, and mitigations specified in any protocol documents which are developed objectives for all supported communication modes. Security objectives particularly include integrity, privacy and non-repudiation and SHOULD protect the network and transport layer protocol headers.  In addition the Internet-wide geo-networking solution MUST also protect privacy, i.e. provide confidentiality to personal data such as relation between node identifier and location.
o) SHOULD support timely and guaranteed delivery of information.

Geonet Assumptions:
============
o) The mechanisms and protocol solutions SHOULD be able to use and insert geographic area information at the network layer.
o) The destination nodes can be any static or moving entities, such as hosts, vehicles, sensors and actuators, goods, that are spread/located in a certain target/destination geographic area.
o) existing IETF mechanism and protocols like LISP, geopriv, ecrit and reverse 911 will be taken into consideration during the design phase 
o) The ISO 19107: Spatial Schema will be considered for the representation of spatial characteristics of geographic features (including geometries), and a set of spatial operations consistent with these schemas. ISO 19107 treats vector geometry and topology up to three dimensions.. Geometries range from point, multipoint, to polygon, to Bezier curves, to Clothoids.
o) The IEEE 1609.2, see below, will be considered  for security and privacy support (https://standards.ieee.org/findstds/standard/1609.2-2013.html

Geonet Use Cases (no particular order)
===========================
Please one paragraph per use case should be provided

o) Dissemination to a particular area: 
Volunteer: Georgios (old use cases that were described in v.01 of the problem statement draft, rewritten in few paragraphs)

o) Goods Tracking
Volunteer: Dino Farinacci?

o) Traffic Safety and Traffic Efficiency and Traffic Management
Volunteer: Georgios

o) Mobile RSU
Volunteer: Brian Dickson?

o) Identification of originating area (network operator, CDN)
Volunteer: needed?

Differences between Geonet and othet IETF working groups:
=======================================
Text need to be written that emphasizes that are the main differences between Geonet and at least (1) ecrit, (2) LISP and (3) geopriv. Need volunteers for this!

Best regards,
Georgios

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Jan 2014 04:06:46 -0900

On 1/14/14 3:22 AM, [email-masked] wrote:
> o) The IEEE 1609.2, see below, will be considered  for security and
> privacy support
> (https://standards.ieee.org/findstds/standard/1609.2-2013.html

Is this available to participants for review?

Thanks,

Melinda

---

From: <[email-masked]>
Date: Tue, 14 Jan 2014 15:12:40 +0000

Hi Melinda,

Not from my side!

Alex, you used this URL in the etherpad link. Do you know if it is available to participants for review?

Best regards,

Georgios

________________________________
Van: its [[email-masked]] namens Melinda Shore [[email-masked]]
Verzonden: dinsdag 14 januari 2014 14:06
To: [email-masked]
Onderwerp: Re: [geonet/its] new descriptions of Geonet problem, challenges, requirements, assumptions + request for volunteers

On 1/14/14 3:22 AM, [email-masked] wrote:
> (<about:blank>https://standards.ieee.org/findstds/standard/1609.2-2013.html

Thanks,

Melinda

---

From: William Whyte <[email-masked]>
Date: Tue, 14 Jan 2014 11:10:07 -0500

Hi all -- I'm editor of 1609.2, which is a published IEEE standard. With
that hat on I should point out that it's available for purchase from the
link provided. IEEE funds standards activities in part with revenue from
standards so any institutions that can afford to purchase the standards
should really go that route. If you're active in the 1609 working group you
often have access to early drafts of the standards documents.

Cheers,

William

On Tue, Jan 14, 2014 at 10:12 AM, <[email-masked]> wrote:

>  ------------------------------
> *Van:* its [[email-masked]] namens Melinda Shore [
> [email-masked]]
> *Verzonden:* dinsdag 14 januari 2014 14:06
> *To:* [email-masked]
> *Onderwerp:* Re: [geonet/its] new descriptions of Geonet problem,
> challenges, requirements, assumptions + request for volunteers
>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 14 Jan 2014 07:16:17 -0900

On 1/14/14 7:10 AM, William Whyte wrote:
> should really go that route. If you're active in the 1609 working group
> you often have access to early drafts of the standards documents.

To be honest I'm not clear on what IETF policy is around
this sort of problem, although personally my feeling is
that if it's useful - and applicable - we should be giving
it serious consideration.  But, if many participants don't
have access to it, that's a problem.  Also, in general
there's a preference for using IETF technologies where
possible.  One thing worth looking at is the extent to
which some of the work coming out of geopriv can be used
here.

Melinda

---

From: Scott Cadzow <[email-masked]>
Date: Tue, 14 Jan 2014 16:19:36 +0000

Endorsing what William has indicated I'd also note that IEEE 1609.2 is the
basis of the security and privacy protection implementation, and core models
in ETSI and ISO for Co-operative ITS (C-ITS). Thus looking at ETSI's TS 102
941 for example you should find a model of using 1609.2 in the privacy
protection mode for C-ITS. ETSI's standards are available from
http://pda.etsi.org/pda/queryform.asp for free for any published document.

Best regards,

Scott

From: its [mailto:[email-masked]] On Behalf Of William Whyte
Sent: 14 January 2014 16:10
To: Georgios Karagiannis
Cc: Melinda Shore; [email-masked]
Subject: Re: [geonet/its] new descriptions of Geonet problem, challenges,
requirements, assumptions + request for volunteers

Cheers,

William

Hi Melinda, 

Not from my side! 

Alex, you used this URL in the etherpad link. Do you know if it is available
to participants for review?

Best regards,

Georgios

  _____  

Van: its [[email-masked]] namens Melinda Shore
[[email-masked]]
Verzonden: dinsdag 14 januari 2014 14:06
To: [email-masked]
Onderwerp: Re: [geonet/its] new descriptions of Geonet problem, challenges,
requirements, assumptions + request for volunteers

Thanks,

Melinda

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Jan 2014 17:20:41 +0100

> you often have access to early drafts of the standards documents.

William - thanks for the update.

Many institutions working on standards can indeed afford to purchase 
some documents.  For example my employer had access to it at some time.

I suppose there could exist a means - still private - whereby documents 
could be shared between IETF participants and IEEE participants driven 
by a common goal of making vehicles communicate.

Alex

>
> Cheers,
>
> William
>
>
> On Tue, Jan 14, 2014 at 10:12 AM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Melinda,
>
>     Not from my side!
>
>     ------------------------------------------------------------------------
>     *Van:* its [[email-masked] <mailto:[email-masked]>]
>     namens Melinda Shore [[email-masked]
>     <mailto:[email-masked]>]
>     *To:* [email-masked] <mailto:[email-masked]>
>     On 1/14/14 3:22 AM, [email-masked]
>     <mailto:[email-masked]> wrote:
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 14 Jan 2014 17:20:54 +0100

Hi Georgios,

I am not sure it is me who pasted this URL in the etherpad.  I guess 
maybe Alison?  Or otherwise anyone who wanted to type there (I am not 
sure there is an access log there).

Alex

> *Van:* its [[email-masked]] namens Melinda Shore

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 14 Jan 2014 11:27:51 -0800

On Tue, 2014-01-14 at 12:22 +0000, [email-masked] wrote:
> o) SHOULD be able to be scalable and maintain its performance to
> acceptable levels even it is applied to: (1) global coverage with
> small target/destination geographic areas, (2) large traffic volumes
> (large flows), (3) large number of active sources

s/scaleable/stable

Reason.  Spectrum is an inelastic resource so you can't just up comms
capacity when sources increase.  What is important is determinism vs
stochasticism.  Because deterministic systems are stable under
overload.  
     At layer 2 we see this in the different MACs.  CSMA (as in WiFi) is
what we used to call 'free net' and crashes under overload.  TDMA MACs
like that in 802.16 are what we used to call 'directed net' and are
stable (and near-deterministic).

---

From: <[email-masked]>
Date: Wed, 15 Jan 2014 08:02:22 +0000

Hi Rex,

Thanks for the comment, however, I have a question regarding your proposed text for the stability requirement:

> stochasticism.  Because deterministic systems are stable under overload.
>      At layer 2 we see this in the different MACs.  CSMA (as in WiFi) is what we
> used to call 'free net' and crashes under overload.  TDMA MACs like that in
> 802.16 are what we used to call 'directed net' and are stable (and near-
> deterministic).

How does this requirement fits to the work that IETF needs to do? 
Please provide the requirement that the Geonet solution will need to support?

Best regards,
Georgios

> From: Rex Buddenberg [mailto:[email-masked]]
> Sent: dinsdag 14 januari 2014 20:28
> Cc: [email-masked]; [email-masked]
> stochasticism.  Because deterministic systems are stable under overload.
>      At layer 2 we see this in the different MACs.  CSMA (as in WiFi) is what we
> used to call 'free net' and crashes under overload.  TDMA MACs like that in
> 802.16 are what we used to call 'directed net' and are stable (and near-
> deterministic).

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 15 Jan 2014 13:46:30 +0100

Le 15/01/2014 09:02, [email-masked] a écrit :
> Hi Rex,
>
> Thanks for the comment, however, I have a question regarding your
> proposed text for the stability requirement:
>
>> s/scaleable/stable Reason.  Spectrum is an inelastic resource so
>> you can't just up comms capacity when sources increase.  What is
>> important is determinism vs stochasticism.  Because deterministic
>> systems are stable under overload. At layer 2 we see this in the
>> different MACs.  CSMA (as in WiFi) is what we used to call 'free
>> net' and crashes under overload.  TDMA MACs like that in 802.16 are
>> what we used to call 'directed net' and are stable (and near-
>> deterministic).
>

Sorry for interfering in your exchange, but I believe his remark - to

> The specified mechanisms and protocol solutions:
[...]

To accommodate his remark maybe we could rather say:

> SHOULD be able to scale, leverage on stable and deterministic
> underlayers when available, and maintain its performance to
> acceptable levels even if it is applied to: (1) global coverage with

Would this read better?

Alex

>
> Best regards, Georgios
>
>
>
>
>
>> -----Original Message----- From: Rex Buddenberg
>> [mailto:[email-masked]] Sent: dinsdag 14 januari 2014 20:28
>> To: Karagiannis, G. (EWI) Cc: [email-masked];
>> [email-masked] Subject: Re: [geonet/its] new
>> descriptions of Geonet problem, challenges, requirements,
>> assumptions + request for volunteers
>>
>>> small target/destination geographic areas, (2) large traffic
>>> volumes (large flows), (3) large number of active sources
>>
>> s/scaleable/stable
>>
>> Reason.  Spectrum is an inelastic resource so you can't just up
>> comms capacity when sources increase.  What is important is
>> determinism vs stochasticism.  Because deterministic systems are
>> stable under overload. At layer 2 we see this in the different
>> MACs.  CSMA (as in WiFi) is what we used to call 'free net' and
>> crashes under overload.  TDMA MACs like that in 802.16 are what we
>>  used to call 'directed net' and are stable (and near-
>> deterministic).
>

---

From: <[email-masked]>
Date: Wed, 15 Jan 2014 12:49:21 +0000

Hi Alex,

Okay, your proposed txt is fine for me!

Best regards,
Georgios

> Sent: woensdag 15 januari 2014 13:47
> To: [email-masked]
> >> s/scaleable/stable Reason.  Spectrum is an inelastic resource so you
> >> can't just up comms capacity when sources increase.  What is
> >> different MACs.  CSMA (as in WiFi) is what we used to call 'free net'
> >> and crashes under overload.  TDMA MACs like that in 802.16 are what
> >> we used to call 'directed net' and are stable (and near-
> >> deterministic).
> >
> Sorry for interfering in your exchange, but I believe his remark - to which I
> agree separately - is about this GeoNet requirement:
> 
> > underlayers when available, and maintain its performance to acceptable
> > levels even if it is applied to: (1) global coverage with small
> > target/destination geographic areas, (2) large traffic volumes (large
> > flows), (3) large number of active sources
> 
> Would this read better?
> 
> Alex
> 
> 
> 
> 
> >
> > Best regards, Georgios
> >
> >
> >
> >
> >
> >> descriptions of Geonet problem, challenges, requirements, assumptions
> >> + request for volunteers
> >>
> >> overload. At layer 2 we see this in the different MACs.  CSMA (as in
> >> WiFi) is what we used to call 'free net' and crashes under overload.
> >> TDMA MACs like that in 802.16 are what we  used to call 'directed
> >> net' and are stable (and near- deterministic).
> >

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 15 Jan 2014 08:07:20 -0800

Giorgios, Alex,

For the last forty years, we've managed QoS control by increasingly
overprovisioning the internet.  Today, the terrestrial internet is
largely congestion-free simply because it is so capacious.
     Topology.  WiFi in the internet today is all at the fringe -- it's
used as a LAN interconnecting last router and end systems.
     
But what you're discussing here changes both: above topology changes to
having a radio-WAN in the interior of the network rather than at the
fringe (thus my use of the term radio-WAN rather than LAN).  This means
we have gigabit plumbing on all sides of a megabit (on good days) comms
path.  It will always be the bottleneck and we can't make it arbitrarily
bigger by adding more lambdas like we do with fiber optic.  
     Scaleability implies to me adding more bandwidth and we're simply
not going to be able to do that unless God is on the [its] list and
decides to contribute by making more spectrum.  Stability, on the other
hand, means that we can add more customers (e.g. more automobiles)
without crashing the system.  
      
Since you asked ... this is a reprise of phenomena we've seen before.
'Real time' operating systems (there are still a few out there) do not
have infinite processing power but rather run processes with a time
limit on each so that all pending processes get a chance (again,
overprovisioning, this time in the form of lotsa CPU horsepower, has
subdued the discussion).  The point is stability under overload because
you can't make the overload go away.
     We went through the same discussions with wired LANs about 25 years
ago.  Ethernet has contention MAC which does indeed crash under
overload.  Token rings (including FDDI as well as 802.5) were
deterministic and non-contention and therefore more stable under
overload.  Again, the discussion was submerged by the takeoff in
capacity -- you ceased hearing about it as soon as we left the
neighborhood of 10M ethernet.  

Help?

(Part of the problem I'm dealing with reading all this is that I can't
tell what layer of the model you're at.  Hopefully as the problem
statement matures this will straighten out.  This particular problem has
historically been at layer 2 (contention MACs crash under overload).
Ironically the solution (DS) has been at layer 3.  ... except that we
tend to miss the MAC discussion which often makes the layer 3 issues
moot.

> Reason.  Spectrum is an inelastic resource so