Subject: [yang-doctors] Yangdoctors last call review of draft-ietf-dots-signal-call-home-11

From: Ebben Aries via Datatracker <[email-masked]>
Date: Tue, 01 Dec 2020 18:15:00 -0800

Reviewer: Ebben Aries
Review result: Almost Ready

1 module in this draft:
- [email-masked]

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.

---

From: <[email-masked]>
Date: Wed, 2 Dec 2020 08:24:32 +0000

Hi Ebben, 

Many thanks for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Ebben Aries via Datatracker [mailto:[email-masked]]
> Envoyé : mercredi 2 décembre 2020 03:15
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; draft-ietf-dots-signal-call-
> [email-masked]
> Objet : Yangdoctors last call review of draft-ietf-dots-signal-call-
> home-11
> 
> Reviewer: Ebben Aries

[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).  

>   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
>   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

[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. 

>   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

[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.  

>   type.  Should this rather be of type 'inet:domain-name'?

[Med] Good catch. Will be fixed. 

  Looking
> at other

[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.