[Wish] WISH Charter Ballot Comments

[Adam Roach <[e-mail]>]

Dear IESG:

Thanks for the careful consideration of the WISH charter! I understand 
that it has been approved for public comment. Looking at the ballot, 
there are a handful of comments that appear to need responses. I have 
left off editorial comments and those pertaining to the (now added) 
milestone. I have copied the WISH mailing list for the information of 
interested parties.


Alvaro Retana No Objection Comment (2021-01-20):

> I don't object to this work, but the list of companies and tools made 
> me wonder about whether people associated with them will be engaged in 
> this work.  Are they?  A quick look at the wish archive doesn't show 
> much, but the discussion has probably been carried out elsewhere.


For the most part, we've been holding off doing the core discussion of 
issues until after charter approval, so as to ensure that the broadest 
set of folks are involved in that conversation. The proponents of this 
work have a rough notion of some areas that need greater focus, and I 
expect to be sending a list of open issues to the working group mailing 
list as soon as the group is approved.

In terms of the expected participants, we have strong interest and 
commitment from Millicast and Caffeine, as well as provisional but 
strong interest from three other major entities in this technology space 
(one broadcasting tool, two realtime CDNs) who I don't feel at liberty 
to name, as they haven't been public about their interest *yet*. I would 
also expect the Janus/Meetecho folks to be keenly interested and 
participate, although I haven't yet touched base with them.


> In either case, I think it would be a good idea for the charter to 
> only generically talk about the interest in this type of work and not 
> explicitly mention companies/tools.


There's a tricky balancing act here. I would expect that most consumers 
of this charter -- that is, typical IETF participants -- will not be 
familiar with the general notion of what broadcaster studio software is 
and how it fits into the ecosystem. The two options here would be either 
including a very long description of how these networks work and the 
role of broadcasting tools in them; or, alternately, to cite the 
specific tools and network to allow folks to explore them and gain an 
understanding of their functionality first-hand.



Éric Vyncke No Objection Comment (2021-01-21):

> Like Alvaro, I would prefer to drop the commercial company names as 
> they bring little to the discussion.
>
> Could the background be more concise ?


Not if we drop company names -- it'll have to get longer. :)

Again, the challenge here is that we're talking about technology that I 
don't believe many IETF participants are all that familiar with, and I 
think having some kind of introduction to the space is important if 
they're going to understand what the work is about and participate in it 
productively. If you want to suggest specific edits that preserve that 
property and yet make it shorter, that would be great.


>
> Will the 'product' of this WG be a single document that is a 
> specification  as indicated by "The product of this working group will 
> be a specification" ?


Yes.


> If so, could the work be done in another WG ?


The discussion in DISPATCH pointed proponents to the creation of a small 
working group over the other potential options of AD sponsorship or 
routing to an existing working group. For deep detail, I encourage you 
to listen starting here for the conversation: 
<https://youtu.be/d871MoUgAKU?t=4325>. If you'd prefer an executive 
summary, the DISPATCH chair conclusion in the minutes 
<https://datatracker.ietf.org/doc/minutes-109-dispatch/> is:

Think this work needs to be done.  Discussion of a charter for a small working group.


> We will also need to ensure that this WG is exposed to MOPS WG and 
> vice-versa.


Yes, MOPS should be looped in, and the second-to-last paragraph should 
be amended to include them. Good catch!



Magnus Westerlund No Objection Comment (2021-01-21):

> I am on the verge of a block here.


Hi, Magnus! I'm glad we're getting your input.


> So the goal is to establish a one-way media over an WebRTC peer 
> connection between a media producer and a consumer. 


Yes, and it's more narrowly scoped than that. It's one-way media using 
WebRTC for broadcasting tools. The general problem of establishing 
one-way media for all potential WebRTC use cases is orders of magnitude 
more complex, and would involve much more general handling of things 
like device capabilities, arbitrary authentication models, 
considerations of allocating and deallocating HTTP endpoints, and a host 
of additional complications.

Without scoping to a specific use case, this protocol runs the risk of 
becoming as complex as SIP, which took several hundred people half a 
decade to develop and refine. This is why the charter is careful, in its 
opening sentence, to narrow the scope to the use case where we're 
actually seeing an acute need and participant interest. If you think 
this needs to be made clearer or repeated elsewhere in the charter, I'd 
welcome proposed text that aims to avoid this confusion.


> What isn't clear in this work is who is the intended initiator to this 
> communication. After having looked in draft-imurillo-whip it appears 
> the intention is for the media producer (or its controller) to 
> initiate the HTTP connection to a consumer (or its controller). Where 
> the necessary configuration is established.


Right, although it's less confusing if you view these roles more 
specifically, as is intended by this proposal. The question of which 
entity -- a broadcasting tool or a realtime CDN ingest gateway -- 
initiates a broadcast session is pretty straightforward when the 
real-world use cases are considered. Ingest gateways will definitionally 
be network servers that can be easily discovered via normal HTTP 
resolution techniques. Broadcast tools will (with extremely rare 
exception) be scattered around the network on dynamic addresses, 
frequently behind NATs, and unable to contribute media to a CDN except 
when activated by their operator.

In a purely theoretical sense, the analysis of how to address this 
really belongs to the working group rather than the charter. In a 
completely practical sense, only one approach is straightforward, so we 
know what the working group is almost certain to conclude.


> I assume based on signalling the media flow could be reversed so the 
> consumer initates the media establishment, but that is also not clear.


It can't, and it is these kinds of observations that I think would make 
you an ideal contributor to the conversation around the protocol 
document once we get the working group established. I'd like to make 
sure that the model for the protocol is crystal clear in the published RFC.


> Clarifying the high level functionality here in the charter might 
> avoid the need for specifically commenting on screens. Because that 
> would basically work if the consumer can be the initiator and request 
> media to it.


Again, if you can propose different language for the charter that makes 
it clear that this kind of use case is explicitly out of scope for the 
working group, that would be great. I tried my best to make this clear 
by mentioning "broadcasting tools" in the existing text seven times, but 
apparently there's still some ambiguity in this version about the scope 
of the problem that people have time and energy to work on.


> The other aspect that I realize is missing is the scope of capability 
> negotiation here and preference indication. Defining this from a 
> WebRTC API perspective might be possible but is not clear. What is 
> needed here? What is assumed about third parties creating media 
> profiles for this type of devices?


Yes! This is already one of the things I have on my list of open items 
that I mention above. It definitely needs consideration by the working 
group -- and I'd value your input when we have that discussion -- but 
this kind of implementation detail doesn't feel to me like the kind of 
thing that rises to the level of a chartering discussion. As an aside, 
to reinforce some of the points I make above: solving the issue of 
capabilities and preferences is somewhat straightforward for the 
specific case of broadcasting tools and network ingest, but arbitrarily 
complex for the general case.



Robert Wilton No Objection Comment (2021-01-21):

> I'm not sure whether this should be part of the charter, but would be 
> helpful for it to specify which version of HTTPS will be targeted, or 
> state a minimum version of HTTPS? 


While the revision of BCP 56 has stalled out after reaching consensus in 
the HTTPBIS working group (I've just now pinged for status), the current 
thinking of HTTP experts is described in its most recent draft revision 
<https://www.ietf.org/archive/id/draft-ietf-httpbis-bcp56bis-09.txt>:


>    Because it is a hop-by-hop protocol, a HTTP connection can be handled
>    by implementations that are not controlled by the application; for
>    example, proxies, CDNs, firewalls and so on.  Requiring a particular
>    version of HTTP makes it difficult to use in these situations, and
>    harms interoperability for little reason (since HTTP's semantics are
>    stable between protocol versions).  Therefore, it is RECOMMENDED that
>    applications using HTTP not specify a minimum version of HTTP to be
>    used.


I would expect that this improved version of BCP 56 will be published 
prior to WHIP's conclusion, and wouldn't want to run awry its guidance 
in final document review. Even if it isn't published, the rationale in 
the quoted passage is sound.

/a