Subject: [geonet/its] suggestions about charter scope limitation and the specific language

From: Alison Chaiken <[email-masked]>
Date: Sat, 16 Nov 2013 18:28:31 -0800

Scope limitation
==================

State explicitly that means of specification of a geographic area is
out of scope, as Carl Reed (and others) have enumerated applicable
methods.

Semantics
==========

The word "mapping" to describe a logical assignment of one sets of
objects into another is descriptive and is used here with a familiar
computer science meaning.  Nonethess, because "mapping" is such a
loaded term in the geoaware context, we should avoid it to describe
logical relationships in order to prevent confusion.

Regarding the term RSU:
Presumably the only necessary condition for a road-side unit is that
it be networked and roadside.   While most RSUs will in fact be
permanently installed, is there any reason not to call mobile access
routers RSUs if they serve the same function as permanent ones?
Perhaps the distinction we need is between "infrastructure" units and
mobile ones?

Regarding the term "access router":
Are access routers necessarily involved in the last hop?

Draft markup
===============

1. Original:

"Standardized protocol(s) is/are needed to allow source nodes anywhere
in the Internet to disseminate packets to all/any node(s) with
geographic location awareness within a specified destination area."

Instead:

Standardized protocol(s) is/are needed to allow source nodes anywhere
in the Internet to disseminate packets to all/any node(s) within a
specified destination area.

Rationale: assuredly the recipient need not be aware of its location?
 For the roll-out of the new protocol, senders may wish to send
messages via geoaware intermediates to endpoints who themselves are
not geoaware if the endpoints are permanently installed and mapped
geographically.

Or,

Standardized protocol(s) is/are needed to allow source nodes anywhere
in the Internet to disseminate packets to all/any node(s) within a
specified destination area via a geoaware access router.

2. Original:

o) Mechanisms and/or protocol solutions are needed to ensure that
geographical information  is available in the addressing mechanism,
such that packets can be forwarded to a target geographical area.

Proposal:

o) Mechanisms and/or protocol solutions are needed to ensure that
geographical information  is available in the addressing mechanism,
such that packets can be forwarded to *or received from* a target
geographical area.

response to Rex Buddenberg
============================
"If we are after a geography-aware routing information protocol,
then what's different from OLSR in MANET?  Tying routing to earth
geography rather than internet geography is trying to square a circle.
Particularly when you account for the facts that LANs and terrestrial
WANs have about four orders of magnitude more capacity than
radio-WANs."

Rex's remarks raise the point that a purely geographic routing method
might transit through radio-WANs even if the endpoint is permanently
installed.   Or is there an obvious way to prevent this?   Perhaps
such a discussion is too solution-oriented, but even if we don't want
to suggest a particular solution, it makes to consider whether one
exists.

response to Melinda Shore
============================

"You might want to spell out what "with geographic location awareness" means."

Many of the applicable terms (e.g. geomulticast, geounicast) are
defined clearly in previous standards.   Perhaps we should back off
drafting a charter and work on a taxonomy or glossary first?    It
strikes me that if we can agree on the relevant objects and their
methods, then we have a common basis for moving forward.   Proceeding
to have these discussions without a shared vocabulary may be
inefficient.

I volunteer to start a shared editable document where we can start to
created a glossary if others would welcome that.    Speaking of which,

Meta question
===============

Might  we have a Wiki or group doc with version control in order to
share suggestions about charter language?    Or do we have one already
that I missed?    Some of Mike Kallas' comments suggested that there
is a shared document somewhere that he is maintaining.

-- 
Alison Chaiken                           [email-masked]
650-279-5600                            http://{she-devel.com,
exerciseforthereader.org}
It's a bug that cars were invented before computers.    -- Eric Schmidt

---

From: Melinda Shore <[email-masked]>
Date: Sat, 16 Nov 2013 17:34:14 -0900

On 11/16/13 5:28 PM, Alison Chaiken wrote:
> Perhaps we should back off
> drafting a charter and work on a taxonomy or glossary first?    

In general I think it's sufficient to define terms in the
charter for this sort of thing, but if there's a gap between
how language is used in the IETF and in other communities
it's probably a good idea to get that sorted out sooner
rather than later.  I keep coming back to nvo3 as an example
of a working group in difficult straits but they spent
several unproductive months dealing with terminology.
I think it can be avoided here if it's spelled out earlier
in the process.

> is a shared document somewhere that he is maintaining.

Good suggestion.

Melinda

---

From: Rex Buddenberg <[email-masked]>
Date: Sat, 16 Nov 2013 19:13:17 -0800

Good discussion, Alison ... response on this:

> Perhaps the distinction we need is between "infrastructure" units and

To my knowledge, RSU is not a standard term but rather a vendor-oriented
packaging one.  

The _typical_ roadside unit would have 
 - terrestrial-WAN backside connection.
 - a router.
 - one or more radio-WAN base stations.  The term base station has
accepted meaning within IEEE 802.16 for this component.
 - power supply.  At least some, if they're deemed mission critical,
would have both grid power and backup.
 - SNMP agent that reaches to all these components.
 - layer 7 gateway if there is non-routable network connects, like to
P25 voice or non-protocol Land Mobile Radio.  

Now, there are a variety of atypical configurations depending...
 - 'quick deploy' models that might use something like 802.16
connections in place of the terrestrial-WAN.  Think hurricane response.
Since these might be in places other than along roads (or the road might
no longer exist;-), still wanna call them RSUs?
 - mobile models that are installed in, say, a fire truck or a comms
van.
 - ... would you still want to call these RSUs?

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Nov 2013 12:07:02 +0100

Le 17/11/2013 03:28, Alison Chaiken a écrit :
[...]
> Meta question

I wonder the same.

Is there a WiKi or group doc with or w/o version control in order to 
share suggestions about charter?

Also, about the Mike Kallas document - is it available somewhere at an URL?

About working together live on a document, maybe we could use Etherpad. 
  It is a tool at IETF that was used for scribing during the meeting.  I 
guess we could use it to develop any other IETF-related document:

http://etherpad.tools.ietf.org:9000/p/geonet-charter

Alex

---

From: Alison Chaiken <[email-masked]>
Date: Fri, 22 Nov 2013 17:49:59 -0800

> share suggestions about charter?

Etherpad looks nice enough to me.   Friends suggested
http://gist.github.com/ as an alternative.    Either looks fine to me.
   I'd be happy to help with two pages, one about Use Cases and one
about terminology.

-- Alison

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 25 Nov 2013 10:21:47 +0100

Le 23/11/2013 02:49, Alison Chaiken a écrit :
>> Is there a WiKi or group doc with or w/o version control in order
>> to share suggestions about charter?
>

I just looked at github's gist. It seems to be offering similar
functionality as etherpad, maybe improved with private/public features.

I would prefer Etherpad since it's hosted at IETF.

> I'd be happy to help with two pages, one about Use Cases and one

Alison - thank you for the offer.  We definitely need to get this going.

Whereas the Charter text may contain text about usecases and
terminology, I think it should be only briefly mentioned; details should
be in drafts.

Some use-cases and terminology are in the existing problem statement
draft-karagiannis-problem-statement-geonetworking; we may need to
discuss them further, and why not based on new drafts.

To that end, I think it is a good idea that you start writing about
Use-Cases and Terminology in that Etherpad geonet-charter.  We may
extract parts from it later?
http://etherpad.tools.ietf.org:9000/p/geonet-charter

How do you see it?

Yours,

Alex