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 <[email protected]> > >> To: [email protected] > >> Date: 04/24/2009 05:01 PM > >> Subject: [GROW] Virtual Aggregation as GROW working group item > >> Sent by: [email protected] > >> > >> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/grow > >> > >> > >> > > _______________________________________________ > > GROW mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/grow > > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
