Change:
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> <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 <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> <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.

Discussion:
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