Re: [Mops] Adam Roach's No Objection on charter-ietf-mops-00-01: (with COMMENT)

"Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com> Wed, 16 October 2019 16:15 UTC

Return-Path: <Glenn.Deen@nbcuni.com>
X-Original-To: mops@ietfa.amsl.com
Delivered-To: mops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2054120A89; Wed, 16 Oct 2019 09:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mIDACRSyyAfb; Wed, 16 Oct 2019 09:15:06 -0700 (PDT)
Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (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 E177D120A4E; Wed, 16 Oct 2019 09:14:47 -0700 (PDT)
Received: from pps.filterd (m0047964.ppops.net [127.0.0.1]) by m0047964.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id x9GGDUL8046678; Wed, 16 Oct 2019 12:14:46 -0400
Received: from usushmgip001.mail.tfayd.com ([216.178.109.235]) by m0047964.ppops.net-00176a04. with ESMTP id 2vkae67ae9-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT); Wed, 16 Oct 2019 12:14:46 -0400
Received: from unknown (HELO potemwp00013.mail.tfayd.com) ([10.40.33.204]) by usushmgip001.mail.tfayd.com with ESMTP; 16 Oct 2019 09:14:44 -0700
Received: from potemwp00032.mail.tfayd.com (100.124.56.56) by potemwp00025.mail.tfayd.com (100.124.56.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 16 Oct 2019 10:14:43 -0600
Received: from potemwp00029.mail.tfayd.com (100.124.56.53) by potemwp00032.mail.tfayd.com (100.124.56.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Wed, 16 Oct 2019 10:14:42 -0600
Received: from potemwp00029.mail.tfayd.com ([100.124.56.53]) by potemwp00029.mail.tfayd.com ([100.124.56.53]) with mapi id 15.01.0669.032; Wed, 16 Oct 2019 10:14:42 -0600
From: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
To: Adam Roach <adam@nostrum.com>, The IESG <iesg@ietf.org>
CC: "mops-chairs@ietf.org" <mops-chairs@ietf.org>, "mops@ietf.org" <mops@ietf.org>, "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
Thread-Topic: [Mops] Adam Roach's No Objection on charter-ietf-mops-00-01: (with COMMENT)
Thread-Index: AQHVhDzRmrDtOGvT8EGSsDI8v3msKw==
Date: Wed, 16 Oct 2019 16:14:42 +0000
Message-ID: <0083643F-9EA2-489F-B04B-94635BB84453@nbcuni.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [100.126.25.31]
x-exclaimer-md-config: 47edc00f-f2d6-45ef-be83-8a353bd47e45
Content-Type: text/plain; charset="utf-8"
Content-ID: <27235CC3644F1743AC2CDAE85CBD68DF@NBCUNI.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-16_07:2019-10-16,2019-10-16 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 adultscore=0 bulkscore=0 impostorscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 phishscore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910160136
Archived-At: <https://mailarchive.ietf.org/arch/msg/mops/PiFf-nKtVw_-V8oIoOnmX2KcyB0>
Subject: Re: [Mops] Adam Roach's No Objection on charter-ietf-mops-00-01: (with COMMENT)
X-BeenThere: mops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Media OPerationS <mops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mops>, <mailto:mops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mops/>
List-Post: <mailto:mops@ietf.org>
List-Help: <mailto:mops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mops>, <mailto:mops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2019 16:15:12 -0000


On 10/15/19, 11:54 PM, "Mops on behalf of Adam Roach via Datatracker" <mops-bounces@ietf.org on behalf of noreply@ietf.org> wrote:

    Adam Roach has entered the following ballot position for
    charter-ietf-mops-00-01: No Objection
      
    
    The document, along with other ballot positions, can be found here:
    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/charter-ietf-mops/__;!c3kmrbLBmhXtig!7ny_KNcfzpti5LwqOjWBTgJRws7KfLKwMsLfBPr4yrOdD8lt9pXtCZI5speKe-wg$ 
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    I'm balloting "No Objection," but I have some pretty substantial
    comments that I'd like to see given serious consideration before
    we send the charter out for further review.
    
    > 2/ 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.
    
    I'd like to request some clarity about the anticipated output relics of those
    determinations.  Are these to be mailing list discussions exclusively? Will
    there be RFCs produced? If not, is there a plan to publish the conclusions in
    a more discoverable location than the MOPS mailing list?
   
    This same comment applies across bullet points 2 through 5, and I think it
    needs to be treated on a bullet-by-bullet basis. In particular, some of these
    enumerated goals (e.g., the first clause of item 3) sound like they intend to
    produce the kind of support documents discussed at
    <https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/support-documents/__;!c3kmrbLBmhXtig!7ny_KNcfzpti5LwqOjWBTgJRws7KfLKwMsLfBPr4yrOdD8lt9pXtCZI5sifwGOs2$ >.
    I'd like to make sure the charter is clear about whether this working group
    expects to request publication of such support documents as part of its
    chartered work.

[GD] Adding to Leslie's reply.  I also expect that we will see presentations at meeting and I-Ds about specific issues from contributors which will get it into the datatracker. So the information won't be left lingering just on the mailing list.

    
    > 4/ Document operational requirements for media acquisition and delivery.
    
    The term "acquisition" seems ambiguous here. A simple reading of this
    would imply the process whereby one acquires media from its canonical
    source (e.g., rights holders); but my previous experience with the
    discussions that led to this charter give me the impression that this likely
    has more to do with physical recording devices, like videocameras. The charter
    should be clear about which of these senses of "acquisition" is meant.

This is purely a Technical acquisition not involving rights in any way.  It's a term of art as they say.

In media there are 4 technical phases that everything gets divided into:  
   1. Acquisition  2. Edit, 3. Package 4. Distribution. 

Acquisition is the technical work needed to transport from capture device(s) to where It can be edited before packaging and distribution which is the work of sending either files or streams 
to viewers.  Basically the INPUT side of the Distribution OUTPUT.   An example is a camera phone capturing and live streaming something to periscope or FB live.

As MOPS is targeted at Media, I suggest that the term acquisition is contextually defined and correct.

    
    > 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.
    
    The use of the word "primary" here is a bit worrisome, as it carries with it
    an implication that MOPS may serve as a secondary custodian of them. I'm
    sure that's not what's intended. I worry that this phrasing could be used
    somewhere down the road in an attempt to defend the undertaking of work
    that really should be done in a more appropriate area. I would suggest a
    revision along the lines of:
    
    "Media operational and deployment issues with specific protocols or technologies
    (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP
    Protocols) remain the responsibility of the groups or areas responsible
    for those protocols or technologies."

I'm good with the proposed change.   
    
    > There must be a continuing 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.
    
    Some mention of the mechanics of how this continuing interest will be determined
    would be welcome.
    

-Glenn
    
    -- 
    Mops mailing list
    Mops@ietf.org
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mops__;!c3kmrbLBmhXtig!7ny_KNcfzpti5LwqOjWBTgJRws7KfLKwMsLfBPr4yrOdD8lt9pXtCZI5st61zCJ0$