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

From: Andy Hutton <[email-masked]>
Date: Fri, 3 Nov 2017 09:18:07 +0000

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
<[email-masked]> 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
>><[email-masked]> 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:[email-masked]]
>>> Sent: 27 September 2017 21:58
>>> To: Christer Holmberg <[email-masked]>
>>> Cc: [email-masked]
>>> 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-nLI
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> -G
>>>
>>>
>>>
>>> On Sep 27, 2017, at 9:19 AM, Christer Holmberg
>>> <[email-masked]> 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 [email-masked]"
>>> <[email-masked] on behalf of [email-masked]> 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-negotiat
>>>i
>>> on/
>>>
>>> There are also htmlized versions available at:
>>>
>>>https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiation-0
>>>1
>>>
>>>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-opportunistic-neg
>>>o
>>> tiation-01
>>>
>>> A diff from the previous version is available at:
>>>
>>>https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-opportunistic-negotia
>>>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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Nov 2017 09:34:30 +0000

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

---

From: Andy Hutton <[email-masked]>
Date: Fri, 3 Nov 2017 10:16:18 +0000

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

But is it really necessary in this case?

Andy

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Nov 2017 11:05:58 +0000

Hi,

>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

>>>>>>https://mailarchive.ietf.org/arch/msg/mmusic/wov2yErrgtUZURyRyVuVZ6K-
>>>>>>nL
>>>>>>I
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>>
>>>>>> -G
>>>>>>
>>>>>>
>>>>>>
>>>>>>https://datatracker.ietf.org/doc/draft-ietf-mmusic-opportunistic-nego
>>>>>>ti
>>>>>>at
>>>>>>i
>>>>>> on/
>>>>>>
>>>>>>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
>>>>>>
>>>>>>https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-opportunistic-neg
>>>>>>ot
>>>>>>ia
>>>>>>t
>>>>>> ion-01
>>>>>>
>>>>>>

---

From: Andy Hutton <[email-masked]>
Date: Wed, 8 Nov 2017 15:45:08 +0000

> answer them from the beginning.

Thanks Christer for the details comments and I have a lot of sympathy
regarding the view that all this should all be specified in the MMUSIC
draft however this is all contrary to the decisions made a couple of
years ago in Dispatch when it was decided to form SIPBrandy to do this
specification work. Unfortunately once we had started down the path of
doing the work in SIPBrandy we discovered that we needed to update RFC
4568 and the AD's instructed us write a short MMUSIC draft to update
the RFC 4568 as the SIPBrandy charter did not allow for this.

So now we are going round in circles and we need to decide whether we
do the OSRTP work in MMUSIC which is what we wanted in the first place
or we continue with SIPBrandy.

Please can the relevant chairs and AD's get together and tell us how to proceed.

Regards
Andy

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Nov 2017 16:10:14 +0000

Hi,

...

> Thanks Christer for the details comments and I have a lot of sympathy regarding the view that all this should
> all be specified in the MMUSIC draft however this is all contrary to the decisions made a couple of years ago in Dispatch

One can always make a new decision.

> when it was decided to form SIPBrandy to do this specification work. 

So, where is the SIPBrandy specification work? All I find is an INFORMATIVE draft (draft-ietf-sipbrandy-osrtp), which does NOT contain the specifications I am asking for.

> Unfortunately once we had started down the path of doing the work in SIPBrandy we discovered that we needed to update RFC
> 4568 and the AD's instructed us write a short MMUSIC draft to update the RFC 4568 as the SIPBrandy charter did not allow for this.
>
> So now we are going round in circles and we need to decide whether we do the OSRTP work in MMUSIC which is what we wanted
> in the first place or we continue with SIPBrandy.
>

Yes, let's do that.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 8 Nov 2017 12:37:42 -0500

> Please can the relevant chairs and AD's get together and tell us how to proceed.

Yes, this is the proper way to sort this out.

	Thanks,
	Paul