Hello, Thanks for addressing the comments. The -19 version looks improved.
Some more reflections below. //Zahed On Tue, Nov 21, 2023 at 4:09 PM Kai GAO <[email protected]> wrote: > Hi Zaheduzzaman, > > We are sorry for the late reply -- the mail was blocked by the spam > detector. Please see our responses inline. > > Best, > Kai > > On Thu, Oct 26, 2023 at 6:56 PM Zaheduzzaman Sarker via Datatracker < > [email protected]> wrote: > >> Zaheduzzaman Sarker 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: >> ---------------------------------------------------------------------- >> >> Thanks for working on this specification. >> >> I have following points which I want to discuss further - >> >> - I understand this new transport is supposed to take advantages of >> HTTP/2 and >> HTTP/3 features and have backward compatibility with HTTP/1.x (x=1, >> likely). My >> take is, if I want to server ALTO server over HTTP2/ or HTTP/3 I would >> use this >> new transport. Now if I also want to also support HTTP1.x for whatever >> reasons >> then I have issue, should this new transport is sufficient to support all >> the >> HTTP versions up to HTTP/3? if yes, then why this does specification not >> update >> or even obsolete rfc8895? if the answer is NO, does that mean I need to >> implement both this specification and rfc8895 for HTTP1.1? This relation >> is not >> explicitly defined in this current draft, which it should. >> >> [KAI] Thanks for the comment. Yes, the new transport is sufficient to > support all HTTP > versions up to HTTP/3. The relationship between new transport and RFC8895 > is also > raised by the IoT telechat review by Wesley Eddy. Our understanding is > that new > transport is not a replacement of ALTO/SSE, and these two extensions can > be combined > (see the introduction of -18 for more complete discussions). > This looks better in -19 version. Thanks > > - I am not convinced that incremental update actually reduces storage at >> ALTO >> server, how is that so? I don't think there is an strict requirement that >> all >> the ALTO clients need to be updated to the recent version to be >> functional (as >> described in this specification), that means unless the serve is sure >> that all >> the clients are updated to certain version it has to keep the update >> versions. >> As storage reduction is a motivation for the transport requirement this >> motivation need to be well described to derive the requirement. >> > > [KAI] The "reduced storage" is compared to the case where the server > stores the contents > of each version. It is a motivation to use incremental updates (which > applies to RFC 8895 > as well) and we consider incremental updates as one motivation for the new > transport. > Does this make sense? > The draft still just mentions this as a statement. I think it would be better if it is clear that the comparison is done with the case where the server stores the contents of the each version. > > > >> - I didn't find any explanation of how the "Concurrent, non-blocking >> update >> transmission" requirement is meet by the new transport. is this solved by >> the >> use of HTTP/3 with uses QUIC and does not have HOL blocking within a >> connection? Or is this addressed by multiple concurrent HTTP connection >> to the >> ALTO server? This need to be understood better and we should define what >> actually "Concurrent, non-blocking update transmission" means in this >> context >> of fetching updates. >> >> > [KAI] The requirement basically requires that incremental updates can be > transmitted > at the same time (concurrent) and the transmission of one update will not > be blocked > by the transmission of another update. This can be realized by 1) multiple > HTTP > connections, or 2) HTTP/3 using multiple streams. This is compared with > RFC 8895 > where SSE multiplexes the updates in a single sequence. You make a good > point that > we should clarify how this can be done with new transport. We will add a > paragraph to > Sec 2.1 and upload a revision soon. > > >> - The encoding or data type of "updates graph (ug)" and "version" is not >> defined. The example uses numeric numbers which is easy to understand with >> incremental values. However, unless and otherwise this data type is >> defined >> then it is up to the implementers to select that and which will lead to >> interoperability issues. or may be I am missing something here, that is >> why I >> need to discuss the intention here. >> >> > [KAI] The data type of the version tag (the one held by the client) is a > string (JSONString) > but the "version" used to compute the URLs is a sequence number > (JSONNumber), both > specified in Sec 6.2. > do you mean "UpdatesGraphSummary" ? can we put the inline ref to the section where version datatype is defined to avoid confusion? > > >> - Here we are composing URIs from the ug , that tells me without proper >> encoding on ug defined there might be some internationalization issues >> (see >> rfc6365). Has there been any thoughts or discussions on this encoding and >> potential issues? >> >> > [KAI] Good point. According to RFC 7285 (the base ALTO protocol), the > contents > of the ALTO maps only allow ASCII characters. I think this document should > have > the same restrictions. > have you mentioned this in -19 version? if not then please write the restriction. //Zahed > > >> and I am also supporting Roman's discuss. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I think my other AD colleagues have already identified nits and typos. >> >> >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
