Hi Murray, Thanks for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Murray Kucherawy via Datatracker <[email protected]> > Envoyé : jeudi 16 février 2023 02:16 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected] > Objet : Murray Kucherawy's No Objection on draft-ietf-lisp-pubsub- > 13: (with COMMENT) > > 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. > [Med] Great. > 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? > [Med] Good catch. Merged the two bullets. > An editorial point: "ITR/RTR/PITR" or some variant of it appears > several times. > Could there be a single term that encapsulates all three? [Med] No as I know. > 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. > [Med] I have a preference to leave this as currently in the draft. That's long but more accurate. Thanks. > 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? [Med] This is an optimization. We are consuming up to 4 messages to cover the specific case where the xTR sent a Map-Notify-Ack but was lost in transmission, while 3 would be just OK when there is an issue in the Map-Server-to-xTR forwarding path. What we had initially in mind is to have a provision for a policy to disable this. > > 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? > [Med] Yes. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
