Subject: Re: [re-ECN] Advancing CONEX work

From: Bob Briscoe <[email-masked]>
Date: Mon, 01 Feb 2010 16:51:04 +0000

Folks,

As we've started the 'any volunteers?' phase, I just want to make my 
role clear in this, given we developed and nurtured this idea at the 
start (and perhaps to also clarify the role of my colleagues in BT, 
but they can speak for themselves)...

If ConEx is going to fly, we need to hand over as much knowledge as 
we have gained as efficiently as possible. That won't be helped if we 
take the leading role in too much of the IETF doc writing. I'm v 
willing to help, and review, and people can copy and paste anything 
we've written in the past (with due acknowledgement). But, if you 
want to volunteer, don't worry that I might be annoyed that you're 
taking my baby away from me. Go! take it! - it's a teenager now (in 
Internet years) - ask my sons - I lost interest at that point!

Seriously, I don't mind having a role in one or two docs. But 
primarily, my goal now is to widen this effort.

Personally, I want to spend more time on quantifying and explaining 
the benefits relative to alternative directions.

Bob

At 17:20 29/01/2010, [email-masked] wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01CAA107.4A5D4388"
>
>The draft Charter is on next week's IESG agenda, so hopefully we'll 
>hear some good news soon. We've asked for a session in Anaheim, on 
>the basis that we'll either have a WG by then or else we can have a 
>"working" bof as the charter will be near final sign-off.
>
>So we should make progress on the first items of our presumed charter:
>
> >>Feb 2010 Internet-Draft functionality statement (Output item 1A) Mar
> >>2010 Internet-Draft applicability statement (Output item 1A, B, C)
>
>The idea was for some short intensive discussion on "functionality", 
>then some short intensive discussion on deployability & security goals.
>
>The best step might be for a volunteer(s) please to be "editor" on 
>this initial item(s). The role would be to summarise the existing 
>thinking, as a first step, and then to lead /capture discussion.
>
>Hopefully the output can be quite short - a number of bullets such 
>as "a mechanism to allow senders to inform the network of the level 
>of congestion they expect their packets to encounter"; "the 
>information the sender adds is a RTT out of date"; etc.
>
>In more detail:-
>
>1. An applicability statement that describes:
>
>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. deployability goals - how the CONEX mechanism can be deployed in 
>networks (non vs ECN vs perhaps CONEX routers) and end systems
>
>C. security goals - addressing threats from falsifying or blanking CONEX info
>
>The purpose is
>
>[1] to detail the key functional and non-functional considerations 
>that guide the work on the mechanism's design
>
>[2] to allow exploration of use cases to begin before work on the 
>mechanism is complete
>
>[3] to provide an intuitive explanation of the new concepts in CONEX
>
>Please shout if you'd like to volunteer to be "editor" on this 
>initial item(s).
>
>Thanks
>Leslie & Phil.
>_______________________________________________
>re-ECN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design