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

[Adam Roach <[e-mail]>]

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