Media OPerationS
charter-ietf-mops-01
Yes
(Suresh Krishnan)
No Objection
(Alissa Cooper)
(Deborah Brungard)
(Ignas Bagdonas)
(Magnus Westerlund)
Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
Éric Vyncke
Yes
Comment
(2019-10-01 for -00-00)
Not sent
This charter has been written by the MOPS BoF chairs + mailing list members. Warren & Éric have reviewed it.
Roman Danyliw
No Objection
Comment
(2019-10-16 for -00-01)
Sent
** I share the concerns that Adam Roach raised. ** I don't see it in the charter text, but the IESG also talking about MOPS having an implicit dispatch function. If this is the case, I recommend it being documented in the charter.
Alexey Melnikov Former IESG member
Yes
Yes
(2019-10-16 for -00-01)
Not sent
I am agreeing with Adam’s comments.
Barry Leiba Former IESG member
(was Block)
Yes
Yes
(2019-10-09 for -00-01)
Sent
Thanks for addressing my comments.
Suresh Krishnan Former IESG member
Yes
Yes
(for -00-01)
Not sent
Adam Roach Former IESG member
No Objection
No Objection
(2019-10-15 for -00-01)
Sent
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.
Alissa Cooper Former IESG member
No Objection
No Objection
(for -00-01)
Not sent
Alvaro Retana Former IESG member
No Objection
No Objection
(2019-10-16 for -00-01)
Sent
"Where new protocols are needed, MOPS will identify appropriate venues for their development." It doesn't seem to be this WGs call to decide where to do new work. As mentioned later in the charter, existing areas/groups already have responsibility in related spaces. It should then be up to the relevant WGs...ADs...the IESG...to determine where new work will take place (if at all). Given the next to last paragraph... ... Media operational and deployment issues with specific protocols or technologies... I think that the sentence above is not needed and may lead do confusion.
Benjamin Kaduk Former IESG member
(was Block)
No Objection
No Objection
(2019-10-10 for -00-01)
Sent
Thank you for addressing my blocking point!
Deborah Brungard Former IESG member
No Objection
No Objection
(for -00-01)
Not sent
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -00-01)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -00-01)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(2019-10-17 for -00-01)
Sent
I like the idea of having such type of WG. However, I find that publishing something like 4 or 5 RFCs is a lot (too much?) compared to the scope of the group. In comparison LAKE doesn't even plan on publishing (as an RFC) requirements for the technology it will develop.
Mirja Kühlewind Former IESG member
(was Block)
No Objection
No Objection
(2019-10-18 for -00-03)
Sent
Thanks for edits and discussion of my Block! ------- Old comment: I don't fully understand the goal of the milestones: documenting Streaming Video Alliance (SVA)/Motion Picture and Television Engineers (SMPTE) reliance on IETF protocols. The charter says: "Solicit regular updates from other media technology developing consortia/standards bodies working with IETF-developed protocols." This sounds like the group would use presentation time and the slides in the processing to get these updates and not necessarily write RFCs.