Draft: draft-ietf-taps-interface

Commentary: We do n't have " Protocol Properties " - two occurrences in -interface should really refer to " protocol - specific Properties " , and two occurrences in -impl should really refer to properties . 
 Are Protocol Specific Properties and Protocol Properties same or different ? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties ) and not introduced in the architecture document . I think we should be clear about what we are defining where and describing where . I would suggest use of cross reference rather describing everything again and again , which might create confusion and inconsistency . 
 Oh , this seems like a mistake ( great catch , thanks ! ) - " Protocol Properties " do n't exist , I think we only have " protocol - specific Properties " . 
 I caught this when reading the implementation doc . So it should be fixed there as well .
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-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.
Paragraph (version A):
A request by an application for Protocol Properties that cannot be
satisfied by any of the available protocols.  For example, if an
application requires "perMsgReliability", but no such feature is
available in any protocol on the host running the transport system
this should result in an error, e.g., when SCTP is not supported
by the operating system.
Paragraph (version A):
A request by an application for Protocol Properties that are in
conflict with each other, i.e., the required and prohibited
properties cannot be satisfied by the same protocol.  For example,
if an application prohibits "reliability" but then requires
"perMsgReliability", this mismatch should result in an error.
Paragraph (version B):
A request by an application for properties that cannot be
satisfied by any of the available protocols.  For example, if an
application requires "perMsgReliability", but no such feature is
available in any protocol on the host running the transport system
this should result in an error, e.g., when SCTP is not supported
by the operating system.
Paragraph (version B):
A request by an application for properties that are in conflict
with each other, i.e., the required and prohibited properties
cannot be satisfied by the same protocol.  For example, if an
application prohibits "reliability" but then requires
"perMsgReliability", this mismatch should result in an error.
Paragraph (version A):
The set of Connection Properties that are supported for setting and
getting on a Connection are described in I-D.ietf-taps-interface.
For any properties that are generic, and thus could apply to all
protocols being used by a Connection, the Transport Services
implementation should store the properties in storage common to all
protocols, and notify all protocol instances in the Protocol Stack
whenever the properties have been modified by the application.  For
protocol-specfic properties, such as the User Timeout that applies to
TCP, the Transport Services implementation only needs to update the
relevant protocol instance.
Paragraph (version B):
The set of Connection Properties that are supported for setting and
getting on a Connection are described in I-D.ietf-taps-interface.
For any properties that are generic, and thus could apply to all
protocols being used by a Connection, the Transport Services
implementation should store the properties in storage common to all
protocols, and notify all protocol instances in the Protocol Stack
whenever the properties have been modified by the application.  For
Protocol-specific Properties, such as the User Timeout that applies
to TCP, the Transport Services implementation only needs to update
the relevant protocol instance.