1 / 3

ALTO Requirements draft-ietf-alto-reqs-04

ALTO Requirements draft-ietf-alto-reqs-04. Sebastian Kiesel Rich Woundy IETF-77, Anaheim, U.S., March 2010. Changes since Hiroshima (-02 to -04). Non-normative classification of information disclosure (7.2) Based on mailing list thread

joylyn
Download Presentation

ALTO Requirements draft-ietf-alto-reqs-04

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ALTO Requirementsdraft-ietf-alto-reqs-04 Sebastian Kiesel Rich Woundy IETF-77, Anaheim, U.S., March 2010

  2. Changes since Hiroshima (-02 to -04) • Non-normative classification of information disclosure (7.2) • Based on mailing list thread • http://www.ietf.org/mail-archive/web/alto/current/msg00536.html • Disclosure of topology data vs. disclosure of user behavior • Disclosure towards the other ALTO entity vs. to a third party • One conclusion: we cannot prevent an ALTO client from redistributing the guiding information to another party (e.g. via gossip), unless we would use some kind of DRM – this is not what we want! Reflected in: • New requirement:REQ. ARv04-49: The operator of an ALTO server MUST NOT assume that an ALTO client will implement mechanisms or comply with rules that limit the ALTO client's ability to redistribute information retrieved from the ALTO server to third parties.

  3. Open issues / planned changes • Add discussion of the “provisioned bandwidth” attribute. • This attribute has been proposed many times • Privacy concerns • Useful? Dangerous? Causing disproportionately high load on high-bandwidth peers, i.e., penalizing premium customers? • See thread on mailing list • http://www.ietf.org/mail-archive/web/alto/current/msg00605.html • So far unclear whether new normative requirements will occur • Add discussion of special requirements caused by per-user attributes (as opposed to per-area / per-PID attributes), in particular in environments with highly dynamic address re-allocation. • To say it in other words: document the limitations of map-based approaches, as discussed in Hiroshima • So far unclear whether new normative requirements will occur

More Related