gnsi.accounting.SessionInfo is lacking in various ways about gnsi HOT 3 CLOSED

I agree that we shouldn't have mixed system-address and local-port :(
It seems reasonable to add 'local-address', and require that both system-address (probably loopback-like) and local-address both be filled in, in the message.

Comments for the ports/protocols seem reasonable, yes.

As to channel-id, I was actually thinking (I believe) that this was the gRPC channel id:

https://grpc.io/docs/what-is-grpc/core-concepts/#channels

upon re-reading that, though, it looks like 'channel' is actually the whole of the connection :( not the sub path/channel I was expecting, and which I think does, actually, exist. So, removing channel-id seems safe.

from gnsi.

OK. #105 addresses the first two bits. I guessed at the intended meaning of the layer4_proto field.

from gnsi.

I am struggling with channel_id. It seems to be nonsense for gRPC, as a gRPC channel is not about multiplexing. gRPC does not appear to have any multiplexing abilities per-se; it is synchronous though.

For ssh, it would make sense (see https://datatracker.ietf.org/doc/html/rfc4254#section-5.1), but I can not think of reason that it would be relevant, except if one wanted to correlate accounting for each channel this could be the "receiver channel" from the struct mentioned in the rfc.

from gnsi.