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

["Panwei (William)" <[e-mail]>]

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]>; [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
> >