These are my recommendations: Section 4: Change this: xTR-ID bit (I-bit): This bit is set to 1 to indicate that a 128 bit xTR-ID and a 64-bit Site-ID fields are present at the end of the Map-Request message. To this: xTR-ID bit (I-bit): This bit is set to 1 to indicate that 128 bit xTR-ID and 64-bit Site-ID fields are present at the end of the Map-Request message. Change this: If the I-bit is set but the Site-ID and/or xTR-ID are not included, a receiver can detect the error because after processing that last EID-record, there are no bytes left from processing the message. To this: If the I-bit is set, but the Site-ID and/or xTR-ID are not included, a receiver can detect the error because, after processing that last EID-record, there are no bytes left from processing the message. Section 5: Change this: The xTR subscribes for changes for a given EID-Prefix by sending a Map-Request to the Mapping System with the N-bit set on the EID-Record To this: The xTR subscribes for changes, to a given EID-Prefix, by sending a Map-Request to the Mapping System with the N-bit set on the EID-Record Change this: The xTR processes this Map-Notify as described in Section 5.7 of [RFC9301] with the following considerations. The xTR MUST use the Map-Notify to populate its Map-Cache with the returned EID-Prefix and RLOC-set. To this: I'm expecting a ":" after considerations and then a list of those considerations, but just see a new sentence. Perhaps make it one sentence: The xTR processes this Map-Notify, as described in Section 5.7 of [RFC9301], and MUST use the Map-Notify to populate its Map-Cache with the returned EID-Prefix and RLOC-set. Change this: The following specifies the procedure to remove a subscription. To this: I'm expecting a ":" after subscription. Perhaps either add the ":" or remove the sentence. Section 6: Change this: The complete mechanism works as follows. To this: I'm expecting a ":" after follows. Either add the ":" or remove the sentence. Change this: The xTR processes the received Map-Notify as specified in Section 5.7 of [RFC9301], with the following considerations. To this: I'm expecting a ":" after considerations. Either add the ":" or remove the sentence. Section 7.1: Change this: Since Map-Notifies from the Map-Server to the ITR need to be... To this: Since Map-Notifies from the Map-Server to the ITR needs to be... Change this: Otherwise, if the Map-Server has to reply with a Map-Notify (e.g. due to subscription accepted) to a received Map-Request, the following extra steps take place. To this: ...extra steps take place: Change this: Note that if the Map-Server replies with a Map-Notify, none of the regular LISP-SEC steps regarding Map-Reply described in Section 5.7 of [RFC9303] takes place) To this: Note that if the Map-Server replies with a Map-Notify, none of the regular LISP-SEC steps regarding Map-Reply, described in Section 5.7 of [RFC9303], takes place. Section 8.2: Change this: Section 8.1 of [RFC9301] suggests two TTL values for Negative Map- Replies, To this: Section 8.1 of [RFC9301] suggests two TTL values for Negative Map- Replies: Section 8.3: Change this: Deployment experience reveals that data-driven SMRs and PubSub mechanisms complement each other well and combined provide a fast and resilient network infrastructure in the presence of mobility events. To this: Deployment experience reveals that data-driven SMRs and PubSub mechanisms complement each other and provide a fast and resilient network infrastructure in the presence of mobility events. Change this: Concretely, in scenarios with significant traffic coming from outside of the LISP network, the experience showed that enabling PubSub in the border routers, significantly improves mobility latency overall, even if edge xTRs do not implement PubSub and traffic exchanged between EID-Prefixes at the edge xTRs still converges based on data- driven events and SMR-triggered updates. To this: In scenarios with significant traffic coming from outside of the LISP network, the experience showed that enabling PubSub in the border routers significantly improves mobility latency overall. Even if edge xTRs do not implement PubSub, and traffic is exchanged between EID-Prefixes at the edge, xTRs still converge based on data- driven events and SMR-triggered updates. Section 8.5: Change this: Interestingly, with PubSub at least the Map-Cache is updated with the correct RLOC information, even when it is not being used or waiting to expire, which helps debugging. To this: With PubSub, the Map-Cache is updated with the correct RLOC information, even when it is not being used or waiting to expire, and this helps with debugging.