Magnus Westerlund has entered the following ballot position for draft-ietf-anima-grasp-api-08: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-grasp-api/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- So I didn't have time to read your document in detail, thus I can easily have missed something. Hopefully a bit of clarification on what I might have missed will resolve this issue. I do wonder over one aspect of this API surface. How does it handles when the GRASP layer is unable to send the messages in a timely fashion based on the API calls? Looking at GRASP I understand that it is using either UDP or TCP. The rate limiting of UDP does not appear to be more well specified that to follow RFC 8085 recommendations. So my concern here is that you actually have some risk of running into that the upper layer using this API tries to become a bit to active and do everything at once, thus resulting in that TCP congestion control and flow control might block timely transmissions, and for UDP the rate limiter / congestion control of the UDP messages. What happens in this API when this occurs? _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
