Hi Eric, I've edited the charter to reflect your concerns. On Thu, Aug 26, 2021 at 5:48 AM Qin Wu <[email protected]> wrote:
> Thanks Eric, see comments inline below. > -----邮件原件----- > >发件人: Éric Vyncke via Datatracker [mailto:[email protected]] > >发送时间: 2021年8月26日 14:06 > >收件人: The IESG <[email protected]> > >抄送: [email protected]; [email protected] > >主题: É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 [email protected] https://www.ietf.org/mailman/listinfo/alto
