[auth48] Re: questions - Re: AUTH48: RFC-to-be 9962 <draft-farinacci-lisp-decent-22> for your review

[Dino Farinacci <[e-mail]>]

> Authors,
> 
> 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
> 
> 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.
> 
> Original:
>   LISP Decent
> 
> Current:
>   LISP-Decent

That is fine.

> b) How may we update the title of the document to introduce the expansion of
> "LISP"?
> 
> Current:
>   A Decent LISP Mapping System (LISP-Decent)
> 
> 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? 
> Specifically, the last item ("maintain") doesn't make sense with "can be", 
> i.e., please clarify "can be distributed, decentralized, and maintain".
> 
> Original:
>   This draft describes how the LISP mapping system can be distributed
>   for scale, decentralized for management and maintain trust among
>   data-plane nodes.
> 
> 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?
> 
> 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.
> 
> 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.
> 
> Original:
> It was presented in London March 2018 [MAR-WG-PRESO] and in Prague
> July 2019 [JUL-WG-PRESO].
> 
> 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" 
> as "the organization"? 
> 
> Current:  
> 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.
> 
> Perhaps: 
> 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. 

> 7) <!-- [rfced] Please clarify; what words are missing in this sentence
> between "intentional" and "all"? (The preceding sentence is included for context.)
> 
> Original: 
> This document does not describe any compatibility with other mapping
> systems. The design is intentional all xTRs and Map-Servers support
> this specification.
> 
> Perhaps:
> This document does not describe any compatibility with other mapping
> systems.  The design is intentional so that all xTRs and Map-Servers 
> 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 
> content that is semantically less important or tangential to the 
> 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. 
> Please review and let us know if you prefer otherwise.
> 
> 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.
> 
> 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?
> 
> 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).
> 
> 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 
> 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"? 
> 
> 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. 
> 
> 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) 
> was intended, please let us know.
> 
> Also, we updated the citation tags to [IETF101-PRESO] and [IETF104-PRESO]
> and updated the URLs to the presentations available on Datatracker.
> 
> Original:
>   [JUL-WG-PRESO]
>              Farinacci, D., "LISP WG July 2019 Presentation",
>              https://www.dropbox.com/scl/fi/3z7uichvi8x9940xlz6pm/lisp-
>              decent-ietf-prague.pdf?rlkey=4v1lup23zc0j6kpicqfr2npro,
>              July 2019.
> 
> 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 
> to conform with the RFC Style Guide, as to avoid ambiguity with
> RFC publication. Please let us know if you prefer otherwise.
> 
> Original:
>   The authors would also like to give a special thanks to 
>   Roman Shaposhnik for several discussions that occurred before 
>   the first draft was published.
> 
>   Eliot Lear and Victor Moreno are appreciated for their efforts 
>   proof reading the draft before Informational RFC publication.
> 
> Current:
>   The authors would also like to give a special thanks to 
>   Roman Shaposhnik for several discussions that occurred before 
>   the initial draft of this document.
> 
>   Eliot Lear and Victor Moreno are appreciated for their efforts 
>   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". 
> 
> 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.
> 
> 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 
> us know if you prefer one form over the other. If there are no objections, 
> we will use the form on the right.
> 
>   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 
>       (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.
> 
> Madison Church and Alice Russo
> RFC Production Center

Thank you so much Madison and Alice!

Cheers,
Dino