Re: [alto] Iotdir telechat review of draft-ietf-alto-new-transport-17

[[e-mail]]

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: [e-mail]
> Send time:Tuesday, 10/24/2023 13:40:02
> To: "Wesley Eddy" <[e-mail]>, "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> 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 <[e-mail]> De la part de Wesley Eddy via
> > Datatracker
> > Envoyé : lundi 23 octobre 2023 19:13
> > À : [e-mail]
> > Cc : [e-mail]; [e-mail]; last-
> > [e-mail]
> > 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
> > [e-mail]
> > 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.