Hi Med and Wesley, Thanks for the comments! I already fix nits 1 & 3 and we will propose some new texts for Issue 1) and Nits 2) as soon as possible. Best, Kai > -----Original Messages----- > From: mohamed.boucadair@xxxxxxxxxx > Send time:Tuesday, 10/24/2023 13:40:02 > To: "Wesley Eddy" <wes@xxxxxxxxxxxxxxx>, "iot-directorate@xxxxxxxx" <iot-directorate@xxxxxxxx> > Cc: "alto@xxxxxxxx" <alto@xxxxxxxx>, "draft-ietf-alto-new-transport.all@xxxxxxxx" <draft-ietf-alto-new-transport.all@xxxxxxxx>, "last-call@xxxxxxxx" <last-call@xxxxxxxx> > Subject: RE: [alto] Iotdir telechat review of draft-ietf-alto-new-transport-17 > > Hi Wes, > > On your first point, the WG discussed that point and the conclusion was to not obsolete SSE: > https://datatracker.ietf.org/meeting/117/materials/slides-117-alto-alto-charter-items-issues-01 > > Re-reading the text in the draft, I do agree that your comment is fair and NEW text is needed to better clarify this. I trust the authors will take care of this. > > Thank you for tagging this. > > Cheers, > Med > (Doc Shepherd) > > > -----Message d'origine----- > > De : alto <alto-bounces@xxxxxxxx> De la part de Wesley Eddy via > > Datatracker > > Envoyé : lundi 23 octobre 2023 19:13 > > À : iot-directorate@xxxxxxxx > > Cc : alto@xxxxxxxx; draft-ietf-alto-new-transport.all@xxxxxxxx; last- > > call@xxxxxxxx > > Objet : [alto] Iotdir telechat review of draft-ietf-alto-new- > > transport-17 > > > > Reviewer: Wesley Eddy > > Review result: Ready with Issues > > > > I only found 1 real "issue" in reading this document, and a few > > smaller nits, described below. None of these comments are > > specifically related to IoTDIR type of concerns, and it doesn't seem > > like the protocol would be intended for use in IoT. > > > > Issues: > > > > 1) The placement of TIPS relative to other ALTO standards is unclear. > > This became evident to me on page 4, reading the bottom paragraph with > > "Despite the benefits, however, ...". Is the gist of this paragraph > > supposed to be that the WG does not think that TIPS should totally > > replace ALTO/SSE? It's not clear to me what the recommendation or > > applicability statement for these is in practical terms. The WG > > should convey more clearly what it believes implemenentations and > > deployments should be using, under what circumstances. If both > > protocols are maintained as standards track, then it should be clearly > > stated why that needs to be the case and that this does not obsolete > > ALTO/SSE. It seems to be created as another option, with unclear > > guidance provided to implementers about what to do. > > > > Nits: > > > > 1) page 4 > > from > > "no capability it transmits incremental" > > to > > "no capability to transmit incremental" > > > > 2) I don't know if this is typical for other ALTO documents, but the > > usage of the term "transport protocol" in the first paragraph of > > section 1 is not consistent with the Internet architecture where > > "transport protocols" are TCP, > > UDP, SCTP, etc., nor is it "transport" in the sense of MPLS, etc. I > > would > > suggest using the alternative term "transfer" to be less jarring. Of > > course, if this is already the standard terminology for ALTO that the > > IETF has accepted, then this comment can be ignored. > > > > 3) In the section 5.4 example, should "my-networkmap" in some of the > > "uses" > > values by "my-network-map" that was defined at the top? > > > > > > > > _______________________________________________ > > alto mailing list > > alto@xxxxxxxx > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > ietf.org%2Fmailman%2Flistinfo%2Falto&data=05%7C01%7Cmohamed.boucadair% > > 40orange.com%7C93e98812d3d24b3bfc3308dbd3eb5e71%7C90c7a20af34b40bfbc48 > > b9253b6f5d20%7C0%7C0%7C638336780069384460%7CUnknown%7CTWFpbGZsb3d8eyJW > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000% > > 7C%7C%7C&sdata=JrptPk%2B4cEymd%2B3eVM21n9Sn8kmxDApvsj%2Bx2%2FisuZ4%3D& > > reserved=0 > ____________________________________________________________________________________________________________ > 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
