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

["Eric Vyncke (evyncke)" <[e-mail]>]

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 <[e-mail]> on behalf of Adam Roach <[e-mail]>
Date: Wednesday, 16 October 2019 at 19:29
To: Leslie Daigle <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, The IESG <[e-mail]>
Subject: Re: Adam Roach's No Objection on charter-ietf-mops-00-01: (with COMMENT)

Thanks for the quick response! Replies inline.

On 10/16/19 10:02 AM, Leslie Daigle wrote:

Hi,

Thanks — some followup, in-line.

On 16 Oct 2019, at 2:54, Adam Roach via Datatracker wrote:

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?

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 think it

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/:
4/ Document operational requirements for media acquisition and delivery.

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.



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.

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.





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.

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