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

[Madison Church <[e-mail]>]

Hi All,

Eliot - Thank you for your quick review! We have added figure numbers to the figures in Sections 4.1 and 4.4, and we’ve also noted your approval on the AUTH48 status page. If any additional changes are needed, please let us know.

Dino and Colin - If you would like to provide SVG alternatives to the two figures, we will be more than happy to review and include them. Otherwise, once we receive author approvals for the document in its current form, we will move forward in the publication process.

Updated files have been posted below:
   https://www.rfc-editor.org/authors/rfc9962.txt
   https://www.rfc-editor.org/authors/rfc9962.pdf
   https://www.rfc-editor.org/authors/rfc9962.html
   https://www.rfc-editor.org/authors/rfc9962.xml
   https://www.rfc-editor.org/authors/rfc9962-diff.html
   https://www.rfc-editor.org/authors/rfc9962-rfcdiff.html (side by side)
   https://www.rfc-editor.org/authors/rfc9962-auth48diff.html
   https://www.rfc-editor.org/authors/rfc9962-auth48rfcdiff.html (side by side)

AUTH48 status page:
   https://www.rfc-editor.org/auth48/rfc9962

Thank you!
Madison Church
RFC Production Center

> On Apr 29, 2026, at 1:01 PM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
> 
> Ok.  Madison, if you're able to make the change, great.  Otherwise, assuming we get the figure #s in, the doc is approved.
> Eliot
> On 29.04.2026 19:44, Dino Farinacci wrote:
>> XML.
>> 
>> Dino
>> 
>> 
>>> On Apr 29, 2026, at 10:14 AM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>>> 
>>> Madison, Dino,
>>> The document looks good. I see two issues:
>>> • The two figures should be labeled; and
>>> • if and only if it's not a lot of work, it would be good to have an SVG alternative for each of the two figures. I'm sorry I didn't catch this earlier, because it's easy to do this using aasvg if using kramdown. Dino how did you mark this up? Direct XML or kramdown?
>>> Thanks,
>>> Eliot
>>> On 29.04.2026 18:24, Madison Church wrote:
>>> 
>>>> Hi Dino, *Eliot,
>>>> 
>>>> *Eliot - Please review the following update in Section 5.3 and let us know if you approve.
>>>> 
>>>> Previous:
>>>> When an xTR wants to register "[1000]fd::2222", it hashes the EID
>>>> string to produce, for example, hash value 0x66. Using the modulus
>>>> value 4 (0x67 & 0x3) produces index 0x3, so the DNS name 3.map-
>>>> server.lispers.net is used and a Map-Register is sent to <rloc1-au>
>>>> and <rloc2-nz>.
>>>> 
>>>> Current:
>>>> When an xTR wants to register "[1000]fd::2222/128", it hashes the EID
>>>> string to produce, for example, hash value 0x67. Using the modulus
>>>> value 4 (0x67 & 0x3) produces index 0x3, so the DNS name 3.map-
>>>> server.lispers.net is used and a Map-Register is sent to <rloc1-au>
>>>> and <rloc2-nz>.
>>>> 
>>>> Dino - Thank you for your quick reply! We have updated the files per your response and we just have one followup note for question 10.
>>>> 
>>>> 
>>>> 
>>>>>> 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).
>>>>> 
>>>>> 
>>>> Thank you for the clarification! We have kept "EID-prefix" in singular form and updated the rest of the text (i.e., we added "bytes" after 0-32 and 0-128). Let us know if any further changes are needed.
>>>> 
>>>> We have no further questions at this time. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process.
>>>> 
>>>> The files have been posted here (please refresh):
>>>> https://www.rfc-editor.org/authors/rfc9962.txt
>>>> https://www.rfc-editor.org/authors/rfc9962.pdf
>>>> https://www.rfc-editor.org/authors/rfc9962.html
>>>> https://www.rfc-editor.org/authors/rfc9962.xml
>>>> 
>>>> The relevant diff files have been posted here (please refresh):
>>>> https://www.rfc-editor.org/authors/rfc9962-diff.html (comprehensive changes)
>>>> https://www.rfc-editor.org/authors/rfc9962-rfcdiff.html (side by side)
>>>> https://www.rfc-editor.org/authors/rfc9962-auth48diff.html (AUTH48 changes only)
>>>> https://www.rfc-editor.org/authors/rfc9962-auth48rfcdiff.html (side by side)
>>>> 
>>>> For the AUTH48 status of this document, please see:
>>>> https://www.rfc-editor.org/auth48/rfc9962
>>>> 
>>>> Thank you!
>>>> Madison Church
>>>> RFC Production Center
>>>> 
>>>> 
>>>> 
>>