Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt

Hi all, 

FYI, a review from Jon is available at: https://github.com/boucadair/draft-dots-telemetry/raw/master/DOTS%20Telemetry%2001-rev%20Jon-res%20Med.docx 

-02 will integrate almost all comments from  Jon. Please find below some points we would like to hear more from the working group:

(1) key value range for telemetry: Jon raised this point "These keys requires 3 bytes - and telemetry information is going to be difficult to fit into a packet.  I appreciate that comprehension-required
Is for numbers less than 0x8000 - perhaps the comprehension-required range is reduced and also has a section higher up so the total of 0x8000 still stands so less bytes can be used here."

   +----------------------+-------+-------+------------+---------------+
   | Parameter Name       | CBOR  | CBOR  | Change     | Specification |
   |                      | Key   | Major | Controller | Document(s)   |
   |                      | Value | Type  |            |               |
   +----------------------+-------+-------+------------+---------------+
   | ietf-dots-signal-cha | 32776 |   5   |    IESG    |   [RFCXXXX]   |
   | nnel:telemetry       |       |       |            |               | 

Med: This is a major one. We need to assess the gain, but it is possible in theory to update our assignment policies and reassign, e.g., 128-255 range to be comprehension-optional (specific for telemetry). This would mean that the telemetry spec will be tagged as updating the base signal channel spec. We need more discussion. 

(2) server-initiated-telemetry: "Having server-initiated-telemetry under max-config-values, but not min-config-values makes no sense to me.  I think it should be under telemetry-config at the level of current-config and possibly removed from current-config as well."

Med: 

A. It is in the max container because setting that value to "false" under that container has a special meaning: the server does not support sending pre-mitigation telemetry. We can put it under min as well but do we have a case where setting it to "true" has a meaning?
B. I do agree that 'server-initiated-telemetry' can be removed from the current configuration because the same functionality is achieved using a GET+Observe but we left it there for the moment as we need to work further the details for subscribing to pre-mitigation from the servers.  

(3) "vendor-id is missing from the cbor table":

Med: This was done on purpose to try to optimize the number of CBOR key values + encourage attributes reuse. E.g., We replaced "telemetry-id", "baseline-id", and "vendor-id" with a single "id" (as we only use those for the moment in the message body) but the YANG module includes the meaning of each "id" in the definition clause. We may need to revise this if we conclude that, e.g., "telemetry-id" (tmid) has to be defined as Path-URI.  

Cheers,
Med

> -----Message d'origine-----
> De : Dots [mailto:dots-bounces@ietf.org] De la part de
> mohamed.boucadair@orange.com
> Envoyé : vendredi 31 janvier 2020 16:18
> À : dots@ietf.org
> Objet : Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt
> 
> Hi all,
> 
> We prepared with Tiru a major revision of the telemetry draft. A diff
> is provided below to track the changes. We will now focus on sections
> 7 and 8.
> 
> Please review and share comments.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Dots [mailto:dots-bounces@ietf.org] De la part de internet-
> > drafts@ietf.org
> > Envoyé : vendredi 31 janvier 2020 15:52
> > À : i-d-announce@ietf.org
> > Cc : dots@ietf.org
> > Objet : [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the DDoS Open Threat Signaling WG of
> the
> > IETF.
> >
> >         Title           : Distributed Denial-of-Service Open Threat
> > Signaling (DOTS) Telemetry
> >         Authors         : Mohamed Boucadair
> >                           Tirumaleswar Reddy
> >                           Ehud Doron
> >                           Meiling Chen
> > 	Filename        : draft-ietf-dots-telemetry-01.txt
> > 	Pages           : 70
> > 	Date            : 2020-01-31
> >
> > Abstract:
> >    This document aims to enrich DOTS signal channel protocol with
> >    various telemetry attributes allowing optimal DDoS attack
> > mitigation.
> >    This document specifies the normal traffic baseline and attack
> >    traffic telemetry attributes a DOTS client can convey to its DOTS
> >    server in the mitigation request, the mitigation status telemetry
> >    attributes a DOTS server can communicate to a DOTS client, and
> the
> >    mitigation efficacy telemetry attributes a DOTS client can
> >    communicate to a DOTS server.  The telemetry attributes can
> assist
> >    the mitigator to choose the DDoS mitigation techniques and
> perform
> >    optimal DDoS attack mitigation.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dots-telemetry-01
> > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-01
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-01
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org
> > https://www.ietf.org/mailman/listinfo/dots
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots