Re: [GGIE] [Mops] [E] Updated proposed charter for a MOPS WG

"Holland, Jake" <> Thu, 05 September 2019 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E55A0120849; Thu, 5 Sep 2019 09:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tkyaz3DScT_v; Thu, 5 Sep 2019 09:33:11 -0700 (PDT)
Received: from ( [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 124311208AC; Thu, 5 Sep 2019 09:33:11 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x85GW5rH027565; Thu, 5 Sep 2019 17:33:00 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=NxknjFa6HeK4znEdDbzAbnff781gKGYnC4cGRP0HvLc=; b=Dg7zmi1kFQpguHiyT4U2D9xox46AkWS6hFyxMVSLDkjYzyDToz7Y630zX9lFKH12KrfJ qX0GFJ39EJeH63PBYXdbHa06GXzNoXNXwxz8TXXR+Cu1ZN560E0x3flH6FcaIKflONPx syI0dgJXQ0k863wiZGJbL6s9Z4Z4c4143v8R04SYk2KoDoLDin05h2bGsn4jNkukzZnv cXH4vOQnaFSVGEbT6DTJp50q87/XB2+0di8pyT84HYqBSjhj3HXKEHIV9BUaW7vCCL2j eh8MnQJ5qpdQ9kvFqsVeNSCZ1g3GQuYOS0cazsdCgFVrVPE5LwkHk1C12d69B9/tEJsb xg==
Received: from prod-mail-ppoint4 ( [] (may be forged)) by with ESMTP id 2uqghv09eq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Sep 2019 17:33:00 +0100
Received: from pps.filterd ( []) by ( with SMTP id x85GHpOp030172; Thu, 5 Sep 2019 12:32:59 -0400
Received: from ([]) by with ESMTP id 2uqm81dg6v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Sep 2019 12:32:59 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 5 Sep 2019 11:32:58 -0500
Received: from ([]) by ([]) with mapi id 15.00.1473.005; Thu, 5 Sep 2019 11:32:58 -0500
From: "Holland, Jake" <>
To: "Eric Vyncke (evyncke)" <>, "" <>, Leslie Daigle <>, "" <>
CC: "" <>, Warren Kumari <>
Thread-Topic: [Mops] [E] Updated proposed charter for a MOPS WG
Thread-Index: AQHVXzypAyofUn4bB0qLvd8aLaJzjqcdcp0A//+8iIA=
Date: Thu, 5 Sep 2019 16:32:58 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.1c.0.190812
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-05_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909050154
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-05_05:2019-09-04,2019-09-05 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 spamscore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 impostorscore=0 malwarescore=0 phishscore=0 suspectscore=0 adultscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909050157
Archived-At: <>
Subject: Re: [GGIE] [Mops] [E] Updated proposed charter for a MOPS WG
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, 05 Sep 2019 16:33:13 -0000


Sorry for the slow response, I've got several things going on, and my
response is complicated.  But I do still care, and I do still support
normalizing this group.

(Also: sorry for not figuring this all out and making the case better
back in February, but my current position was influenced by new
information from feedback during 105.)

I think we should revisit the idea of making mops a research group
instead of a working group.


Some of the feedback I got for draft-jholland-mops-taxonomy seemed to
indicate some consensus that it's not worth forming a working group to
produce documents like that one.

And they might be right.  I think there's a serious value in these
meetings, but I'm not sure the main value is from producing the
currently proposed work item, or other things like it.

Rather, it's about getting focus on media delivery from a wide range
of internet experts, from all the performance- and scale-relevant
angles (even where we don't know what they are yet).

If we think of the case study of "how would GGIE have played out in
a world where mops had already existed", I think documenting and
it as an experimental protocol along with performance measurements
would be in-scope for a RG about media delivery, but probably not for
an ops WG as proposed here.

To me, that seems like an indication that the WG approach is a mistake.

Crazy stuff like GGIE--which might work but it's weird, and people
need a venue to argue over the details and make a cogent case for why
IPv6 is/isn't an appropriate mapping substrate and suggest what would
work better--is exactly the kind of thing that mops should be enabling,

And the goal for a proposal like GGIE should be about turning it into
a protocol with enough people convinced it's a good idea to spin it
off into a WG to focus on that specifically, or to kill it if its
core value rests on a fundamentally bad idea (which I don't think was
true for ggie and I'm sad to see it apparently dead, though I do think
it had some nasty issues--but the point is those issues might be
fixable if there had been a good venue to refine it).

Allowing for that kind of flexibility in the charter is a feature, not
a bug.  But it's a point against chartering as a WG as opposed to an RG.

What I really want is:

- to keep meeting, but with more people and to be on the IETF agenda
- for the meetings to be recorded
- any time someone has a new network-related scheme that's supposed to
  help media delivery, they're presenting at this meeting.
- any time someone has a new kind of problem with media delivery, they're
  presenting at this meeting.
- there's a reasonable effort to avoid conflicts on wherever else they're
  presenting, if anywhere.
(+ nice-to-have: the note-well, for better clarity about IPR)

I think WG vs. RG is irrelevant to that wish list.

AFAICT, WG is only necessary if we have BCPs or standard to propose that
need interop, right?  Are there any such?  (Would GGIE have necessarily
died if it went through a phase as Experimental through the IRTF first?)

Also: an RG could equally well publish the taxonomy document, as they can
make Informational and Experimental RFCs.

So as a "strategic direction"-level comment on the charter text, maybe
a better model to copy the charter from is iccrg, which has a similarly
loose and wide-ranging but important mission that likewise can't be
easily untangled from lots of other topics.  So they just state that
and run with it:

Minor comments (on the current charter text):
- I'm not clear what "technologies of control protocols" means in the
2nd paragraph.  When I try to guess what it might mean, I'm not sure
they should be excluded from the scope, where they have a bearing on the
performance dynamics for media delivery.
- I'm not clear what "media acquisition" is in items 3 and 4
- I like points #1 and 2, and think they should appear in the charter
even if we go the RG direction.  But I think point #2 should probably
be split into 2 points (one for identify operational issues, and another
for solutions), and should use "propose" instead of "determine" for the

Thanks for all your work on this Leslie, and I hope this group can find
a regular home at IETF meetings, because I think it's extremely valuable
to be meeting there.

Best regards,