10/7/2014 - ECRF/LVF Session Notes

Page 1 of 2

Provisioning & Maintenance of GIS Data to ECRF/LVF

Tue, October 7 | 1:15PM – 3:00PM | Boca I & II

Facilitated by John Brosowsky

Participants will continue the review of comments that were received during the public review

period for the draft NENA Standards for the Provisioning and Maintenance of GIS data to

ECRF/LVF document. Attention will be focused on issues that are cross-functional between

workgroups.

Deliverables:

Edits to the document, and corresponding notes and responses added to the comment

tracking spreadsheet.

Target Audience:

ECRF/LVF workgroup members

Members of other workgroups working on other standards and i3 functional elements

that may include ECRF/LVF interactions (ESRP and LIS)

Notes taken during session:

Table of Contents misspells interface and benefits

4.2.1 Service Area Boundaries

o Requirements #77

Commenter states that the bullets aren’t really requirements but

recommendations. Should they be strengthened or not?

Brian Rosen thinks that because it’s an informational document, these are not

requirements, but suggestions.

Bigger question is: is the doc really a standards doc, or an informational doc?

The concern is potential for conflicts with STA-010 (08-003). Don’t want to

modify those standards in this doc. We can refer to requirements expressed in

STA-010 but the concern is normative text that appears in our doc, and not in

STA-010

Struck the notion of “requirements” in the sentence before the bullets.

o Service boundary gaps and overlaps #251

Comment suggests a change from “but” to “and may” and suggests that other

gap/overlap measurements could be added, like perimeter. Text was changed.

A WG member raised concern about the gap/overlap tolerance being different

between SIF and ECRF. Per STA-010, the operators will choose this (section

5.3.4); and the values may be different at the SIF, and different at the ECRF.

Brian Rosen stated that if we can recommend a good threshold value, we should

consider adding it, and the group thinks that as well, because this document is

all about providing recommendations. Some debate on what the value should

10/7/2014 - ECRF/LVF Session Notes

Page 2 of 2

be – based on the accuracy of the request geometries, and the boundary

polygons themselves? Or something else? Also, debate on if any gaps or

overlaps should be allowed… and what to do when they are encountered. Best

recommendation of a value that the group agrees with: use zero for the

allowable tolerance. But that raises a few questions: do we then want to submit

discrepancy reports for tiny gaps and overlaps? And what about precision

issues? We agree that numerical precision issues caused by projections and

databases shouldn’t be raised as gap/overlap problems, however.

Perhaps we need text that explains the problems caused by small values versus

large values.

The comment about a perimeter check: nope, not adding it.

We’ll add a recommended value, and text that describes operational

considerations about the relative size of the value.

o Comment about unintended gaps/overlaps: whose responsibility is it to catch and

correct these issues, especially if multiple authorities are provisioning. #78

Added some clarifying text to state that large discrepancies should be resolved,

and small ones are fine left as-is, but large vs small is defined by the tolerance

threshold described above.

Also: fix gap/overlap case throughout the document. There may be instances

that are uppercase.

Per the specific comment, the responsibilities are outlined elsewhere in the

document. No changes made in the text regarding this specific comment.

4.4 GIS Data Ownership, Distribution, and Sharing

o Comment #179: No change for agency collaboration comment but did change text to

state that sharing data “used for provisioning” is encouraged. Covers both new and

existing data.

4.5 GIS Data Standards

o Comment #180: Group agrees that we need newer spatial data accuracy standards.

Diana will file an issues document, and Jason will submit new text defining accuracy

standards but in such a way that the work is ongoing, and until it’s used across the

board at NENA, use 02-014.

5.2.3 ECRF/LVF Operator

o Comment #184: How do we define “reliable access?” Added a sentence to state that

SLAs are negotiated.

o Same comment: security restrictions should apply to “names” and nothing else. No

change to the text; we do protect some sensitive information, by virtue of what we

return in LoST, and control access by unauthorized parties.

o Same comment: periodic reconciliation, and how it relates to timeframes mandated for

issue resolution in 9-1-1. Comment isn’t germane since periodic reconciliation is a

functional error checking mechanism that will occasionally attempt to find provisioning

errors that only can be discovered by full reconciliation. No change in text.