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

[Flemming Andreasen <[e-mail]>]

A Doodle poll is now available at

	http://doodle.com/poll/kxw4n9a2v7v3pe2y

We are looking at either Wednesday or Friday next week (November 2 or 
4), so please get your vote in pretty quickly if you are interested.

Thanks

-- Flemming


On 10/25/16 12:01 AM, Flemming Andreasen wrote:
> 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
>>
>> .
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic