Re: [GGIE] MOPS - Media Ops BoF request

<emile.stephan@orange.com> Thu, 06 June 2019 08:09 UTC

Return-Path: <emile.stephan@orange.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 A3BEB12009E for <ggie@ietfa.amsl.com>; Thu, 6 Jun 2019 01:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 cX1M_oTSlldU for <ggie@ietfa.amsl.com>; Thu, 6 Jun 2019 01:09:05 -0700 (PDT)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDBC712001A for <ggie@ietf.org>; Thu, 6 Jun 2019 01:09:04 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 45KJG662p4z7w61; Thu, 6 Jun 2019 10:09:02 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 45KJG64xW6z3wbd; Thu, 6 Jun 2019 10:09:02 +0200 (CEST)
Received: from OPEXCAUBM44.corporate.adroot.infra.ftgroup ([fe80::e8a4:8bb:d7c2:f4e2]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([fe80::2c53:f99a:e2a9:19c6%21]) with mapi id 14.03.0439.000; Thu, 6 Jun 2019 10:08:58 +0200
From: emile.stephan@orange.com
To: "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/aqdoChaaOPvpA
Date: Thu, 06 Jun 2019 08:08:57 +0000
Message-ID: <14944_1559808542_5CF8CA1E_14944_230_1_dff2a204-54d5-4940-9ce0-3cb5232cdfa4@OPEXCAUBM7C.corporate.adroot.infra.ftgroup>
References: <71DC6F98-8F22-4783-8837-70DF84851F58@akamai.com>
In-Reply-To: <71DC6F98-8F22-4783-8837-70DF84851F58@akamai.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ggie/CibGlA2B0LxwLb1Dk6GTtGP3kHM>
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:09:08 -0000

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-zK6kEsS8_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.