Re: [Dots] Any reason why RFC8903 is stale since 09/20?

[kaname nishizuka <[e-mail]>]

Hi,

Attached is the latest status.
Yes, it's because some authors are not responding.
I hope ADs will make it move forward.

thanks,
Kaname

On 2021/01/04 18:18, [e-mail] wrote:
>
> Hi all,
>
> This document is in AUTH48 for too long.
>
> It would be appreciated if the authors can share an update of the blocking issues, if any.
>
> If this is stale just because some authors didn’t reply, I guess this statement can be followed:
>
> https://ietf.org/about/groups/iesg/statements/auth48/ <https://ietf.org/about/groups/iesg/statements/auth48/>
>
> Cheers,
>
> Med
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots

--- Begin Message ---

Greetings again,

> On Dec 2, 2020, at 10:15 PM, Sandy Ginoza <[e-mail]> wrote:
> 
> Greetings,
> 
> Just a friendly reminder that we await approvals from the individuals listed below.  We have not heard anything further in the last month.  
> 
> Please let us know how you would like to proceed.  

Please see <https://www.rfc-editor.org/faq/#missingauthor> for some information regarding options for moving forward when one or more authors is unresponsive.

Thank you,
RFC Editor/sg


> 
> Thank you,
> RFC Editor/sg
> 
> 
>> On Nov 3, 2020, at 3:54 PM, Sandy Ginoza <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Greetings all, ADs*,
>> 
>> We do not believe we have heard from the following authors since the document entered AUTH48 on 12 September: 
>> 
>> Roland Dobbins
>> Robert Moskowitz
>> Liang Xia
>> 
>> Please help us reach these authors to move the document along to publication. 
>> 
>> * ADs, please consider whether you would like to approve the document for publication in the absence of replies from these authors per <https://www.ietf.org/about/groups/iesg/statements/auth48/ <https://www.ietf.org/about/groups/iesg/statements/auth48/>>.  
>> 
>> Thank you,
>> RFC Editor/sg
>> 
>> 
>> 
>>> On Oct 15, 2020, at 11:07 AM, Marshika Szabo <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Authors,
>>> 
>>> This is a friendly reminder that we await approval of this document from Roland, Robert, and Liang before continuing with the publication process. 
>>> 
>>> Thank you,
>>> RFC Editor/ms
>>> 
>>> 
>>> 
>>>> On Oct 6, 2020, at 10:34 AM, Marshika Szabo <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Kaname,
>>>> 
>>>> Thank you for your reply. We have noted your approval on the AUTH48 status page for this document (http://www.rfc-editor.org/auth48/rfc8903 <http://www.rfc-editor.org/auth48/rfc8903>). 
>>>> 
>>>> Once we receive approval from Roland, Robert, and Liang, we can move forward in the publication process.
>>>> 
>>>> Thank you,
>>>> 
>>>> RFC Editor/ms
>>>> 
>>>>> On Oct 4, 2020, at 9:44 PM, kaname nishizuka <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I approve the document.
>>>>> 
>>>>> thanks,
>>>>> Kaname Nishizuka
>>>>> 
>>>>> 
>>>>> On 2020/10/03 3:51, Marshika Szabo wrote:
>>>>>> Nik,
>>>>>> 
>>>>>> Thank you for your reply. We have noted your approval on the AUTH48 status page for this document (http://www.rfc-editor.org/auth48/rfc8903 <http://www.rfc-editor.org/auth48/rfc8903>).
>>>>>> 
>>>>>> Once we receive approval from Roland, Robert, Liang, and Kaname, we can move forward in the publication process.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Thank you,
>>>>>> 
>>>>>> RFC Editor/ms
>>>>>> 
>>>>>>> On Sep 30, 2020, at 3:51 AM, Teague, Francis <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>> 
>>>>>>> Hi please accept this email as my approval
>>>>>>> 
>>>>>>> Thanks
>>>>>>> 
>>>>>>> -Nik
>>>>>>> 
>>>>>>> On Wed, 30 Sep 2020 at 03:08, Marshika Szabo <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>> Daniel,
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Thank you for the reply. Your approval has been noted on the AUTH48 status page of this document (http://www.rfc-editor.org/auth48/rfc8903 <http://www.rfc-editor.org/auth48/rfc8903>).
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Please note that individual approvals are needed from all authors before we can proceed with publication.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> 
>>>>>>> RFC Editor/ms
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Sep 29, 2020, at 2:19 PM, Daniel Migault <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>> Hi,
>>>>>>>> Thanks for the update. This seems fine to me. I approve the document in its current form, I believe other co-authors do so as well.
>>>>>>>> Yours,
>>>>>>>> Daniel
>>>>>>>> From: Marshika Szabo <[e-mail] <mailto:[e-mail]>>
>>>>>>>> Sent: Tuesday, September 29, 2020 2:51 PM
>>>>>>>> To: Daniel Migault <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>;[e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
>>>>>>>> Subject: Re: AUTH48 [MS]: RFC 8903 <draft-ietf-dots-use-cases-25.txt> NOW AVAILABLE
>>>>>>>> Daniel,
>>>>>>>> Thank you for your reply. The updated files are listed below. Please review and let us know if any further changes are needed or if you approve the document in its current form.
>>>>>>>> __________________________
>>>>>>>> The updated XML file is here:
>>>>>>>> https://protect2.fireeye.com/v1/url?k=b2ee2c48-ec5ff728-b2ee6cd3-86e2237f51fb-34bc4e80e849360a&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.xml <https://protect2.fireeye.com/v1/url?k=b2ee2c48-ec5ff728-b2ee6cd3-86e2237f51fb-34bc4e80e849360a&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.xml>
>>>>>>>> The updated output files are here:
>>>>>>>> https://protect2.fireeye.com/v1/url?k=14ea9126-4a5b4a46-14ead1bd-86e2237f51fb-47c0dd293b918466&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.html <https://protect2.fireeye.com/v1/url?k=14ea9126-4a5b4a46-14ead1bd-86e2237f51fb-47c0dd293b918466&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.html>
>>>>>>>> https://protect2.fireeye.com/v1/url?k=99937051-c722ab31-999330ca-86e2237f51fb-5d5406b76e285aef&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.txt <https://protect2.fireeye.com/v1/url?k=99937051-c722ab31-999330ca-86e2237f51fb-5d5406b76e285aef&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.txt>
>>>>>>>> https://protect2.fireeye.com/v1/url?k=5f73cd53-01c21633-5f738dc8-86e2237f51fb-746924ea09641497&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.pdf
>>>>>>>> This diff file shows all changes made during AUTH48:
>>>>>>>> https://protect2.fireeye.com/v1/url?k=1fbf387c-410ee31c-1fbf78e7-86e2237f51fb-cf7844dcc093708c&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-auth48diff.html
>>>>>>>> The other diff files are here:
>>>>>>>> https://protect2.fireeye.com/v1/url?k=735a325b-2debe93b-735a72c0-86e2237f51fb-22a9f694402fe7c5&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-diff.html
>>>>>>>> https://protect2.fireeye.com/v1/url?k=3f70c422-61c11f42-3f7084b9-86e2237f51fb-f9b98daad763a156&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-alt-diff.html (this diff makes viewing moved text easier)
>>>>>>>> Note that it may be necessary for you to refresh your browser to view the most recent version.
>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>> https://protect2.fireeye.com/v1/url?k=440c4d21-1abd9641-440c0dba-86e2237f51fb-9c3159eecd0ff0fd&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903
>>>>>>>> Thank you,
>>>>>>>> RFC Editor/ms
>>>>>>>>> On Sep 28, 2020, at 6:36 PM, Daniel Migault <[e-mail]> wrote:
>>>>>>>>> Hi Marshika,
>>>>>>>>> Thanks for the feed backs. I like proposal A) better  which corresponds to your example. I really appreciate the careful review you are performing and apology for the inconvenience.
>>>>>>>>> Yours,
>>>>>>>>> Daniel
>>>>>>>>> From: Marshika Szabo <[e-mail]>
>>>>>>>>> Sent: Monday, September 28, 2020 8:28 PM
>>>>>>>>> To: Daniel Migault <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>>>>>>>>> Subject: Re: AUTH48 [MS]: RFC 8903 <draft-ietf-dots-use-cases-25.txt> NOW AVAILABLE
>>>>>>>>> Daniel,
>>>>>>>>> Thank you for your reply. We have one follow-up question.
>>>>>>>>> Before updating the terminology, we would like to clarify the capitalization of ‘DDoS Mitigation’ (when not a part of a term). We are wondering about consistency with 'DDoS Mitigation’ vs. 'DDoS mitigation capacity’, for example. Should ‘Mitigation’ be either capitalized or lowercased in these occurrences (i.e., either A) 'DDoS Mitigation’ and 'DDoS Mitigation capacity’ or B) 'DDoS mitigation’ and 'DDoS mitigation capacity’)? Please let us know your preference.
>>>>>>>>> One example:
>>>>>>>>> Original:
>>>>>>>>> DDoS Mitigation System selection and DDoS Mitigation techniques
>>>>>>>>> may depend on the type of the DDoS attack.  In some cases, a manual
>>>>>>>>> confirmation or selection may also be required to choose a proposed
>>>>>>>>> strategy to initiate a DDoS Mitigation.
>>>>>>>>> Perhaps:
>>>>>>>>> DMS selection and DDoS Mitigation techniques
>>>>>>>>> may depend on the type of the DDoS attack.  In some cases, a manual
>>>>>>>>> confirmation or selection may also be required to choose a proposed
>>>>>>>>> strategy to initiate a DDoS Mitigation.
>>>>>>>>> Thank you,
>>>>>>>>> RFC Editor/ms
>>>>>>>>> On Sep 24, 2020, at 1:32 PM, Daniel Migault <[e-mail]> wrote:
>>>>>>>>> Hi,
>>>>>>>>> This looks fine to me. Thanks!
>>>>>>>>> Yours,
>>>>>>>>> Daniel
>>>>>>>>> From: Marshika Szabo <[e-mail]>
>>>>>>>>> Sent: Wednesday, September 23, 2020 8:36 PM
>>>>>>>>> To: Daniel Migault <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail]<[e-mail]>; [e-mail]<[e-mail]>;[e-mail]<[e-mail]>; [e-mail]<[e-mail]>; [e-mail]<[e-mail]>; [e-mail] <[e-mail]>; [e-mail]<[e-mail]>
>>>>>>>>> Subject: Re: AUTH48 [MS]: RFC 8903 <draft-ietf-dots-use-cases-25.txt> NOW AVAILABLE
>>>>>>>>> Daniel,
>>>>>>>>> Thank you for your response. We have updated the document accordingly. The updates can be found in this diff file: https://protect2.fireeye.com/v1/url?k=e28ec4ff-bc3f1f9f-e28e8464-86e2237f51fb-58a1a50b42039e1c&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903.
>>>>>>>>> We have two followup questions/comments.
>>>>>>>>> 1. Regarding this question:
>>>>>>>>> 2) <!-- [rfced] Does "decisions" refer to "some or all of the mitigation" or
>>>>>>>>> "some or all...to another DDoS Mitigation System".
>>>>>>>>> Original:
>>>>>>>>>  The DDoS Mitigation System may be composed of cluster of hardware and/or
>>>>>>>>>  software resources, but could also involve an orchestrator that may take
>>>>>>>>>  decisions such as outsourcing some or all of the mitigation to another DDoS
>>>>>>>>>  Mitigation System.
>>>>>>>>> Perhaps:
>>>>>>>>>  The DDoS Mitigation System may be composed of cluster of hardware and/or
>>>>>>>>>  software resources but could also involve an orchestrator that may make
>>>>>>>>>  decisions, such as outsourcing some or all of the mitigation, to another
>>>>>>>>>  DDoS Mitigation System.
>>>>>>>>> OR
>>>>>>>>>  The DDoS Mitigation System may be composed of cluster of hardware and/or
>>>>>>>>>  software resources but could also involve an orchestrator that may make
>>>>>>>>>  decisions, such as outsourcing some or all of the mitigation to another
>>>>>>>>>  DDoS Mitigation System.
>>>>>>>>> We have updated the document using the second option.
>>>>>>>>> 2. Regarding this issue:
>>>>>>>>> 7) <!-- [rfced] Throughout the text, "DDoS Mitigation" appears to be capitalized
>>>>>>>>> inconsistently. Please review these occurrences and let us know if/how
>>>>>>>>> they may be made consistent.
>>>>>>>>> DDoS Mitigation vs. DDoS mitigation
>>>>>>>>> DDoS Mitigation System (DMS) vs. DDoS mitigation system(s)
>>>>>>>>> DDoS Mitigation Service Provider
>>>>>>>>> DDoS Mitigation Service(s)
>>>>>>>>> DDoS mitigation activities/assistance/capacity/solutions (and more)
>>>>>>>>> -->
>>>>>>>>> <mglt>
>>>>>>>>> I think the idea was to indicate we used a word defined in the terminology. One other aspect of the capitalized terminology is that it indicates how to read the term.
>>>>>>>>> I would say before the terminology section we do not use any capitalized letters. These are used after the terminology section.
>>>>>>>>> More explicitly here are the rules I had in mind - thought I am very flexible.
>>>>>>>>> Before the terminology section we use DDoS mitigation.
>>>>>>>>> After the terminology section we use DDoS Mitigation
>>>>>>>>> Before the terminology section we use DDoS mitigation systems.
>>>>>>>>> After the terminology section we use DMS
>>>>>>>>> Before the terminology section we use DDoS mitigation service provider
>>>>>>>>> After the terminology section we use DDoS Mitigation Service Provider
>>>>>>>>> When the term is not defined in the terminology section we do not use capitalized letters. DDoS mitigation activities/assistance/capacity/solutions  (and more) do not have capitalized letters.
>>>>>>>>> We have changed all instances of "DDOS mitigation systems" following the Terminology section to “DMS”.
>>>>>>>>> Please note that in other RFCs, it’s typical and acceptable for the authors to pick a case that is used consistently throughout the doc, including any sections that appear before the Terminology section.  We suggest capitalizing the terms in question throughout the document for consistency (except for the terms that you noted should be lowercase).  Please let us know if you agree with this approach, and we will update the text accordingly.
>>>>>>>>> _______________________________________________________
>>>>>>>>> The updated XML file is here: (please be sure to refresh)
>>>>>>>>> https://protect2.fireeye.com/v1/url?k=598cc463-073d1f03-598c84f8-86e2237f51fb-8fe958260b9d0efe&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.xml
>>>>>>>>> The updated output files are here:
>>>>>>>>> https://protect2.fireeye.com/v1/url?k=51a2cb1f-0f13107f-51a28b84-86e2237f51fb-5c2c964f4285e824&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.html
>>>>>>>>> https://protect2.fireeye.com/v1/url?k=7b0bb38f-25ba68ef-7b0bf314-86e2237f51fb-03715e75f5fefdb5&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.txt
>>>>>>>>> https://protect2.fireeye.com/v1/url?k=b41ee505-eaaf3e65-b41ea59e-86e2237f51fb-47f02f384c6f823c&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.pdf
>>>>>>>>> This diff file shows all changes made during AUTH48:
>>>>>>>>> https://protect2.fireeye.com/v1/url?k=7d832425-2332ff45-7d8364be-86e2237f51fb-698125781005d04f&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-auth48diff.html
>>>>>>>>> The other diff files are here:
>>>>>>>>> https://protect2.fireeye.com/v1/url?k=6acb9158-347a4a38-6acbd1c3-86e2237f51fb-023bc7c261109f80&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-diff.html
>>>>>>>>> https://protect2.fireeye.com/v1/url?k=676b608c-39dabbec-676b2017-86e2237f51fb-302faa3b33d55773&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-alt-diff.html (this diff makes viewing moved text easier)
>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>> https://protect2.fireeye.com/v1/url?k=b4b0aa3e-ea01715e-b4b0eaa5-86e2237f51fb-159941795be92f5b&q=1&e=184d3c26-e28c-4cbe-9a5e-b37e99188560&u=http%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903
>>>>>>>>> Thank you,
>>>>>>>>> RFC Editor/ms
>>>>>>>>>   On Sep 18, 2020, at 3:42 PM, Daniel Migault <[e-mail]> wrote:
>>>>>>>>> Hi,
>>>>>>>>> Thank you for the feedbacks. I apology for the delayed response. Please find my comment inline. Feel free to let me know if additional information is needed.
>>>>>>>>> Yours,
>>>>>>>>> Daniel
>>>>>>>>> From: [e-mail] <[e-mail]>
>>>>>>>>> Sent: Saturday, September 12, 2020 7:26 PM
>>>>>>>>> To: [e-mail] <[e-mail]>; Daniel Migault <[e-mail]>; [e-mail]<[e-mail]>; [e-mail]<[e-mail]>; [e-mail]<[e-mail]>; [e-mail]<[e-mail]>
>>>>>>>>> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail]<[e-mail]>
>>>>>>>>> Subject: Re: AUTH48 [MS]: RFC 8903 <draft-ietf-dots-use-cases-25.txt> NOW AVAILABLE
>>>>>>>>> Authors,
>>>>>>>>> While reviewing this document during AUTH48, please resolve (as necessary)
>>>>>>>>> the following questions, which are also in the XML file.
>>>>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear in
>>>>>>>>> the title) for use on https://protect2.fireeye.com/v1/url?k=ea8e512f-b42e9286-ea8e11b4-86959e472243-93001f80ddc374f5&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Fsearch. -->
>>>>>>>>> <mglt>
>>>>>>>>> I think the title catch them all.
>>>>>>>>> </mglt>
>>>>>>>>> 2) <!-- [rfced] Does "decisions" refer to "some or all of the mitigation" or
>>>>>>>>> "some or all...to another DDoS Mitigation System".
>>>>>>>>> Original:
>>>>>>>>>   The DDoS Mitigation System may be composed of cluster of hardware and/or
>>>>>>>>>   software resources, but could also involve an orchestrator that may take
>>>>>>>>>   decisions such as outsourcing some or all of the mitigation to another DDoS
>>>>>>>>>   Mitigation System.
>>>>>>>>> Perhaps:
>>>>>>>>>   The DDoS Mitigation System may be composed of cluster of hardware and/or
>>>>>>>>>   software resources but could also involve an orchestrator that may make
>>>>>>>>>   decisions, such as outsourcing some or all of the mitigation, to another
>>>>>>>>>   DDoS Mitigation System.
>>>>>>>>> OR
>>>>>>>>>   The DDoS Mitigation System may be composed of cluster of hardware and/or
>>>>>>>>>   software resources but could also involve an orchestrator that may make
>>>>>>>>>   decisions, such as outsourcing some or all of the mitigation to another
>>>>>>>>>   DDoS Mitigation System.
>>>>>>>>> -->
>>>>>>>>> <mglt>
>>>>>>>>> I cannot see the difference between the two alternatives, but I am fine with the proposed change.
>>>>>>>>> </mglt>
>>>>>>>>> 3) <!-- [rfced] Would "does so" be an acceptable substitute for "honors the
>>>>>>>>> request"?
>>>>>>>>> Original:
>>>>>>>>>   The DOTS server which receives the DOTS Mitigation request determines that
>>>>>>>>>   it has been configured to honor requests from the requesting DOTS client,
>>>>>>>>>   and honors the request by orchestrating its own DMS.
>>>>>>>>> Perhaps:
>>>>>>>>>   The DOTS server, which receives the DOTS Mitigation request, determines that
>>>>>>>>>   it has been configured to honor requests from the requesting DOTS client and
>>>>>>>>>   does so by orchestrating its own DMS.
>>>>>>>>> -->
>>>>>>>>> <mglt>
>>>>>>>>> Works for me.
>>>>>>>>> </mglt>
>>>>>>>>> 4) <!-- [rfced] For clarity and to avoid repetition of "such as", may
>>>>>>>>> "such as routers" be changed to "i.e., routers"?
>>>>>>>>> Original:
>>>>>>>>>   Then the orchestrator can take further actions such as requesting
>>>>>>>>>   forwarding nodes such as routers to filter the traffic.
>>>>>>>>> Perhaps:
>>>>>>>>>   Then the orchestrator can take further actions such as requesting
>>>>>>>>>   forwarding nodes (i.e., routers) to filter the traffic.
>>>>>>>>> -->
>>>>>>>>> <mglt>
>>>>>>>>> I understand that i.e routers means "that is to router" and may not capture the fact that router are only one example. It seems to me that e.g. would be more appropriated.
>>>>>>>>> </mglt>
>>>>>>>>> 5) <!--[rfced] Does "the above DDoS Orchestration" refer to Figure 4?
>>>>>>>>> If so, we suggest lowercasing "orchestration" and adding the figure
>>>>>>>>> number as shown below. If not, please clarify.
>>>>>>>>> Original:
>>>>>>>>>   In addition to the above DDoS Orchestration, the selected DDoS
>>>>>>>>>   mitigation system can return back a mitigation request to the
>>>>>>>>>   orchestrator as an offloading.
>>>>>>>>> Perhaps:
>>>>>>>>>   In addition to the DDoS orchestration shown in Figure 4, the selected
>>>>>>>>>   DDoS mitigation system can return back a mitigation request to the
>>>>>>>>>   orchestrator as an offloading.
>>>>>>>>> -->
>>>>>>>>> <mglt>
>>>>>>>>> I agree with the change.
>>>>>>>>> </mglt>
>>>>>>>>> 6) <!--[rfced] FYI, we added "(at the time of writing)" to this phrase
>>>>>>>>> as the WG chairs have changed. Please confirm this is accurate.
>>>>>>>>> Original:
>>>>>>>>> the DOTS WG chairs, Roman Danyliw and Tobias Gondrom
>>>>>>>>> Current:
>>>>>>>>> the DOTS WG Chairs (at the time of writing) Roman Danyliw and Tobias Gondrom
>>>>>>>>> -->
>>>>>>>>> <mglt>
>>>>>>>>> That is correct.
>>>>>>>>> </mglt>
>>>>>>>>> 7) <!-- [rfced] Throughout the text, "DDoS Mitigation" appears to be capitalized
>>>>>>>>> inconsistently. Please review these occurrences and let us know if/how
>>>>>>>>> they may be made consistent.
>>>>>>>>> DDoS Mitigation vs. DDoS mitigation
>>>>>>>>> DDoS Mitigation System (DMS) vs. DDoS mitigation system(s)
>>>>>>>>> DDoS Mitigation Service Provider
>>>>>>>>> DDoS Mitigation Service(s)
>>>>>>>>> DDoS mitigation activities/assistance/capacity/solutions (and more)
>>>>>>>>> -->
>>>>>>>>> <mglt>
>>>>>>>>> I think the idea was to indicate we used a word defined in the terminology. One other aspect of the capitalized terminology is that it indicates how to read the term.
>>>>>>>>> I would say before the terminology section we do not use any capitalized letters. These are used after the terminology section.
>>>>>>>>> More explicitly here are the rules I had in mind - thought I am very flexible.
>>>>>>>>> Before the terminology section we use DDoS mitigation.
>>>>>>>>> After the terminology section we use DDoS Mitigation
>>>>>>>>> Before the terminology section we use DDoS mitigation systems.
>>>>>>>>> After the terminology section we use DMS
>>>>>>>>> Before the terminology section we use DDoS mitigation service provider
>>>>>>>>> After the terminology section we use DDoS Mitigation Service Provider
>>>>>>>>> ...
>>>>>>>>> When the term is not defined in the terminology section we do not use capitalized letters. DDoS mitigation activities/assistance/capacity/solutions  (and more) do not have capitalized letters.
>>>>>>>>> These are only my thoughts.
>>>>>>>>> </mglt>
>>>>>>>>> Thank you.
>>>>>>>>> RFC Editor/ms/ar
>>>>>>>>> On Sep 12, 2020, [e-mail] wrote:
>>>>>>>>> *****IMPORTANT*****
>>>>>>>>> Updated 2020/09/12
>>>>>>>>> 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-use-cases-25.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://protect2.fireeye.com/v1/url?k=2f009f05-71a05cac-2f00df9e-86959e472243-a2a62c04a7d60391&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F%23auth48.)
>>>>>>>>> 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://protect2.fireeye.com/v1/url?k=ab7a2c43-f5daefea-ab7a6cd8-86959e472243-3ed16037e9fe8457&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.html
>>>>>>>>>  https://protect2.fireeye.com/v1/url?k=aabe9828-f41e5b81-aabed8b3-86959e472243-7775ec61a68e5a9b&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.pdf
>>>>>>>>>  https://protect2.fireeye.com/v1/url?k=593a6547-079aa6ee-593a25dc-86959e472243-07f10801c34b8c0a&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.txt
>>>>>>>>>  https://protect2.fireeye.com/v1/url?k=1fc7d422-4167178b-1fc794b9-86959e472243-a9bf32629bbc85ae&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.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://protect2.fireeye.com/v1/url?k=4d59b343-13f970ea-4d59f3d8-86959e472243-342a6d7afc375bce&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-diff.html
>>>>>>>>> Changes to the XML file are viewable in the following diff file
>>>>>>>>> (includes updates to the XML tagging and the content):
>>>>>>>>>  https://protect2.fireeye.com/v1/url?k=15ed52aa-4b4d9103-15ed1231-86959e472243-7a3ad49ca536272e&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903-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://protect2.fireeye.com/v1/url?k=0c8bb516-522b76bf-0c8bf58d-86959e472243-0451ac79abde77a3&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.original.v2v3.xml
>>>>>>>>> XMLv3 file that is a best effort to capture v3-related format updates only:
>>>>>>>>>  https://protect2.fireeye.com/v1/url?k=3289aec5-6c296d6c-3289ee5e-86959e472243-f6ede64e9ef6e4bc&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc8903.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://protect2.fireeye.com/v1/url?k=406271c9-1ec2b260-40623152-86959e472243-33590a3a090fc025&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Fmaterials%2FFAQ-xml2rfcv3.html%23q_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://protect2.fireeye.com/v1/url?k=d67237e1-88d2f448-d672777a-86959e472243-35fa6ecd41a800ca&q=1&e=335774f9-c4e0-4694-8b93-b789516ad792&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc8903
>>>>>>>>> Thank you for your cooperation,
>>>>>>>>> RFC Editor
>>>>>>>>> --------------------------------------
>>>>>>>>> RFC8903 (draft-ietf-dots-use-cases-25)
>>>>>>>>> Title            : Use cases for DDoS Open Threat Signaling
>>>>>>>>> Author(s)        : R. Dobbins, D. Migault, R. Moskowitz, N. Teague, L. Xia, K. Nishizuka
>>>>>>>>> WG Chair(s)      : Liang Xia, Valery Smyslov
>>>>>>>>> Area Director(s) : Roman Danyliw, Benjamin Kaduk
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data.
>>>>>>> 
>>>>>>> If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message.
>>>>> 
>>>> 
>>> 
>> 
> 

--- End Message ---