Hi all,
I’ve been going through the FANTEL problem statement and I had a few questions and thoughts about the security considerations that I wanted to flag with the group. I was curious about the trust boundary around subscriptions. Since the document introduces the idea of recipient nodes “subscribing” to specific classes of notifications, are there expectations for how implementations authenticate and authorize subscribers? Could an attacker register for a large number of subscription categories (or register repeatedly) and consume resources or gain access to detailed information that might otherwise not be visible? I also didn’t see much discussion of authorization for “who is allowed to send what.” It seems important to ensure that only the correct devices are permitted to originate certain types of events otherwise a compromised or misconfigured node might try to influence traffic behaviour outside of its intended scope. What is the intent for authorization? Finally, the document acknowledges that FANTEL may expose sensitive operational data. Could the document include text around confidentiality expectations? For example, could it discuss scenarios where the notification payloads must be encrypted? I am interested in hearing how others are thinking about these aspects. If any of this is already being addressed in companion drafts, feel free to point me in that direction. Thank you, Dan. On Fri, Jan 16, 2026 at 6:12 AM Yingzhen Qu via Datatracker < [email protected]> wrote: > This message starts a rtgwg WG Call for Adoption of: > draft-dong-fantel-problem-statement-03 > > This Working Group Call for Adoption ends on 2026-01-30 > > Abstract: > Modern networks require adaptive traffic manipulation including > Traffic Engineering (TE), load balancing, flow control, and > protection, to support high-throughput, low-latency, and lossless > applications such as Artificial Intelligence (AI) /Machine Learning > (ML) training and real-time services. A good and timely > understanding of network operational status, such as congestion and > failures, can help to improve network utilization, enable the > selection of paths with reduced latency, and enable faster response > to critical events. This document describes the existing problems > and why a new set of fast network notification solutions are needed. > > Please reply to this message and indicate whether or not you support > adoption > of this Internet-Draft by the rtgwg WG. Comments to explain your preference > are greatly appreciated. Please reply to all recipients of this message and > include this message in your response. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > Appropriate IPR disclosures required for full conformance with the > provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can be > found at [3]. > > Thank you. > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-dong-fantel-problem-statement/ > > There is also an HTMLized version available at: > > https://datatracker.ietf.org/doc/html/draft-dong-fantel-problem-statement-03 > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-dong-fantel-problem-statement-03 > > _______________________________________________ > rtgwg mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
