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

Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
IEFRA-32 SAMSON references IEF-RA 1.0b1 open
IEFRA-31 Inventory problems IEF-RA 1.0b1 open
IEFRA-30 Typo IEF-RA 1.0b1 open
IEFRA-29 Use standard OMG document number formats IEF-RA 1.0b1 open
IEFRA-28 Typo IEF-RA 1.0b1 open
IEFRA-27 i.e./e.g. IEF-RA 1.0b1 open
IEFRA-26 Agreement IEF-RA 1.0b1 open
IEFRA-25 Agreement IEF-RA 1.0b1 open
IEFRA-24 Typo IEF-RA 1.0b1 open
IEFRA-23 Agreement IEF-RA 1.0b1 open
IEFRA-22 Section 1.2 clause list inaccurate IEF-RA 1.0b1 open
IEFRA-21 Use definitional language IEF-RA 1.0b1 open
IEFRA-20 Dates and places IEF-RA 1.0b1 open
IEFRA-19 Bullet context IEF-RA 1.0b1 open
IEFRA-18 Non-sentence IEF-RA 1.0b1 open
IEFRA-17 Standard Fuzzy Bitmap Diagram Gripe IEF-RA 1.0b1 open
IEFRA-16 Compliance section confusing IEF-RA 1.0b1 open
IEFRA-15 ISSG Request Message does not match document figure 39? IEF-RA 1.0b1 open
IEFRA-14 typo for TrustmarkData IEF-RA 1.0b1 open
IEFRA-13 Clarify permissions required for file access within folders IEF-RA 1.0b1 open
IEFRA-12 Add clarifying note that alternative implementations for email are possible IEF-RA 1.0b1 open
IEFRA-11 Verify that XSD, figures and text match for Attribute names etc IEF-RA 1.0b1 open
IEFRA-10 Resolve inconsistency of text and number of response values listed for AuthorizationResponseType entry IEF-RA 1.0b1 open
IEFRA-9 Add (new) security considerations section IEF-RA 1.0b1 open
IEFRA-8 Fix spelling errors. IEF-RA 1.0b1 open
IEFRA-7 Entry #12 has * but no associated text IEF-RA 1.0b1 open
IEFRA-6 Typos in attribute names, mismatches with XSD IEF-RA 1.0b1 open
IEFRA-5 Fix typos in Figures 5 and 10 IEF-RA 1.0b1 open
IEFRA-4 Figure text is blurred and not clear IEF-RA 1.0b1 open
IEFRA-3 Meaning of parenthetical "suite or virtual machine" not clear IEF-RA 1.0b1 open
IEFRA-2 Fix Broken URL links in glossary IEF-RA 1.0b1 open
IEFRA-1 Correct OMG document URLs IEF-RA 1.0b1 open

Issues Descriptions

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: Thu, 27 Jul 2017 17:29 GMT

Inventory problems

  • Key: IEFRA-31
  • 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: Thu, 27 Jul 2017 17:28 GMT

Typo

  • Key: IEFRA-30
  • 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: Thu, 27 Jul 2017 17:28 GMT

Use standard OMG document number formats

  • Key: IEFRA-29
  • 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: Thu, 27 Jul 2017 17:27 GMT

Typo

  • Key: IEFRA-28
  • 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: Thu, 27 Jul 2017 17:27 GMT

i.e./e.g.

  • Key: IEFRA-27
  • 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: Thu, 27 Jul 2017 17:26 GMT

Agreement

  • Key: IEFRA-26
  • 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: Thu, 27 Jul 2017 17:25 GMT

Agreement

  • Key: IEFRA-25
  • 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: Thu, 27 Jul 2017 17:25 GMT

Typo

  • Key: IEFRA-24
  • 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: Thu, 27 Jul 2017 17:24 GMT

Agreement

  • Key: IEFRA-23
  • 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: Thu, 27 Jul 2017 17:24 GMT

Section 1.2 clause list inaccurate

  • Key: IEFRA-22
  • 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: Thu, 27 Jul 2017 17:23 GMT

Use definitional language

  • Key: IEFRA-21
  • 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: Thu, 27 Jul 2017 17:23 GMT

Dates and places

  • Key: IEFRA-20
  • 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: Thu, 27 Jul 2017 17:22 GMT

Bullet context

  • Key: IEFRA-19
  • 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: Thu, 27 Jul 2017 17:22 GMT

Non-sentence

  • Key: IEFRA-18
  • 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: Thu, 27 Jul 2017 17:21 GMT

Standard Fuzzy Bitmap Diagram Gripe

  • Key: IEFRA-17
  • 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: Thu, 27 Jul 2017 17:20 GMT

Compliance section confusing

  • Key: IEFRA-16
  • 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: Thu, 27 Jul 2017 17:19 GMT

ISSG Request Message does not match document figure 39?

  • Key: IEFRA-15
  • 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: Wed, 12 Jul 2017 19:32 GMT

typo for TrustmarkData

  • Key: IEFRA-14
  • 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: Wed, 12 Jul 2017 19:31 GMT

Clarify permissions required for file access within folders

  • Key: IEFRA-13
  • 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: Wed, 12 Jul 2017 19:31 GMT

Add clarifying note that alternative implementations for email are possible

  • Key: IEFRA-12
  • 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: Wed, 12 Jul 2017 19:30 GMT

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

  • Key: IEFRA-11
  • 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: Wed, 12 Jul 2017 19:30 GMT

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

  • Key: IEFRA-10
  • 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: Wed, 12 Jul 2017 19:29 GMT

Add (new) security considerations section

  • Key: IEFRA-9
  • 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: Wed, 12 Jul 2017 19:29 GMT

Fix spelling errors.

  • Key: IEFRA-8
  • 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: Wed, 12 Jul 2017 19:19 GMT

Entry #12 has * but no associated text

  • Key: IEFRA-7
  • 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: Wed, 12 Jul 2017 19:18 GMT

Typos in attribute names, mismatches with XSD

  • Key: IEFRA-6
  • 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: Wed, 12 Jul 2017 19:17 GMT

Fix typos in Figures 5 and 10

  • Key: IEFRA-5
  • 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: Wed, 12 Jul 2017 19:17 GMT

Figure text is blurred and not clear

  • Key: IEFRA-4
  • 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: Wed, 12 Jul 2017 19:16 GMT

Meaning of parenthetical "suite or virtual machine" not clear

  • Key: IEFRA-3
  • 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: Wed, 12 Jul 2017 19:16 GMT

Fix Broken URL links in glossary


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: Wed, 12 Jul 2017 19:14 GMT