[netconf] Re: Opsdir last call review of draft-ietf-netconf-restconf-trace-ctx-headers-04

[Per Andersson <[e-mail]>]

(Add [e-mail] for record.)

Hi Tim,

Thanks for your clarification!


--
Per


On Tue, Aug 18, 2026 at 11:13 AM Tim Chown <[e-mail]> wrote:
>
> Hi,
>
> Sorry, it took me a while to remember this one given it’s so long ago, but from re-reading and the comments below then yes, I’m happy.
>
> With the explanation below, I think it’s the W3C spec that should have said "MUST propagate the traceparent and tracestate (when present) headers and guarantee traces are not broken”, i.e., adding “(when present)” for clarity, but that ship has already sailed.
>
> Tim
>
> On 15/08/2026, 18:25, "Per Andersson" <[e-mail]> wrote:
>
> Hi Tim,
>
> Does the updated document address your concerns?
>
>
> --
> Per
>
>
> On Sat, Mar 14, 2026 at 4:04 PM Roque Gagliano (rogaglia)
> <[e-mail]> wrote:
> >
> > Hi Tim,
> >
> > Looks like this message went through the cracks.
> >
> > Please see my comments below which we are planning to add in next release.
> >
> > Roque
> >
> > —
> >
> > Roque Gagliano
> >
> > Automation Principal Solutions Architect
> >
> > [phone]
> >
> > From: Per Andersson <[e-mail]>
> > Date: Thursday, 8 May 2025 at 11:57
> > To: Tim Chown <[e-mail]>
> > Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
> > Subject: Re: Opsdir last call review of draft-ietf-netconf-restconf-trace-ctx-headers-04
> >
> > Dear Authors,
> >
> > I can't find if Tim's comments are addressed in the draft or discussed on
> > the mailing list.
> >
> > Can you please address Tim's comments.
> >
> >
> > --
> > Per, NETCONF co-chair
> >
> >
> > On Mon, Jan 20, 2025 at 11:32 AM Tim Chown via Datatracker
> > <[e-mail]> wrote:
> > >
> > > Reviewer: Tim Chown
> > > Review result: Not Ready
> > >
> > > Hi,
> > >
> > > I have reviewed this document as part of the Operational directorate's ongoing
> > > effort to review all IETF documents being processed by the IESG. These comments
> > > were written with the intent of improving the operational aspects of the IETF
> > > drafts. Comments that are not addressed in last call may be included in AD
> > > reviews during the IESG review.  Document editors and WG chairs should treat
> > > these comments just like any other last call comments.
> > >
> > > The draft defines a RESTCONF extension to support Trace Context propagation as
> > > defined by the W3C Trace Context Recommendation.
> > >
> > > The document is short, mainly pointing to required support from the W3C spec in
> > > the RESTCONF extension.
> > >
> > > I'm not an expert in the RESTCONF area. I have read the cited W3C documents and
> > > in doing so I'm led to a 'Not Ready' conclusion for my review. While my
> > > assessment may be from a relatively naive position, I feel the document should
> > > clarify the points below before progressing. The proposed RESTCONF extension
> > > may be fine, but the rationale could be clearer given the differences I see to
> > > the W3C spec.
> > >
> > > There are two issues:
> > >
> > > 1.
> > >
> > > The W3C spec at https://www.w3.org/TR/trace-context/ (and
> > > https://www.w3.org/TR/2021/REC-trace-context-1-20211123/ which is cited by the
> > > draft) in Section 2.3 states tracing tools "MUST propagate the traceparent and
> > > tracestate headers and guarantee traces are not broken. This behavior is also
> > > referred to as forwarding a trace."
> > >
> > > But the text here says in section 2 that a RESTCONF server only SHOULD support
> > > the tracestate header. I would assume there has been discussion of this
> > > different requirement between the W3C spec and the draft RFC, but I don't see
> > > text in the draft. If people come to this doc familiar with the W3C spec they
> > > may wonder why there is a difference here.
> > >
> > > As above, there may be a perfectly good reason that they differ, but I don't
> > > see it explained. The abstract of the draft says the draft is written to
> > > support Trace Context as defined by the W3C, but this is a little different?
> >
> > (Roque)  The traceparent header is mandatory but the tracestate header is optional (also mentioned in section 2.3 of the W3C document). What is mandatory is to “propagate” received traces. We address this propagation requirement when we state in section 2.4: "A RESTCONF server SHOULD follow the "Processing Model for Working with Trace Context" as specified in {{W3C-Trace-Context}}.” As supporting the tracestate is optional, we will update the doc changing SHOULD by MAY, which is what we are using in the NETCONF document.
> >
> > >
> > > 2.
> > >
> > > The W3C spec in Section 2.3 also says that tracing tools "CAN also choose to
> > > participate in a trace by modifying the traceparent header and relevant parts
> > > of the tracestate header containing their proprietary information. This is also
> > > referred to as participating in a trace."
> > >
> > > This isn't mentioned in the draft. Is this something that would never be
> > > required, or might it follow in a later RFC, or is it just taken as a given (as
> > > a "MAY" in RFC terms)?  Perhaps some text on this would be useful, to clarify.
> >
> > (Roque) I aded the following text: "When interacting with these headers, the RESTCONF server follow the specifications of section 2.3 in {{W3C-Trace-Context}}. A detailed processing model example is also provided in the document."
> >
> > >
> > > Other comments:
> > >
> > > In reading some of the W3C text this also seemed to state that the traceparent
> > > headers are portable while the tracestate headers are vendor-specific. This may
> > > be worth repeating in the draft.
> >
> > (Roque) Added the following in the introduction section: "While the traceparent header is portable and mandatory, the tracestate header is optional and meant to transport vendor-specific data presented by a set of key/value pairs."
> >
> > >
> > > Best wishes,
> > > Tim
> > >
> > >
> > >