Reviewer: Ebben Aries Review result: Almost Ready 1 module in this draft: - ietf-dots-call-home@xxxxxxxxxxxxxxx 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
