Subject: [conex] Remaining ConEx I-Ds

From: Bob Briscoe <[email-masked]>
Date: Wed, 19 Mar 2014 09:46:14 +0000

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: <<mailto:[email-masked]>[email-masked]>
>Date: Thu, Mar 13, 2014 at 2:31 PM
>Subject: New Version Notification for draft-ietf-conex-abstract-mech-11.txt
>To: Matt Mathis 
><<mailto:[email-masked]>[email-masked]>, 
>"Bob J. Briscoe" <<mailto:[email-masked]>[email-masked]>
>
>
>
>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>http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-11.txt
>Status: 
>Â  Â  Â  Â 
><https://datatracker.ietf.org/doc/draft-ietf-conex-abstract-mech/>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>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 <http://tools.ietf.org>tools.ietf.org.
>
>The IETF Secretariat
>

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 19 Mar 2014 10:51:01 +0100

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ó:
>> 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?
>    (Small groups are actively working on implementing and evaluating 
> policing and audit.)
>
>
> * 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
>> 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.
>>
>>
>> From: <[email-masked] <mailto:[email-masked]> >
>> To: Matt Mathis <[email-masked] 
>> <mailto:[email-masked]>>, "Bob J. Briscoe" <[email-masked] 
>> <mailto:[email-masked]>>
>>
>>
>>
>> Title: Â  Â  Â  Â  Â Congestion Exposure (ConEx) Concepts and 
>> Abstract Mechanism
>> 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:
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>

---

From: Dirk Kutscher <[email-masked]>
Date: Wed, 19 Mar 2014 16:40:02 +0000

Hi,

conex-mobile has been rev'ed recently -- we have a plan for another update before we would ask for WGLC.

Dirk

> -----Original Message-----
> From: conex [mailto:[email-masked]] On Behalf Of marcelo bagnulo
> braun
> Sent: Mittwoch, 19. März 2014 10:51
> To: Bob Briscoe
> Cc: ConEx IETF list
> Subject: Re: [conex] Remaining ConEx I-Ds
> 
> Hi,
> 
> I can only speak about the conex ones, the tcp one and the dst options one, i
> will issue a wglc shortly.
> >> has been successfully submitted by Matt Mathis and posted to the IETF
> >> repository.
> >>
> >> Abstract Mechanism Document date: Â 2014-03-13
> >> Group: Â  Â  Â  Â  Â conex
> >> Pages: Â  Â  Â  Â  Â 29
> >> URL: Â  Â  Â  Â  Â  Â
> >> Â  Â 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
> >>
> >
> _______________________________________________
> conex mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/conex