Hi Bob, Hi Martin, See my reflections below prefixed with [ZS].
> On 8 Jul 2022, at 01:05, Bob Briscoe <[email protected]> wrote: > > Martin, > > Thx. No push back from me to anything you've said, except one clarification > inline tagged [BB]. > > On 06/07/2022 18:19, Martin Duke wrote: >> Thanks Bob >> >> Replies inline >> >> On Mon, Jul 4, 2022 at 3:23 PM Bob Briscoe <[email protected] >> <mailto:[email protected]>> wrote: >> Zahed, Martin, >> >> I agree with DaveT - the reasoning for not including r-t CCs seems weak. >> The main reason for bringing everything together is that CC expertise is >> thin on the ground. Including r-t would force the CCLR WG to think >> carefully about what is possible as 'general-purpose' and what isn't, >> and to decide on what the maximum subsets are, and what is necessary for >> interop between them. >> >> It seems like RMCAT is approaching end-of-life, so it would surely be >> sensible to pick up any future r-t CC work in this newly proposed group, >> rather than ruling it out in the charter. I.e. better to rule it in to >> this CCLR charter as an intention, but rule it out as a short-term >> exception while RMCAT finishes its current work stand-alone. >> >> [MD] I filed an issue on this. Zahed, Colin, and I will discuss what >> baseline we should bring to the meeting. [ZS] thanks for creating the issue.. lets discuss this. I am yet to get convinced that we need a super working group to take care of all the congestion control issues. CCRL can still be chartered with very specific scope and deliverables to start with, later recharter to bring new topics or scopes. RMCAT is the first one where we wanted to go for standard congestion control algorithm for interactive real-time media and we have some experiences from those we should learn to be more successful. >> >> >> Here's some additional thoughts on the proposed new WG and charter: >> >> 1) Name-and-shame compliance testing >> In other areas of the IETF, people and companies most want to get >> involved when an RFC is about to publish interop requirements that will >> preclude what they want to do - unless they intervene and contribute. CC >> is generally sender-only, so there is no binary works/fails interop >> test. Instead, CC interop is "non-functional", meaning it's about harm >> to the performance of others (or of self). I don't mean testing to give >> products a compliance certificate. I am thinking more about name and >> shame. So if this WG wants to ensure healthy participation, it ought to >> at least consider compliance testing work. >> >> [MD] Although this is a bit out of the usual IETF activity, I can imagine >> the occasional IETF document >> saying that you shouldn't use algorithm XYZ. I'm not sure this would work >> out in practice, but if others >> are interested, we can consider it. Issue filed. > > [BB] When I said that people get most interested when an RFC preclude > something they're doing, I wasn't meaning solely "shouldn't use algo XYZ". > I meant more generally that, if a draft takes care to specify how to /test/ a > required behaviour, if some company already has an algo that would fail that > compliance test, they would suddenly become v interested in participating in > the IETF. Whereas before they could just ignore it. [ZS] I kind of agree that test case are good way to engage algorithm developers as they wanted to see how their CC algorithms perform under certain settings/condition, however, it does not give guarantee that they would not ignore what is happening at IETF once they are satisfied. We have this experience in RMCAT, CC developers were enthusiastic to test their algorithms and show results to IETF but once they got their expected behaviour they were not really interested in pursuing standardising their algorithm - eventually ignoring what is there in IETF in their implementation. We certainly does not want CCRL to be just a place where algorithm developers comes and test and show their performance. We need higher commitment levels on the deployment and maturity level for the algorithm to enter in CCRL scope. This will be tricky to set a bar here though. //Zahed
smime.p7s
Description: S/MIME cryptographic signature
