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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 5 Sep 2019 11:34:26 +0000

[Adding the old GGIE mailing list as perhaps some GGIE members did not switch/join the MOPS mailing list]

As the potential Area Director supporting a potential MOPS Working Group, I must:

  1.  Thank Sanjay for his support (and comment)
  2.  Wonder whether other group members are still supporting this MOPS effort?

About 2) May be some members are not fully aware of IETF rules / processes, but, having only one reply for a charter review is not a good sign as it does not indicate a high level of support.

Can people interested in MOPS review the charter (see below) and approve it? or suggest changes ? Or disapprove completely ?

Please reply to all

Regards

-éric

From: Mops <[email-masked]> on behalf of "sanjay.mishra=[email-masked]" <sanjay.mishra=[email-masked]>
Date: Friday, 30 August 2019 at 16:14
To: Leslie Daigle <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Mops] [E] Updated proposed charter for a MOPS WG

Hi Leslie – The proposed charter looks good. I just have a comment RE need of clarity on the text “or networks are inadequate to meet these updated requirements”.

Otherwise, the charter seems consistent with the discussions during the BOF.

Thanks
Sanjay

From: Mops [mailto:[email-masked]] On Behalf Of Leslie Daigle
Sent: Friday, August 23, 2019 11:22 AM
To: [email-masked]
Subject: [E] [Mops] Updated proposed charter for a MOPS WG

Hi,

The two clear takeaways I had from the MOPS bof at IETF 105 were that there is interest in “this area of work” and that the proposed charter was not nearly crisp enough to agree on what the area of work was, or the specific things to be done.

As I said in the meeting, the challenge in trying to be crisp by narrowing the focus is that we actually need a rather broad “catchment” area, specifically pulling in things from several areas within the IETF and being open to input from other organizations. To achieve some level of sanity, I’ve attempted to make things clearer by being more specific about the work to be done. I’ve copied below an UPDATED proposed charter, that is aiming to be at least a little more concrete.

Action items:

1/ Please review the draft charter and provide feedback. (Yes, it looks like the sort of thing you would like to see chartered; suggestions for greater crispness, etc).

2/ Of particular importance, we need more work items in the Milestones. I told the ADs that I didn’t want to just write a bunch of things and then try to badger people into working on them (though I will if I have to :^) ). I’d rather have suggestions from interested parties about the things they are willing to work on in this area, or that they’d like to see done with a little help from others.

Okay — please comment.

Leslie.

—8<——8<——8<—

Media OPS WG

Internet- and Internet-protocol-delivered media is widespread, 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. MOPS’ focus is on identifying areas where existing protocols and/or networks are inadequate to meet these updated requirements.

[I would like to add that the issue is more than to meet these “updated” requirements. In fact, I see MOPS to focus specifically on how protocols coming out of the IETF “factory” when used in “real-world” may have implications across the service delivery food chain. Some of the implications may be by design or not as expected. MOPS will help bring operational issue whether it relates to delivery of service using a protocol that is efficient (or inefficient), or, is the network on which protocol is running supporting the protocol “as-is” or is there a need for network operators adjust the network, or is there an issue for UA conforming to delivery using a particular protocol.].

Not necessarily suggesting above commentary as a substitute text as it is not meant to be, but, a little more specificity will be helpful. I know, you do go into that part of specificity in the next paragraph but some up front clarity is useful.

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 networking. 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 premise of MOPS is that 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 acts as a clearinghouse to identify appropriate venues for further protocol development, where necessary.

MOPS goals include documenting existing protocol and operational issues with media on the Internet, and identifying requirements for potential IETF work.

To those ends, MOPS will:

1/ Solicit regular updates from other media technology developing consortia/standards bodies working with IETF-developed protocols.

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.

3/ Solicit discussion and documentation of the issues and opportunities in media acquisition and delivery, and of the resulting innovations developed outside the IETF

4/ Document operational requirements for media acquisition and delivery.

5/ Develop operational information to aid in operation of media technologies in the global Internet.

These activities should document media operational experience, including global Internet, inter-domain and within-domain operations.

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.

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.

Milestones

July 2020 Taxonomy of Issues in Internet Media

<more concrete, committed work items needed>

--

________________________________

Leslie Daigle
Principal, ThinkingCat Enterprises

[email-masked]<mailto:[email-masked]>

---

From: "Ali C. Begen" <[email-masked]>
Date: Thu, 5 Sep 2019 19:11:38 +0300

Hi Eric

I will bite first. I am fairly interested and willing to contribute to the MOPS (if it takes off). 

Having said that, I have a number of high-level comments on the scope and charter:

1) Soliciting input from other organizations: Is this supposed to be thru liaisons? We all know how slow that process is and usually takes several months before it can be sent/received due to different meeting cycles. Or do we expect people from all the relevant organizations to be on the MOPS list and communicate more quickly? The latter would be nicer, but most organizations do not liaise/communicate that way.

2) Input from network operators: Besides the well-known common problems, I don’t think we can expect any operator to report its operational excellence or operational failures. Or do we expect that?

3) Issues and opportunities in media acquisition and delivery. This came up in the meeting, though I don’t recall which aspects of media acquisition would be within the scope. Similarly, I don’t understand well enough to comment on 4/ and 5/ below (like operation of media technologies in the global Internet). What are the media technologies that are referred to here and what do we mean by their operation in the global Internet? Yes, most of the Internet traffic is video today, but most of that video is not going around the globe to be delivered, at least not in that amount. Replication/fanout is pretty close to the edge. To me, that part of the network is more challenging than the core.

I also agree that IETF protocols should be dealt with in their respective working groups. HTTP is popularly used to carry video, and that belongs to the HTTP working group but then maybe it would be a good idea to provide a guidelines document on how to use HTTP caching for video delivery in the MOPS WG. Input from CDN and SP folks would certainly be useful to collect and document, assuming they are willing to share their knowledge.

I have a few other comments, but I hope this will stir up some discussion.

-acbegen

> On Sep 5, 2019, at 2:34 PM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> 	• Thank Sanjay for his support (and comment)
> 	• Wonder whether other group members are still supporting this MOPS effort?
>  
> [email-masked]
> Mops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mops

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 5 Sep 2019 16:32:58 +0000

Hi,

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

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

Reasoning:

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,
IMO.

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:
https://datatracker.ietf.org/rg/iccrg/about/

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

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,
Jake

---

From: "Leslie Daigle" <[email-masked]>
Date: Thu, 05 Sep 2019 15:28:30 -0400

I want to provide a few answers, in-line, while I think Jake and Glenn 
are articulating some of the more pressing strategic issues to resolve.

On 5 Sep 2019, at 12:11, Ali C. Begen wrote:

> 1) Soliciting input from other organizations: Is this supposed to be 
> thru liaisons? We all know how slow that process is and usually takes 
> several months before it can be sent/received due to different meeting 
> cycles. Or do we expect people from all the relevant organizations to 
> be on the MOPS list and communicate more quickly? The latter would be 
> nicer, but most organizations do not liaise/communicate that way.

I was certainly not thinking of formal liaisons — recall, I was chair 
of the IAB for 5 years, and have a very clear notion of just how well 
those work.

And, yet, I agree that all other organizations are not going to join a 
WG mailing list so that they can share their individual views.

However, my thinking was twofold:

1/ Putting that in the charter makes it clearer where people from other 
organizations might find the relevant part of the IETF to come talk to.

2/ We can have informal updates from other organizations — and, we 
already have, between Sanjay’s contributions on work being done at 
SVA, and the SMPTE perspective that Glenn shared.

>
> 2) Input from network operators: Besides the well-known common 
> problems, I don’t think we can expect any operator to report its 
> operational excellence or operational failures. Or do we expect that?

Indeed, and I’m sure every involved operator has an excellent network. 
  However,  time passes, things change, and I’ve certainly heard 
operators express, in other contexts, things that would make their lives 
easier or harder wrt a given technology.

>
> 3) Issues and opportunities in media acquisition and delivery. This 
> came up in the meeting, though I don’t recall which aspects of media 
> acquisition would be within the scope. Similarly, I don’t understand 
> well enough to comment on 4/ and 5/ below (like operation of media 
> technologies in the global Internet). What are the media technologies 
> that are referred to here and what do we mean by their operation in 
> the global Internet? Yes, most of the Internet traffic is video today, 
> but most of that video is not going around the globe to be delivered, 
> at least not in that amount. Replication/fanout is pretty close to the 
> edge. To me, that part of the network is more challenging than the 
> core.

Perhaps because I happen to live in places with ISPs too small to have 
tight CDN attachments, I think it is too soon to give up on the 
possibility of functional video across the core.

>
> I also agree that IETF protocols should be dealt with in their 
> respective working groups. HTTP is popularly used to carry video, and 
> that belongs to the HTTP working group but then maybe it would be a 
> good idea to provide a guidelines document on how to use HTTP caching 
> for video delivery in the MOPS WG.

Sure.  And maybe coordination of more video-specific requirements could 
be done in MOPS to share with the HTTP wg.

> Input from CDN and SP folks would certainly be useful to collect and 
> document, assuming they are willing to share their knowledge.
>

Likewise — I’m mostly in listening mode.

Leslie.
>> About 2) May be some members are not fully aware of IETF rules / 
>> processes, but, having only one reply for a charter review is not a 
>> good sign as it does not indicate a high level of support.
>>
>> Can people interested in MOPS review the charter (see below) and 
>> approve it? or suggest changes ? Or disapprove completely ?
>>
>> Please reply to all
>>
>> Regards
>>
>> -éric
>>
>> From: Mops <[email-masked]> on behalf of 
>> "sanjay.mishra=[email-masked]" 
>> <sanjay.mishra=[email-masked]>
>> Hi Leslie – The proposed charter looks good. I just have a comment 
>> RE need of clarity on the text “or networks are inadequate to meet 
>> these updated requirements”.
>>
>> The two clear takeaways I had from the MOPS bof at IETF 105 were that 
>> there is interest in “this area of work” and that the proposed 
>> charter was not nearly crisp enough to agree on what the area of work 
>> was, or the specific things to be done.
>>
>> As I said in the meeting, the challenge in trying to be crisp by 
>> narrowing the focus is that we actually need a rather broad 
>> “catchment” area, specifically pulling in things from several 
>> areas within the IETF and being open to input from other 
>> organizations. To achieve some level of sanity, I’ve attempted to 
>> make things clearer by being more specific about the work to be done. 
>> I’ve copied below an UPDATED proposed charter, that is aiming to be 
>> at least a little more concrete.
>>
>> Action items:
>>
>> 1/ Please review the draft charter and provide feedback. (Yes, it 
>> looks like the sort of thing you would like to see chartered; 
>> suggestions for greater crispness, etc).
>>
>> 2/ Of particular importance, we need more work items in the 
>> Milestones. I told the ADs that I didn’t want to just write a bunch 
>> of things and then try to badger people into working on them (though 
>> I will if I have to :^) ). I’d rather have suggestions from 
>> interested parties about the things they are willing to work on in 
>> this area, or that they’d like to see done with a little help from 
>> others.
>>
>> Okay — please comment.
>>
>> Leslie.
>>
>> —8<——8<——8<—
>>
>> Media OPS WG
>>
>> Internet- and Internet-protocol-delivered media is widespread, 
>> 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. MOPS’ focus is on identifying areas where 
>> existing protocols and/or networks are inadequate to meet these 
>> updated requirements.
>>
>> [I would like to add that the issue is more than to meet these 
>> “updated” requirements. In fact, I see MOPS to focus specifically 
>> on how protocols coming out of the IETF “factory” when used in 
>> “real-world” may have implications across the service delivery 
>> food chain. Some of the implications may be by design or not as 
>> expected. MOPS will help bring operational issue whether it relates 
>> to delivery of service using a protocol that is efficient (or 
>> inefficient), or, is the network on which protocol is running 
>> supporting the protocol “as-is” or is there a need for network 
>> operators adjust the network, or is there an issue for UA conforming 
>> to delivery using a particular protocol.].
>>
>> Not necessarily suggesting above commentary as a substitute text as 
>> it is not meant to be, but, a little more specificity will be 
>> helpful. I know, you do go into that part of specificity in the next 
>> paragraph but some up front clarity is useful.
>>
>> 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 
>> networking. 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 premise of MOPS is that 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 acts as a clearinghouse to identify appropriate venues 
>> for further protocol development, where necessary.
>>
>> MOPS goals include documenting existing protocol and operational 
>> issues with media on the Internet, and identifying requirements for 
>> potential IETF work.
>>
>> 1/ Solicit regular updates from other media technology developing 
>> consortia/standards bodies working with IETF-developed protocols.
>>
>> 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.
>>
>> 3/ Solicit discussion and documentation of the issues and 
>> opportunities in media acquisition and delivery, and of the resulting 
>> innovations developed outside the IETF
>>
>> These activities should document media operational experience, 
>> including global Internet, inter-domain and within-domain operations.
>>
>> 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.
>>
>> 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.
>>
>> Milestones
>>
> _______________________________________________
> GGIE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ggie

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------