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

From: Adam Roach via Datatracker <[email-masked]>
Date: Tue, 15 Oct 2019 23:54:04 -0700

Adam Roach has entered the following ballot position for
charter-ietf-mops-00-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-mops/

----------------------------------------------------------------------
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://www.ietf.org/about/groups/iesg/statements/support-documents/>.
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.

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

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

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

---

From: "Leslie Daigle" <[email-masked]>
Date: Wed, 16 Oct 2019 11:02:32 -0400

Hi,

Thanks — some followup, in-line.

> https://datatracker.ietf.org/doc/charter-ietf-mops/

That’s an interesting question, and I think there are, indeed, some 
implicit assumptions in this text.

Let me preface the rest of my answer with:  MOPS can’t be just about 
people talking among themselves.  So, the right question in every case 
is going to be:  if this is useful information, how can we make it 
available to (others) who need to know it, now or in the future.

For this particular point, my first thought is that there will be 
presentations at MOPS meetings, and thus there will be proceedings 
materials.  And, if there is particular interest in the items that are 
identified, the people presenting will either be vectored to the WG(s) 
that need to hear about the issues, or a WG document would seem like a 
logical follow up to flesh out any identified issues.

> This same comment applies across bullet points 2 through 5, and I 

Here is 3/:
3/ Solicit discussion and documentation of the issues and opportunities 
in
media acquisition and delivery, and of the resulting protocols and 
technologies
developed outside the IETF.

Same answer as for “2/“ — mailing list contribution -> meeting 
presentation (proceedings) -> redirect to other WG, or document more 
fully in I-D/RFC

And 4/:

Ditto

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

Ditto.

> expects to request publication of such support documents as part of 

I’m a little unclear why this has to be decided up front.  ISTM that 
some items will be more ephemeral than others, and saying either “we 
will never publish” (which could bury information useful to others) or 
“we will always request publication” (which could yield a lot of 
make-work) seems premature.

> should be clear about which of these senses of "acquisition" is meant.

It is the latter.  “Technical media acquisition”? “Non-legal media 
acquisition”?

> for those protocols or technologies."

That’s better, thanks.

> Some mention of the mechanics of how this continuing interest will be 

This was a paragraph Éric asked us to import from another WG’s 
charter, so I’d be happy to have his guidance on how that should be 
handled.

Leslie.

-- 

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

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Oct 2019 12:29:01 -0500

Thanks for the quick response! Replies inline.

On 10/16/19 10:02 AM, Leslie Daigle wrote:
> 3/ Solicit discussion and documentation of the issues and opportunities in

Okay; if the answer is the same, then this can probably be consolidated 
into one paragraph that discusses working group deliverables.

> make-work) seems premature.

The cited IESG statement itself talks about why this needs to be 
discussed up front:

> As regards to timing, it would be worthwhile to discuss the need to 
> publish support documents early during the charter development process 
> in order to set the right expectations and minimize surprises at a 
> late stage. Therefore, working group charters may direct the working 
> group to publish this content using alternate mechanisms, or may 
> instruct the working group to consider the appropriate mechanism as 
> work proceeds.

For working groups that aren't explicitly chartered to produce such 
"support documents," there have been a number of instances of strong 
push-back at IESG evaluation time against such documents, for the 
reasons cited elsewhere in that IESG statement. If it is the intention 
of this working group to publish such documents as RFCs, we should have 
the discussion about whether that is an appropriate outcome *now*, or 
you'll run into issues later, on a draft-by-draft basis, if and when you 
attempt to do so. It sounds like you intend to leave the door open to 
such publication (while not requiring it); in which case, the charter 
should explicitly state as much.

> It is the latter. “Technical media acquisition”? “Non-legal media 

Thanks to Glenn for his clarification about the clear meaning of this 
term in specific technical circles. I'm not objecting to the use of the 
term of art here; I'm suggesting that it have a layperson-level 
clarification appended to it. e.g.:

4/ Document operational requirements for media acquisition (for example, 
from cameras and recording devices) and delivery.

/a

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 17 Oct 2019 09:51:06 +0000

Adam

Let me chime in about the type of documents produced by the MOPS WG. And indeed the charter should be clear about the document publication.

My take is that MOPS will be quite similar to V6OPS where the _WG_ documents (i.e. the work items) will be published as RFC but other documents presented/discussed in MOPS may never be published as RFC: for example, deployment experiences. Those presented documents will only be ‘published’ as meeting materials.

-éric

From: iesg <[email-masked]> on behalf of Adam Roach <[email-masked]>
Date: Wednesday, 16 October 2019 at 19:29
To: Leslie Daigle <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>
Subject: Re: Adam Roach's No Objection on charter-ietf-mops-00-01: (with COMMENT)

Hi,

That’s an interesting question, and I think there are, indeed, some implicit assumptions in this text.

Let me preface the rest of my answer with: MOPS can’t be just about people talking among themselves. So, the right question in every case is going to be: if this is useful information, how can we make it available to (others) who need to know it, now or in the future.

For this particular point, my first thought is that there will be presentations at MOPS meetings, and thus there will be proceedings materials. And, if there is particular interest in the items that are identified, the people presenting will either be vectored to the WG(s) that need to hear about the issues, or a WG document would seem like a logical follow up to flesh out any identified issues.

Here is 3/:
3/ Solicit discussion and documentation of the issues and opportunities in
media acquisition and delivery, and of the resulting protocols and technologies
developed outside the IETF.

Same answer as for “2/“ — mailing list contribution -> meeting presentation (proceedings) -> redirect to other WG, or document more fully in I-D/RFC

And 4/:

Ditto

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

Ditto.

Okay; if the answer is the same, then this can probably be consolidated into one paragraph that discusses working group deliverables.

I’m a little unclear why this has to be decided up front. ISTM that some items will be more ephemeral than others, and saying either “we will never publish” (which could bury information useful to others) or “we will always request publication” (which could yield a lot of make-work) seems premature.

The cited IESG statement itself talks about why this needs to be discussed up front:
As regards to timing, it would be worthwhile to discuss the need to publish support documents early during the charter development process in order to set the right expectations and minimize surprises at a late stage. Therefore, working group charters may direct the working group to publish this content using alternate mechanisms, or may instruct the working group to consider the appropriate mechanism as work proceeds.

For working groups that aren't explicitly chartered to produce such "support documents," there have been a number of instances of strong push-back at IESG evaluation time against such documents, for the reasons cited elsewhere in that IESG statement. If it is the intention of this working group to publish such documents as RFCs, we should have the discussion about whether that is an appropriate outcome *now*, or you'll run into issues later, on a draft-by-draft basis, if and when you attempt to do so. It sounds like you intend to leave the door open to such publication (while not requiring it); in which case, the charter should explicitly state as much.

It is the latter. “Technical media acquisition”? “Non-legal media acquisition”?

Thanks to Glenn for his clarification about the clear meaning of this term in specific technical circles. I'm not objecting to the use of the term of art here; I'm suggesting that it have a layperson-level clarification appended to it. e.g.:

4/ Document operational requirements for media acquisition (for example, from cameras and recording devices) and delivery.

/a