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

[[e-mail]]

Hi Francesca, 

This is a nudge to check whether the revised spec addresses your concern.

For convenience, the changes made since your review can be tracked here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-alto-new-transport-17&url2=draft-ietf-alto-new-transport-21&difftype=--html

Thank you

Med (Doc Shepherd)

> -----Message d'origine-----
> De : alto <[e-mail]> De la part de [e-mail]
> Envoyé : mardi 21 novembre 2023 15:03
> À : Francesca Palombini <[e-mail]>
> Cc : The IESG <[e-mail]>; [e-mail]; draft-ietf-alto-
> [e-mail]; [e-mail]
> Objet : 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
> atracker.ietf.org%2Fdoc%2Fdraft-ietf-alto-new-
> transport%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ca6fed3153
> a1d4496d27808dbea9a9206%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
> 38361721829635090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1rD5yJ4Sy
> EzCVk6CLHwewSDuGSFdKoGpEq8dvOPBHfA%3D&reserved=0). Could you please
> take a look and see if the proposed changes address your DISCUSS
> points? Thanks!
> 
> 
> Best,
> Kai
> 
> 
> > -----Original Messages-----
> > From: [e-mail]
> > Send time:Thursday, 11/09/2023 13:25:56
> > To: "Francesca Palombini" <[e-mail]>
> > Cc: "The IESG" <[e-mail]>, [e-mail],
> > [e-mail], [e-mail]
> > 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" <[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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > > w.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-
> po
> > >
> sitions%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ca6fed3153
> > >
> a1d4496d27808dbea9a9206%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> > >
> C638361721829635090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> > >
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6yP
> > > G3wYNBNN%2FCZ0UZqfz%2BVxfmFxNsM0s%2FNsUbqcMEKE%3D&reserved=0
> > > for more information about how to handle DISCUSS and COMMENT
> positions.
> > >
> > >
> > > The document, along with other ballot positions, can be found
> here:
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> > > tatracker.ietf.org%2Fdoc%2Fdraft-ietf-alto-new-
> transport%2F&data=05%
> > >
> 7C01%7Cmohamed.boucadair%40orange.com%7Ca6fed3153a1d4496d27808dbea9a
> > >
> 9206%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638361721829635090
> > >
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> > >
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1rD5yJ4SyEzCVk6CLHwewS
> > > DuGSFdKoGpEq8dvOPBHfA%3D&reserved=0
> > >
> > >
> > >
> > > ------------------------------------------------------------------
> --
> > > --
> > > DISCUSS:
> > > ------------------------------------------------------------------
> --
> > > --
> > >
> > > Thank you for the work on this document.
> > >
> > > Many thanks to Spencer Dawkins for his ART ART reviews (most
> recent
> > > being
> > >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > > ilarchive.ietf.org%2Farch%2Fmsg%2Fart%2FLibZiksz5-nO-
> g8IyOJrrtczj94%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ca6fe
> d3153a1d4496d27808dbea9a9206%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C
> 0%7C638361721829635090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Bc
> DvTyEnqZuXm5yAh7s24y8DsVBdtSSF8cwKLXjf7Us%3D&reserved=0), and to
> Martin Thomson for his HTTPDir reviews (most recent being
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> archive.ietf.org%2Farch%2Fmsg%2Flast-call%2Fvz87ZLJVlbuVnSacxli8hvl-
> LTU%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ca6fed3153a1d449
> 6d27808dbea9a9206%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383617
> 21829635090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Z39wtmOLZHARsW6
> LLBTD8mAT1VHtRdzo7VES8ZFRxFk%3D&reserved=0).
> > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
> > > ilarchive.ietf.org%2Farch%2Fmsg%2Fmedia-types%2F1hOBaaTVCfl-
> M3uHmu2a
> > >
> 7Q5Ogzk%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7Ca6fed3153
> > >
> a1d4496d27808dbea9a9206%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7
> > >
> C638361721829635090%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> > >
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LA1
> > > Osjh84n0eKnTvv%2F01aj33UAHylTddEGgF%2BKwMs40%3D&reserved=0
> > > 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.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.