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? 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. 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. Best wishes, Tim -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
