Re: [alto] Benjamin Kaduk's No Objection on draft-ietf-alto-incr-update-sse-20: (with COMMENT)
Dear Ben, We have submitted a new version -22, and please see this link for the revisions that we have made from -20 to -22 https://www.ietf.org/rfcdiff?url1=draft-ietf-alto-incr-update-sse-20&url2=draft-ietf-alto-incr-update-sse-22 Thank you so much! Richard On Sun, Mar 15, 2020 at 10:36 PM Y. Richard Yang wrote: > Dear Ben, > > Thank you so much for the thorough, thoughtful review. Sorry for the late > reply---I did no > t get the initial email containing your review. Please see inline. > > On Wed, Mar 11, 2020 at 8:02 PM Benjamin Kaduk via Datatracker < > nore...@ietf.org> wrote: > >> >> Benjamin Kaduk has entered the following ballot position for >> draft-ietf-alto-incr-update-sse-20: No Objection >> >> 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/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/ >> >> -- >> COMMENT: >> -- >> >> Thanks for your response to the genart reviewer; I'm happy to see that >> change staged for the next version. >> >> > Thanks! > > >> It's a bit interesting to see that we present JSON merge patch and JSON >> patch in the reverse order in which they were defined (RFC 7396/7386 vs. >> 6902). >> >> > It is indeed interesting. The historical reason was that the early > versions defined > only JSON merge patch, and then added JSON patch later, motivated by the > need > to handle potential inefficiencies (see the end of Sec. 3.1.1 and the > beginning of > Sec. 3.2.1). Although in reverse chronological order, the flow and > transition appear > to be good so far, and let's keep the flow. OK? > > > >> It's very surprising to me that we replicate the algorithm for JSON >> merge patch and SSE but just refer to RFC 6902 for the JSON patch >> algorithm. >> > > Good catch on consistency. As we have removed the algorithm for the merge > patch, > they are treated equally now. > > >> What happens if either party closes the update stream without the proper >> clean-up message(s)? >> >> > Very good discussion. I see you may mean two cases: (C1) the overall > update stream; > and (C2) one of the substreams. The case of C1 is a special case of C2. > > If the server closes (e.g., due to an internal error) a substream without > sending > a control update of a substream, the client may receive a partial update > message. > Hence, it is important that the client uses a transaction based > implementation > to commit updates. > > If the client closes a substream, there can be two cases: (1) the client > uses stream > control, and the server is in the middle of sending a data update for the > substream; it is > recommended that the server finishes sending the data update, and the > client is > recommended to know that the close is effective only after getting the > notification > control update. (2) the client could just close the http connection (and > send FIN) > without properly sending the stop as in (1). In this case, the server TCP > connection > will be notified, and the server code should handle it. > > Is the above you are looking for? > > Section 1 >> >>considerations by both ALTO servers and clients; Section 13 discusses >>a design feature that is not supported; Section 10 discusses security >>issues; The last two sections review the requirements for future ALTO >>services to use SSE and IANA considerations, respectively. >> >> I think this last remark perhaps should not have survived a section >> reordering to put the not-supported design feature (section 13) last. >> > > Although I do not see that we make section-level changes (e.g., add > sections > at the end or reordering sections) at this point, self-updating reference > is > always a better idea. We will revise the last remark. Thanks for the > suggestion. > > >> Section 2 >> >>Stream Control Server: An stream control server providing the stream >>control service. >> >> Perhaps we could avoid defining a "stream control server" as a "stream >> control server" that does some things. >> > > Sounds good. We will remove the redundant structure of the definitions, > e.g., > Update Stream: An update stream is an HTTP connection ... > -> > Update Stream: An HTTP connection ... > > We will revise all definitions to be consistent in style. > > >> >>Control Update Message: A control update message is a message in an >>update stream for the update stream server to notify the ALTO client >>of related control information of the update stream. The first >>message of an update stream is a control update me
[alto] I-D Action: draft-ietf-alto-incr-update-sse-22.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application-Layer Traffic Optimization WG of the IETF. Title : ALTO Incremental Updates Using Server-Sent Events (SSE) Authors : Wendy Roome Y. Richard Yang Filename: draft-ietf-alto-incr-update-sse-22.txt Pages : 58 Date: 2020-03-20 Abstract: The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients, to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes; and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-22 https://datatracker.ietf.org/doc/html/draft-ietf-alto-incr-update-sse-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-incr-update-sse-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Draft agenda for IETF 107 virtual interim
Hello Vijay, Thank you for this information. So the target submission deadline would be April 7th . Thanks, Sabine From: Vijay Gurbani Sent: Friday, March 20, 2020 3:16 PM To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) Cc: IETF ALTO Subject: Re: [alto] Draft agenda for IETF 107 virtual interim Dear Sabine: I am no aware of any specific deadline, however, as always, please make sure that your draft has been submitted at least two weeks before our virtual meeting date to give the WG some time to look at it. Thanks, - vijay On Fri, Mar 20, 2020 at 6:19 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) mailto:sabine.randriam...@nokia-bell-labs.com>> wrote: Hi Vijay, Thanks a lot for the agenda. As the ID submission tool was re-opened pursuant to the F2F IETF107 cancellation, is there any new deadline to submit new versions for the drafts to be presented? Thanks, Sabine From: alto mailto:alto-boun...@ietf.org>> On Behalf Of Vijay Gurbani Sent: Thursday, March 19, 2020 5:37 PM To: IETF ALTO mailto:alto@ietf.org>> Subject: [alto] Draft agenda for IETF 107 virtual interim All: The draft agenda for the virtual interim is at https://datatracker.ietf.org/doc/agenda-interim-2020-alto-01-alto-01/ If anyone sent Jan and me an agenda request that is not reflected in the agenda, please let us know. Thanks, - vijay ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Draft agenda for IETF 107 virtual interim
Dear Sabine: I am no aware of any specific deadline, however, as always, please make sure that your draft has been submitted at least two weeks before our virtual meeting date to give the WG some time to look at it. Thanks, - vijay On Fri, Mar 20, 2020 at 6:19 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) wrote: > Hi Vijay, > > > > Thanks a lot for the agenda. As the ID submission tool was re-opened > pursuant to the F2F IETF107 cancellation, is there any new deadline to > submit new versions for the drafts to be presented? > > Thanks, > > Sabine > > > > > > *From:* alto *On Behalf Of *Vijay Gurbani > *Sent:* Thursday, March 19, 2020 5:37 PM > *To:* IETF ALTO > *Subject:* [alto] Draft agenda for IETF 107 virtual interim > > > > All: The draft agenda for the virtual interim is at > https://datatracker.ietf.org/doc/agenda-interim-2020-alto-01-alto-01/ > > > > If anyone sent Jan and me an agenda request that is not reflected in the > agenda, please let us know. > > > > Thanks, > > > > - vijay > ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Draft agenda for IETF 107 virtual interim
Hi Vijay, Thanks a lot for the agenda. As the ID submission tool was re-opened pursuant to the F2F IETF107 cancellation, is there any new deadline to submit new versions for the drafts to be presented? Thanks, Sabine From: alto On Behalf Of Vijay Gurbani Sent: Thursday, March 19, 2020 5:37 PM To: IETF ALTO Subject: [alto] Draft agenda for IETF 107 virtual interim All: The draft agenda for the virtual interim is at https://datatracker.ietf.org/doc/agenda-interim-2020-alto-01-alto-01/ If anyone sent Jan and me an agenda request that is not reflected in the agenda, please let us know. Thanks, - vijay ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
