Subject: [dtn] DTN use cases

From: Marc Blanchet <[email-masked]>
Date: Tue, 17 Feb 2015 11:33:13 -0500

Hello,
 The list of DTN use cases has been edited and are located at: http://trac.tools.ietf.org/wg/dtn/trac/wiki/DtnUseCases

Do we have concensus that this list represents a good (no need for perfect, nor exhaustive) set of use cases that we can build on?

Regards, Marc.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 17 Feb 2015 17:02:12 +0000

I think this list is a good basis for our work.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Marc Blanchet
Sent: Tuesday, February 17, 2015 8:33 AM
To: [email-masked]
Subject: [dtn] DTN use cases

Hello,

Regards, Marc.
_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: Gelard Patrick <[email-masked]>
Date: Wed, 18 Feb 2015 07:57:29 +0000

Hello

I don't see requirement about Broadcast, Multicasting in DTN.  

For example in the context of "Vehicles communicate with each other for road safety, traffic monitoring, navigation, etc." (Vehicular ad hoc networks ("Vanet") context) there is a problematic of broadcasting/multicasting the  safety  message  to  the  vehicles, in the geographical region call zone of relevance, when for example any accident  occurs  on  the  highway. Many scenario of traffic exist (Dense/broadcast storm problem,  Sparse/Broadcast hole problem,  regular/irregular topology problem).

Best Regards,
Patrick

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 18 Feb 2015 09:56:35 +0000

Hi Marc,

I think that this list is exhaustive!
Furthermore, for the vehicular use case, one should note that VANETs
exhibit bipolar behavior depending on network topology: fully connected
topology with high traffic volume or sparsely connected topology
when traffic volume is low. Thus, vehicular networks may deliver data using
the store-carry-and-forward (SCF) paradigm of DTNs rather than a simple
carry-and-forward method.

On Wed, Feb 18, 2015 at 7:57 AM, Gelard Patrick <[email-masked]>
wrote:

> For example in the context of "Vehicles communicate with each other for
> road safety, traffic monitoring, navigation, etc." (Vehicular ad hoc
> networks ("Vanet") context) there is a problematic of
> broadcasting/multicasting the  safety  message  to  the  vehicles, in the
> geographical region call zone of relevance, when for example any accident
> occurs  on  the  highway. Many scenario of traffic exist (Dense/broadcast
> storm problem,  Sparse/Broadcast hole problem,  regular/irregular topology
> problem).
>
> Best Regards,
> Patrick
>

-- 

Best Regards

*nabilbenamar.ipv6-lab.net <http://nabilbenamar.ipv6-lab.net/>*

---

From: Gelard Patrick <[email-masked]>
Date: Wed, 18 Feb 2015 13:09:52 +0000

Hi Nabil,

I am Patrick.

>> Thus, vehicular networks may deliver data using the store-carry-and-forward (SCF) paradigm of DTNs rather than a simple carry-and-forward method.

How this sentence answers the need of send the same message to a group of terminal ?

What is the meaning of carry-and-forward without storage ?

For a network node if we don't have any contact / link we have the choice : delete the block of information (IP network) or store the block of information (DTN network) independently of the movement of the node.

What is the meaning of carry in the context of Telecom ? Since Galileo Galilei we know that the movement is as nothing ( http://en.wikipedia.org/wiki/Galilean_invariance ) thus how the concept of carry are represented in the context of telecom ? 

Best Regards
Patrick

---------------------------------------------------------------------------------------------------------------------------------------
De : Nabil Benamar [mailto:[email-masked]] 
Envoyé : mercredi 18 février 2015 10:57
À : Gelard Patrick
Cc : [email-masked]
Objet : Re: [dtn] DTN use cases

Hi Marc,

I think that this list is exhaustive! 
Furthermore, for the vehicular use case, one should note that VANETs exhibit bipolar behavior depending on network topology: fully connected topology with high traffic volume or sparsely connected topology when traffic volume is low. Thus, vehicular networks may deliver data using the store-carry-and-forward (SCF) paradigm of DTNs rather than a simple carry-and-forward method.

On Wed, Feb 18, 2015 at 7:57 AM, Gelard Patrick <[email-masked]> wrote:
Hello

Best Regards,
Patrick

-- 

Best Regards

nabilbenamar.ipv6-lab.net

---

From: Nabil Benamar <[email-masked]>
Date: Wed, 18 Feb 2015 19:59:07 +0000

Hi Patrick,

My comment is about VANETs vs VDTNs when it comes to routing protocols.

Nodes in DTN context operate in a store, carry and forward

(SCF) manner. A DTN node needs to take custody of a bundle until

it is either delivered to the destination or another DTN node has

taken custody of it after coming into contact. This behavior doesn't exist
in MANETs !

In VDTN, the nodes (vehicles) store and carry network data

while waiting for opportunities to forward it. Thus, in VDTN, the

vehicles are also used to carry the data towards the destination,

which is unlike the other non-VDTN approaches for VANETs.

On Wed, Feb 18, 2015 at 1:09 PM, Gelard Patrick <[email-masked]>
wrote:

> Hi Nabil,
>
> I am Patrick.
>
> >> Thus, vehicular networks may deliver data using the
> store-carry-and-forward (SCF) paradigm of DTNs rather than a simple
> For a network node if we don't have any contact / link we have the choice
> : delete the block of information (IP network) or store the block of
> information (DTN network) independently of the movement of the node.
>
> What is the meaning of carry in the context of Telecom ? Since Galileo
> Galilei we know that the movement is as nothing (
> http://en.wikipedia.org/wiki/Galilean_invariance ) thus how the concept
> of carry are represented in the context of telecom ?
>
> Best Regards
> Patrick
>
>

-- 

Best Regards

---

From: Joerg Ott <[email-masked]>
Date: Sat, 21 Feb 2015 16:56:18 +0200

Hi,

nice list, but I would actually add some minimal structure as I would
see at least two different "classes" of use cases.

1) Those that have a clear and immediate need for DTN and also feature
    industry already embracing DTN as part of the solution.  This would
    include:
    -- Space Systems Communications
    -- Unmanned Air Systems (UAS) in Integrated Air Space
    -- Unmanned Underwater Vehicles (UUV)

    and to some extent
    -- Disaster Response and Humanitarian Aid
    and maybe others

2) Those that could benefit from DTN but have disjoint industries
    (read: those not involved here) driving the respective technologies.
    I would include:
    -- Vehicular Delay Tolerant Networks
    -- Civil Aviation

I would suggest focusing on the former and keeping the others on the
backburner, knowing that technologies will likely be different and
thus whatever requirements there might be, those may not need be
hard ones or ones to address soonish.  This doesn't mean that we
cannot build stuff that would also work there, but it's not a priority.

Jörg

---

From: [email-masked]
Date: Sun, 22 Feb 2015 13:37:52 +0100 (CET)

Hi Jörg,

Do you have factual references about the use of DTN in operationnal project and not in experimental project ?

Best Regards,
Patrick

----- Mail original -----
De: "Joerg Ott" <[email-masked]>
À: "Marc Blanchet" <[email-masked]>, [email-masked]
Envoyé: Samedi 21 Février 2015 15:56:18
Objet: Re: [dtn] DTN use cases

Hi,

    and to some extent

Jörg

---

From: "Will Ivancic" <[email-masked]>
Date: Sun, 22 Feb 2015 13:57:28 -0500

I'll state it one more time.  Unmanned Air Vehicles (UAVs) are  not a valid use case with regards to air traffic control and air traffic management.  Previous posts have given the regulations.  The ATC communication system is design for continuous communication over the Continental US.  Other Countries have similar regulations.

Regarding Small UAVs:  here is the recent proposal.  Basically, you must be in continuous control of your UAV.

http://www.faa.gov/news/press_releases/news_story.cfm?newsId=18295

Will Ivancic

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, February 22, 2015 7:38 AM
To: Joerg Ott
Cc: [email-masked]
Subject: Re: [dtn] DTN use cases

Hi Jörg,

Best Regards,
Patrick

----- Mail original -----
De: "Joerg Ott" <[email-masked]>
À: "Marc Blanchet" <[email-masked]>, [email-masked]
Envoyé: Samedi 21 Février 2015 15:56:18
Objet: Re: [dtn] DTN use cases

Hi,

nice list, but I would actually add some minimal structure as I would see at least two different "classes" of use cases.

    and to some extent

I would suggest focusing on the former and keeping the others on the backburner, knowing that technologies will likely be different and thus whatever requirements there might be, those may not need be hard ones or ones to address soonish.  This doesn't mean that we cannot build stuff that would also work there, but it's not a priority.

Jörg

On 17.02.2015 18:33, Marc Blanchet wrote:
> Hello,
>   The list of DTN use cases has been edited and are located at: 
> http://trac.tools.ietf.org/wg/dtn/trac/wiki/DtnUseCases
>

---

From: Joerg Ott <[email-masked]>
Date: Sun, 22 Feb 2015 21:37:20 +0200

Well, I don't need this use case.  For data collection (rather than
command & control) I have seen diverse bits of work using DTN, party
in the US, partly in other countries.  But maybe people just didn't
get close enough to reality.

Jörg

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Mon, 23 Feb 2015 14:19:02 +0000

We looked at using DTN on the NASA GlobalHawk UAVs for science data.  The
problem is, DTN really doesn't buy you anything in a single hop network.
If you're not connected you store.  Once you're connected, you are
connected to the Internet and can just use whatever set of tools you want.
 The Principal Investigators basically used RSYNC to synchronize the UAV
and Ground databases.  The UAV only stayed out for 30 hours max, so you
can really dump your data once you returned for super large data sets.
Depending on the instrument, rsync worked or you had to get to the ground
and dump as the satellite link capacity 2 - 8 Mbps simply wasn't
sufficient to get the data off the vehicle.

The same holds for LEO science spacecraft.  It is a single hop to the
Internet.  Us an efficient transport protocol like Saratoga to get data to
the ground and go from there with existing tools.

Will

On 2/22/15 2:37 PM, "Joerg Ott" <[email-masked]> wrote:

>> I'll state it one more time.  Unmanned Air Vehicles (UAVs) are  not a
>>valid use case with regards to air traffic control and air traffic
>>management.  Previous posts have given the regulations.  The ATC
>>communication system is design for continuous communication over the
>>Continental US.  Other Countries have similar regulations.
>>
>> Regarding Small UAVs:  here is the recent proposal.  Basically, you
>>must be in continuous control of your UAV.
>>
>> Do you have factual references about the use of DTN in operationnal
>>project and not in experimental project ?
>>
>> Best Regards,
>> Patrick
>>
>>backburner, knowing that technologies will likely be different and thus
>>whatever requirements there might be, those may not need be hard ones or
>>ones to address soonish.  This doesn't mean that we cannot build stuff
>>that would also work there, but it's not a priority.
>>
>> Jörg
>>
>>
>>> Do we have concensus that this list represents a good (no need for
>>>perfect, nor exhaustive) set of use cases that we can build on?
>>>
>>> Regards, Marc.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 23 Feb 2015 14:56:15 +0000

This is actually not correct, Will.  DTN buys you plenty on a "single hop" network, because none of these networks are actually single hop.  There's only one hop that is discontinuous, but there are always other hops on the ground, and there may additionally be other hops on the vehicle, as on the International Space Station.

At either end of the discontinuous hop, you're right, when you're not connected you store; when you're connected, you transmit.  DTN does exactly that, in an openly defined, interoperable, automatic manner rather than using ad hoc, home-grown expedients.  Beyond this, though, it establishes end-to-end communication relationships that automatically span both the discontinuous hop and the continuous Internet hops, so that the application is insulated from the underlying differences.  This is sort of like the way IP establishes end-to-end communication relationships that automatically span both wired and wired network hops, insulating Internet applications from the differences between Ethernet and 802.11.

You can always use existing tools to do anything, if you're willing to construct enough ad hoc stuff to do all the things that the existing tools don't do.  What DTN buys you is not needing to construct much additional stuff.

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Ivancic, William D. (GRC-LCA0)
Sent: Monday, February 23, 2015 6:19 AM
To: Joerg Ott; Will Ivancic; [email-masked]
Cc: [email-masked]
Subject: Re: [dtn] DTN use cases

We looked at using DTN on the NASA GlobalHawk UAVs for science data.  The problem is, DTN really doesn't buy you anything in a single hop network.
If you're not connected you store.  Once you're connected, you are connected to the Internet and can just use whatever set of tools you want.
 The Principal Investigators basically used RSYNC to synchronize the UAV and Ground databases.  The UAV only stayed out for 30 hours max, so you can really dump your data once you returned for super large data sets.
Depending on the instrument, rsync worked or you had to get to the ground and dump as the satellite link capacity 2 - 8 Mbps simply wasn't sufficient to get the data off the vehicle.

The same holds for LEO science spacecraft.  It is a single hop to the Internet.  Us an efficient transport protocol like Saratoga to get data to the ground and go from there with existing tools.

Will

On 2/22/15 2:37 PM, "Joerg Ott" <[email-masked]> wrote:

>command & control) I have seen diverse bits of work using DTN, party in 
>the US, partly in other countries.  But maybe people just didn't get 
>close enough to reality.
>
>Jörg
>
>>thus whatever requirements there might be, those may not need be hard 
>>ones or ones to address soonish.  This doesn't mean that we cannot 
>>build stuff that would also work there, but it's not a priority.
>>
>> Jörg
>>
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 Feb 2015 15:54:11 +0000

Hi Will,

> From: dtn [mailto:[email-masked]] On Behalf Of Will Ivancic
> Sent: Sunday, February 22, 2015 10:57 AM
> To: [email-masked]; 'Joerg Ott'
> Cc: [email-masked]
> I'll state it one more time.  Unmanned Air Vehicles (UAVs) are  not a valid use case with regards to air traffic control and air traffic
> management.  Previous posts have given the regulations.

We need to separate regulations from reality. In the real world, UAVs are going to
wander away from line of sight and may experience lost or disrupted comms regardless
of what regulations say. What are they supposed to do then? Self-destruct?

If a UAV experiences loss or disruption of comms for some period, the operator will
want to know what the UAV experienced once comms are restored. Hence, a use
case for DTN.

> The ATC communication system is design for continuous communication
> over the Continental US.

The ATN backbone should indeed support continuous communications, yes.
But, the "last mile" between the ATN and airborne vehicles may be disrupted.

> Other Countries have similar regulations.

I didn't see what the regulations had to say about loss of comms or communications
during periods of disruption. Is it self-destruct only, or is there some sort of
recovery procedure? If there is a recovery procedure, DTN should be part of it.

> http://www.faa.gov/news/press_releases/news_story.cfm?newsId=18295

Continuous control is always true except for when it isn't. Hence, a use case
for DTN.

Thanks  - Fred
[email-masked]

> I would suggest focusing on the former and keeping the others on the backburner, knowing that technologies will likely be different
> and thus whatever requirements there might be, those may not need be hard ones or ones to address soonish.  This doesn't mean
> that we cannot build stuff that would also work there, but it's not a priority.
> 
> Jörg
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 Feb 2015 16:24:16 +0000

Hi Will,

> sufficient to get the data off the vehicle.

What about UAV-to-UAV comms? That would be a multi-hop, right?

Thanks - Fred

---

From: "Ivancic, William D. (GRC-LCA0)" <[email-masked]>
Date: Mon, 23 Feb 2015 17:02:27 +0000

In Line

>What about UAV-to-UAV comms? That would be a multi-hop, right?

Absolutely, but I was answering the question posed. "Do you have factual
references about the use of DTN in operational project and not in
experimental project?"

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 Feb 2015 18:05:55 +0000

Hi Marc,

I went through the list comments, and the majority were suggesting additions
to the use cases and not changes to what is already there. (I think Joerg
suggested a prioritization, but not sure whether we need to do anything
about that now?)

As such, I have compiled a "TODO" list of items to add in the next version but
I don't think that should stop us from moving forward with what is already in
the list as it currently stands.

Can we move forward with what we currently have and then bring in any
additions and/or prioritizations later?

Thanks - Fred

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 26 Feb 2015 11:53:36 -0500

do people think the set of use cases are in enough stable form? (short support statement such as « yes » is useful, « no » would need a bit of explanation)

Thanks, Marc.

> Le 2015-02-23 à 13:05, Templin, Fred L <[email-masked]> a écrit :
> 
> Hi Marc,
>

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 26 Feb 2015 16:54:35 +0000

Yes.

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Marc Blanchet
Sent: Thursday, February 26, 2015 8:54 AM
To: [email-masked]
Subject: Re: [dtn] DTN use cases

Thanks, Marc.

> I went through the list comments, and the majority were suggesting 
> additions to the use cases and not changes to what is already there. 
> (I think Joerg suggested a prioritization, but not sure whether we 
> need to do anything about that now?)
> 
> As such, I have compiled a "TODO" list of items to add in the next 
> version but I don't think that should stop us from moving forward with 
> what is already in the list as it currently stands.
>

---

From: Joerg Ott <[email-masked]>
Date: Thu, 26 Feb 2015 19:01:11 +0200

As I said: they are useful, but they are of different quality.
I would suggest expressing the 'closeness to some reality' in those
use cases.  And others pointed out that not all use cases are feasible
such as UAVs due to regulations.  Those would need clarification.

Cheers,
Jörg

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Feb 2015 17:15:33 +0000

Hi Joerg,

> From: dtn [mailto:[email-masked]] On Behalf Of Joerg Ott
> Sent: Thursday, February 26, 2015 9:01 AM
> To: Marc Blanchet; [email-masked]
> use cases. 

Do you have specific insights into some of the use cases in order
to make recommendations on closeness to reality?

> And others pointed out that not all use cases are feasible

I am trying to understand "not all use cases are feasible". DTN for
UAVs is for safe operation in off-nominal conditions. Regulations
can stipulate behavior in nominal conditions, but when nominal
conditions break down there still needs to be some safety net.

Thanks - Fred

---

From: Joerg Ott <[email-masked]>
Date: Thu, 26 Feb 2015 20:02:11 +0200

Hi Fred,

as I wrote before: I don't see a vehicular networking use case for
DTNs anywhere close to reality, at least not using the bundle
protocol.

Jörg

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Feb 2015 18:18:06 +0000

Hi Joerg,

> From: Joerg Ott [mailto:[email-masked]]
> Sent: Thursday, February 26, 2015 10:02 AM
> To: Templin, Fred L; Marc Blanchet; [email-masked]

There are many different classes of "vehicles", and not all of them are
the cars we drive on well-established roads and highways. So, it is not
necessarily all about vehicles used for public transportation. Does this
need clarification?

Thanks - Fred

---

From: Joerg Ott <[email-masked]>
Date: Thu, 26 Feb 2015 20:30:22 +0200

Hi Fred,

then I guess this will need clarification.  The term vehicular
networking has a certain mainstream connotation and without
disambiguation this is misleading (apparently :-)

Cheers,
Jörg

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Feb 2015 18:39:49 +0000

Hi Joerg,

How does this look as a rewrite:

OLD:
---
o Vehicles communicate with each other for road safety, traffic monitoring, navigation, etc. 
o Infreqenet transmission opportunities due to intermittent signals, sparse traffic conditions, terrain features etc. 
o Short contacts between vehicles passing
---

NEW:
---
o Many classes of vehicles, including personal automotive, public transportation, commercial
    fleets, law enforcement, expeditionary forces, etc.
o More limited-scale applications (e.g., law enforcement) likely before full-scale adoption (e.g.,
    personal automotive)  
o Vehicles communicate with each other for road safety, traffic monitoring, navigation, information sharing, etc. 
o Infrequent transmission opportunities due to intermittent signals, sparse traffic conditions, terrain features etc. 
o Short contacts between vehicles passing
---

Thanks - Fred

> Sent: Thursday, February 26, 2015 10:30 AM
> >>>>> do people think the set of use cases are in enough stable form? (short support statement such as « yes » is useful, « no »
> would
> >>>> need a bit of explanation)
> >>>>>
> >>>>> Thanks, Marc.
> >>>>>
> >>>>>>> Do we have concensus that this list represents a good (no need for perfect, nor exhaustive) set of use cases that we can
> build
> >> on?
> >>>>>>>
> >>>>>>> Regards, Marc.

---

From: Joerg Ott <[email-masked]>
Date: Fri, 27 Feb 2015 10:23:57 +0200

Hi Fred,

not yet convinced.  Two of the last three bullets (left unchanged)

o Vehicles communicate with each other for road safety, traffic
   monitoring, navigation, information sharing, etc.
o Infrequent transmission opportunities due to intermittent signals,
   sparse traffic conditions, terrain features etc.

suggest that you look into mainstream vehicular communications.
I don't mind doing this if we have the right industry expertise
and backing.  This is no longer a research group.

Jörg

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Feb 2015 16:10:42 +0000

Hi Joerg,

> Sent: Friday, February 27, 2015 12:24 AM

Are you suggesting there is something wrong with these with respect
to the new bullets I proposed? I don't see a problem. For example, if
a major metropolatin area's law enforcement vehicles all started using
DTN  but no personal vehicles did, the above two bullets apply even
though it is only the law enforcement vehicles and no others that are
engaged in the DTN. What in the above do you think needs to change?

> suggest that you look into mainstream vehicular communications.

I don't think an exhaustive investigation of mainstream vehicular 
communications is necessary in order to support this text going
forward - there are many other examples for vehicular comms
as I have noted.

> and backing.

Also do not think we need to wait for major automotive industry
players to come on board - that might not happen for a long time.

> This is no longer a research group.

Correct. It is a "get things done" group in order to satisfy the use
cases. So, let's start moving forward.

Thanks - Fred

---

From: Joerg Ott <[email-masked]>
Date: Fri, 27 Feb 2015 18:19:35 +0200

Hi Fred,

> players to come on board - that might not happen for a long time.

right.  So, you don't have a real use case because the people who
would articulate it aren't there.  That's my point.

> cases. So, let's start moving forward.

I made my point and I am not going to argue this further.  So, we can
move ahead.

Cheers,
Jörg

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Feb 2015 17:07:04 +0000

Hi Joerg,

> Sent: Friday, February 27, 2015 8:20 AM

My industry cares about vehicular communications in limited applications, so
the use case is there. Maybe this would be fixed by taking out the "personal
automotive" for now. How does this look as a rewrite:

OLD:
---
o Vehicles communicate with each other for road safety, traffic monitoring, navigation, etc. 
o Infreqenet transmission opportunities due to intermittent signals, sparse traffic conditions, terrain features etc. 
o Short contacts between vehicles passing
---
NEW:
---
o Vehicular communications in limited-scale applications, including public transportation,
    commercial fleets, law enforcement, expeditionary forces, etc.
o Vehicles communicate with each other for road safety, traffic monitoring, navigation, information sharing, etc. 
o Infrequent transmission opportunities due to intermittent signals, sparse traffic conditions, terrain features etc. 
o Short contacts between vehicles passing
---

?

Thanks - Fred

---

From: Joerg Ott <[email-masked]>
Date: Fri, 27 Feb 2015 19:31:58 +0200

Hi Fred,

this is a better reflection I think.  It would also capture a
flavor of this use case in industrial applications involving
dedicated vehicles we are working on, but would not be misleading
towards the general C2X use case.

Cheers,
Jörg

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 27 Feb 2015 12:50:12 -0500

>> forward - there are many other examples for vehicular comms

Why are we talking about *standardizing* a solution to a problem that 
has not been completely explored by anyone represented in this group?

Personally, I strongly believe that an exhaustive investigation into 
vehicular communications would be a good idea *if* such is going to be 
listed as a use case for this protocol.  The burden should be on *us* 
("us", in this case, being the individual stakeholder representing the 
technology) to understand the applicability of a technology to a problem 
*before* it is included as a work item targeted by an engineering 
standards body, I think.

If there is no stakeholder present to champion a specific use case, I 
would argue that it should not be listed (or even really considered) at 
all.  We can worry about it if a stakeholder shows up.

> would articulate it aren't there.  That's my point.

I feel like the time it would take for major automotive industry players 
(or any other industry players, for that matter) to come on board is 
irrelevant.  We're working through this protocol *now*.  As such, only 
those who are here *now* will get to influence the result.  We shouldn't 
be waiting for *anyone* in particular to join or leave the project, 
regardless of how useful we believe DTN would (or wouldn't) be to the 
industry or interest they happen to represent.

For what it's worth,
Gilbert Clark

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Feb 2015 18:35:22 +0000

Hi Gilbert,

I consider my industry to be a stakeholder for special-purpose vehicular
communications as indicated in my responses to Joerg. That said, I agree
with you and Joerg that we should not list the general-purpose automotive
use case since we do not have stakeholders from that industry; hence,
my proposed rewording:

OLD:
---
o Vehicular communications in special-purpose applications, including public transportation,

Does it work for you?

Thanks - Fred

PS Notice I substituted "special-purpose" for "limited-scale". Let me know if
      that is not OK.

> From: dtn [mailto:[email-masked]] On Behalf Of Gilbert Clark
> Sent: Friday, February 27, 2015 9:50 AM
> To: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Feb 2015 20:53:04 +0000

Hello,

I updated the use cases to clarify the vehicular use case per list discussions:

https://tools.ietf.org/wg/dtn/trac/wiki/DtnUseCases#

Please note that I am still maintaining a laundry list of items to add based
on mailing list input, but would prefer to hold off on those for now until
we can declare consensus on what we already have.

Any further comments on this version?

Thanks - Fred

---

From: Gilbert Clark <[email-masked]>
Date: Fri, 27 Feb 2015 19:32:19 -0500

No further objections here.  Thanks for addressing this.

Cheers,
Gilbert