Subject: [Dots] Barry Leiba's No Objection on draft-ietf-dots-server-discovery-14: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Wed, 28 Oct 2020 14:40:15 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-dots-server-discovery-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Overall discussion question (but not at blocking DISCUSS level):
Does it make sense for DOTS clients to proactively discover appropriate DOTS
servers *before* a DDoS attack hits, to avoid the issue of discovery being
blocked by the attack that the client is trying to report?  Should this
document discuss that?

Other comments, all minor:

— Section 1 —

   This approach allows to
   reduce the impact of an attack and leads to more efficient defensive

Nit: “allows to” isn’t proper English, as it lacks a subject: “allows <some
entity> to”.  I think the subject you want here is DOTS, so maybe this works?:

NEW
   With this approach, DOTS can
   reduce the impact of an attack and lead to more efficient defensive
END

— Section 2 —

   The reader should be familiar with the terms defined in [RFC8811],
   [RFC3958], and [I-D.ietf-dots-signal-call-home].

I think this makes RFC 8811 and draft-ietf-dots-signal-call-home normative
references, as they define require terminology.  Certainly 8811 is normative in
any case, as the architecture needs to be understood.

— Section 3 —

   It is tempting to specify one single discovery mechanism for DOTS.
   Nevertheless, the analysis of the various use cases sketched in

Nit: Ignore this if you’re happy with the text as it is, but I would remove the
first sentence and just start this as “Analysis of the various use cases…”.

Please expand “CPE” on first use — especially as it’s confusingly and
contradictorily described as “Customer Premises Equipment” (provided by the
operator) and “Customer Provided Equipment” (not provided by the operator), so
we need to know which you mean.

— Section 4 —

   These may be
   specified either as IP addresses or the DNS name of a DOTS
   server.

The first half of the sentence is plural and the second singular.  Should both
be plural, “…either as IP addresses or DNS names of DOTS servers.” ?  If it’s
intentional that it can be multiple IP addresses but only one DNS name, it
would be better to be more explicit about that.

— Section 5 —

   and server while accommodating for the current best practices

Nit: not “accommodating for”: just “accommodating”.

— Section 5.1.1 —

   o  dots-agent-name: A fully qualified domain name of the peer DOTS
      agent.  This field is formatted as specified in Section 10 of
      [RFC8415].

As all Section 10 of 8415 does is send us to Section 3.1 of 1035, why not just
point to the latter directly, rather than making the reader follow an extra
reference?

And it wouldn’t be bad to append to the “an example” sentence as follows:

NEW
   An example of the dots-agent-name encoding is shown in Figure 4.
   This example conveys the FQDN "dots.example.com.”, and the
   resulting Option-length field is 18.
END

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 28 Oct 2020 16:47:46 -0700

Hi Barry,

And here I had assumed that this was so obvious so as to not need
mentioning.  Apparently not; let's go ahead and mention this explicitly.

> Other comments, all minor:

Thanks for those.

-Ben

---

From: <[email-masked]>
Date: Thu, 29 Oct 2020 06:55:20 +0000

Hi Barry, 

Thanks you for the comments.

I updated the draft to address the review. You can track the changes at: https://tinyurl.com/dots-discovery-iesg. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Barry Leiba via Datatracker [mailto:[email-masked]]
> Envoyé : mercredi 28 octobre 2020 22:40
> À : The IESG <[email-masked]>
> Cc : [email-masked]; dots-
> [email-masked]; [email-masked]; Valery Smyslov <[email-masked]>;
> [email-masked]
> Objet : Barry Leiba's No Objection on draft-ietf-dots-server-
> discovery-14: (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> 
> Does it make sense for DOTS clients to proactively discover
> appropriate DOTS servers *before* a DDoS attack hits, to avoid the
> issue of discovery being blocked by the attack that the client is
> trying to report?  Should this document discuss that?
> 

[Med] This is already covered in the text as the discovery is triggered by new network attachments (which includes bootstrapping). The discovery information is thus available independently of the attack conditions. 

>    reduce the impact of an attack and lead to more efficient
> defensive END
> 

[Med] Fixed. Thanks.

> I think this makes RFC 8811 and draft-ietf-dots-signal-call-home
> normative references, as they define require terminology.  Certainly
> 8811 is normative in any case, as the architecture needs to be
> understood.
> 

[Med] As we don't deal with how DOTS sessions are handled nor we interfere with the internal DOTS signalling machinery, we don't cite 8811 (but also 8782, 8783) as normative ones. Of course, having the required background is useful but implementing the discovery process does not require these pieces.

I understand the references in the terminology section may suggest that knowledge is required. To avoid that, the terminology section is updated to list the terms used in the document. 

> Nit: Ignore this if you’re happy with the text as it is, but I would
> remove the first sentence and just start this as “Analysis of the
> various use cases…”.

[Med] Went with your proposal. 

> 
> Please expand “CPE” on first use — especially as it’s confusingly
> and contradictorily described as “Customer Premises Equipment”
> (provided by the
> operator) and “Customer Provided Equipment” (not provided by the
> operator), so we need to know which you mean.
> 

[Med] Done. 

> The first half of the sentence is plural and the second singular.
> Should both be plural, “…either as IP addresses or DNS names of DOTS
> servers.” ?  If it’s intentional that it can be multiple IP
> addresses but only one DNS name,

[Med] I confirm.

 it would be better to be more
> explicit about that.

[Med] Changed to "a list of IP addresses" 

> Nit: not “accommodating for”: just “accommodating”.

[Med] Fixed. 

> As all Section 10 of 8415 does is send us to Section 3.1 of 1035,
> why not just point to the latter directly, rather than making the
> reader follow an extra reference?
> 

[Med] Agree. Done. 

_________________________________________________________________________________________________________________________

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.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 29 Oct 2020 09:08:00 -0400

Hi, Med, and many thanks for making the changes and addressing my comments.

> [Med] This is already covered in the text as the discovery is triggered by new network
> attachments (which includes bootstrapping). The discovery information is thus available
> independently of the attack conditions.

Indeed, so the list at the end of Section 4 implies, and that ought to
be enough.

Still, may I ask for one more minor change, which I think makes it
just a tad more explicit?  In the lead-in to the list:

OLD
   The discovery method is reiterated by a DOTS agent upon the following
   events:

NEW
   The discovery method is performed upon attachment to a network, and is
   reiterated by a DOTS agent upon the following events:

END

> I understand the references in the terminology section may suggest that knowledge is
> required. To avoid that, the terminology section is updated to list the terms used in the
> document.

I looked at the update, and that works for me; thanks!

Barry

---

From: <[email-masked]>
Date: Thu, 29 Oct 2020 13:29:55 +0000

Re-,

Sure. Please check the update at: https://tinyurl.com/dots-discovery-iesg  

Thank you. 

Cheers,
Med

> De : Barry Leiba [mailto:[email-masked]]
> Envoyé : jeudi 29 octobre 2020 14:08
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : The IESG <[email-masked]>; draft-ietf-dots-server-
> [email-masked]; [email-masked]; [email-masked]; Valery
> Smyslov <[email-masked]>
> Objet : Re: Barry Leiba's No Objection on draft-ietf-dots-server-
> > [Med] This is already covered in the text as the discovery is
> > triggered by new network attachments (which includes
> bootstrapping).
> > The discovery information is thus available independently of the
> attack conditions.
> 
> Indeed, so the list at the end of Section 4 implies, and that ought
> to be enough.
> 
> > I understand the references in the terminology section may suggest
> > that knowledge is required. To avoid that, the terminology section
> is
> > updated to list the terms used in the document.
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 29 Oct 2020 10:16:03 -0400

Perfect; thanks again, Med.

Barry