-
Notifications
You must be signed in to change notification settings - Fork 419
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stage 2 changes for RFC 0018 - extending the threat.*
field set
#1438
Stage 2 changes for RFC 0018 - extending the threat.*
field set
#1438
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does threat.group.alias
have to be an array or is a single keyword also permissible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One open question to address diction, though I do not believe the implication of "should" versus "may" is a significant one. Both terms suggest an exception in which an array may not have multiple values.
"Should" is used because while Elasticsearch fields can have zero or more values by default, data sources and libraries producing ECS data need to distinguish between when a field only holds a single value vs. an array of possible values even if only one value is present sometimes ( The note in the field reference is to help users implementing ECS know when to use an array construct in their implementation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
dd70bc8
to
6e2e32b
Compare
…astic#1438) # Conflicts: # experimental/generated/csv/fields.csv # generated/csv/fields.csv
* master: Stage 2 changes for RFC 0018 - extending the `threat.*` field set (elastic#1438) Remove deprecated `host.user.*` fields (elastic#1439) Explicitly include user identifiers in `related.user` field description (elastic#1420) Set the merge date on RFC 0018 stage 2 (elastic#1429) [RFC] Extend Threat Fieldset - Stage 2 Proposal (elastic#1395) [Tooling] Add --exclude flag to Generator to support field removal testing (elastic#1411) Add `host.user.*` deprecation notice in field reuse description (elastic#1422) Stage 2 changes for RFC 0015 - `elf` header (elastic#1410) Stage 3 changes for RFC 0012 - `orchestrator` field set (elastic#1417) Support `match_only_text` in Go code generator (elastic#1418) Stage 3 Orchestrator RFC (elastic#1343) moving into folder (elastic#1416) removing use-cases (elastic#1405) removing --oss (elastic#1404) Set the merge date on RFC 0015 stage 2 (elastic#1409) Consolidate `Breaking changes` sections in `CHANGELOG.next` (elastic#1408) RFC-Stage-0: Proposal to add a "ticket" schema / field definition to ECS (elastic#1383) [RFC] `match_only_text` type migration - Stage 0 (elastic#1396) Client port is wrongly documented (elastic#1402) (elastic#1406)
Apply changes from stage 2 extending the
threat.*
header RFC (0018): #1395Docs preview of these changes