Subject: [re-ECN] Complete draft Charter for proposed CONEX WG

From: <[email-masked]>
Date: Tue, 8 Dec 2009 15:28:38 -0000

Hi,
We've now added a draft list of Milestones to the problem statement and
Output already discussed. 
Please send comments as soon as possible - hoping to get into IESG next
week. 
Thanks
Phil & Leslie
---

The purpose of the CONEX working group is to develop a mechanism to 
allow senders to inform the network of the level of congestion they 
expect their packets to encounter. This information is currently only 
visible at the transport layer. With the output of CONEX, it will be 
possible to provide sufficient information in each IP datagram so that 
any node in the network can see the expected rest-of-path congestion. 
Once any node can see the impact it causes (and suffers) by sending or 
forwarding packets, it will be possible to hold senders and whole 
networks accountable for the congestion they cause downstream. Tools 
that exploit the CONEX output could be used for mitigating distributed 
denial of service (DDoS); simplifying differentiation of quality of 
service (QoS); policing compliance to congestion control; and so on.

Intended output of the WG:

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

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

2. Specification of IP (v4 & v6) packet structure to carry CONEX
information (header bits, interpretation)

3. Transport-related Best practices and specifications:

A. for the transport of congestion information from the destination to
the sender,

B. 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.

4. Use cases -- possible uses of CONEX information to reduce congestion
and/or increase the accountability for it. The main purpose is to
encourage experiments that use CONEX information and to describe their
results; it is not to delineate all potential uses cases, nor to provide
a full architectural/deployment/security analysis of use cases. Future
work may include specifications to implement one or more use cases.

The output is Informational and Experimental, apart from #2 which is
tentatively slated as Standards track.

Milestones

Feb 2010 Internet-Draft functionality statement (Output item 1A)

Mar 2010 Internet-Draft applicability statement (Output item 1A, B, C)

Mar 2010 Internet-Draft(s) for CONEX IPv4 & IPv6 specifications (Output 
item 2)

May 2010 Internet-Draft use cases (Ouput item 4)

Jun 2010 First WG draft CONEX IPv4 specification

Jun 2010 First WG draft CONEX IPv6 specification

Jun 2010 Draft transport-related best practices

Jun 2010 Proposals (individual I-Ds) for TCP modification (Ouput item
3A)

Jun 2010 Proposals (individual I-Ds) for mechanism to ensure
trustworthiness of CONEX information (Ouput item 3B)

Sep 2010 Complete applicability statement (sent to IESG)

Nov 2010 CONEX IPv4 specification to WGLC

Nov 2010 CONEX IPv6 specification to WGLC

Jan 2011 Complete IPv4 specification (sent to IESG)

Jan 2011 Complete IPv6 specification (sent to IESG)

Mar 2011 Spec of TCP modification to WGLC

Mar 2011 Spec of mechanism to ensure trustworthiness to WGLC

Mar 2011 Transport-related best practices to WGLC

Mar 2011 Use cases to WGLC

May 2011 Complete remaining docs (sent to IESG)

Jun 2011 Close or re-charter

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 8 Dec 2009 16:47:29 +0100

Hi,

see below

> visible at the transport layer. 
I would add the end systems here: "This information is currently only visible 
at the transport layer in the end systems."

> With the output of CONEX, it will be 
Maybe change the order here: "Tools that exploit the CONEX output could be 
used for simplifying differentiation of quality of service (QoS); policing 
compliance to congestion control; mitigating distributed denial of service 
(DDoS); and so on."

BR,
Mirja

---

From: <[email-masked]>
Date: Tue, 8 Dec 2009 18:36:16 -0000

Thanks Mirja - both changes work for me
phil

> -----Original Message-----
> From: Mirja Kühlewind [mailto:[email-masked]] 
> Sent: 08 December 2009 15:47
> To: [email-masked]
> Cc: Eardley,PL,Philip,DEE1 R
> Subject: Re: [re-ECN] Complete draft Charter for proposed CONEX WG
> 
> 
> Hi,
> 
> see below
>

---

From: <[email-masked]>
Date: Wed, 9 Dec 2009 09:58:57 -0000

Some suggestions/correction inline...

> From: Moncaster,T,Toby,DEE1 R
> Sent: 09 December 2009 09:37
> To: Moncaster,T,Toby,DEE1 R
> Subject: Complete draft Charter for proposed CONEX WG
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: 08 December 2009 15:29
> To: [email-masked]
> Subject: [re-ECN] Complete draft Charter for proposed CONEX WG
> 
> Hi,

The CONEX working group will develop mechanisms to

> visible at the transport layer. 

Although I agree with Mirja's comment, an argument that could be made to
say the information is visible in the network if you use DPI
equipment... However I think highlighting that only the end-systems are
DESIGNED to see the info is a good thing...

> any node in the network can see the expected rest-of-path congestion.

I think I would prefer to say "The main output of CONEX will be a
protocol that allows each IP datagram to carry sufficient information to
allow any node in the network to see the whole path congestion." I make
the subtle distinction between rest of path and whole path so that we
leave the door open for Matt Mathis's mark on drop suggestion...

> 1. An applicability statement that consists of

Don't like "consists of" would prefer something like "explains" or
"describes"

> A. the functionality / capability that is expected to be provided by
> the CONEX mechanism itself, including its architectural features,

Including analysis of the impact of full vs partial deployment (or
something like this - highlight that what matters is how we get to a
system that is useful) 

> C. security analysis - threats from falsifying or blanking CONEX info

Think I would just all that a threat analysis and I think there is a
good chance it could exist as a separate document...

> 3. Transport-related Best practices and specifications:

Add the word "covering" after specifications...

> A. for the transport of congestion information from the destination to

For the timely transport ?

> or be able to fall-back to non-CONEX operation.

Somewhere in work items 2 or 3 we need to specifically refer to a need
to mitigate those threats identified in the threat analysis...

> and/or increase the accountability for it. 

This first sentence seems to pre-suppose which use cases are of
interest... Perhaps change it to "possible uses of CONEX information
which include controlling or reducing congestion and increasing
accountability for congestion."

> The main purpose is to
> results; it is not to delineate all potential uses cases, nor to
> provide a full architectural/deployment/security analysis of use
cases.
> Future work may include specifications to implement one or more use
> cases.

Highlight that we expect there to be a number of use case documents (or
a number of sections within a master use case document).

> Jun 2011 Close or re-charter

My word that's an exhaustive list of milestones! For simplicity can we
also break out the list of intended publication dates for the final
outputs? My personal instinct is that we should be able to publish the
applicability statement in July or at least WGLC it. Also sometime round
November 2010 we need to actually select which individual IDs we are
progressing for TCP and trustworthiness...

Toby

---

From: John Leslie <[email-masked]>
Date: Wed, 9 Dec 2009 06:30:05 -0500

[email-masked] <[email-masked]> wrote:
> say the information is visible in the network if you use DPI equipment...

   That is an argument we need to rebut: Deep Packet Inspection is not
sufficient to show congestion management -- merely to infer reasonable
guesses from artifacts of congestion managment, which is not good
enough to act upon.

> However I think highlighting that only the end-systems are DESIGNED to
> see the info is a good thing...

   Even this is subtly wrong. There are many different congestion-control
schemes in current use. Most, but not all, are designed to infer packet
loss and interpret that as congestion. We are not talking about getting
every router along the path to have the same view of packet loss: we
are talking about getting every router along the way to have the same
view of expected congestion _whether_or_not_ any packets are ever
dropped.

> allow any node in the network to see the whole path congestion."

   This is a good issue to raise.

   But I don't agree with Toby: any congestion _earlier_ in the path is
of no concern to a router -- there is nothing reasonable to _do_ about
it. Even if we don't actually design algorithms about what to do about
rest-of-path congestion, that remains the concern to consider. (Said
differently, there's no point in punishing congestion _after_ the last
bottleneck in the path.)

> I make the subtle distinction between rest of path and whole path so
> that we leave the door open for Matt Mathis's mark on drop suggestion...

   I'm happy to leave that door open, but I don't think Toby's suggestion
is necessary to do so.

--
John Leslie <[email-masked]>

---

From: <[email-masked]>
Date: Thu, 10 Dec 2009 10:40:45 -0000

Thanks toby & john
> The CONEX working group will develop mechanisms to

"mechanisms" might imply that we going to develop several different ways
of doing this.
So I prefer keeping as "a mechanism" (albeit one with several parts -
which I think was your point)

> > visible at the transport layer.

I think everyone so far is ok with mirja's suggestion to add "in the end
systems", please shout if I mis-interpreted.

> Although I agree with Mirja's comment, an argument that could 
> be made to say the information is visible in the network if 
> you use DPI equipment... However I think highlighting that 
> only the end-systems are DESIGNED to see the info is a good thing...
> 
> I think I would prefer to say "The main output of CONEX will 
> be a protocol that allows each IP datagram to carry 
> sufficient information to allow any node in the network to 
> see the whole path congestion." I make the subtle distinction 
> between rest of path and whole path so that we leave the door 
> open for Matt Mathis's mark on drop suggestion...

Please can you remind me what Matt's suggestion is. 
At the moment, prefer to leave as "rest-of-path congestion" (knowing one
implies knowing the other, and rest-of-path emphasises the new info
useful for a router, as john says)

> > Intended output of the WG: 1. An applicability statement 
> that consists 
> > of
> 
> Don't like "consists of" would prefer something like 
> "explains" or "describes"

Ok

> > limitations and assumptions it makes about networks and end 
> systems B. 
> > deployment analysis - how the CONEX mechanism can be deployed in 
> Including analysis of the impact of full vs partial 
> deployment (or something like this - highlight that what 
> matters is how we get to a system that is useful)

This raises an interesting question. There are several deployment
issues:
* the functionality of the routers (non, ECN, maybe CONEX, maybe a mix)
* the functionality of the end systems (is the destination non, ECN,
CONEX?)
* the functionality of the network (specifically, this about the
enforcement of trustworthiness of conex info)

The 3rd one seems to me a big issue, & one that first requires work on
the mechanism in 3B. So I see network-by-network partial deployment as a
use case, potentially to be explored under item 4. 

"Output Item 1" (APPlicability) is intended to be early work "to detail
the key functional and non-functional considerations that guide the work
on the mechanism's design". 
I'm not convinced that network-by-network deployment analysis falls into
this category. 

But maybe just my perception! 
 
> Think I would just all that a threat analysis and I think 
> there is a good chance it could exist as a separate document...
> 
> > 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
> > 

Ok

> > 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.
> 
> Somewhere in work items 2 or 3 we need to specifically refer 
> to a need to mitigate those threats identified in the threat 
> analysis...

Ok

> 
> 
> > 
> > 4. Use cases -- possible uses of CONEX information to reduce 
> > congestion and/or increase the accountability for it.
> 
> This first sentence seems to pre-suppose which use cases are 
> of interest... Perhaps change it to "possible uses of CONEX 
> information which include controlling or reducing congestion 
> and increasing accountability for congestion."

Ok. Widening the text allows things like simply monitoring the info, in
order to do some off-line network planning perhaps

> > cases. Future work may include specifications to implement 
> one or more 
> > use cases.
> 
> Highlight that we expect there to be a number of use case 
> documents (or a number of sections within a master use case document).

Think we can leave this to the WG to decide.

> > Feb 2010 Internet-Draft functionality statement (Output 
> item 1A) Mar 
> > 2010 Internet-Draft applicability statement (Output item 
> 1A, B, C) Mar 
> > 2010 Internet-Draft(s) for CONEX IPv4 & IPv6 specifications (Output 
> > item 2) May 2010 Internet-Draft use cases (Ouput item 4)
> My word that's an exhaustive list of milestones! For 
> simplicity can we also break out the list of intended 
> publication dates for the final outputs? My personal instinct 
> is that we should be able to publish the applicability 
> statement in July or at least WGLC it. Also sometime round 
> November 2010 we need to actually select which individual IDs 
> we are progressing for TCP and trustworthiness...

Thnks, we'll have a think whether there's a better way to list them.

---

From: <[email-masked]>
Date: Thu, 10 Dec 2009 11:19:34 -0000

> From: Eardley,PL,Philip,DEE1 R
> Sent: 10 December 2009 10:41
> To: Moncaster,T,Toby,DEE1 R; [email-masked]'
> Subject: RE: [re-ECN] Complete draft Charter for proposed CONEX WG
> 
> Thanks toby & john
> > > ---
> > >
> "mechanisms" might imply that we going to develop several different
> ways of doing this.
> I think everyone so far is ok with mirja's suggestion to add "in the
> end systems", please shout if I mis-interpreted.

I'm OK with it. Arguably it should perhaps be "at the transport layer
and above"

> At the moment, prefer to leave as "rest-of-path congestion" (knowing
> one implies knowing the other, and rest-of-path emphasises the new
info
> useful for a router, as john says)

Matt is suggesting we react to drops by inserting marks in the forward
path. That will give packets that carry whole path congestion
information but there will be no way to measure rest of path info from
IP header... I just want to try and make sure we don't close the door on
that suggestion as it is a good potential deployment scenario. The only
possible way round it is to claim that to the sender whole path and rest
of path are identical... But as you worded it Matt's approach wouldn't
be CONEX

> the mechanism in 3B. So I see network-by-network partial deployment as
> a use case, potentially to be explored under item 4.
> 
> the key functional and non-functional considerations that guide the
> work on the mechanism's design".
> I'm not convinced that network-by-network deployment analysis falls
> into this category.
> 

One of the big questions we could try and answer is what happens if each
element moves first, and the combinations. Who gets the benefit most
quickly. Do the benefits come on the correct timescales (e.g. an end
user would want to see an immediate benefit whereas a network operator
may be prepared to invest time and money if it gives a significant
saving in the long term). We also need to look at what happens if people
don't do it (what if network X refuses to upgrade, does it matter, what
is impact on X and what on its neighbours? What if a major OS refuses to
install this? What are the impacts on their customers. Etc)

> Thnks, we'll have a think whether there's a better way to list them.

One suggestion: Use an approach like this:

May 2010   IND  Internet-Draft use cases (Ouput item 4) 
Jun 2010   WGD  First WG draft CONEX IPv4 specification 
Sep 2010   INF  Complete applicability statement (sent to IESG) 

Where you add a column for IND (individual draft), WGD (working group
draft), WLC (WG LC), INF (informational RFC), EXP (experimental RFC) and
STD (standards RFC). 

That allows people to pick out the key milestones. Or even simpler use *
to highlight those milestones that are draft to IESG for publication...

---

From: Leslie Daigle <[email-masked]>
Date: Thu, 10 Dec 2009 14:08:26 -0500

Mostly agreeing with discussion so far, I wanted to flag a couple of things:

[email-masked] wrote:
  B.
> install this? What are the impacts on their customers. Etc)

This could be done.  And, it would be interesting.  But, I'm concerned 
it's straying rather far from the intent of analyzing whether (and 
communicating how) the CONEX mechanism can be used and useful even 
without 100% uptake.

We may need to reframe the output item to make that clearer, IMO.

> draft), WLC (WG LC), INF (informational RFC), EXP (experimental RFC) and

I'm not convinced that inventing new keying systems will make the 
milestone list any clearer.  It's not even that long a list!  Once we've 
memorized and agonized over the deliverables, it won't seem intimidating 
at all... :-)

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: <[email-masked]>
Date: Mon, 14 Dec 2009 11:14:24 -0000

it would be great if we could get this to Lars in the next couple of
days. Please send any more comments asap
thanks!
phil

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: 08 December 2009 15:29
	To: [email-masked]
	Subject: [re-ECN] Complete draft Charter for proposed CONEX WG

	Hi, 
	We've now added a draft list of Milestones to the problem
statement and Output already discussed. 
	Please send comments as soon as possible - hoping to get into
IESG next week. 
	Thanks 
	Phil & Leslie 
	--- 

	The purpose of the CONEX working group is to develop a mechanism
to 
	allow senders to inform the network of the level of congestion
they 
	expect their packets to encounter. This information is currently
only 
	visible at the transport layer. With the output of CONEX, it
will be 
	possible to provide sufficient information in each IP datagram
so that 
	any node in the network can see the expected rest-of-path
congestion. 
	Once any node can see the impact it causes (and suffers) by
sending or 
	forwarding packets, it will be possible to hold senders and
whole 
	networks accountable for the congestion they cause downstream.
Tools 
	that exploit the CONEX output could be used for mitigating
distributed 
	denial of service (DDoS); simplifying differentiation of quality
of 
	service (QoS); policing compliance to congestion control; and so
on. 

	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 

	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 

	A. for the transport of congestion information from the
destination to the sender, 

	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.

	4. Use cases -- possible uses of CONEX information to reduce
congestion and/or increase the accountability for it. The main purpose
is to encourage experiments that use CONEX information and to describe
their results; it is not to delineate all potential uses cases, nor to
provide a full architectural/deployment/security analysis of use cases.
Future work may include specifications to implement one or more use
cases.

	The output is Informational and Experimental, apart from #2
which is tentatively slated as Standards track. 

	Milestones 

	Mar 2010 Internet-Draft applicability statement (Output item 1A,
B, C) 

	Mar 2010 Internet-Draft(s) for CONEX IPv4 & IPv6 specifications
(Output 
	item 2) 

	Jun 2010 Proposals (individual I-Ds) for TCP modification (Ouput
item 3A)

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 14 Dec 2009 18:12:48 +0000

Phil, Leslie,

I'm happy with the agreement so far (mainly on the intro text), but i'm
afraid I have some issues with the intended outputs of the w-g, listed
here, then details inline:

1. Separate IP spec? (I've started separate thread on this)

2. Which numbers and letters mean separate docs, and which don't?

3. Scope of transport spec?

4. #2 as stds track?

5. A nit.

At 11:14 14/12/2009, [email-masked] wrote:

Content-class:
urn:content-classes:message

Content-Type: multipart/alternative;

boundary="----_=_NextPart_001_01CA7CAE.97FAE246"

it would be great if
we could get this to Lars in the next couple of days. Please send any
more comments asap

thanks!

phil

-----Original Message-----

From: [email-masked]
[
mailto:[email-masked]] On Behalf Of [email-masked]

To: [email-masked]

Subject: [re-ECN] Complete draft Charter for proposed CONEX
WG

Intended output of the
WG:

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

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

2. Specification of IP (v4 &
v6) packet structure to carry CONEX information (header bits,
interpretation)

I notice we've implicitly decided to write the ConEx-IP specs
separately from TCP and other transports. The alternative is to write one
spec for ConEx-TCP/IP including additional generic guidelines for all
transports. On balance I believe separating IP out is the best course,
but I'm not certain and I'm willing to be persuaded...

See separate thread I will start on this
issue.

3. Transport-related Best
practices and specifications:

A. for the transport of
congestion information from the destination to the sender,

B. for ensuring the
trustworthiness of the CONEX information

In general, it would be better to be specific on what docs you are
expecting. The numbers and letters seem to be designed to hide indecision
;)

Is 3A a different document to 3B? I hope so.

The implementer of 3A (OS coder) will be a different type of beastie to
that for 3B (network policing box
coder).

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.

How about:

"Capability negotiation is only in scope to the extent that one
ConEx host needs to know the capabilities of the other end that are
necessary for ConEx to interwork. Otherwise capability negotiation is out
of scope."

Reasoning:

The spec of the transport should surely be whatever is necessary to
implement it. If capability negotiation is necessary, it is in scope. If
not it's out of scope.

If there are different types of legacy out there that each require a
ConEx host to behave in one of n different ways, we need to handle them
all, whether n=1 or 3. We can't handle some of them, and hope we can
handle the others later.

E.g. I believe a basic level of capability negotiation will be necessary
for TCP, but not for RTCP.

Consider TCP-ECN. The way TCP was written doesn't work well for ConEx,
because the feedback loses any more than 1 ECN mark per RTT. If we
specify a ConEx-specific feedback upgrade to a TCP receiver (3A), the
sender needs to know whether the meaning of the feedback is legacy or
new.

4. Use cases -- possible uses of
CONEX information to reduce congestion and/or increase the accountability
for it. The main purpose is to encourage experiments that use CONEX
information and to describe their results; it is not to delineate all
potential uses cases, nor to provide a full
architectural/deployment/security analysis of use cases. Future work may
include specifications to implement one or more use cases.

The output is Informational and
Experimental, apart from #2 which is tentatively slated as Standards
track.

At what point do we need to decide which track each doc is on? Surely
best to have a crack at that during chartering?

Bear in mind the only bit we've found suitable in IPv4 (bit 48) is
"reserved for future use". That's not even experimental track,
let alone stds track. I would be v surprised if the IESG give away the
last bit in the IPv4 header without an experiment first - and an
experiment that must prove it can be unwound if it fails (so the bit
could be reused elsewhere).

RFC4727, RFC3692 & particularly RFC2780 define a fairly
straightforward process for experimental use of values in the IP header
(and other base headers). Assuming for a moment, that we use bit 48 in
IPv4, this implies work items for a charter would need to
include:

ONLY IF NECESSARY:

2A. (STD) Reassign value 1 of IPv4 bit 48 from 'reserved' to
'experimental use'

(not specifically for ConEx)

Also possibly describe conditions on experiments, e.g.:

- confined in space and in time

- multiple simultaneous experiments with same value would
need v strong case

2B. (EXP) ConEx protocol in IPv4 (using experimental bit 48 in IPv4)

2C. (STD) ConEx protocol extension hdr in v6

We also have to include contingency in the charter in case we cannot find
a viable ConEx encoding without reusing the ECN nonce codepoint. Then the
charter needs to allow us to write a doc to change the status of the ECN
nonce (RFC3540) from expt to historic, BUT ONLY IF ABSOLUTELY NECESSARY.
It would also have to update DCCP and SCTP, which are stds track. In
summary:

ONLY IF NECESSARY:

2D. (INF/STD) Move ECN nonce in IPv4&6 (RFC3540) from Experimental to
Historic

[When we designed re-ECN, we found we needed to reuse the ECN Nonce
codepoint. Given ConEx provides a superset of the Nonce capabilities, and
given no-one is aware of the Nonce ever having been implemented, except
in TCP on the machine of the author, moving it to historic seems
reasonable. This applies for use of the nonce in all of TCP, DCCP &
SCTP - all specified but never tested through implementation.]

Milestones

Finally, a nit. I agree with others that the milestone list is hard to
follow.

It would help (me) to have the output identifier in a visible column, for
example:

Feb 2010 1A     Functionality statement:
Internet-Draft

Mar 2010 1A,B,C Applicability statement: Internet-Draft

....

Jun 2010 2A     CONEX IPv4 specification: WG
draft

....

Cheers

Bob

Feb 2010 Internet-Draft
functionality statement (Output item 1A)

Mar 2010 Internet-Draft
applicability statement (Output item 1A, B, C)

Mar 2010 Internet-Draft(s) for
CONEX IPv4 & IPv6 specifications (Output

item 2)

May 2010 Internet-Draft use
cases (Ouput item 4)

Jun 2010 First WG draft CONEX
IPv4 specification

Jun 2010 First WG draft CONEX
IPv6 specification

Jun 2010 Draft transport-related
best practices

Jun 2010 Proposals (individual
I-Ds) for TCP modification (Ouput item 3A)

Jun 2010 Proposals (individual
I-Ds) for mechanism to ensure trustworthiness of CONEX information (Ouput
item 3B)

Sep 2010 Complete applicability
statement (sent to IESG)

Nov 2010 CONEX IPv4
specification to WGLC

Nov 2010 CONEX IPv6
specification to WGLC

Jan 2011 Complete IPv4
specification (sent to IESG)

Jan 2011 Complete IPv6
specification (sent to IESG)

Mar 2011 Spec of TCP
modification to WGLC

Mar 2011 Spec of mechanism to
ensure trustworthiness to WGLC

Mar 2011 Transport-related best
practices to WGLC

Mar 2011 Use cases to
WGLC

May 2011 Complete remaining docs
(sent to IESG)

Jun 2011 Close or
re-charter

_______________________________________________

re-ECN mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/re-ecn

________________________________________________________________

Bob
Briscoe,
BT Innovate & Design