1. OMG Mailing List
  2. IEF Reference Architecture 1.0 FTF

Open Issues

  • Issues not resolved
  • Name: ief-ftf
  • Issues Count: 67

Issues Summary

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

Issues Descriptions

Amend IEFRA-42 Proposal

  • Key: IEFRA_-166
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Amend IEFRA-31 issues

  • Key: IEFRA_-162
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Amend IEFRA-3 proposal

  • Key: IEFRA_-165
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Ammend IEFRA-36 Proposal

  • Key: IEFRA_-161
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Ammend IEFRA-5 Proposal

  • Key: IEFRA_-146
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Amend IEFRA-71 Proposal

  • Key: IEFRA_-150
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Ammend IEFRA-31 proposal

  • Key: IEFRA_-148
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Non-URL issues in IEFRA-3

  • Key: IEFRA_-172
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

informative ancillary files in FTF Report confusion

  • Key: IEFRA_-81
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Amend IEFRA-41 Proposal

  • Key: IEFRA_-167
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

IPR Mode in Licenses Clause

  • Key: IEFRA_-80
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Type

  • Key: IEFRA_-91
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

IPR / Licensing Wording in Document

  • Key: IEFRA_-82
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Correct Document Numbers in Annex A and B

  • Key: IEFRA_-84
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Recommended word change

  • Key: IEFRA_-92
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Errors in TOC

  • Key: IEFRA_-83
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Ammend to IEFRA-41 Proposal

  • Key: IEFRA_-154
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Make bullets points consistent

  • Key: IEFRA_-68
  • Status: open  
  • Source: cebe IT & KM ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Verb form

  • Key: IEFRA_-65
  • Status: open  
  • Source: cebe IT & KM ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Verb form

  • Key: IEFRA_-66
  • Status: open  
  • Source: cebe IT & KM ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Table of Contents title

  • Key: IEFRA_-67
  • Status: open  
  • Source: cebe IT & KM ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Issues in Glossary

  • Key: IEFRA_-85
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Assorted Typos

  • Key: IEFRA_-87
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Issue in XSD

  • Key: IEFRA_-88
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Issue with

  • Key: IEFRA_-86
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Change in wording

  • Key: IEFRA_-89
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Inconsistent punctuation, esp. commas and semicolons

  • Key: IEFRA_-69
  • Status: open  
  • Source: cebe IT & KM ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Policy or policies?

  • Key: IEFRA_-71
  • Status: open  
  • Source: cebe IT & KM ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Section 1.2 clause list inaccurate

  • Key: IEFRA_-35
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Pagination

  • Key: IEFRA_-70
  • Status: open  
  • Source: cebe IT & KM ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Non-sentence

  • Key: IEFRA_-38
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Agreement

  • Key: IEFRA_-43
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Agreement

  • Key: IEFRA_-39
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Dates and places

  • Key: IEFRA_-45
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Typo

  • Key: IEFRA_-40
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Typographic error

  • Key: IEFRA_-37
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Fix Broken URL links in glossary


Meaning of parenthetical "suite or virtual machine" not clear

  • Key: IEFRA_-5
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Correct OMG document URLs

  • Key: IEFRA_-1
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Fix typos in Figures 5 and 10

  • Key: IEFRA_-9
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Figure text is blurred and not clear

  • Key: IEFRA_-7
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Random "*"

  • Key: IEFRA_-13
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Standard Fuzzy Bitmap Diagram Gripe

  • Key: IEFRA_-46
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT
  • Attachments:

Use standard OMG document number formats

  • Key: IEFRA_-44
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

i.e./e.g.

  • Key: IEFRA_-47
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Amend IEFRA-24 Proposal

  • Key: IEFRA_-149
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Inventory problems

  • Key: IEFRA_-41
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

change in wording 2

  • Key: IEFRA_-90
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Use definitional language

  • Key: IEFRA_-42
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Bullet context

  • Key: IEFRA_-36
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Amend IEFRA-43 Proposal

  • Key: IEFRA_-168
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Security considerations section

  • Key: IEFRA_-93
  • Status: open  
  • Source: Advanced Systems Management Group Ltd. ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Fix spelling errors.

  • Key: IEFRA_-15
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Add (new) security considerations section

  • Key: IEFRA_-17
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Typos in attribute names, mismatches with XSD

  • Key: IEFRA_-11
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Amend IEFRA-166 (Amend IEFRA-42)

  • Key: IEFRA_-179
  • Status: open  
  • Source: MITRE ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Amend IEFRA 149 (Amend IEFRA-24)

  • Key: IEFRA_-178
  • Status: open  
  • Source: MITRE ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

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

  • Key: IEFRA_-19
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Clarify permissions required for file access within folders

  • Key: IEFRA_-26
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

typo for TrustmarkData

  • Key: IEFRA_-23
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Agreement

  • Key: IEFRA_-34
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

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

  • Key: IEFRA_-21
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

ISSG Request Message does not match document figure 39?

  • Key: IEFRA_-25
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    ISSG Request Message does not match document figure 39?

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 17:26 GMT
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Typo

  • Key: IEFRA_-33
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

SAMSON references

  • Key: IEFRA_-32
  • Status: open  
  • Source: Technical Director Emeritus ( Andrew Watson)
  • Summary:

    Please supply URLs for the SAMSON documents (references 22 & 23 in section section 3.2).

  • Reported: IEF-RA 1.0b1 — Thu, 27 Jul 2017 15:41 GMT
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Add clarifying note that alternative implementations for email are possible

  • Key: IEFRA_-24
  • Status: open  
  • Source: Fujitsu ( 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT

Compliance section confusing

  • Key: IEFRA_-31
  • Status: open  
  • 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
  • Updated: Tue, 9 Jul 2019 14:21 GMT
  • Attachments: