Meeting Notes from the Emergency Management Infrastructure Subcommittee
Date: May 11, 2010 1100-1200 EST, Call-in 800-320-4330, PIN 024471
Attendance: Elysa Jones, Rob Torchon, Jeff Waters, Rex Brooks, Hans Jespersen, Werner Joerg, Martena Gooch, Gary Ham
We do have quorum.
NoteTaker: Jeff Waters
Note-Taker's Summary: At today’s meeting, the participants discussed the following topics related to the work towards a new version of the Distribution Element 2.0 -- (1) Call for Comments 30-days – the call is now out and should take 30 days, finishing just prior to our scheduled Face-2-Face meeting June 28-30. (2) Routing Best Practices Guide – participants agreed that what was initially termed a routing specification might be better termed a “Routing Best Practices Guide”, describing what is currently being done in the field for routing solutions. Multiple scenarios will be considered, such as routing within an organization, routing across organizations with strict security restrictions and routing across organizations with typical security restrictions. The typical exchange patterns and requirements will then be discussed and how the DE is best used to address these requirements. The goal is to provide guidance about routing issues separately from the DE 2.0 specification to facilitate the DE work progressing. Hans and Jeff will work on an initial version of this document. (3) XMLSpy tools – participants discussed the need of all members to have a good xml editor, such as XMLSpy, and the desire of the subcommittee to recommend to the Emergency Management Technical Committee that three copies be budgeted for those members who need it.
Background: The EM Infrastructure Framework Subcommittee was originally founded in 2003 when within the EM community there was a lack of definition regarding the validation, selection and deployment of infrastructure-based facilities supporting persistent interoperability across a broad range of applications. For instance, what components and/or protocols support interoperability, and are they valid in the context of an national emergency management system? Significant progress has been made to define this framework with the subsequent efforts to produce the Emergency Data Exchange Language (EDXL) family of standards, including Common Alert Protocol (CAP), Hospital Availability (HAVE), Resource Messaging (RM), and the Distribution Element (DE). In particular, the DE is now the focus of education and adoption efforts and significant enhancements are in store for the next version, DE 2.0. The IF Subcommittee's current focus is to discuss, define and implement DE 2.0. This enhanced standard will provide a bedrock foundation for enabling intelligent routing, through the integration of multi-agency policies, to enable secure, reliable, and authorized messaging. This work is consistent with the IF Subcommittee's continuing purpose to research, analyze, recommend, and organize currently available protocols in order to define a validated systemic framework enabling stable, on-demand connectivity between EM systems.
References and Info:
- Dave's Slides (note that this will download as a file called bin00001.bin, but just rename it to PolicyVectorsForInteroperability.pptx after you download):
Meeting Discussion: (any items in blue or in parens were added by the Note-Taker)
Elysa: Ballot for CAP 1.2, we already have 80% but nice when we can have everybody, Don will be late. Dave will not be on the line because he is at the DoD Enterprise Architecture meeting.
Jeff: My apologies for not having the minutes ready. I will have them next time.
Elysa: EDXL call for comments is out. So that’s already been done. I believe the last time. In the absence of agenda items, could we discuss trying to settle on dates for face-to-face to further DE, last week of June good?
Rex: Last week we didn’t want to set the date until we had the result for call for comments back so we could factor into the face-to-face. We didn’t want to backtrack and do something else. Also call for comments should go to Europeans who are using the DE to route the TSO (Tactical Situation Object). So we want to make sure we get that back and that may be a more focused effort to automate the process of getting permissions and roles handled. That is particularly important for us to know and that is the crossing the border problem that we want to handle.
Elysa: Do you have a particular contact?
Rex: Yes, to the principle author.
Elysa: And Dr. Ianella in Australia?
Rex: He isn’t in this field anymore due to funding adjustments. There just wasn’t sufficient interest and commitment. There is more interest in other areas. So I can give Dave info there. Is Doug on the line?
Gary: I’m on but in a bad place.
Rex: We want to make sure Doug gets whatever feedback he needs from Canadian uses.
Elysa: They intend to.
Rex: Maybe we can nudge them forward. We are generating some points and concerns out of the CIQ work but not far enough along to comment yet.
Elysa: 60 day call for comments and covering requirements, might be a little late, did you talk about that?
Rex: I think we were thinking 30 days. Do you want to take roll?
Elysa: We have a quorum.
------
TOPIC: Best Practices Guide
------
Jeff: One topic of discussion for us is the Routing Specification. We discussed this at the face-2-face in February as a way to provide guidance on best ways to use the DE to address example routing use cases, which would enable the DE work to proceed. Hans and I volunteered to work on that. Can we discuss the status of that?
Hans: This is similar to the geo-oasis:where work. We could just use that as a model and carve off the functionality as a focus group. What I’m not keen on doing is some huge effort to recreate all of the routing protocols. We don’t need to recreate reliable messaging, etc.
Elysa: Do we need a focus group of what open standard routing capabilities are out there.
Hans: There are some good ones from OASIS. But they aren’t ones we would normally include. They would be protocols for transport under EDXL and pretty transparent and you don’t call them out. So what we need to focus on is those fields which we absolutely need to include in EDXL and they have functionality not covered in those pre-existing standards.
Jeff: The DE does provide the hooks that the routers rely on to enable their capability, so the issues are intertwined. But the idea was that, although the DE provides the hooks, the explanation and understanding of emergency-management specific routing is a separate effort that could benefit from some separate attention.
Elysa: I like that and focusing on the DE specifically and routing separately is exactly what needs to be done. Maybe a separate spec is not necessary. Maybe we need a small group to review and come back with a recommendation.
Hans: Things like reply-to and some data type changes, and I made a DE 2.0 schema with some of those changes in it and we just need to focus on the rest of the things that we’ve talked about.
Rex: One of the things with the call for comments is you find out what’s going on. It gets difficult and often comments maybe not received until the last week or day before its due, that’s human nature, and you find out things you are not aware of. We’ll discover things coming out of Europe and aspects that are coming out that are valuable to us. Easier to say good idea and adopt it. I think that maybe, difficult to say this, cause if we had a best practices guide for routing, that would help.
Jeff: Best practices guide for EM routing. Is that correct?
Rex: I don’t know how official we can make it. Like official handbook for EDXL. Add to EDXL 101 family of presentations.
Jeff: Best practices guide is what I thought routing spec would be.
Rex: Would be good if we could do some paid hours
Hans: Doug (Allport) is keen to walk-thru cross-border scenario and that was a good idea. And if we wrote it out in best practices, then that would be good and even if we did it on paper.
Jeff: And multiple routing levels.
Hans: We could build a prototype.
Jeff: Can we do this for next time?
Elysa: Other use case is DNDO.
Hans: That’s the one that I’m working on.
Rex: Cross-border scenario that I’m thinking about for WCDM carries the water for a lot of what we’re talking about. We have two real-live use cases. Keep it to a best practices guide for the moment.
Hans: Why don’t we just document what is known today
Rex: And that goes hand-in glove with comments
Werner: I’d like to add a comment. I’m in favor of separating high-level writing of DE from technology driven routing on the other side. I’d like to see DE routing defined over independent level of technology to translate down to some of the known standards. I’d like to see the abstract layer become part of the RIM. Discussions about the DE and routing should be independent.
Jeff: Yes.
Rex: But I would warn you about going with expectations beforehand about how you are going to do it.
Werner: What we want to find out is what primitives do we need to implement the higher level consistent abstraction layer and then how to translate into a separate document, not a matter of picking technologies at this stage.
Rex: I was warning you about your mind made up about the approach. You should let what is happening in the field. You shouldn’t assume that what smacks of high level security can't serve other levels as well.
Jeff: Yes, both discussions and comments
Rex: While you and Hans are defining things on a practical level what we need to do, that would be excellent.
Jeff: Action item for us?
Hans: Happy to contribute. My only concern is about best practices document and high level model perhaps in conflict with each other.
Rex: Flesh out the scenarios so you can make genuine progress. So we can get dirty with details. So we can figure out what goes into higher level stuff.
Hans: When we get comments back and agenda for face-to-face then we have solid grounding.
Jeff: Implementations can guide us. I know we have Dave's experience from his implementation. Are there other implementations?
Rex: Comments should help fill that gap. I have programs that I may be able to leverage from NCOIC stuff that should work with the DE.
Hans: I can think of other industries that use XML and other messages that might be a model for us, business, e-commerce, not sure how much we want to stay out of our domain.
Jeff: Don also has his prototype work on routing. Any further agenda items?
Rex: I'd suggest you work with Dave to set agenda on practical grounded stuff. The DoD stuff is what I’m concerned about, they have high level, they are using Dave and my concepts but they aren’t going to change anytime soon, but the SOA stuff is not EM stuff, so it’s not appropriate to discuss it here.
Jeff: Anything else for us to discuss today?
Elysa: I’m glad we’re having a full hour. Of course, Don and Dave not being here, the group is making good progress. And I’m good about waiting for call for comments. And we can pencil in so we can identify funding.
Rex: I was going to agree, but if Jeff and Hans want to discuss.
Jeff: Do we have a rough face-to-face time?
Elysa: End of June is still possible.
Hans: Did it fit with a trade show or other event? The more advance notice the better. I can always fund if also doing other activities in the area.
Elysa: Early Mon/Tue, the week of the 28th in DC.
Rex: I have semantic technology conference the week before in San Francisco, presenting on the 23rd, from 25th on I’m available.
Hans: Then July 4 long weekend.
Elysa: Is everyone available then? I do have member section call for today, so I’ll be inquiring about funding for face-to-face there.
------
TOPIC: Need for XML Editors
------
Rex: I will ask for xml spy. As a tool that we can use for XML.
Elysa: I wasn’t aware of a request. Ok, sorry, I missed that.
Rob: My 2 cents, the basic tool everyone uses for xml development.
Elysa: How many do we need and what is the cost?
Rob: Let me look on website?
Elysa: IS EA (Enterprise Architect) working for us?
Rob: EA is more for requirements gathering but XMLSpy is more the guts.
Rex: Those are the two tools that go together. They are as close to a standard as you get to proprietary stuff. They don’t have universal approval, but they are used by enough people in the industry.
Rob: Somebody like MITRE can get it automatically, but us poor consultants wonder where we can get one. Probably need 2 or 3. Rex, Werner, Rob ...
Hans: I use a different product, but I think that’s ok, I use Stylus Studio.
Gary: That’s true with me too.
Elysa: Rob if you can get pricing and get that to me.
------
TOPIC: Best Practices Guide – Outline
------
Jeff: To begin our discussion of the best practices guide, perhaps we could talk about an outline.
Rex: DE Basics covers that, so pick up from there.
Hans: I was thinking 2 or 3 scenarios involving routing, simplest within an org and two that are across organizations, one low level security, one higher
Rex: Good if could cross international boundaries. And just so you know, All Hazards Alert and Warning, just finished 150 change request and is in review for final voting, and then we have EDXL DE and CAP both in a combined system where they walk in tandom. So I wanted to use those as a basis for the next set, and I wanted to get folks from this TC or from NCOIC into this TC so we could get some cross-connection to use our time more wisely, to get more bang for the buck. So you could use stuff from there. Bunch of people to help standard.
Jeff: Intro, scenarios, requirements, approaches for what DE would look like to address those scenarios..
Hans: Concept of routing based on info included in the DE and inside the included document versus routing based on external meta-data. Draw a distinction between those two.
Rex: Separation of content for routing v. content for content
Hans: But also for content for routing, ... most implementations use SOAP and web services and a bunch of other protocols not part of DE out of band, and other implementations use the DE header for the routing, so we need to address both of those two. That’s a key idea that gets us past having to overload all routing functions into the DE.
Jeff: Where the DE is special.
Hans: Implementation-specific approaches and list them and similarly when you do routing, you need to look at message exchange patterns, so a pub/sub versus request/response, and some like reply-to are more required for a request/response.
Gary: If you really want to look at various message patterns, look at EBXML, which go beyond message out, etc., they are about patterns and choreographies.
Rex: And RM does that a lot. That’s built into RM
Gary: There are some choreographies.
Jeff: Agree, let’s start with outline.
Rex: Move to adjourn. Hans second.
Meeting Adjourned.