Start of network headers RFC

[leehinman]

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

[dainperkins]

Sweet, nice work @leehinman.

1st thing that was bugging me - when you consider IPFIX many of these can be not only src based as would be typical for a packet capture, but also bi-directional, making me think using src/dst (or specific src/dst fields under network...) would be beneficial. I think I'm actually partial to nesting under network with src/dst.

Do you think it's necessary to have the header portion of the objects? Seems unnecessary to me

Do you want the rest of the list of network fields (e.g. cos, tos, dscp, windowing, etc.)? Course then it would be useful to also include some of those, particularly e.g. qos, under observer as well.

[ebeahan]

Thanks, @leehinman, for writing up this proposal.

@dainperkins brings up some great points. Let's make sure to pull those into the discussion and capture concerns if necessary in the stage 1 PR.

This looks great to me for stage 0; the proposed changes are appropriate and seem useful additions to ECS.

I'll move forward with merging, setting the date, and assigning it an RFC number.

[abraxxa]

Thanks for the pointer to this pull-request @ebeahan!

As the RFC document doesn' t describe how someone besides the RFC author can comment on the proposal I'll do it here.

I'd suggest to drop the header part to shorten the fields and define the tcp flags as an array as multiple can be set.

[legoguy1000]

I agree with the comment above. This will be great for the suricata, zeek, snort... modules/integrations.

[legoguy1000]

Is this RFC going to be pushed to the next stage??

[kgeller]

@legoguy1000 no one has opened a PR for the next stage yet.

If you're interested, we certainly encourage community involvement!

[legoguy1000]

@kgeller I opened #1641. There is a lot missing but I wanted to get a least something on the board to start the next round of conversation.