IEF Reference Architecture Avatar
  1. OMG Specification

IEF Reference Architecture — Closed Issues

  • Acronym: IEF-RA
  • Issues Count: 68
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
IEFRA_-145 correction for IEFRA-42 IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-31 Compliance section confusing IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-24 Add clarifying note that alternative implementations for email are possible IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-93 Security considerations section IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-90 change in wording 2 IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-168 Amend IEFRA-43 Proposal IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-149 Amend IEFRA-24 Proposal IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-179 Amend IEFRA-166 (Amend IEFRA-42) IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-178 Amend IEFRA 149 (Amend IEFRA-24) IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-46 Standard Fuzzy Bitmap Diagram Gripe IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-23 typo for TrustmarkData IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-26 Clarify permissions required for file access within folders IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-21 Verify that XSD, figures and text match for Attribute names etc IEF-RA 1.0b1 IEF-RA 1.0 Duplicate or Merged closed
IEFRA_-19 Resolve inconsistency of text and number of response values listed for AuthorizationResponseType entry IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-17 Add (new) security considerations section IEF-RA 1.0b1 IEF-RA 1.0 Duplicate or Merged closed
IEFRA_-15 Fix spelling errors. IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-13 Random "*" IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-11 Typos in attribute names, mismatches with XSD IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-9 Fix typos in Figures 5 and 10 IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-7 Figure text is blurred and not clear IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-1 Correct OMG document URLs IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-25 ISSG Request Message does not match document figure 39? IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-32 SAMSON references IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-41 Inventory problems IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-44 Use standard OMG document number formats IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-47 i.e./e.g. IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-34 Agreement IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-33 Typo IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-42 Use definitional language IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-36 Bullet context IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-92 Recommended word change IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-91 Type IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-89 Change in wording IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-88 Issue in XSD IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-87 Assorted Typos IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-86 Issue with IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-85 Issues in Glossary IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-84 Correct Document Numbers in Annex A and B IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-83 Errors in TOC IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-82 IPR / Licensing Wording in Document IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-154 Ammend to IEFRA-41 Proposal IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-5 Meaning of parenthetical "suite or virtual machine" not clear IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-3 Fix Broken URL links in glossary IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-37 Typographic error IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-40 Typo IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-43 Agreement IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-39 Agreement IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-35 Section 1.2 clause list inaccurate IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-45 Dates and places IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-38 Non-sentence IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-71 Policy or policies? IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-70 Pagination IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-69 Inconsistent punctuation, esp. commas and semicolons IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-68 Make bullets points consistent IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-67 Table of Contents title IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-66 Verb form IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-65 Verb form IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-81 informative ancillary files in FTF Report confusion IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-80 IPR Mode in Licenses Clause IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-172 Non-URL issues in IEFRA-3 IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-167 Amend IEFRA-41 Proposal IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-166 Amend IEFRA-42 Proposal IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-165 Amend IEFRA-3 proposal IEF-RA 1.0b1 IEF-RA 1.0 Deferred closed
IEFRA_-162 Amend IEFRA-31 issues IEF-RA 1.0b1 IEF-RA 1.0 Duplicate or Merged closed
IEFRA_-161 Ammend IEFRA-36 Proposal IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-150 Amend IEFRA-71 Proposal IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-148 Ammend IEFRA-31 proposal IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed
IEFRA_-146 Ammend IEFRA-5 Proposal IEF-RA 1.0b1 IEF-RA 1.0 Resolved closed

Issues Descriptions

correction for IEFRA-42

  • Key: IEFRA_-145
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    Note: IEFRA-21 in FTF 1 was renumbered as IEFRA-42 in FTF 2.

    As a specification, this document should be definitional ("XYZ is ...") not aspirational ("XYZ will be ..."). Pretend you're reading the specification 5 years in the future, when all the component specifications that make up IEF have been written. Sentences cst in the future tense like "The IEF will provide the ability and capacity for people, processes, and systems to work together efficiently ..." will not then make sense.

    There are 78 sentences containing the word "will" in the specification, and I'll wager that at least 70 of them should be recast as definitions ("IEF specifies X") instead of aspirations ("IEF will do X when it's finished"). There are also two sentences containing the word "seeks" that should be considered for rephrasing.

    (This issue was rainsed at the specification's pre-adoption AB review).

  • Reported: IEF-RA 1.0b1 — Sun, 13 May 2018 03:05 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    Require correction to IEFRA-42 proposal

    Issue with the Proposal to the correction for IEFRA-42

    Required correction of minor typographical issues.

    This sentence is convoluted and it is not clear how to parse it:
    "The sequence diagrams in this Annex illustrate a representative set of interactions between IEF components during their adjudication and enforcement user security policy for structure messaging, email exchange, file sharing and instant messaging."

    Should it be "enforcement of user security policy?" Is it interactions among IEF components, or between IEF compoments and what else?

    The next sentence has a mistake: "do not characterized" should be "do not characterize".

    I voted "no" on the wrong issue – left comments on #150 that were actually for this one:
    a) part of the revision doesn't make sense. "illustrate a set of interactions between IEF components during their adjudication and enforcement user security policy...". Can't tell who the "their" is referring to unless the IEF components are the ones performing the adjudication and enforcement. If that is the case, then need to insert an "of" between "enforcement" and "user security policy".
    b) Typo in the next sentence – "...IEF components and do not characterized all.." should be "...IEF components and do not characterize all.."

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Compliance section confusing

  • Key: IEFRA_-31
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    Section 2.2 says there are 4 compliance points, but then later on says "A vendor or integrator may select one of the compliance points described below, or combine the capabilities to form additional compliant configurations", implying that implementers may ignore the compliance points - which means they aren't actually compliance points at all. The relationship between components, configurations and compliance points isn't clear. I would also expect each of the 4 compliance points to have their own section at the same heading level, but "File Share" is section 2.3.2.1 while "Structured Messaging" is 2.3.1.

    Overall, this section needs more work.

    (This issue was raised during the specification's pre-adoption AB review).

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 14:49 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    Readdress Compliace wording

    The wording should have been - "combine the compliance points" vs the capabilities.

    Meaning an implementer can develop a solution with one or more of the compliance points addressed.

  • Updated: Tue, 8 Oct 2019 17:56 GMT
  • Attachments:

Add clarifying note that alternative implementations for email are possible

  • Key: IEFRA_-24
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    For file retrieval I note that for extremely large files it could be inefficient to retrieve the entire file to parse out the SAC to get the meta data and then deny; would spec disallow a smarter file server that returns only the metadata (over the secure bus) as a first step , then only retrieve file if authorized? I believe answer is spec would not disallow this.

    This would be an implementation optimization and the flows are only examples

    Adding a note to this effect might be helpful, along with this optimization example for email.

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 17:09 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    Readdress IEFRA-24

    Deferred until RTF

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Security considerations section

  • Key: IEFRA_-93
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    IEFRA-9
    Not asking for a book, simply a paragraph or two in a section that summarizes the security concerns noted elsewhere in the document. Not unreasonable for a specification of this complexity.

    NOTE to AB, we should review whether Security/Privacy Considerations should be generally required in specifications going forward.

  • Reported: IEF-RA 1.0b1 — Sat, 29 Dec 2018 03:11 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    correction to IEFRA-93

    Not asking for a book, simply a paragraph or two in a section that summarizes the security concerns noted elsewhere in the document. Not unreasonable for a specification of this complexity.

    NOTE to AB, we should review whether Security/Privacy Considerations should be generally required in specifications going forward.

    Added Section "1.10 Security Considerations" to the IEF-RA. This is considered a minor change because the information was already in the document.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

change in wording 2

  • Key: IEFRA_-90
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    IEFRA-21

    Change
    “These diagrams are not intended to prescribe the operations of the each component, which will be documented in a separate specification, E.g.:”
    in Annex D to read
    “These diagrams are not intended to prescribe the operations of the each component that is documented in a separate specification, e.g.:”

    2nd bullet: change “The PPS that will be defined” to “The PPS defined”

    Is this sentence needed? Perhaps better not to imply frequent changes will be needed.
    “This Reference Architecture will be updated to reflect change imposed by the individual component specifications.”

    Change
    “The choices in the selection of components and specifications will guide the sequencing of activities within and between the components.”
    To
    “The choices in the selection of components and specifications guide the sequencing of activities within and between the components.”

    Change in 3 places:
    “Many of these considerations will be addressed”
    to
    “Many of these considerations are addressed”

  • Reported: IEF-RA 1.0b1 — Sat, 29 Dec 2018 03:03 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    *Required Editorial Change to IEF-RA proposal *

    Deferred to RTF - the documents have been submitted - and a stable version is required for NAT0 evaluation and Testing in June

    Requires minor correction for typographical errors

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Amend IEFRA-43 Proposal

  • Key: IEFRA_-168
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    The proposed resolution does not appear to address the first of the two agreement problems raised by the issue submitter.

    "the Policy Enforcement Point (PEP) feature that form..." should still be EITHER "the Policy Enforcement Point (PEP) feature that forms..." or "the Policy Enforcement Point (PEP) features that form..."

  • Reported: IEF-RA 1.0b1 — Fri, 8 Mar 2019 02:15 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    Requireed correction to Proposal for IEFRA-43

    Deferred to RTF - the documents have been submitted - and a stable version is required for NAT0 evaluation and Testing in June

    Requires minor correction for typographical errors

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Amend IEFRA-24 Proposal

  • Key: IEFRA_-149
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    Suggest different wording (affected text shown under the numbered list):
    1- remove "to" between "metadata" and "authorizes".
    2 - add a period after the closing parenthesis just before "This Reference Arch..."
    3 - "updated to reflect change" should be "updated to reflect changes"
    4 - "are representatives of the interactions between IEF components" should be "representative of interactions between IEF components"
    5 - "adjudication" should be "adjudications".
    "...metadata to authorizes receipt or release, or filtering specific non-complient elements) This Reference Architecture will be updated to reflect change imposed by the individual component specifications for the PEP, PDP, PAP, and PPS. The Sequence Diagrams in this Annex are representatives of the interactions between IEF components, and do not represent all possible interactions or adjudication of user security policy..."

  • Reported: IEF-RA 1.0b1 — Wed, 6 Mar 2019 02:39 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-149

    Suggest different wording (affected text shown under the numbered list):
    1- remove "to" between "metadata" and "authorizes".
    2 - add a period after the closing parenthesis just before "This Reference Arch..."
    3 - "updated to reflect change" should be "updated to reflect changes"
    4 - "are representatives of the interactions between IEF components" should be "representative of interactions between IEF components"
    5 - "adjudication" should be "adjudications".
    "...metadata to authorizes receipt or release, or filtering specific non-complient elements) This Reference Architecture will be updated to reflect change imposed by the individual component specifications for the PEP, PDP, PAP, and PPS. The Sequence Diagrams in this Annex are representatives of the interactions between IEF components, and do not represent all possible interactions or adjudication of user security policy..."

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Amend IEFRA-166 (Amend IEFRA-42)

  • Key: IEFRA_-179
  • Status: closed  
  • Source: Jackrabbit Consulting ( Mrs. Charlotte Wales)
  • Summary:

    typos again –
    Clause 6.1, Para 1, Pg 24
    a) " It will also be of interested to tool vendors interested in developing products..." should be "It will also be of interest to tool vendors interested in developing products...", i.e., replace "interested" with "interest" after "It will also be of.."
    Clause 9, Para 1, page 71
    b) In "It can be an information source for end users, auditors and developers who seek to understanding the the services that enforce and govern secure and trusted information sharing." Replace "seek to understanding the the" with either (your choice) "seek to understand the" or "seek understanding of the"

  • Reported: IEF-RA 1.0b1 — Mon, 18 Mar 2019 19:56 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    Deferred to RTF - IEFRA-179

    Deferred to RTF - the documents have been submitted - and a stable version is required for NAT0 evaluation and Testing in June

    Requires minor correction for typographical errors

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Amend IEFRA 149 (Amend IEFRA-24)

  • Key: IEFRA_-178
  • Status: closed  
  • Source: Jackrabbit Consulting ( Mrs. Charlotte Wales)
  • Summary:

    a) part of the revision doesn't make sense. "illustrate a set of interactions between IEF components during their adjudication and enforcement user security policy...". Can't tell who the "their" is referring to unless the IEF components are the ones performing the adjudication and enforcement. If that is the case, then need to insert an "of" between "enforcement" and "user security policy".
    b) Typo in the next sentence – "...IEF components and do not characterized all.." should be "...IEF components and do not characterize all..

  • Reported: IEF-RA 1.0b1 — Mon, 18 Mar 2019 19:52 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    Deffered to RTF - IEFRA-178

    Deferred to RTF - the documents have been submitted - and a stable version is required for NAT0 evaluation and Testing in June

    Requires minor correction for typographical errors

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Standard Fuzzy Bitmap Diagram Gripe

  • Key: IEFRA_-46
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    The SFBDG ("Standard Fuzzy Bitmap Diagram Gripe") applies. There are 48 figures in the specification, and at least the first 21 are bitmaps that look fuzzy at high magnification (after that I stopped checking). What's more, many are JPEGs, a file format designed for photographs and completely unsuitable for this sort of diagram. All the bitmap diagrams will need to be replaced with vector graphics (preferably in open standard SVG format).

    UML diagrams are best exported (in SVG format) from the UML tool being used to maintain the model. If your tool can't export SVG, there are many others that can, and some of the vendors generously offer free licences to OMG specification authors. If all else fails, take a look at this free tool that allows you to specify UML diagrams via textual commands, and exports the result as SVG:

    http://plantuml.com/
    https://en.wikipedia.org/wiki/PlantUML
    https://www.planttext.com/

    The free drawing tool Inkscape can also be used to edit SVG diagrams if required.

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:05 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction to IEFRA-46

    Note: IEFRA-17 in FTF 1 was renumbered as IEFRA-46 in FTF 2.

    The SFBDG ("Standard Fuzzy Bitmap Diagram Gripe") applies. There are 48 figures in the specification, and at least the first 21 are bitmaps that look fuzzy at high magnification (after that I stopped checking). What's more, many are JPEGs, a file format designed for photographs and completely unsuitable for this sort of diagram. All the bitmap diagrams will need to be replaced with vector graphics (preferably in open standard SVG format).

    UML diagrams are best exported (in SVG format) from the UML tool being used to maintain the model. If your tool can't export SVG, there are many others that can, and some of the vendors generously offer free licences to OMG specification authors. If all else fails, take a look at this free tool that allows you to specify UML diagrams via textual commands, and exports the result as SVG:

    http://plantuml.com/
    https://en.wikipedia.org/wiki/PlantUML
    https://www.planttext.com/

    The free drawing tool Inkscape can also be used to edit SVG diagrams if required.

    (Comment) When originally created the version of MSword used would not present and SVG image. For FTF 1 - A set of SVG images was provided as an Auxiliary document (.zip). The current version of MSword presents SVGs, So all the PNG model images in the document were replaced with SVG images in the Reference Architecture and the auxilliary document eliminated.

  • Updated: Tue, 8 Oct 2019 17:56 GMT
  • Attachments:

typo for TrustmarkData

  • Key: IEFRA_-23
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    typo for TrustmarkData (ISSG Response Message) in mars/2017-05-03 ; XSD for ISMD and supporting data types

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 17:24 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-23

    Note: IEFRA-14 in FTF 1 was renumbered as IEFRA-23 in FTF 2. This element also related to the changes in IEFRA-132.

    typo for TrustmarkData (ISSG Response Message) in mars/2017-05-03 ; XSD for ISMD and supporting data types

    Corrected typos in Section 16.3.10 ISSG Response Message:
    Corrected typos in diagram and replaced diagram.
    Replace Table 30 - page 182 "Trustmarks" --> "Trustmark"
    Replace Table 30 - page 182 "Trustmatks" --> "Trustmark"

    Also corrected in Document TrustmarkData (ISSG Response Message) in mars/2017-05-03 XSD

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Clarify permissions required for file access within folders

  • Key: IEFRA_-26
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    For folder access it isn’t clear, but It think from the flow diagram that not only do you need folder permission to list the folder contents, but also permission to access each item in the folder to display it in the list? Is this correct? It wasn’t entirely clear.
    (looks like this is different from Unix execute directory permissions)

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 17:11 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-26

    Note: IEFRA-13 in FTF 1 was renumbered as IEFRA-26 in FTF 2.

    For folder access it isn’t clear, but It think from the flow diagram that not only do you need folder permission to list the folder contents, but also permission to access each item in the folder to display it in the list? Is this correct? It wasn’t entirely clear.
    (looks like this is different from Unix execute directory permissions)

    It is - and adds another level of security for shared networks requiring operating with multiple security and caveat domains.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Verify that XSD, figures and text match for Attribute names etc

  • Key: IEFRA_-21
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    Verify that attribute names match (e.g. spelling etc) in text, figures and XSD

    I noticed some inconsistencies (filed in a separate issue) which suggest an automated verification would be valuable.

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 17:00 GMT
  • Disposition: Duplicate or Merged — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-21

    Note: IEFRA-11 in FTF 1 was renumbered as IEFRA-21 in FTF 2.

    Duplication of IEFRA-11 - corrections provided in IEFRA-132.

    All the IEFRA Message Diagrams were compared with there XSDs and differences corrected in IEFRA-132.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Resolve inconsistency of text and number of response values listed for AuthorizationResponseType entry

  • Key: IEFRA_-19
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    Annex B
    AuthorizationResponseType entry

    text says "As per the XACML standard, this field can take one of three values"

    but

    in table more than 3 are defined, not clear how this can be. Assume that this spec is thus extending what can be returned beyond what the XACML standard defines. Maybe text should be clarified with “but the IEF defines additional values as shown here”

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:58 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-19

    Note: IEFRA-10 in FTF 1 was renumbered as IEFRA-19 in FTF 2. There were no additional comment from FTF 1.

    Annex B
    AuthorizationResponseType entry

    text says "As per the XACML standard, this field can take one of three values"

    in table more than 3 are defined, not clear how this can be. Assume that this spec is thus extending what can be returned beyond what the XACML standard defines. Maybe text should be clarified with “but the IEF defines additional values as shown here”

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Add (new) security considerations section

  • Key: IEFRA_-17
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    In general, I think it could be useful for such a document to have a security considerations section that outlines in broad terms some of the major security assumptions (and associated risks) that are applicable. For example, elsewhere in the body of the IEF RA it notes that a secure messaging bus is necessary, and that this separates the traffic from other traffic and provides protection. Another example might be how external services can be trusted, and how far vulnerabilities could propagate through the system (e.g. issues with key strength, algorithms etc, CA issues etc) and how such issues might be detected. Another item might be prevention of bypassing proxies (e.g managed in most cases via prior encryption). These high level notions are not implementation specific but are assumptions for the overall architecture, and also relate to implementation.

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:54 GMT
  • Disposition: Duplicate or Merged — IEF-RA 1.0
  • Disposition Summary:

    Proposal for IEFRA-9

    This is a specification on data protection - addressing all related data, platform and network security assumptions and risks cannot be accomplished in a paragraph or two - and beyond the scope of this reference architecture.

    The tolerance for risk and selection technology for each supporting service (IdM, Access Controls, Crypto, ...) is at the discretion of the user. I have a book "Information Security Management Handbook - ISBN-10: 0-8493-7495 -2" providing 3300 pages of description on the suggested topics - not sure what could be said in a couple of paragraphs that would cover the scope of these topics. Take this up in RTF - and see if someone can suggest something useful. Dozens of other books in the library as well - many with differing approaches.

    I am really concerned with the scope the IEF has been asked to incorporate over the years.

    ------
    FTF 2

    This is the response from FTF1 - the issues as resolved as an FTF2 issue IEFRA-93. A discussion with the FTF AB Reviewer clarified the expected scope, which was less onerous then anticipated. Addressing this issue was central to initiating FTF -2. It was felt by the submitters that is was a key issue to address.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Fix spelling errors.

  • Key: IEFRA_-15
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    Please run spell checker on entire document.

    I noticed the following spelling errors:

    I assume ‘defence’ is the French spelling, I am familiar with ‘defense’. Thus 'defence-in-depth’ could be updated.

    1.7.3 specifiy

    3.1 #11 change two typos, "IEF Reference Arcitecture FRP” to "IEF Reference Architecture RFP”

    suggest adding informative reference for SAMSON:
    http://cradpdf.drdc-rddc.gc.ca/PDFS/unc251/p804697_A1b.pdf

    6.7 replace in with is in UAF defintion last sentence

    Annex A, Annex B (multiple instances)
    machione

    Annex B
    "into e PPS” InfromationElementMetadata

    Annex B - PPS Policies
    confimin
    is issues

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:48 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-15

    Corrected Identified Spelling Errors

    Conducted an additional spelling review - see end of revised text

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Random "*"

  • Key: IEFRA_-13
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    Entry #12 has * but no associated text - if this is a footnote, where did the associated text go?

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:46 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-13

    Note: IEFRA-7 in FTF 1 was renumbered as IEFRA-13 in FTF 2

    Entry #12 has * but no associated text - if this is a footnote, where did the associated text go?

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Typos in attribute names, mismatches with XSD

  • Key: IEFRA_-11
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    Figure 39: Request-Identity-Attrubute should be Request-Identity-Attribute (ISSG Request Message)
    also doesn’t match XML - XSD has ""Requested-IdentityAttribute”
    (I have not compared all XML with all figures, but noticed this one)

    Figure 40: Typo, TrustmatkData (ISSG Response Message)
    element name in XML is “Trustmark”, not “Trustmarks” in diagram
    typo for TrustmarkData is in XSD file as well

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:44 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA11

    Note: IEFRA-6 in FTF 1 was renumbered as IEFRA-11 in FTF 2.

    Reviewed all ISMB Message Diagrams and made a number of Editorial corrections to align spelling Figures and XSDs.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Fix typos in Figures 5 and 10

  • Key: IEFRA_-9
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    figure 5 send-email
    typo “receie" in alt -all recipients authorized

    Figure 10
    Instance Deployment not Instant Deployment (in caption)

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:42 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-9

    Note: IEFRA-5 in FTF 1 was renumbered as IEFRA-9 in FTF 2.

    figure 5 send-email: typo “receie" in alt -all recipients authorized

    Searched for "receie" throughout page 14 and could not find it.

    Figure 10: Instance Deployment not Instant Deployment (in caption)
    Replace "Instant" with Instance in Caption. Figure 10 became Figure 13 after the restructuring of Clause 2

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Figure text is blurred and not clear

  • Key: IEFRA_-7
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    Fix figure to be clear at various resolutions, text is not readable. Figure 2 and 9.

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:39 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-7

    Note: IEFRA-4 in FTF 1 was renumbered as IEFRA-7 in FTF 2.

    Replaced diagrams in clause 2 to improve clarity.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Correct OMG document URLs

  • Key: IEFRA_-1
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    OMG document identifiers need to follow standard OMG format

    Annex A
    "mars20170503" (use mars/2017-05-03)

    Annex B
    "mars 20170504" (use mars/2017-05-04)

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:30 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-1

    The JIRA reference remained IEFRA-01 for both FTF1 and FTF2. Additional correction in IEFRA-84 to correct for changing document numbers.

    Issue:
    Incorrect document number formats in in Annex A and Annex B.

    The document numbers were changed between FTF1 and FTF2, as follows:

    In FTF 1 the documents references were changed:
    replace "mars20170503" with "ptc/2018-05-21" in Annex A
    replace "mars20170504" with "ptc/2018-05-22" in Annex B

    In FTF 2 the documents were changed to

    replace "mars20170503" with "ptc/2018-05-21" in Annex A
    replace "mars20170504" with "ptc/2018-05-22" in Annex B

  • Updated: Tue, 8 Oct 2019 17:56 GMT

ISSG Request Message does not match document figure 39?

  • Key: IEFRA_-25
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    ISSG Request Message does not match document figure 39?

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 17:26 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEF-RA-25

    Note: IEFRA-15 in FTF 1 was renumbered as IEFRA-25 in FTF 2.

    ISSG Request Message does not match document figure 39?

  • Updated: Tue, 8 Oct 2019 17:56 GMT

SAMSON references


Inventory problems

  • Key: IEFRA_-41
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    In the accompanying submission Inventory, mars/17-05-07, "Auxiliary Files:" should be "Ancillary Files". In fact, the "IEF Model in in XMI" should be labelled informative or normative, not ancillary. The inventory itself should be labelled as informative. Here's some guidance on what labels to give to files:

    Normative: A document that specifies how a conforming implementation shall behave (but may contain specifically-labelled non-normative sections).

    Informative: Non-normative material aimed at users of the specification, such as examples or non-normative guidelines.

    Ancillary: Material intended to help OMG Members reviewing the report or creating future revisions of the specification, such as a change-tracked specification showing issue resolutions applied, editable source of models stored in proprietary formats, or programs used to build parts of the specification from machine-readable sources. The specification shall be usable without reference to the ancillary files, which should not be given URLs.

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:35 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    Resolution to IEFRA-41

    Deferred to RTF - the documents have been submitted - and a stable version is required for NAT0 evaluation and Testing in June

    Requires minor correction for typographical errors

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Use standard OMG document number formats

  • Key: IEFRA_-44
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    Non-standard OMG document numbers used in several places. In each case, please replace with numbers that conform to OMG document number syntax:

    1. Three on the cover page:

    mars-20170502 - IEF RA Attachments.docx
    Mars-20170503 - IEF ISMB messages XML.zip
    mars-20170504 - IEPPV-PPS Policy XSDs.zip

    2. In the introduction to Annex A: "mars20170503 ISMB Messages XSD.zip".

    3. A few lines into Annex B: "mars 20170504 - IEPPV-PPS Policy XSDs."

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:32 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    correction for IEFRA-29

    Note: IEFRA-2 in FTF 1 was renumbered as IEFRA-3 in FTF 2.

    Non-standard OMG document numbers used in several places. In each case, please replace with numbers that conform to OMG document number syntax:

    1. Three on the cover page:

    mars-20170502 - IEF RA Attachments.docx
    Mars-20170503 - IEF ISMB messages XML.zip
    mars-20170504 - IEPPV-PPS Policy XSDs.zip

    2. In the introduction to Annex A: "mars20170503 ISMB Messages XSD.zip".

    3. A few lines into Annex B: "mars 20170504 - IEPPV-PPS Policy XSDs."

    Note: IEFRA-44 (29) is a similar issue to IEFRA-1.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

i.e./e.g.

  • Key: IEFRA_-47
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    In Table 10 "Simple Mail Transfer Protocol (SMTP) is an Internet standard for e-mail transmission (e.g., RFC 5321);", the "e.g." should be "i.e.".

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:30 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction to IEFRA-47

    Note: IEFRA-27 in FTF 1 was renumbered as IEFRA-47 in FTF 2.

    In Table 10 "Simple Mail Transfer Protocol (SMTP) is an Internet standard for e-mail transmission (e.g., RFC 5321);", the "e.g." should be "i.e.".

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Agreement

  • Key: IEFRA_-34
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    In section 2.1 "An implementer may select to implement one of more of the service patterns." needs correcting ("of"->"or", "select to implement").

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:27 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-34

    Note: IEFRA-25 from FTF 1 is now IEFRA-34 in FTF 2.

    In section 2.1 "An implementer may select to implement one of more of the service patterns." needs correcting ("of"->"or", "select to implement").

    This was also addressed with IEFRA-31 / IEFRA-118 and the restructuring of Clause 2.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Typo

  • Key: IEFRA_-33
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    In section 1.8 there's a single spurious back-quote character after "architectural artifacts".

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:26 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-33

    Note: IEFRA-24 in FTF 1 became IEFRA-33 in FTF 2.

    Spurious ' in section 1.8

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Use definitional language

  • Key: IEFRA_-42
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    As a specification, this document should be definitional ("XYZ is ...") not aspirational ("XYZ will be ..."). Pretend you're reading the specification 5 years in the future, when all the component specifications that make up IEF have been written. Sentences cst in the future tense like "The IEF will provide the ability and capacity for people, processes, and systems to work together efficiently ..." will not then make sense.

    There are 78 sentences containing the word "will" in the specification, and I'll wager that at least 70 of them should be recast as definitions ("IEF specifies X") instead of aspirations ("IEF will do X when it's finished"). There are also two sentences containing the word "seeks" that should be considered for rephrasing.

    (This issue was rainsed at the specification's pre-adoption AB review).

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:22 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    Correction to IEFRA-42

    Deferred to RTF - the documents have been submitted - and a stable version is required for NAT0 evaluation and Testing in June

    Requires minor correction for typographical errors

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Bullet context

  • Key: IEFRA_-36
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    In section 1.6 ("IEF Objectives"), please ensure that each bullet reads correctly in the context of the introductory clause (which is currently "This will require solutions that:", but will need changing in response to comment 2 above).

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:15 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    Correction to IEFRA-36 Proposal

    Deferred to RTF - the documents have been submitted - and a stable version is required for NAT0 evaluation and Testing in June

    Requires minor correction for typographical errors

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Recommended word change

  • Key: IEFRA_-92
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    IEFRA-26
    Initial 10.1 sentence still needs update
    Change
    “The following figure identifies the Policy Enforcement Point (PEP) feature that form part of each of the four type of PEP:”
    to
    “The following figure identifies the Policy Enforcement Point (PEP) features that constitute part of each of the four types of PEP:”

  • Reported: IEF-RA 1.0b1 — Sat, 29 Dec 2018 03:09 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-92

    Initial 10.1 sentence still needs update
    Change
    “The following figure identifies the Policy Enforcement Point (PEP) feature that form part of each of the four type of PEP:”
    to
    “The following figure identifies the Policy Enforcement Point (PEP) features that constitute part of each of the four types of PEP:”

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Type

  • Key: IEFRA_-91
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    IEFRA-23
    In 1.7.2 typo still exists “secuence diagrams”

  • Reported: IEF-RA 1.0b1 — Sat, 29 Dec 2018 03:07 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction IEFRA-91

    In 1.7.2 typo still exists “secuence diagrams”

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Change in wording

  • Key: IEFRA_-89
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    For “Data Centric Defense-in-Depth” change to “that directly apply”
    For Self-Defending Change “safeguard its own data” to “safeguard their own data”

    Make this list in the spec alphabetical or state it is in priority order.

  • Reported: IEF-RA 1.0b1 — Sat, 29 Dec 2018 03:01 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-89

    For “Data Centric Defense-in-Depth” change to “that directly apply”
    For Self-Defending Change “safeguard its own data” to “safeguard their own data”

    Make this list in the spec alphabetical or state it is in priority order.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Issue in XSD

  • Key: IEFRA_-88
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    IEFRA-15

    The XSD does not match the diagram 38 in the specification or Table 27

    ISSG-Request.xsd has elements named “Request-CryptographicKeys” and “Request-TrustMarks” but specification has “Request-CryptographicKey” and “Request-TrustMark”

  • Reported: IEF-RA 1.0b1 — Sat, 29 Dec 2018 02:55 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction to IEFRA-88

    The XSD does not match the diagram 38 in the specification or Table 27. ISSG-Request.xsd has elements named “Request-CryptographicKeys” and “Request-TrustMarks” but specification has “Request-CryptographicKey” and “Request-TrustMark”

    Make the terms singular in the XSD.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Assorted Typos

  • Key: IEFRA_-87
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    Further corrections are needed.

    The issue requested running a spell checker. Really. Why was this request ignored? (I acknowledge there are false positives but also lots of real errors), also why not use auto-correct for spelling in Word?

    1.2 “Refernce” 3x

    1.3 “Undergroung subway”

    1.4 “Crytographic”

    1.6 “provide Pprovide”

    1.7.1 “injest”

    1.7.2 “secuence”, “multiple informationpackages”

    3.2 Howard not Howad for “The Security Development Lifecycle”, 4

    Campbell not Cambell for “Building a Global Information Assurance Program”, 5

    Section 6.2 “DRDC CSS contributed the Specificsation”

    6.5 “focusses”

    6.7 “ennumerations”

    7.2 “interopeable”

    9.1 “labelled" , “iswill also be formatted”

    Table 9: “THe PEP”

    Table 10: “approriately", “detemines", “adudicating", “recipinet", “approriate"

    10.3.1 “logic.The” (add space)

    Table 11 “PDP-Reponse”

    “secure_file-share” – underscore or space?

    Table 11 “system.A” (add space)

    10.4.1 “chatroom” (two words), “paricipation"

    Table 12 “ditributiuon”, “tcryptographic”,

    10.5 “Appication”, “the the”

    Table 19 heading “Attributes Attributes”

    16.3 “identifiy”
    16.4.1 “suite” should be “suit”

    Table 28 “Registy”

    Annex A “the the” (Message Metadata), “Cintainer” (Secure Asset Container), “tha provisions”

    Annex B “the the” (PPS Policies), “SemanticxModel”

    Table 40 “aa specified”, “sentitivity”

    Annex D: “efficientcies”

    P 262 “riecpient”, “devive”, “the the”

    Table 53, “Sservices”

    Glossary “formating" (Packages)

  • Reported: IEF-RA 1.0b1 — Sat, 29 Dec 2018 02:51 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-87

    1.2 “Refernce” 3x

    1.3 “Undergroung subway”

    1.4 “Crytographic”

    1.6 “provide Pprovide”

    1.7.1 “injest”

    1.7.2 “secuence”, “multiple informationpackages”

    3.2 Howard not Howad for “The Security Development Lifecycle”, 4

    Campbell not Cambell for “Building a Global Information Assurance Program”, 5

    Section 6.2 “DRDC CSS contributed the Specificsation”

    6.5 “focusses”

    6.7 “ennumerations”

    7.2 “interopeable”

    9.1 “labelled" , “iswill also be formatted”

    Table 9: “THe PEP”

    Table 10: “approriately", “detemines", “adudicating", “recipinet", “approriate"

    10.3.1 “logic.The” (add space)

    Table 11 “PDP-Reponse”

    “secure_file-share” – underscore or space?

    Table 11 “system.A” (add space)

    10.4.1 “chatroom” (two words), “paricipation"

    Table 12 “ditributiuon”, “tcryptographic”,

    10.5 “Appication”, “the the”

    Table 19 heading “Attributes Attributes”

    16.3 “identifiy”
    16.4.1 “suite” should be “suit”

    Table 28 “Registy”

    Annex A “the the” (Message Metadata), “Cintainer” (Secure Asset Container), “tha provisions”

    Annex B “the the” (PPS Policies), “SemanticxModel”

    Table 40 “aa specified”, “sentitivity”

    Annex D: “efficientcies”

    P 262 “riecpient”, “devive”, “the the”

    Table 53, “Sservices”

    Glossary “formating" (Packages)

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Issue with

  • Key: IEFRA_-86
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    IEFRA-6
    Figure 31 is now Figure 32, etc. Perhaps clarify in issue resolution.

    Update FTF Report, Figure 39 and Figure 40 replace ISMB with ISSG for figure captions (in report)

  • Reported: IEF-RA 1.0b1 — Sat, 29 Dec 2018 02:47 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-86

    Figure 31 is now Figure 32, etc. Perhaps clarify in issue resolution.

    Update FTF Report, Figure 39 and Figure 40 replace ISMB with ISSG for figure captions (in report)

    Fuzziness of Figures was address throughout the diagram. All the PNG diagrams were replaced with SVG versions post Clause 2. The Clause 2 diagrams generated were PowerPoint generated and not replaced

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Issues in Glossary

  • Key: IEFRA_-85
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    I’m not sure removing problematical URLs is always the best response to the request for correct URLs – where possible good URLs can be provided. In a number of cases sources are no longer credited. In general a good glossary should include sources (e.g. ISO document numbers) so it is clear which are generally accepted (and international) definitions and which are not. However this can be a big job so I understand the approach here. Perhaps this is a more general OMG question.

    I think you should add a reference for MILS, for example to this paper, “MILS Architecture”, 2014, EURO-MILS white paper
    http://euromils.eu/downloads/2014-EURO-MILS-MILS-Architecture-white-paper.pdf

    Information Payload was deleted entirely from the glossary – did you intend that?

    It seems that the numbering is problematical in the FTF report and not the document, XML Schema Part 2 should be #12 in the report. Please fix this in the report and remove “Note: MSword auto numbering is messed up in the marked up document.”

    In FTF report, for some reason strikethrough appears in the URL shown in the PDF and should be removed (but not when copied and pasted here, bizarre):
    "http://www.computerworld.com/article/2485175/security0/snowden-s-role-provided-perfect-coverfor-nsa-data-theft.html"

    All references after #4 in section 3.3 seem to be missing. For example I cannot find the NIEM reference noted in this issue. Is there a problem with section 3.3?

  • Reported: IEF-RA 1.0b1 — Sat, 29 Dec 2018 02:42 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction to IEFRA-85

    I’m not sure removing problematical URLs is always the best response to the request for correct URLs – where possible good URLs can be provided. In a number of cases sources are no longer credited. In general a good glossary should include sources (e.g. ISO document numbers) so it is clear which are generally accepted (and international) definitions and which are not. However this can be a big job so I understand the approach here. Perhaps this is a more general OMG question.

    (Comment) Most of the definitions come from the IEPPV v1.0. I spent a lot of time seeking replacement URLs with no luck. At some point one must concede the Internet and URLS are not stable. In additions what at one time are open site and now can only be accessed at a cost, or secured by the organization. The Canadian Government (SAMSON Documents archived but still available) is revamping their web sites and archiving much of the old information. News sites are temporary at best - a losing battling.

    I think you should add a reference for MILS, for example to this paper, “MILS Architecture”, 2014, EURO-MILS white paper
    http://euromils.eu/downloads/2014-EURO-MILS-MILS-Architecture-white-paper.pdf

    (Comment) I have no issue with that. Will be added.

    Information Payload was deleted entirely from the glossary – did you intend that?

    (Comment) Accidentally moved out of alphabetical order and corrected

    It seems that the numbering is problematical in the FTF report and not the document, XML Schema Part 2 should be #12 in the report. Please fix this in the report and remove “Note: MSword auto numbering is messed up in the marked up document.”

    (Comment) The FTF report is auto-generated by the JIRA application. MSword maked a mess of "TrackChange" document in numbering and formatting.

    In FTF report, for some reason strikethrough appears in the URL shown in the PDF and should be removed (but not when copied and pasted here, bizarre):
    "http://www.computerworld.com/article/2485175/security0/snowden-s-role-provided-perfect-coverfor-nsa-data-theft.html"

    (Comment) The FTF report is auto-generated by the JIRA application.

    All references after #4 in section 3.3 seem to be missing. For example I cannot find the NIEM reference noted in this issue. Is there a problem with section 3.3?

    (comment) they are direct references to books, Forgot to add the ISBN - will add to document. will be added

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Correct Document Numbers in Annex A and B

  • Key: IEFRA_-84
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    OMG Issue: IEFRA-1
    Unfortunately a further correction is needed (probably because of Word). The fragments are case sensitive so “Ptc” needs to be replaced with “ptc” for both Annex A and B, e.g. both “Ptc/2018-05-21“ and “Ptc/2018-05-22” need to be fixed.

    Also please note that the FTF report says to use mars/2017-05-03 and use mars/2017-05-04 in the summary section – this should be fixed in the report to avoid confusion.

  • Reported: IEF-RA 1.0b1 — Sat, 29 Dec 2018 02:40 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Resolution to IEFRA-84

    Issue generated from FTF 1 Report Comments.

    Unfortunately a further correction is needed (probably because of Word). The fragments are case sensitive so “Ptc” needs to be replaced with “ptc” for both Annex A and B, e.g. both “Ptc/2018-05-21“ and “Ptc/2018-05-22” need to be fixed.

    Also please note that the FTF report says to use mars/2017-05-03 and use mars/2017-05-04 in the summary section – this should be fixed in the report to avoid confusion.

    This was a MSword auto correct missed in the final review.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Errors in TOC

  • Key: IEFRA_-83
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    The final revised submission contains instances of “Error! Reference source not found” that should be fixed.

  • Reported: IEF-RA 1.0b1 — Sat, 29 Dec 2018 01:58 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction to IEFRA-83

    Errors in TOC

  • Updated: Tue, 8 Oct 2019 17:56 GMT

IPR / Licensing Wording in Document

  • Key: IEFRA_-82
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    The FTF report states that the IPR mode will be Non-Assert, however the license boilerplate in the specification talks about Royalty Free license terms. The specification should be updated to explicitly refer to a Non-Assert covenant.

  • Reported: IEF-RA 1.0b1 — Fri, 28 Dec 2018 23:01 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction to IEFRA-82

    The FTF report states that the IPR mode will be Non-Assert, however the license boilerplate in the specification talks about Royalty Free license terms. The specification should be updated to explicitly refer to a Non-Assert covenant.

    Add the non-assert covenant clauses

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Ammend to IEFRA-41 Proposal

  • Key: IEFRA_-154
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    Things got a little mangled:
    The MagicDraw and Model in XMI are provided to support creation offuture revisions of the specification. and are thus auxiliary based on the definitions provided. All the requisite information from the model is in the specification, and does not require access t the original model.
    Change: "offuture" to "of future".
    Change "access t the original model" to "access to the original model"

  • Reported: IEF-RA 1.0b1 — Wed, 6 Mar 2019 16:03 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    IEFRA-41 Proposal issue resolution

    Typo in the resolution to the test in the Proposal.

    Things got a little mangled:
    The MagicDraw and Model in XMI are provided to support creation offuture revisions of the specification. and are thus auxiliary based on the definitions provided. All the requisite information from the model is in the specification, and does not require access t the original model.
    Change: "offuture" to "of future".
    Change "access t the original model" to "access to the original model"

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Meaning of parenthetical "suite or virtual machine" not clear

  • Key: IEFRA_-5
  • Status: closed  
  • Source: Upham Security ( Frederick Hirsch)
  • Summary:

    The Meaning of parenthetical "suite or virtual machine" not clear - add text to clarify for reader.

    (first sentence of section)

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:37 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-5

    Note: IEFRA-3 in FTF 1 was renumbered as IEFRA-5 in FTF 2. The response and revisions remain the same. No issues to these changes were raised by the AB.

    The use of "(suite or virtual machine)" in the paragraph is mot needed - propose the following wording change"

    "services (suite or virtual machine)" ---> "software services"

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Fix Broken URL links in glossary


Typographic error

  • Key: IEFRA_-37
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    In the introduction to Annex B, "confimin" should presumably be "conforming".

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:33 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-37

    Note: IEFRA-30 from FTF 1 in now IEFRA-37 in FTF 2.

    Changed "confimin" to "conforming"

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Typo

  • Key: IEFRA_-40
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    In the introduction to Annex A "representital" should presumably be "representative"?

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:31 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-40

    Note: IEFRA-28 in FTF 1 was renumbered as IEFRA-40 in FTF 2.

    In the introduction to Annex A "representital" should presumably be "representative"?

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Agreement

  • Key: IEFRA_-43
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    In section 10.1 ("PEP Component Operations"), this sentence has 2 agreement problems: "The following figure identifies the Policy Enforcement Point (PEP) feature that form part of each of the four type of PEP".

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:28 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-43

    Note: IEFRA-26 in FTF 1 was renumbered as IEFRA-43 in FTF 2.

    In section 10.1 ("PEP Component Operations"), this sentence has 2 agreement problems: "The following figure identifies the Policy Enforcement Point (PEP) feature that form part of each of the four type of PEP".

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Agreement

  • Key: IEFRA_-39
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    In section 1.7.2 "Process multiple files in a single instructions;" needs correcting for agreement.

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:25 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    correction for IEFRA-39

    Note: IEFRA-23 in FTF 1 was renumbered as IEFRA-39 in FTF 2.

    "Process multiple files in a single instruction " needs explanation.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Section 1.2 clause list inaccurate

  • Key: IEFRA_-35
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    Section 1.2 ("Organization of this Specification") lists the clauses wrongly - for instance, Clause 8 is listed as "Policy Decision Point (PDP)", but is actually "Policy Administration Point (PAP)".

    (This issue was raised at the pre-adoption AB review).

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:23 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-35

    Note IEFRA-22 in FTF 1 now IEF-RA -35 in FTF 2.

    mis-Numbered clauses in section 1.2 - organization of the reference architecture.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Dates and places

  • Key: IEFRA_-45
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    In section 1.3 ("Motivation"), "the 2007 London subway bombing" should be "the 2005 London Underground bombing" (get the date right, use local terminology).

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:16 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    correction for IEFRA-20

    Note: IEFRA-20 in FTF 1 was renumbered as IEFRA-45 in FTF 2.

    Incorrect date and terminology

    Replace "2007 London Subway" with "2005 London Underground"

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Non-sentence

  • Key: IEFRA_-38
  • Status: closed  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    In section 1.6 ("IEF Objectives"), the sentence beginning "Provide strategies, techniques and tools that enable users to translate .." isn't actually a sentence.

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:14 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-38

    ote: IEFRA-18 in FTF 1 was renumbered as IEFRA-38 in FTF 2.

    In section 1.6 ("IEF Objectives"), the sentence beginning "Provide strategies, techniques and tools that enable users to translate .." isn't actually a sentence.

    Redundant / repetitive text - covered in other sections of the document - delete text.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Policy or policies?

  • Key: IEFRA_-71
  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    The first 3 bullets in 1.5 alternate between the singular (policy) and the plural (policies) and it is not clear that they are all correct. In particular, "Activate ISS policy" is not grammatical – it can be "Activate an ISS policy" or "Activate ISS policies" but not what's written.

  • Reported: IEF-RA 1.0b1 — Tue, 7 Aug 2018 05:59 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Resolution to issue 71

    FTF 2 submitted issue

    The first 3 bullets in 1.5 alternate between the singular (policy) and the plural (policies) and it is not clear that they are all correct. In particular, "Activate ISS policy" is not grammatical – it can be "Activate an ISS policy" or "Activate ISS policies" but not what's written.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Pagination

  • Key: IEFRA_-70
  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    As can be seen in the TOC, page numbers restart at 1 when getting to the Scope. As a result, the pages in the footers do not match the pages in the file.

  • Reported: IEF-RA 1.0b1 — Tue, 7 Aug 2018 05:53 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Resolution to issue 70

    As can be seen in the TOC, page numbers restart at 1 when getting to the Scope. As a result, the pages in the footers do not match the pages in the file.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Inconsistent punctuation, esp. commas and semicolons

  • Key: IEFRA_-69
  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    There are a number of stylistically incorrect uses of commas and semicolons, and this should be reviewed throughout the document. The first clear issue is in 1.3, in the paragraph that straddles the bottom of page 3 and the top of page 4 (pages 19 and 20 of the PDF file):

    • the semicolon after "share" is incorrect
    • the comma after "as well as" is incorrect
    • the semicolon after "principles" is incorrect
    • the semicolon after "separated" seems incorrect
  • Reported: IEF-RA 1.0b1 — Tue, 7 Aug 2018 05:44 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Resolution of IEFRA-69

    FTF 2 submitted issue

    There are a number of stylistically incorrect uses of commas and semicolons, and this should be reviewed throughout the document. The first clear issue is in 1.3, in the paragraph that straddles the bottom of page 3 and the top of page 4 (pages 19 and 20 of the PDF file):

    the semicolon after "share" is incorrect
    the comma after "as well as" is incorrect
    the semicolon after "principles" is incorrect
    the semicolon after "separated" seems incorrect

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Make bullets points consistent

  • Key: IEFRA_-68
  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    In 1.2, Clause 10, all bullet points start with "The", except the last one (IM-PEP). They should all be the same.
    Capitalizing "The" looks strange. It may therefore be best to remove "The" from the first bullets instead of adding it to the last one.

  • Reported: IEF-RA 1.0b1 — Tue, 7 Aug 2018 05:33 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Resolution of IEFRA-68

    FTF submitted issue

    In 1.2, Clause 10, all bullet points start with "The", except the last one (IM-PEP). They should all be the same.
    Capitalizing "The" looks strange. It may therefore be best to remove "The" from the first bullets instead of adding it to the last one.

    Accept requested changes

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Table of Contents title

  • Key: IEFRA_-67
  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    The "Table of Contents" is incorrectly entitled "Table Contents" (page 5).

  • Reported: IEF-RA 1.0b1 — Tue, 7 Aug 2018 05:27 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Resolution of IEFRA-67

    FTF 2 submitted issue

    The "Table of Contents" is incorrectly entitled "Table Contents" (page 5).

    Corrected to Table of Contents

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Verb form

  • Key: IEFRA_-66
  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    In 1.7.3, "This level of detail should be covering in the PEP specification" should probably be "...covered..." instead of "covering".

  • Reported: IEF-RA 1.0b1 — Tue, 7 Aug 2018 05:24 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Resolution of IEFRA-66

    FTF 2 submitted issue

    In 1.7.3, "This level of detail should be covering in the PEP specification" should probably be "...covered..." instead of "covering".

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Verb form

  • Key: IEFRA_-65
  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    "The reference architecture does not specifiy the support user file formats" should probably say "supported" rather than "support".

  • Reported: IEF-RA 1.0b1 — Tue, 7 Aug 2018 05:20 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Resolution of IEFRA-65

    FTF 2 generated issue.

    "The reference architecture does not specifiy the support user file formats" should probably say "supported" rather than "support".

  • Updated: Tue, 8 Oct 2019 17:56 GMT

informative ancillary files in FTF Report confusion

  • Key: IEFRA_-81
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    I’m not sure the packaging of the informative ancillary files makes sense. The ptc-18-05-26 zip contains both IEFRA-17 and IEFRA-16. It isn’t obvious why the figures are bundled with the restructured section. A README in the zip would be very helpful.

  • Reported: IEF-RA 1.0b1 — Fri, 28 Dec 2018 22:54 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Response to IEF-RA81

    FTF 1 - comment to the FTF report. I’m not sure the packaging of the informative ancillary files makes sense. The ptc-18-05-26 zip contains both IEFRA-17 and IEFRA-16. It isn’t obvious why the figures are bundled with the restructured section. A README in the zip would be very helpful.

    When originally written the version of Word used would not integrate SVG files suggested to improve the quality of the document diagrams. We decised to add the auxiliary document (zip file) to provide the SVG versions of the document to integrate in the OMG release. The latest version of word integrates SVG - so the diagrams were integrated into the FTF 2 document, and the need for the auxiliary docuument that will now be eliminated.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

IPR Mode in Licenses Clause

  • Key: IEFRA_-80
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    Issue raised by AB

    The FTF report states that the IPR mode will be Non-Assert, however the license boilerplate in the specification talks about Royalty Free license terms. The specification should be updated to explicitly refer to a Non-Assert covenant.

  • Reported: IEF-RA 1.0b1 — Thu, 27 Dec 2018 18:04 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction to IEFRA-80

    Correction to to an issue raised in the FTF 1 Report.

    The FTF 2 report will identify that the IPR mode is "non-assert" - this is agreed by all contributors.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Non-URL issues in IEFRA-3

  • Key: IEFRA_-172
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    I think you should add a reference for MILS, for example to this paper, “MILS Architecture”, 2014, EURO-MILS white paper
    http://euromils.eu/downloads/2014-EURO-MILS-MILS-Architecture-white-paper.pdf

    Information Payload was deleted entirely from the glossary – did you intend that?

    It seems that the numbering is problematical in the FTF report and not the document, XML Schema Part 2 should be #12 in the report. Please fix this in the report and remove “Note: MSword auto numbering is messed up in the marked up document.”

    In FTF report, for some reason strikethrough appears in the URL shown in the PDF and should be removed (but not when copied and pasted here, bizarre):
    "http://www.computerworld.com/article/2485175/security0/snowden-s-role-provided-perfect-coverfor-nsa-data-theft.html"

    All references after #4 in section 3.3 seem to be missing. For example I cannot find the NIEM reference noted in this issue. Is there a problem with section 3.3?

  • Reported: IEF-RA 1.0b1 — Fri, 8 Mar 2019 04:05 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-72

    I think you should add a reference for MILS, for example to this paper, “MILS Architecture”, 2014, EURO-MILS white paper
    http://euromils.eu/downloads/2014-EURO-MILS-MILS-Architecture-white-paper.pdf

    Information Payload was deleted entirely from the glossary – did you intend that?

    It seems that the numbering is problematical in the FTF report and not the document, XML Schema Part 2 should be #12 in the report. Please fix this in the report and remove “Note: MSword auto numbering is messed up in the marked up document.”

    In FTF report, for some reason strikethrough appears in the URL shown in the PDF and should be removed (but not when copied and pasted here, bizarre):
    "http://www.computerworld.com/article/2485175/security0/snowden-s-role-provided-perfect-coverfor-nsa-data-theft.html"

    All references after #4 in section 3.3 seem to be missing. For example I cannot find the NIEM reference noted in this issue. Is there a problem with section 3.3?

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Amend IEFRA-41 Proposal

  • Key: IEFRA_-167
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    Things got a little mangled:
    The MagicDraw and Model in XMI are provided to support creation offuture revisions of the specification. and are thus auxiliary based on the definitions provided. All the requisite information from the model is in the specification, and does not require access t the original model.
    Change: "offuture" to "of future".
    Change "access t the original model" to "access to the original model"

  • Reported: IEF-RA 1.0b1 — Fri, 8 Mar 2019 01:59 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    *correction to IEFRA-167 *

    Things got a little mangled:
    The MagicDraw and Model in XMI are provided to support creation offuture revisions of the specification. and are thus auxiliary based on the definitions provided. All the requisite information from the model is in the specification, and does not require access t the original model.

    Change: "offuture" to "of future".

    Change "access t the original model" to "access to the original model"

    These issues no longer apply to the final resolution.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Amend IEFRA-42 Proposal

  • Key: IEFRA_-166
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    In Clause 6.1, Para 1, Page 24, Replace “Specification” with “reference architecture”; Replace “who will use this profile to” with “seeking to”; replace “tools” with “products and services”; replace “support for the”; replace “interoperability” with “sharing and safeguarding”; replace “will have” with who seek”
    What is "support for the" being replaced with?? Doesn't say.

    In Clause 9, para 1, page 71, Replace “will be defined to the”
    What is "will be defined to the" being replaced with? Doesn't say

  • Reported: IEF-RA 1.0b1 — Fri, 8 Mar 2019 01:56 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-166

    1 - In Clause 6.1, Para 1, Page 24, Replace “Specification” with “reference architecture”; Replace “who will use this profile to” with “seeking to”; replace “tools” with “products and services”; replace “support for the”; replace “interoperability” with “sharing and safeguarding”; replace “will have” with who seek”
    What is "support for the" being replaced with?? Doesn't say.

    In Clause 9, para 1, page 71, Replace “will be defined to the”
    What is "will be defined to the" being replaced with? Doesn't say

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Amend IEFRA-3 proposal

  • Key: IEFRA_-165
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    as I (Char) said in the comments on this issue – rather than declaring this whole issue "unresolved" because Mike wasn't able to fix all the links – better to separate it into two issues – one which covers the links that Mike did resolve and then shift all the ones that still need to be resolved into their own issue. No reason to treat this as an all or nothing deal.

  • Reported: IEF-RA 1.0b1 — Fri, 8 Mar 2019 01:49 GMT
  • Disposition: Deferred — IEF-RA 1.0
  • Disposition Summary:

    Defer the Glossary URL issues to RTF

    as I (Char) said in the comments on this issue – rather than declaring this whole issue "unresolved" because Mike wasn't able to fix all the links – better to separate it into two issues – one which covers the links that Mike did resolve and then shift all the ones that still need to be resolved into their own issue. No reason to treat this as an all or nothing deal.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Amend IEFRA-31 issues

  • Key: IEFRA_-162
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    #31
    Have gone thru the proposed revised section and recommend the following:
    Within Sxn 2.3 - "Figure 2 outlines a generalized architecture including call four information sharing types, including the two forms of Structured messaging integration."

    "call four" should be "all four"

    Within Sxn 2.4 -
    "Figure 3 illustrates the integration patterns IEF elements utilizing the IEF as a set of proxy information sharing and safeguarding services where the client application and a corresponding server are provided on the users’ own network and security domain."
    Should be:
    Figure 3 illustrates the integration patterns whereby IEF elements utilize IEF as a set of proxy information sharing and safeguarding services and client application and a corresponding server are provided on the users’ own network and security domain.

    Also "This often means that the User Client application must include or integrated with..."

    Insert a "be" before "integrated"

    In Sxn 2.6.1, am thinking that in "selective sharing of structured data, as messages," – ", as messages," could be either ", treated as messages," or ", i.e., messages," given that I believe this is the intent. The other way to apporach this is ", packaged as messages," – which would be consistent with the usage in the next paragraph.

    Sxn 2.6.2
    "File information sharing and safeguarding compliance requires a PEP is tailored..." add a "that" in front of "is tailored"
    also – "authorized to request the operation" – should be "an operation"

    Sxn 2.6.3 and 2.6.4
    same as 2.6.2 – replace "is tailored" with "that is tailored"

  • Reported: IEF-RA 1.0b1 — Fri, 8 Mar 2019 01:25 GMT
  • Disposition: Duplicate or Merged — IEF-RA 1.0
  • Disposition Summary:

    *Duplicate of *

    Accidentally added this issue twice

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Ammend IEFRA-36 Proposal

  • Key: IEFRA_-161
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    What does this mean? What change is it that's being made?
    Clause 1.6, Para 1, Page 7, Reuse of Existing Standards and Specifications, Replace “The Platform Specific Models will represent the assignment of specific standards and specifications to the components (e.g., DDS for data dissemination) and interfaces (e.g., XAMCL for exchange of policies).” With “(e.g., DDS and XACML)”.
    You're not replacing the whole sentence with "e.g., DDS and XACML)" Are you? That makes no sense.
    Think it would make more sense to say:
    "The Platform Specific Models will represent the assignment of specific standards and specifications to the components and interfaces (e.g., DDS for data dissemination and XACML for exchange of policies, respectively)."

    In the list of corrections, there appears to be one place where "Defense-in-Depth" is being replaced with the UK/CA spelling "Defence", and another place where it is "Defense".

    In a later correction, it says "in a manner that provide them" – it should be "in a manner that provides them".

  • Reported: IEF-RA 1.0b1 — Fri, 8 Mar 2019 01:22 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA 161

    1 - What does this mean? What change is it that's being made?
    Clause 1.6, Para 1, Page 7, Reuse of Existing Standards and Specifications, Replace “The Platform Specific Models will represent the assignment of specific standards and specifications to the components (e.g., DDS for data dissemination) and interfaces (e.g., XAMCL for exchange of policies).” With “(e.g., DDS and XACML)”.
    You're not replacing the whole sentence with "e.g., DDS and XACML)" Are you? That makes no sense.
    Think it would make more sense to say:
    "The Platform Specific Models will represent the assignment of specific standards and specifications to the components and interfaces (e.g., DDS for data dissemination and XACML for exchange of policies, respectively)."

    Claude
    2- In the list of corrections, there appears to be one place where "Defense-in-Depth" is being replaced with the UK/CA spelling "Defence", and another place where it is "Defense".

    3 - In a later correction, it says "in a manner that provide them" – it should be "in a manner that provides them".

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Amend IEFRA-71 Proposal

  • Key: IEFRA_-150
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    Should be: "Activate/deactivate ISS policies that respond to changes in operational requirements; ("responds" should be "respond", "change" should be "changes")"

  • Reported: IEF-RA 1.0b1 — Wed, 6 Mar 2019 14:52 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    correction to IEFRA-71 resolution

    Should be: "Activate/deactivate ISS policies that respond to changes in operational requirements; ("responds" should be "respond", "change" should be "changes")"

    accept recommented change

    "responds" should be "respond", "change" should be "changes" in Bullet 3.

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Ammend IEFRA-31 proposal

  • Key: IEFRA_-148
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    Have gone thru the proposed revised section and recommend the following:
    Within Sxn 2.3 - "Figure 2 outlines a generalized architecture including call four information sharing types, including the two forms of Structured messaging integration."

    "call four" should be "all four"

    Within Sxn 2.4 -
    "Figure 3 illustrates the integration patterns IEF elements utilizing the IEF as a set of proxy information sharing and safeguarding services where the client application and a corresponding server are provided on the users’ own network and security domain."
    Should be:
    Figure 3 illustrates the integration patterns whereby IEF elements utilize IEF as a set of proxy information sharing and safeguarding services and client application and a corresponding server are provided on the users’ own network and security domain.

    Also "This often means that the User Client application must include or integrated with..."

    Insert a "be" before "integrated"

    In Sxn 2.6.1, am thinking that in "selective sharing of structured data, as messages," – ", as messages," could be either ", treated as messages," or ", i.e., messages," given that I believe this is the intent. The other way to apporach this is ", packaged as messages," – which would be consistent with the usage in the next paragraph.

    Sxn 2.6.2
    "File information sharing and safeguarding compliance requires a PEP is tailored..." add a "that" in front of "is tailored"
    also – "authorized to request the operation" – should be "an operation"

    Sxn 2.6.3 and 2.6.4
    same as 2.6.2 – replace "is tailored" with "that is tailored"

  • Reported: IEF-RA 1.0b1 — Wed, 6 Mar 2019 02:36 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction for IEFRA-148

    Have gone thru the proposed revised section and recommend the following:
    Within Sxn 2.3 - "Figure 2 outlines a generalized architecture including call four information sharing types, including the two forms of Structured messaging integration."

    "call four" should be "all four"
    (Comment) - accepted

    Within Sxn 2.4 -
    "Figure 3 illustrates the integration patterns IEF elements utilizing the IEF as a set of proxy information sharing and safeguarding services where the client application and a corresponding server are provided on the users’ own network and security domain."
    Should be:
    Figure 3 illustrates the integration patterns whereby IEF elements utilize IEF as a set of proxy information sharing and safeguarding services and client application and a corresponding server are provided on the users’ own network and security domain.

    Also "This often means that the User Client application must include or integrated with..."

    Insert a "be" before "integrated"

    In Sxn 2.6.1, am thinking that in "selective sharing of structured data, as messages," – ", as messages," could be either ", treated as messages," or ", i.e., messages," given that I believe this is the intent. The other way to approach this is ", packaged as messages," – which would be consistent with the usage in the next paragraph.

    Sxn 2.6.2
    "File information sharing and safeguarding compliance requires a PEP is tailored..." add a "that" in front of "is tailored"
    also – "authorized to request the operation" – should be "an operation"

    Sxn 2.6.3 and 2.6.4
    same as 2.6.2 – replace "is tailored" with "that is tailored"

  • Updated: Tue, 8 Oct 2019 17:56 GMT

Ammend IEFRA-5 Proposal

  • Key: IEFRA_-146
  • Status: closed  
  • Source: Advanced Systems Management Group Ltd. ( Mr. Michael Abramson)
  • Summary:

    Amendment to FTF 2 solution to IEFRA-5

    Remove the comma between "that communicate" and "using". Not needed. Minor tweak I know but less jarring on the reader who's left wondering why anyone would add a comma like that. Example "I weed the garden using a hoe".

  • Reported: IEF-RA 1.0b1 — Wed, 6 Mar 2019 02:23 GMT
  • Disposition: Resolved — IEF-RA 1.0
  • Disposition Summary:

    Correction to IEFRA-5 Amendment

    Amendment to FTF 2 solution to IEFRA-5

    Remove the comma between "that communicate" and "using". Not needed. Minor tweak I know but less jarring on the reader who's left wondering why anyone would add a comma like that. Example "I weed the garden using a hoe".

    Remove ","

  • Updated: Tue, 8 Oct 2019 17:56 GMT