Hi Gyan, thanks Mahesh for the explanation, it’s exactly right. We don’t update the HTTP spec at all, we borrow its concepts and apply them to netconf. The w3c trace context headers are sent as XML attributes for NETCONF. I don’t understand the minor issue you list Gyan. What about port 830, SOAP 832 & 833? Regardless if NETCONF is over SSH, TLS, SOAP (in turn over BEEP or HTTPS), it still sends XML encoded RPCs and the trace context XML attributes are encoded in there. I don’t think we need to explicitly mention or deal with the details of the lower layer transports!? The abstract changes read very similarly to me, do you really think this warrants another spin at this point? Kind regards, Kristian. > On 29 Oct 2024, at 19:30, Mahesh Jethanandani <mjethanandani@xxxxxxxxx> wrote: > > [Speaking as a contributor] > > Hi Gyan, > >> On Oct 28, 2024, at 12:10 AM, Gyan Mishra via Datatracker <noreply@xxxxxxxx> wrote: >> >> Reviewer: Gyan Mishra >> Review result: Not Ready >> >> Summary: >> This document defines how to propagate trace context information across the >> Network Configuration Protocol (NETCONF), that enables distributed tracing >> scenarios. It is an adaption of the HTTP-based W3C specification. >> >> I reviewed draft revision -01 and the draft is almost ready for publication but >> has some minor issue below. >> >> Major issue: >> None >> >> Minor issues: >> >> Network Configuration Protocol (NETCONF) uses the Secure Shell (SSH) transport >> layer as its default mechanism using default port 830, SOAP port 833 or HTTP >> port 832. >> >> Abstract recommended change >> Old: >> >> This document defines how to propagate trace context information across the >> Network Configuration Protocol (NETCONF), that enables distributed tracing >> scenarios. It is an adaption of the HTTP-based W3C specification.¶ >> >> New: >> >> This document defines how to propagate trace context information using Network >> Configuration Protocol (NETCONF) push in order to enable distributed tracing >> scenarios. It is an adaption of the HTTP-based W3C specification. >> >> W3C owns the HTTP specification so how is this draft changing the W3C http >> specification? >> >> Netconf can use http but it’s not changing the http specification correct ? >> >> In the introduction see this paragraph >> >> The W3C has defined two HTTP headers for context propagation that are useful in >> use case scenarios of distributed systems like the ones defined in [RFC8309]. >> This document defines an extension to the NETCONF protocol to add the same >> concepts and enable trace context propagation over NETCONF. >> >> So we are defining an extension to Netconf protocols in section 2 related to >> W3Cs HTTP specification so in that way is this draft actually updating HTTP >> specification as well for the two new header types? > > I do not think the document is updating the HTTP specification. All it says that the <rpc> operation in NETCONF uses the HTTP like symantics to send information to the other end. For example: > > <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1" > xmlns:w3ctc="urn:ietf:params:xml:ns:netconf:w3ctc:1.0" > w3ctc:traceparent= > "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01"> > <get-config/> > </rpc> > > The above operation is a NETCONF operation. It is using HTTP like trace context header format [1], but in no way is changing the HTTP protocol. HTH. > > Cheers. > >> >> Nits: >> None > > [1] https://www.w3.org/TR/trace-context/ > > Mahesh Jethanandani > mjethanandani@xxxxxxxxx > > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
