Hi Ebben, Many thanks for the comments. Please see inline. Cheers, Med > -----Message d'origine----- > De : Ebben Aries via Datatracker [mailto:noreply@xxxxxxxx] > Envoyé : mercredi 2 décembre 2020 03:15 > À : yang-doctors@xxxxxxxx > Cc : last-call@xxxxxxxx; dots@xxxxxxxx; draft-ietf-dots-signal-call- > home.all@xxxxxxxx > Objet : Yangdoctors last call review of draft-ietf-dots-signal-call- > home-11 > > 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)? [Med] We used to have the same terminology in previous versions but reviewers were confused about that, which is a fair comment BTW for the following reasons: * the differences about how the sessions are established and maintained (heartbeats). * the base reference architecture is different from the on in RFC8811. * the call home can be used with or without the base signal channel. * the checks done by a "DOTS client/server" in the base spec are not the same as those in the call home. To address these comments, we went with the current terminology in the draft. This terminology has the advantage to help to better articulate the co-existence considerations (see Section 4). > > - 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? [Med] The old session is closed and a new one is established with the alternate call home client. 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? [Med] Yes. This is covered by this text: "The processing of the TTL is defined in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]." + Section 4.6 of rfc8782-bis says the following: This fallback mechanism is triggered immediately upon expiry of the TTL, except when a DDoS attack is active. 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. [Med] Yes. One of the reasons for this design is discussed in Section 4.6 of [I-D.ietf-dots-rfc8782-bis]: During a DDoS attack, the DNS server may be the target of another DDoS attack, the alternate DOTS server's IP addresses conveyed in the 5.03 response help the DOTS client skip the DNS lookup of the alternate DOTS server, at the cost of trusting the first DOTS server to provide accurate information. > > - 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'. [Med] I confirm. This is explicitly mentioned in the draft: "This is an optional attribute for the base DOTS signal channel operations." 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? [Med] This was on purpose. RFC8782 was scoped to convey the minimal required information to seek for mitigation. We don't change that scope in 8782-bis. > > > 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'? [Med] Good catch. Will be fixed. 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. [Med] We are using inet:domain-name for target-fqdn but not alt-server. Will fix that as well. > > 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. > [Med] Thank you for your careful review. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
