Thank you. Looks good.
Regards,
Dan
On Tue, Nov 17, 2020 at 6:37 PM <mohamed.boucadair@xxxxxxxxxx> wrote:
Hi Dan,
We moved the text that I already quoted from the appendix to the main text and updated with more text to better address your issue #1.
The changes can be tracked at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-rfc8782-bis-02
Thank you.
Cheers,
Med
> -----Message d'origine-----
> De : mohamed.boucadair@xxxxxxxxxx
> [mailto:mohamed.boucadair@xxxxxxxxxx]
> Envoyé : jeudi 12 novembre 2020 13:01
> À : Dan Romascanu <dromasca@xxxxxxxxx>; ops-dir@xxxxxxxx
> Cc : last-call@xxxxxxxx; draft-ietf-dots-rfc8782-bis.all@xxxxxxxx;
> dots@xxxxxxxx
> Objet : RE: Opsdir last call review of draft-ietf-dots-rfc8782-bis-
> 01
>
> 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.
_________________________________________________________________________________________________________________________
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
