Last Call Review of draft-ietf-dots-signal-call-home-11
review-ietf-dots-signal-call-home-11-yangdoctors-lc-aries-2020-12-01-00

1 module in this draft:
- ietf-dots-call-home@2020-10-15.yang

YANG compiler errors or warnings (pyang 2.4.0, yanglint 1.9.2)
- No compiler errors or warnings however pyang 2.4.0 is currently the only
  compiler verified to emit YANG sx:structure data in tree format.  Instance
  data could not yet easily be validated given the current linters/compilers.

General comments/clarifications on the draft/modules:
------------------------------------------------------
- My first thoughts after reading through the draft is some use of terminology
  that I find confusing or rather need some clarification.  This draft
  reverses the TCP/TLS or DTLS connection initiation but the DOTS roles of
  client/server remain the same.  If that is the case, then I ask why does the
  terminology need to deviate that of the DOTS signal channel terminology to
  make use of 'Call Home DOTS client' and 'Call Home DOTS server' (Starting in
  Section 1.2)?

- Regarding 'redirected-signal' for alternate call home clients.

  What occurs if 'alt-ch-client-record' is populated with a list of IP
  addresses in addition to the mandatory 'alt-ch-client' FQDN?  If DTLS or TLS
  connections are unable to be satisfied to the client after the PUT request,
  is there any sort of fallback when the TTL cache expires?  From what I
  gather, the 'alt-ch-client-record' takes precedence over resolving the
  mandatory FQDN attribute and/or acts like a static host record should both
  be encapsulated in the PUT request.

- Regarding the structure augment of 'source' nodes.  It seems to me (and this
  may be a misinterpretation) that this is not entirely specific to 'call
  home'.  Is there any reason why these nodes do not exist directly in
  rfc8782-bis or can you help clarify why this is specific to this scenario
  only?


Module ietf-dots-call-home:
------------------------------------------------------
- Node 'alt-ch-client' is targeted to represent a FQDN with a loose string
  type.  Should this rather be of type 'inet:domain-name'?  Looking at other
  usage among dots related modeling is mixed between the 2 types for
  representing a FQDN so this comment can also apply to my alternate dots YD
  review.

Overall, from a YANG module/structure standpoint it appears on the right track
for complementing the 'ietf-dots-signal-channel' module and see no major
issues.