[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Updated report proposal
Wunder, John A. wrote this message on Thu, Sep 21, 2017 at 12:55 +0000: > This is a good question. A few general guidelines might be: > > > * If you make a PDF or blog post out of it, it’s a Report > * If your Marketing/PR/management approves it, it’s a Report > * If it changes on a regular basis, it’s a Grouping. > > I don’t think we should put that in the spec, but they seem like some general guidelines we could put in an FAQ or on the docs site. Can we do the exercise that Allan did w/ the recent time stamp discussion, which is strip the name, and only use the definitions as they are proposed? I feel that too much time is spent micro parsing what each of us think a particular term means instead of what we define the term to be... Note I have modifed the descriptions slightly so that it's less obvious which is which. Object A: A object is a group of references to threat intelligence that the object creator wishes to treat as a distinct entity with some shared context. The Object SDO contains a list of references to SDOs and SROs along with an explicit statement of the context shared by the content, a textual description and the name of the collection Object B: Objects are collections of threat intelligence focused on one or more topics, such as a description of a threat actor, malware, or attack technique, including context and related details. They are used to group related threat intelligence together so that it can be broadcast as a comprehensive cyber threat collection. The Object SDO contains a list of references to SDOs and SROs (the CTI objects included in the object) along with a textual description and the name of the report. Now that I've extracted the descriptions of the two objects, I really don't see much of a difference between the two. > From: <cti-stix@lists.oasis-open.org> on behalf of "Ted Bedwell (tebedwel)" <tebedwel@cisco.com> > Date: Wednesday, September 20, 2017 at 7:48 PM > To: John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > Subject: Re: [cti-stix] Re: [EXT] Re: [cti-stix] Updated report proposal > > Lots of good viewpoints in this thread. I agree with the proposed solution. That said, as John mentioned, they are very similar. What guidance should we provide to implementers with respect to when to use Report vs Grouping? > > Thanks, > ~ted > > From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> > Date: Wednesday, September 20, 2017 at 3:26 PM > To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > Subject: [cti-stix] Re: [EXT] Re: [cti-stix] Updated report proposal > > I agree with this. > > All, to sum up a long conversation we (myself, Bret, Andras, Alexandre, Sean, Jason) had on Slack…it seems like people are converging around the following option: > > > * Add a new SDO called “Grouping” (two object approach) > * Grouping will not have a separate status or published field. Instead, we’ll have a label with the name “unverified”, and in the specification it will be explicitly defined as unverified information that the producer considers too preliminary to automate on. > * No changes to Report > > Thanks, > John > > From: "Bret Jordan (CS)" <Bret_Jordan@symantec.com> > Date: Wednesday, September 20, 2017 at 3:00 PM > To: Sean Barnum <sean.barnum@FireEye.com>, Allan Thomson <athomson@lookingglasscyber.com>, John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > Subject: Re: [EXT] Re: [cti-stix] Updated report proposal > > > I think we need to stay more close to what the content creator is trying to say. I believe what the MISP people are saying is if the content is verified or unverified. is_automation_ready is trying to tell people what to do or not do with the content, and that is data markings. Saying that content is not finished or not verified to be true, is different than trying to say you can or should not automate on it. > > > > You may have groups that live at the edge and are willing to break things in every effort to block anything remotely bad, even if it has not yet been verified. But doing so, means you might break things. This is why a verified and unverified seems to make more sense. > > > > Bret > > ________________________________ > From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Sean Barnum <sean.barnum@FireEye.com> > Sent: Wednesday, September 20, 2017 9:09:07 AM > To: Allan Thomson; Wunder, John A.; cti-stix@lists.oasis-open.org > Subject: [EXT] Re: [cti-stix] Updated report proposal > > I would agree with Allan that any STIX content is "automatable". > That is why I suggested "is_automation_ready" in an attempt to convey an assertion by the producer that it is ready. Maybe this still has the same issue though. > > Get Outlook for iOS<https://clicktime.symantec.com/a/1/KTjzN6qJuBY6glP61IcF3Nw4JW4Up1x8I0yVaaffSM8=?d=iR-OjVU5ySHxnlpC05qdZCWv7hxOemGdSapPQl0jZMOhuQCMAviXgFJmtrLpov383egnuc_376rEyRKs0eHm_sDTk3oerSFInxOoxUHSNZ1oDVHqd6BqeBtcFNMvTKZ-wJdyuByemoSfS5Bbf6vwEHmve9rInMC6rmyg-gP-zW78vW1NOY-KGV5RovYCbf9eMmw1nd5f4Q5hbHhPLxmSsr6mAlFnLlkqBbAyI8WokN40x9JNJ9Dl8YM_vRTXXBl10cgtid3S51tKA7g8bVnEyLlEuiYUdRGKEr4QAC9oBXOITKWZcS7nA0ueGL-7qjXn1Zy1XMEv7zaWL7U1W6gvQwHqvjrxVOo8oWVJxf7NKAaPnXFQ0d-r8aOjMRB-fefLJO6LvyF2b4oOb3x52RnfsN3JRwvHNpBLAemYGgVWUzKLcFXmcaLneobaPzADdOyHnyVA7lUvnAaLSc9F6QuY1h0aLncerGAlRD7yjg%3D%3D&u=https%3A%2F%2Faka.ms%2Fo0ukef> > ________________________________ > From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> > Sent: Wednesday, September 20, 2017 11:05:53 AM > To: Wunder, John A.; cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Updated report proposal > > Hi John – All CTI whether it’s this object or not is automatable (and often is). > > I suggest we use a different term than that. > > Will provide suggestions in the google doc. > > Allan Thomson, > CTO, Lookingglass Cyber Solutions<https://clicktime.symantec.com/a/1/_XbiXKRFegqSc14jm6e23pmWwocjwvnaOOOtM8fQbw4=?d=iR-OjVU5ySHxnlpC05qdZCWv7hxOemGdSapPQl0jZMOhuQCMAviXgFJmtrLpov383egnuc_376rEyRKs0eHm_sDTk3oerSFInxOoxUHSNZ1oDVHqd6BqeBtcFNMvTKZ-wJdyuByemoSfS5Bbf6vwEHmve9rInMC6rmyg-gP-zW78vW1NOY-KGV5RovYCbf9eMmw1nd5f4Q5hbHhPLxmSsr6mAlFnLlkqBbAyI8WokN40x9JNJ9Dl8YM_vRTXXBl10cgtid3S51tKA7g8bVnEyLlEuiYUdRGKEr4QAC9oBXOITKWZcS7nA0ueGL-7qjXn1Zy1XMEv7zaWL7U1W6gvQwHqvjrxVOo8oWVJxf7NKAaPnXFQ0d-r8aOjMRB-fefLJO6LvyF2b4oOb3x52RnfsN3JRwvHNpBLAemYGgVWUzKLcFXmcaLneobaPzADdOyHnyVA7lUvnAaLSc9F6QuY1h0aLncerGAlRD7yjg%3D%3D&u=http%3A%2F%2Fwww.lookingglasscyber.com%2F> > This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited > > > From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org> > Date: Wednesday, September 20, 2017 at 8:01 AM > To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > Subject: Re: [cti-stix] Updated report proposal > > Hey everybody…a slight update to the proposal below. After talking to Andras and Sean, I updated the “Grouping” proposal to remove the published field and add an “automatable” property. When “automatable” is true, consumers should assume that the content is finished enough to automate. When “automatable” is false, they should assume it’s preliminary and not take action. > > John > > From: <cti-stix@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org> > Date: Wednesday, September 20, 2017 at 9:57 AM > To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > Subject: Re: [cti-stix] Updated report proposal > > Hey everybody, > > Thanks for weighing in. Given that we’re seeing some people changing their opinions here, I’d ask that if you have an opinion on this topic and haven’t yet weighed in over e-mail that you please do so. If you think they should be two objects and haven’t yet responded here, please let us know. If you think it should be a single object, please let us know. If we get enough consensus over e-mail we can avoid a ballot, but having gone back and forth a few times on this (I think I’ve developed 5-6 proposals for this topic) I’d like to have responses in e-mail rather than just on the working call. > > Also, if we do end up going with two objects, I’d like to have a proposal prepared for the Grouping object. Rich and I had previously developed a “Collection” object to capture this data, I just renamed it to Grouping and added it to the working concepts document. It has almost the same fields as Report, but the “published” property is optional (allowing the MISP team to indicate whether the report is published by either omitting or including that property) and the description is different to allow for the different semantics. Please review it here: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.t56pn7elv6u7<https://clicktime.symantec.com/a/1/eFgzdKT-HxWHjISLi9yvZPOs1xE8IQOHJrY2cHRzFd8=?d=iR-OjVU5ySHxnlpC05qdZCWv7hxOemGdSapPQl0jZMOhuQCMAviXgFJmtrLpov383egnuc_376rEyRKs0eHm_sDTk3oerSFInxOoxUHSNZ1oDVHqd6BqeBtcFNMvTKZ-wJdyuByemoSfS5Bbf6vwEHmve9rInMC6rmyg-gP-zW78vW1NOY-KGV5RovYCbf9eMmw1nd5f4Q5hbHhPLxmSsr6mAlFnLlkqBbAyI8WokN40x9JNJ9Dl8YM_vRTXXBl10cgtid3S51tKA7g8bVnEyLlEuiYUdRGKEr4QAC9oBXOITKWZcS7nA0ueGL-7qjXn1Zy1XMEv7zaWL7U1W6gvQwHqvjrxVOo8oWVJxf7NKAaPnXFQ0d-r8aOjMRB-fefLJO6LvyF2b4oOb3x52RnfsN3JRwvHNpBLAemYGgVWUzKLcFXmcaLneobaPzADdOyHnyVA7lUvnAaLSc9F6QuY1h0aLncerGAlRD7yjg%3D%3D&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4%2Fedit%23heading%3Dh.t56pn7elv6u7> (it’s right under Report). I believe that if we go with that approach we can dispense with the “status” vocabulary and other changes to the Report object that have been discussed, given we’ll have the optional published property on Grouping and there hasn’t been a strong need identified for “status” on report other than to support this use case. > > John > > From: Allan Thomson <athomson@lookingglasscyber.com> > Date: Wednesday, September 20, 2017 at 9:11 AM > To: John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > Subject: Re: [cti-stix] Updated report proposal > > > 1. Originally, I had no strong opinion on single or separate objects. However, given the discussion/debate on the meaning of these objects on this thread alone suggests to me that separate might be more easily understood once it goes beyond the TC to the broader community of orgs implementing this standard. > 2. Prefer making sure the status-ov includes the additional status being called for by folks like MISP….etc and avoid having a published property timestamp at all. > 3. As per 2) just update to include additional status. > > Allan Thomson, > CTO, Lookingglass Cyber Solutions<https://clicktime.symantec.com/a/1/_XbiXKRFegqSc14jm6e23pmWwocjwvnaOOOtM8fQbw4=?d=iR-OjVU5ySHxnlpC05qdZCWv7hxOemGdSapPQl0jZMOhuQCMAviXgFJmtrLpov383egnuc_376rEyRKs0eHm_sDTk3oerSFInxOoxUHSNZ1oDVHqd6BqeBtcFNMvTKZ-wJdyuByemoSfS5Bbf6vwEHmve9rInMC6rmyg-gP-zW78vW1NOY-KGV5RovYCbf9eMmw1nd5f4Q5hbHhPLxmSsr6mAlFnLlkqBbAyI8WokN40x9JNJ9Dl8YM_vRTXXBl10cgtid3S51tKA7g8bVnEyLlEuiYUdRGKEr4QAC9oBXOITKWZcS7nA0ueGL-7qjXn1Zy1XMEv7zaWL7U1W6gvQwHqvjrxVOo8oWVJxf7NKAaPnXFQ0d-r8aOjMRB-fefLJO6LvyF2b4oOb3x52RnfsN3JRwvHNpBLAemYGgVWUzKLcFXmcaLneobaPzADdOyHnyVA7lUvnAaLSc9F6QuY1h0aLncerGAlRD7yjg%3D%3D&u=http%3A%2F%2Fwww.lookingglasscyber.com%2F> > This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this message is intended only for use by the individual(s) to whom it is addressed. If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution of the contents contained within is strictly prohibited > > > From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org> > Date: Tuesday, September 19, 2017 at 1:14 PM > To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > Subject: Re: [cti-stix] Updated report proposal > > All, I wanted to re-up this since we just discussed it on the working call. The proposal is here: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.y3otj21tnvuj<https://clicktime.symantec.com/a/1/FWHxHGoQ2RMwbrCgz9ATvsej-COpXpGBpCGoJ00BVtk=?d=iR-OjVU5ySHxnlpC05qdZCWv7hxOemGdSapPQl0jZMOhuQCMAviXgFJmtrLpov383egnuc_376rEyRKs0eHm_sDTk3oerSFInxOoxUHSNZ1oDVHqd6BqeBtcFNMvTKZ-wJdyuByemoSfS5Bbf6vwEHmve9rInMC6rmyg-gP-zW78vW1NOY-KGV5RovYCbf9eMmw1nd5f4Q5hbHhPLxmSsr6mAlFnLlkqBbAyI8WokN40x9JNJ9Dl8YM_vRTXXBl10cgtid3S51tKA7g8bVnEyLlEuiYUdRGKEr4QAC9oBXOITKWZcS7nA0ueGL-7qjXn1Zy1XMEv7zaWL7U1W6gvQwHqvjrxVOo8oWVJxf7NKAaPnXFQ0d-r8aOjMRB-fefLJO6LvyF2b4oOb3x52RnfsN3JRwvHNpBLAemYGgVWUzKLcFXmcaLneobaPzADdOyHnyVA7lUvnAaLSc9F6QuY1h0aLncerGAlRD7yjg%3D%3D&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4%2Fedit%23heading%3Dh.y3otj21tnvuj> > > As a reminder, this topic is meant to address a need MISP brought up to share collections of threat intelligence (they call them “Events”) that are not at the level of a published report but need to be shared as a cohesive set with some shared context (title, description, labels, etc.) > > We still have three open questions: > > > 1. Is doing this in the Report object the right approach, or do we need to add a new Grouping object? Consensus has been that we should do this in the Report object, though Sean in particular has pointed out that FireEye believes it should be separate (as he said below). Given previous consensus across two working calls here I think we can assume that we’ll do it in Report unless we get a lot of feedback saying otherwise. > 2. Should we add a separate status property to capture the status of the report (as in the proposal now), or should we just use the labels property with pre-defined labels to enable automation. Consensus is mixed here, so please weigh in with your reasoning. MISP felt like to enable automation we needed a separate property, JMG and Bret pointed out that we’ve previously put values meant to enable automation in labels. > 3. What values should go in that status vocabulary, regardless of which property we end up putting it in? Right now we have a proposal from Allan Thomson for “initial-analysis”, “updated-analysis”, “final”, and “finished-product”. Are these correct? What new/changed values should there be? > > I think we’re VERY close to finally figuring this one out, so please let us know what you think. My opinions are: > > > 1. Do it in Report. > 2. Honestly either way seems doable to me, but I lean towards a separate status field so you can easily separate out the status values from other stuff you might put into report labels. > 3. I would keep “initial-analysis”, “final”, “finished-product”. I would remove “updated-analysis” because I think you can capture that semantic with the modified property and a value of “initial-analysis” (maybe call them “working-analysis”, “final-analysis”, “finished-product”). > > Thanks! > John > > From: <cti-stix@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org> > Date: Monday, September 18, 2017 at 4:59 PM > To: Sean Barnum <sean.barnum@FireEye.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > Subject: Re: [cti-stix] Updated report proposal > > Sorry about that…somewhat ironically, after there were problems with finding all of the stuff we were working on, I moved it over to the Working Concepts doc later last week: https://docs.google.com/document/d/15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4/edit#heading=h.y3otj21tnvuj<https://clicktime.symantec.com/a/1/FWHxHGoQ2RMwbrCgz9ATvsej-COpXpGBpCGoJ00BVtk=?d=iR-OjVU5ySHxnlpC05qdZCWv7hxOemGdSapPQl0jZMOhuQCMAviXgFJmtrLpov383egnuc_376rEyRKs0eHm_sDTk3oerSFInxOoxUHSNZ1oDVHqd6BqeBtcFNMvTKZ-wJdyuByemoSfS5Bbf6vwEHmve9rInMC6rmyg-gP-zW78vW1NOY-KGV5RovYCbf9eMmw1nd5f4Q5hbHhPLxmSsr6mAlFnLlkqBbAyI8WokN40x9JNJ9Dl8YM_vRTXXBl10cgtid3S51tKA7g8bVnEyLlEuiYUdRGKEr4QAC9oBXOITKWZcS7nA0ueGL-7qjXn1Zy1XMEv7zaWL7U1W6gvQwHqvjrxVOo8oWVJxf7NKAaPnXFQ0d-r8aOjMRB-fefLJO6LvyF2b4oOb3x52RnfsN3JRwvHNpBLAemYGgVWUzKLcFXmcaLneobaPzADdOyHnyVA7lUvnAaLSc9F6QuY1h0aLncerGAlRD7yjg%3D%3D&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F15qD9KBQcVcY4FlG9n_VGhqacaeiLlNcQ7zVEjc8I3b4%2Fedit%23heading%3Dh.y3otj21tnvuj> > > John > > From: Sean Barnum <sean.barnum@FireEye.com> > Date: Monday, September 18, 2017 at 4:56 PM > To: John Wunder <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > Subject: Re: [cti-stix] Updated report proposal > > I don’t see any proposal in the linked doc. > > I would object to attempts to conflate these two objects together. I believe I have given clear reasoning for this position in the past. > > Sean Barnum > Principal Architect > FireEye > M: 703.473.8262 > E: sean.barnum@fireeye.com > > From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org> > Date: Tuesday, September 12, 2017 at 8:36 AM > To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> > Subject: [cti-stix] Updated report proposal > > All, > > As I mentioned in an e-mail yesterday, based on the straw poll that we had on the August 29 working call (notes here: https://www.oasis-open.org/committees/download.php/61462/OASIS-CTI-TC_WorkingSession_August29_2017.pdf)<https://clicktime.symantec.com/a/1/jGEc7Kmo5qh0apVtrzc2YiBniMsx-UzKh1q2TohBvI8=?d=iR-OjVU5ySHxnlpC05qdZCWv7hxOemGdSapPQl0jZMOhuQCMAviXgFJmtrLpov383egnuc_376rEyRKs0eHm_sDTk3oerSFInxOoxUHSNZ1oDVHqd6BqeBtcFNMvTKZ-wJdyuByemoSfS5Bbf6vwEHmve9rInMC6rmyg-gP-zW78vW1NOY-KGV5RovYCbf9eMmw1nd5f4Q5hbHhPLxmSsr6mAlFnLlkqBbAyI8WokN40x9JNJ9Dl8YM_vRTXXBl10cgtid3S51tKA7g8bVnEyLlEuiYUdRGKEr4QAC9oBXOITKWZcS7nA0ueGL-7qjXn1Zy1XMEv7zaWL7U1W6gvQwHqvjrxVOo8oWVJxf7NKAaPnXFQ0d-r8aOjMRB-fefLJO6LvyF2b4oOb3x52RnfsN3JRwvHNpBLAemYGgVWUzKLcFXmcaLneobaPzADdOyHnyVA7lUvnAaLSc9F6QuY1h0aLncerGAlRD7yjg%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fcommittees%2Fdownload.php%2F61462%2FOASIS-CTI-TC_WorkingSession_August29_2017.pdf%29> I put together a proposal to modify the report object to cover the concept of an evolving collection of content (i.e., the MISP use case). > > Proposal is here: https://docs.google.com/document/d/1wiG6RoNEFaE2lrblfgjpu3RTAJZOK2q0b5OxXCaCV14/edit#heading=h.n8bjzg1ysgdq<https://clicktime.symantec.com/a/1/J-aXq09yTF4IZfsKEgLoDq0pFHSEbTG3Jk1AO3Ddb-w=?d=iR-OjVU5ySHxnlpC05qdZCWv7hxOemGdSapPQl0jZMOhuQCMAviXgFJmtrLpov383egnuc_376rEyRKs0eHm_sDTk3oerSFInxOoxUHSNZ1oDVHqd6BqeBtcFNMvTKZ-wJdyuByemoSfS5Bbf6vwEHmve9rInMC6rmyg-gP-zW78vW1NOY-KGV5RovYCbf9eMmw1nd5f4Q5hbHhPLxmSsr6mAlFnLlkqBbAyI8WokN40x9JNJ9Dl8YM_vRTXXBl10cgtid3S51tKA7g8bVnEyLlEuiYUdRGKEr4QAC9oBXOITKWZcS7nA0ueGL-7qjXn1Zy1XMEv7zaWL7U1W6gvQwHqvjrxVOo8oWVJxf7NKAaPnXFQ0d-r8aOjMRB-fefLJO6LvyF2b4oOb3x52RnfsN3JRwvHNpBLAemYGgVWUzKLcFXmcaLneobaPzADdOyHnyVA7lUvnAaLSc9F6QuY1h0aLncerGAlRD7yjg%3D%3D&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1wiG6RoNEFaE2lrblfgjpu3RTAJZOK2q0b5OxXCaCV14%2Fedit%23heading%3Dh.n8bjzg1ysgdq> > > The changes are: > > 1. The description of the Report object was modified slightly to remove the reference to it being “published”. There were also some additional examples added. > 2. The published property was made optional, to allow for cases where the report is not yet published. > 3. A new status property was added, based on a suggestion from Allan that what we were describing as “published” or “not published” was not really a binary flag. The vocabulary is still somewhat TBD, right now I just put “ongoing-analysis” and “final” in as placeholders. > > On the call most folks seemed to think that the best option was to modify the Report object, but we did have a couple open questions: > > > 1. Now that you’ve seen the proposal, does this general approach seem acceptable? > 2. What are the possible values in the “status” vocabulary? The thought on the call was that there were more than two, but I couldn’t think of anything and I asked on Slack and didn’t get anything either. > > Thanks, > John > This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. > This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. -- John-Mark
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]