Martin Duke has entered the following ballot position for draft-ietf-taps-interface-22: Yes
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-taps-interface/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am excited about this doc, and can confirm based on some experience that this is basically implementable. Nevertheless there are a few problems, and potentially significant errors: (S4.1) "Namespaces for each of the keywords provided in the IANA protocol numbers registry ... are reserved for Protocol-specific Properties and MUST NOT be used for vendor or implementation-specific properties." It's regrettable that this excludes QUIC, TLS, HTTP, and other candidates for protocols operating under this API. Would it be too much to add a registry for additional reserved names? Indeed, there is enough noise in the protocol number registry it might be better to just have a registry of the 10? protocols that today might conceivably operate under TAPS. (S7.3) This section confused me as to whether ICE is done by the Transport Service (paragraph 4), the app (paragraph 8), or both. (I think it's both.) Maybe state this more explicitly? (S7.4) What happens if a Clone command results in a connection with different properties (e.g. in a second connection, the peer rejects the necessary TCP option)? (S8, paragraph 3) "Therefore, it is RECOMMENDED that Protocol-specific Properties are used for properties common across different protocols and that Protocol-specific Properties are only used where specific protocols or properties are necessary." I think the first instance of "protocol-specific properties should be "generic properties"? (S8.2) UTO is not TCP-specific! QUIC does it too. Maybe this should be a generic property? (S9.2.6) "The Transport Services API does order connPriority over msgPriority. In the absence of other externalities (e.g., transport-layer flow control), a priority 1 Message on a priority 0 Connection will be sent before a priority 0 Message on a priority 1 Connection in the same group." Everywhere in this doc, larger integers = higher priorities. So IIUC the Priority 1 connection should be sent first! _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
