Change:
This implements the change I suggested in , and it also replaces "Protocol Specific Properties" with "protocol-specific Properties".
The example could be even more useful perhaps: /Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a connection could support a TCP-specific Transport Property, such as {{tcp-uto}}, in a protocol-specific parameter called ./
Done, in line with your suggestion. The wording is slightly different for several reasons: really using would be confusing because that particular property doesn't exist (there are, if you will, sub-properties). The {{tcp-uto}} reference expands as "Section ...", so using "such as" doesn't work; it's not a "protocol-specific parameter" but a "protocol-specific property". Oh and the connection is a Connection :-)
Specific suggestion you could start from: "For IETF protocols, the name of a Protocol-specific Property SHOULD be specified in a IETF document published in the RFC Series."
P.S. I would also be happy to continue with another recommendation, for additional transport properties that was proposed which says something like add it to the RFC.
URL are all the current protocols defined their Namespace in the respective RFCs? can we put a example reference? can we be more detailed on "SHOULD be defined in an RFC" actually mean?
My understanding is that this is meant as guidance for implementations, and for future RFCs to be written. If I write a TAPS system and provide a property that exists in QUIC only (and cannot reasonably be mapped to other protocols), then I should call it "quic.propertyname" - much like the TCP-specific properties in section 8.2. Similarly, future RFCs should define such namespaces if they offer properties that are protocol-specific. It seems that this second sentence poses quite a burden on the IETF in general, and may not be realistic - will people follow this? Suggested solution: remove the second sentence, and add a reference to section 8.2 to the first sentence to show an example.
I'm not sure removing the sentence is the right thing to do. To me this is like the rules to add to a registry, and we should simply describe what they ought to do: what I thought was intended was that the IETF ought to publish the binding in a RFC that defines the thing with a property, or (if necessary) a separate RFC.
It sounded like a too broad demand to make - e.g., RFC 9000 should then have such stuff in it. What if we would phrase this more like, e.g.: "Future RFCs that extend Transport Service systems SHOULD define property names under these namespaces."
I don’t read the problem the same here… your text suggests a property name needs to be in the spec itself - which might be good — but is more than my proposal that said the property name for transport systems SHOULD be defined in the RFC series. Although we might decide to say both. The potential problem as a WG Chair here is that there is no mechanism to remind or check that this is done. To me, it seems like if we had a registry, then we would have an IETF process to encourage ID authors to do the things in 4.1 and 4.2 of interface.
Ok, the phrase "SHOULD be in the RFC series" makes this leave the domain of my IETF knowledge - are we talking about an IANA registry here? Can we use a capital SHOULD as a request to IANA? Or what other form would that take? What would it mean to make such a SHOULD request to the IETF ("RFC series") as a whole? Suggestion: I update my PR to not remove the sentence, merge the PR without closing this issue, and you propose text?

Discussion:
Note that configuring Connection Properties and Message Properties on Preconnections is preferred over setting them later.  Early specification of Connection Properties allows their use as additional <del> input to the selection process.  Protocol Specific Properties, which </del> <ins> input to the selection process.  Protocol-specific Properties, which </ins> enable configuration of specialized features of a specific protocol, see Section 3.2 of I-D.ietf-taps-arch, are not used as an input to the selection process, but only support configuration if the

properties, i.e., for properties that are not specific to a protocol and are defined in an RFC. <del> Protocol Specific Properties MUST use the protocol acronym as the Namespace, e.g., "tcp" for TCP specific Transport Properties.  For IETF protocols, property names under these namespaces SHOULD be defined in an RFC. </del> <ins> Protocol-specific Properties MUST use the protocol acronym as the Namespace (e.g., a "tcp" Connection could support a TCP-specific Transport Property, such as the user timeout value, in a protocol- specific property called "tcp.userTimeoutValue" (see tcp-uto). </ins> Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace. <ins> For IETF protocols, the name of a Protocol-specific Property SHOULD be specified in an IETF document published in the RFC Series. </ins> Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol- <del> numbers/protocol-numbers.xhtml) are reserved for Protocol Specific </del> <ins> numbers/protocol-numbers.xhtml) are reserved for protocol-specific </ins> Properties and MUST NOT be used for vendor or implementation-specific properties.  Avoid using any of the terms listed as keywords in the protocol numbers registry as any part of a vendor- or implementation-

transport protocol stack.  Generic Connection Properties are defined in connection-props below. <del> Protocol Specific Properties are defined in a transport- and </del> <ins> Protocol-specific Properties are defined in a transport- and </ins> implementation-specific way to permit more specialized protocol <del> features to be used.  Too much reliance by an application on Protocol Specific Properties can significantly reduce the flexibility of a transport services implementation to make appropriate selection and configuration choices.  Therefore, it is RECOMMENDED that Protocol Properties are used for properties common across different protocols and that Protocol Specific Properties are only used where specific protocols or properties are necessary. </del> <ins> features to be used.  Too much reliance by an application on protocol-specific Properties can significantly reduce the flexibility of a transport services implementation to make appropriate selection and configuration choices.  Therefore, it is RECOMMENDED that Protocol Properties are used for properties common across different protocols and that Protocol-specific Properties are only used where specific protocols or properties are necessary. </ins> The application can set and query Connection Properties on a per- Connection basis.  Connection Properties that are not read-only can

Message Properties can be set and queried using the Message Context: <del> These Message Properties may be generic properties or Protocol Specific Properties. </del> <ins> These Message Properties may be generic properties or protocol- specific Properties. </ins> For MessageContexts returned by send Events (see send-events) and receive Events (see receive-events), the application can query