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

[tirumal reddy <[e-mail]>]

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-4Q9l2USxIAe6P8O4Zc
> >
> >     *  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
>
>