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

[[e-mail]]

Hi Francesca,

Thanks for the review. Please see our responses to the "other points" below.

Best,
Kai


> -----Original Messages-----
> From: "Francesca Palombini via Datatracker" <[e-mail]>
> Send time:Wednesday, 10/25/2023 14:29:19
> To: "The IESG" <[e-mail]>
> Cc: [e-mail], [e-mail], [e-mail]
> Subject: [alto] Francesca Palombini's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS)
> 
> 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.

[KAI] Thanks for pointing this out. We change the media type of the response in 
section 7.4.2 to "application/merge-patch+json", updating the base object of type
AddTIPSResponse.

> 
> 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.

[KAI] The context of the sentence is not clear. We change the paragraph to the
following:

      A server MUST NOT use a URI for different TIPS views, either for
      different resources or different request bodies to the same
      resource.  URI generation is implementation specific, for example,
      one may compute a Universally Unique Identifier (UUID, [RFC4122])
      or a hash value based on the request, and append it to a base URL.
      For performance considerations, it is NOT RECOMMENDED to 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, which may result in duplicated TIPS views in cases such
      as mobile clients.  However, this is not mandatory as a server may
      intentionally use client information to compute the TIPS view URI
      to provide service isolation between clients.

> 
> > 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.

[KAI] The SHOULD here are changed to MUST, with the condition "if present" as 
"field" and "value" attributes are optional according to RFC 7285.

> 
> Section 7.2:
> 
> > Hence, the server processing logic SHOULD be:
> 

[KAI] Changed to MUST.

> 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.
> 

[KAI] This section is repeating Section 9.3 of RFC 8895 and is now removed from
this document.
> 
> 
> 
> 
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto