Re: [GGIE] MOPS - Media Ops BoF request

"Huangyihong (Rachel)" <> Thu, 06 June 2019 08:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EA3012015A for <>; Thu, 6 Jun 2019 01:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wgei8OM-bLZv for <>; Thu, 6 Jun 2019 01:22:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3141312004F for <>; Thu, 6 Jun 2019 01:22:51 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 7DC0531DF02B9FDE052C for <>; Thu, 6 Jun 2019 09:22:48 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 6 Jun 2019 09:22:48 +0100
Received: from ( by ( 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 ( by ( 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 ([]) by ([]) with mapi id 14.03.0439.000; Thu, 6 Jun 2019 16:22:44 +0800
From: "Huangyihong (Rachel)" <>
To: "" <>, "Deen, Glenn (NBCUniversal)" <>, Leslie Daigle <>
CC: "" <>
Thread-Topic: [GGIE] MOPS - Media Ops BoF request
Thread-Index: AQHVG7Gix3EcM8lWGEWwKx/aqdoChaaOPvpAgAALTMA=
Date: Thu, 6 Jun 2019 08:22:43 +0000
Message-ID: <>
References: <> <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-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [GGIE] MOPS - Media Ops BoF request
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discuss IETF-related items for Glass to Glass Internet Ecosystem of Video Content <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?


> -----Original Message-----
> From: GGIE [] On Behalf Of
> Sent: Thursday, June 06, 2019 4:09 PM
> To: Deen, Glenn (NBCUniversal) <>;; Leslie Daigle
> <>;
> Cc:
> 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 [] De la part de Holland, Jake Envoyé :
> mercredi 5 juin 2019 17:16 À : Deen, Glenn (NBCUniversal);
> 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)" <>;
> Date: 2019-06-03 at 09:50
> To: ""; <>;
> Cc: "Deen, Glenn (NBCUniversal)" <>;
> 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
> 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
> ________________________________________________________________
> _________________________________________________________
> 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