Thanks for this. I have the same nit as was with draft-ietf-netconf-netconf-client-server.

Thank you to Daniel Migault for the secdir review.

Section 4.1, 4.2, References:  Why is SSH mentioned?  There are no configurations for SSH in the body of the draft.  Consider removing it from the SC and references.

Section 4.1 and 4.2, para 2:  Please replace the last sentence with "The YANG-based management protocols have to use a secure transport layer such as SSH [RFC4252], TLS [RFC8446], or QUIC [RFC9000].  The YANG-based management protocols also have to use mutual authentication."  [and if SSH is removed, then remove it here too.]

Section 4:  While RFC6241 doesn't reference BCP195 (because it predated it), RFC8040 does.  Those statements need to be updated to include RFC9523 and BCP195. Perhaps a statement like this: 'Implementations SHOULD also refer to [BCP195] for additional details.'

Consider moving/replicating this statement earlier in the document:

"Note that RESTCONF requires HTTPS, the HTTP option is provided to support cases where a TLS-terminator is deployed in front of the RESTCONF-client."

I had this question during initial review and was pleased to find the answer clearly stated, but it might be helpful to flag it for readers up front. It might also deserve mention in the Security Considerations section.

Hi Kent, 

Thank you for the perseverance to push this specification forward.

Except the factorization comment among TLS/TCP/SSH, almost all other comments I made for draft-ietf-netconf-netconf-client-server apply here as well. I'm not repeating those here, but I trust you will align the changes in both documents. 

I found there are many items that are repeated here and draft-ietf-netconf-netconf-client-server, defining those once and reuse them would be a cleaner design.

Cheers,
Med

Thank you to Linda Dunbar for the GENART review.

Thanks to Mahesh for checking the source of the YANG catalog error.

# Éric Vyncke, INT AD, comments for draft-ietf-netconf-restconf-client-server-42
CC @evyncke

Thank you for the work put into this document.

Please find below one addressed DISCUSS points (kept for archive), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Qiufang Ma for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


## DISCUSS (for archive no more blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics:

### YANGCATALOG error

Probably a datatracker/YCO bug combined with my lack of YANG know-how, but the datatrack exhibits `1 errors, 0 warnings` and it seems to me that 'max' is not defined in:
```
  leaf max-wait {
            type uint16 {
              range "1..max";
            }
        ...
```

Happy to stand corrected :-)

## COMMENTS (non-blocking and still to be addressed probably)

### Section 1.1

s/This document presents one or more YANG modules/This document presents *two** YANG modules/

### Section 2.3

Possibly again for my lack of YANG expertise but this I-D has a normative reference to [I-D.ietf-netconf-tls-client-server] but I do not see any related import in the YANG module.

Same cause probably as I raised my eyebrow when reading `feature foo` and `if-feature "foo and not foo";`, probably time to add a 'false' constant in YANG ;-)