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" _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
