The ALTO Transport Information Publication Service
draft-ietf-alto-new-transport-22

# Internet AD comments for draft-ietf-alto-new-transport-17
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S1

* "there is no capability it transmits" ->
  "there is no capability for the server to transmit", perhaps?

Thank you for the work on this document.

Many thanks to Spencer Dawkins for his ART ART reviews (most recent being https://mailarchive.ietf.org/arch/msg/art/LibZiksz5-nO-g8IyOJrrtczj94/), and to Martin Thomson for his HTTPDir reviews (most recent being https://mailarchive.ietf.org/arch/msg/last-call/vz87ZLJVlbuVnSacxli8hvl-LTU/). Spencer and Martin's expertise has helped improve the document considerably, so thanks to them, and to the authors for considering their reviews.

Thank you for addressing my previous DISCUSS.

I support Francesca and Roman’s DISCUSS positions.

Thanks to Spencer Dawkins for his two ARTART reviews.

The answer to question #11 in the shepherd writeup is incomplete.

I support Francesca's DISCUSS position.  To answer her question about media types, I must admit I'm at a loss to understand this object notation and how it relates to a JSON payload.  A reference to decoding it would be helpful.  My best guess is that this one media type will be used for both cases, the payload will be something in JSON format in either case, and a consumer infers the semantics of the payload based on inspection of its structure, presumably returning an error if something unexpected is found.  However, this seems peculiar in the context of media types; I would prefer to see such division done using a parameter to the media type rather than inspection, since the whole idea of labeling a payload with a media type is to know what it is you're holding before you start doing something with it.

The SHOULDs in 6.2 are bare.  When might one legitimately deviate from that advice?  If no such reason exists, why aren't they MUSTs?  Same question about the SHOULDs in 4.1 and 8.5.

Regarding Sections 10.1 and 10.2, I suggest reviewing RFC 8126 for what's expected in "Interoperability Considerations".

I support Roman's DISCUSS.

Thank you to Donald Eastlake for the SECDIR review.

Thanks for addressing my DISCUSS feedback.

** Section 6.2.  Editorial. New text was added clarifying text to prescribe that TIPS view URI must not be reused.  I would recommend being a clearer on this language.

OLD
      A server MUST NOT use a URI for different TIPS views, either for
      different resources or different request bodies to the same
      resource. 
NEW
A server MUST NOT use the same URI for different TIPS views, either for different resources or different request bodies to the same      resource. 


** Section 9.  
   The security considerations (Section 15 of [RFC7285]) of the base
   protocol fully apply to this extension.  For example, the same
   authenticity and integrity considerations (Section 15.1 of [RFC7285])
   still fully apply;

Since ALTO TIPS is a new protocol mechanism is it possible to improve on the TLS guidance in Section 8.3.5 of RFC7295 (from circa 2014)?  Specifically, can RFC9325 be mandated?

The -20 version addresses my discuss comments. Thanks for resolving those. No objection from my side on this -20 version.

Hi,

Thank you for this document.  I haven't reviewed this document that closely, and it might be interesting to know whether there are interoperable implementations of this specification, or where there may still be issues lurking, or more precise text to describe its behavior and APIs.  Hence, I was wondering whether it would be better from this document to be published as an experimental RFC rather than Proposed Standard, this would then leave a lot more flexibility for making more substantial changes to the protocol specification in future, if needed.

Regards,
Rob