Subject: [alto] draft-ietf-alto-protocol-16 - minor comments

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Mon, 24 Jun 2013 17:02:31 +0000

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

[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". +This re/indirection is indicated by the media-type "application/alto-directory+json"+. In particular etc. ...".

[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."

[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-".

[Page 38] § 10 Protocol Specification: Service Information Resources
A "d" should be added in sentence, to have: "This section documents.... define+d+ ... document".

[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"?

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Mon, 24 Jun 2013 17:16:27 +0000

Sorry, In my comment on [Page 37] § 9.6. Cost Type, I made the same typo I wanted to point out and forgot to indicate that "Cost Type" should be replaced  by "Cost Metric" and "combinaton" by "combinat+i+on", so the sentence in § 9.6 should be:
be "The combinat+i+on of +a+ Cost+++Metric+ and a Cost++Mode defines a Cost++Type"

Sabine

De : [email-masked] [mailto:[email-masked]] De la part de RANDRIAMASY, SABINE (SABINE)
Envoyé : lundi 24 juin 2013 19:03
À : [email-masked]
Objet : [alto] draft-ietf-alto-protocol-16 - minor comments

Dear all,

[Page 27] §8.5.3 Example

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 1 Jul 2013 00:17:02 -0400

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-masked]> 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 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
      "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".
> +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". 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" 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-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>