[Dots] TR: AUTH48 [RE]: RFC 8909 <draft-ietf-dots-signal-filter-control-07.txt> NOW AVAILABLE

[[e-mail]]

Hi all, 

I forgot to cc the list as these are required changes to reflect the WG decision to update rfc8782.

Cheers,
Med

-----Message d'origine-----
De : BOUCADAIR Mohamed TGI/OLN 
Envoyé : lundi 14 septembre 2020 07:52
À : '[e-mail]' <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc : [e-mail]; [e-mail]; [e-mail]
Objet : RE: AUTH48 [RE]: RFC 8909 <draft-ietf-dots-signal-filter-control-07.txt> NOW AVAILABLE

Dear RFC Editor, all, 

The edits look good. Below some comments:

(1) s/[DOTS-ARCH]/[RFC8811]

(2) While this document was in the editing queue, we discovered an issue with RFC8782 that implies some modifications to this draft: 

a. Replace through the document RFC8782 with draft-ietf-dots-rfc8782-bis b. Update the tree structure in Section 3.2.2.1 as follows:

OLD:
   module: ietf-dots-signal-control
     augment /ietf-signal:dots-signal/ietf-signal:message-type
             /ietf-signal:mitigation-scope/ietf-signal:scope:
       +--rw acl-list* [acl-name] {control-filtering}?
          +--rw acl-name
          |    -> /ietf-data:dots-data/dots-client/acls/acl/name
          +--rw activation-type?   ietf-data:activation-type

NEW: 
module: ietf-dots-signal-control
  augment-structure /ietf-signal:dots-signal/ietf-signal:message-type
                    /ietf-signal:mitigation-scope/ietf-signal:scope:
    +-- acl-list* [acl-name]
       +-- acl-name
       |       -> /ietf-data:dots-data/dots-client/acls/acl/name
       +-- activation-type?   ietf-data:activation-type

c. Update the imports in Section 3.2.2.2. Notes:
- RFCXXXX will be the number to be assigned to draft-ietf-dots-rfc8782-bis)
- RFC 8791 to be listed as a normative reference. 

OLD:
     import ietf-dots-signal-channel {
       prefix ietf-signal;
       reference
         "RFC 8782: Distributed Denial-of-Service Open Threat
                    Signaling (DOTS) Signal Channel Specification";
     }

NEW:
     import ietf-dots-signal-channel {
       prefix ietf-signal;
       reference
         "RFC XXXX: Distributed Denial-of-Service Open Threat
                    Signaling (DOTS) Signal Channel Specification";
     }
     import ietf-yang-structure-ext {
       prefix sx;
       reference
         "RFC 8791: YANG Data Structure Extensions";
     }

d. Update this part of the YANG module: 

OLD: 
     feature control-filtering {
       description
         "This feature means that the DOTS signal channel is able
          to manage the filtering rules created by the same DOTS
          client using the DOTS data channel.";
     }

     augment "/ietf-signal:dots-signal/ietf-signal:message-type"
           + "/ietf-signal:mitigation-scope/ietf-signal:scope" {
       if-feature control-filtering; "control-filtering";

NEW:
  sx:augment-structure "/ietf-signal:dots-signal/ietf-signal:message-type"
                     + "/ietf-signal:mitigation-scope/ietf-signal:scope" {

e. s/Section 10 of [RFC8782]/Section 11 of [RFC8782]

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]]
> Envoyé : samedi 12 septembre 2020 00:37 À : [e-mail]; BOUCADAIR 
> Mohamed TGI/OLN <[e-mail]>; [e-mail]; 
> [e-mail] Cc : [e-mail]; 
> [e-mail]; dots- [e-mail]; [e-mail] 
> Objet : AUTH48 [RE]: RFC 8909 <draft-ietf-dots-signal-filter- 
> control-07.txt> NOW AVAILABLE
> 
> *****IMPORTANT*****
> 
> Updated 2020/09/11
> 
> RFC Author(s):
> --------------
> 
> Instructions for Completing AUTH48 in XML
> 
> This is your last chance to make changes to your RFC-to-be:
> draft-ietf-dots-signal-filter-control-07.txt.
> Once the document is published as an RFC, we will not make changes.
> Please follow the instructions below to complete the AUTH48 process.
> (For frequently asked questions, please see
> https://www.rfc-editor.org/faq/#auth48.)
> 
> 1) This document is being processed using xml2rfc v3 tools.
>    Please help us by reviewing all formats carefully during AUTH48.
>    The following files are available for review:
> 
>    https://www.rfc-editor.org/authors/rfc8909.html
>    https://www.rfc-editor.org/authors/rfc8909.pdf
>    https://www.rfc-editor.org/authors/rfc8909.txt
> 
>    https://www.rfc-editor.org/authors/rfc8909.xml
>    (Note: you may need to view the page source to save the file.)
> 
> Note that <https://tools.ietf.org/rfcdiff> provides tools to make 
> various kinds of diff files.  We provide the following for your 
> convenience.
> 
> Changes to the content are best viewable in the following diff file of 
> the text:
>    https://www.rfc-editor.org/authors/rfc8909-diff.html
> 
> Changes to the XML file are viewable in the following diff file 
> (includes updates to the XML tagging and the content):
>    https://www.rfc-editor.org/authors/rfc8909-xmldiff1.html
> 
> 
> The following files are provided to facilitate creation of your own 
> diff files of the XML.
> 
> Initial XMLv3 created using XMLv2 as input:
>    https://www.rfc-editor.org/authors/rfc8909.original.v2v3.xml
> 
> XMLv3 file that is a best effort to capture v3-related format updates 
> only:
>    https://www.rfc-editor.org/authors/rfc8909.form.xml
> 
> 2) Review and resolve (as necessary) any questions raised by the RFC
>    Editor.  The questions (if any) have been included in the XML file 
> as
>    comments marked <!-- [rfced] ... --> and will be sent in a 
> subsequent email.
> 
> 3) Send us your changes or respond with your approval for publication.
>    Please use 'REPLY ALL' so that [e-mail] and the 
> parties
>    CC'ed on this message receive your response.
> 
>    Your document will not move forward until we have received
>    approvals from each of the authors listed on the front page.
>    Your approval indicates that you approve the .xml, .html, .pdf,
>    and .txt for publication. Your approval also indicates that you 
> have
>    engaged other parties (e.g., Contributors or Working Group) as
>    necessary before providing your approval.
> 
>    If sending changes, please do one of the following:
> 
>    a. Update the provided XML file, then email us the revised XML 
> file.
>       You may use any filename for the revised file; we will rename
>       it as needed.
> 
>   --OR--
> 
>    b. Provide us with an explicit list of changes in this format.
> 
>       Section # (or indicate Global)
> 
>       OLD:
>       old text
> 
>       NEW:
>       new text
> 
>    Be sure to pay particular attention to these areas of the
> document:
>    - IANA Considerations updates (if applicable)
>    - Contact information
>    - Copyright notice and legends; see the Trust Legal Provisions
> (TLP)
>      -- https://trustee.ietf.org/license-info/
> 
>    In particular for XMLv3, please review the XML tagging to ensure it
>    is correct. In addition, please do the following:
> 
>    a) if applicable, review the type attribute of each sourcecode 
> element
>       in the XML file to ensure correctness. See the xml2rfc FAQ for 
> details
>       (https://www.rfc-editor.org/materials/FAQ-
> xml2rfcv3.html#q_sourcecode).
> 
>    b) review each artwork element. Specifically, should any artwork 
> element
>       be tagged as sourcecode or another element?
> 
>    c) update the XML if you would like to take advantage of any of the
>       new features allowed in XML v3 (e.g., superscript and bold).
> 
> 4) If your document contains an SVG image, please be aware that the
>    RFC Editor will ask you to make any necessary changes to that file.
>    Revisions to SVG are most easily done in the tool used to create
>    the file.  Please use svgcheck to validate your SVG file
>    before submission (see https://pypi.org/project/svgcheck/).
> 
> 5) Review changes submitted by your coauthors (if any).  We assume 
> that
>    you will speak up if you do not agree with the proposed changes.
>    That is, your silence is your assent to changes submitted by your
>    coauthors. Note that any changes that are beyond editorial will be
>    sent to the relevant body for approval.
> 
> 6) Please reply, as the document will not be published until we 
> receive
>    approvals from each author.  The details of the AUTH48 status of 
> your
>    document are here:
> 
>    https://www.rfc-editor.org/auth48/rfc8909
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC8909 (draft-ietf-dots-signal-filter-control-07)
> 
> Title            : Controlling Filtering Rules Using Distributed
> Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
> Author(s)        : K. Nishizuka, M. Boucadair, T. Reddy, T. Nagata
> WG Chair(s)      : Liang Xia, Valery Smyslov
> Area Director(s) : Roman Danyliw, Benjamin Kaduk
> 


_________________________________________________________________________________________________________________________

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.