Draft: draft-ietf-taps-interface

Commentary: Section 6 says . " Attempts to set Specific Protocol Properties on a protocol stack not containing that specific protocol are simply ignored , and do not raise an error " Should this be normative ? " Attempts to set Specific Protocol Properties on a protocol stack not containing that specific protocol MUST be ignored , and MUST NOT raise an error " I note that this a random sentence where spotted that normative language could be used . I do n't look for these kind of occasion systematically ... 
 I could see a case that the first requirement to ignore , I think this actually a requirement for predictable interop ? ( in which case we could motivate that ? ) I am much less sure of the second MUST , and think an error notification is not an interop issue ? 
 The first MUST is definitely important for code portability , and so I think this is a good suggestion . I 'm also less sure of the second MUST , but I think it 's good to keep : yes , errors can be ignored by an application , but they can also lead to application code like : adjust QUIC properties if error : adjust TCP properties If an application absolutely must do this and must find out what 's going on , it can , it 's ok for a Transport Services system to make everything readable ... but throwing errors in addition is yet another hint for a programmer to start developing code like this . We should discourage such code . That 's why I 'd keep the MUST NOT ( as a counter - example , " SHOULD NOT " would mean that there would have to be a good reason for the designer of a Transport Services system to make an exception - what would such a reason be ? " This particular function of this particular protocol is so important , I think here I should really throw an error after all ? " - Nah ... ) .
Paragraph (version A):
Connection Properties represent the configuration and state of the
selected Protocol Stack(s) backing a Connection.  These Connection
Properties may be Generic, applying regardless of transport protocol,
or Specific, applicable to a single implementation of a single
transport protocol stack.  Generic Connection Properties are defined
in connection-props below.  Specific Protocol Properties are defined
in a transport- and implementation-specific way, and MUST NOT be
assumed to apply across different protocols.  Attempts to set
Specific Protocol Properties on a protocol stack not containing that
specific protocol are simply ignored, and do not raise an error;
however, too much reliance by an application on Specific Protocol
Properties can significantly reduce the flexibility of a transport
services implementation.
Paragraph (version B):
Connection Properties represent the configuration and state of the
selected Protocol Stack(s) backing a Connection.  These Connection
Properties may be Generic, applying regardless of transport protocol,
or Specific, applicable to a single implementation of a single
transport protocol stack.  Generic Connection Properties are defined
in connection-props below.
Paragraph (version B):
Protocol Specific Properties are defined in a transport- and
implementation-specific way, and MUST NOT apply across different
protocols.  Too much reliance by an application on Protocol Specific
Properties can significantly reduce the flexibility of a transport
services implementation.