Re: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-path-vector-19: (with COMMENT)

Hi Murray,

Thanks for the review and please see the replies inline.

Best,
Kai

> -----Original Messages-----
> From: "Murray Kucherawy via Datatracker" <noreply@ietf.org>
> Sent Time: 2021-12-06 13:46:28 (Monday)
> To: "The IESG" <iesg@ietf.org>
> Cc: alto-chairs@ietf.org, draft-ietf-alto-path-vector@ietf.org, alto@ietf.org
> Subject: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-path-vector-19: (with COMMENT)
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-alto-path-vector-19: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 6.2.1 should be at least a sentence, perhaps:
> 

>   The Entity Domain Type is "ane".

We will use the proposed text.

> 
> I think Section 7.2.1 would be better expressed as:
> 
>    The media type of the multipart Filtered Cost Map resource is
>    "multipart/related" and the required "type" parameter MUST have
>    a value of "application/alto-costmap+json".
> 
> By constraining the type to be a specific string, you're removing the
> flexibility of a MIME parser to allow intervening whitespace, line wrapping,

> etc.

Thanks for the suggestion. We will use the proposed text (and modify 7.3.1 accordingly) in the next revision.

> 
> Why are the RECOMMENDEDs in 7.2.6 and 7.3.6 not REQUIRED?  Is there ever a
> reason to send them out-of-order?

>

We use "RECOMMENDED" because the order of part messages does not

affect the correctness as the root object can always be correctly identified

using the "start" parameter and the application may pipeline the parsing and

processing the two parts with an incremental MIME library (e.g., FeedPaser

in Python). The path vector part is generally larger, e.g., for the flow scheduling

problem the path vector part contains the 1 coefficients of a routing matrix

and the property map part contains the link capacities).

PV: path vector part

PM: property map part

Tr: Time to receive

Tp: Time to parse

Th: Time to handle

When order is (PV, PM):

|Tr(PV)   | Tp(PV)    | Th(PV)    |

          | Tr(PM)| Tp(PM) | Th(PM) |

When order is (PM, PV):

| Tr(PM)| Tp(PM) | Th(PM) |

        |Tr(PV)   | Tp(PV)    | Th(PV)    |

However, in cases where the application do not need to evaluate the whole

set but each (source, destination) pair, the application may want to receive the

property map part first:

When order is (PV, PM):

|Tr(PV)   | Tp(PV)    |             | Th(PV)    |

          | Tr(PM)| Tp(PM) | Th(PM) |

When order is (PM, PV):

| Tr(PM)| Tp(PM) | Th(PM) |

        |Tr(PV)   | Tp(PV)    | Th(PV)    |

> 
> 
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto