OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-rim message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [emergency] RE: [emergency-rim] RE: [emergency-if] RE:[emergency-rim] Questions & Observations #1: Don's IF SC Use Cases

Thanks for the feedback.

I may not have made it clear but this system is not doing request/reply for data at rest.  The endpoint I specified may have been RESTful, but that can also be a pub/sub endpoints as well.  The entire backend is running pub/sub and the system is scalable to multiple nodes / instances, and supports routing to/from other EDXL systems like a Solace Router, etc.  Lists, while hosted on a web server for query may also choose to implement underlying service mechanisms to push out of band updates to nodes as well as a host of other options.  However at this stage in the game we are focused on getting a prototype system out the door that can do some basic DE routing based on a dynamic user model and connect up some real first responder systems.  As we move ahead we will continue to evaluate our "customer's" needs and adjust accordingly.

Maybe what we should do is the following compromise:
Fix the obvious errors in 1.0 such as the "XMLContent" type causing non-valid XML.  We can push through the things that have no need for further discussion or analysis and work through the rest.  I'll accept that this was rushed few and the specifics of the URN were overlooked, however we need real use cases and supporting architectural concepts of specifically why we need to use URN as opposed to a URI or just a unique string. As of now I still don't feel there is sufficient information out there to make that case.  Pub/sub in its raw form does not scale large and although I agree this is an issue, we need to make sure we separate both yours and my implementation issues from the standards issues.  I would also state that for your thoughts of implementing the DE secure policy based information is indeed the holy grail of interoperability; however for my edge use cases it is more focused on data standards themselves, getting legacy and new systems to talk, and layering security on top on an as needed basis.

Office: 315-838-2669
Cell: 315-383-1197

-----Original Message-----
From: David E. Ellis [mailto:dellis@sandia.gov]
Sent: Monday, April 05, 2010 12:27 PM
To: McGarry, Donald P.; 'Gary Ham'; 'Lee Tincher'
Cc: rexb@starbourne.com; 'Hans Jespersen'; emergency-if@lists.oasis-open.org; emergency-rim@lists.oasis-open.org; emergency@lists.oasis-open.org
Subject: RE: [emergency] RE: [emergency-rim] RE: [emergency-if] RE: [emergency-rim] Questions & Observations #1: Don's IF SC Use Cases

Don and others;

Thank you for the detailed e-mail.  We need to put your use case into EA.
As I read this however, there seems to be a specific application and
technology "structured Restful or other URI" technology choice made.  We
should evaluate these issues and determine if they are real requirements for
the EDXL-DE routing standard and if so work to provide a means to solve

The requirements you outline still look like metadata describing content
(Content object) and ways to "pull/poll" for data at rest.  You are correct
in your assessment of UCORE and UICDS in my opinion.  However; the use of
URL and "string" in EDXL-DE 1.0 example(s) and the other artifacts were due
to the rapid nature of the EDXL-DE 1.0 standard.  Also, Many of the
requirements you specify are really IPAWS like and this was the primary
reason we pushed the standard out so fast.

The theory of the URN was not an accident and it had significant
subcommittee discussion.  Unfortunately we did not have a "Jeff" documenting
subcommittee meetings or audio recordings. I think we need to again have
detailed discussions about requirements and not rush to put out a OASIS
EDXL-DE 2.0.  The real problem is much of the technical talent which
developed the theory of the EDXL-DE 1.0 have left the TC.  In fact, there
has been several attempts by these standard developers and other
technical/consumer groups to create a different technical committee to move
DE work or create a more universal "interoperability" EDXL-DE like standard.

A truly secure policy based information exchange capability is the "Holy
Grail" of solving numerous interoperability needs.  The need to dynamically
determine situational (incident centric in OASIS EM requirement space)
participant roles and enforce information exchange policies between them in
time evolving scenario is critical to any small/large information exchange.
Unfortunately, the determination of when a small incident will become a
larger and potentially more information restrictive (terrorist attack)
cannot be determined in advance and there is a need to have a seamless
capability to scale information exchanges.

One of the reasons the DoD GIG is having so many problems with exchanging
information is because it does not use the TCP/IP packet and metadata stack
pattern/concept for exchanging data.  They keep implementing "Service" which
must be dynamically queried "pull/poll" for evaluating policy and routing
metadata evaluations (SAML/XACML).  These type of system inevitable fail
when they are scaled.  Even the internet DNS system which is used to create
routing metadata (sender creation) is out of band, highly decentralized in
authoritative updates and not used by intermediate security and routing
infrastructure.  The IP packet uses IP addressing and ports to implement
routing and security decisions when in transit.  For those of us who were a
part of the Arpanet (AFWL) and DECNET development, these lessons learned
should not be relearned in our evolving application metadata routing

This is an important national/international need and OASIS EDXL-DE 1.0 was a
good first effort in meeting the need.


-----Original Message-----
From: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
Sent: Friday, April 02, 2010 9:59 PM
To: Gary Ham; Lee Tincher
Cc: <rexb@starbourne.com>; Hans Jespersen;
<emergency-if@lists.oasis-open.org>; <emergency-rim@lists.oasis-open.org>;
Subject: RE: [emergency] RE: [emergency-rim] RE: [emergency-if] RE:
[emergency-rim] Questions & Observations #1: Don's IF SC Use Cases

Lee/Gary/Others:  My apologies....That did not come out as it was
represented in my head as intended in the email.  My point was not to say
that folks were not using it at all, nor to say that it was only for point
to point non-redistribution.  I was speaking more of the "advanced" routing
component that Dave is speaking of.  Bottom line is I want this thing to
flourish and grow its adoption base beyond where we are now.  I don't think
our concern or focus can be on specific large-scale systems with
requirements without technical details to support their needed requirements.

My use case is this:
1. Field paramedic sends a message to an exposure system with his sender
role and keywords describing message content, which includes multiple
payloads.  Field paramedic doesn't know the state of the command structure
for multiple reasons: bandwidth of always pushing around the state of
command; changing people in roles; explicit addressing locks down adding
unintended producers / consumers of data, which is bad in some cases.
2. Message system routes and exposes data based on current state of ICS /
command model.   This is based on predefined valuelists for terminology,
roles, and keywords that can hosted at destination URI's, but can also be
pushed to endpoint nodes; the <string> only represents a structured RESTful
or other URI that gives context to a unique name.  However a URI gives you
the ability to pull this data later if needed.
3. Data gets to intended folks.

System Requirements:
1. Easy / clear to implement
2. Lightweight processing footprint
3. Can be carried on low bandwidth / intermittent connections
4. Implementable by local government
5. Ability to use own terminology
6. Does not require "custom" hardware/software solutions - (i.e. COTS
product where I can just install it and use it)
7. Ability to report unit information, situational information, hospital
status, emergency patient information
8. Ability to carry field sensor data
9. Ability to describe information carried in multiple payloads without
inspecting the data itself
10. Only need to use the sender information and keywords to send the
message.  Field paramedics don't need to know what explicitaddresses to send
to.  That's for the messaging infrastructure to figure out.
11. Ability to host / poll lists of data terminology used in value lists in
a standard way; not required for all DE implementations, but an option
chosen by this one.

Basic Architecture drilldown:
1. Field provider's edge device wraps up content objects with
contentkeywords.  Keywords may be copied to DE Keywords header.  This is
then wrapped in DE with various sender roles filled in from a managed list
for their sender roles...i.e. paramedic mcgarry, gbac 2, ALS ambulance,
treatment sector officer, etc.
2. Message published to RESTful web service.  Message transport changed to
async pub/sub or push.  Message transitioned to routing service.  All async
cross-machine operations are mediated through DTC's.
3. Routing service ingests message, preforms xpath queries on DE header.  If
keywords are marked for internal processing, redistributes to multiple
services.  Messages can also be passed to other DE ingestors.
4. Service operations include caching for archival, querying of model to
determine exposure/delivery, querying of weighted tree for detail level
exposure determination, translation of content formats to vis formats
5. Processed / transformed content objects pass around the infrastructure
via the routing service, which can be dynamically updated with explicit
rules, however the goal of this research is to leave the heavy lifting up to
the standard models, because I think we can easily become rapidly bogged
down with explicit routing rules at the operational level.

The analytic basis for making a routing sub-element has value.  Separate
this obvious point of contention so those folks that want to build a large
grid system would have an area to focus their development and theoretical
efforts, and those of us who want to build "lesser" systems can just move
on.  I'm advocating for leaving the flexibility in, while adding clarifying
documentation on its use.  You are advocating to lock down this part of the
standard without presenting clear technical evidence that a URN is necessary
as opposed to any unique string that can hold contextual information (which
could be a URI).  Since you are advocating for a more restrictive case I
think you should have to really prove your case as well.  I'll be happy to
elaborate on any of the above to make mine.  I'll also be more than happy to
share all my library source code and point folks to a real implementation of
this on the public internet once my new server goes up on the DMZ in the
next month and my code clears public release.  My thoughts on moving the
routing information to a sub-element would be to lighten up the root de
element, add a generic valuelist component that DE-light systems can use,
and allow the hardcore routing folks to keep their routing component locked
down to URN only.  As a member of this TC I would like to see the use cases
and architectural requirements that would drive a URN-only solution in DE

As an OASIS TC member are you suggesting that I just go use other non-EDXL
standards in lieu of using the DE?  An unfortunate truth here is that we
require that all our other standards be carried in the DE.  UCORE doesn't
provide a standard mechanism to represent roles, and is much too large to
have a lightweight XML processor, and can't make it over low bandwidth
links.  UICDS from my impression isn't a standard.  It's a redistribution
model comparable to a controlled UDP broadcast that it web based.  That
doesn't provide any extendibility to do model based routing / exposure based
on command structure.

I don't really think the whole <string> thing in the ValueListURN element is
an inconsistency.  It's in the documentation and the schema.  A URL is used
in the first example.  That seems pretty consistent to me.

1. If you want this process to be requirements driven where are your
2. I will consider any routing architecture brought to the table.  It needs
to be an architecture though.
3. Once again, please don't minimize my implementation because it's not
yours or doesn't fit into your vision for how pub/sub will "scale" for
SOA...My project is trying to deliver the interoperability vision to
day-to-day boots on the ground First Responders (as are a lot of others
here); a large scale model doesn't apply to this application.
"The primary purpose of the Distribution Element is to facilitate the
routing of any properly formatted XML emergency message to recipients. The
Distribution Element may be thought of as a "container". It provides the
information to route "payload" message sets (such as Alerts or Resource
Messages), by including key routing information such as distribution type,
geography, incident, and sender/recipient IDs."

That's from the DE spec.  That's our requirements.  In fact in the
requirements for Design section of the spec there is no mention of specific
system implementations, non-repudiation, secure policy oriented routing,
etc.  On my side there's no talk of command models, low bandwidth links,
edge devices, CAD systems, etc.  These are implementation issues.  There is
however a lot of talk about business process driven flexibility for
terminology, interoperable exchanging of various payloads, and an open
container model.  I'm more than willing to play ball on coming to a
compromise about this routing stuff, but outside of your personal take on
what the DE is, we don't have any solid technical requirements or
architectural comments to support your needs.

Office: 315-838-2669
Cell: 315-383-1197

-----Original Message-----
From: Gary Ham [mailto:gham@grandpaham.com]
Sent: Friday, April 02, 2010 8:32 PM
To: Lee Tincher
Cc: McGarry, Donald P.; <rexb@starbourne.com>; Hans Jespersen;
<emergency-if@lists.oasis-open.org>; <emergency-rim@lists.oasis-open.org>;
Subject: Re: [emergency] RE: [emergency-rim] RE: [emergency-if] RE:
[emergency-rim] Questions & Observations #1: Don's IF SC Use Cases

Not to mention the TEP interoperability work going on this month. De
wrapping - multiple applications. And (of course since it is me
writing this) the expanded capability of dm-open 2.0 when it comes

Sent from my iPhone

On Apr 2, 2010, at 7:08 PM, "Lee Tincher" <ltincher@evotecinc.com>

> Don,
> I respectfully disagree on one point in this...not only does DNDO
> use the DE
> for virtually every message exchange - I personally have it as the
> main
> focus of our commercial product that does a whole lot more than
> point to
> point exchanges...I even use it to carry multiple CAP messages as
> payloads
> for routing distribution down the pipe...it carries HAVE and SiTRep
> reports
> as well as Justice defined NIEM IEP's...I rely heavily on it as do
> all of
> the recipient and "re-distributors" that use our product....
> Thanks,
> Lee
> The aim of education should be to teach us rather how to think, than
> what to
> think - rather to improve our minds, so as to enable us to think for
> ourselves, than to load the memory with thoughts of other men.  ~Bill
> Beattie
> -----Original Message-----
> From: McGarry, Donald P. [mailto:dmcgarry@mitre.org]
> Sent: Friday, April 02, 2010 4:11 PM
> To: rexb@starbourne.com; Hans Jespersen
> Cc: Gary Ham; emergency-if@lists.oasis-open.org;
> emergency-rim@lists.oasis-open.org; emergency@lists.oasis-open.org
> Subject: [emergency-rim] RE: [emergency-if] RE: [emergency-rim]
> Questions &
> Observations #1: Don's IF SC Use Cases
> All-
> 1. My feeling is that if it doesn't stand the test of time we can
> change it.
> Frankly I don't see how changing one character in the name of one
> element
> will cause any harm.  In fact we really aren't changing anything
> outside the
> name since once again I point out it is typed as <string>.  I still
> like my
> idea of moving all of the URN stuff into a routing sub-element and
> putting a
> generic ValueList component in the root.
> 2. Our method for people not mucking it up now seems to be no one
> using it
> at all, beyond just passing point to point data.  I'd rather have
> people
> start using it and have them grow with the standard rather that have
> the
> "perfect standard" that is so theoretically wonderful that no one
> uses it.
> 3. I fail to see how preforming an unintended DoS attack on an
> improperly
> tuned webserver applies to this, but point taken that people can and
> will
> mess anything up.
> 4. I'm still waiting for what "should" be a simple answer to my
> questions...What does limiting our spec to a URN buy us?  If it was so
> important why was it completely overlooked in 1.0?  What is the
> architecture
> that disproves a unique string (which could be a URI) can't do the
> same job.
> If we are willing to agree to compromise and move on, so be it.  I
> would
> suggest that given this outcome, that all non-constructive criticism
> also go
> with it.  As a researcher who's completing my dissertation in this
> stuff I'm
> more than happy to accommodate anyone who can present legitimate
> technical
> contributions that will point out oversights in my (or any other OASIS
> member's) product or work.  However, opinion, undocumented claims,
> etc. are
> starting to wear very thin and are without merit.  I'm sure I speak
> for many
> folks on these committees when I ask that that comments, opinions, and
> criticisms be brought out only when there is solid technical
> evidence to
> support the counterpoint.  I think this is in both the true spirit of
> industry, academia, and general to overall productivity.
> -Don
> Office: 315-838-2669
> Cell: 315-383-1197
> dmcgarry@mitre.org
> -----Original Message-----
> From: Rex Brooks [mailto:rexb@starbourne.com]
> Sent: Friday, April 02, 2010 2:31 PM
> To: Hans Jespersen
> Cc: Gary Ham; McGarry, Donald P.; emergency-if@lists.oasis-open.org;
> emergency-rim@lists.oasis-open.org; emergency@lists.oasis-open.org
> Subject: Re: [emergency-if] RE: [emergency-rim] Questions &
> Observations #1:
> Don's IF SC Use Cases
> My intention to reply in depth to Don's post has managed to get pushed
> farther and farther down my priority list, especially since Gary's
> proposed compromise, which I indicated I could live with, and today
> has
> been particularly difficult in that regard, so I must, in essence,
> throw
> in the towel with a couple of comments only.
> While I can live with Gary's compromise, I don't think it will stand
> the
> test of time, but we'll see about that. That's just my opinion. Having
> weighed the opposition, I decided that fighting it didn't make sense
> and
> was wasting precious time. I don't like it, but that's happened before
> and it hasn't proved fatal to me personally, and not as far as I
> know to
> anyone else, yet.
> The problem with the compromise is that no matter how well we caveat
> it,
> people will find a way to muck it up. Hopefully we can catch as much
> of
> that as possible in testing. Case in point, when we initially finished
> CAP one of our three letter agencies decided to use it and promptly
> caused its network to crash because so many of their systems went out
> over the web at the same time to get the schema and validate it. I
> would
> never have guessed that folks with that much experience and
> intelligence
> would not actually cache the schema locally, but they didn't.
> Stuff happens.
> I will ask that we carefully and accurately document our requirements
> and our caveats. I think it would be especially helpful if we
> carefully
> delineate where users can safely use <explicitAddress>. Where URNs are
> required for policy, we will need to ask that those networks make that
> clear so that we minimize inadvertent mismatches.
> Cheers,
> Rex
> Hans Jespersen wrote:
>> Comments inline denoted [hj]
>> -hans
>> -----Original Message-----
>> From: Gary Ham [mailto:gham@grandpaham.com]
>> Sent: Wednesday, March 31, 2010 8:56 AM
>> To: McGarry, Donald P.
>> Cc: rexb@starbourne.com; emergency-if@lists.oasis-open.org;
>> emergency-rim@lists.oasis-open.org; emergency@lists.oasis-open.org
>> Subject: Re: [emergency-if] RE: [emergency-rim] Questions &
>> Observations
>> #1: Don's IF SC Use Cases
>> Sounds to me like network rules related to ValueList elements
>> 1. Parse them.
>> [hj]or not as the case may be. Not every ValueList element MUST be
>> used
>> by every DE implementation.
>> 2. If your network does not find a URN it needs for distribution,
>> refuse
>> it, or do not redistribute.
>> [hj] or add one so that downstream nodes know more about the
>> message and
>> can treat it accordingly.
>> 3. Any URI would be acceptable in the schema, but only those with
>> formal
>> URNs might be used on some networks.
>> [hj] Seems fine to me as long as everyone understands that any URI
>> can
>> be in these fields and they should not fail to parse, choke, or drop
>> messages if it's a URN and not a URL (i.e the opposite of #2 should
>> not
>> happen).
>> Adds the need to parse to all push redistributors.   But it would
>> seem
>> to me that they would need to do that anyway.
>> The rules need to be put into the DE documentation so that it is not
>> ambiguous. I.e,"Warning: If you do not use a formal URN, some of the
>> more security conscious networks will not be able to use your
>> document."
>> But you can use other URI's for categorization, filtering, etc.
>> Seems to be a reasonable compromise to me.
>> R/s
>> Gary
>> On Mar 31, 2010, at 11:42 AM, McGarry, Donald P. wrote:
>>> Rex-
>>> Agree with your in-band / out-of-band assessment; however I think we
>> are getting to bogged down in some implementation details...
>>> 1. Proponents of the URN feel that it is required to adequately
>> extract authority context from its structure to do secure routing.
>>> 2. Proponents of the URI feel that:
>>>     a. URIs/URNs/URLs are just structured strings.  Although URNs
>> imply a unique name; newer principles of REST state that URLs (or
>> more
>> generally URIs) also can act unique names for resources - including a
>> name of a list
>>>     b. Although URNs can be registered at an authoritative source
>> (IANA or your own infrastructure), at some point someone needs to
>> go and
>> verify that unique    name from the authoritative source.  This can
>> be
>> done in-band, out-of-band, or periodically; but it still has to be
>> done
>> and has a host of security issues, not completely dis-similar from
>> verifying a certificate chain in a registered uri/url
>>>     c. If you want to add a dynamic component to your lists; URNs
>> require that you have a custom URN resolution software to resolve the
>> URN to a location to pull the list from; If you do an out of band
>> push,
>> you still need to resolve /authorize the entity pushing the update.
>> Again, not completely dis-similar from pulling list data from a url
>> location and authenticating the server through CAS
>>> 3. The valuelist concept is about flexibility.  Everytime we want to
>> allow implementers to use their own terminology we plug this thing
>> in.
>> That's to provide flexibility.
>>> 4. The DE is about distributing data.
>>> 5. Since the purpose of the URN/URI is to identify the referenced
>>> list
>> and the authority context associated with it in a "secure" system, if
>> you only want to work with URN's drop the message when you the first
>> characters != 'urn'...You need to parse the string anyway...if
>> there are
>> no 'urn' identified list in the DE...then your system shouldn't be
>> getting it anyway...
>>> I think pushing this back to the subcommittee is a bad idea.  To
>>> date,
>> we've been discussing this over and over, yet there exists no
>> architecture diagram coupled with a use case to refute this point.
>> If
>> this was so important in the DE 1.0, why was it typed as <string>?  I
>> don't think we should have to hold back the DE 2.0 to further
>> "discuss"
>> this.  Given the perceived "importance" of this structure I would
>> think
>> that there could be a clear use case and architecture to support the
>> claims of the URN camp available now.  I think that we are continuing
>> down the path we have already been down and that we'll end up in the
>> same spot that we are at right now next quarter if we don't change
>> our
>> approach to this.
>>> -Don
>>> Office: 315-838-2669
>>> Cell: 315-383-1197
>>> dmcgarry@mitre.org
>>> -----Original Message-----
>>> From: Rex Brooks [mailto:rexb@starbourne.com]
>>> Sent: Wednesday, March 31, 2010 10:32 AM
>>> To: emergency-if@lists.oasis-open.org;
>> emergency-rim@lists.oasis-open.org
>>> Subject: [emergency-rim] Questions & Observations #1: Don's IF SC
>>> Use
>> Cases
>>> Hi Everyone,
>>> Don McGarry produced a pdf of a set of Visio files as Use Cases and
>> uploaded them 2 March 2010.
>> http://www.oasis-open.org/apps/org/workgroup/emergency-if/download.php/3
>> 6650/Visio-DE_IF_Use_Cases_v1.vsd.pdf
>>> I happened to be out of pocket at the NCOIC March Plenary at the
>>> time
>> and didn't notice this until it was pointed out to me yesterday in a
>> call with Dave Ellis. If I had been here I would certainly have
>> asked a
>> number of questions and made a few observations about these
>> diagrammatic
>> illustrations. However, I found myself at a loss when asked how I
>> could
>> support something I had never seen, to which I said I couldn't and it
>> was at this point that Dave pointed me to this file.
>>> So this sets up an interesting set of disconnects for me wrt how I
>> want to respond to this as it relates to the ValueListURx
>> discussions in
>> both the Infrastructure Framework and the Reference Information Model
>> SCs. I assume we all know what ASSUME stands for? All puns intended.
>>> Now, it looks to me like we have had dueling assumptions, and both
>> sets of assumptions appear to have been asserted and defended without
>> giving the opposing set of assumptions the benefit of the doubt, and
>> both have been argued out of context, in my opinion.
>>> For now, in this particular message, I'm going to stick with just
>> asking my questions about this set of Use Cases. I will be
>> composing and
>> sending out a couple or a few more messages where I hope to focus on
>> different specific aspects of this discussion.
>>> I will give them separate Subject Lines so, hopefully, we can
>>> harvest
>> any further discussions more easily. I've tried this before and it
>> usually breaks down because people ignore Subject Lines which would
>> otherwise serve to collect related discussions in an easily
>> referenced
>> way and react only to specific comments within a message. I don't
>> expect
>> this to be any different, but I keep trying in the hope that one fine
>> day, it will "take."
>>> Question #1: What list is it that the user wants to update?
>>> This makes an incredible difference since, (in my opinion) IF it
>> relates to the user's social structure; e.g. a change in the
>> permissions
>>> (policy) assigned to a given role (job description and title) for a
>> position in Mitre or OASIS or Foo or Bar or The Dept of Redundancy
>> Dept;
>> THEN (In my opinion and in any repeatable Service Oriented pattern I
>> work on) it definitely should not be submitted to the List Server
>> or the
>> Https Server or the Router through any external network In-Band.
>>> My opinion (with the understanding that this Infrastructure is only
>> now beginning to be implemented):
>>> It should be submitted through the social structure's duly
>>> authorized
>> method to a Third Party Registry (possibly a public-private shared
>>> resource) or Broker Service where it can be separately validated,
>> authorized and authenticated before being propagated to the network
>> routers where it would be updated system-wide just like DNS. I could
>> argue that no significant change should be submitted In-Band, but I
>> think that for the next few years we can probably allow simple
>> changes
>> in the kind of ValueLists which are aimed solely to document a given
>> jurisdiction's facilities, terminologies and equipment names to
>> simply
>> be published separately and shared among the partners with whom the
>> jurisdiction has mutual aid or other service level agreements. I
>> would
>> envision those lists being shared by municipalities and counties in
>> shared DBs once we educate them to the value of such datasharing.
>>> I recognize that this seems like a more heavyweight process than may
>> seem needed, but I think that there is more than sufficient need for
>> verifiable security, financial liability assurance, audit trails and
>> confidence, as well as scalability. Once it is done a few times, we
>> can
>> learn how to streamline the process, and once in place, maintenance
>> should be much easier than most people think. However, it does
>> require
>> practice and making that maintenance a regular SOP. We need to set up
>>> 24/7 365 testbeds anyway, so this should help take the sting out of
>> the learning curve, especially if we can use students to do the
>> initial
>> documentation.
>>> Cheers,
>>> Rex
>>> --
>>> Rex Brooks
>>> President, CEO
>>> Starbourne Communications Design
>>> GeoAddress: 1361-A Addison
>>> Berkeley, CA 94702
>>> Tel: 510-898-0670
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>> Gary Ham
>> http://grandpaham.com
>> 703-899-6241
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/
>> my_workgroups.php
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-898-0670
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]