Hi Murray, Thanks for the review and please see the replies inline.
Best, Kai > -----Original Messages----- > From: "Murray Kucherawy via Datatracker" <[email protected]> > Sent Time: 2021-12-06 13:46:28 (Monday) > To: "The IESG" <[email protected]> > Cc: [email protected], [email protected], [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
