[lisp] Warren Kumari's No Objection on draft-ietf-lisp-pubsub-11: (with COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-lisp-pubsub-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-pubsub/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Much thanks to Al Morton for the OpsDir review
(https://datatracker.ietf.org/doc/review-ietf-lisp-pubsub-10-opsdir-lc-morton-2023-01-22/)
I'm at a conference (NANOG) this week, and so the OpsDir reviews are especially
useful.

I've provided some nits below -- feel free to address them when making other
changes, or ignore them (they are just nits): 1: "The Locator/ID Separation
Protocol (LISP) [RFC9300] [RFC9301] splits IP addresses in two different
namespaces" - I think this is: "splits IP addresses into two different
namespaces"

2: "It is RECOMMENDED that the xTR uses persistent storage to keep nonce
state." - I think this would be better as: "to keep the none state"

3: "The Map-Server that receives the Map-Request will be the Map-Server
responsible to notify that specific xTR " -> "responsible for notifying"

4: "A similar problem may be experienced when a large number of state were
simultaneously updated." - "states are"

5: "Alternatively, the Map-Server can instead determine that such subscription
request fails, and send" - "requests fail"

6: "When the ITR wants to update the security association for that Map-Server
and EID-Prefix, it follows again the procedure described in this section."  --
I think that this is either "it follows the procedure described in this section
again.", or 9probably better) "it once again follows..."

7: "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." - for readability, I think this would be better as "take place" or
"occur".

8: "Misbehaving nodes may send massive subscription requests which may lead to
exhaust the resources of a Map-Server" - "exhausting"

9: (Appendix): "The following subsections provides an inventory of some
experience lessons from these deployments." - "provide"