[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
- My thoughts are that altitude should be deferred to a future release when we have more defined use cases (I don’t really see how it’s necessary at the moment).
- Since the ISO standards cost money, my preference would be to not use them unless the information is also available elsewhere for free.
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)
31 Tech Valley Drive
East Greenbush, NY 12061
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org - 1-866-787-4722
From: <cti-stix@lists.oasis-open.org
> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Monday, July 24, 2017 at 3:28 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org >
Subject: [cti-stix] FW: [cti] Location - precision, altitude, and administrative area
Sorry, I should have sent this to cti-stix, as this is really a conversation specifically about STIX.
From: <cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Monday, July 24, 2017 at 3:27 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Location - precision, altitude, and administrative area
All,
Now that the discussion on location precision has subsided, it seems like the closest thing we have to consensus is that the precision field should be optional and, if it’s not present, the precision is unspecified (i.e. no default). A consuming tool can then provide its own defaults and treat it how it thinks best. I realize this isn’t what everyone wanted, but it did seem like the most common either first or second-best option.
We do have two other questions to resolve:
1. Are there any use cases for an altitude property?
Altitude has been suggested once but we discussed it on a working call and there didn’t seem to be anything clear. Given that you can currently represent an address (including floor/etc) and lat/lng, are there any use cases that require an altitude specifically?
2. Should we use ISO-3166-2 for administrative area?
This was suggested on a TC call…we currently have said we’ll use ISO-3166-1 for country code, but 3166 also includes a set of values for administrative area (state, province, etc.). For example, an ISO 3166-1 alpha-2 country code is “us”, while an ISO 3166-2 area code would be “US-NY”.
There are some pros and cons to doing ISO-3166-2. The pros are obviously that it’s an international standard and provides a good set of values to use. That said, it isn’t in as much common use as ISO-3166-1 (country codes) is and so people will need to figure out how to find and use it.
My points of view on these:
- I can’t think of any use cases for altitude…address provides the best way to describe people on a certain floor/room in a building.
- We shouldn’t use ISO-3166-2 for administrative area, it’s not commonly used enough and I don’t think the value of having defined properties for that field outweighs the downside of people doing it wrong or having to figure out what it is.
John
.....
. . . . .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]