RFC 0013 Network Headers - stage 1

[leehinman]

• switch to field set that can be nested under source and destination

[ebeahan]

Adding this entry listing the stage 1 criteria to help us track outstanding items.

Stage 1 Criteria:

• 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
• 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

[ebeahan]

@leehinman When you have some time to come back to this, would you be able to create field definitions of these additions? These definitions can be organized into a directory named 0013 after the RFC like we've done elsewhere.

I think accounting for capturing the different headers for directional flows is a good improvement. I worry about using header as the field set name for all flag data because values like .ip and .port are also in the connection headers, and I could see it becoming confusing quickly.

[legoguy1000]

I'll add my comment that I think that the header fields should stay under network as all the tools that i've seen supply that data, don't distinguish. For all traffic the header will always be from the source. 🤷‍♂️

[legoguy1000]

@any updates on this??

[github-actions]

This PR is stale because it has been open for 60 days with no activity.

[legoguy1000]

un-stale :)

[rwaight]

If the current plan is to put network as a field set under source and destination, then it should also be placed under client and server as this is relevant to data coming from Zeek. Otherwise, I agree with the header fields staying under network. as mentioned in #1508 (comment).

[jamiehynds]

@leehinman @dainperkins this RFC has been stale for some time, but there's certainly still demand. Do you think you'll have time to advance the RFC over the coming weeks? (No problem whatsoever if not).

[leehinman]

I don't think I will have the time :-(

[github-actions]

This PR is stale because it has been open for 60 days with no activity.

[legoguy1000]

don't be stale :)

[github-actions]

This PR is stale because it has been open for 60 days with no activity.

[rwaight]

• Identified "sponsor" at Elastic who will participate in RFC process and take ownership of the change after the process completes

If this still needs an internal "sponsor" at Elastic, I am willing to sponsor this RFC. As mentioned in #1508 (comment). I still agree that the header fields should stay under network. as mentioned in #1508 (comment).

If we have an internal sponsor, what are the next steps to move this forward, @ebeahan and @leehinman ?

[github-actions]

This PR is stale because it has been open for 60 days with no activity.

[legoguy1000]

Bump

[github-actions]

This PR is stale because it has been open for 60 days with no activity.