Hi Richard, Thanks a lot for your updates that all perfectly address my comments and clarify a lot. I have inserted suggestions inline, on your update on "[Page 27] §8.5.3 Example" and leave it up to you to use them. Their purpose is to clarify from the beginning the fact that a Cost Type name is local to an IRD and the names listed in the "meta" member are not necessarily supported by all applicable resources entries. Thanks Sabine
De : [email protected] [mailto:[email protected]] De la part de Y. Richard Yang Envoyé : lundi 1 juillet 2013 06:17 À : RANDRIAMASY, SABINE (SABINE) Cc : [email protected] Objet : Re: [alto] draft-ietf-alto-protocol-16 - minor comments Hi Sabine, Thanks a lot for the excellent comments! Please see below. On Mon, Jun 24, 2013 at 1:02 PM, RANDRIAMASY, SABINE (SABINE) <[email protected]<mailto:[email protected]>> wrote: Dear all, While going through the latest update, I have listed some minor comments and typos and suggest some re-phrasings below, in particular in paragraphs on new features such as the new cost type and the in/re-direction to other IRDs. I also attached a text file with the comments. Hoping it helps. Sabine --------------------------------------- COMMENTS ON draft-ietf-alto-protocol-16 --------------------------------------- - everything in ++ indicates ADDED text, including white space - everything in -- indicated REMOVED text [Page 27] §8.5.3 Example The example IRD exposes a capability called "cost-type-name" that is not introduced before and it would help to add some sentences to better distinguish the roles of "cost-type-name" and "cost-type". Especially as the combination of cost metric and cost mode into cost type is new to people who already coded an ALTO Client. Besides, the field "cost-type" of the meta member defines the cost type names but also specifies their members. So I propose to add some text after the example IRD and before sentence "Specifically, the "meta" member of the example IRD defines....", that would look like: "When an ALTO Client wants to fetch the Cost Types supported at the uris listed in the ALTO Server, it should look after string "cost-type-names". The values of "cost-type-names" indicate Cost Types whose Cost Metric and Cost Mode are specified in the field "cost-type" of member "meta" of the IRD. Specifically etc. ...". Good comment. Here is the new text based on your suggestion: Specifically, the "meta" member of the example IRD defines a field named "cost-types", which defines the names of cost types[ +for this IRD+ ] . For example, "num-routing" in the example is the name that refers to a Cost Type with Cost Mode being "numerical" and Cost Metric being "routingcost". The value of "cost-types" is of type IRDMetaCostTypes defined below; see Section 9.6 for the definition of CostType. The names defined in "cost-types" can be used in [ -the - ] [ +one or more+ ] "resources" entries. For example, the second entry of "resources" defines a Cost Map. The "cost-type-names" of its "capabilities" specifies that this resource supports a Cost Type named as "num-routing". The ALTO Client looks up the name "num-routing" in "cost-types" of the IRD to obtain the Cost Type named as "num-routing". The last entry of "resources" uses all four names defined in "cost-types". [Page 28] § 8.5.4 Delegation and Multiple Choices Redirection to another IRD is another new feature so like in the previous section, I suggest to add text on the media-type. A proposal for the first paragraph: "... In the example above, the -- +fourth uri/entry+ provides additional Network and Cost Maps via a separate subdomain, "custom.alto.example.com<http://custom.alto.example.com>". +This re/indirection is indicated by the media-type "application/alto-directory+json"+. In particular etc. ... ". Good suggestion. Here is the new text based on your suggestion: Consider the preceding example. The fourth entry of "resources" provides additional Network and Cost Maps via a separate subdomain: "custom.alto.example.com<http://custom.alto.example.com>". This delegation is indicated by the media-type "application/alto-directory+json". The ALTO Client can discover the maps available at "custom.alto.example.com<http://custom.alto.example.com>" by successfully performing a request to "http://custom.alto.example.com/maps": [Page 30] § 8.5.5.1 ALTO Client text says: "In general, it is preferred for ALTO Clients to use GET requests where appropriate, since it is more likely for responses to be cachable." As the ECS seems as attractive as the Cost Map Service in many use cases, I'd prefer to mention preferences for both CostMap and ECS with a text like: "An ALTO Client may prefer to use GET requests for cacheable information. It may on the other hand prefer POST requests for example to get ALTO costs or properties on a restricted set of PIDs or Endpoints or to update cached information previously acquired via GET requests." Here is the revised text to add the POST part f your suggestion: In general, it is preferred for ALTO Clients to use GET requests where appropriate, since it is more likely for responses to be cachable. However, an ALTO Client may need to use POST, for example, to get ALTO costs or properties that are for a restricted set of PIDs or Endpoints, or to update cached information previously acquired via GET requests." [Page 37] § 9.6. Cost Type text says: "The combinaton of CostType and a CostMode defines a CostType" Given the latest specs in §6.1 and the IRD examples, the sentence should be "The combinaton of +a+ Cost++Type and a Cost++Mode defines a Cost++Type" The object CostType specified in this section contains a field called "CostModel" where I believe the "l" should be removed to give "CostMode-l-". Fixed both: The combination of a CostMetric and a CostMode defines a CostType: object { CostMetric cost-metric; CostMode cost-mode; [JSONString description;] } CostType; [Page 38] § 10 Protocol Specification: Service Information Resources A "d" should be added in sentence, to have: "This section documents.... define+d+ ... document". Good catch. Fixed. [Page 40] Section 10.1.1.6 Example In paragraph after the example, in following part of 2nd sentence: "such as transforming the Network Map into a IP trie": should it be "tree"? I see the ambiguity. Here is a new text: If lookup efficiency at runtime is crucial, then the returned Cost Map and Network Map can be transformed into data structures offering more efficient lookup. For example, one may store the Cost Map as a matrix, and the Network Map as a trie-based data structure, which may allow efficient longest-prefix matching of IP addresses. Please let us know if they address your comments. Thanks again. Richard _______________________________________________ alto mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
