Document: draft-ietf-tsvwg-usr-exp Title: User Ports for Experiments Reviewer: Tim Evens Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-tsvwg-usr-exp-?? Reviewer: Tim Evens Review Date: 2025-08-06 IETF LC End Date: 2025-08-04 IESG Telechat date: Not scheduled for a telechat Summary: Overall the draft is well written and addresses an issue with developer use of layer 4 ports (UDP, TCP, ...) that may have otherwise been privileged or disallowed by security control points. The draft aims to standardize a range of user ports for experimental (aka developer) use, starting with two ports, that supports multiplexing to scale the usage of the user ports. I like the simplistic multiplexing approach using a single 4-byte PExID, but I am concerned that the simplistic method may not scale to future requirements that may need some flags or additional TLVs. Major issues: None Minor issues: There are developer use-cases, especially within labs, that need help from the network infrastructure to ensure traffic does not leak out of contained labs/etc. Security inspection points, such as a firewall, are used to catch a leak and filter it. I see this basic requirement missing for containment of developer/experiment user ports and PExIDs from being leaked out. There is no indication to the FW that it should drop or allow the packet based on PExID. Suggest to define a PExID range for IANA to be used where no registration will exist. If there is no registration, I would tend to expect that packets would not be allowed outside of containment (aka LAB, local, ...). In other words, no public internet or corporate network access allowed within this PExID range. If there is a registration, maybe that should indicate scope of where these packets should be forwarded... Might make sense to define a range for some basic scopes, such as allowed within LAB only, allowed within local/enterprise/campus, allowed everywhere including internet. I don't believe this needs to go into the weeds of authorization... There is a pre-established trust with the experimental user-ports and PExIDs. These scopes are more of a safe guard to prevent accidental leakage of traffic that should have not been allowed out of an experiment/lab. Nits/editorial comments: -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
