Murray Kucherawy has entered the following ballot position for draft-ietf-lisp-pubsub-13: 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 for a well done IANA Considerations section. In Section 1, in that list of steps, it looks strange that in step 1 you send a request, and then in step 2 you mutate a bit on the request. Is that possible? Or would it be better to say that in step 1 you construct a request that has this bit set, and in step 2 you send it? An editorial point: "ITR/RTR/PITR" or some variant of it appears several times. Could there be a single term that encapsulates all three? Repeating that cluster of initialisms has me reading it like "this or that or the other" each time, and it feels like it could be simplified. In Section 5: "If the Map-Server removes the subscription state, it SHOULD notify the xTR by sending a single Map-Notify with the same nonce but with Loc-Count = 0 (and Loc-AFI = 0), and ACT bits set to 5 "Drop/Auth-Failure"." Why is this only a SHOULD? Also in Section 5: "If the subscription request fails, the Map-Server MUST send a Map-Reply to the originator ..." That should be a "Negative Map-Reply", right? _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
