[lisp] Éric Vyncke's No Objection on draft-ietf-lisp-pubsub-13: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke 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:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-lisp-pubsub-13
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Luigi Iannone for the shepherd's detailed write-up including
the WG consensus.

Other thanks to Sheng Jiang, the Internet directorate reviewer (at my request),
please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-lisp-pubsub-10-intdir-telechat-jiang-2023-02-09/
and I read the author's reply.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Updating RFC 9301 ?

Like Erik Kline, I wonder whether this I-D should formally update RFC 9301. Or
is the IANA registry addition enough ?

### Section 5 and intended status

```
The exact details to characterize such policies are deployment and
implementation specific. Likewise, this document does not specify which
notifications take precedence when these policies are enforced. ```

This is indeed my biggest concern about this mechanism as it can trigger a
flood of Map-Notify when a EIP mapping changes. PubSub is nice when there is
one publisher and many potential subscribers but in this specific case it is
several publishers to several subscribers with many subscriptions.

An experimental status would be more comforting.

### Missed notification

If for any reason a Map-Notify is missed (e.g., publisher is overloaded), then
what is the fall-back ? When a Map-Request gets no response, then the
Map-Request can be resent by the xTR but in the case of Map-Notify ? There is
some text in section 5, but only from the point of view of the publisher.

### Appendix A.1

The monitoring use case is indeed quite a useful one. My comments above do not
really apply in this use case.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments