Added interface fields #689
Conversation
Added basic interface fields
There was a problem hiding this comment.
I've added comments on many fields.
But before addressing them, I'd like to discuss whether we need all of these fields at all. I think the fields .id and .name and maybe .description make sense. I could totally see them being added to network events as meta-data.
However I'm not convinced about the other fields. They sound like the kind of fields we would populate when performing an inventory of host or network device capabilities. Or do you think they should be populated as additional meta-data as well?
If they're meant solely for inventory purposes, I think we should hold off a bit on these fields and remove them for now.
ECS so far has been focused on events, not inventories. As you know, I think it makes sense to stretch ECS towards inventories as well eventually. But we're not there yet, and I'd like to reduce confusion and focus on events as much as possible until we're ready to address inventories.
|
|
||
| - name: enabled | ||
| level: extended | ||
| type: keyword |
There was a problem hiding this comment.
| type: keyword | |
| type: boolean |
| type: keyword | ||
| example: connected | ||
| description: > | ||
| Interface logical connection state as reported by the system. Possible values are connected, not-connected, error-disabled |
There was a problem hiding this comment.
Where do these 3 value come from? Are they a set of industry standard values, or can we improve the wording?
|
|
||
| - name: speed | ||
| level: extended | ||
| type: keyword |
There was a problem hiding this comment.
| type: keyword | |
| type: long |
|
|
||
| - name: negotiation | ||
| level: extended | ||
| type: keyword |
There was a problem hiding this comment.
| type: keyword | |
| type: boolean |
|
|
||
| - name: bandwidth | ||
| level: extended | ||
| type: keyword |
There was a problem hiding this comment.
| type: keyword | |
| type: long |
| type: keyword | ||
| example: GigabitEthernet0/1 | ||
| description: > | ||
| Optional long interface name as reported by the systen. |
There was a problem hiding this comment.
| Optional long interface name as reported by the systen. | |
| Optional long interface name as reported by the system. |
| top_level: true | ||
| expected: | ||
| - agent | ||
| - client | ||
| - host | ||
| - observer | ||
| - server |
There was a problem hiding this comment.
I'd like to understand the reuse, in all scenarios.
- An agent is software running on a host, where it collects observations about the host. I think we should remove "agent" from the list.
- Using
interface.*at the top level (top_level: true) means what? Should we make this false, to signal that it's only meant to be used nested? - A host or observer can have multiple network interfaces. When nested there, is the field set meant to describe only the "relevant" interface for a network transmission, or do you want this to enable tracking all interfaces on the host? (an array of objects)
- client/server: they both make sense 👍
- source/destination: shouldn't we add those as well? In ECS we're trying to establish source/destination as the minimum baseline for capturing network traffic. When it's important and possible to determine, we encourage mapping to client/server as well, to add semantic meaning. So in my mind, we should have it nested under both as well.
|
refactored basics into pr #752. (skipped inventory type fields for now) |
|
@dainperkins Can we close this one as well, then? |
|
yes we can... |
Added basic interface fields