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

[Leslie Daigle <[e-mail]>]

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

[e-mail] wrote:
  B.
>>>> deployment analysis - how the CONEX mechanism can be deployed in
>>>> networks (non vs ECN vs perhaps CONEX routers) and end systems
>>> 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!
> 
> 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)
> 

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.


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

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
[e-mail]
-------------------------------------------------------------------