OASIS Cyber Threat Intelligence (CTI) TC

All, When we first worked on the Location object, there was some discussion about adding a precision property for lat/long.  Back then, I went along with the request and claims being made.  However, after letting this sit for a while (6 months), I now think that precision for lat/long is just not worth it. The amount of extra complexity it will require on implementations and systems not knowing what to do with it, makes this a solid candidate for a custom property. We have a history in the TC about debating precision on timestamps, and I feel like this falls in to that same bucket. We decided to elide timestamp precision and I think we should do the same here with lat/long precision in the Location object.  If we find in the future that we honestly really do need it, then sure, we can see about adding it.  I just do not feel like it is worth it right now and would strongly propose that we remove precision from Location before it is included in 2.1.  Thanks Bret

I agree with this proposal. Is this really needed, and realistically how often will anyone provide it, and if so how often would consumers process it. (FWIW, you can't even populate this value from Maxmind originated location data since it's definition disagrees with how they communicate accuracy, which is based on a radius) - Jason Keirstead Lead Architect - IBM Security Cloud www.ibm.com/security "Things may come to those who wait, but only the things left by those who hustle." - Unknown From:         Bret Jordan <Bret_Jordan@symantec.com> To:         "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Date:         08/12/2018 09:06 PM Subject:         [cti] Location Object Sent by:         <cti@lists.oasis-open.org> All, When we first worked on the Location object, there was some discussion about adding a precision property for lat/long.  Back then, I went along with the request and claims being made.  However, after letting this sit for a while (6 months), I now think that precision for lat/long is just not worth it. The amount of extra complexity it will require on implementations and systems not knowing what to do with it, makes this a solid candidate for a custom property. We have a history in the TC about debating precision on timestamps, and I feel like this falls in to that same bucket. We decided to elide timestamp precision and I think we should do the same here with lat/long precision in the Location object. If we find in the future that we honestly really do need it, then sure, we can see about adding it.  I just do not feel like it is worth it right now and would strongly propose that we remove precision from Location before it is included in 2.1. Thanks Bret

Jason Keirstead wrote this message on Sun, Aug 12, 2018 at 22:44 -0300: > I agree with this proposal. Is this really needed, and realistically how > often will anyone provide it, and if so how often would consumers process > it. > > (FWIW, you can't even populate this value from Maxmind originated location > data since it's definition disagrees with how they communicate accuracy, > which is based on a radius) We have defined precision AS a radius. Per WD02: "The actual Location may be anywhere up to precision meters from the defined point." Here is MaxMind's definition:[1] "The approximate accuracy radius, in kilometers, around the latitude and longitude for the geographical entity (country, subdivision, city or postal code) associated with the IP address." Our definition is the same as MaxMinds except that we use meters instead of kilometers. (If MaxMind were to indicate precision of 100 meters, they would use .1, while we would use 100.) That MaxMind includes precision in their data shows that we should include it in ours. It is a simple matter of multiplying by 1000 their accuracy radius to populate the precision property. Removing this optional property significantly degrades the ability to convey location data, and decreases the confidence in the accuracy of the provided data. [1] https://www.maxmind.com/en/geoip2-precision-insights > From: Bret Jordan <Bret_Jordan@symantec.com> > To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> > Date: 08/12/2018 09:06 PM > Subject: [cti] Location Object > Sent by: <cti@lists.oasis-open.org> > > > > All, > > When we first worked on the Location object, there was some discussion > about adding a precision property for lat/long. Back then, I went along > with the request and claims being made. However, after letting this sit > for a while (6 months), I now think that precision for lat/long is just > not worth it. The amount of extra complexity it will require on > implementations and systems not knowing what to do with it, makes this a > solid candidate for a custom property. > > We have a history in the TC about debating precision on timestamps, and I > feel like this falls in to that same bucket. We decided to elide timestamp > precision and I think we should do the same here with lat/long precision > in the Location object. > > If we find in the future that we honestly really do need it, then sure, we > can see about adding it. I just do not feel like it is worth it right now > and would strongly propose that we remove precision from Location before > it is included in 2.1. > > Thanks > Bret > > > > > > -- John-Mark

I still think location precision should be dropped, for the exact same reasons we did not do it for timestamps. Bret From: John-Mark Gurney <jmg@newcontext.com> Sent: Wednesday, August 15, 2018 10:17:11 AM To: Jason Keirstead Cc: Bret Jordan; cti@lists.oasis-open.org Subject: [EXT] Re: [cti] Location Object   Jason Keirstead wrote this message on Sun, Aug 12, 2018 at 22:44 -0300: > I agree with this proposal. Is this really needed, and realistically how > often will anyone provide it, and if so how often would consumers process > it. > > (FWIW, you can't even populate this value from Maxmind originated location > data since it's definition disagrees with how they communicate accuracy, > which is based on a radius) We have defined precision AS a radius.  Per WD02: "The actual Location may be anywhere up to precision meters from the defined point." Here is MaxMind's definition:[1] "The approximate accuracy radius, in kilometers, around the latitude and longitude for the geographical entity (country, subdivision, city or postal code) associated with the IP address." Our definition is the same as MaxMinds except that we use meters instead of kilometers.  (If MaxMind were to indicate precision of 100 meters, they would use .1, while we would use 100.) That MaxMind includes precision in their data shows that we should include it in ours.  It is a simple matter of multiplying by 1000 their accuracy radius to populate the precision property. Removing this optional property significantly degrades the ability to convey location data, and decreases the confidence in the accuracy of the provided data. [1] https://clicktime.symantec.com/a/1/1oqDe4B2i-l9BK-2pShIwtrGaFHNhMNwlC1X8RaZwt0=?d=X33-a9ljFD3YWM_6dP3GtyS-m3ihRKJdFPOUVjp45IXc3BQ79jLsO-dQynq01oAuPwPWC2ffJR09UeUpFvarZMXKDAozqCPX0C30gX24EPrYX3DrSLoj5tfvvVCGbf-OhCcascDmEWxfvzcnn6OIrg1kRxF7ji8C_yp4-j50GwAHPzzHDxeG_904Vc4yRiVbkaBj1EHvnmR4j5hKkBomakwDkRAUpmCvcqcxQXjOWy6k7pn67balqgYkOZtMoEkZzQg_A-L7fuCmesVgR4AynQgNHlngbRnK8d0_jgIlC_UgMWQ7QFRM_wREK8OxqwxUdciqISBnb9Xq8lyINkoybdPm21cMD3M_G7qQ-6Vf_Z0%3D&u=https%3A%2F%2Fwww.maxmind.com%2Fen%2Fgeoip2-precision-insights > From:   Bret Jordan <Bret_Jordan@symantec.com> > To:     "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> > Date:   08/12/2018 09:06 PM > Subject:        [cti] Location Object > Sent by:        <cti@lists.oasis-open.org> > > > > All, > > When we first worked on the Location object, there was some discussion > about adding a precision property for lat/long.  Back then, I went along > with the request and claims being made.  However, after letting this sit > for a while (6 months), I now think that precision for lat/long is just > not worth it. The amount of extra complexity it will require on > implementations and systems not knowing what to do with it, makes this a > solid candidate for a custom property. > > We have a history in the TC about debating precision on timestamps, and I > feel like this falls in to that same bucket. We decided to elide timestamp > precision and I think we should do the same here with lat/long precision > in the Location object. > > If we find in the future that we honestly really do need it, then sure, we > can see about adding it.  I just do not feel like it is worth it right now > and would strongly propose that we remove precision from Location before > it is included in 2.1. > > Thanks > Bret > > > > > > -- John-Mark

On 15.08.2018 16:55:40, Bret Jordan wrote: > I still think location precision should be dropped, for the exact > same reasons we did not do it for timestamps. > Well, Bret, that is your opinion. Everybody has one. Given that a great many CTI TC members are currently out on summer holiday, I respectfully insist that we refrain from removing location precision (previously discussed and reviewed at length by the TC) until September when folks come back from summer holiday. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "Conservative, n.: One who admires radicals centuries after they're dead." --Leo Rosten Attachment: signature.asc Description: PGP signature

To quote you, well, Trey, that is your opinion. Everyone has one.


Bret 

Sent from my Commodore 64 


PGP
Fingerprint:  63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050


On Aug 15, 2018, at 11:25 AM, Trey Darley < trey@newcontext.com > wrote:



On 15.08.2018 16:55:40, Bret Jordan wrote:
I still think location precision should be dropped, for the exact

same reasons we did not do it for timestamps.




Well, Bret, that is your opinion. Everybody has one.

Given that a great many CTI TC members are currently out on summer
holiday, I respectfully insist that we refrain from removing location
precision (previously discussed and reviewed at length by the TC)
until September when folks come back from summer holiday.

--
Cheers,
Trey
++--------------------------------------------------------------------------++
Director of Standards Development, New Context
gpg fingerprint: 3918 9D7E 50F5 088F 823F  018A 831A 270A 6C4F C338
++--------------------------------------------------------------------------++
--
"Conservative, n.: One who admires radicals centuries after they're
dead." --Leo Rosten

On 15.08.2018 19:42:52, Bret Jordan wrote: > To quote you, well, Trey, that is your opinion. Everyone has one. > Bret - To quote your oft-repeated refrain, we in the CTI TC leadership must endeavor to ensure that the community's voices are heard. To wit - and I repeat myself - given that a great many CTI TC members are currently out on summer holiday, I respectfully insist that we refrain from removing location precision (previously discussed and reviewed at length by the TC) until September when folks come back from summer holiday. Unless you've reconsidered your position, we should hold off until the TC regains quorum. If you no longer agree with the notion that the TC community's voices must be heard and given due consideration, then we can have an altogether different discussion. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "For all resources, whatever it is, you need more." --RFC 1925 Attachment: signature.asc Description: PGP signature

On 15.08.2018 09:17:11, John-Mark Gurney wrote: > > Removing this optional property significantly degrades the ability > to convey location data, and decreases the confidence in the > accuracy of the provided data. > I fully agree with John-Mark's assessment. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "All models are wrong, some models are are useful." --George Box Attachment: signature.asc Description: PGP signature