Subject: Re: [alto] Éric Vyncke's No Objection on charter-ietf-alto-04-01: (with COMMENT)

From: Qin Wu <[email-masked]>
Date: Thu, 26 Aug 2021 12:47:40 +0000

Thanks Eric, see comments inline below.
-----邮件原件-----
>发件人: Éric Vyncke via Datatracker [mailto:[email-masked]] 
>发送时间: 2021年8月26日 14:06
>收件人: The IESG <[email-masked]>
>抄送: [email-masked]; [email-masked]
>主题: É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.

---

From: Martin Duke <[email-masked]>
Date: Fri, 27 Aug 2021 12:51:48 -0700

Hi Eric, I've edited the charter to reflect your concerns.

On Thu, Aug 26, 2021 at 5:48 AM Qin Wu <[email-masked]> wrote:

> >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.)
>
>
>
> >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
>
> >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]: 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