Re: [MMUSIC] I-D Action: draft-ietf-mmusic-opportunistic-negotiation-01.txt

[Christer Holmberg <[e-mail]>]

Hi,

>Christer, I understand the desire to put others through the same pain
>as yourself that’s natural :-).

There is no pain like BUNDLE pain - even though ICEbis pain comes very
close :)

Anyway, it’s not up to me to decide whether a new WGLC would be needed.
I’ll leave that to the chairs.

>But is it really necessary in this case?

Seriously, I think it is. This is something that is expected to be widely
implemented (as we know, there are already implementations and SIP
profiles doing it), so I think the procedures need to be clear. Just
because those of use familiar with SDP might think it’s simple, it doesn’t
mean others will.

Now, the draft says:

   "The exact negotiation mechanism is however outside the scope of this
    document, an example mechanism can be found in
[I-D.ietf-sipbrandy-osrtp].”


How do you implement and test something based on a statement like that? In
addition, the “example mechanism” does not cover subsequent offers.

And, ietf-sipbrandy-osrtp says:

   "The use of SDP Security Descriptions using the RTP/AVP profile is
defined in
    [I-D.mmusic-opportunistic-negotiation].”


So, both drafts seem to say that one shall look at the other draft for
details :)

So, I think you should add the following sections:

X.  SDP Offer/Answer Procedures
X.1.  Generating the Initial SDP Offer
X.2.  Generating the SDP Answer
X.3.  Offerer Processing of the SDP Answer
X.4.  Modifying the Session


In addition to defining how the offers and answers are created (that is
the simple part), it also needs to be clear whether there are restrictions
in subsequent offers.

For example, what does it mean to send a subsequent offer with RTP/AVP,
WITHOUT a=fingerprint/crypto/zrtp-hash? Is the security disabled?

Also, as this document updates RFCs 4568 and 4585, I’d prefer to have a
dedicated section named “Updates to RFC 4568 and RFC 4585”, and then
indicate what is updated.

Also, are there BUNDLE considerations? For example, can you use
opportunistic security in one bundled m- section, while you use vanilla
security in another m- section?

These are questions that may come up sooner or later, so let’s try to
answer them from the beginning.

Regards,

Christer


>On Fri, Nov 3, 2017 at 9:34 AM, Christer Holmberg
><[e-mail]> wrote:
>> Hi,
>>
>> Just because the draft is “simple”, I still think we shall do it
>>properly,
>> as this is the specification defining the normative O/A procedures.
>>
>> Also, based on the discussions regarding SDP related terminology, I
>>think
>> we should talk about “m=“ sections instead of “m=“ lines.
>>
>> Sometimes we do need additional WGLCs - I’ve lost count on how many
>>WGLCs
>> we’ve had for BUNDLE by now :)
>>
>> Regards,
>>
>> Christer
>>
>>
>> On 03/11/17 11:18, "Andy Hutton" <[e-mail]> wrote:
>>
>>>The comment from Christer below was the only WGLC comment I believe.
>>>
>>>Whilst I see some value in what Christer suggests I think this is a
>>>simple draft which already adequately describes the solution and to be
>>>honest I don't really want to go round the loop of making significant
>>>changes to the draft and going through more last calls etc.
>>>
>>>Please can the chairs let us know how we should proceed.
>>>
>>>Unfortunately I will not be in Singapore to discuss but lets find a
>>>way to get this done.
>>>
>>>Regards
>>>Andy
>>>
>>>
>>>
>>>
>>>On Thu, Sep 28, 2017 at 10:35 AM, Christer Holmberg
>>><[e-mail]> wrote:
>>>> Hi,
>>>>
>>>>>I agree that ideally we should have all the associated procedures in
>>>>>one place and having two specs is not ideal however we have been going
>>>>>round this circle for a couple of years now and just need to get this
>>>>>done.
>>>>>
>>>>>Originally we wanted this work to be done in MMUSIC but it got
>>>>>dispatched to SIPBrandy but it was later discovered that an update to
>>>>>RFC 4568 was needed and that the SIPBrandy charter did not allow this
>>>>>so we were told an MMUSIC draft was needed after all to update the RFC
>>>>>before the SIPBrandy work could be completed.
>>>>>
>>>>>I do not want to start again and waste another couple of years lets
>>>>>just get it finished.
>>>>
>>>> I suggest that we:
>>>>
>>>> 1)      Keep the SIPBRANDY draft as it is. Perhaps they could add a
>>>>sentence
>>>> pointing out that that the normative procedures will be described
>>>> elsewhere.
>>>> 2)      Keep the MMUSIC draft, but we add a proper 'SDP Offer/Answer
>>>> Considerations’ section, where we include the normal subsections
>>>>(create
>>>> initial offer, process offer, process answer etc).
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>
>>>>>On Wed, Sep 27, 2017 at 9:35 PM, Christer Holmberg
>>>>><[e-mail]> wrote:
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> In the mail you referenced the following is said:
>>>>>>
>>>>>>
>>>>>>
>>>>>> “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.”
>>>>>>
>>>>>>
>>>>>>
>>>>>> But, draft-ietf-mmusic-opportunistic-negotiation doesn’t really
>>>>>>define
>>>>>>any
>>>>>> procedures ­ it references the SIPBRANDY draft for everything.
>>>>>>
>>>>>>
>>>>>>
>>>>>> “[I-D.ietf-sipbrandy-osrtp] describes how Secure Real-time transport
>>>>>>
>>>>>>               protocol (SRTP) can be negotiated opportunistically.”
>>>>>>
>>>>>>
>>>>>>
>>>>>> But, as the SIPBRANDY is only Informational, where are the normative
>>>>>> procedures?
>>>>>>
>>>>>>
>>>>>>
>>>>>> “The exact negotiation mechanism is however outside the scope of
>>>>>>this
>>>>>> document,
>>>>>>
>>>>>>               an example mechanism can be found in
>>>>>> [I-D.ietf-sipbrandy-osrtp].”
>>>>>>
>>>>>>
>>>>>>
>>>>>> How can negotiation be outside the scope of the document, when the
>>>>>>title of
>>>>>> the document contains “negotiating”?
>>>>>>
>>>>>>
>>>>>>
>>>>>> In addition, the text says that the sipbrandy only contains “an
>>>>>>example
>>>>>> mechanism”.
>>>>>>
>>>>>>
>>>>>>
>>>>>> If we are going to have this document, I think we shall include
>>>>>>normative
>>>>>> offer/answer procedures. The draft DOES contain some normative
>>>>>>procedures,
>>>>>> but I think we shall have it all in one place. One shall not have to
>>>>>>read
>>>>>> both documents just to figure out the offer/answer procedures.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Gonzalo Salgueiro (gsalguei) [mailto:[e-mail]]
>>>>>> Sent: 27 September 2017 21:58
>>>>>> To: Christer Holmberg <[e-mail]>
>>>>>> Cc: [e-mail]
>>>>>> Subject: Re: [MMUSIC] I-D Action:
>>>>>> draft-ietf-mmusic-opportunistic-negotiation-01.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Christer -
>>>>>>
>>>>>>
>>>>>>
>>>>>> See this:
>>>>>>
>>>>>>https://mailarchive.ietf.org/arch/msg/mmusic/wov2yErrgtUZURyRyVuVZ6K-
>>>>>>nL
>>>>>>I
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>>
>>>>>> -G
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sep 27, 2017, at 9:19 AM, Christer Holmberg
>>>>>> <[e-mail]> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am currently reviewing draft-ietf-sipbrandy-osrtp-03, and the
>>>>>>following
>>>>>> question comes to my mind: do we really need
>>>>>> draft-ietf-mmusic-opportunistic-negotiation? :)
>>>>>>
>>>>>> Section 3 of draft-ietf-sipbrandy-osrtp-03 already more or less
>>>>>>contains
>>>>>> SDP Offer/Answer procedures for OSRTP. We can change the name of
>>>>>>section 3
>>>>>> in that draft to ³SDP Offer/Answer Procedures², modify the
>>>>>>structure a
>>>>>> little, and add whatever might be missing.
>>>>>>
>>>>>> Or, am I missing something?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 14/09/17 19:03, "mmusic on behalf of [e-mail]"
>>>>>> <[e-mail] on behalf of [e-mail]>
>>>>>>wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>>> directories.
>>>>>> This draft is a work item of the Multiparty Multimedia Session
>>>>>>Control
>>>>>>WG
>>>>>> of the IETF.
>>>>>>
>>>>>>       Title           : Negotiating SRTP and RTCP Feedback using the
>>>>>> RTP/AVP Profile
>>>>>>       Authors         : Andrew Hutton
>>>>>>                         Roland Jesske
>>>>>>                         Alan Johnston
>>>>>>                         Gonzalo Salgueiro
>>>>>>                         Bernard Aboba
>>>>>> Filename        : draft-ietf-mmusic-opportunistic-negotiation-01.txt
>>>>>> Pages           : 7
>>>>>> Date            : 2017-09-14
>>>>>>
>>>>>> Abstract:
>>>>>>  This document describes how the use of the Secure Real-time
>>>>>>transport
>>>>>>  protocol (SRTP) [RFC3711]. can be negotiated using the RTP/AVP
>>>>>>(Audio
>>>>>>  Video Profile) defined in [RFC3551].  Such a mechanism is used to
>>>>>>  provide a means for encrypted media to be used in environments
>>>>>>where
>>>>>>  support for encryption is not known in advance, and not required.
>>>>>>  The same mechanism is also applied to negotiation of the Extended
>>>>>>RTP
>>>>>>  Profile for Real-time Transport Control Protocol Based Feedback
>>>>>>(RTP/
>>>>>>  AVPF) [RFC4585].
>>>>>>
>>>>>>
>>>>>> The IETF datatracker status page for this draft is:
>>>>>>
>>>>>>https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-nego
>>>>>>ti
>>>>>>at
>>>>>>i
>>>>>> on/
>>>>>>
>>>>>> There are also htmlized versions available at:
>>>>>>
>>>>>>https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiati
>>>>>>on
>>>>>>-0
>>>>>>1
>>>>>>
>>>>>>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic
>>>>>>-n
>>>>>>eg
>>>>>>o
>>>>>> tiation-01
>>>>>>
>>>>>> A diff from the previous version is available at:
>>>>>>
>>>>>>https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-opportunistic-neg
>>>>>>ot
>>>>>>ia
>>>>>>t
>>>>>> ion-01
>>>>>>
>>>>>>
>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>> submission
>>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>>
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>
>>