Draft Meeting Notes from the EM CAP-Profile SC Telecon Meeting

Date: January 22, 2009 11:00 AM EST

A quorum was in attendance.

Attendees

Bob Bunge

Sukumar

Gary Ham

Tim Grapes

Bill Kalin

Dennis Gusty

Elysa Jones

Tom Ferrentino

Jacob Westfall

Rex Brooks

  1. Note Taker Appointed
  2. Meeting notes taken by Tom Ferrentino
  3. Approve Meeting Notes from January 15, 2009
  4. Approve meeting minutes from last meeting motion approved by Rex Brooks and amend the change from 13th to the 15th on the content of the notes. The motion was seconded by Elysa Jones.
  5. Tom Ferrentino made the correction @ 12:30 PM 1/22/2009
  6. Public review announcement on submission document:
  7. Needed to have more background information. Rex then put the boilerplate back in and added background information. Mary recommended a 15 day for review instead of 7. TC did accept the document for review. Needs to be reviewed by Oasis to get to review.
  8. Rex: Mary offered to have someone in OASIS take Rex’s document and placing it into a spreadsheet. Rex is still working on the first draft and will work along with them.
  9. SD: Content looks fine and all we need to review is the structure of the content.
  10. Rex uploaded a rules document today. 85 to 90 percent done as far as the CAP elements are concerned. Sukumar uploaded the IPAWS requirements document. Table gives a terse and succinct view of the profile. Does not give them an idea of how to use it.
  11. Gary says there needs to be a similar thing done with the Hazcollect side. Gary can help with Hazcollect and find out what the NWS side is doing.
  12. RB: Need more for CMAS also
  13. SD: Line up business rules for each system
  14. RB: Anything he does from here will be relatively easier. Needs to be prioritized on what needs and does not need to be in the document. Work on Organizing and formatting.
  15. SD: Open this up for discussion with the group on how we want to fill out this information
  16. EJ: Use style where each processing rules are in a different section. Will help us if any comments come in and changes need to be made.
  17. EJ: Who might be responding to the comments
  18. RB: Floor is open to discussion…
  19. Benefit to the implementers
  20. JW: Could be a lot of changes to be made based on the implementation based on the non-normative stuff. Are setting ourselves up for a monthly changes based on comments.
  21. RB: Should non-normative be in a specifications section or in a separate document altogether? Requires some thought and does not need to be decided today.
  22. Good idea to get most important things into the specification (or a separate document).
  23. SD: Discussion on the structure of the documents that goes out for public review.
  24. RB: Second table needs to stay in the order that it is. More detail and less priority.
  25. RB: First table has minimal number of elements, second has table has all four profile requirements, third character limitations, urgency, severity, code list, code table for EAS, etc…
  26. EJ: Conformance information that NIMS STEP will be using for the profile. Industry group will be intent on hoe the profile conformance will be tested.
  27. TG: TC can work with NIMS STEP folks and work out the conformance issues.
  28. RB: Ask Gary Ham (who has experience with this) if he can on the targets (EAS, Hazcollect, CMAS, etc…) and the conformance issues.
  29. SD: Ask Elyse if she can work with the NIMS STEP folks in regards to the profile conformance issues.
  30. RB: Need to educate the IPAWS people with what the conformance issues are with OASIS and also need to do this with the NIMS STEP folks.
  31. BK: Things are going on behind the scenes that cannot be discussed right now. It is on the NIMS STEP radar right now.
  32. SD: Move forward on what we can work on including the conformance issues. We can have the NIMS folk’s revue it at a later time. Work out more detail plans.
  33. EJ: Let’s get something out there.
  34. SD: CAP does not have a conformance section, should we have one for the profile?
  35. EJ: It is more critical to have one for the Profile, go through the specification you do not have a choice, Rex agrees. Should get something out there and get comments on it.
  36. RB: Asked Sukumar to take action item on it and he accepted.
  37. RB: How do we want it structured at this stage? Would like a motion on the vote…
  38. TG: Minimize the non-normative text?
  39. RB Long range goal, can take it out a lot easier than putting it in. Would like to put as much in right now. Show what we are missing for CMAS and Hazcollect.
  40. RB: Can always take it out and add to a second document.
  41. TG & JW – Great idea for a comment period
  42. EJ: Accept the motion that the formatting of the document that each of the sections are in the same document – seconded by Rex.
  43. SD: Conformities section – Rex talk to us on the different section
  44. RB – Have first draft by next Tuesday
  45. RB: First Page – Include the Canadian profile or saying something about it?
  46. RB asks Bill if IPAWS is a government mandated system.
  47. EJ: Says that she believes there is no specific legislation that it says that
  48. EJ: Legislation is the FCC point in order
  49. Title of the document:
  50. EJ: Needs to say DHS FEMA IPAWS
  51. EJ: Not important that Canadian profile needs to be in the document. It still must be regarded as part of this committee and future discussion and concern.
  52. RB: Declared XML Namespace - Abstract is drawn largely by the FEMA IPAWS requirements document. Put in red to think about the abstract for this specification.
  53. Introduction and US Specific concerns – Language from the FEMA requirements..would like group affirmation on this issue
  54. SD: Waiting on FEMA confirmation on this
  55. RB: End of this section is two paragraphs on concerns that need to be understood and decisions needed to make. Make sure that they belong there.
  56. RB – Terminology section specifically saying on what is needed to be done.
  57. EJ: The intent of the profile is not to change the original CAP. Is intended to validate against any CAP 1.1 schema. This needs to be in here. We do not want anyone saying this is not really CAP.
  58. RB – Made the change and saving the document…Will be working draft 01.
  59. SD: Gary can you help with the Hazcollect information?
  60. GH: Once he gets most of it put together and Gary can go in and confirm whatever Rex has in there and add and subtract whatever is in there. Probably cannot be done in parallel.
  61. RB: Will leave place holders for optional and required
  62. BB: Only contact with Hazcollect is with Herb White.
  63. GH: Only contact is with people that have programmed to the interface and what CAP accepts. And contact with those who did the programming on the Hazcollect interface.
  64. BB: Appropriate person should most likely be Herb White.
  65. RB: Like the way OGC defines their profiles. Have not recommended a version of his own. Did research and likes OGC’s formatting of the profile.
  66. SD: Can we do this on the list itself? Once we get can agree on a definition then we can extract it into the document. If someone could champion that it would be great.
  67. RB: If someone wants to run with it that would be great
  68. 1.4 Non-Normative references – If we had a second document this is where we would extract it out. Where ever it is appropriate we would like to have all reference materials under non-normative references. Part of what people think is boilerplate. Implementers guide can go here. Cite materials from the FEMA IPAWS PMO and any other official sources. This document needs to have a URL and something that we can cite.
  69. 4.5.1 – IPAWS status rules –
  70. EAS Status processing Rules
  71. “Test” may be used to test task reception
  72. EJ – Discussed heavily in the industry group. Does a test get sent or not? Do not know how well it worked out.
  73. RB: Made it red so it is something that may need to be worked out
  74. 4.18 event – several in a row where an element is required by CAP IPAWS exchange processing partners but no processing rules – Flagged all of these
  75. Event Code – Put table of abbreviations of eventCode.
  76. EJ: eventCode critical for interoperability. Get outside of the United States we need to think about eventCode. Future agenda topic eventCode!
  77. SD: Non specific list that can be maintained
  78. JW: Does NIST maintain event codes?
  79. EJ: FCC is uses codes but codes are assigned by NIST. Do more research on this…?
  80. Specific kinds of rules for parameter don’t think it will be a problem. Specific processing codes for specific parameters.
  81. SD: Open up to the group if there are any other items and or concerns?
  82. Motion to adjourn – Elysa accepts motion and adjournment is unanimous