Comment # | Page # | Line # | Section | Comment (Include rationale for comment) |
Suggested Change | Type of Comment (General/Editorial/Technical) |
---|---|---|---|---|---|---|
1 | 15 | - | 4.1.1 | Table 3 | Include IEEE 1540 SW Risk Mgmt | T |
2 | 15 | - | 4.1.2 | Table 3 | Include IEEE/ISO/IEC 16085 Risk Mgmt | T |
3 | 5 | 335 | 2 | Existing Stds may help form the scope of a stakeholders work | add: It is recommended that implementers be familiar with 1540 and 16085 (see above) | T |
4 | 5 | 369 | 3 | Existing Stds may help form the scope of a stakeholders work | add: It is recommended that implementers be familiar with 1540 and 16085 (see above) | T |
5 | 6 | 393 | 3 | perhaps more context | add: It is recommended that implementers be familiar with 1540 and 16085 (see above) | T |
6 | 6 | 393 | 3.2 | for industry implementation, further contextual embellishment is perhaps prudent | see note in email | |
7 | 6 | 400 | 3.2 | ambiguous | add: the impact of a potential PNT cybersecurity events, as well as optimize operational effectiveness. | T |
8 | 119 | - | Table 25 | 3rd row, 3rd column | the term "lifecycle" is used, but different stakeholders have different context/perpective. Suggesting clarifying what is meant. | T |
9 | 24 | 517 | 4.1.1 | ambiguous | add: (including mission, functions, operational effectiveness, image, or reputation) | T |
10 | 34 | 538 | 4.2 | perhaps more context, definition, and direction | add annother section (see email | T |
11 | N.A. | N.A. | N.A | https://standards.ieee.org/ieee/1952/10606/ | IEEE P1952 | |
12 | iv | 81 | Abstr. | Standard GPO style is to abbreviate "U.S." rather than "US" (Section 9.7 of https://www.govinfo.gov/content/pkg/GPO-STYLEMANUAL-2016/pdf/GPO-STYLEM… ) (See also line 73, above.) |
Change "US" to "U.S." throughout document (also p. 98 line 810, p. 93 line 981, p. 98 line 1169) |
Editorial |
13 | iv | 83 | Abstr. | "government wide" | "government-wide" | Editorial |
14 | iv | 86 | Abstr. | Closing comma for appositive needed after "Services" | Add comma | Editorial |
15 | iv | 87 | Abstr. | Opening comma for appositive needed after "(NIST)" | Add comma | Editorial |
16 | vii | 154 | Exec. Summ. | First two "and"s should be "or"s, since either alone is sufficient | Change "and"s to "or"s | Editorial |
17 | vii | 155 | Exec. Summ. | Change "and" to "or" since any one of the four alone would be sufficient | Change "and" to "or" | Editorial |
18 | vii | 160 | Exec. Summ. | Change "issue" to "constitute" | Change "issue" to "constitute" | Editorial |
19 | x | 240 | Table of Cont. | Notice superflous blank space | Remove extra space found on Page 74, Line 649 | Editorial |
20 | 1 | 253 | 1 | Mismatced singular/plural | Change "are" to "is" | Editorial |
21 | 1 | 257 | 1.1 | Superfluous "in order" | Delete "in order" | Editorial |
22 | 2 | 290 | 1.2 | For parallism and ease of reading, put a "to" at the front of the line, preceding "national." | Add word "to" | Editorial |
23 | 2 | 296 | 1.2 | Add period to end of sentence | Add a period | Editorial |
24 | 3 | 315 | 1.3 | Preceed new paragraph with white space | Fix paragraph style | Editorial |
25 | 9 | 419 424 426 passim | 3.2 | Pick a consistent style for capitalizing (or not) "Subcategory(ies)". Contrast these lines with e.g., 491, 514, and 527. | Chose and use a consistant style for the capitalization of "Subcatagory." Suggest using lower case, except in titles, headings, and in reference to specific, named subcategories. | Editorial |
26 | 9 | 425 | 3.2 | Add comma after "risk telerance" for consistancy of style within document and conformance with GPO Style §8.46 |
Add a "serial" comma | Editorial |
27 | 9 | 428 | 3.2 | There is reference here to "Section 3.3," but there is no such section in the document. | Fix reference to Section 3.3. Is "Section 4" meant? |
Editorial |
28 | 11 | 462 | 4 | Add blank space in "AppendixA" | "Appendix A" | Editorial |
29 | 11 | 463 | 4 | Table 2 omits "Risk Management Strategy" Category (ID.RM) of the CSF, while it is used in this document (pp. 30-31, Section 4.1.5) | Add line to Table 2 | Editorial |
30 | 12 | 463 | 4 | Orange is used in Table 2 for "Detect," while yellow is used elsewhere (e.g., Table 1, pages 60-70) |
Change orange to yellow | Editorial |
31 | 14 | 490 491 492 | 4.1 | This is the same issue as "Table 2 omits 'Risk Management Strategy'," above. This text refers to "five" categories and "Sections 4.1.1 through Sections 4.1.5." In fact, all six categories are covered in sections up to 4.1.6. | Update paragraph to describe current version of the document. | Editorial |
32 | 15 | 501 passim | 4.1.1 | Note margin shift within text block | Make margins within text blocks self-consistant. | Editorial |
33 | 17 | 501 passim | 4.1.1 | Note font size shift within text block | Make font sizes within text blocks self-consistant. | Editorial |
34 | 22 | 509 | 4.1.2 | Third line duplicates Second line | Delete duplicate line | Editorial |
35 | 30 | 523 | 4.1.5 | Add comma after "risk tolerences" for consistancy of style within document and conformance with GPO Style §8.46 |
Add a "serial" comma | Editorial |
36 | 30 | 526 | 4.1.5 | Add comma after "constraints" for consistancy of style within document and conformance with GPO Style §8.46 |
Add a "serial" comma | Editorial |
37 | 36 | 558 | 4.2.1 | AC-3 block not bolded | Add bold style | Editorial |
38 | 45 | 572 | 4.2.3 | Change "Consider PNT receivers…" to "Consider using PNT receivers…" to match preceeding paragraph | Add "using" | Editorial |
39 | 44 45 46 |
572 | 4.2.3 | Add the following to DS-6, following the two paragraphs that begin "Consider using PNT receivers…": "Consider using PNT receivers, as they might be available, that are certified (or self-certified by their manufacturers) as meeting all data validation (range checking) guidelines in https://www.dhs.gov/sites/default/files/publications/21_0727_st_gps_whi… " Add this document to the list of References, and use the Reference code in this table. | Add Reference to important DHS document, which was issued subsequent to original PNT Profile publication. | Technical |
40 | 54 | 586 | 4.2.5 | Font shift to something Sans Serif in MA-1 | Fix font style | Editorial |
41 | 54 | 586 | 4.2.5 | Third paragraph, about leap seconds, is not maintenance related. | Combine with DS-6, which already mentions the issue. | Technical |
42 | 58 | 592 | 4.2.6 | Add the following to PT-5 to become its second paragraph: "Consider using PNT receivers, as they might be available, that are certified (or self-certified by their manufacturers) as meeting all data validation (range checking) guidelines in https://www.dhs.gov/sites/default/files/publications/21_0727_st_gps_whi… " Add this document to the list of References, and use the Reference code in this table. | Add Reference to important DHS document, which was issued subsequent to original PNT Profile publication. | Technical |
43 | 58 | 592 | 4.2.6 | Add the following to PT-5 to become its third paragraph: "Consider using PNT receiver antennas, as they might be available, that use multiple elements to provide "anti-jam" functionality." You might add a footnote to the effect that such antennas may be export controlled under ITAR regulations, but that does not preclude responsible use within the United States. This may also call for adding "ITAR" to Appendicies A and B, and perhaps "anti-jam" to Appendix B. | Technical | |
44 | 62 | 614 | 4.3.1 | In AE-4, follow "infrequent events" with "[such as leap seconds and GPS week rollovers]". While mentioned elsewhere in the document, it may be needed here, too, for clarity. Also, note shift in paragraph line spacing in this element. | Technical | |
45 | 69 | 620 | 4.3.3 | Include in DP-4 that GPS anomolies should be reported to NAVCEN, via https://www.navcen.uscg.gov/contact/gps-problem-report | Technical | |
46 | 29 | 521 | 4.1.4 RA-4 | Need to identify the maximum tolerable period of time in which PNT Services' data might be lost. The existence of RPO is confirmed in CO-1; the RPO value needs to be identified before then. |
Identify the Recovery Point Objective (RPO), which is the maximum tolerable period of time in which PNT Services' data might be lost. RPO is the backup frequency. | Technical |
47 | 29 | 521 | 4.1.4 RA-4 | Need to identify how quickly an organization must recover its business processes to avoid negative consequences following an incident involving PNT Services The existence of RTO is confirmed in CO-1; the RTO value needs to be identified before then. |
Identify how quickly an organization must recover its business processes to avoid negative consequences following an incident involving PNT Services, which is the Recovery Time Objective (RTO). | Technical |
48 | 114 | 1765 | Appendix D | Frame the example use cases in Appendix D as notional, to highlight how the guidance can be used, rather than as mandatory directives. | Technical | |
49 | 119-120 | 1789 | Appendix D | Some language in Appendix D could be construed as overly prescriptive and therefore should be revised. For example, the Example Scenario on “supply chain” sets unduly directive language for supplier and third-partytesting and certification, stating that organizations should identify “conformance testing and certification requirements and processes.” It is not appropriate to set expectations for testing as circumstances and needs will vary. | Technical | |
50 | 118 | 1789 | Appendix D | Example Scenario on “data in transit” is likewise too prescriptive.Decisions regarding network management and procedures must be agile and reflect the types of data at issue as well as the resiliency and redundancy of existing systems. | Technical | |
51 | 114 | 1788 | Appendix D | Due to these widely varying uses of PNT services, DHS has previously explained that “[e]nd users should be responsible for mitigating temporary GPS disruptions.” | Technical | |
52 | 114 | 1787 | Appendix D | better delineate these roles, including in Appendix D.For example, equipment manufacturers or end users may be best positionedto address theExample Scenarios involving users, software, and hardware by building in resiliency or redundancy | Technical | |
53 | TBD | Network providers, in turn,can look to CommunicationsSector-specific resources such as the Communications Sector PNT Risk Assessment Plan for specific guidance on howto augment their risk management programs to achieve the desired outcomes commensurate with acceptable and responsible levels of risk that result from the disruption or manipulation of PNT data. | NIST should clarify the Draft Revision’s audience by noting that end users and manufacturers are often best positioned to address PNT resiliency and that network providers should follow sector-specific guidance. | |||
54 | Appendix D and maybe E(?) | Understanding that NIST itself will not be developing the contractual language, we encourage NIST to update Appendix E | to discuss the importance of flexibility in any future contractual language or clauses, with respect to the Foundational PNT ProfileRevision, so that contractors can continue to address context-dependent risks. | |||
55 | Appendix E? | The Foundational PNT Profile Revision should expressly note that agencies should take a risk-based approach to diverse PNT uses across government, building on this and other documents but not attempting to impose one uniform approach. | ||||
56 | Continue to incorporate wireless sector feedback and perspectives into the Foundational PNT ProfileRevision, as the wireless industry has been collaborating on these issues; | General | ||||
57 | Aim for a consistent approach to federal government PNT workstreams and guidance; | General | ||||
58 | Maintain and bolster the voluntary, flexible, and risk-based nature ofthe document in the Foundational PNT Profile Revision, recognizing that responsibilities for various PNT resiliency functions will fall on different stakeholders. | General | ||||
59 | Encourage flexibility for any future government contracting language that is developed from the Foundational PNT ProfileRevision. | General | ||||
60 | 1 | 278 | 1.2 | the definition is incomplete when considering positioning. | altitude (including depth) | General |
61 | 1 | 281 | 1.2 | incomplete description | NTP (including NTP Sec) | General |
62 | 1 | 298 | 1.2 | This would be inconsistent with NIST doctrine (NIST 800-161) on supply chain security for data. There should be a reference that describes that the potential security from the "out-of-scope" sources of data that indicates how to get an assurance from upstream sources of data that may have their security controls or regimes. These would need to be referenced in order to give an assurance that the data arriving at the system met equivalent or better security. For example, under this doctrine, would GPS and time corruptions be caught? | The organization's PNT profile | General |
63 | 9 | 434 | 4 | In figure 3, should there be a reference to where the identification of safety significant systems (a label used by regulatory bodies and accreditation bodies) woud fit in this process? While these could be argued as being part of the cybersecurity requirements (such as for shipping under IACS UR E22). | Insert footnote to indicate that this is where the safety significant delineation fits into the process. | General |
64 | 11 | 463 | 4 | Protective technology should have the Y put at the end of technology | make technology one word again | editorial |
65 | 17 | AM-3: Is there a logical limit that should be applied here? Should an organization be able to say "GPS data from…" or does it need to go deeper? This appears unclear. | Identify the PNT data source and distribution medium where it comes into the span of control of the organization (e.g. GPS data from source…) | General | ||
66 | 19 | AM-5: This should reflect the reality of tiered support. For example, maintenance may be able to reset or configure equipment but there be issues in attempting to work with the internals of equipment that that the suppliers do not want accessed. | AM-5: Provide adequate training and support within appropriate roles and responsibilities to ensure that appropriate support for PNT resources is demonstrable. | General | ||
67 | 21 | The third line and the second line are the same | remove one of them | Editorial | ||
68 | 23 | The comprehensive strategy associated with PNT operations likely already exists. What needs to happen is that PNT considerations are included in the overall cybersecurity risk management strateg that feeds that strategy. | PNT considerations are identified and then incorporated or integrated into cybersecurity or the overarching operational policies. | General | ||
69 | 27 | RA-3: What is a manufactured threat? 800-30 has adversarial and non-adversarial. Manufactured threats do not appear in 800-30 for risk management. Point to ask: why are not the categories of threats within the NIST guide to conducting risk assessments used? | Align lists. | General | ||
70 | 27 | This statement creates a "checklist" of threats when interpreted literally ("should include"). | Change should include to should consider (at a minimum) | General | ||
71 | 30 | RM-1: Should disposal not be considered in terms of the responsible use to ensure a full lifecycle coverage? | Add disposal to the list | General |