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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail]
> <[e-mail]>
> Sent: Thursday, February 6, 2020 12:09 PM
> To: Jon Shallow <[e-mail]>; Konda, Tirumaleswar Reddy
> <[e-mail]>; [e-mail]
> Subject: RE: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt
> 
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> Hi Jon, all,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Jon Shallow [mailto:[e-mail]]
> > Envoyé : mercredi 5 février 2020 21:24 À : 'Konda, Tirumaleswar
> > Reddy'; BOUCADAIR Mohamed TGI/OLN; [e-mail] Objet : RE: [Dots]
> > I-D Action: draft-ietf-dots-telemetry-01.txt
> >
> > See inline
> >
> > Regards
> >
> > Jon
> >
> ...
> > > >
> > > > (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.
> > >
> > > Why not change the DOTS telemetry attributes to comprehension-
> > required
> > > ?
> 
> [Med] Telemetry attributes are not mandatory for the signal channel to
> function. A signal channel message enriched with telemetry data should not
> exacerbate message failure.
> 
> > > If the server does not understand the DOTS telemetry attributes, it
> > will
> > > respond with 4.00 error response, and the client can re-send the
> > request
> > > without the DOTS telemetry attributes.
> >
> > Jon> Telemetry is also gated by a different sets of Path-URIs.
> 
> [Med] Except when telemetry is also included in an update during a
> mitigation (S-C or S-C). What I have for this one in my local copy is as follows:
> 
>    In order to make use of this feature, DOTS clients MUST establish a
>    telemetry setup session with the DOTS server in 'idle' time and MUST
>    set the 'server-originated-telemetry' attribute to 'true'.
> 
>    DOTS servers MUST NOT include telemetry attributes in mitigation
>    status updates sent to DOTS clients for which 'server-originated-
>    telemetry' attribute is set to 'false'.
> 
> > However,
> > source-prefix attribute comes from draft-ietf-dots-signal-call-home
> > and also occupies 3 bytes - do we change the source-prefix CBOR Key
> > type to comprehension-required?
> >
> 
> [Med] Including a source prefix in a signal channel message while not
> supported by the server must not lead to an error. That attribute cannot be
> set a comprehension-required. I suggest we don't touch that part.

Works for me.

-Tiru