Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <20260428005324.14F232CCE6A@rfcpa.rfc-editor.org>
Date: Mon, 27 Apr 2026 19:13:29 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <EAFA6370-7181-45D4-955F-3E431885CF04@gmail.com>
References: <20260428005324.14F232CCE6A@rfcpa.rfc-editor.org>
To: rfc-editor@rfc-editor.org
Message-ID-Hash: 75BQ25F7ITNKIJV5D45WMMTKGTIGVSIB
CC: Colin Cantrell <colin@nexus.io>, rfc-ise@rfc-editor.org,
 auth48archive@rfc-editor.org, Dino Farinacci <farinacci@gmail.com>
Precedence: list
Subject: =?utf-8?q?=5Bauth48=5D_Re=3A_questions_-_Re=3A_AUTH48=3A_RFC-to-be_9962_=3Cd?=
 =?utf-8?q?raft-farinacci-lisp-decent-22=3E_for_your_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/auth48archive/aO2DXC6CZ_aSHXIrbsaq90biJgI>

> Authors,
>=20
> While reviewing this document during AUTH48, please resolve (as =
necessary) the following questions, which are also in the source file.

See responses inline.

> 1) <!-- [rfced] Title
>=20
> a) FYI - We have updated the short title of the document as follows to
> match the consistent hyphenation of "LISP-Decent". Please let us know =
any
> objections.
>=20
> Original:
>   LISP Decent
>=20
> Current:
>   LISP-Decent

That is fine.

> b) How may we update the title of the document to introduce the =
expansion of
> "LISP"?
>=20
> Current:
>   A Decent LISP Mapping System (LISP-Decent)
>=20
> Perhaps:
>   A Decent Locator/ID Separation Protocol Mapping System (LISP-Decent)
> -->

How about "A Decentralized Locator/ID Separation Protocol Mapping System =
(LISP-Decent)". Just so we don't duplicate "Decent".

> 2) <!-- [rfced] Please insert any keywords (beyond those that appear =
in
> the title) for use on https://www.rfc-editor.org/search. -->

None needed.

> 3) <!--[rfced] Abstract: How may this sentence be rephrased for =
clarity?=20
> Specifically, the last item ("maintain") doesn't make sense with "can =
be",=20
> i.e., please clarify "can be distributed, decentralized, and =
maintain".
>=20
> Original:
>   This draft describes how the LISP mapping system can be distributed
>   for scale, decentralized for management and maintain trust among
>   data-plane nodes.
>=20
> Perhaps:
>   This document describes how the Locator/ID Separation Protocol =
(LISP)
>   mapping system can be distributed for scale and decentralized for
>   management, while maintaining trust among data plane nodes.
> -->

Your revision is fine.

> 4) <!-- [rfced] Introduction: May we rephrase this sentence to avoid =
the
> redundancy of "and protocols" since the expansion of "LISP" is =
"Locator/ID
> Separation Protocol"? Additionally, may we rephrase for improved
> readability?
>=20
> Original:
>   The LISP architecture and protocols [RFC9300] introduces two new
>   numbering spaces, Endpoint Identifiers (EIDs) and Routing Locators
>   (RLOCs) that are intended to provide overlay network functionality.
>=20
> Perhaps:
>   The LISP architecture [RFC9300] introduces two new numbering spaces =
that
>   are intended to provide overlay network functionality: Endpoint
>   Identifiers (EIDs) and Routing Locators (RLOCs).
> -->

Your correction is great. Thanks.

> 5) <!-- [rfced] FYI - We updated this sentence, as IETF 104 was in =
Prague
> in March 2019, not July 2019.
>=20
> Original:
> It was presented in London March 2018 [MAR-WG-PRESO] and in Prague
> July 2019 [JUL-WG-PRESO].
>=20
> Current:
> It was presented in London in March 2018 [IETF101-PRESO] and
> in Prague in March 2019 [IETF104-PRESO].-->

Looks good.

> 6) <!-- [rfced] May we rephrase this sentence to clarify "who"=20
> as "the organization"?=20
>=20
> Current: =20
> The MSP can be managed by a separate organization other than the one
> that manages xTRs. This model provides a business separation between
> who manages and responsible for the control-plane versus who manages
> the data plane overlay service.
>=20
> Perhaps:=20
> The MSP can be managed by a separate organization other than the one
> that manages xTRs. This model provides a business separation between
> the organization that manages (and is responsible for) the control
> plane versus the organization that manages the data plane overlay
> service.
> -->

Looks good.=20

> 7) <!-- [rfced] Please clarify; what words are missing in this =
sentence
> between "intentional" and "all"? (The preceding sentence is included =
for context.)
>=20
> Original:=20
> This document does not describe any compatibility with other mapping
> systems. The design is intentional all xTRs and Map-Servers support
> this specification.
>=20
> Perhaps:
> This document does not describe any compatibility with other mapping
> systems.  The design is intentional so that all xTRs and Map-Servers=20=

> support this specification.
> -->

Looks fine.

> 8) <!-- [rfced] Please review whether any of the notes in this =
document
> should be in the <aside> element. It is defined as "a container for=20
> content that is semantically less important or tangential to the=20
> content that surrounds it" =
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
> -->

They should not be.

> 9) <!-- [rfced] FYI, we corrected the phrase "By doing a looking to" =
as follows.=20
> Please review and let us know if you prefer otherwise.
>=20
> Original:
> By doing a looking to this Map-Resolver for EID 233.252.1.1, the =
external xTR
> could get the complete list of members for the mapping system group.
>=20
> Current:
> By looking at the Map-Resolver for EID 233.252.1.1, the external xTR
> could get the complete list of members for the mapping system group.
> -->

Thanks for the correction.

> 10)       <!-- [rfced] May we update "EID-prefix" to "EID-prefixes" to =
match the
> plural form of "pairs"? Additionally, may we clarify the unit of
> measurement for the prefix lengths?
>=20
> Original:
>    The configuration consists of pairs of EID-prefix (the
>    well-known EID allocation range in CIDR notation, e.g.,
>    240.11.0.0/16) and lookup-length (the prefix length to use for
>    hash computation when EIDs fall within this range, 0-32 for
>    IPv4, 0-128 for IPv6).
>=20
> Perhaps:
>    The configuration consists of pairs of EID-prefixes (the well-known =
EID
>    allocation range in  Classless Inter-Domain Routing (CIDR) =
notation, e.g.,
>    240.11.0.0/16) and lookup-length (the prefix length to use for hash
>    computation when EIDs fall within this range, 0-32 bytes for IPv4 =
and
>    0-128 bytes for IPv6).
> -->

Should be singular. We are referring to one EID-prefix but the pair is a =
2-tuple of (EID-prefix, lookup-length).

> 11) <!-- [rfced] FYI - We have removed the <figure> element from the =
artwork in
> Section 5.2 for consistency with other artwork elements in this
> document, as they do not use this element. Please let us know if you
> prefer otherwise. If you would like to add <figure> elements around=20
> the artwork in this document, the result would be that each figure =
would
> be numbered and (optionally) have a title.
> -->

It doesn't matter to me as long as the figure remains readable and in =
the html version I reviewed, it looks fine.

> 12)     <!-- [rfced] We have removed "protocol" from instances of =
"LISP
> protocol" since the expansion would read as "Locator/ID Separation =
Protocol
> protocol". How can we rephrase the sentence below to avoid "LISP
> protocols"?=20
>=20
> Current:
>   By configuring the expected registration prefix length for each
>   allocation range, ITRs can reliably locate the correct Map-Servers
>   without modifying the LISP protocols or introducing complex
>   multi-level lookups.=20
>=20
> Perhaps:
>   By configuring the expected registration prefix length for each
>   allocation range, ITRs can reliably locate the correct Map-Servers
>   without modifying LISP or introducing complex
>   multi-level lookups.
> -->

This is fine and needed I think.

> 13) <!-- [rfced] FYI, this reference has been updated to March 2019 =
(IETF 104)
> because the URL provided shows March 2019.  However, if July 2019 =
(IETF 105)=20
> was intended, please let us know.
>=20
> Also, we updated the citation tags to [IETF101-PRESO] and =
[IETF104-PRESO]
> and updated the URLs to the presentations available on Datatracker.
>=20
> Original:
>   [JUL-WG-PRESO]
>              Farinacci, D., "LISP WG July 2019 Presentation",
>              =
https://www.dropbox.com/scl/fi/3z7uichvi8x9940xlz6pm/lisp-
>              decent-ietf-prague.pdf?rlkey=3D4v1lup23zc0j6kpicqfr2npro,
>              July 2019.
>=20
> Current:
>   [IETF104-PRESO]
>              Farinacci, D. and C. Cantrell, "A Decentralized Mapping
>              System: draft-farinacci-lisp-decent-03", IETF 104
>              Proceedings, March 2019,
>              <https://datatracker.ietf.org/meeting/104/materials/
>              slides-104-lisp-a-decent-lisp-mapping-system-00>.
> -->

Thanks for catching this.

> 14) <!-- [rfced] We have rephrased the following in the =
Acknowledgments=20
> to conform with the RFC Style Guide, as to avoid ambiguity with
> RFC publication. Please let us know if you prefer otherwise.
>=20
> Original:
>   The authors would also like to give a special thanks to=20
>   Roman Shaposhnik for several discussions that occurred before=20
>   the first draft was published.
>=20
>   Eliot Lear and Victor Moreno are appreciated for their efforts=20
>   proof reading the draft before Informational RFC publication.
>=20
> Current:
>   The authors would also like to give a special thanks to=20
>   Roman Shaposhnik for several discussions that occurred before=20
>   the initial draft of this document.
>=20
>   Eliot Lear and Victor Moreno are appreciated for their efforts=20
>   proofreading the draft before publication as an RFC.
> -->

Looks good.

> 15) <!-- [rfced] Please review the "Inclusive Language" portion of the =
online
> Style Guide
> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and =
let us
> know if any changes are needed.  Updates of this nature typically =
result in
> more precise language, which is helpful for readers. In particular, =
please
> consider whether "native" should be updated for clarity. A common
> replacement in RFCs for "native" is "built-in".=20
>=20
> Current:
> If a match is found, the ITR MUST use the configured lookup
> prefix length instead of the EID's native prefix length when
> computing the hash string.
>=20
> Perhaps:
> If a match is found, the ITR MUST use the configured lookup
> prefix length instead of the EID's built-in prefix length when
> computing the hash string.
> -->

Change "built-in prefix length" to "registered prefix length".

> 16) <!-- [rfced] Please review the form of the following terms and let=20=

> us know if you prefer one form over the other. If there are no =
objections,=20
> we will use the form on the right.
>=20
>   mapping system vs. Mapping System

Fine.

>   map-server vs. Map-Server

Good.

>   Group address 233.252.2.2 vs. group 233.252.2.2

I think you should keep "group address".

>   Decent-Pushed Based vs. Decent-Push-Based=20
>       (Updated to lowercase 'b' in running text: Decent-Push-based.)
> -->

Thanks.

> 17) <!-- [rfced] FYI - We have added expansions for abbreviations upon =
first use
> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> expansion in the document carefully to ensure correctness.
> -->

Looks good.

> Thank you.
>=20
> Madison Church and Alice Russo
> RFC Production Center

Thank you so much Madison and Alice!

Cheers,
Dino