[RFC] 0017 Remove log.original stage 1

[djptek]

• Have you signed the contributor license agreement? Y
• Have you followed the contributor guidelines? Y
• For proposing substantial changes or additions to the schema, have you reviewed the RFC process? Y
• If submitting code/script changes, have you verified all tests pass locally using make test? n/a stage 1
• If submitting schema/fields updates, have you generated new artifacts by running make and committed those changes? n/a stage 1
• Is your pull request against master? Unless there is a good reason otherwise, we prefer pull requests against master and will backport as needed. Y
• Have you added an entry to the [CHANGELOG.next.md] (https://github.com/elastic/ecs/blob/master/CHANGELOG.next.md)? n/a stage 1

[ebeahan]

Thanks for iterating on this, @djptek!

I think overall it's shaping up well. Couple of "virtual paperwork" items 😸 :

• Would you add the URL for this PR to the section towards the bottom for stage 1?
• Also would you add my handle, @ebeahan, as the sponsor under the People section?

[ebeahan]

Including field definition files when adding or changing fields has proven useful in a couple of ways:

• The fields can be used either with the --include flag to test out the field changes
• Sometimes, the proposed field definitions get a little long, especially for brand new fieldsets. Separating the field definitions from the markdown keeps everything a bit tidier.

The way that custom files are merged with the current ECS fields, even if you remove a current ECS field it'll still be present in all the outputs. So it's not a problem to include these field definitions here, but unfortunately, we can't use them with the --include flag and get the expected result.

I do think we could consider having a consistent way to mark a field as deprecated in the ECS docs until we're ready to entirely remove the field. Looking at the Elastic docs repo, there is an asciidoc admonition available for deprecated that we might be able to leverage somehow: https://github.com/elastic/docs#old-section.

We have something similar for the beta attribute: https://github.com/elastic/ecs/blob/master/scripts/templates/field_details.j2#L13-L18

[ebeahan]

Thanks, @djptek, for the updates! Everything is looking great here.

I'm going to list out the criteria for advancing to stage one. The one remaining item is capturing some of the potential implementation challenges and concerns in the proposal doc.

• Opened pull request for this proposal revising the existing strawperson
• Identified "sponsor" at Elastic who will participate in RFC process and take ownership of the change after the process completes
• Outlined initial field definitions
• High-level description of examples of usage
• High-level description of example sources of data
• Identified potential concerns and implementation challenges/complexity
  • Let's note under Scope of impact that Beats modules and Agent integration packages would be required to migrate if this change is adopted as proposed. No need to find or list every instance, but we should call out that those ingestion sources will be affected if this change takes place.
  • I think lines 10-13 noting the breaking changes could go under the Scope of impact section as well.
• Subject matter experts identified and weighed in on the high level utility of these changes in the pull request
• ECS team weighed in on appropriateness of these changes in the pull request

[djptek]

Thanks for the comments @ebeahan I've updated as discussed during the call today + applied the changes requested here in Identified potential concerns and implementation challenges/complexity

[ebeahan]

Other than the one nit item, LGTM 👍 !

I'll let you handle merging, @djptek. Before you do, please add a commit setting the Date at the top of the proposal doc to the date you're merging on. When you push the commit, you'll dismiss the approval ✅ , but feel free to merge without additional approval.

Typically once an RFC has advanced as stage one, another PR is opened to add new fields or changes to the experimental schema. Since the only proposed change here is updating the log.original field's description, I don't think we worry about adding the experimental schema changes.

I'm also open to discussing more if we think there might be value to including those changes, though.