>>As an interesting example - if there is a natural disaster, should
>there
>>be protocol mechanisms to enable use of emergency services without
>direct
>>Internet connectivity to the DB?
>
>Would you consider this as a threat or a feature that the protocol needs
>to be concerned with regarding reachability of the database?

A threat analysis provides requirements that might be met with specific 
features of technical proposals.  Too often we carry implicit ideas on the 
features and implementation (like FCC rules, or TLS+509 for all security 
requirements) that impact our view of the problem area. 

Here specifically (the disaster scenario), we should allow devices (perhaps 
only empowered emergency service devices) to continue to use spectrum when the 
database is not available due to a natural disaster. 

Since we are all looking at what this would mean for a protocol mechanism - the 
implication is that we need to support more than one type of policy for 
enabling transmission.  The ".. stop immediately if you've not been enabled in 
the last 60 seconds ..." model may be one approach, but if we are trying to 
plan for the future and develop a robust communication technology, then we need 
to have protocol mechanism that indicates differences in the application of 
policies.  Some policies should allow more lenient interpretation of the 
temporary spectrum usage authorization provided by the DB.  WE should not hard 
code current FCC rules into devices, but have some ability to 

I'm not at this time proposing a specific mechanism at this time ... just the 
requirement (in the form of threat models).

>
>>
>>Loss of service (emergency and normal) usage of WS is a threat that
>>should be listed and may or may not be addressed by technical or
>>procedural mechanisms.
>
>If you can elaborate or (preferably) provide the text describing the
>threat and consequences, I would be happy to include it.

I did before ... time permitting I'll resubmit.

Paul
>
>-Raj
>
>>
>>Paul

_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws

Reply via email to