Re: [conex] Remaining ConEx I-Ds

[marcelo bagnulo braun <[e-mail]>]

Hi,

I can only speak about the conex ones, the tcp one and the dst options 
one, i will issue a wglc shortly.
the other ones, i can ask for expression of interest in working in the 
documents and see how much energy we have left.

Regards, marcelo



El 19/03/14 10:46, Bob Briscoe escribió:
> Marcelo,
>
> At 21:39 13/03/2014, Matt Mathis wrote:
>> I am concerned that there are too many non-progressing IDs as 
>> references. Â  These are not so much of an issue at this stage, but 
>> we need a plan for the RFC editor: which are we going to leave at 
>> "work in progress" and which can be replaced by other references?
>
> [Matt, actually, all except the "historic" re-ECN ones have had recent 
> material updates.]
>
> What's the plan for each category below in the timescale of RFC-Edits 
> on abstract-mech?
> 1) Ready: presumably you will WG last-call the ConEx ones? Or has that 
> already happened?
> 2) "Historic" (re-ECN): Do we leave these to expire, or get them 
> issued as historic RFCs?
> 3) Individual: Do you plan to make these WG items?
>    (Small groups are actively working on implementing and evaluating 
> policing and audit.)
>
>
> I count the following I-D refs in abstract-mech:
>
> 1) Ready for WG last call (either ConEx or TCPM):
> * ietf-conex-destopt
> * ietf-tcp-modifications
> * ietf-tcpm-accecn-reqs
>
> 2) "Historic" re-ECN drafts
> * briscoe-conex-re-ecn-motiv
> * briscoe-conex-re-ecn-tcp
>
> 3) Individual drafts satisfying ConEx charter items:
> * briscoe-conex-policing
> * draft-wagner-conex-audit (mistakenly not referenced from 
> abstract-mech, but we'll add during RFC-Editor phase)
>
> The other category in the charter (cited in concepts-uses, not 
> abstract-mech) is
> 4) Use cases
> draft-ietf-conex-mobile
> draft-briscoe-conex-data-centre
> draft-briscoe-conex-initial-deploy
>
>
>
> Bob
>
>
>
>
>> Thanks,
>> --MM--
>> The best way to predict the future is to create it. Â - Alan Kay
>>
>> Privacy matters! Â We know from recent events that people are using 
>> our services to speak in defiance of unjust governments. Â  We treat 
>> privacy and security as matters of life and death, because for some 
>> users, they are.
>>
>>
>> ---------- Forwarded message ----------
>> From: <[e-mail] <mailto:[e-mail]> >
>> Date: Thu, Mar 13, 2014 at 2:31 PM
>> Subject: New Version Notification for 
>> draft-ietf-conex-abstract-mech-11.txt
>> To: Matt Mathis <[e-mail] 
>> <mailto:[e-mail]>>, "Bob J. Briscoe" <[e-mail] 
>> <mailto:[e-mail]>>
>>
>>
>>
>> A new version of I-D, draft-ietf-conex-abstract-mech-11.txt
>> has been successfully submitted by Matt Mathis and posted to the
>> IETF repository.
>>
>> Name: Â  Â  Â  Â  Â draft-ietf-conex-abstract-mech
>> Revision: Â  Â  Â  11
>> Title: Â  Â  Â  Â  Â Congestion Exposure (ConEx) Concepts and 
>> Abstract Mechanism
>> Document date: Â 2014-03-13
>> Group: Â  Â  Â  Â  Â conex
>> Pages: Â  Â  Â  Â  Â 29
>> URL: Â  Â  Â  Â  Â  Â 
>> http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-11.txt 
>>
>> Status: Â  Â  Â  Â 
>> https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech/
>> Htmlized: Â  Â  Â 
>> http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-11 
>> <http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-11>
>> Diff: Â  Â  Â  Â  Â 
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-conex-abstract-mech-11
>>
>> Abstract:
>> Â  Â This document describes an abstract mechanism by which senders 
>> inform
>> Â  Â the network about the congestion encountered by packets earlier in
>> Â  Â the same flow. Â Today, network elements at any layer may signal
>> Â  Â congestion to the receiver by dropping packets or by ECN markings,
>> Â  Â and the receiver passes this information back to the sender in
>> Â  Â transport-layer feedback. Â The mechanism described here enables the
>> Â  Â sender to also relay this congestion information back into the
>> Â  Â network in-band at the IP layer, such that the total amount of
>> Â  Â congestion from all elements on the path is revealed to all IP
>> Â  Â elements along the path, where it could, for example, be used to
>> Â  Â provide input to traffic management. Â This mechanism is called
>> Â  Â congestion exposure or ConEx. Â The companion document "ConEx 
>> Concepts
>> Â  Â and Use Cases" provides the entry-point to the set of ConEx
>> Â  Â documentation.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
> ________________________________________________________________
> Bob Briscoe, BT
>