Re: [auth48] AUTH48: RFC-to-be 9284 <draft-ietf-dots-multihoming-13> for your review

[Reuben Esparza <[e-mail]>]

Hi Authors,


Thank you for your replies. I’ll be finishing the AUTH48 on this document for Megan while she’s away.

Mohamed, we've made your new proposed update and have added your approval to the AUTH48 status page.


As approvals are now complete, this document will move forward in the publication process at this time.

Please see the AUTH48 status page at https://www.rfc-editor.org/auth48/rfc9284.  


Thank you.
RFC Editor/re



> On Aug 28, 2022, at 11:32 PM, [e-mail] wrote:
> 
> Hi Megan, all, 
> 
> Apologies for the delay to replay (I was out of office the last month). 
> 
> The changes look good to me except this one:
> 
>   Upon receipt of this
>   request, a client-domain DOTS gateway MUST check whether the
>   request is to be forwarded upstream (if the target IP prefix is
>   managed by the upstream server) or rejected.
> 
> I suggest we revert back to the OLD version we had or use the following:
> 
>   Client-domain DOTS gateways MUST check whether a received 
>   request is to be forwarded upstream (if the target IP prefix is
>   managed by the upstream server) or rejected.
> 
> Assuming this change is made, I approve the publication of the document. 
> 
> Thank you for your great effort, as usual. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Megan Ferguson <[e-mail]>
>> Envoyé : mardi 23 août 2022 22:02
>> À : Panwei (William) <[e-mail]>; BOUCADAIR
>> Mohamed INNOV/NET <[e-mail]>
>> Cc : tirumal reddy <[e-mail]>; RFC Errata System <rfc-
>> [e-mail]>; [e-mail]; [e-mail];
>> [e-mail]; Roman Danyliw <[e-mail]>;
>> [e-mail]
>> Objet : Re: AUTH48: RFC-to-be 9284 <draft-ietf-dots-multihoming-
>> 13> for your review
>> 
>> Wei PAN,
>> 
>> Thank you for your reply.  We have updated the AUTH48 status page
>> to reflect your approval.  Once we hear approval from Mohamed,
>> this document will be ready to move forward in the publication
>> process.
>> 
>> Please note that we will assume your assent to any further changes
>> submitted by your coauthors unless we hear otherwise at that time.
>> 
>> The AUTH48 status page is viewable at:
>> 
>> http://www.rfc-editor.org/auth48/rfc9284
>> 
>> Thank you.
>> 
>> RFC Editor/mf
>> 
>> 
>> 
>>> On Aug 20, 2022, at 1:39 AM, Panwei (William)
>> <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> Thanks for your work, the changes look good to me, too. I
>> approve the publication.
>>> 
>>> Regards & Thanks!
>>> Wei PAN (潘伟)
>>> 
>>> 
>>>> -----Original Message-----
>>>> From: Megan Ferguson [mailto:[e-mail]]
>>>> Sent: Saturday, August 20, 2022 4:13 AM
>>>> To: tirumal reddy <[e-mail]>; Panwei (William)
>>>> <[e-mail]>; <[e-mail]>
>>>> <[e-mail]>
>>>> Cc: RFC Errata System <[e-mail]>; dots-
>> [e-mail];
>>>> [e-mail]; [e-mail]; Roman Danyliw
>>>> <[e-mail]>; [e-mail]
>>>> Subject: Re: AUTH48: RFC-to-be 9284 <draft-ietf-dots-
>> multihoming-13>
>>>> for your review
>>>> 
>>>> Tiru,
>>>> 
>>>> Thanks for the reply.  We’ve updated your status to “Approved”
>> at the
>>>> AUTH48 status page.
>>>> 
>>>> We will await word from each coauthor prior to moving the
>> document
>>>> forward in the publication process.
>>>> 
>>>> The AUTH48 status page is available here:
>>>>  http://www.rfc-editor.org/auth48/rfc9284
>>>> 
>>>> Thank you.
>>>> 
>>>> RFC Editor/mf
>>>> 
>>>>> On Aug 16, 2022, at 6:26 AM, tirumal reddy <[e-mail]>
>> wrote:
>>>>> 
>>>>> Changes look good to me, I approve the publication.
>>>>> 
>>>>> Best Regards,
>>>>> -Tiru
>>>>> 
>>>>> On Tue, 16 Aug 2022 at 04:01, Megan Ferguson
>> <[e-mail]>
>>>> wrote:
>>>>> Hi Tiru,
>>>>> 
>>>>> Thanks for the reply and guidance.  We have updated as you
>> suggested.
>>>>> Please review our updates carefully and let us know if any
>> further
>>>>> changes are necessary or if the current version should be
>> moved
>>>>> forward
>>>> in the publication process.
>>>>> We will await approval from each author listed at the AUTH48
>> status
>>>>> page
>>>> (below).
>>>>> 
>>>>> The files have been posted here:
>>>>>  https://www.rfc-editor.org/authors/rfc9284.txt
>>>>>  https://www.rfc-editor.org/authors/rfc9284.pdf
>>>>>  https://www.rfc-editor.org/authors/rfc9284.html
>>>>>  https://www.rfc-editor.org/authors/rfc9284.xml
>>>>> 
>>>>> The relevant diff files have been posted here:
>>>>>  https://www.rfc-editor.org/authors/rfc9284-diff.html
>>>>> (comprehensive
>>>> diff)
>>>>>  https://www.rfc-editor.org/authors/rfc9284-rfcdiff.html
>>>> (comprehensive rfcdiff)
>>>>>  https://www.rfc-editor.org/authors/rfc9284-auth48diff.html
>> (AUTH48
>>>>> changes only)
>>>>> 
>>>>> The AUTH48 status page is available here:
>>>>>  http://www.rfc-editor.org/auth48/rfc9284
>>>>> 
>>>>> Thank you.
>>>>> 
>>>>> RFC Editor/mf
>>>>> 
>>>>>> On Aug 10, 2022, at 9:08 AM, tirumal reddy
>> <[e-mail]>
>>>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Please see inline.
>>>>>> 
>>>>>> On Tue, 2 Aug 2022 at 05:19, <[e-mail]>
>> wrote:
>>>>>> Authors,
>>>>>> 
>>>>>> While reviewing this document during AUTH48, please resolve
>> (as
>>>> necessary) the following questions, which are also in the XML
>> file.
>>>>>> 
>>>>>> 1) <!-- [rfced] FYI, the title of the document has been
>> updated as
>>>>>> follows. We have removed the expansion of "DDoS" as it is
>> included
>>>>>> inside another abbreviation, and it is considered well known
>> on the
>>>>>> abbreviations list
>>>> (https://www.rfc-editor.org/materials/abbrev.expansion.txt).
>>>>>> Please let us know if you prefer otherwise.
>>>>>> 
>>>>>> Original:
>>>>>> Multi-homing Deployment Considerations for
>>>> Distributed-Denial-of-Service
>>>>>>                     Open Threat Signaling (DOTS)
>>>>>> 
>>>>>> Current:
>>>>>> Multihoming Deployment Considerations for DDoS Open Threat
>>>> Signaling
>>>>>> (DOTS)
>>>>>> -->
>>>>>> 
>>>>>> Okay.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that
>>>>>> appear in the title) for use on https://www.rfc-
>> editor.org/search.
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 3) <!--[rfced] Will it be clear to readers what is multihomed
>> in
>>>>>> this
>>>> sentence?
>>>>>> 
>>>>>> Original:
>>>>>>  The goal is to provide some guidance for DOTS clients and
>>>>>>  client-domain DOTS gateways when multihomed.
>>>>>> 
>>>>>> Yes, the term "multihomed" is used in several RFCs.
>>>>>> 
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 4) <!--[rfced] Please clarify "server(s) addresses" here; the
>> "(s)"
>>>>>> seems unnecessary. Does either suggestion convey the intended
>>>>>> meaning?
>>>>>> 
>>>>>> Original:
>>>>>>  The DOTS client establishes one or more DOTS sessions by
>>>>>>  connecting to the provided DOTS server(s) addresses (e.g.,
>> by using
>>>>>>  [RFC8973]).
>>>>>> 
>>>>>> Option A:
>>>>>>  The DOTS client establishes one or more DOTS sessions by
>>>>>>  connecting to the provided DOTS server addresses (e.g., by
>> using
>>>>>>  [RFC8973]).
>>>>>> 
>>>>>> Option B:
>>>>>>  The DOTS client establishes one or more DOTS sessions by
>>>>>>  connecting to the provided addresses for the DOTS server or
>>>>>>  servers (e.g., by using [RFC8973]).
>>>>>> -->
>>>>>> 
>>>>>> Option B looks good.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 5) <!--[rfced] Should Section 4.1's title also use a colon?
>>>>>> 
>>>>>> Current:
>>>>>> Multihomed Residential Single CPE
>>>>>> 
>>>>>> Perhaps:
>>>>>> Multihomed Residential: Single CPE
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>> 
>>>>>> For comparison:
>>>>>> 4.2.  Multihomed Enterprise: Single CPE, Multiple Upstream
>> ISPs
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 6) <!--[rfced] In the following text, please clarify whether
>> the "/"
>>>>>> in "IP addresses/prefixes" means "and" or "or", and please
>> review
>>>>>> whether "the" or "a" may be used for "default gateway
>> address" and
>>>>>> "DOTS server's name".
>>>>>> 
>>>>>> Original:
>>>>>>  *  Each of these provisioning domains assigns IP
>>>> addresses/prefixes
>>>>>>     to the CPE and provides additional configuration
>> information
>>>> such
>>>>>>     as a list of DNS servers, DNS suffixes associated with
>> the
>>>>>>     network, default gateway address, and DOTS server's name
>>>>>>     [RFC8973].
>>>>>> 
>>>>>> Perhaps:
>>>>>>  *  Each of these provisioning domains assigns IP addresses
>> or
>>>> prefixes
>>>>>>     to the CPE and provides additional configuration
>> information
>>>> such
>>>>>>     as a list of DNS servers, DNS suffixes associated with
>> the
>>>>>>     network, the default gateway address, and the DOTS
>> server's
>>>> name
>>>>>>     [RFC8973].
>>>>>> 
>>>>>> Proposed text looks good.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Throughout this document, please review the usage of
>>>> "addresses/prefixes"
>>>>>> (16 instances) as well as similar "address/prefix" (2
>> instances)
>>>>>> and "prefixes/addresses" (1 instance) and let us know if any
>>>>>> updates are
>>>> needed.
>>>>>> Perhaps "and", "or", or "and/or" is intended.
>>>>>> 
>>>>>> You can use "or".
>>>>>> 
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 7) <!--[rfced] Please clarify this sentence. It seems there's
>> an
>>>>>> extraneous "from".
>>>>>> The "either ... or" phrase should contain two parallel items,
>> e.g.,
>>>>>> A) either "the DNS servers learned" or "the DNS servers
>> associated"
>>>>>> B) either "learned from" or "associated with"
>>>>>> Please see below.
>>>>>> 
>>>>>> Original:
>>>>>>  The DOTS client MUST resolve the DOTS server's name
>> provided by
>>>> each
>>>>>>  provisioning domain using either the DNS servers learned
>> from the
>>>>>>  respective provisioning domain or from the DNS servers
>> associated
>>>>>>  with the interface(s) for which a DOTS server was
>> explicitly
>>>>>>  configured (Section 4).
>>>>>> 
>>>>>> Option A (removing "from"):
>>>>>>  The DOTS client MUST resolve the DOTS server's name
>> provided by
>>>> each
>>>>>>  provisioning domain using either the DNS servers learned
>> from the
>>>>>>  respective provisioning domain or the DNS servers
>> associated
>>>>>>  with the interface(s) for which a DOTS server was
>> explicitly
>>>>>>  configured (Section 4).
>>>>>> 
>>>>>> Option B (avoiding repetition of "DNS servers"):
>>>>>>  The DOTS client MUST resolve the DOTS server's name
>> provided by
>>>> each
>>>>>>  provisioning domain using the DNS servers either learned
>> from the
>>>>>>  respective provisioning domain or associated
>>>>>>  with the interface(s) for which a DOTS server was
>> explicitly
>>>>>>  configured (Section 4).
>>>>>> 
>>>>>> Option B looks good.
>>>>>> 
>>>>>> 
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> 8) <!--[rfced] Regarding this text:
>>>>>> - Please clarify what "it" refers to in "it MUST check".
>>>>>> Does it refer to a client-domain DOTS gateway?
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>> - In the first sentence, will "the latter" be clear to the
>> reader?
>>>>>> Does it refer to DOTS clients?
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>> 
>>>>>> Original:
>>>>>>  When PA addresses/prefixes are used, but no filter rules
>> are
>>>> provided
>>>>>>  to DOTS clients, the latter MUST contact all client-domain
>> DOTS
>>>>>>  gateways simultaneously to send a DOTS message.  Upon
>> receipt
>>>> of a
>>>>>>  request by a client-domain DOTS gateway, it MUST check
>> whether
>>>> the
>>>>>>  request is to be forwarded upstream (if the target IP
>> prefix is
>>>>>>  managed by the upstream server) or rejected.
>>>>>> 
>>>>>> Perhaps:
>>>>>>  When PA addresses/prefixes are used, but no filter rules
>> are
>>>> provided
>>>>>>  to DOTS clients, the clients MUST contact all client-domain
>> DOTS
>>>>>> 
>>>>>> You may want to replace "the clients" with "the DOTS clients"
>> or "it".
>>>>>> 
>>>>>>  gateways simultaneously to send a DOTS message.  Upon
>> receipt
>>>> of this
>>>>>>  request, a client-domain DOTS gateway MUST check whether
>> the
>>>>>>  request is to be forwarded upstream (if the target IP
>> prefix is
>>>>>>  managed by the upstream server) or rejected.
>>>>>> -->
>>>>>> 
>>>>>> Good catch, the proposed text looks good.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 9) <!--[rfced] FYI, RFC 8811, Section 4 is IANA
>> Considerations, so
>>>>>> we have updated this to point to Section 5 (Security
>>>>>> Considerations)
>>>> instead.
>>>>>> 
>>>>>> Original:
>>>>>>  DOTS-related security considerations are discussed in
>> Section 4 of
>>>>>>  [RFC8811].
>>>>>> 
>>>>>> Current:
>>>>>>  DOTS-related security considerations are discussed in
>> Section 5 of
>>>>>>  [RFC8811].
>>>>>> -->
>>>>>> 
>>>>>> Thanks.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 10) <!--[rfced] Regarding [TS.24008], the original noted
>> "Release 16".
>>>>>> Do you want to reference a specific version?
>>>>>> 
>>>>>> No, I don't see the need to reference a specific version.
>>>>>> 
>>>>>> Please change my affiliation to Nokia and remove the office
>> address.
>>>>>> 
>>>>>> Cheers,
>>>>>> -Tiru
>>>>>> 
>>>>>> If so, did you intend
>>>>>> 16.3.0 in December 2019 (as shown under "Versions" at the
>> provided
>>>>>> URL) or a different version?
>>>>>> 
>>>>>> Original:
>>>>>>  [TS.24008] 3GPP, "Mobile radio interface Layer 3
>> specification; Core
>>>>>>             network protocols; Stage 3 (Release 16)",
>> December
>>>> 2019,
>>>>>>             <http://www.3gpp.org/DynaReport/24008.htm>.
>>>>>> 
>>>>>> Current:
>>>>>>  [TS.24008] 3GPP, "Mobile radio interface Layer 3
>> specification; Core
>>>>>>             network protocols; Stage 3", 3GPP TS 24.008
>> 16.3.0,
>>>>>>             December 2019,
>>>>>>             <https://www.3gpp.org/DynaReport/24008.htm>.
>>>>>> -->
>>>>>> 
>>>>>> 
>>>>>> Thank you.
>>>>>> 
>>>>>> RFC Editor/st/ar
>>>>>> 
>>>>>> 
>>>>>> On Aug 1, 2022, [e-mail] wrote:
>>>>>> 
>>>>>> *****IMPORTANT*****
>>>>>> 
>>>>>> Updated 2022/08/01
>>>>>> 
>>>>>> RFC Author(s):
>>>>>> --------------
>>>>>> 
>>>>>> Instructions for Completing AUTH48
>>>>>> 
>>>>>> Your document has now entered AUTH48.  Once it has been
>> reviewed
>>>> and
>>>>>> approved by you and all coauthors, it will be published as an
>> RFC.
>>>>>> If an author is no longer available, there are several
>> remedies
>>>>>> available as listed in the FAQ (https://www.rfc-
>> editor.org/faq/).
>>>>>> 
>>>>>> You and you coauthors are responsible for engaging other
>> parties
>>>>>> (e.g., Contributors or Working Group) as necessary before
>> providing
>>>>>> your approval.
>>>>>> 
>>>>>> Planning your review
>>>>>> ---------------------
>>>>>> 
>>>>>> Please review the following aspects of your document:
>>>>>> 
>>>>>> *  RFC Editor questions
>>>>>> 
>>>>>> Please review and resolve any questions raised by the RFC
>> Editor
>>>>>> that have been included in the XML file as comments marked as
>>>>>> follows:
>>>>>> 
>>>>>> <!-- [rfced] ... -->
>>>>>> 
>>>>>> These questions will also be sent in a subsequent email.
>>>>>> 
>>>>>> *  Changes submitted by coauthors
>>>>>> 
>>>>>> Please ensure that you review any changes submitted by your
>>>>>> coauthors.  We assume that if you do not speak up that you
>> agree
>>>>>> to changes submitted by your coauthors.
>>>>>> 
>>>>>> *  Content
>>>>>> 
>>>>>> Please review the full content of the document, as this
>> cannot
>>>>>> change once the RFC is published.  Please pay particular
>> attention
>>>> to:
>>>>>> - IANA considerations updates (if applicable)
>>>>>> - contact information
>>>>>> - references
>>>>>> 
>>>>>> *  Copyright notices and legends
>>>>>> 
>>>>>> Please review the copyright notice and legends as defined in
>> RFC
>>>>>> 5378 and the Trust Legal Provisions  (TLP –
>>>>>> https://trustee.ietf.org/license-info/).
>>>>>> 
>>>>>> *  Semantic markup
>>>>>> 
>>>>>> Please review the markup in the XML file to ensure that
>> elements
>>>>>> of  content are correctly tagged.  For example, ensure that
>>>> <sourcecode>
>>>>>> and <artwork> are set correctly.  See details at
>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>>> 
>>>>>> *  Formatted output
>>>>>> 
>>>>>> Please review the PDF, HTML, and TXT files to ensure that
>> the
>>>>>> formatted output, as generated from the markup in the XML
>> file, is
>>>>>> reasonable.  Please note that the TXT will have formatting
>>>>>> limitations compared to the PDF and HTML.
>>>>>> 
>>>>>> 
>>>>>> Submitting changes
>>>>>> ------------------
>>>>>> 
>>>>>> To submit changes, please reply to this email using ‘REPLY
>> ALL’ as
>>>>>> all the parties CCed on this message need to see your
>> changes. The
>>>>>> parties
>>>>>> include:
>>>>>> 
>>>>>> *  your coauthors
>>>>>> 
>>>>>> *  [e-mail] (the RPC team)
>>>>>> 
>>>>>> *  other document participants, depending on the stream
>> (e.g.,
>>>>>>    IETF Stream participants are your working group chairs,
>> the
>>>>>>    responsible ADs, and the document shepherd).
>>>>>> 
>>>>>> *  [e-mail], which is a new archival
>> mailing list
>>>>>>    to preserve AUTH48 conversations; it is not an active
>> discussion
>>>>>>    list:
>>>>>> 
>>>>>>   *  More info:
>>>>>> 
>>>>>> 
>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-
>> 4Q9l2US
>>>>>> xIAe6P8O4Zc
>>>>>> 
>>>>>>   *  The archive itself:
>>>>>>      https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>> 
>>>>>>   *  Note: If only absolutely necessary, you may temporarily
>> opt out
>>>>>>      of the archiving of messages (e.g., to discuss a
>> sensitive matter).
>>>>>>      If needed, please add a note at the top of the message
>> that you
>>>>>>      have dropped the address. When the discussion is
>> concluded,
>>>>>>      [e-mail] will be re-added to the CC
>> list
>>>> and
>>>>>>      its addition will be noted at the top of the message.
>>>>>> 
>>>>>> You may submit your changes in one of two ways:
>>>>>> 
>>>>>> An update to the provided XML file
>>>>>> — OR —
>>>>>> An explicit list of changes in this format
>>>>>> 
>>>>>> Section # (or indicate Global)
>>>>>> 
>>>>>> OLD:
>>>>>> old text
>>>>>> 
>>>>>> NEW:
>>>>>> new text
>>>>>> 
>>>>>> You do not need to reply with both an updated XML file and an
>>>>>> explicit list of changes, as either form is sufficient.
>>>>>> 
>>>>>> We will ask a stream manager to review and approve any
>> changes that
>>>>>> seem beyond editorial in nature, e.g., addition of new text,
>>>>>> deletion of text, and technical changes.  Information about
>> stream
>>>>>> managers can be found in the FAQ.  Editorial changes do not
>> require
>>>> approval from a stream manager.
>>>>>> 
>>>>>> 
>>>>>> Approving for publication
>>>>>> --------------------------
>>>>>> 
>>>>>> To approve your RFC for publication, please reply to this
>> email
>>>>>> stating that you approve this RFC for publication.  Please
>> use
>>>>>> ‘REPLY ALL’, as all the parties CCed on this message need to
>> see
>>>>>> your
>>>> approval.
>>>>>> 
>>>>>> 
>>>>>> Files
>>>>>> -----
>>>>>> 
>>>>>> The files are available here:
>>>>>> https://www.rfc-editor.org/authors/rfc9284.xml
>>>>>> https://www.rfc-editor.org/authors/rfc9284.html
>>>>>> https://www.rfc-editor.org/authors/rfc9284.pdf
>>>>>> https://www.rfc-editor.org/authors/rfc9284.txt
>>>>>> 
>>>>>> Diff file of the text:
>>>>>> https://www.rfc-editor.org/authors/rfc9284-diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9284-rfcdiff.html
>> (side by
>>>>>> side)
>>>>>> 
>>>>>> Diff of the XML:
>>>>>> https://www.rfc-editor.org/authors/rfc9284-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/rfc9284.original.v2v3.xml
>>>>>> 
>>>>>> XMLv3 file that is a best effort to capture v3-related format
>>>>>> updates
>>>>>> only:
>>>>>> https://www.rfc-editor.org/authors/rfc9284.form.xml
>>>>>> 
>>>>>> 
>>>>>> Tracking progress
>>>>>> -----------------
>>>>>> 
>>>>>> The details of the AUTH48 status of your document are here:
>>>>>> https://www.rfc-editor.org/auth48/rfc9284
>>>>>> 
>>>>>> Please let us know if you have any questions.
>>>>>> 
>>>>>> Thank you for your cooperation,
>>>>>> 
>>>>>> RFC Editor
>>>>>> 
>>>>>> --------------------------------------
>>>>>> RFC9284 (draft-ietf-dots-multihoming-13)
>>>>>> 
>>>>>> Title            : Multi-homing Deployment Considerations for
>>>> Distributed-Denial-of-Service Open Threat Signaling (DOTS)
>>>>>> Author(s)        : M. Boucadair, T. Reddy.K, W. Pan
>>>>>> WG Chair(s)      : Valery Smyslov, Liang Xia
>>>>>> 
>>>>>> Area Director(s) : Roman Danyliw, Paul Wouters
>>>>> 
>>> 
>> 
>> 
>> 
>> 
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>