Mobile spec additions

[bryce-b]

Follow up of #1669
I updated the yaml files & verified the various make checks pass.

Changes

• adds net.host.carrier.*
• adds net.host.connection_type

Related issues #

#1647 Add semantic convention for describing network connectivity conditions

[bryce-b]

hm, it seems that make markdownlint and make table-check are at odds.

[bryce-b]

I need some assistance resolving this error in the semantic-conventions check. It oddly seems to resolve if a space is arbitrarily added in 7e7a188, but that breaks markdownlint. Is this actually an issue between the yaml spec & the markdown file? How can I view what the tool is generating from the yaml?

[arminru]

Hi @bryce-b!

I need some assistance resolving this error in the semantic-conventions check. It oddly seems to resolve if a space is arbitrarily added in 7e7a188, but that breaks markdownlint. Is this actually an issue between the yaml spec & the markdown file? How can I view what the tool is generating from the yaml?

The tools' output is done right in-place if you run it as advised in the README, so you should see it right away and commit it together with the YAML change. You'll also have to re-run the tool now anyway since ba64493 introduced wording that is actually a bit different from what the Markdown generator would add, then it should pass again.

[bryce-b]

I've already made this comment, but it's in an outdated review comment chain, so I'm re-adding it for visibility.

I deleted all the table markdown I manually added, and let the table-generation add them. (7af45c0) It looks much better, but it seems like the table-generation is adding an additional space at line 64 that is making markdownlint unhappy.

./specification/trace/semantic_conventions/span-general.md:64 MD012/no-multiple-blanks Multiple consecutive blank lines [Expected: 1; Actual: 2]

[Oberon00]

Unfortunately, this looks like a bug in the semantic convention generator, when more than one enum is added and there is a (foot)note in one. 😞

I created open-telemetry/build-tools#47

[bryce-b]

@Oberon00 phew! I'm glad it wasn't me, haha

[maxgolov]

I think, as a minimum, the concepts that need to be gathered are:

• network cost
• device id
• manufacturer: make, model
• OS arch type
• possibly a vector of device features: hasKeyboard, hasMouse, hasLTE or WiFi only, hasPhone-alike characteristics, e.g. Dialer which may be a feature even on device that has WiFi only.
• many (most) devices in developing nations are dual-SIM ; you have to account for the fact that network is a vector, not a single value
• for any field added - there has to be a separate column, whether this field potentially needs a privacy review. For all of these privacy-sensitive fields - these should be definitely all marked as optional. But mere fact of collecting provider name and network id, deserves a separate asterisk / notion of a potential field that needs a privacy review.

[jkwatson]

I think, as a minimum, the concepts that need to be gathered are:

• network cost
• device id
• manufacturer: make, model
• OS arch type
• possibly a vector of device features: hasKeyboard, hasMouse, hasLTE or WiFi only, hasPhone-alike characteristics, e.g. Dialer which may be a feature even on device that has WiFi only.
• many (most) devices in developing nations are dual-SIM ; you have to account for the fact that network is a vector, not a single value
• for any field added - there has to be a separate column, whether this field potentially needs a privacy review. For all of these privacy-sensitive fields - these should be definitely all marked as optional. But mere fact of collecting provider name and network id, deserves a separate asterisk / notion of a potential field that needs a privacy review.

I think it's ok to start simple and just pick one thing to specify, rather than trying to boil the ocean and specify every possible thing in a single PR. Let's keep this PR focussed on just describing the network that a mobile device is using for data communications, if that's ok.

[jmacd]

@maxgolov I read your concerns above and want to acknowledge them. I believe I am correct in saying that most of the issues you raised are about instrumentation, not semantic conventions. The users of these semantic conventions will have to pay attention to privacy, for example. I am under the impression that there is a new SIG that will form for client-side instrumentation, which at this time exists as a discussion in the #otel-client-side-telemetry room of the CNCF slack.

[jmacd]

This has only one approval since net.host.connection.subtype changed. @open-telemetry/specs-approvers please take another look.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[nachoBonafonte]

This is a needed PR for mobile tracking

[bryce-b]

@carlosalberto could you re-approve, since there were a few changes since your original approval?

[bryce-b]

@jmacd how are we looking for merge?

[jmacd]

Thanks @bryce-b!