Minutes for ALTO at IETF-interim-2011-alto-1
minutes-interim-2011-alto-1-00

Meeting notes from ALTO WG virtual interim meeting
Wednesday, June 15, 2011, 15:00-17:00 GMT

About 20 attendees

This report has been distilled from the detailed meeting notes taken by
Greg Bernstein and Vijay Gurbani

Chairs: Enrico Marocco, Vijay Gurbani and Jon Peterson.


Agenda
------

Enrico presents the agenda and the status of the WG.

No questions nor comments.


Requirements
------------

Sebastian Kiesel presents the post-WGLC version of the requirements
draft. Since Prague, harmonized reqs document with CDN work to make sure
that existing reqs do not harm CDN work. Sebastian went through the
details on changes between -08 and -10. Ongoing work with the protocol
has resulted in some new requiremnts (REQ Arv10-48) in the requirements
draft. This is the only substantial change since -08.

Enrico: any comments? None. Suggest two week last call period. No
outstanding issues? Sebastian: not to my knowledge. Those who have sent
comments please check the latest version. Not planning any further
changes. Enrico: any one opposed to the plan? None.

Some comments were not incorporated due to conflict with other ideas.
But the substantive comments were addressed.


ALTO Protocol
-------------

Richard Alimi presents the latest version of the protocol document,
redesigned in order to shift from a REST-like to a RESTful approach.

Sebastian: is the name "resource directory" well known in the context
of RESTful design? Richard: good point. If this is an overlap in
terminology we can change it. Sebastian: it's already used in ALTO
problem statement RFC, would suggest you change it. Richard: will do.

Richard goes through the outstanding issues: multiple cost types, PID
properties, etc. (slide 11). Next version will try to close some of
these open issues.

Enrico: would be particularly helpful to get feedback from
implementers. Any thoughts you'd like to share?

Jan Medved: good version, incorporate the list discussion on errata
and bugs in the new version for bakeoff. Specifically the comments from
Robert and Ning. Richard: we can fold those in. Okay. Is it reasonable
to wait till the beginning of next week then come out with a new
version? Enrico: sounds reasonable.

Richard: anyone objects to the extensions proposed on the mailing
list. If there are no objections we can start, but not for next week.
Maybe after interop testing.

Emile Stephan: concerning network map, is there a need for a version
tag for the cost map? Richard: version tag is not meant to be a
timestamp. Network map, cost map use corresponding vtag (version tag).
Emile: yes I understand, but don't we need for cost map? Richard: there
is a vtag for the cost map, if not one, then there should be. There is
not one for endpoint cost service since it does not make use of PIDs.

Enrico: would like to thank Richard, Ben, and all the contributors.


Interoperability Event in Quebec City
-------------------------------------

Vijay provides an introduction of the context and the open questions:
when, what, how and how to report.

Jan: if you provide public IPs, can you also provide a server with
multiple VMs? It would be nice to have actual hardware. Vijay: we can
think about that.

Jan: if we have a hardware infrastructure we can just leave it up
during the meeting. Vijay: don't think we can get a room for the whole
week. Jon: if we have these on a server in the IETF NOC we might as well
have them on a server back in San Jose. Jan: doesn't really matter where
we have the servers.

Jon: proposed time (Sunday, 12:00-16:00) is the time when IAB and IESG
meet. Vijay: Friday? Richard: bit more tricky.

Vijay: how should we do this "bake-offs"? My previous experience was
with SIP bakeoffs. The chairs will put out some test cases by Friday.
Jon: depends on how many show up. Don't think we need to be as formal
with our write up as an IETF draft.

Jan: in addition to the test cases, test topology matters. What maps
will be exported? Vijay: some sort of canonical maps should do.

Richard: interesting to test will be make sure that given a client can
discover and access the services.

Richard: would be also interesting the testing of a static-file-based
service.

Enrico: if you have other suggestion send to the list.