Change:
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> <ins> example with some Network Address Translator (NAT) traversal protocols (see rendezvous). </ins> 5.2.

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