Hi Dan,
Thank you for the review.
There are no changes to the on wire protocol because the YANG modeled data is mapped to CBOR (Section 3):
This document specifies a YANG module for representing DOTS
mitigation scopes, DOTS signal channel session configuration data,
and DOTS redirected signaling (Section 5). All parameters in the
^^^^^^^^^^^^^^^^^^^^
payload of the DOTS signal channel are mapped to CBOR types as
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
specified in Table 5 (Section 6).
^^^^^^^^^^^^^^^^^^^^
and that we managed the update with the following in mind (Appendix A. Summary of Changes From RFC8782):
These modifications are made with the constraint to avoid changes to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
the mapping table defined in Table 5 (Section 6). A DOTS signal^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
channel attribute that may be present in both requests and responses
will thus have the same CBOR key value and CBOR major type.
Even if an implementation relies on the YANG module to generate the mapping table, it must anyway to comply with Table 5 (RFC8782):
Note: Implementers must check that the mapping output provided by
their YANG-to-CBOR encoding schemes is aligned with the content of
Table 5. For example, some CBOR and JSON types for enumerations
and the 64-bit quantities can differ depending on the encoder
used.
Cheers,
Med
> -----Message d'origine-----
> De : Dan Romascanu via Datatracker [mailto:noreply@xxxxxxxx]
> Envoyé : jeudi 12 novembre 2020 12:19
> À : ops-dir@xxxxxxxx
> Cc : last-call@xxxxxxxx; draft-ietf-dots-rfc8782-bis.all@xxxxxxxx;
> dots@xxxxxxxx; dromasca@xxxxxxxxx
> Objet : Opsdir last call review of draft-ietf-dots-rfc8782-bis-01
>
> Reviewer: Dan Romascanu
> Review result: Has Issues
>
> This document specifies the Distributed Denial-of-Service Open
> Threat Signaling
> (DOTS) signal channel, a protocol for signaling the need for
> protection against Distributed Denial-of-Service (DDoS) attacks to a
> server capable of enabling network traffic mitigation on behalf of
> the requesting client. The DOTS data channel is defined in an
> associated document. The document updates RFC 8872.
>
> The document is almost Ready from an OPS perspective, but there are
> a couple of issues worth clarification before approval.
>
> 1. Appendix A describes the changes from RFC 8782. I could not find
> however any information in the document concerning backwards
> compatibility and the path of upgrade that an operator should be
> aware about when migrating an existing client, server or the whole
> network from RFC 8782 support. If I missed it, please point and
> maybe detail this information in the Appendix. If not, it would be
> useful to add.
>
> 2. I could not find any information about the supplementary overload
> that the changes in signaling brought by this update may bring. If
> such an analysis was made, it would be useful to mention its
> results. No significant extra-load is fine. If anything different,
> it would be useful to add more details.
>
_________________________________________________________________________________________________________________________
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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
