Dear all,
I think that all 7 items are desirable and well-scoped goals.
I am willing to spend signficant energy on items 1. and 2.,
and I will comment on and contribute to all others.
Side note: for 3. and 4. the new work item description should really
make clear that we are going to evaluate general mechanisms (json patch,
http/2.0, etc.) first, before we start specifying ALTO-specific
mechanisms.
Thanks to Vijay and Enrico for putting this list together and starting
the discussion!
Sebastian
On Thu, Jan 23, 2014 at 01:11:14PM -0600, Vijay K. Gurbani wrote:
> 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
