Attached are the raw notes we've received from on of the two note takers (thanks Jan!). As soon as we receive notes from the other note taker, we'll produce a digested version and will upload it on the proceedings page.
Enrico Y.J. Gu wrote: > Say hello everybody. > I did not attend the meeting, is there meeting minutes for ALTO? > Thank you. > > Regards > > Yingjie Gu > > > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto
IETF-75 ALTO Session Notes by Jan Seedorf -------------------- -------------------- Jon Peterson presents the note well and agenda ---------------------------------------------- -- there are two related bar bofs this ietf: DECADE on Wednesday and PPSP on Thursday, problem statement doc is in last call, requirements draft was agreed to stay alive for a while, protocol proposals and survey proposals have merged since ietf-74 Sebastian Kiesel presents the alto-requirements draft ----------------------------------------------------- -- draft has been adopted as WG item at ietf-74 -- there are three new terms replacing the "host location attribute" (see slides for details), several requirements can be expressed better with the new terms (examples on the slides), no comments on the new "host group descriptor requirements" Sebastian presented -- there are different options regarding alto server discovery requirements (ALTO client finding "right" ALTO server, or ALTO client finding a near ALTO server and then redirection), Hannes: what do operators think on this issue, Hannes: Finding the access provider based on the IP address of the end host is complicated and error prone, Song Haibin: redirection might be good for load balancing but prefers first option, Rich Woundy: undecided, maybe a combination is best way to go, Rony Evan: why does there have to be a requirement either way?, Albert Tian: also thinks not necessary to have such requirements, second option seems more doable, ??: what means "right" ALTO server is not clear, David ?: some parts of the requirements doc are confusing, including this issue, Hannes: Nobody is going to read that document anyway after it is finished, Rich Alimi: worried about the trust issue in the second option when there is redirection between ALTO servers, Lars: probably the discovery requirement should be more general and not so detailed, -- there are new security requirements regarding authentication of servers and clients, Lars: authentication between client and servers is probably not so important but data authentication (authenticating the information exchanged) is important, Ruediger: what kind of NAT is meant with the NAT traversal requirement?, -- general comments/discussion; David ?: are the new terms target of the query?, John ?: have you considered and anonymity server for privacy purposes?, further discussion referred to the mailing list Reinaldo Penno presents the merged alto protocol draft ----------------------------------------------------- -- the current draft is a merger of plenty initial protocol proposals (P4P, infoexport, ATTP, proxidor, ...), Reinaldo presents the contributions of the individual drafts which have now been merged together, Martin: what happened to the proxidor approach of sorting ip addresses in the server, abandoned? How did the merger happen exactly? answer: none, -- Reinaldo explains the "my internet view" concept and other key concepts of the draft, there may be multiple costs between a pair of network locations, Lars: is the "my internet view" service specific? do several clients have to ask twice? answer: peers within the same group should have the same "my internet view", Lars: can you query information only related to yourself or also query information between two other peers?, answer: both possible, ??: costs are a critical issue, should the WG make certain cost types a requirement?, Wolfgang: does A really need to know the cost between B and C, and would any service provider actually reveal such information? answer: there are different types of cost, not only monetary costs -- Rich Alimi presents some details of this protocol proposal: Rich presents use-cases, ALTO query types, Lars: we should think what information exchange actually makes sense, not everything is necessarily to be done via an ALTO-service; Rich explains network map, ??: returning a range of values is good for privacy, maybe this should enter the requirements in the future; Rich explains path rating and protocol message encoding (proposed is http + REST-ful API + XML encoding in bodies), Volker: there is lots of felxibility in the protocol, this means that clients and servers need to implement many options and maybe this should be implified, answer: this should be discussed; Rich presents use-cases in detail (see his slides); Rich aks WG if this should be adopted as WG item? -- discussion: Stefano: supports adoption as WG; Lisa: this is probably the best REST-ful design she has seen in the ietf; Bertrand Mathieu: does not think it is a good merged document, has concerns that the information retrieved from ALTO is quite extensive; Jan Seedorf: has concerns with the workload for ALTO servers caused by queries with multiple source network locations, risk of easy DoS attacks, answer: the resulting answer matrices can be pre-computed and should not change that frequently -- no hum on WG adoption, further discussion referred to the mailing list Zoran Despotovic presents Feedback-based Client Prototol -------------------------------------------------------- -- see slides for details -- no questions nor comments regarding this proposal Marco Tomsu presents the merged ALTO discovery protocol ------------------------------------------------------- -- the current draft is mainly a merger without much new technical content, next steps are adopting the draft as a WG document -- discussion: David ?: what is really the information needed? what does really need to be standardized? ??: are different versions considered for DHCP and in general? answer: yes; -- no hum on adopting this draft as WG document Zoran Despotovic presents BGP-based ALTO Service ------------------------------------------------ -- BGP can be the source for locaility information used by an ALTO-server, Zoran presents the relevant BGP attributes which could be used, -- discussion: David ?: thinks this is an interesting direction; Stefano: understand usefulness of BGP but finds the approach dangerous because it uses different semantics, may have impact on actual BGP use
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
