Hi Vijay, I believe all these items are reasonable and there is enough energy from the group to finish the deliverables.
Best Regards! -Haibin > -----Original Message----- > From: alto [mailto:[email protected]] On Behalf Of Vijay K. Gurbani > Sent: Friday, January 24, 2014 3:11 AM > To: alto > Subject: [alto] Work items for re-chartering > > 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 _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
