Hi, Rob: Thank for your raising this DISCUSS, see clarification below. -----邮件原件----- 发件人: Robert Wilton via Datatracker [mailto:[email protected]] 发送时间: 2022年5月25日 23:06 收件人: The IESG <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 主题: Robert Wilton's Discuss on draft-ietf-alto-cost-mode-03: (with DISCUSS)
Robert Wilton has entered the following ballot position for draft-ietf-alto-cost-mode-03: Discuss 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/about/groups/iesg/statements/handling-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-cost-mode/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, This is a "discuss" discuss, as in I'm not sure the document is wrong, but I thought that it would be helpful to flag this for further discussion. In RFC 7285, cost-mode is defined as a field that MUST take one of two string values, either "numerical" or "ordinal". I'm not really familiar with RFC 7285, and in particular, whether a receiver is required to explicitly check that the received data must take one of these two values, or whether a reasonable implementation could check for a single value, and if doesn't match that value assume that it must be the other value (since there are only two allowed values). Obviously, moving to more than two values could then cause this assumption to break in existing implementations. [Qin Wu] The motivation of this short document is relax this constraint imposed by the base ALTO specification on allowed cost modes, see section 3 updated text to RFC7285 in draft-ietf-alto-cost-mode " 3.2. Updates to Section 10.5 of RFC7285 This document updates Section 10.5 of [RFC7285] as follows: OLD: A cost mode is encoded as a string. The string MUST have a value of either "numerical" or "ordinal". NEW: A cost mode is encoded as a string. The string MUST be no more than 32 characters, and it MUST NOT contain characters other than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen-minus ('-', U+002D), the colon (':', U+003A), or the low line ('_', U+005F). Cost modes reserved for Private Use are prefixed with "priv:" (Section 4). Otherwise, the cost mode MUST have a value that is listed in the registry created in Section 4 of RFCXXXX. " Was this issue considered and discussed by the WG? [Qin Wu] Yes, see path vector discussion during IESG review https://mailarchive.ietf.org/arch/msg/alto/fQQ8xWoQ8W700UIzY5fN16yFGb8/ https://mailarchive.ietf.org/arch/msg/alto/WWoyJyM0PioBWM_rADYT-Z_I8t4/ It looks like alto does support a versioning mechanism (i.e., by defining new media types) that might allow the definition of this field to be upgraded in a safer way. Was that approach considered? Regards, Rob _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
