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

[[e-mail]]

Hi Éric, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker <[e-mail]>
> Envoyé : jeudi 16 février 2023 09:43
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Objet : Éric Vyncke's No Objection on draft-ietf-lisp-pubsub-13:
> (with COMMENT)
> 
> É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 ?
> 

[Med] I asked in the past for an update header for the draft but the WG call is to be conservative but consistent in all LISP specs. Please refer to the summary at: https://mailarchive.ietf.org/arch/msg/lisp/mWukquyGiXnsMwxxvCwhTY2K1HM/. We are following that conclusion. 

> ### 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.
> 

[Med] The key requirement is the following: 

   Servers SHOULD be configured with policies to control the maximum
   number of subscriptions and also the pace of Map-Notify messages.

Like with any rate limit recommendation, I don't think we can mandate by design a specific way to enforce it or how a server can control the number of state it maintains.

> 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.
> 

[Med] Not sure to get the point, Éric. Can you please clarify your concern? Thanks. 

_________________________________________________________________________________________________________________________

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.