Semantic convention for Multicast and Broadcast IP is missing

[sirzooro]

What are you trying to achieve?
My application uses multicast IP communication. On sender side I can report target multicast IP address in existing net.peer.ip attribute. However on receiver side I have two IP addresses: sender IP and multicast IP address (latter one obtained using IP_PKTINFO socket option). Sender IP can be reported in net.peer.ip, but there is no separate attribute which could be used for multicast IP.

Similar issue exists for UDP Broadcast, where packets are sent to broadcast addresses.

Please define new attibute(s) for this purpose, e.g. net.multicast.ip and net.broadcast.ip. Alternatively you can define one generic one net.group.ip. Please also clarify how sender should report target IP address - by using old net.peer.ip attribute only, new one only or both.

[sirzooro]

General semantic conventions were updated in the meantime and new set of net.sock.* attributes were added. It looks that receiver of packet could use net.sock.peer.addr to store sender address, and net.peer.addr to store multicast/broadcast address. At this moment net.peer.addr is not defined. Please add it.

[ocelotl]

I asked Claude to review this issue and Claude suggests it be closed with this explanation:

Purely a semantic-convention request for net.* attributes (net.multicast.ip / net.broadcast.ip / net.group.ip). All semantic conventions moved to open-telemetry/semantic-conventions, where the referenced net.* attributes were since superseded by network.*; this gap belongs in that repo (no such issue exists there yet). Cross-referenced #2607 (closed/completed) only addressed net.peer vs net.sock scoping, not multicast/broadcast.

To guard against a mistaken suggestion, Claude then independently re-verified this conclusion:

Pure semantic-convention request for multicast/broadcast IP attributes; all semconv moved to open-telemetry/semantic-conventions (net.* superseded by network.*), so this belongs there, not in the spec repo. The ask is still substantively unmet, but wrong venue = moved-repo. Searches of semantic-conventions confirmed no equivalent issue exists.

Claude evaluated this issue with medium confidence that it can be closed.

Claude has classified this issue as belonging in another repository.

The intention of this comment is to make it easier for a human being to review this issue before making a decision.

[svrnm]

Closing this issue, it was discussed, no conclusion found and stalled. If you think this topic should be discussed again, reopen or raise a new issue.