Subject: Re: [Dots] New Version Notification - draft-ietf-dots-signal-call-home-10.txt

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 27 Oct 2020 09:58:22 -0700

On Thu, Oct 22, 2020 at 06:00:39AM -0700, [email-masked] wrote:
> 
> A new version (-10) has been submitted for draft-ietf-dots-signal-call-home:
> https://www.ietf.org/archive/id/draft-ietf-dots-signal-call-home-10.txt
> 
> Sub state has been changed to AD Followup from Revised ID Needed
> 
> 
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dots-signal-call-home/
> 
> Diff from previous version:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-10

Thanks for the updates; this all looks quite good.  I have just a few
editorial remarks on the new text (below), and the only issue keeping me
from issuing an IETF LC is the IPR question
(https://datatracker.ietf.org/ipr/3318/ appears in the IPR search for this
document).  I'm happy to do so if we have broad WG consensus to proceed
even in light of the IPR report (or if the IPR report gets updated), but I
don't remember anyone other than the authors replying on that topic yet.

-Ben

Section 5.3.1

   The 'source-prefix' parameter is a mandatory attribute when the
   attack traffic information is signaled by a Call Home DOTS client
   (i.e., the Call Home scenario depicted in Figure 7). 'target-prefix'
   attribute MUST be included in the mitigation request signaling the
   attack information to a Call Home DOTS server.  The 'target-uri' or

nit: Start the second sentence with "The" (just like the third sentence).

   If the Call Home DOTS server rejects the mitigation request without
   waiting for a consent from the Call Home DOTS server domain
   administrator, the 'conflict-cause' set to '4' is returned in 4.09
   (Conflict) sent back to the Call Home DOTS client.   

   If the attack traffic information is identified by the Call Home DOTS
   server or the Call Home DOTS server domain administrator as
   legitimate traffic, the mitigation request is rejected with a 4.09
   (Conflict) or a notification message with the 'conflict-clause'
   (Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]) set to the following
   new value:

These two paragraphs seem to have a decent amount of overlap, and the
first one also uses the conflict-cause value '4' before it's introduced
by the second paragraph.  I think we should be able to consolidate the
two paragraphs.

Section 5.3.2

   Figure 10 depictes an example of a network provider that hosts a Call
   Home DOTS client and deploys a Carrier Grade NAT (CGN) between the
   DOTS client domain and DOTS server domain.  In such case,

nit: "cases" plural.

---

From: tirumal reddy <[email-masked]>
Date: Wed, 28 Oct 2020 10:32:23 +0530

Hi Ben,

Please see inline

> don't remember anyone other than the authors replying on that topic yet.

The IPR declaration will be updated to option "c) Reasonable and
Non-Discriminatory License to All Implementers with Possible Royalty/Fee"
this week.

Cheers,
-Tiru

---

From: <[email-masked]>
Date: Wed, 28 Oct 2020 07:01:54 +0000

Hi Ben, all, 

A new version that fixes the points you raised is available online. 

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-11 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk [mailto:[email-masked]]
> Envoyé : mardi 27 octobre 2020 17:58
> À : [email-masked]
> Cc : [email-masked]
> Objet : Re: New Version Notification - draft-ietf-dots-signal-call-
> home-10.txt
> 
> > https://www.ietf.org/archive/id/draft-ietf-dots-signal-call-home-
> 10.tx
> > t
> >
> Thanks for the updates; this all looks quite good.  I have just a
> few editorial remarks on the new text (below), and the only issue
> keeping me from issuing an IETF LC is the IPR question
> (https://datatracker.ietf.org/ipr/3318/ appears in the IPR search
> for this document).  I'm happy to do so if we have broad WG
> consensus to proceed even in light of the IPR report (or if the IPR
> report gets updated), but I don't remember anyone other than the
> authors replying on that topic yet.
> 
> -Ben
> 
> 
> Section 5.3.1
> 
> These two paragraphs seem to have a decent amount of overlap, and
> the first one also uses the conflict-cause value '4' before it's
> introduced by the second paragraph.  I think we should be able to
> consolidate the two paragraphs.
> 
> Section 5.3.2
> 

_________________________________________________________________________________________________________________________

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.