Subject: Re: [alto] State of the WG

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Fri, 5 Feb 2016 17:56:03 +0000

Hi Michael, Hans and all,

I have volunteered to review draft-ietf-alto-deployment-13. As time passes and the document is long, I prefer to send you my feedback piecewise, focusing first on the updated sections. For the sake of rapidity, I sometimes put Nits and other feedback together. 

So below, you will find my feedback on section 3.6. 
Then, I'll send you my feedback on sections 1 to 3.4 included. 

All in all, thanks for this clarified and enriched version of draft-ietf-alto-deployments. I found no major issues but some sentences need to be re-formulated and figures need be referenced in the text. Don't hesitate to get back to me if needed. 

Thanks,
Sabine

------------------------------------------------------
I used the following conventions:

(1.2.3) section nb
(p12) page nb
para 2 = paragraph 2

(++ blabla) = added blabla
(-- blabla) = removed blabla
"old blabla" ==> "new blabla" = replace "old blabla" by "new blabla"

---------
General:

Figures 14 to 20: the caption should be harmonized with the rest of the document in that the common nouns should be written in low case and not start with a capital letter.

In section 3.6.4 Calculation of Cost Map: many clarifications are needed on the path cost calculation

---------
(p40)
--------- 
para 1: "Figure 2" should be replaced by "Figure 15" as fas as I understand
para 2: "listed information" ==> "listed information(++s)"

---------
(p41)
---------
- para 1: "As example" ==> "For example"
- para 2: "information" ==> "information(++s)"
- item 1: "Link" ==> "link"
- (3.6.2), title: for transition to section 3.6.3 I suggest "Potential (++ input) Data Processing and Storage"
- (3.6.2), para 3: to reference Figure 16, I suggest: "Each router could..." ==> "(++ As illustrated in Figure 16 for the router R2 of Figure 14,) each router could..."

---------
(p42)
---------
- item 2: to avoid hinting that an endpoint may be associated to several PIDs, I suggest: "AS numbers, or AS distances.
 Endpoints may belong to..." ==> "AS numbers (--,) or AS distances.
 Endpoints may be connected to"
- para 2: "and/ or" ==> "and/or"

- The presence of the remaining text "A suitable information... belongs to its own AS" before Figures 16 and 17 is pretty confusing, especially when encountering terms "weights" and "metrics". So I strongly suggest to move this remaining text after Figure 17 (p44). 

- instead: we need to reference Figure 16 and clarify the example attribute "Metric". So I suggest right after "just to name a few", to append "Figure 16 provides an example set of attributes associated to the router R2 of the exemple network depicted in Figure 14. The attribute "Metric" is an example of ... TBC"

---------
(p43)
---------
- Figure 16: please clarify what "default client subnet metric" can be
- para 2: reference to Figure 17 needed. i suugest replacing "Router R8... " by "Figure 17 provides values for the same attributes associated to router R8. R8... " 

---------
(p44)
---------
- para 1 (after text moved from p42): Insert ref to fig. 18, suggestion: "In the example, the link attributes..." ==> "Figure 18 provides an example where the link attributes..."

---------
(p45)
---------
- (3.6.3) title: in relation to (3.6.2) I suggest: "Calculation of Network Map (++from the Input Data)"
- para 1: suggestion: "presentation of the network to a coarse-grained matrix presentation" ==> "(++re)presentation of the network to a coarse(++r) grained (++and abstracted) matrix (++re)presentation"
- para 2: algorithm(++s) can utilize all (?? you mean "all" or "any" ?) information ....  The functions ... to simplify the map or (--to) hide details ... published (--with) (++in) the resulting ALTO network map.

---------
(p46)
---------
- para 2: "Figure 14" ==> "Figure 19"
- (3.6.4), para 1: "calculate values unidirectional" ==> "calculate unidirectional values"

--------- 
(p47)
---------
It is necessary to clarify the text on path calculation in this page. 

--- para 1: 
- "or subnet the cost" ==> "or subnet (++,) the cost"
- "cost function may calculate" ==> "cost function may (++first) calculate"
- "In that case a" ==> "In that case (++,) a"
- "required which decide(--s)" ==> "required to decide..."
- as this section is about computing values exposed by the ALTO Server, I suggested to append to following text. "resulting cost value" ==> "resulting cost value (++as RFC7285 allows one cost value only between 2 PIDs.)"
- Such (++a) tie-breaker can be (a++) simple function(--s) such as minimum, maximum, or average value.

--- para 2: reformulation is needed here in order to cover the most "popular" optimal path extraction methods. 
- "the minimum path weight." ==> "the minimum weight path."

- I recommend the following insertion: "The path weight is the sum..." ==> "(++When the link weight is represented by an additive metric,) the path weight is the sum...". 
The reason is that: when the link weight metric represents a bandwidth performance, the metric composition law is "MIN" and path weight is equal to the smallest of the link weights. For a metric such as packet loss, the path weight is the multiplication over all links.  

- sentence "Hence, the cost function must first determine the path before it can determine any other metric value": besed on my previous comment, I'd rather say "Hence, the cost function generally extracts the optimal path w.r.t. a chosen metric". 

- sentence "As a result, the metric value can differ from the expectation where the path with the shortest path weight was not considered" is hard to understand and could be removed and replaced with some elaboration on the Dijkstra example. I will propose some formulation right after the next item. 

- "But it is also possible..." ==> "(--But) it is also possible..."

- Suggestion for para 2 (let me know if I missed something)
"No matter what metric the cost function is using, the path from source to destination is usually defined by the minimum (-+ weight) path.
 (++When the link weight is represented by an additive metric,) the path weight is the sum of the link weights of all traversed links.
 The path may be determined for instance with the Bellman-Ford or Dijkstra algorithm. The latter progressively builds the shortest path in terms of cumulated link lengths. In our example, the link lengths are link weights with values illustrated in Figure 15. (--2 sentences removed). (--But) It is also possible that more than one path..." 

--- para 3
-  "values for other PID pairs for arbitrary reasons" ==> " values for some PID pairs due to arbitrary reasons"

--- para 4
- "In this example, the selected
 metric..." ==> "Figure 20 provides an example where the selected metric..."
- "from source to (++ the endpoints connected to the) destination PID": otherwise all the values in Figure 20 should be minus 1. 

--------- 
(p47) 
--------- 
para 1: "Due to the minimum value tie-breaker 3..." ==> "Due to the minimum (++hopcount)value tie-breaker (++,) 3..."

>>-----Message d'origine-----
>>De : alto [mailto:[email-masked]] De la part de Vijay K. Gurbani
>>Envoyé : mardi 26 janvier 2016 16:29
>>À : IETF ALTO
>>Objet : [alto] State of the WG
>>
>>Folks: The mailing list has been awfully quiet.
>>
>>Presently, we have 3 active I-Ds that are being tracked towards charter
>>fulfillment:
>>
>>1. draft-ietf-alto-deployments is in its second WGLC.  The new WGLC
>>ends
>>  on February 3, 2016.
>>
>>2. draft-ietf-alto-incr-update-sse appears to be moving along and there
>>  do not seem to be any stop gap issues that we are aware of.  Authors,
>>  please inform the WG if there are.
>>
>>3. draft-ietf-alto-multi-cost is also fairly mature.
>>
>>It seems reasonable to move 2 and 3 ahead.
>>
>>Then there are a number of independent submissions dating back to Sep-
>>Oct 2015 timeframe.  These have not been updated and nor has there been
>>much discussion on the mailing list.  Some of these submissions are
>>important for charter deliverables related to graph representation
>>formats.  Can the authors of the independent submissions kindly share
>>what their plans are with respect to the drafts?
>>
>>This will help us gauge whether or not we should meet face-to-face in
>>Buenos Aires or have an interim meeting before it and meet face-to-face
>>in Berlin.
>>
>>Note that while the final plans are still up in the air and subject to
>>change, there is a good chance that neither Jan or I will be able to
>>make it to Buenos Aires.  However, if a F2F meeting is desired, it is
>>important to get a sense of the energy behind the independent drafts,
>>as the list traffic has been woefully quiet on this front.
>>
>>Thanks,
>>
>>- vijay
>>--
>>Vijay K. Gurbani, Bell Laboratories, Nokia 1960 Lucent Lane, Rm. 9C-
>>533, Naperville, Illinois 60563 (USA)
>>Email: vkg@{bell-labs.com,acm.org} / [email-masked]
>>Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
>>
>>_______________________________________________
>>alto mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/alto

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Fri, 5 Feb 2016 17:58:53 +0000

Hi again, 

I don't know if it will work, but I try to send my review as an attachment.
Cheers,
Sabine

>>De : alto [mailto:[email-masked]] De la part de EXT Randriamasy,
>>Sabine (Nokia - FR)
>>Envoyé : vendredi 5 février 2016 18:56
>>À : Gurbani, Vijay (Nokia - US); IETF ALTO
>>Objet : Re: [alto] State of the WG
>>
>>
>>I have volunteered to review draft-ietf-alto-deployment-13. As time
>>passes and the document is long, I prefer to send you my feedback
>>piecewise, focusing first on the updated sections. For the sake of
>>rapidity, I sometimes put Nits and other feedback together.
>>
>>All in all, thanks for this clarified and enriched version of draft-
>>ietf-alto-deployments. I found no major issues but some sentences need
>>to be re-formulated and figures need be referenced in the text. Don't
>>hesitate to get back to me if needed.
>>
>>Thanks,
>>Sabine
>>
>>Figures 14 to 20: the caption should be harmonized with the rest of the
>>document in that the common nouns should be written in low case and not
>>start with a capital letter.
>>
>>para 1: "Figure 2" should be replaced by "Figure 15" as fas as I
>>understand para 2: "listed information" ==> "listed information(++s)"
>>
>>---------
>>(p41)
>>---------
>>- (3.6.2), para 3: to reference Figure 16, I suggest: "Each router
>>could..." ==> "(++ As illustrated in Figure 16 for the router R2 of
>>Figure 14,) each router could..."
>>
>>---------
>>(p42)
>>---------
>>- item 2: to avoid hinting that an endpoint may be associated to
>>several PIDs, I suggest: "AS numbers, or AS distances.
>>- The presence of the remaining text "A suitable information... belongs
>>to its own AS" before Figures 16 and 17 is pretty confusing, especially
>>when encountering terms "weights" and "metrics". So I strongly suggest
>>to move this remaining text after Figure 17 (p44).
>>
>>- instead: we need to reference Figure 16 and clarify the example
>>attribute "Metric". So I suggest right after "just to name a few", to
>>append "Figure 16 provides an example set of attributes associated to
>>the router R2 of the exemple network depicted in Figure 14. The
>>attribute "Metric" is an example of ... TBC"
>>
>>---------
>>(p43)
>>---------
>>- para 2: reference to Figure 17 needed. i suugest replacing "Router
>>R8... " by "Figure 17 provides values for the same attributes
>>associated to router R8. R8... "
>>
>>---------
>>(p44)
>>---------
>>- para 1 (after text moved from p42): Insert ref to fig. 18,
>>suggestion: "In the example, the link attributes..." ==> "Figure 18
>>provides an example where the link attributes..."
>>
>>
>>---------
>>(p45)
>>---------
>>- para 1: suggestion: "presentation of the network to a coarse-grained
>>matrix presentation" ==> "(++re)presentation of the network to a
>>coarse(++r) grained (++and abstracted) matrix (++re)presentation"
>>- para 2: algorithm(++s) can utilize all (?? you mean "all" or "any" ?)
>>information ....  The functions ... to simplify the map or (--to) hide
>>details ... published (--with) (++in) the resulting ALTO network map.
>>
>>---------
>>(p46)
>>---------
>>- as this section is about computing values exposed by the ALTO Server,
>>I suggested to append to following text. "resulting cost value" ==>
>>"resulting cost value (++as RFC7285 allows one cost value only between
>>2 PIDs.)"
>>--- para 2: reformulation is needed here in order to cover the most
>>"popular" optimal path extraction methods.
>>- I recommend the following insertion: "The path weight is the sum..."
>>==> "(++When the link weight is represented by an additive metric,) the
>>path weight is the sum...".
>>The reason is that: when the link weight metric represents a bandwidth
>>performance, the metric composition law is "MIN" and path weight is
>>equal to the smallest of the link weights. For a metric such as packet
>>loss, the path weight is the multiplication over all links.
>>
>>- sentence "Hence, the cost function must first determine the path
>>before it can determine any other metric value": besed on my previous
>>comment, I'd rather say "Hence, the cost function generally extracts
>>the optimal path w.r.t. a chosen metric".
>>
>>- sentence "As a result, the metric value can differ from the
>>expectation where the path with the shortest path weight was not
>>considered" is hard to understand and could be removed and replaced
>>with some elaboration on the Dijkstra example. I will propose some
>>formulation right after the next item.
>>
>>- Suggestion for para 2 (let me know if I missed something) "No matter
>>what metric the cost function is using, the path from source to
>>destination is usually defined by the minimum (-+ weight) path.
>> (++When the link weight is represented by an additive metric,) the
>>path weight is the sum of the link weights of all traversed links.
>> The path may be determined for instance with the Bellman-Ford or
>>Dijkstra algorithm. The latter progressively builds the shortest path
>>in terms of cumulated link lengths. In our example, the link lengths
>>are link weights with values illustrated in Figure 15. (--2 sentences
>>removed). (--But) It is also possible that more than one path..."
>>
>>--- para 3
>>- "from source to (++ the endpoints connected to the) destination PID":
>>otherwise all the values in Figure 20 should be minus 1.
>>
>>---------
>>(p47)
>>---------
>>para 1: "Due to the minimum value tie-breaker 3..." ==> "Due to the
>>minimum (++hopcount)value tie-breaker (++,) 3..."
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>>De : alto [mailto:[email-masked]] De la part de Vijay K.
>>>>Gurbani Envoyé : mardi 26 janvier 2016 16:29 À : IETF ALTO Objet :
>>>>[alto] State of the WG
>>>>
>>>>Oct 2015 timeframe.  These have not been updated and nor has there
>>>>been much discussion on the mailing list.  Some of these submissions
>>>>are important for charter deliverables related to graph
>>representation
>>>>Buenos Aires or have an interim meeting before it and meet
>>>>face-to-face in Berlin.
>>>>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 5 Feb 2016 21:01:37 -0600

On 02/05/2016 11:56 AM, Randriamasy, Sabine (Nokia - FR) wrote:
> All in all, thanks for this clarified and enriched version of
> draft-ietf-alto-deployments. I found no major issues but some
> sentences need to be re-formulated and figures need be referenced in
> the text. Don't hesitate to get back to me if needed.

Sabine: Awesome!  On behalf of the chairs, thanks for taking the time
to review the updated document.

Cheers,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Nokia
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Mon, 8 Feb 2016 16:41:39 +0000

As promised, here is my feedback to sections 1 to 3.4 included. I tried to separate "Nits only" and "nits + comments".
In a first step, I am sending the review as an attachment. 

Again, thanks a lot for the work, this text is very well structured, clear and interesting. Some parts need a bit of clarifications and also, some re-phrasing to highlight the advantages of ALTO Services and providing incentives to use them is suggested here and there.  

Thanks,
Sabine

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Mon, 8 Feb 2016 16:49:56 +0000

Hi again,

Apologies, I should also have reviewed the text of my e-mail. The attached review "feedback_deployment_13_section1-to-3-4_sr.txt" I just sent STOPS at beginning of 3.4, as I wanted to focus on the last updates.

Thanks,
Sabine

>>De : Randriamasy, Sabine (Nokia - FR)
>>Envoyé : lundi 8 février 2016 17:42
>>À : Randriamasy, Sabine (Nokia - FR); Gurbani, Vijay (Nokia - US); IETF
>>ALTO
>>Objet : RE: [alto] State of the WG
>>
>>As promised, here is my feedback to sections 1 to 3.4 included. I tried
>>to separate "Nits only" and "nits + comments".
>>Again, thanks a lot for the work, this text is very well structured,
>>clear and interesting. Some parts need a bit of clarifications and
>>also, some re-phrasing to highlight the advantages of ALTO Services and
>>providing incentives to use them is suggested here and there.
>>
>>Thanks,
>>Sabine
>>
>>
>>>>De : alto [mailto:[email-masked]] De la part de EXT
>>>>Randriamasy, Sabine (Nokia - FR) Envoyé : vendredi 5 février 2016
>>>>18:56 À : Gurbani, Vijay (Nokia - US); IETF ALTO Objet : Re: [alto]
>>>>State of the WG
>>>>
>>>>
>>>>Figures 14 to 20: the caption should be harmonized with the rest of
>>>>the document in that the common nouns should be written in low case
>>>>and not start with a capital letter.
>>>>
>>>>- (3.6.2), title: for transition to section 3.6.3 I suggest
>>"Potential
>>>>(++ input) Data Processing and Storage"
>>>>- The presence of the remaining text "A suitable information...
>>>>belongs to its own AS" before Figures 16 and 17 is pretty confusing,
>>>>especially when encountering terms "weights" and "metrics". So I
>>>>strongly suggest to move this remaining text after Figure 17 (p44).
>>>>
>>>>- para 2: algorithm(++s) can utilize all (?? you mean "all" or "any"
>>>>?) information ....  The functions ... to simplify the map or (--to)
>>>>hide details ... published (--with) (++in) the resulting ALTO network
>>map.
>>>>
>>>>---------
>>>>(p46)
>>>>---------
>>>>- as this section is about computing values exposed by the ALTO
>>>>Server, I suggested to append to following text. "resulting cost
>>>>value" ==> "resulting cost value (++as RFC7285 allows one cost value
>>>>only between
>>>>2 PIDs.)"
>>>>==> "(++When the link weight is represented by an additive metric,)
>>>>the path weight is the sum...".
>>>>-  "values for other PID pairs for arbitrary reasons" ==> " values
>>for
>>>>some PID pairs due to arbitrary reasons"
>>>>
>>>>
>>>>--- para 4
>>>>>>formats.  Can the authors of the independent submissions kindly
>>>>>>share what their plans are with respect to the drafts?
>>>>>>
>>>>>>This will help us gauge whether or not we should meet face-to-face
>>>>>>in Buenos Aires or have an interim meeting before it and meet
>>>>>>face-to-face in Berlin.
>>>>>>
>>>>>>make it to Buenos Aires.  However, if a F2F meeting is desired, it
>>>>>>is important to get a sense of the energy behind the independent
>>>>>>drafts, as the list traffic has been woefully quiet on this front.
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>- vijay
>>>>>>--

---

From: Gao Kai <[email-masked]>
Date: Tue, 23 Feb 2016 09:48:50 +0800

Hello Vijay and all,

Ican go through the WG drafts 2 and 3 (the SSE and Multi-cost) and give
some feedbacks as soon as possible.

Regards,
Kai

On 26/01/16 23:29, Vijay K. Gurbani wrote:
> 1. draft-ietf-alto-deployments is in its second WGLC.  The new WGLC ends
>  on February 3, 2016.
>
> Note that while the final plans are still up in the air and subject
> to change, there is a good chance that neither Jan or I will be able to

---

From: Gao Kai <[email-masked]>
Date: Tue, 23 Feb 2016 15:51:28 +0800

Hiall,

Below are my feedbacks on the multi-cost draft:

Review on draft-ietf-alto-multi-cost-01:

Notation:
sec#X: Section X
para#X: paragraph X
line#X: line X
=====

sec#1-para#1-line#3:
Typo: "such" -> "such as"

sec#1-para#7-line4:
Typo: "definition" -> "definitions"

sec#3.6:

Instead of reusing the "constraints" field for "testable-cost-types",
I'd like
to propose that we enforce the use of "or-constraints".

Firstly, the format of "testable-cost-types" is a list of cost types,
but the
"constraints" field is originally designed for testing one cost type.  Even
using the extended format, the conditions can only be concatenated by
the AND
operator.  Using "or-constraints", on the other hand, provides better
flexibility.

Secondly, according to the draft, if the "testable-cost-types" is
missing, the
servers will test the "multi-cost-types" with the conditions specified by
"or-constraints".  Thus using "or-constraints" for both cases can
simplify the
implementation because the "constraints" field can be totally ignored in
this
case.

Finally, from the example in section 5.4, I feel the extended usage of
"constraints" seems to be only designed for the special case that the
number of
elements in "testable-cost-types" is 1, which I think the benefits are not
worth the complexity it brings to both clients and servers.

sec4.1.1-para#1:

The type of "or-constraints" should be:

    [JSONArray or-constraints<0..*>;]

sec4.1.1:

In the description for "testable-cost-types", the first paragraph says it is
described for the "constraints" parameter, which should be for the
"or-constraints" parameter or, if we decide to reuse the "constraints"
field,
for both parameters.

sec4.1.2:

The description for "testable-cost-type-names" capability indicates it
requires
the "cost-constraints" capability to be "true".  However, in that case,
according to RFC 7285, all cost types should be able to be included in
constraints, which means they are "testable".  I cannot think of a good
reason
of doing that so my proposal is that we do the opposite:

When the "cost-constraints" is set to "true", all types are testable and the
"testable-cost-type-names" SHOULD NOT appear and MUST be omitted if it does.
Otherwise, only the types specified in the "testable-cost-type-names" are
considered testable.

You thoughts and opinions are highly appreciated!

Regards,
Kai

On 23/02/16 09:48, Gao Kai wrote:
> Hello Vijay and all,
>
> Ican go through the WG drafts 2 and 3 (the SSE and Multi-cost) and
> give some feedbacks as soon as possible.
>
> Regards,
> Kai
>

---

From: Jensen Zhang <[email-masked]>
Date: Tue, 23 Feb 2016 16:36:20 +0800

Hi all,

There are some considerations about draft-ietf-alto-incr-update-sse.

According to this thread [1], there is an unclear description in the input
parameters of update steam service (Section 6.3). I also suggest the first
fixing option from Wendy, which is to make “start-updates” and
“stop-updates” exclusive. Since “stream-id” is only used by “stop-updates”,
why not make it a filed in the value of “stop-updates”?

And another consideration is about Stream Restart (Section 9.2). Can we
support to compute a merge patch between two special tags (for those
resource with tags, such as networkmap).

Also looking forward to a more detailed review for this draft.

[1] https://mailarchive.ietf.org/arch/msg/alto/peGfjZ4_s1GXsKx5hlEhQX_CIK0

Regards,
Jensen

2016-02-23 15:51 GMT+08:00 Gao Kai <[email-masked]>:

> Hi all,
> Instead of reusing the "constraints" field for "testable-cost-types", I'd
> like
> Firstly, the format of "testable-cost-types" is a list of cost types, but
> the
> using the extended format, the conditions can only be concatenated by the
> AND
> Secondly, according to the draft, if the "testable-cost-types" is missing,
> the
> "or-constraints".  Thus using "or-constraints" for both cases can simplify
> the
> I can go through the WG drafts 2 and 3 (the SSE and Multi-cost) and give
> alto mailing [email-masked]://www.ietf.org/mailman/listinfo/alto
>
>
>

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Tue, 23 Feb 2016 10:24:51 +0000

Hi Kai,

Thanks a lot for the review.
Sabine

De : alto [mailto:[email-masked]] De la part de EXT Gao Kai
Envoyé : mardi 23 février 2016 08:51
À : Gurbani, Vijay (Nokia - US); IETF ALTO
Objet : Re: [alto] State of the WG

Hi all,

Notation:
sec#X: Section X
para#X: paragraph X
line#X: line X
=====

sec#1-para#1-line#3:

sec#1-para#7-line4:

sec#3.6:

Instead of reusing the "constraints" field for "testable-cost-types", I'd like
to propose that we enforce the use of "or-constraints".

Firstly, the format of "testable-cost-types" is a list of cost types, but the
"constraints" field is originally designed for testing one cost type.  Even
using the extended format, the conditions can only be concatenated by the AND
operator.  Using "or-constraints", on the other hand, provides better
flexibility.

Secondly, according to the draft, if the "testable-cost-types" is missing, the
servers will test the "multi-cost-types" with the conditions specified by
"or-constraints".  Thus using "or-constraints" for both cases can simplify the
implementation because the "constraints" field can be totally ignored in this
case.

Finally, from the example in section 5.4, I feel the extended usage of
"constraints" seems to be only designed for the special case that the number of
elements in "testable-cost-types" is 1, which I think the benefits are not
worth the complexity it brings to both clients and servers.

sec4.1.1-para#1:

sec4.1.1:

In the description for "testable-cost-types", the first paragraph says it is
described for the "constraints" parameter, which should be for the
"or-constraints" parameter or, if we decide to reuse the "constraints" field,
for both parameters.

sec4.1.2:

The description for "testable-cost-type-names" capability indicates it requires
the "cost-constraints" capability to be "true".  However, in that case,
according to RFC 7285, all cost types should be able to be included in
constraints, which means they are "testable".  I cannot think of a good reason
of doing that so my proposal is that we do the opposite:

Regards,
Kai

I can go through the WG drafts 2 and 3 (the SSE and Multi-cost) and give some feedbacks as soon as possible.

Regards,
Kai

Thanks,

- vijay

alto mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Wed, 24 Feb 2016 14:28:19 +0000

Hi Sabine,

Thanks a lot for the review! I am currently busy but I will look into it as soon as possible.

Thanks

Michael

-----Original Message-----
From: alto [mailto:[email-masked]] On Behalf Of EXT Randriamasy, Sabine (Nokia - FR)
Sent: Monday, February 08, 2016 5:50 PM
To: Randriamasy, Sabine (Nokia - FR); Gurbani, Vijay (Nokia - US); IETF ALTO
Subject: Re: [alto] State of the WG

Hi again,

Thanks,
Sabine

>>À : Randriamasy, Sabine (Nokia - FR); Gurbani, Vijay (Nokia - US); 
>>IETF ALTO Objet : RE: [alto] State of the WG
>>
>>As promised, here is my feedback to sections 1 to 3.4 included. I 
>>tried to separate "Nits only" and "nits + comments".
>>also, some re-phrasing to highlight the advantages of ALTO Services 
>>and providing incentives to use them is suggested here and there.
>>
>>Thanks,
>>Sabine
>>
>>
>>>>to be re-formulated and figures need be referenced in the text. 
>>>>Don't hesitate to get back to me if needed.
>>>>
>>>>Thanks,
>>>>Sabine
>>>>
>>>>attribute "Metric". So I suggest right after "just to name a few", 
>>>>to append "Figure 16 provides an example set of attributes 
>>>>associated to the router R2 of the exemple network depicted in 
>>>>Figure 14. The attribute "Metric" is an example of ... TBC"
>>>>
>>>>---------
>>>>(p43)
>>>>---------
>>>>before it can determine any other metric value": besed on my 
>>>>previous comment, I'd rather say "Hence, the cost function generally 
>>>>extracts the optimal path w.r.t. a chosen metric".
>>>>
>>>>Dijkstra algorithm. The latter progressively builds the shortest 
>>>>path in terms of cumulated link lengths. In our example, the link 
>>>>lengths are link weights with values illustrated in Figure 15. (--2 
>>>>sentences removed). (--But) It is also possible that more than one path..."
>>>>
>>>>--- para 3
>>>>to

---

From: "Randriamasy, Sabine (Nokia - FR)" <[email-masked]>
Date: Wed, 24 Feb 2016 14:57:00 +0000

Hi Michael,

You are welcome. No worries, I will be on vacation next week.
Best regards
Sabine

>>De : Scharf, Michael (Nokia - DE)
>>Envoyé : mercredi 24 février 2016 15:28
>>À : Randriamasy, Sabine (Nokia - FR); Randriamasy, Sabine (Nokia - FR);
>>Gurbani, Vijay (Nokia - US); IETF ALTO
>>Apologies, I should also have reviewed the text of my e-mail. The
>>attached review "feedback_deployment_13_section1-to-3-4_sr.txt" I just
>>sent STOPS at beginning of 3.4, as I wanted to focus on the last
>>updates.
>>
>>Thanks,
>>Sabine
>>
>>
>>draft-

---

From: Qiao Xiang <[email-masked]>
Date: Sun, 28 Feb 2016 17:26:27 -0500

Hi All,

The following are my comments on the draft-ietf-alto-incr-update-sse draft.

1. The last sentence of Paragraph 4 in Sec. 2 and the last sentence in Sec.
6.5 use the same example. but the first one uses "should" and the second
one uses "SHOULD". I suggest capitalize the first one to make the draft
consistent.

2. Section 6.6.3, "the that stream" -> "the same stream".

3. Section 6.9, first sentence of Paragraph 1: "a line-at-a-time" -> "one
line-at-a-time" seems more appropriate.

4. Section 6.9, second sentence of Paragraph 1: "of not tens of" -> "if not
tens of".

5. Regarding the exclusion issue of "start-updates" and "stop-updates",
discussed by Hans, Wendy and Jensen, I am inclined to vote for Wendy's
option 3, i.e., using two separate request "start-new-update-stream" and
"modify-existing-update-stream".

I will post to the group if I have any other comments. Thanks.

Best
Qiao

-- 
Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University