[conex] Remaining ConEx I-Ds
Bob Briscoe <bob.briscoe@bt.com> Wed, 19 March 2014 09:46 UTC
Return-Path: <bob.briscoe@bt.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F4A1A069A for <conex@ietfa.amsl.com>; Wed, 19 Mar 2014 02:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqGpiz3R6pPf for <conex@ietfa.amsl.com>; Wed, 19 Mar 2014 02:46:33 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id D832F1A06A9 for <conex@ietf.org>; Wed, 19 Mar 2014 02:46:32 -0700 (PDT)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 19 Mar 2014 09:46:23 +0000
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 19 Mar 2014 09:46:21 +0000
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Wed, 19 Mar 2014 09:46:16 +0000
Received: from BTP075694.jungle.bt.co.uk ([10.109.159.220]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s2J9kE0x010476; Wed, 19 Mar 2014 09:46:14 GMT
Message-ID: <201403190946.s2J9kE0x010476@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 19 Mar 2014 09:46:14 +0000
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <CAH56bmCZkcPr+mRauDbX8vTtN7OwYydhm5qYwyaQrz4tyubH=g@mail.g mail.com>
References: <CAH56bmCZkcPr+mRauDbX8vTtN7OwYydhm5qYwyaQrz4tyubH=g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_50083949==.ALT"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/conex/9i_uJVaZod-PD781keoirH4fF8U
Cc: ConEx IETF list <conex@ietf.org>
Subject: [conex] Remaining ConEx I-Ds
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Mar 2014 09:46:40 -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:internet-drafts@ietf.org>internet-drafts@ietf.org> >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:mattmathis@google.com>mattmathis@google.com>, >"Bob J. Briscoe" <<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com> > > > >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
- [conex] Remaining ConEx I-Ds Bob Briscoe
- Re: [conex] Remaining ConEx I-Ds marcelo bagnulo braun
- Re: [conex] Remaining ConEx I-Ds Dirk Kutscher