Martin Duke has entered the following ballot position for draft-ietf-lisp-pubsub-12: 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: ---------------------------------------------------------------------- Thanks to Magnus for the TSVART review, and the authors for the extended (!) discussion of that review. I have a few notes: (S1) the sequence of events omits the Map-Notify-Ack in response to the initial Map-Notify. (S5) "If the Map-Request has only one ITR-RLOC with AFI=0..." I assume this Map-Request has the I-bit set? (S5) The paragraph about congestion control that begins with "As a reminder..." is probably better in S6, as originally discussed in the thread, because it's the Publish Map-Notifies that are the most likely to trigger congestion. (S6) Just to clarify, the Map-Notify has no change from RFC9301 with respect to flags (unlike the Map-Request)? (S6) "...it may stop trying to send the Map-Notify" This seems too weak to me; why not cancel the subscription, or better yet, cancel all subscriptions to that xTR if it's unresponsive? _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
