Re: [GROW] Virtual Aggregation as GROW working group item

[Paul Francis <francis at mpi-sws.org>]

Christopher Morrow  wrote:

> 
> Re: [GROW] Virtual Aggregation as GROW working group item
> 
> 
> 

> 
> I THINK all that's required is a consensus that the doc should be
> homed in 'some group' (call it grow-wg for this discussion) and then
> to officially adopt it as such (via chairs sending the requested doc
> forward as an accepted WG doc, where it gets renamed from
> draft-paul-blah to draft-grow-blah)...
> 
> Are there any folks attempting to block this as a work-item for Grow?

If there are such people, I don't think they will come out until we take 
the next step here.

So, I suggest that we go ahead and call these grow-wg accepted documents, 
and issue them under the grow name. 

PF



> 
> -Chris
> 
> > adopting this work.  If the WG wants to do this, and if the chairs 
want some
> > help dealing with any procedural obstacles, I am happy to help.
> >
> > Paul Francis wrote:
> >>
> >> From:
> >> Paul Francis <francis at mpi-sws.org>
> >> To: grow at ietf.org
> >> Date: 04/24/2009 05:01 PM
> >> Subject: [GROW] Virtual Aggregation as GROW working group item
> >> Sent by: grow-bounces at ietf.org
> >>
> >> Gang,
> >>
> >> I would like to start the discussion of making Virtual Aggregation, 
which
> >> I presented at the GROW meeting in SF, a working group item.
> >>
> >> A new version of the document has been posted, which mainly consists 
of
> >> minor clarifications from folks who make up an expanded author list 
(Zhang,
> >> Jen, and Raszuk).  It is at
> >> http://www.ietf.org/internet-drafts/draft-francis-intra-va-01.txt.
> >>
> >> Note that there are two companion documents associated with this, one 
each
> >> on the specifics of MPLS and IP-in-IP tunnels in support of VA. 
 These
> >> have not been updated, though we expect them to be soon.  (These are 
at
> >> http://tools.ietf.org/id/draft-francis-va-tunnels-mpls-00.txt and
> >> http://www.ietf.org/internet-drafts/draft-xu-va-tunnels-gre-00.txt
> >> respectively)
> >>
> >> I think that there are mainly two things to discuss:
> >>
> >> 1.  What additional documentation, if any, is needed (requirements,
> >> scenarios, MIB, ....)?
> >> 2.  What should the status of the produced RFCs be (informational, 
BCP,
> >> standard)?
> >>
> >> Regarding the first, I do think that a requirements/scenarios 
document is
> >> a good idea, but would like to hear opinions.
> >>
> >> Regarding the second, there are arguments for and against each type.
> >> Strictly speaking no protocol changes are needed (except for a case
> >> involving GRE tunnels with key values, which require an extended 
communities
> >> attribute to convey the key info).  So informational or BCP could 
both work.
> >>  I'm inclined towards BCP, but would like to hear opinions.  Even 
possibly
> >> we could start this as a working group item without making this 
decision
> >> just yet.
> >>
> >> Thanks all,
> >>
> >> PF
> >>
> >> _______________________________________________
> >> GROW mailing list
> >> GROW at ietf.org
> >> https://www.ietf.org/mailman/listinfo/grow
> >>
> >>
> >>
> > _______________________________________________
> > GROW mailing list
> > GROW at ietf.org
> > https://www.ietf.org/mailman/listinfo/grow
> >
> _______________________________________________
> GROW mailing list
> GROW at ietf.org
> https://www.ietf.org/mailman/listinfo/grow