Re: IETF74 FCAST Action Item

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.






Magnus Westerlund wrote:
> 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:
>   
>> 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 protected]
>>
>>
>>
>>
>> _______________________________________________
>> Rmt mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/rmt
>>
>>     
>
>
>   

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