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

Hi Francesca,

We have uploaded a new revision (-18) of the document draft-ietf-alto-new-transport (https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/). Could you please take a look and see if the proposed changes address your DISCUSS points? Thanks!

Best,
Kai

> -----Original Messages-----
> From: kaigao@scu.edu.cn
> Send time:Thursday, 11/09/2023 13:25:56
> To: "Francesca Palombini" <francesca.palombini@ericsson.com>
> Cc: "The IESG" <iesg@ietf.org>, alto-chairs@ietf.org, draft-ietf-alto-new-transport@ietf.org, alto@ietf.org
> Subject: Re: [alto] Francesca Palombini's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS)
> 
> Hi Francesca,
> 
> Thanks for the review. Please see our responses to the "other points" below.
> 
> Best,
> Kai
> 
> 
> > -----Original Messages-----
> > From: "Francesca Palombini via Datatracker" <noreply@ietf.org>
> > Send time:Wednesday, 10/25/2023 14:29:19
> > To: "The IESG" <iesg@ietf.org>
> > Cc: alto-chairs@ietf.org, draft-ietf-alto-new-transport@ietf.org, alto@ietf.org
> > 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
> > alto@ietf.org
> > https://www.ietf.org/mailman/listinfo/alto