Re: [MMUSIC] Moving Forward on 4572-update (was Re: Rough concensus: Re: 4572-update: Consensus call on how to move forward)

[Flemming Andreasen <[e-mail]>]

Hi Ben

We will get a poll setup as soon as we understand any major constraints 
from the key participants.

Thanks

-- Flemming


On 10/21/16 4:49 PM, Ben Campbell wrote:
> Hi Everyone, please accept my apologies for waiting this long to weigh 
> in.
>
> I think it's clear that multiple people are not happy with how we got 
> to this point. But assigning blame doesn't help us make progress on 
> the draft. I propose that we get over that, and instead focus instead 
> on how to move forward. Email discussion doesn't seem to be helping. 
> Maybe a call will.
>
> Flemming and/or Bo: Can you set up a Doodle poll to get Christer, 
> Cullen, and other demonstratively  interested parties on a conference 
> call? I will join if at all possible, but don't let scheduling around 
> me stop a call from happening.
>
> Thanks!
>
> Ben.
>
> On 21 Oct 2016, at 11:05, Flemming Andreasen wrote:
>
>> [fixing cc-list]
>>
>> On 10/21/16 11:59 AM, Flemming Andreasen wrote:
>>>
>>>
>>> On 10/21/16 11:21 AM, Cullen Jennings wrote:
>>>> I think that is a bad way to run a WG. All I asked for was a phone 
>>>> call to discuss this so we could get the issues on the table and 
>>>> discuss what is best. The chairs never even replied to my request 
>>>> for a WG call to discuss this.
>>> That is simply not true. You (and Christer) were explicitly asked to 
>>> setup a phone call on 10/6/16 to discuss this issue; a request that 
>>> (like many other others) went unanswered or required extensive 
>>> prodding to get any attention.
>>>
>>>> The list discussions that ensued from this resulted in people other 
>>>> than me sugesting possibilities that were much better than any of 
>>>> the three below -  none of which were considered in your consensus 
>>>> call.
>>> I'm not sure what those proposals are, nor were they brought up in 
>>> response to the consensus call.
>>>
>>>> I don’t plan to appeal this but I am considering if it’s worth my 
>>>> time to participate in this WG if we are not going to be willing to 
>>>> actually spend a short time to discuss possible solutions before 
>>>> taking a consensus call.  As input to that decisions, it would be 
>>>> really useful to know why you refused to have a phone call on this 
>>>> topic and what your policy in general is going to be toward 
>>>> discussions of proposed solutions to problems in the future.
>>> My position is that we will try our very best to get to not only 
>>> consensus but to satisfy as many concerns as we possibly can. It 
>>> does however require people to engage in a timely manner, and even 
>>> when they don't, we still do what we can, but at some point we need 
>>> to move forward. As for the issue at hand, it has been discussed 
>>> extensively, and several changes were made to the draft to try and 
>>> accommodate your requests.
>>>
>>> The one major remaining issue I believe you have is around whether 
>>> this document updates RFC 4572. This has been discussed extensively 
>>> on the wgchairs list; a discussion I initiated to try and help 
>>> address your concern. You may disagree with how that discussion 
>>> concluded, but again, to try and alleviate your concerns, a note was 
>>> added to 4572-update to make it clear that the document does not 
>>> make existing 4572 implementations non-compliant with RFC 4572.
>>>
>>> I believe the chairs, authors, and the WG at large has done 
>>> everything that can reasonably be done to try and address your 
>>> concerns, and at this point we need to move forward.
>>>
>>> Thanks
>>>
>>> -- Flemming (as MMUSIC co-chair)
>>>
>>>
>>>
>>>>
>>>>> On Oct 19, 2016, at 6:43 AM, Flemming Andreasen 
>>>>> <[e-mail]> wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> Following up on the consensus call, we have received 5 responses 
>>>>> in favor of option a) below, one neutral, and one objection. 
>>>>> Looking at the document we have noted that backwards compatibility 
>>>>> is handled by the current text in the document and it also clearly 
>>>>> states that it does not make current RFC 4572 implementation 
>>>>> non-compliant with RFC 4572. Since we have not heard of any 
>>>>> technical problems with proposal a), nor seen any tangible 
>>>>> progress on how to address the objection, we are hereby declaring 
>>>>> rough consensus on option a). We will proceed with the publication 
>>>>> request for the current draft while duly noting the "roughness" of 
>>>>> the consensus based on the pending objection as part of this.
>>>>>
>>>>> Thanks
>>>>>
>>>>>     Flemming & Bo (MMUSIC chairs)
>>>>>
>>>>>
>>>>> On 10/12/16 6:23 PM, Flemming Andreasen wrote:
>>>>>> Greetings
>>>>>>
>>>>>> There has been quite a bit of discussion on 
>>>>>> draft-ietf-mmusic-4572-update (currently -07), which had 
>>>>>> previously completed WGLC when a few concerns were raised. The 
>>>>>> document currently:
>>>>>> 1. Clarifies the usage of multiple SDP 'fingerprint' attributes
>>>>>> 2. Updates the preferred cipher-suite with a stronger cipher suite
>>>>>> 3. Updates RFC 4572.
>>>>>>
>>>>>> Item 1 seems to be generally agreeable, whereas items 2 and 3 are 
>>>>>> not. The chairs are hereby soliciting WG feedback on how to 
>>>>>> proceed based on the following choices:
>>>>>>
>>>>>> a) Proceed with publication of 4572-update-07 in its current form 
>>>>>> (i.e. covering all 3 items above)
>>>>>>
>>>>>> b) Remove item 2 from 4572-update, i.e. do not update the 
>>>>>> preferred cipher-suite
>>>>>>
>>>>>> c) Remove item 3 from 4572-update, i.e. do not indicate that this 
>>>>>> document constitutes an update to RFC 4572.
>>>>>>
>>>>>>
>>>>>> Note that choice a) is mutually exclusive with b) and c), but b) 
>>>>>> and c) are not mutually exclusive.
>>>>>>
>>>>>> Please let us know your preference wrt to the above no later than 
>>>>>> Friday October 14th.
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>        Flemming & Bo (MMUSIC chairs)
>>>>>>
>>>>>> _______________________________________________
>>>>>> mmusic mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>> .
>>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> .
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> .
>