[DISCUSS] Should we require that source/destination always be populated, even if client/server are populated?

[webmat]

#236 introduces client/server as the other pair of network endpoints we can use to represent an exchange over the network. We've discussed in #61 that there can be big advantages to representing the exchange that way, over using the source/destination pair.

I think it's great to populate client/server when we can, but I would contend that when this happens, we should still populate source/destination.

I want to know that 100% of my events have source/destination. (And I think we can populate it in all situations.)

What do people think? Should we introduce this?

[webmat]

Ping @ruflin @MikePaquette @robgil @andrewkroh @andrew-goldstein

[farrp]

I completely agree. It would be good to know that source/destination are always available. It may be a bit of duplication but it is not 100% the same thing. Regards Peter Farr OPS Consulting +1 416 436 5977

…

On Dec 6, 2018, at 4:55 PM, Mathieu Martin ***@***.***> wrote: #236 introduces client/server as the other pair of network endpoints we can use to represent an exchange over the network. We've discussed in #61 that there can be big advantages to representing the exchange that way, over using the source/destination pair. I think it's great to populate client/server when we can, but I would contend that when this happens, we should still populate source/destination. I want to know that 100% of my events have source/destination. (And I think we can populate it in all situations.) What do people think? Should we introduce this? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[strikaco]

Yes. Most network appliances and analytics tools already think in terms of source/dest. It would make sense for a common schema to enforce adherence to terms applicable to the broadest base-- the users of everything from Wireshark to Splunk and many network appliances are already familiar with these terms.

Adding an additional pair of terms for the same artifacts and making either set optional opens the door to ambiguity, the consequences of which have been one of our biggest headaches with the Elastic platform and one I personally hoped to see resolved with the advent of ECS. Our current schema already requires us having to check multiple fieldsets for the same artifact (usually under incident!) and it's an error-prone waste of everybody's time. Field aliases are only a partial (and recent) solution; I would hate to see this anti-pattern end up in any standard or guideline.

The client/server designation seems rather arbitrary and niche...if there's a logical source/dest to be found in the document, being artifacts common to all network events they ought to always be made available under those terms.

[ruflin]

No strong opinions here. I removed the beta2 label as this will be a documentation change and not a change in fields, so it can follow later.

[webmat]

Submitted a PR for this: #265. The wording is very much open to discussion :-)