[alto] Summary of draft-ietf-alto-protocol changes between -13 and -14

["Y. Richard Yang" <[e-mail]>]

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).

------------------