Re: [conex] Remaining ConEx I-Ds

[Dirk Kutscher <[e-mail]>]

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:[e-mail]] 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.
> 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
> >
> 
> _______________________________________________
> conex mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/conex