Santosh Cheler

The ask is to mark the instrumentations stable only from a telemetry perspective, as defined [here](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/telemetry-stability.md). Can you provide some info on why this sounds complex? Do any of the...

Yes, I will take up the spec for document-load/xhr/fetch in RUM SIG. Thanks for the other info.

> The "more" correct approach that the addSpanNetworkEvents SHOULD be doing is creating a SINGLE event and having the available values as Attributes. I support this proposal. The events can...

> Isn't it a bit premature to claim spans with events to hold timing information over SpanEvents when there's 0 specification changes or OTEPs actually saying that yes it should...

This looks helpful i support this change. Is there any process currently for introducing breaking changes? For example, this change could be based on an InstrumentationConfig option and you could...

Discussed this with @t2t2 and @MSNev today - this feature applies to all browser instrumentations except document-load, and not just xhr and fetch. Given that document-load is the only instrumentation...

@t2t2 on the topic of `push ephemeral resource attributes to reality`, I am wondering if we could make this work in increments. That is, the ephemeral resource attributes could be...

The [spec](https://github.com/open-telemetry/opentelemetry-specification/blob/8ed127a403c59e1baa5203c6cdf472ea21df0332/specification/common/mapping-to-non-otlp.md#instrumentation-scope-attributes) on mapping Instrumentation Scope Attributes to non-OTLP destinations specifies that the scope attributes SHOULD be recorded at the Span/LogRecord level - and there's a section in the scope...

These are not stable for sure. The ask is only to move them into experimental folder since they instrumentations are not for 3rd party libraries.

This is not a strong ask, just something I found confusing as the fetch and xhr instrumentations are in the core repo.