Draft: draft-ietf-taps-interface

Commentary: 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 does n't exist ( there are , if you will , sub - properties ) . The { { tcp - uto } } reference expands as " Section ... " , so using " such as " does n'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 . 
 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 can not 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 do n’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    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 ?
Paragraph (version A):
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
input to the selection process.  Protocol Specific Properties, which
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
respective protocol has been selected.
Paragraph (version B):
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
input to the selection process.  Protocol-specific Properties, which
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
respective protocol has been selected.
Paragraph (version A):
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.
Paragraph (version A):
Namespaces for each of the keywords provided in the IANA protocol
numbers registry (see https://www.iana.org/assignments/protocol-
numbers/protocol-numbers.xhtml) are reserved for Protocol Specific
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-
specific property name.
Paragraph (version B):
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).
Paragraph (version B):
For IETF protocols, the name of a Protocol-specific Property
SHOULD be specified in an IETF document published in the RFC
Series.
Paragraph (version B):
Namespaces for each of the keywords provided in the IANA protocol
numbers registry (see https://www.iana.org/assignments/protocol-
numbers/protocol-numbers.xhtml) are reserved for protocol-specific
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-
specific property name.
Paragraph (version A):
Protocol Specific Properties are defined in a transport- and
implementation-specific way to permit more specialized protocol
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.
Paragraph (version B):
Protocol-specific Properties are defined in a transport- and
implementation-specific way to permit more specialized protocol
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.
Paragraph (version A):
These Message Properties may be generic properties or Protocol
Specific Properties.
Paragraph (version B):
These Message Properties may be generic properties or protocol-
specific Properties.