Dear all, The chairs have suggested, which we think is a very good idea, that we sent out a summary of changes between -13 and -14. You can see a diff between the two versions at http://www.ietf.org/rfcdiff?url2=draft-ietf-alto-protocol-14
Any comments are welcome! ------------------ - Document organizational changes: - Added a new section (Section 6 of -14) on Endpoint Properties. - Split a single section (Section 6 of 013) into multiple sections: Protocol Specification: General Processing (Section 7 of -14); Protocol Specification: Basic ALTO Data Types (Section 8 of -14), and Protocol Specification: Service Information Resources (Section 9 of -14). The goal of the split is to better show the general structure of the alto protocol, to allow the possibility (or evaluation of the possibility) of extensions. - Added ALTO Error Code Registry in IANA Considerations (Section 12 of -14). Hence, all IANA matters are placed into a single place. - Deleted Verifying Correct Operation (Sec. 11.1.5 of -13) and Accounting Management (Sec. 11.2.5 of -13) in Manageability Considerations. - Specific content changes: - More specific clarification on the benefits of ALTO to Applications (Sec. 1.3.2 of -14) - Define the meaning of that two Version Tags match; added a sentence on potential collision probability (Sec. 5.3 of -14) - Added that an ALTO Server MUST define the 'pid' Endpoint Property Type and that the Version Tag of the Network Map used to return the pid property MUST be included. (Sec. 6.1 of -14) - Changed from MAY to MUST: An ALTO Server MUST support SSL/TLS [RFC5246] to implement server and/or client authentication ... (Sec. 7.3.5 in -14; Sec. 6.3.5 in -13) - Clarified that "An ALTO Client MUST interpret both HTTP Status Code and ALTO Error Code. If the ALTO Error Code indicates an error, the ALTO Client should consider that the request has failed." (Sec. 7.7 of -14) - Added a constraint on Cost Type: "For an identifier with the 'priv:' or 'exp:' prefix, an additional string (e.g., company identifier or random string) MUST follow to reduce potential collisions. For example, a short string after 'exp:' to indicate the starting time of a specific experiment is recommended." (Sec. 8.5 of -14) - Fixed the pid example to include map-vtag (Sec. 9.3.1.6 of -14) - Revised the discussion on Hosts with multiple endpoint addresses (Sec. 11.2 of -14) - Added a table (Table 3) to summarize Cost Types. - Added a table (Table 4) to summarize Endpoint Property Types. - Added a table (Table 5) to summarize Address Types. - Added one paragraph to discuss that ISPs must be cognizant that ALTO may reveal addition information when/if certain endpoint property is revealed (Sec. 13.1 of -14) - Added a couple sentences that filtering service may degenerate into a full map and hence becomes an operation issue that needs to be considered (Sec. 14.1.1 of -14) - Added a suggestion on the possibility of a monitoring service for ALTO (Sec. 14.1.4 of -14). ------------------
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
