Re: [re-ECN] CONEX problem statement

[Mirja Kuehlewind <[e-mail]>]

Hi,

some little comments below:

> 1. An applicability statement that consists of
> A. the functionality /capability that is expected to be provided by the
> conex mechanism itself, including its architectural features,
> limitations and assumptions it makes about networks and end systems
> B. deployment analysis - how the conex mechanism can be deployed in
> networks (non vs ECN vs [perhaps] Conex routers) and end systems
> C. security analysis - threats from falsifying or blanking conex info
I'm not sure if you can specify architectural features without having an 
concret mechanism. Regarding re-ECN this would be droper and policer, right? 
There might be different solutions possible... 


> 3. Transport-related Best practices and specifications:
> [1] for the transport of congestion information from the destination to
> the sender,
> [2] for ensuring the trustworthiness of the conex information
> Note: capability negotiation is out of scope, except to the extent that
> a Conex sender should either be able to work with a legacy destination
> or be able to fall-back to non-Conex operation.
I would say:  [1] requirements for the transport of congestion information....

BR,
Mirja