Re: [GGIE] [EXTERNAL] RE: MOPS - Media Ops BoF request

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Mon, 10 June 2019 01:01 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 7D892120043 for <ggie@ietfa.amsl.com>; Sun, 9 Jun 2019 18:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 eJbJeWiR-gvM for <ggie@ietfa.amsl.com>; Sun, 9 Jun 2019 18:01:41 -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 BDC97120047 for <ggie@ietf.org>; Sun, 9 Jun 2019 18:01:40 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6A280BE7D3C800CE54AE for <ggie@ietf.org>; Mon, 10 Jun 2019 02:01:38 +0100 (IST)
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 10 Jun 2019 02:01:38 +0100
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 10 Jun 2019 02:01:37 +0100
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml703-chm.china.huawei.com (10.201.108.52) 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; Mon, 10 Jun 2019 02:01:37 +0100
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.232]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0439.000; Mon, 10 Jun 2019 09:01:33 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
CC: "emile.stephan@orange.com" <emile.stephan@orange.com>, Leslie Daigle <ldaigle@thinkingcat.com>, "ggie@ietf.org" <ggie@ietf.org>
Thread-Topic: [EXTERNAL] RE: [GGIE] MOPS - Media Ops BoF request
Thread-Index: AQHVG7Gix3EcM8lWGEWwKx/aqdoChaaOPvpAgAALTMD//8GLgIAGDL+A
Date: Mon, 10 Jun 2019 01:01:33 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBBAF0AC3C5@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>, <51E6A56BD6A85142B9D172C87FC3ABBBAF0AAC26@DGGEML532-MBX.china.huawei.com> <F9DCE989-0CAD-4048-B1BF-BF14C03B7D8B@nbcuni.com>
In-Reply-To: <F9DCE989-0CAD-4048-B1BF-BF14C03B7D8B@nbcuni.com>
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: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBBAF0AC3C5DGGEML532MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ggie/c6did_hIAIUIqBKmeXJNX9oCB38>
Subject: Re: [GGIE] [EXTERNAL] RE: 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: Mon, 10 Jun 2019 01:01:45 -0000

Thanks, Glenn. Good to know that.

BR,
Rachel

From: Deen, Glenn (NBCUniversal) [mailto:Glenn.Deen@nbcuni.com]
Sent: Thursday, June 06, 2019 8:38 PM
To: Huangyihong (Rachel) <rachel.huang@huawei.com>
Cc: emile.stephan@orange.com; Leslie Daigle <ldaigle@thinkingcat.com>; ggie@ietf.org
Subject: Re: [EXTERNAL] RE: [GGIE] MOPS - Media Ops BoF request

Hi Rachel,

I believe it would be since professional video groups like SMPTE and it's SMPTE 2110 Suite of. Specs for Professional Media over Managed IP Networks is entirely dependent on IETF RFCs

https://www.smpte.org/st-2110

Glenn

On Jun 6, 2019, at 1:22 AM, Huangyihong (Rachel) <rachel.huang@huawei.com<mailto:rachel.huang@huawei.com>> wrote:
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<mailto:emile.stephan@orange.com>
Sent: Thursday, June 06, 2019 4:09 PM
To: Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com<mailto:Glenn.Deen@nbcuni.com>>; Leslie Daigle
<ldaigle@thinkingcat.com<mailto:ldaigle@thinkingcat.com>>
Cc: ggie@ietf.org<mailto: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<mailto: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<mailto:Glenn.Deen@nbcuni.com>>
Date: 2019-06-03 at 09:50
To: "ggie@ietf.org<mailto:ggie@ietf.org>" <ggie@ietf.org<mailto:ggie@ietf.org>>
Cc: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com<mailto: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<mailto: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<mailto:GGIE@ietf.org>
https://www.ietf.org/mailman/listinfo/ggie