Re: [GGIE] MOPS - Media Ops BoF request

["Huangyihong (Rachel)" <[e-mail]>]

Support and interested.

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

BR,
Rachel

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