A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol
draft-ietf-alto-cost-mode-05

# ART AD Review of draft-ietf-alto-cost-mode-03

cc @fpalombini

Thank you for the work on this document.

Many thanks to Jaime Jimenez for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/AdWmf0LOQ2JPGOZRQWVqTczvlwA/, and thanks to the authors for addressing his comment.

I only have one comment about the IANA section - I do not believe it rises as a DISCUSS, but I strongly think it should be addressed before publication.

Francesca

## Comments

### IANA considerations

Section 4:
>   This document requests IANA to create a new subregistry entitled
>   "ALTO Cost Modes" under the "Application-Layer Traffic Optimization
>   (ALTO) Protocol" registry available at [ALTO].

Please add a paragraph going over the different fields in the registry, listing them and providing a short description. 

In the definition for the "Identifier" field you should either repeat or point to the constraints defined in Section 3.2, including the fact that identifiers prefixed with "priv:" are reserved for Private Use (Section 4.1 of [RFC8126]) (which I believe is more precise than just saying "_Cost modes_ prefixed with "priv" are reserved ..." at the end of the section).


## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

Thanks for addressing my DISCUSS position.

A minor suggestion: In Section 5, include the table of initial values after you've defined the required fields.

Old DISCUSS:

Probably an easily answered issue, but I am not too familiar with ALTO.

     The string MUST be no more than 32 characters, and it MUST NOT contain characters other than [...]

Are there implementations that already deployed a cost string with more than 32 characters or characters not in this newly imposed set of characters? What should happen if that is in use? That is, is this protocol modification potentially breaking interoperability with older implementations?

[previously all values were numerical or ordinal, which would not exceed 32 chars, nor allow non-ascii digit characters, so this string restriction is orthogonal to old types and not a new restriction on old types. Also, generic error handling is defined on how to deal with strings that are too long or have wrong characters.]

While no fan of "patch RFCs", thank you for at least putting the OLD and NEW text in one document, so an implementer and reviewer doesn't have to switch between documents and get confused about what was read was the old doc or new doc.

That said, patching in the text "This document" feels a little weird. What RFC does "This document" then refer to?
Perhaps change "This document defines two cost modes" to "Two cost modes are defined".

     Future documents that define a new cost mode SHOULD indicate

I think that SHOULD can be a MUST. Although one could question the 2119 usage as it seems to be a directive to a document author and not a protocol action. So I would also be okay with lowercasing this.

Thank you to Stephen Farrell for the SECDIR review.

Section 4 specifies an assignment policy of “IETF Review.”  To double-check, you also do not want a designated expert too?

# GEN AD review of draft-ietf-alto-cost-mode-03

CC @larseggert

Thanks to Roni Even for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/xlaIzXHKY1NzjJRJpuXpzKwP4rc).

## Comments

### Section 1, paragraph 4
```
     Additional cost modes are required for specific ALTO deployment cases
     (e.g., [I-D.ietf-alto-path-vector]).  In order to allow for such use
     cases, this document relaxes the constraint imposed by the base ALTO
     specification on allowed cost modes (Section 3) and creates a new
     ALTO registry to track new cost modes (Section 4).
```
I second Rob's DISCUSS, i.e., it's not clear at all that current ALTO
implementations will handle this protocol parameter now taking on
values other than "numerical" or "ordinal" without explicit
negotiation.

I will let Rob hold the DISCUSS, but will monitor the discussion to
see if this issue will be addressed.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Thanks for adding text to accommodate my concerns.

Regards,
Rob