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).

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.."

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).

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.

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.

Readdress IEFRA-24

Deferred until RTF

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.

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.

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”

*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

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..."

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

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..."

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..."

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"

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

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..

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

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.

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.

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

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

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)

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.

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.

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.

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”

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”

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.

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.

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

Correction for IEFRA-15

Corrected Identified Spelling Errors

Conducted an additional spelling review - see end of revised text

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

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?

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

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.

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

Figure 10
Instance Deployment not Instant Deployment (in caption)

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

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

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.

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)

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

ISSG Request Message does not match document figure 39?

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?

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

Correction for IEFRA-32

Note: IEFRA-32 in FTF is IEFRA-32 in FTF 2.

Added references (URLs) for both SAMSON Documents - references 22 & 23 in section 3.2 - Reference Materials:
22. SAMSON Technology Demonstrator Architectural Design Document Phase IV SD002, Dr. Daniel Charlebois et al, Defence Research and Development Canada, 2013, http://publications.gc.ca/collections/collection_2016/rddc-drdc/D68-3-C3-2013-eng.pdf
23. SAMSON Technology Demonstrator Detailed Design Document Phase IV SD004, Dr. Daniel Charlebois et al, Defence Research and Development Canada, http://publications.gc.ca/collections/collection_2016/rddc-drdc/D68-3-C6-2013-eng.pdf

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.

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

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."

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.

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.".

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.".

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

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.

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

Correction for IEFRA-33

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

Spurious ' in section 1.8

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).

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

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).

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

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:”

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:”

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

Correction IEFRA-91

In 1.7.2 typo still exists “secuence diagrams”

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.

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.

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”

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.

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)

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)

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)

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

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?

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

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.

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.

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

Correction to IEFRA-83

Errors in TOC

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.

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

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"

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"

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

(first sentence of section)

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"

Glossary Issues:

Decision Advantage
http://www.jfcom.mil/about/glossary.htm
Page Not Found

Digest - Logical Entity eXchange Specification (LEXS).
http://130.207.211.107/content/lexs-overview
could not open page

information advantage
link does not lead to definition
http://www.fas.org/spp/military/docops/defense/97_jwstp/jw4a.htm

Multi-Independent Levels of Security
http://www.adacore.com/gnatpro-high-security/mils#sthash.BUzkPb7t.dpuf
404 Page Not Found

Responsible Information Sharing
National Security through Responsible Information Sharing (http://proceedings.esri.com/library/userconf/nss13/papers/nss-010.pdf); and
Page not found

PublisherMetadata
Derived from: Logical Entity Exchange Specifications 4.0 (LEXS) User Guide
(http://130.207.211.107/sites/all/lexs/docs/lexs-4.0/LEXS_4_UserGuide%209-27-2011.pdf)
no return

Broken fragments:
https://www.w3.org/standards/techs/xmlschema#w3c_all

The links below are not broken, but the document does not use the exact URL, and the links were redirected. It may be a good idea to link to the final location, for the sake of speed.

http://www.computerworld.com/s/article/9242493/Snowden_s_role_provided_perfect_cover_for_NSA_data_theft
redirected to
http://www.computerworld.com/article/2485175/security0/snowden-s-role-provided--perfect-cover--for-nsa-data-theft.html
Status: 301 -> 200 OK
This is a permanent redirect. The link should be updated.

http://xmpp.org/ redirected to https://xmpp.org/
Status: 301 -> 200 OK
This is a permanent redirect. The link should be updated.

http://www.computerworld.com/s/article/9242493/Snowden_s_role_provided_perfect_cover_for_NSA_dat%20a_theft
redirected to
http://www.computerworld.com/article/2485175/security0/snowden-s-role-provided--perfect-cover--for-nsa-data-theft.html
Status: 301 -> 200 OK
This is a permanent redirect. The link should be updated.

http://www.niem.gov/ redirected to https://www.niem.gov/
Status: 301 -> 200 OK
This is a permanent redirect. The link should be updated.

Corrention of IEFRA-3 - broken URLs

Note: IEFRA-2 in FTF 1 was renumbered as IEFRA-3 in FTF 2. The response and revisions remain the same. Issues raise by AB to the FTF 1 report are addressed in as IEFRA-85 proposal.

1: Resolves IEFRA-2 - broken links in glossary. - proposal: Remove the URL links in the glossary - the URLs were provided as information only and will be difficult to maintain over life-time of the specification: as many organizations allow aging URLs to decay, archive the materials and change the URLS, or remove the content and URLs from the web.

2: Broken Fragments: Proposal: Replace the reference from the W3C XML Schema Current Status page and add the reference to the specifications.

3: Broken Links: Proposal: Replace the links in the document.

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

Correction for IEFRA-37

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

Changed "confimin" to "conforming"

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

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"?

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".

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".

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

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.

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).

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.

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

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"

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

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.

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.

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.

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.

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.

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

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

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.

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

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

Resolution of IEFRA-67

FTF 2 submitted issue

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

Corrected to Table of Contents

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

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".

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

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".

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.

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.

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.

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.

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?

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?

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"

*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.

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

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

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.

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.

#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"

*Duplicate of *

Accidentally added this issue twice

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".

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".

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

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.

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"

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"

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".

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 ","