Re: [GGIE] MOPS - Media Ops BoF request

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Thu, 06 June 2019 08:22 UTC

Return-Path: <rachel.huang@huawei.com>
X-Original-To: ggie@ietfa.amsl.com
Delivered-To: ggie@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA3012015A for <ggie@ietfa.amsl.com>; Thu, 6 Jun 2019 01:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgei8OM-bLZv for <ggie@ietfa.amsl.com>; Thu, 6 Jun 2019 01:22:51 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3141312004F for <ggie@ietf.org>; Thu, 6 Jun 2019 01:22:51 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7DC0531DF02B9FDE052C for <ggie@ietf.org>; Thu, 6 Jun 2019 09:22:48 +0100 (IST)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 6 Jun 2019 09:22:48 +0100
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 6 Jun 2019 09:22:48 +0100
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Thu, 6 Jun 2019 09:22:47 +0100
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.232]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0439.000; Thu, 6 Jun 2019 16:22:44 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: "emile.stephan@orange.com" <emile.stephan@orange.com>, "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>, Leslie Daigle <ldaigle@thinkingcat.com>
CC: "ggie@ietf.org" <ggie@ietf.org>
Thread-Topic: [GGIE] MOPS - Media Ops BoF request
Thread-Index: AQHVG7Gix3EcM8lWGEWwKx/aqdoChaaOPvpAgAALTMA=
Date: Thu, 6 Jun 2019 08:22:43 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBBAF0AAC26@DGGEML532-MBX.china.huawei.com>
References: <71DC6F98-8F22-4783-8837-70DF84851F58@akamai.com> <14944_1559808542_5CF8CA1E_14944_230_1_dff2a204-54d5-4940-9ce0-3cb5232cdfa4@OPEXCAUBM7C.corporate.adroot.infra.ftgroup>
In-Reply-To: <14944_1559808542_5CF8CA1E_14944_230_1_dff2a204-54d5-4940-9ce0-3cb5232cdfa4@OPEXCAUBM7C.corporate.adroot.infra.ftgroup>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.153.152]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ggie/E_DkvCNTmqTDRInYtzLdqeBPw9I>
Subject: Re: [GGIE] MOPS - Media Ops BoF request
X-BeenThere: ggie@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discuss IETF-related items for Glass to Glass Internet Ecosystem of Video Content <ggie.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ggie>, <mailto:ggie-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ggie/>
List-Post: <mailto:ggie@ietf.org>
List-Help: <mailto:ggie-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ggie>, <mailto:ggie-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2019 08:22:54 -0000

Support and interested.

I'm wondering whether studio video transport is also in the scope?

BR,
Rachel

> -----Original Message-----
> From: GGIE [mailto:ggie-bounces@ietf.org] On Behalf Of
> emile.stephan@orange.com
> Sent: Thursday, June 06, 2019 4:09 PM
> To: Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com>;; Leslie Daigle
> <ldaigle@thinkingcat.com>;
> Cc: ggie@ietf.org
> Subject: Re: [GGIE] MOPS - Media Ops BoF request
> 
> Hi Glenn and Leslie
> 
> I support the BoF.
> It may decide if more interop is needed on the ingest side. AFAIK, it is not in the
> CDNi WG charter yet.
> Wrt to the delivery, IMO, more interactions with the network is required (e.g.
> at least to allow back pressure during peak of traffic).
> 
> Regards
> Emile
> 
> -----Message d'origine-----
> De : GGIE [mailto:ggie-bounces@ietf.org] De la part de Holland, Jake Envoyé :
> mercredi 5 juin 2019 17:16 À : Deen, Glenn (NBCUniversal); ggie@ietf.org
> Objet : Re: [GGIE] MOPS - Media Ops BoF request
> 
> Hi Glenn,
> 
> Thanks for posting this.  The charter mostly looks good to me, I have a few
> comments inline with [JH] (text pasted from the google docs link).
> 
> Cheers,
> Jake
> 
> 
> Media OPS WG
> 
> Internet- and Internet-protocol-delivered video/media is popular, leading to
> significant technology development across industries not traditionally thought
> of as Internet technology developers or operators, as well as considerable
> quantities of traffic on local and transit networks.  Continued development of
> Internet-using technologies should be properly coordinated in order to ensure
> that the existing technologies are well-utilized, and new ones are developed in
> sympathy with the Internet’s core protocols and design.
> 
> MOPS will solicit input on operational issues and practices, existing and
> proposed technologies related to the deployment, engineering, and operation
> of media streaming and manipulation protocols and procedures in the global
> Internet, inter-domain and single domain.  In this case, media is considered to
> include the transport of video, audio, objects and any combination thereof,
> possibly non-sequentially.  The scope is media and media protocols’
> interactions with the network, but not the technologies of control protocols or
> media formats.
> 
> The goals of mops are:
> 1. Solicit input from network operators and users to identify
>    operational issues with media delivery in and across networks, and
>    determine solutions or workarounds to those issues.
> 
> 2. Solicit discussion and documentation of the issues and opportunities
>    media acquisition and delivery and of the resulting innovations.
> 
> [JH] I'm confused on this one.  I think at very least it's missing "in"
>      between "opportunities" and "media".  But there might be a better
>      way to phrase this overall, I'll propose one if I think of a
>      suggestion.
> [JH] I think "media acquisition" needs a definition.  Web search of
>      this term seems to refer to obtaining intellectual property
>      rights for particular properties; I'm not quite sure what the
>      intent is here, but I suspect not that.
> 
> 3. Operational solutions for identified issues should be developed in
>    mops and documented in informational or BCP drafts.
> 
> 4. Document operational requirements for media acquisition and delivery
> 
> 5. Develop mechanisms and procedures for sharing operational information
>    to aid in operation of media technologies in the global Internet
> 
> 6. Develop tools, extend protocols and provide operational and
>    implementation advice that assists in media technology administration,
>    diagnostics, troubleshooting and deployment between/within native and
>    non-native environments.
> 
> These documents should document media operational experience, including
> global Internet, inter-domain and within-domain operations.
> [JH] Maybe "should address" or "should cover", instead of "these documents
>      should document"?
> 
> Media operational and deployment issues with specific protocols or
> technologies (such as Applications, Transport Protocols, Routing Protocols, DNS
> or Sub-IP Protocols) are the primary responsibility of the groups or areas
> responsible for those protocols or technologies.
> However, the mops Working Group may provide input to those areas/groups,
> as needed, and cooperate with those areas/groups in reviewing solutions to
> mops operational and deployment problems.
> [JH] Should we use something strong than "may" here?  "should"?  "is
>      expected to"?
> 
> Future work items within this scope will be adopted by the Working Group only
> if there is a substantial expression of interest from the community and if the
> work clearly does not fit elsewhere in the IETF.
> 
> There must be a continuous expression of interest for the Working Group to
> work on a particular work item. If there is no longer sufficient interest in the
> Working Group in a work item, the item may be removed from the list of
> Working Group items.
> 
> [JH] I thought there's a similar expectation already for WGs in general,
>      is there a sense which this WG needs special handling?
> [JH] Should there be a provision for criteria that would justify closing
>      the WG?  (If sufficient consideration of media delivery concerns
>      becomes routine in protocol specs, or if interest or attendance
>      drops below some threshold?)  Not sure what's normal for ops
>      groups, but some of the RFC 2418 text seems to suggest the normal
>      WG goal is about defining protocols, and like other ops groups,
>      this is a little different.
> 
> 
> 
> From: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>;
> Date: 2019-06-03 at 09:50
> To: "ggie@ietf.org"; <ggie@ietf.org>;
> Cc: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>;
> Subject: [GGIE] MOPS - Media Ops BoF request
> 
> Hi everyone,
> 
> IETF105 BoF requests are due this Friday, so now would be good time to send
> your comments on the MOPS BoF draft
> 
> https://docs.google.com/document/d/1S4soR8QVjbCa1k1CXS8bCXox_h8-zK6k
> EsS8_IU4yXI/
> 
> The current draft is an amalgam of the discussions we had at IETF104 and
> feedback from a few ADs, but the more the better so please don’t be shy.
> 
> This is a chance to bring forward, officially the topic of creating an group with
> video expertise at the IETF that can help video problems across the great
> diversity of technical areas that are the IETF.  So I encourage you to please
> take a couple of minutes when you get this email, look at the draft and
> comment back the list your thoughts.
> 
> Even – “it looks good to me”  – is helpful to hear.
> 
> regards
> Glenn
> 
> 
> 
> _______________________________________________
> GGIE mailing list
> GGIE@ietf.org
> https://www.ietf.org/mailman/listinfo/ggie
> 
> ________________________________________________________________
> _________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this
> message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> 
> _______________________________________________
> GGIE mailing list
> GGIE@ietf.org
> https://www.ietf.org/mailman/listinfo/ggie