Original text:
scope for alternate path discovery during Connection establishment. The Resolve() method is, however, provided to resolve a Local Endpoint or a Remote Endpoint in cases where this is required, for <del> example with some NAT traversal protocols (see rendezvous). </del>  5.2. be minimized at the expense of bandwidth efficiency.  This implies that the Connection may fail if the desired rate cannot be maintained across the Path.  A transport may interpret this <del> capacity profile as preferring a circuit breaker RFC8084 to a rate adaptive congestion controller. </del>  The application is not interactive.  It expects to send/receive a <del> large amount of data, without any urgency.  This can be used to select protocol stacks with scavenger transmission control, to signal a preference for less-than-best-effort treatment, and so on. </del>  5.3. established to the Remote Endpoint, or when the application is prohibited from rendezvous by policy. <del> When using some NAT traversal protocols, e.g., ICE RFC5245, it is expected that the Local Endpoint will be configured with some method of discovering NAT bindings, e.g., a STUN server.  In this case, the Local Endpoint may resolve to a mixture of local and server reflexive addresses.  The Resolve() method on the Preconnection can be used to discover these bindings: </del>  The Resolve() call returns a list of Preconnection Objects, that represent the concrete addresses, local and server reflexive, on Connection's Niceness value, M is the maximum Niceness value used by all Connections in the group and C is the total available capacity. However, the niceness setting is purely advisory, and no guarantees <del> are given about capacity allocation and each implementation is free to implement exact capacity allocation as it sees fit. </del>  7. Send Parameters may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is <del> sent.  For example, infinite Lifetime is not possible on a Message over a Connection not providing reliability.  Sending a Message with Send Properties inconsistent with the Transport Preferences on the Connection yields an error. </del>  The following send parameters are supported: 7.1.2. <del> Niceness represents an unbounded hierarchy of priorities of Messages, relative to other Messages sent over the same Connection and/or Connection Group (see groups).  It is most naturally represented as a non-negative integer.  A Message with Niceness 0 will yield to a Message with Niceness 1, which will yield to a Message with Niceness 2, and so on.  Niceness may be used as a sender-side scheduling construct only, or be used to specify priorities on the wire for Protocol Stacks supporting prioritization. </del>  <del> Note that this inversion of normal schemes for expressing priority has a convenient property: priority increases as both Niceness and Lifetime decrease. </del>  7.1.3. this message. Response time (latency) should be optimized at the expense of <del> bandwidth efficiency and delay variation when sending this </del>  message.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's algorithm); to prefer immediate acknowledgment from the peer endpoint when supported by the underlying transport; to signal a preference for lower-latency, higher-loss treatment; and so on. <del> Delay and delay variation should be minimized at the expense of bandwidth efficiency. </del>  This Message may be sent at the system's leisure.  This can be used to signal a preference for less-than-best-effort treatment, <del> to delay sending until lower-cost paths are available, and so on. </del>  7.2. the maximum Message size that can be received.  This property is read-only.  In order to specify Specific Protocol Properties, Transport System implementations may offer applications to attach a set of options to the Preconnection Object, associated with a specific protocol.  For

Reviewer comments:
and addresses
Section: Low Latency: : I really dislike the term /bandwidth efficiency/ - because we are not talking here of bandwidth in MHz, and certainly of not how efficiently the bandwidth is used from a radio perspective. Could we say /efficiently of using the available capacity/? I also have problems undrestaing what was intended by /and delay variation/ - because it doesn’t read correctly to me. What is intended? Section: Constant Rate: : still dislike /bandwidth efficiency/ - see above. /rate adaptive/ should this be /rate-adaptive/ ? Section: Scavenger/Bulk: : /for less-than-best-effort treatment, and so on./ can we explicitly point to the scavenger traffic class, rather than just the transport behaviour? e.g. add /or to assign the traffic to a lower effort service/ ?? Should we expand these abbreviations on first use?: NAT, ICE, STUN, SIP Section: Connection Groups {#groups} Could we consider removing the following clause ... I am not sure that I buy the specification text that reads: /An ideal transport system implementation would assign the Connection the capacity share (M-N) x C / M, where N is the Connection's Niceness value, M is the maximum Niceness value used by all Connections in the group and C is the total available capacity. / I’d prefer to feel comfortable that we have running code that does this - NEAT does not implement this approach, it could do something I am sure - but do we have to write this as if we specify this in the API? I do not like the words /about capacity allocation/ --- my rationale is that this doesn’t imply using an allocation method - I’d much prefer /about the way capacity is shared/ Similarly: /exact capacity allocation/ -- I’d prefer: /the way an implementation shares capacity/ /For example, infinite Lifetime is not possible on a Message over a Connection not providing reliability. / This didn’t read quite correct to me, is this better: /For example, it is not possible to set an infinite Lifetime for a Message over a Connection that does not provide reliability. / or /For example, a Connection must provide reliability to allow a Message to set an infinite Lifetime. / The concept of /an infinite Lifetime/ is just a tiny little odd, does this mean the value is set to infinite - or do we really expect persistent non-volatile storage of the message until it is sent?, I'd perhaps geel happier if we explained this as /an infinitie value for the lifetime property means that ..../ Section: Niceness {#send-niceness} The term /normal/ /Note that this inversion of normal schemes for expressing priority has a convenient property: priority increases as both Niceness and Lifetime decrease./ I wonder if this actually is clearer just to say: /This encoding of the priority has a convenient property that the priority increases as both Niceness and Lifetime decrease./ /It is most naturally represented as a non-negative integer./ the other terms are defined more concretely. Is there any reason we do not start the niceness section by saying Niceness is a numeric (non-negative integer) quantity. I didn't read the appendexes because I thought they were still being edited - happy to read when asked.
I'll try to take care of these early next week, together with a few other updates I planned for that period.
About this one: I'd rather keep this: otherwise it's not clarified anywhere what the real meaning of a niceness value is - is it a linear priority, is it like doubling priorities per value (as Harald was forced to invent here, for lack of any other available definition: URL ), or what? And BTW, indeed we do implement it like this in NEAT - AFAIK both the SCTP scheduler and Safiqul's coupled cc. kernel patch do this.
We need to distinguish between sending unreliably, but congestion controlled, and sending unreliably without congestion control (the application must know if it has to perform congestion control or not). This should influence at least the protocol and path selection properties.
lgtmLooks good

Revised text:
scope for alternate path discovery during Connection establishment. The Resolve() method is, however, provided to resolve a Local Endpoint or a Remote Endpoint in cases where this is required, for  <ins> example with some Network Address Translator (NAT) traversal protocols (see rendezvous). </ins> 5.2. be minimized at the expense of bandwidth efficiency.  This implies that the Connection may fail if the desired rate cannot be maintained across the Path.  A transport may interpret this  <ins> capacity profile as preferring a circuit breaker RFC8084 to a rate-adaptive congestion controller. </ins> The application is not interactive.  It expects to send/receive a  <ins> large amount of data, without any urgency.  This can, for example, be used to select protocol stacks with scavenger transmission control, to signal a preference for less-than-best-effort treatment, or to assign the traffic to a lower-effort service. 5.2.13. Type: Preference This property specifies whether the application would like the Connection to be congestion controlled or not.  Note that if a Connection is not congestion controlled, an application using such a Connection should itself perform congestion control in accordance with RFC2914.  Also note that reliability is usually combined with congestion control in protocol implementations, rendering "reliable but not congestion controlled" a request that is unlikely to succeed. </ins> 5.3. established to the Remote Endpoint, or when the application is prohibited from rendezvous by policy.  <ins> When using some NAT traversal protocols, e.g., Interactive Connectivity Establishment (ICE) RFC5245, it is expected that the Local Endpoint will be configured with some method of discovering NAT bindings, e.g., a Session Traversal Utilities for NAT (STUN) server. In this case, the Local Endpoint may resolve to a mixture of local and server reflexive addresses.  The Resolve() method on the Preconnection can be used to discover these bindings: </ins> The Resolve() call returns a list of Preconnection Objects, that represent the concrete addresses, local and server reflexive, on Connection's Niceness value, M is the maximum Niceness value used by all Connections in the group and C is the total available capacity. However, the niceness setting is purely advisory, and no guarantees  <ins> are given about the way capacity is shared.  Each implementation is free to implement a way it shares capacity that it sees fit. </ins> 7. Send Parameters may be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given Message is  <ins> sent.  For example, a Connection must provide reliability to allow setting an infinitie value for the lifetime property of a Message. Sending a Message with Send Properties inconsistent with the Transport Preferences on the Connection yields an error. </ins> The following send parameters are supported: 7.1.2.  <ins> Niceness is a numeric (non-negative) value that represents an unbounded hierarchy of priorities of Messages, relative to other Messages sent over the same Connection and/or Connection Group (see groups).  A Message with Niceness 0 will yield to a Message with Niceness 1, which will yield to a Message with Niceness 2, and so on. Niceness may be used as a sender-side scheduling construct only, or be used to specify priorities on the wire for Protocol Stacks supporting prioritization. </ins>  <ins> This encoding of the priority has a convenient property that the priority increases as both Niceness and Lifetime decrease. </ins> 7.1.3. this message. Response time (latency) should be optimized at the expense of  <ins> efficiently using the available capacity when sending this </ins> message.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's algorithm); to prefer immediate acknowledgment from the peer endpoint when supported by the underlying transport; to signal a preference for lower-latency, higher-loss treatment; and so on.  <ins> Delay should be minimized at the expense of efficiently using the available capacity. </ins> This Message may be sent at the system's leisure.  This can be used to signal a preference for less-than-best-effort treatment,  <ins> assign the traffic to a lower effort service, delay sending until lower-cost paths are available, and so on. </ins> 7.2. the maximum Message size that can be received.  This property is read-only. <ins> Congestion control: This boolean property informs about the protocol carrying out congestion control or not.  This property is read-only. </ins> In order to specify Specific Protocol Properties, Transport System implementations may offer applications to attach a set of options to the Preconnection Object, associated with a specific protocol.  For