Re: [Tsv-art] Tsvart early review of draft-bichot-msync-08

[Guillaume Bichot <[e-mail]>]

Hi Eliot and all.

We do want to continue in the independent stream targeting the Informational RFC status.  We are working on the next version for addressing your recommendations. We plan to add a subsections for describing the multicast network and the assumptions/requirements related to it and in particular about resource provisioning and congestion control. Yes the multicast network is assumed to be a controlled network in the sense that the ISP owning that multicast network controls the QOS. MSYNC is the way to propagate an HTTP Adaptive Streaming session started on Internet over that controlled multicast network.

Note that multicast network service can be exposed to any CDN provider through a standard API  like the one defined by the IETF CDNi group allowing any content provider/or CDN provider to distribute their content exploiting the ISP's controlled multicast service.

Guillaume

-----Original Message-----
From: Independent Submissions Editor (Eliot Lear) <[e-mail]>
Sent: Monday, March 13, 2023 12:27 PM
To: Joerg Ott <[e-mail]>; Magnus Westerlund <[e-mail]>; Guillaume Bichot <[e-mail]>; Joerg Ott <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [Tsv-art] Tsvart early review of draft-bichot-msync-08

I understand.  What you should understand is that I have received favorable reviews for this work, and it may prove useful to a certain constituency (streaming content providers).  Sometimes early work is an appropriate use of the ISE.  The IETF needn't pick this up now.  You can wait and see whether demand for its use develops and then improve on it.  I do want to ensure that it is not going to harm the Internet, tho.

Eliot

On 13.03.23 10:55, Joerg Ott wrote:
> Hi Eliot,
>
> as I said in my review, this is a highly problematic document. Not
> sure if section 3 of RFC 5742 does offer a suitable option (since the
> draft in question does not _extend_ and IETF protocol but rather uses
> several, unless you would judge it extending HTTP in some way).
>
> The only choice would be option 5, which then would lead to IETF
> review.
>
> The issues is that this is IMHO a very early draft that requires
> substantial review investment to fix the many bits that are broken.
> We are not really at a stage that we are discussing a complete
> specification.  Where are these cycles supposed to come from?
> And why shoud they be invested for documenting a proprietary protocol
> as an RFC?
>
> Best,
> Jörg
>
> On 13.03.23 10:44, Independent Submissions Editor (Eliot Lear) wrote:
>> Hi Joerg,
>>
>> If Guillaume and the IETF would like to take this to the IETF, it is
>> a perfectly fine outcome, as far as I am concerned. Perhaps the
>> TSVAREA would like to discuss it?  Otherwise I am happy for it to
>> continue in the independent stream.  Please note that the fact that
>> it is in the independent stream does not imply that the ISE has made
>> a publication decision.  Also, like all others, this document must
>> undergo an RFC 5742 conflict review.
>>
>> Eliot
>>
>>
>> On 13.03.23 10:38, Joerg Ott wrote:
>>> Hi Eliot and Magnus,
>>>
>>> yes to all.
>>>
>>> If we start doing in-depth design review and improving the draft
>>> over time, then I am wondering if still remains an independent submission.
>>> Shouldn't this then rather see some form of WG process and review if
>>> we deem the approach to be worthwhile documeting for the IETF
>>> community?
>>>
>>> Where do we draw the line between (repeated) expert reviews (tsv-art
>>> or
>>> other) and broader community engagenent?  I certainly cannot claim I
>>> would be able to judge all aspects and implications.
>>>
>>> Best,
>>> Jörg
>>>
>>> On 13.03.23 10:33, Independent Submissions Editor (Eliot Lear) wrote:
>>>> Hi Magnus,
>>>>
>>>> On 13.03.23 10:15, Magnus Westerlund wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> To me it sounds like this document likely need some solutions to
>>>>> handle scenarios when the network is not providing what was
>>>>> expected, i.e. at least some type of circuit breaker
>>>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc8084%2F&data=05%7C01%7Cguillaume.bichot%40broadpeak.tv%7Cab25277ed83142e9473108db23b5d5a0%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C638143036107545279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V2nv5ZJVPfG6hBDVhPqdPCdUZNrtHKvBSg8W5z6O4r0%3D&reserved=0.
>>>>>
>>>> Yes, the fundamental issue here is that the applications using this
>>>> msync and their associated administrations may be entirely distinct
>>>> from those who need to put in place such circuit breakers,
>>>> especially if this traffic is traversing the Internet. So to your
>>>> point:
>>>>
>>>>> So I think a lot of care needs to be taken here.
>>>>>
>>>> Double yes.  The draft must go into some detail here.  An entire
>>>> section would not be inappropriate.
>>>>
>>>> Eliot
>>>>
>>>>
>>>> _______________________________________________
>>>> Tsv-art mailing list
>>>> [e-mail]
>>>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
>>>> ww.ietf.org%2Fmailman%2Flistinfo%2Ftsv-art&data=05%7C01%7Cguillaume
>>>> .bichot%40broadpeak.tv%7Cab25277ed83142e9473108db23b5d5a0%7C0ebe44e
>>>> ac9c9438da0407e699f358ed4%7C0%7C0%7C638143036107545279%7CUnknown%7C
>>>> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
>>>> XVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HFhvHTax5LHL8E79RIgaJshHUEauJnfjV
>>>> 16zN7jIbj8%3D&reserved=0
>>>
>
Broadpeak, S.A. Registered offices at 15 rue Claude Chappe, Zone des Champs Blancs, 35510 Cesson-Sévigné, France | Rennes
Trade Register: 524 473 063
This e-mail and its attachments contain confidential information from Broadpeak S.A. and/or its affiliates (Broadpeak), which is intended only for the person to whom it is addressed.
If you are not the intended recipient of this email, please notify immediately the sender by phone or email and delete it. Any use of the information contained herein in any way, including, but not limited to, total or partial disclosure, reproduction, or dissemination, by persons other than the intended recipient(s) is prohibited, unless expressly authorized by Broadpeak. Broadpeak, S.A. and its affiliates respect privacy laws, and is committed to the protection of personal data. Emails and/or attachments thereof exchanged between us may include your personal data which may be processed by Broadpeak and/or its affiliates according to applicable privacy laws & regulations.
In compliance with Regulation (EU) 2016/679 (GDPR) and applicable implementation in local legislations, you can exercise at any time your rights of access, rectification or erasure of your personal data, as well as your rights to restriction, portability or object to the processing.
For such purpose, or to know more about how Broadpeak processes your personal data, you may contact Broadpeak by email [e-mail].
Local authority : Commission Nationale Informatique et Libertés (CNIL): 3 Place de Fontenoy - TSA 80715 - 75334 PARIS CEDEX 07 or www.cnil.fr