Last Call Review of draft-ietf-netconf-trace-ctx-extension-02
review-ietf-netconf-trace-ctx-extension-02-yangdoctors-lc-liu-2024-11-10-00

This is a review of the YANG modules in
draft-ietf-netconf-trace-ctx-extension-02.

1) Even though the module ietf-trace-context is simple, I still find a tree
diagram beneficial. Can you please consider including one such as the following?

module: ietf-trace-context

  structure trace-context-error-info:
    +-- trace-context-error-info
       +-- meta-name?    string
       +-- meta-value?   string
       +-- error-type?   meta-error-type

2) Sec 2.1. serves as a data instance example.  In the <error-info>,  there is
<ietf-trace-context:trace-context-error-info>, which happens to match either
the structure name or the container name. According to RFC 8791, both seem to
be parts of the data instance (as shown in Sec. A.5.). Is it intended to have
the duplicated structure and container?

3) Is it intended to have all leaves in trace-context-error-info optional with
no default values? What would an empty structure or container indicate?

4) Modules ietf-trace-ctx-traceparent-1.0 and ietf-trace-ctx-tracestate-1.0
seem to be used for capabilities only, without any YANG data nodes. It would be
good to have some explicit explanations in the description to say that this is
intentional (as I was expecting some content in the module initially).

5) It is not conventional to have the version number as a part of the module
name, as used by modules ietf-trace-ctx-traceparent-1.0 and
ietf-trace-ctx-tracestate-1.0 (Sec 4.1, 4.8 of RFC 8407).

6) It would be good to have an example YANG Library instance to show how
modules ietf-trace-ctx-traceparent-1.0 and ietf-trace-ctx-tracestate-1.0 are
used. Are they should be parts of config-modules or state-modules?

Thanks,
- Xufeng