Subject: [Rmt] IETF74 FCAST Action Item

From: Brian Adamson <[email-masked]>
Date: Thu, 16 Apr 2009 11:12:05 -0400

Hello,

During discussions at the IETF74 RMT meeting, we concluded that we  
should poll the mailing list to determine if there is sufficient  
interest in adding the new FCAST document and pursuing it as an RMT  
working group item.  There was some interest expressed during the  
working group meeting and a number of folks raised their hands  
indicating they would review the document (i.e. we need broader  
participation than just the document authors!)

This message requests interested parties to respond on the mailing  
list to indicate their opinion on this:

1) Do you think there is merit in the FCAST specification as an RMT WG  
item (or not)?

2) Will you review the document so that we can rapidly finish it if it  
is accepted as a working group item?

Thank you in advance for your responses to this query.

best regards,

Brian Adamson
[email-masked]

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 17 Apr 2009 21:20:21 +0900 (JST)

Hi Brian,

> 1) Do you think there is merit in the FCAST specification as an RMT
> WG item (or not)?

I support it.
Supporting both ALC and NORM would be highly beneficial for various
use-cases. And no IPR issue will be good for potential developers.

> 2) Will you review the document so that we can rapidly finish it if
> it is accepted as a working group item?

Yes, I'd be happy to review the document.

Regards,
--
Hitoshi Asaeda

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Apr 2009 12:49:34 +0200

Hi,

If the interest for this item is this low, I am very hesitant to approve
taking it on as WG item.

Cheers

Magnus

Brian Adamson skrev:
> This message requests interested parties to respond on the mailing list
> to indicate their opinion on this:
> 
> _______________________________________________
> Rmt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rmt
> 

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 29 Apr 2009 12:48:32 -0700

Poll response: I think there is indeed merit.  Worthwhile WG item.

At the risk of overkill, here are some of my reasons and rationale:

My comments have to do with the utility of FCAST (and NORM) in military 
and emergency services environments.  If I get this right, it will be a 
translation from operational needs into protocol requirements.

Traffic observation.  A much higher percentage of traffic  in the 
military/EMS world is multicast  than in the civilian world.  We have 
acronyms like BFT (blue force track, asset tracking), COP (common 
operational picture), chat, APB (all points bulletin, from the TV 
shows), and CAP -- common alerting protocol -- which should give you an 
idea of how ubiquitous multicast data is.
Conversely, all of this entails extension of the internet to mobile 
platforms so we suffer a 10*4 decrease in bandwidth at the radio-WAN.  
The only offset to that bandwidth constriction is the fact that the 
media is a shared one -- the ether.

That much rationale should convince that multicast is a good idea -- the 
demand side and supply side arguments intersect.  Further, we have to 
cover multicast at all layers of the ISO reference model (application 
layer included) in order to get the benefit.  Multicast at layers 1-4 
provides no relief if the applications don't use it.

One of the banes of military 'data links' is that they do not include 
meta data in the data stream.  Compounded by the fact that the data 
dictionary (format) is usually in the same spec as the communications 
specification.   This, coupled with the fact that the data dictionaries 
between any two information systems don't coincide yields all kinds of 
interoperability difficulties.  This leads to phenomena where a single 
physical object (a ship) is reported by several different sensor/comms 
lashups to a common operational plot where it shows up as several 
objects (one appearance per sensor/comms instantiation).   Is it any 
wonder that the users don't trust it?  Modularizing communications and 
data away from each other is a core interoperability problem.  Including 
the meta data in the data stream is one very good means of accomplishing 
that end.

Therefore, the basic ideas in FCAST are good and necessary.

But there's more.  Look at the problem from the data point of view 
rather than the comms (internet) one for a moment.  There is 
considerable work in object-orienting data.  I know of three initiatives 
out there worth mentioning:

XMPP.  Chat implementations have flowered like the proverbial Czech 
springtime.  Many were not interoperable with each other and none 
carried object security (vital).  DISA has latched onto XMPP as the 
common denominator.  We shouldn't have too much trouble figuring out 
that a multicast-based chat implementation has many benefits over the 
current server-centric model, both in terms of robustness and bandwidth 
conservation.

Cursor on Target.  Object oriented data format that uses XML as the 
tagging means (small step from the MIME typing mentioned in FCAST).  
There are several things wrong with Cursor on Target, lack of 
authenticity being one of them.  But for this discussion, the most 
egregious one is that there's no 'envelope' specified for Cursor o 
meritn Target messages (e.g.e-mail). I can't read the Cursor on Target 
specification and point to any layer 6/7 protocols.

Common Alerting Protocol.  Over the years, several means of warning the 
public, and alerting emergency services, have evolved.  Many are 
stovepipes (remember the TV warnings about nuclear attack?).  CAP is 
designed to get past the stovepipes by specifying an XML-based schema 
that modularizes both the message and the meta-data away from the 
communications means of delivery.  Many of the FCAST I-D para 4.1 items 
also appear (object time validity, for example)  in the CAP schema.  CAP 
also eschews  specifying a 'wrapper' or 'envelope' -- considered outside 
scope.

Somewhere between a layer 6/7 protocol and MIME/XML-based data formats 
we will need a careful modularization boundary ... don't have a complete 
interoperability solution without it.

-- 
Rex Buddenberg
Senior Lecturer
Naval Postgraduate School
Monterey, Ca 93943
831/656-3576