Thanks Eric, see comments inline below. -----邮件原件----- >发件人: Éric Vyncke via Datatracker [mailto:nore...@ietf.org] >发送时间: 2021年8月26日 14:06 >收件人: The IESG <i...@ietf.org> >抄送: alto-cha...@ietf.org; alto@ietf.org >主题: Éric Vyncke's No Objection on charter-ietf-alto-04-01: (with COMMENT)
>Éric Vyncke has entered the following ballot position for >charter-ietf-alto-04-01: 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.) >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/charter-ietf-alto/ ---------------------------------------------------------------------- >COMMENT: ---------------------------------------------------------------------- >While I still wonder whether there is a need for a ALTO 'extension' working >group, I do not object the rechartering. [Qin]: Yes, ALTO operational support doesn't require ALTO protocol extension, ALTO over HTTP3 needs to be investigated to see whether the protocol extension or just guidance is required? Even protocol extension is not needed, guidance on ALTO over HTTP2 or HTTP3 is still useful, e.g., how multiple stream carried in one connection can be leverage to support SSE. See section 4 of RFC8650 " 4. QoS Treatment Qos treatment for event streams is described in Section 2.3 of [RFC8639]. In addition, if HTTP/2 is used, the publisher MUST: * Take the "weighting" leaf node in [RFC8639] and copy it into the HTTP/2 stream weight, Section 5.3 of [RFC7540], and * Take any existing subscription "dependency", as specified by the "dependency" leaf node in [RFC8639], and use the HTTP/2 stream for the parent subscription as the HTTP/2 stream dependency (as described in Section 5.3.1 of [RFC7540]) of the dependent subscription. * Set the exclusive flag (Section 5.3.1 of [RFC7540]) to 0. For dynamic subscriptions with the same Differentiated Services Code Point (DSCP) value to a specific publisher, it is recommended that the subscriber sends all URI GET requests on a common HTTP/2 session (if HTTP/2 is used). Conversely, a subscriber cannot use a common HTTP/2 session for subscriptions with different DSCP values. " As an example, HTTP 1.1 and HTTP 2.0 actually introduce different QoS treatment. >Nevertheless I am puzzled by the apparent conflict of a YANG model milestone >and the sentence "This *may* include YANG models and OAM mechanisms"... [Qin]: Okay, will see how to fix it. >About the protocol extensions for H/2 and H/3, does it imply the use of >multistreaming ? [Qin]: I think some design guideline should be investigated, e.g., multiple stream multiplexing is one feature that can be leveraged to enhance SSE, maybe there are other design principles here, e.g., ALTO over HTTP over QUIC features I will ask ALTO proponents to chime in to comment on this. >One minor nit: please introduce OAM at first use. [Qin]: Thanks. _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
