Re: The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued"

Are we good to go and submit the mmusic draft then?

I don't disagree with Paul it is just an artifact of the
organisational structure but this is what SIPBrandy WG, AD's, and
Chairs decided and it has taken far to long already. Lets press ahead
and get it done.

Andy

On Fri, May 19, 2017 at 3:10 PM, Paul Kyzivat <[email protected]> wrote:
> On 5/19/17 9:19 AM, Flemming Andreasen wrote:
>>
>> Hi Paul
>>
>> Does this satisfy any concerns you may have had with taking on this work
>> and adopting the draft as a WG item ?
>
>
> I still think this is just a silly artifact of the organizational structure.
> But it doesn't matter much so I have no objection to moving forward as-is.
>
>         Thanks,
>         Paul
>
>
>> Thanks
>>
>> -- Flemming (as MMUSIC co-chair)
>>
>> On 5/15/17 8:48 AM, Andy Hutton wrote:
>>>
>>> On Tue, May 9, 2017 at 6:35 PM, Gonzalo Salgueiro (gsalguei)
>>> <[email protected]> wrote:
>>>>>
>>>>> On May 9, 2017, at 1:28 PM, Paul Kyzivat <[email protected]>
>>>>> wrote:
>>>>>
>>>>> On 5/9/17 1:13 PM, Gonzalo Salgueiro (gsalguei) wrote:
>>>>>>
>>>>>> SIPBRANDY WG is not chartered to produce PS specs, which the
>>>>>> original draft (draft-ietf-sipbrandy-osrtp) would have been since
>>>>>> it was updating a current PS. The WG made the decision (vetted by
>>>>>> AD and IESG) to not re-charter and instead decided split off the
>>>>>> piece that updates a PS into a new PS
>>>>>> (draft-hutton-mmusic-opportunistic-negotiation).
>>>>>
>>>>> OK. But then couldn't everything be put into the MMUSIC document?
>>>>> ISTM that given the limited content in these documents that
>>>>> splitting it into two, with a lot of overlap, is confusing.
>>>>
>>>> I see your point but Currently SIPBRANDY is chartered to produce
>>>> Opportunistic SRTP as a BCP. There is also a milestone to inform
>>>> MMUSIC or other appropriate WGs of any changes needed to support
>>>> Opportunistic SRTP (Not expected to be published as an RFC).  I think
>>>> SIPBRANDY is just carrying out what they are chartered to do.
>>>>
>>> Agree this is largely procedural we started the work in SIPBrandy and
>>> then realised we needed to update RFC 4568 so were forced to go to
>>> MMUSIC to do that. The tidy thing to do now is just finish what we
>>> started in both MMUSIC and SIPBrandy.
>>>
>>> Andy
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> .
>>>
>>
>>
>