[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
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 availabe. Sent from my iPhone On Apr 2, 2010, at 7:08 PM, "Lee Tincher" <ltincher@evotecinc.com> wrote: > 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]