How about give different milestones to different items, with some later milestones? The chairs enforce more strictly the deadlines.
Thanks! Richard On Sat, Jan 25, 2014 at 11:29 PM, Reinaldo Penno (repenno) < [email protected]> wrote: > I do not support all 7. In my opinion it will be more we can deliver. > > The original charter was around, say, 15 months and 4 documents and we > are late by 2 years. > > I think we need a charter with a small number of documents we can > deliver in a short timeframe. Nothing wrong to continue to work on other > extensions in the meantime and including then in another recharter. > > Thanks, > > > From: "Y. Yang" <[email protected]> > Date: Friday, January 24, 2014 at 7:53 PM > To: Vijay Gurbani <[email protected]> > Cc: alto <[email protected]> > Subject: Re: [alto] Work items for re-chartering > > Dear all, > > I support all of the 7 items. They provide key functions that together > will both fill some gaps in the base ALTO protocol and extend ALTO to be > more useful. As more networks open up to applications (e.g., some recent > major movement by ChinaTelecom), the new functionalities can be quite > helpful to allow ALTO to make a bigger impact! > > Richard > > > On Thu, Jan 23, 2014 at 2:11 PM, Vijay K. Gurbani <[email protected]>wrote: > >> Folks: Over the last few IETFs, Enrico and I have solicited feedback >> during face-to-face meetings, WG sessions, hallway conversations, ALTO >> mailing list and private conversations on how to move ahead with respect >> to adopting new work items. >> >> As we begin the charter discussions, we have identified seven >> work items to propose as additions to the charter. The first four of >> these work items are fairly uncontroversial. The last three are work >> items that have a monumental mind share in the ALTO working group and >> have been found to be extremely useful in controlled networks (e.g., >> VPNs). However, we have to take some care in defining these such that >> we do not duplicate the functionality available elsewhere (e.g., general >> routing) in ALTO, nor do we take on an aspect that the working group >> does not fully understand. >> >> Here are the seven items up for discussion: >> >> 1. Anycast-based server discovery >> (Presented by Reinaldo Penno in IETF 86 and appears to have >> some support for adoption.) >> >> 2. Third-party server discovery >> (Sebastian Kiesel et al. have been driving this work and it >> also appears to have support.) >> >> 3. Incremental ALTO map updates >> (Side meeting held during IETF 86; two proposals have been >> studied. One way forward is to use an ALTO-specific incremental >> update that may be more efficient, and the second approach is to >> simply use JSON patch.) >> >> 4. Server-initiated update notifications >> (Jan Seedorf and Enrico Marocco have suggested the use of >> Websockets; HTTP/2.0 may provide some mitigation as well.) >> >> 5. Extensions to annotate PIDs with properties (e.g., geographical >> locations). >> (Useful as an extension in controlled environments, e.g., VPNs >> where IP addresses are not the only form of identification. >> Some drafts, including draft-roome-alto-pid-properties >> has already started work in this direction.) >> >> 6. Extensions for cost metrics. >> (Some drafts, including draft-wu-alto-json-te, have started work >> in this direction.) >> >> 7. An ALTO format for encoding graphs. >> (draft-ietf-alto-protocol already recognizes the need to provide >> topology details that are useful in controlled environments. >> Richard Yang, Greg Bernstein and others have been working on the >> need and use cases for such an encoding. draft-yang-alto-topology >> is a good start. Projects like OpenDayLight and NetworkX (Python) >> have JSON models for graph representation. Some concrete examples >> of how we envision encoding graphs will be useful during list >> discussion.) >> >> We will like to understand whether the working group believe such >> additional deliverables, if included in an updated charter proposal, >> would allow people to do the extension work that has been repeatedly >> proposed. (Clarification: we are explicitly asking whether people could >> find such an update acceptable. We understand that anyone will have a >> preferred flavor of the above.) >> >> We are at a point where show of support by whoever is interested is >> essential for moving forward. If it turns out to be positive, Enrico >> and I will subsequently circulate actual text, including milestones, for >> a rechartering request. >> >> Thanks. >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >> Email: vkg@{bell-labs.com,acm.org} / [email protected] >> Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> > > > > -- > -- > ===================================== > | Y. Richard Yang <[email protected]> | > | Professor of Computer Science | > | http://www.cs.yale.edu/~yry/ | > ===================================== > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
