[alto] Francesca Palombini's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS)

[Francesca Palombini via Datatracker <[e-mail]>]

Francesca Palombini has entered the following ballot position for
draft-ietf-alto-new-transport-17: 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-new-transport/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.

I have a couple of points I'd like to DISCUSS.

First of all, I have looked for media type reviews in the media-types mailing
list, and could not find the registration request posted. As specified by
RFC6838, it is strongly encouraged to post the media type registration to the
media-types mailing list for review (see
https://mailarchive.ietf.org/arch/msg/media-types/1hOBaaTVCfl-M3uHmu2a7Q5Ogzk/
for an example of a registration review). If I missed it, my apologies. If not,
please post to the media-types mailing list, and I will remove the discuss with
no objections raised in a week or so. Please make sure to copy-paste the full
sections 10.1 and 10.2 (not just a pointer to them) in your mail to media-types.

Talking about the media types, I was surprised to see that both media types are
used with two different formats. For example, application/alto-tips+json is
used both with a JSON object of type AddTIPSResponse (section 6.2) and a JSON
object of type UpdatesGraphSummary (section 7.4.2). I asked Murray to take a
look (as the expert on media types), so I will look out for his ballot there.

In several places (see below for what I identified as problematic SHOULDs) the
document lacks text about why these are SHOULD and not MUST or MAY. I agree
with John Klensin, who formulated it very clearly: If SHOULD is used, then it
must be accompanied by at least one of: (1) A general description of the
character of the exceptions and/or in what areas exceptions are likely to
arise.  Examples are fine but, except in plausible and rare cases, not
enumerated lists. (2) A statement about what should be done, or what the
considerations are, if the "SHOULD" requirement is not met. (3) A statement
about why it is not a MUST. I believe some context around these would be enough
to solve my concern, and give the reader enough context to make an informed
decision. If you believe the context is there, and I just missed it, please do
let me know.

Francesca

Section 6.2:

> A server SHOULD NOT use properties that are not included in the request body
to determine the URI of a TIPS view, such as cookies or the client's IP address.

> If the TIPS request does not have a "resource-id" field, the error code of
the error message MUST be E_MISSING_FIELD and the "field" field SHOULD be
"resource-id".

> The "field" field SHOULD be the full path of the "resource-id" field, and the
"value" field SHOULD be the invalid resource-id.

Section 7.2:

> Hence, the server processing logic SHOULD be:

Section 8.5:

> If the new value does not, whether there is an update depends on whether the
previous value satisfies the test. If it did not, the updates graph SHOULD NOT
have an update.