[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Location - precision, altitude, and administrative area
Hi Ryu,
thank you for "cooling down my euphoric" hint.
You seem to be correct with the offered specific formats, but the
full "managed" list of 249 datasets (select the "Full list of country
codes" link leading to:
https://www.iso.org/obp/ui/#search/code/) nicely fits into
the "Results per page:" 300 option and would equally work for
the purposes of implementing STIX I guess.
Also I see no indication that blocks the usage of the presented data.
The complete item history and details are on that page only one click away.
And in the details for Afghanistan (https://www.iso.org/obp/ui/#iso:code:3166:AF
first entry in default sorting), you see a lot of freely licensed sources named:
" List source
IGN 1992 update BET 1996; http://www.un.org/depts/cartographic/map/profile/afghanis-reg.pdf; http://www.undp.org.af/links/gov_afghan.htm , 2005-01-10; http://supremecourt.gov.af/PDFiles/constitution2004_english.pdf; http://www.pcgn.org.uk/Afghanistan%20-%20Dari.pdf; http://en.wikipedia.org/wiki/Provinces_of_Afghanistan; http://geonames.nga.mil/gns/html/romanization.html#table; https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/364395/Afghan_Romanization_System.pdf; NGA GNS (http://geonames.nga.mil/gns/html/) "
Thus, tracking down the (above) wikipedia link to
http://en.wikipedia.org/wiki/Provinces_of_Afghanistan
as an example, the referenced content is licensed as
"Text is available under the Creative Commons Attribution-ShareAlike License;"
So, it seems only to be the data stewardship, and logistics, ISO wants to have
reimbursed, when "buying" the service, and not the data itself.
To me, the above mentioned single page (sortable) result would be all
I need, but other people have different requirements.
This "service offering" (to buy) with the optimised formats and a push
like distribution, may well be costly for ISO; so I consider this extra
convenience as a fair offering to take or not to take.
All the best and thanks again for following up on this one,
Stefan.
On 03/08/17 04:48, Masuoka, Ryusuke wrote:
> Hi, Stefan,
>
> Thank you for information.
>
>> 1) ISO 3166 - 1, 2, and 3 - The catalogue:
>> ...
>> The collection contains the codes from parts 1, 2 and 3 of ISO 3166 in
>> 3 different formats: .xml, .csv, and .xls for easy integration into your own systems.
>
> Are those files for fee or freely available?
> I looked around in the page and only things freely available are
> those for BZ, NZ, and CH. It seems that I have to pay CHF 300
> to buy them.
>
> Regards,
>
> Ryu
>
> -----Original Message-----
> From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Mr. Stefan Hagen
> Sent: Wednesday, August 02, 2017 3:05 PM
> To: cti-stix@lists.oasis-open.org
> Subject: [cti-stix] Re: Location - precision, altitude, and administrative area
>
> Dear TC members,
>
> far below in this mail thread, John IMO stated in a clear manner the two questions to answer in consensual manner, as base for our decision on what to use, but this mail thread has - at least in my perception - mutated since then a tad towards free vs. closed, paywall, "whatever" hard to weight opinion statements.
>
> I hereby kindly suggest that we re-focus on these questions.
>
> For the ease of use aspects, we might take into account the following fact / offering (that lower the entry barrier for implementers):
>
> 1) ISO 3166 - 1, 2, and 3 - The catalogue:
>
> The one stop shop for free and always up to date as formally possible w.r.t.
> ISO 3166 .* is at https://www.iso.org/obp/ui/#iso:pub:PUB500001:en
> and it is freely accessible on the top of that page I find:
>
> "Whether you're in banking or a business using country codes, look no further than this collection to keep you up-to-date. It allows you to download the most recent, official lists of country codes and/or subdivisions not to mention formerly used codes in one convenient location.
>
> The collection contains the codes from parts 1, 2 and 3 of ISO 3166 in 3 different formats: .xml, .csv, and .xls for easy integration into your own systems. You will be notified when changes are made so you can download the latest versions. In this way, you can be sure that your database is always using the most up-to-date information from ISO.
>
> The service is automatically renewed every year, which means that you will keep receiving updates until you stop the auto renewal on your account."[ibid]
>
> What could an implementer besides background information in wikipedia need in addition (here I mean with such a trivial naming catalogue style standard)?
> These are mappings, that will fill a catalogue in the implementation to use for generation or validation/interpretation, that's it - or am I wrong?
>
>
> Just because I think the below list is always handy (OData ISO/IEC 20802-1:2016 and ISO/IEC 20802-2:2016 is on it because our TC insisted on the free availability upon requesting submission from OASIS to ISO, MQTT v3.1.1 "missed" that I guess ;-)
>
> 2) Freely available ISO standards list:
>
> http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html is always a good place to check, if an ISO standard is available for free with the usual caveat:
>
> "The following standards are made freely available for standardization purposes. They are protected by copyright and therefore and unless otherwise specified, no part of these publications may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, microfilm, scanning, reproduction in whole or in part to another Internet site, without permission in writing from ISO. Requests should be addressed to the ISO Central Secretariat.
>
> The documents you are about to download are a single-user, non-revisable Adobe Acrobat PDF file, to store on your personal computer. You may print out and retain one printed copy of the PDF file. This printed copy is fully protected by national and international copyright laws, and may not be photocopied or reproduced in any form. Under no circumstances may it be resold."[ibid]
>
>
>
> All the best,
> Stefan
>
> On 31/07/17 18:53, Bret Jordan wrote:
>> If the content is not freely available elsewhere online, like
>> wikipedia (some ISO content is), then I suggest that we do not use it.
>> I am fundamentally against having to pay to read a standard.
>>
>>
>> Bret
>>
>>
>>
>> ----------------------------------------------------------------------
>> --
>> *From:* cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org>
>> on behalf of Struse, Richard J. <rjs@mitre.org>
>> *Sent:* Friday, July 28, 2017 9:15:46 AM
>> *To:* Wunder, John A.; Taylor, Marlon; Masuoka, Ryusuke; Allan
>> Thomson; Sarah Kelley; Terry MacDonald
>> *Cc:* cti-stix@lists.oasis-open.org
>> *Subject:* [EXT] Re: [cti-stix] FW: [cti] Location - precision,
>> altitude, and administrative area
>>
>>
>> I think the question that we as a TC need to answer is do we want to
>> encumber the implementation of our open and freely-available work with
>> the necessity of purchasing other standards from other organizations?
>> My sense, at least to date, is that our answer is no. But this is a
>> conversation we should have as a TC.
>>
>>
>>
>> *From: *<cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A."
>> <jwunder@mitre.org>
>> *Date: *Friday, July 28, 2017 at 11:08 AM
>> *To: *"Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov>, "Masuoka, Ryusuke"
>> <masuoka.ryusuke@jp.fujitsu.com>, Allan Thomson
>> <athomson@lookingglasscyber.com>, Sarah Kelley
>> <Sarah.Kelley@cisecurity.org>, Terry MacDonald
>> <terry.macdonald@cosive.com>
>> *Cc: *"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
>> *Subject: *Re: [cti-stix] FW: [cti] Location - precision, altitude,
>> and administrative area
>>
>>
>>
>> I’ve been looking in to this. I’ve asked Chet if there’s an ISO
>> liaison to OASIS that I can work through or, if not, I’ll just reach
>> out to ISO directly. In talking to Chet, OASIS’s perspective is that
>> we’re free to reference ISO standards and it’s up to the organizations
>> implementing our specifications to legally obtain and use the referenced specifications.
>>
>>
>>
>> John
>>
>>
>>
>> *From: *<cti-stix@lists.oasis-open.org> on behalf of Marlon Taylor
>> <Marlon.Taylor@hq.dhs.gov>
>> *Date: *Friday, July 28, 2017 at 9:56 AM
>> *To: *John Wunder <jwunder@mitre.org>, "Masuoka, Ryusuke"
>> <masuoka.ryusuke@jp.fujitsu.com>, Allan Thomson
>> <athomson@lookingglasscyber.com>, Sarah Kelley
>> <Sarah.Kelley@cisecurity.org>, Terry MacDonald
>> <terry.macdonald@cosive.com>
>> *Cc: *"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
>> *Subject: *RE: [cti-stix] FW: [cti] Location - precision, altitude,
>> and administrative area
>>
>>
>>
>> Hi John,
>>
>>
>>
>> On (1), Is OASIS looking into those lawyer type questions with ISO?
>>
>>
>>
>> -Marlon
>>
>>
>>
>> *From:* cti-stix@lists.oasis-open.org
>> [mailto:cti-stix@lists.oasis-open.org] *On Behalf Of *Wunder, John A.
>> *Sent:* Friday, July 28, 2017 8:52 AM
>> *To:* Masuoka, Ryusuke; Allan Thomson; Sarah Kelley; Terry MacDonald
>> *Cc:* cti-stix@lists.oasis-open.org
>> *Subject:* Re: [cti-stix] FW: [cti] Location - precision, altitude,
>> and administrative area
>>
>>
>>
>> Hi Ryu,
>>
>>
>>
>> Thanks for the comments.
>>
>>
>>
>> (1): We’re all in agreement that we should use ISO 3166-1 for country
>> code. It’s in super common use across industry. We’re still not
>> settled on the use of ISO-3166-2 for administrative area. It’s not in
>> as much common use and, because it’s an ISO specification, we have the
>> concern about whether it requires organizations buy the specification
>> to implement it. I know most of the values are on Wikipedia, but is
>> ISO OK with vendors using the values from Wikipedia without buying the
>> specification? Are those values up to date given the amount of churn
>> (at least in some countries) in administrative areas? I’d like to be
>> able to use it, I’m just not sure we have a good answer to those questions yet.
>>
>>
>>
>> (2): Yes, absolutely those values can be in other languages. Your
>> example is correct, you’d add the “lang” attribute and that would
>> denote that the human-oriented strings in the object are in Japanese.
>>
>>
>>
>> John
>>
>>
>>
>> *From: *"Masuoka, Ryusuke" <masuoka.ryusuke@jp.fujitsu.com
>> <mailto:masuoka.ryusuke@jp.fujitsu.com>>
>> *Date: *Friday, July 28, 2017 at 3:07 AM
>> *To: *John Wunder <jwunder@mitre.org <mailto:jwunder@mitre.org>>,
>> Allan Thomson <athomson@lookingglasscyber.com
>> <mailto:athomson@lookingglasscyber.com>>, Sarah Kelley
>> <Sarah.Kelley@cisecurity.org <mailto:Sarah.Kelley@cisecurity.org>>,
>> Terry MacDonald <terry.macdonald@cosive.com
>> <mailto:terry.macdonald@cosive.com>>
>> *Cc: *"cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>" <cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>>
>> *Subject: *RE: [cti-stix] FW: [cti] Location - precision, altitude,
>> and administrative area
>>
>>
>>
>> Hi, John, All,
>>
>>
>>
>> (1) As for “country”and “administrative_area”,
>>
>> can we make it “MUST”(at least “Should”) to use the following?
>>
>>
>>
>> ISO 3166-1 alpha-2 for “country”
>>
>> https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
>>
>> ISO 3166-2 for “administrative_area”
>>
>> https://en.wikipedia.org/wiki/ISO_3166-2
>>
>>
>>
>> So it would be
>>
>> {
>>
>> “country”: “US”,
>>
>> “administrative_area”: “US-MD”,
>>
>> “city”: “Annapolis Junction”,
>>
>> “street_address”: “300 Sentinel Drive, Suites 500 & 600”
>>
>> }
>>
>>
>>
>> (2) Is it okay to use a language other than English describing the address?
>>
>>
>>
>> If so, then my office address would be (“lang:”option is now
>> optional,
>>
>> so it may be without “lang:”field.)
>>
>>
>>
>> {
>>
>> “lang”: “ja”,
>>
>> “country”: “JP”,
>>
>> “administrative_area”: “JP-13”,
>>
>> “city”: “千代田区”,
>>
>> “street_address”: “虎ノ門2-10-1 虎ノ門ツインビルディング東棟18 階”
>>
>> }
>>
>>
>>
>> FYI, JP-13 is for Tokyo.
>>
>> https://en.wikipedia.org/wiki/ISO_3166-2:JP
>>
>>
>>
>> Regards,
>>
>>
>>
>> Ryu
>>
>>
>>
>> *From:*cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>
>> [mailto:cti-stix@lists.oasis-open.org] *On Behalf Of *Wunder, John A.
>> *Sent:* Friday, July 28, 2017 2:38 AM
>> *To:* Allan Thomson; Sarah Kelley; Terry MacDonald
>> *Cc:* cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>
>> *Subject:* Re: [cti-stix] FW: [cti] Location - precision, altitude,
>> and administrative area
>>
>>
>>
>> So putting floor in the street_address field should be supported now,
>> just like any other part of the street address. We should probably
>> clarify this in examples.
>>
>>
>>
>> As an example, MITRE’s located on floors 5-6 in our national business
>> part site, by saying suite 500 and 600. Given our current location
>> approach that would be:
>>
>>
>>
>> {
>>
>> “country”: “us”,
>>
>> “administrative_area”: “Maryland”,
>>
>> “city”: “Annapolis Junction”,
>>
>> “street_address”: “300 Sentinel Drive
>>
>> Suites 500 & 600”
>>
>> }
>>
>>
>>
>> Obviously the newline would be encoded. If you had a location where
>> they just wanted to say floor you could do that too, like “Floor 16”.
>>
>>
>>
>> The reason I don’t think we should add AGL/MSL altitude is the usual
>> one…IMO we should only add fields when there’s a use case for them
>> that’s in common use across many organizations/tools.
>>
>>
>>
>> John
>>
>>
>>
>>
>>
>> *From: *<cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>> on behalf of Allan Thomson
>> <athomson@lookingglasscyber.com
>> <mailto:athomson@lookingglasscyber.com>>
>> *Date: *Thursday, July 27, 2017 at 1:29 PM
>> *To: *Sarah Kelley <Sarah.Kelley@cisecurity.org
>> <mailto:Sarah.Kelley@cisecurity.org>>, Terry MacDonald
>> <terry.macdonald@cosive.com <mailto:terry.macdonald@cosive.com>>
>> *Cc: *"cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>" <cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>>, John Wunder
>> <jwunder@mitre.org <mailto:jwunder@mitre.org>>
>> *Subject: *Re: [cti-stix] FW: [cti] Location - precision, altitude,
>> and administrative area
>>
>>
>>
>> Hi Sarah – As shared in response to John’s email I would be fine if we
>> support floor at a minimum. But there location systems that handle
>> altitude also.
>>
>>
>>
>> Is there a reason I’m missing why we don’t allow both as options?
>>
>>
>>
>> *Allan Thomson <https://www.linkedin.com/in/url4allant/>*
>>
>> CTO
>>
>> +1-408-331-6646
>>
>> LookingGlass Cyber Solutions
>> <https://clicktime.symantec.com/a/1/enZJDev3wrxXSmtrmIYem_1BnmKdXdu1kl
>> xbhZoKIPw=?d=n86SB-r1n4HjuUJGe6_qSA0MtBxEyviLUeep1t34rktmRDnUQtKdGjnpi
>> CMGeFbVcnsagHpebKKKh29fksRfsdMMd74waf4VH01GGV3KF-OH9TUcsy6_b2Mp6LVWFxB
>> fOFOwadcD0z4xa8Jm9mB3_NsoXBCGCk3gcruYf7J6h-cv63HVb96-GuBrTdwEZ2nzka9WF
>> ov2bB4VxMTKKhg7_f_fE9JHdYRghNzbkxmtbDn0ftuo0J44d515Kch8o3Xe0fuZYLmM9Ho
>> J1tEvJDBR2kCYf4guJ3I8ULfWP5_PU6XR-zXFfONvKrDDC9MChYsjKZF9hMGO_U67njmQz
>> DQ5GaZnuyrQHVckiOhGXpddvSvJoz6HU456A1138rp2chSAlkf9ckv_08QmpAwBmE_jMzo
>> bm8McFqzeCTuqp_ZJx6hE64d4a6DBMNwbulR6pCHlsSAb8Xhhesw0UlpJPKcy5A_voqy87
>> PK_IbLI5kBBgseBGCbNZQ%3D%3D&u=http%3A%2F%2Fwww.lookingglasscyber.com%2
>> F>
>>
>>
>>
>> *From: *Sarah Kelley <Sarah.Kelley@cisecurity.org
>> <mailto:Sarah.Kelley@cisecurity.org>>
>> *Date: *Thursday, July 27, 2017 at 10:27 AM
>> *To: *Allan Thomson <athomson@lookingglasscyber.com
>> <mailto:athomson@lookingglasscyber.com>>, Terry MacDonald
>> <terry.macdonald@cosive.com <mailto:terry.macdonald@cosive.com>>
>> *Cc: *"cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>" <cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>>, "Wunder, John"
>> <jwunder@mitre.org <mailto:jwunder@mitre.org>>
>> *Subject: *Re: [cti-stix] FW: [cti] Location - precision, altitude,
>> and administrative area
>>
>>
>>
>> So, my question to you Allan would be this. If the primary purpose of
>> adding the altitude field would be so that you could represent a
>> specific floor of a building, then:
>>
>> 1. Why would you not just include the floor in the actual street address?
>> 2. How would someone translate “fifth floor” into Altitude = 60 ft?
>>
>>
>>
>> I’m not saying that if people need this field we shouldn’t do it. My
>> biggest problem with altitude is that the only use case I’ve heard is
>> building floor, which is like more accurately represented by just
>> saying
>> “123 Main Street, Fifth Floor, Rm #12” than it is by saying “Altitude
>> =
>> 60 ft”.
>>
>>
>>
>> Is there a use case I’m missing here? I’d willing to expand my knowledge.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> *Sarah Kelley*
>>
>> *Senior Cyber Threat Analyst*
>>
>> *Multi-State Information Sharing and Analysis Center
>> (MS-ISAC) *
>>
>> *31 Tech Valley Drive*
>>
>> *East Greenbush, NY 12061*
>>
>> * *
>>
>> *sarah.kelley@cisecurity.org <mailto:sarah.kelley@cisecurity.org>*
>>
>> *518-266-3493*
>>
>> *24x7 Security Operations Center*
>>
>> *SOC@cisecurity.org <mailto:SOC@cisecurity.org> - 1-866-787-4722*
>>
>> * *
>>
>> ** <https://msisac.cisecurity.org/>
>>
>> * *** <https://www.facebook.com/CenterforIntSec>* ***
>> <https://twitter.com/CISecurity>* ***
>> <https://www.youtube.com/user/TheCISecurity>* ***
>> <https://www.linkedin.com/company/the-center-for-internet-security>
>>
>>
>>
>> *From: *Allan Thomson <athomson@lookingglasscyber.com
>> <mailto:athomson@lookingglasscyber.com>>
>> *Date: *Thursday, July 27, 2017 at 1:15 PM
>> *To: *"terry.macdonald@cosive.com <mailto:terry.macdonald@cosive.com>"
>> <terry.macdonald@cosive.com <mailto:terry.macdonald@cosive.com>>,
>> Sarah Kelley <Sarah.Kelley@cisecurity.org
>> <mailto:Sarah.Kelley@cisecurity.org>>
>> *Cc: *"cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>" <cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>>, "John A. Wunder"
>> <jwunder@mitre.org <mailto:jwunder@mitre.org>>
>> *Subject: *Re: [cti-stix] FW: [cti] Location - precision, altitude,
>> and administrative area
>>
>>
>>
>>
>>
>>
>>
>>
>> All – Whether you agree or disagree with the number of organizations
>> interested in altitude representation in location there are use cases
>> that it helps solve.
>>
>>
>>
>> As stated previously, any large city with skyscrapers (NY, London,
>> Signapore….etc) or enterprise (Fortune 500) that have many different
>> floors and typically multi-tenant environments, then being able to
>> determine location of related intelligence associated with a
>> particular floor is a valid use case.
>>
>>
>>
>> I don’t think organizations that don’t care about this use case should
>> necessarily make decisions to exclude the ability for the standard to
>> support altitude.
>>
>>
>>
>> Is there really a big impact to the velocity of STIX2.1 location
>> efforts by not having altitude as an option?
>>
>>
>>
>> I suggest there’s minimal impact to **allowing** altitude as an option
>> in the location object if a provider wants to include it as an option
>> property.
>>
>>
>>
>> *Allan Thomson <https://www.linkedin.com/in/url4allant/>*
>>
>> CTO
>>
>> +1-408-331-6646
>>
>> LookingGlass Cyber Solutions
>> <https://clicktime.symantec.com/a/1/enZJDev3wrxXSmtrmIYem_1BnmKdXdu1kl
>> xbhZoKIPw=?d=n86SB-r1n4HjuUJGe6_qSA0MtBxEyviLUeep1t34rktmRDnUQtKdGjnpi
>> CMGeFbVcnsagHpebKKKh29fksRfsdMMd74waf4VH01GGV3KF-OH9TUcsy6_b2Mp6LVWFxB
>> fOFOwadcD0z4xa8Jm9mB3_NsoXBCGCk3gcruYf7J6h-cv63HVb96-GuBrTdwEZ2nzka9WF
>> ov2bB4VxMTKKhg7_f_fE9JHdYRghNzbkxmtbDn0ftuo0J44d515Kch8o3Xe0fuZYLmM9Ho
>> J1tEvJDBR2kCYf4guJ3I8ULfWP5_PU6XR-zXFfONvKrDDC9MChYsjKZF9hMGO_U67njmQz
>> DQ5GaZnuyrQHVckiOhGXpddvSvJoz6HU456A1138rp2chSAlkf9ckv_08QmpAwBmE_jMzo
>> bm8McFqzeCTuqp_ZJx6hE64d4a6DBMNwbulR6pCHlsSAb8Xhhesw0UlpJPKcy5A_voqy87
>> PK_IbLI5kBBgseBGCbNZQ%3D%3D&u=http%3A%2F%2Fwww.lookingglasscyber.com%2
>> F>
>>
>>
>>
>> *From: *"cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>" <cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>> on behalf of Terry MacDonald
>> <terry.macdonald@cosive.com <mailto:terry.macdonald@cosive.com>>
>> *Date: *Wednesday, July 26, 2017 at 10:27 PM
>> *To: *Sarah Kelley <Sarah.Kelley@cisecurity.org
>> <mailto:Sarah.Kelley@cisecurity.org>>
>> *Cc: *"cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>" <cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>>, "Wunder, John"
>> <jwunder@mitre.org <mailto:jwunder@mitre.org>>
>> *Subject: *Re: [cti-stix] FW: [cti] Location - precision, altitude,
>> and administrative area
>>
>>
>>
>> I agree with Sarah. I believe that altitude is only useful to a very
>> small group, and the 80/20 rule will apply in this case.
>>
>>
>>
>> Cheers
>>
>> Terry MacDonald
>>
>> Cosive
>>
>>
>>
>> On 25/07/2017 7:44 AM, "Sarah Kelley" <Sarah.Kelley@cisecurity.org
>> <mailto:Sarah.Kelley@cisecurity.org>> wrote:
>>
>> 1. 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).
>> 2. 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*
>>
>> * *
>>
>> *sarah.kelley@cisecurity.org <mailto:sarah.kelley@cisecurity.org>*
>>
>> *518-266-3493*
>>
>> *24x7 Security Operations Center*
>>
>> *SOC@cisecurity.org <mailto:SOC@cisecurity.org> - 1-866-787-4722*
>>
>> * *
>>
>> ** <https://msisac.cisecurity.org/>
>>
>> * *** <https://www.facebook.com/CenterforIntSec>* ***
>> <https://twitter.com/CISecurity>* ***
>> <https://www.youtube.com/user/TheCISecurity>* ***
>>
>> <https://www.linkedin.com/company/the-center-for-internet-security>
>>
>>
>>
>> *From: *<cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>> on behalf of "Wunder, John
>> A." <jwunder@mitre.org <mailto:jwunder@mitre.org>>
>> *Date: *Monday, July 24, 2017 at 3:28 PM
>> *To: *"cti-stix@lists.oasis-open.org
>> <mailto:cti-stix@lists.oasis-open.org>"
>> <cti-stix@lists.oasis-open.org <mailto: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 <mailto:cti@lists.oasis-open.org>>
>> on behalf of John Wunder <jwunder@mitre.org <mailto:jwunder@mitre.org>>
>> *Date: *Monday, July 24, 2017 at 3:27 PM
>> *To: *"cti@lists.oasis-open.org <mailto:cti@lists.oasis-open.org>"
>> <cti@lists.oasis-open.org <mailto: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:
>>
>>
>>
>> 1. 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.
>> 2. 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]