Re: [Dots] Opsdir early review of draft-ietf-dots-telemetry-10

[[e-mail]]

Hi Nagendra, all, 

FWIW, the proposed changes are now implemented in -11: 

URL:            https://www.ietf.org/internet-drafts/draft-ietf-dots-telemetry-11.txt 
Status:         https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ 
Htmlized:       https://tools.ietf.org/html/draft-ietf-dots-telemetry-11 
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry 
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-11

Cheers,
Med

> -----Message d'origine-----
> De : [e-mail]
> [mailto:[e-mail]]
> Envoyé : lundi 20 juillet 2020 09:00
> À : Nagendra Nainar <[e-mail]>; [e-mail]
> Cc : [e-mail]; [e-mail]
> Objet : RE: Opsdir early review of draft-ietf-dots-telemetry-10
> 
> Hi Nagendra,
> 
> Thank you for the review.
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Nagendra Nainar via Datatracker [mailto:[e-mail]]
> Envoyé
> > : vendredi 17 juillet 2020 18:52 À : [e-mail] Cc :
> > [e-mail]; [e-mail]
> > Objet : Opsdir early review of draft-ietf-dots-telemetry-10
> >
> > Reviewer: Nagendra Nainar
> > Review result: Has Nits
> >
> > Hi,
> >
> > I have reviewed this document as part of the Operational
> directorate's
> > ongoing effort to review all IETF documents being processed by the
> > IESG.  These comments were written with the intent of improving the
> > operational aspects of the IETF drafts per guidelines in RFC5706.
> >
> > Comments that are not addressed in last call may be included in AD
> > reviews during the IESG review.  Document editors and WG chairs
> should
> > treat these comments just like any other last call comments.
> >
> > Overall Summary:
> >
> > This draft is a standard track proposing telemetry attributes for
> DOTS
> > signal channel (RFC8782) that can be exchanged between DOTS client
> and
> > server. The draft clarifies that these attributes are not mandatory.
> > As these telemetry attributes are extensions of the existing DOTS
> > signal channel and it already clarifies that they are not mandatory,
> > this draft does not introduce any backward compatibility issues.
> >
> > The draft also proposes high level error handling mechanism for the
> > telemetry attributes defined in this document.
> >
> > Overall this is a well written document. Some ambiguity observed
> that
> > needs attention are listed below:
> >
> > --> The below reference seems to be wrong. RFC7252 is COAP and not
> > CBOR.
> > --> I
> > think it should be RFC7049.
> >
> 
> [Med] I confirm. Fixed.
> 
> > "Telemetry messages exchanged between DOTS agents are serialized
> using
> >    Concise Binary Object Representation (CBOR) [RFC7252]"
> >
> > --> An early reference to RFC7950 may be useful in Section 4.5.
> 
> [Med] OK.
> 
> >
> > --> tsid seems to be a terminology introduced in this draft. It
> > will be
> > --> good to
> > add this in the terminology section. Same for tmid.
> 
> [Med] No problem. This will be added.
> 
> >
> > --> Section 6.1.2 states that a PUT request with link capacity set
> > to 0
> > --> to
> > delete a link when the other link is active. What happens if a PUT
> > request is sent with all the links set to a capacity of 0?. Will it
> be
> > treated as error or as "DELETE"?.
> 
> [Med] This falls under this behavior in 6.1.2:
> 
>    o  If the request is missing a mandatory attribute, does not
> include
>       'cuid' or 'tsid' Uri-Path parameters, or contains one or more
>       invalid or unknown parameters, 4.00 (Bad Request) MUST be
> returned
>       in the response.
> 
> I added this note to make it explicit:
> 
> "Note that if the DOTS server receives a PUT request with a 'capacity'
> attribute set to "0" for all included links, it MUST reject the
> request with a 4.00 (Bad Request)."
> 
> >
> > --> The DMS mentioned below can be expanded or included in the
> > --> terminology
> > section. I cant find it in RFC8287 as well.
> 
> [Med] I expanded the acronym to DDoS Mitigation System, but removed
> "DMS" as it is not used in other parts of the text.
> 
> >
> > The 'total-attack-traffic' attribute (Figure 27) conveys the total
> >    attack traffic identified by the DOTS client domain's DMS (or
> DDoS
> >
> > --> I understand that Pre-or-Ongoing-Mitigation attribute can be
> > --> signaled by
> > DOTS client or Server. Can this be used to report an ongoing attack
> to
> > the server?
> 
> [Med] Yes, clients can send telemetry to the servers.
> 
> . If so, what should be the value set in the
> > end-time field?.
> 
> [Med] This attribute will be used if the attack was mitigated. The
> client will set it to the time when the attack traffic is not seen
> anymore in the DOTS domain client.
> 
> >
> > --> I am skipping the YANG module as I noticed that YANGDOCTOR
> > review is
> > already done.
> >
> > Few nits:
> >
> > s/If no target clause in included in the request/If no target clause
> > is included in the request
> >
> >
> [Med] Thank you for catching this. Fixed.
> 
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.


_________________________________________________________________________________________________________________________

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.