This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. Apologies for missing the last call deadline; however I hope the input is useful. This document is basically ready; some issues and questions for the WG below. General Considerations, Data Channel Design ------------------------------------------------ On its own this document is okay from a transport considerations standpoint: the data channel does not have to operate in a degraded environment (i.e.,. on an interface under attack) and makes perfectly reasonable use of RESTCONF. The companion signal channel document will require (much) more careful attention from the transport directorate. Please pay attention to whatever your SECDIR review says anything about the use of TLS client authentication (as specified with mutual authentication). I suppose the use of mutual auth was inherited from RESTCONF, though? I'd be curious to know whether other client authentication schemes were considered. The use of cdid as a client rate association token and rate-limiter seems open to misconfiguration or misuse. Is there a concept for protecting against this beyond log-and-detect? Data Model Design -------------------- The target-fqdn element in the alias definition seems prone to cause confusing results if used naïvely (indeed the document itself points this out). On the other hand, in dynamic service environments it is quite useful for an alias to refer to a name as opposed to a set of addresses. Did the working group consider including some further context for the resoultion of these into IP addresses (for example, by providing a link to a DoT/DoH server to update the resolutions periodically)? If not, perhaps some text about doing this out of band would be helpful. Thanks, cheers, Brian