Re: [Status] Updated charter

Yeah, good catch.

The previous text had gone too far the other way since there is going to be some
small amount of state maintained (otherwise forwarding is going to be really
hard).

I think it is the "per flow state" that will not be needed, and we can add that
back in.

Adrian

> -----Original Message-----
> From: status-bounces@ietf.org [mailto:status-bounces@ietf.org] On Behalf Of
> Rob Shakir
> Sent: 01 October 2013 10:41
> To: stbryant@cisco.com
> Cc: status@ietf.org
> Subject: Re: [Status] Updated charter - version 3 and maybe 4
> 
> Hi Stewart, {SPRING,STATUS},
> 
> One thing that has gone missing from the charter is the specification of where
> state should be maintained in the solution. I think (and I think the feelings
of the
> list are) that this is an absolute fundamental of the architecture, so it
would be
> good to have this specified in the charter.
> 
> Kind regards,
> r.
> 
> 
> 
> On 30 Sep 2013, at 16:52, Stewart Bryant <stbryant@cisco.com> wrote:
> 
> > Adrian and I took a close look the SPRING charter
> > and have edited it to get text that we think is more
> > likely to get through the review cycles.
> >
> > The intent of the changes is not change the work
> > programme, the deliverables or the networks. The
> > purpose of the changes is to generate what we think
> > is a viable charter that matches the intent of
> > this list.
> >
> > First we added a summary of what spring is and
> > why it is needed - that is covered by the first
> > paragraph, the list of *example* and the following
> > paragraph.
> >
> > We then note that we need bot strict and loose
> > path specification.
> >
> > We then discuss the trust model
> >
> > We then say we start with single AS but must be
> > able to multi-AS
> >
> > We call out centralized and distributed path comp.
> >
> > We then call out SPRING as an OAM and the need
> > to manage SPRING.
> >
> > Then for data plane, control plane and management
> > we say, try to use existing, but if that does
> > not work we specify the process for change.
> > Note that we talk about data planes in the plural.
> >
> > We then provide the deliverable as an edited
> > version of the delivery plan.
> >
> > We do not explicitly call out either MPLS or
> > IPv6 (or any other data plane), because,
> >
> > 1) That emerges from the use cases.
> > 2) The charter says use the dataplanes (note the
> > plural) and protocols that are derived from
> > the use cases.
> >
> > The charter therefore set a strong expectation
> > that whatever dataplanes need to to be used
> > to satisfy the network need is in scope.
> >
> > Comments please
> >
> > Stewart
> >
> > PS you may see -04 with some cosmetic/layout changes.
> >
> >
> >
> > _______________________________________________
> > status mailing list
> > status@ietf.org
> > https://www.ietf.org/mailman/listinfo/status
> 
> _______________________________________________
> status mailing list
> status@ietf.org
> https://www.ietf.org/mailman/listinfo/status