Subject: [MMUSIC] Adam Roach's Yes on draft-ietf-mmusic-sdp-bundle-negotiation-49: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 17 Apr 2018 00:21:26 -0700

Adam Roach has entered the following ballot position for
draft-ietf-mmusic-sdp-bundle-negotiation-49: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to everyone who spent time over the past seven years getting this
document complete and out the door.

---------------------------------------------------------------------------

Abstract:

Please indicate that the document updates RFC 7941.

---------------------------------------------------------------------------

§1:

>  This specification updates RFC 3264 [RFC3264], to allow assigning a
>  zero port value to a "m=" section without meaning that the media
>  described by the "m=" section is disabled or rejected.

This needs further qualification: the exception is very narrow, while this
paragraph makes it sound like the meaning of "0" to reject a media section has
been removed altogether.

---------------------------------------------------------------------------

§10.2:

>  Applications can implement RTP stacks in many different ways.  The
>  algorithm below details one way that RTP streams can be associated
>  with "m=" sections, but is not meant to be prescriptive about exactly
>  how an RTP stack needs to be implemented.
...
>  To prepare to associate RTP streams with the correct "m=" section,
>  the following steps MUST be followed for each BUNDLE group:

This "MUST" seems to be at odds with the text about not being prescriptive.
Please clarify whether the steps following this statement are prescriptive
(normative) or not.

---------------------------------------------------------------------------

§10.2:

>     Layer Refresh Request (LRR):  [I-D.ietf-avtext-lrr] (PT=PSFB,
>        FMT=TBD).

Please replace "TBD" with "10" (cf
https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-9)

---------------------------------------------------------------------------

§11.1:

>  NOTE: The following ICE-related media-level SDP attributes are
>  defined in [I-D.ietf-mmusic-ice-sip-sdp]: 'candidate', 'remote-
>  candidates', 'ice-mismatch', 'ice-ufrag', 'ice-pwd', and 'ice-
>  pacing'.

This seems to leave "ice-options" out.

---------------------------------------------------------------------------

§15.2:

>  applications SHALL avoid generating
>  the identification-tag using a pattern that enables user- or
>  application identification.

Without some kind of recommended MID-generation algorithm, application
identification will be nearly a foregone conclusion. RID makes a concrete
suggestion to start with "1" and go up from there. You may want to consider
doing the same thing, or at least something similar.

This has an impact on §17 as well.

===========================================================================
Nits
===========================================================================

General:

I agree with EKR that the use of "address:port" is cumbersome. For the places
where this is not a stand-in for the term "'m=' section", I would suggest that
the well-known term "3-tuple" would serve the purpose in a much more readable
way.

---------------------------------------------------------------------------

§1:

>  As defined in RFC 4566 [RFC4566], the semantics of assigning the same
>  transport address (IP address and port) to multiple "m=" sections are
>  undefined, and there is no grouping defined by such means.  Instead,
>  an explicit grouping mechanism needs to be used to express the
>  intended semantics.  This specification provides such an extension.

This reads as if the present document is going to define semantics associated
with having the same port and address associated with a multiple m-lines. I
think this was true of BUNDLE at some point in its history, but the present
mechanism uses port=0/bundle-only rather than duplicate port numbers. The
preceding paragraph probably needs to be heavily edited or -- more likely --
removed.

---------------------------------------------------------------------------

§3:

Please consider updating to use RFC 8174 boilerplate.

---------------------------------------------------------------------------

§6:

>  The offerer and answerer assign a zero
>  port value and includes an SDP 'bundle-only' attribute to every other
>  bundled "m=" section.

"...and include..."

---------------------------------------------------------------------------

§8.3.4:

>  it MUST first check the following criteria:

"...criterion:"

>  If the criteria above is fulfilled, the answerer can not reject the

"If the criterion..."

---------------------------------------------------------------------------

§8.3.5:

>    o=bob 2808844564 2808844564 IN IP6 2001:db8::3
...
>    c=IN IP6 2001:db8::3

As this is supposed to be an answer to the offer in §8.2.2, please select a
different address for the answerer than the offerer.

---------------------------------------------------------------------------

§11.1:

>  When an answerer assigns a BUNDLE address to an "m=" section within a
>  BUNDLE group (the "m=" section represented by the answerer BUNDLE-
>  tag), the answerer onlys include SDP 'candidate' attributes (and

Nit: "...only includes..."

---------------------------------------------------------------------------

§12:

>  o  If the DTLS client supports DTLS-SRTP [RFC5764] it MUST include
>     the 'use_srtp' extension [RFC5764] in the DTLS ClientHello message
>     [RFC5764].  The client MUST include the extension even if the
>     usage of DTLS-SRTP is not negotiated as part of the multimedia
>     session (e.g., SIP session [RFC3261].

Fix missing closing paren.

---------------------------------------------------------------------------

§14.3 & §14.4:

The update described by these sections appears unnecessary, as the original text
does not preclude the additional meaning assigned to port=0 by this document. If
this has already been discussed, I don't want to revisit WG consensus; but, if
not, I would recommend removing these sections as superfluous.

---------------------------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Apr 2018 09:31:39 +0000

Hi Adam,

Thank You for the review! Please see inline.

Will do.

What about:

 "This specification updates RFC 3264 [RFC3264], to allow assigning a
  zero port value to a "m=³ section also in cases where the media
  described by the "m=" section is disabled or rejected."

I will ask Magnus/Colin to address this.

Will fix as suggested.

I assumed ice-options was a session-level attribute. Also in
draft-ietf-mmusic-sdp-mux-attributes it is only indicated as a
session-level attribute.

However, when looking in draft-ietf-mmusic-ice-sip-sdp it is defined as
both a session- and media-level attribute. I can add it to the list.

Having said that, draft-ietf-mmusic-ice-sip-sdp does not define any
semantics for media-level usage. Does it mean that the indicated ICE
option only applies to ICE for the given media section, but not to other
media sections? I will send an e-mail on the MMUSIC list.

Section 17 says:

  "Therefore, the identification-tag values MUST be
   generated in a fashion that does not leak user information, e.g.,
   randomly or using a per-bundle group counter, and SHOULD be 3 bytes
   or less, to allow them to efficiently fit into the MID RTP header
   extension." 

I personally have nothing against ³3-tuple², ³transport² (suggested by
Taylor at some point), etc.

The problem is that whenever I change the terminology someone later wants
something else, and then I again have to change it.

Unless someone wants to keep it - and will suggest modified text - I will
remove it.

Will fix.

Will fix.

Will fix.

Will fix.

Will fix.

Will fix.

I don¹t think there have been much discussions about this, so unless
someone wants to keep it I can remove it.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Apr 2018 06:46:18 -0700

On Tue, Apr 17, 2018 at 2:31 AM, Christer Holmberg <
[email-masked]> wrote:

>
> >===========================================================
> ===============
> >=
> >Nits
> >===========================================================
> ===============
> >=
> >
> >General:
> >

Well, we're at IESG review now, so this is the last round.

Who, specifically, is in favor of the current terminology?

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Apr 2018 13:57:29 +0000

Hi,

General:

>> I personally have nothing against '3-tuple', Œtransport' (suggested by

I see it more as terminology that people in the WG could live with.

Having said that, if we can change it with a search/replace operation I am
happy to discuss it. I THINK we could do that e.g., with ³transport² or
³3-tuple². 

But I don¹t want to make yet another re-write of the document just to once
again change the terminology.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 17 Apr 2018 10:26:05 -0500

> On Apr 17, 2018, at 8:46 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Apr 17, 2018 at 2:31 AM, Christer Holmberg <[email-masked]> wrote:
> 
> >I agree with EKR that the use of "address:port" is cumbersome.. For the
> >places

The current terminology may be my fault. IIRC (and I may have this confused with a different document), the pubreq’d version used “bundle address” to mean address and port, and I objected to this being different than the commonly used meaning of “address”.

I am not particularly fond of address:port, though, and agree that “3-tuple” would be better, as long as the usage is clearly defined early in the document.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Apr 2018 18:15:22 +0000

Hi,

>>>General:
>>>
>>> I agree with EKR that the use of "address:port" is cumbersome.. For 
>>> the places where this is not a stand-in for the term "'m=' section", 
>>> I would suggest that the well-known term "3-tuple" would serve the 
>>> purpose in a much more readable way.
>> 
>> I personally have nothing against "3-tuple", "transport" (suggested by 
>> The problem is that whenever I change the terminology someone later 
>> wants something else, and then I again have to change it.
>> 
> The current terminology may be my fault. IIRC (and I may have this confused with a different document), 
> the pubreq’d version used “bundle address” to mean address and port, and I objected to this being different 
> than the commonly used meaning of “address”.
>
> I am not particularly fond of address:port, though, and agree that “3-tuple” would be better, as long as the 
> usage is clearly defined early in the document.

Personally I'd prefer "transport", because "BUNDLE transport" sounds better than "BUNDLE 3-tuple" in my ears. 

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Apr 2018 13:15:27 -0700

On Tue, Apr 17, 2018 at 6:57 AM, Christer Holmberg <
[email-masked]> wrote:

> >>wants

This doesn't answer my question. Who, specifically, thinks that this
terminology
of focusing on the address:port and not the m= section is good?

> again change the terminology.

This document is going to be used by a lot of people. It's important that
it be
clear.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Apr 2018 07:23:10 +0000

Hi,

General:

>>>> I agree with EKR that the use of "address:port" is cumbersome. For the
>>>> places where this is not a stand-in for the term "'m=' section", I would
>>>> suggest that the well-known term "3-tuple" would serve the purpose in a much more
>>>> readable way.
>>>
> This doesn't answer my question. Who, specifically, thinks that this terminology

Considering that the focus has been on the address and port since day one, for 7 years, I think it is good. After all, while there is more to it than the address:port, the main reason for BUNDLE is to be able to multiplex in a single address:port.

Now, we HAVE discussed changing "address:port" to "transport", but it would still not be about the m= section.

>> happy to discuss it. I THINK we could do that e.g., with "transport" or
>> "3-tuple". 
>>
> This document is going to be used by a lot of people. It's important that it be
> clear.

I fully agree. But, I am not sure that endless re-writings the document is going to achieve that.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2018 05:52:41 -0700

On Wed, Apr 18, 2018 at 12:23 AM, Christer Holmberg <
[email-masked]> wrote:

> Considering that the focus has been on the address and port since day one,
> for 7 years, I think it is good.

Yes, who besides you? Because in the text above your argument is that if we
change it, then you will
have to change it again because someone else will object. That's different
from *you* disagreeing

After all, while there is more to it than the address:port, the main reason
> for BUNDLE is to be able to multiplex in a single address:port.
>

Perhaps, but not necessarily the one in the m= line, because of ICE.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Apr 2018 14:46:04 +0000

Hi,

General:

>> Considering that the focus has been on the address and port since day one, for 7 years, I think it is good.
>
> Yes, who besides you?

As the MMUSIC WG decided to move the document forward, I assume that the interested parties think it’s at least good enough.

> Because in the text above your argument is that if we change it, then you will have to change it again because someone else will object.

Considering the history of this draft, and all the re-writes, as author I think that is a fair argument :)

Having said that, I will of course implement whatever the community decides.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 19 Apr 2018 11:41:30 +0200

> I fully agree. But, I am not sure that endless re-writings the document is going to achieve that.

I think this has turned into an argument about style. One usage may be more pleasing to the “ear” than the other, but I don’t see issues of technical correctness or clarity here. As I asked for the the “associated with” question, is anyone arguing that the word choice here is likely to cause material implementation errors?

Ben.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Apr 2018 06:28:43 -0700

On Thu, Apr 19, 2018 at 2:41 AM, Ben Campbell <[email-masked]> wrote:

> > Considering that the focus has been on the address and port since day
> one, for 7 years, I think it is good. After all, while there is more to it
> than the address:port, the main reason for BUNDLE is to be able to
> multiplex in a single address:port.
> >
> I think this has turned into an argument about style. One usage may be
> more pleasing to the “ear” than the other, but I don’t see issues of
> technical correctness or clarity here. As I asked for the the “associated
> with” question, is anyone arguing that the word choice here is likely to
> cause material implementation errors?
>

I don't think "address:port" versus "transport" will, but I do think
"address:port" versus "m=section" or "transport parameters" will, and in
fact I identified a material issue around trickle the other day, that I
haven't seen a response to.

-Ekr

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Apr 2018 13:35:14 +0000

Hi,

> I don't think "address:port" versus "transport" will, but I do think "address:port" versus "m=section" or "transport parameters" will, and in fact I identified a material issue around trickle the other day, that I haven't seen a response to.

My suggestion was to add text about the special case of port 9 and IP address 0.0.0.0.

Because, when you use trickle, the offer may not contain any address information at all (you can send an offer without any candidates), so it is a special case no matter what.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Apr 2018 07:05:38 -0700

On Thu, Apr 19, 2018 at 6:35 AM, Christer Holmberg <
[email-masked]> wrote:

> Because, when you use trickle, the offer may not contain any address
> information at all (you can send an offer without any candidates), so it is
> a special case no matter what.
>

Yes, but the point is that you cannot address the m=section parameters via
address:port, so every piece of text in the document that suggests that you
do so needs to be repaired.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Apr 2018 14:31:16 +0000

Hi,

…

>> I think this has turned into an argument about style. One usage may be more pleasing to the “ear” than the other, but I
>> don’t see issues of technical correctness or clarity here. As I asked for the the “associated with” question, is anyone arguing
>> that the word choice here is likely to cause material implementation errors?
>
> I don't think "address:port" versus "transport" will, but I do think "address:port" versus "m=section" or "transport parameters" will,
> and in fact I identified a material issue around trickle the other day, that I haven't seen a response to.
>
>> Because, when you use trickle, the offer may not contain any address information at all
>> (you can send an offer without any candidates), so it is a special case no matter what.
>
> Yes, but the point is that you cannot address the m=section parameters via address:port, so every
> piece of text in the document that suggests that you do so needs to be repaired.

You don’t need to address the parameters via address:port. You will address the parameters via the BUNDLE-tag.

Yes, the answerer picks the BUNDLE address:port – which it has to do no matter what – but what is does is picking an m- line (the m- line containing the address:port selected to be used) and assigns the BUNDLE-tag to it.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Apr 2018 07:32:34 -0700

On Thu, Apr 19, 2018 at 7:31 AM, Christer Holmberg <
[email-masked]> wrote:

> more pleasing to the “ear” than the other, but I
>
> >> don’t see issues of technical correctness or clarity here. As I asked
> for the the “associated with” question, is anyone arguing
>
> "address:port" versus "m=section" or "transport parameters" will,
>
> information at all
> You don’t need to address the parameters via address:port. You will
> address the parameters via the BUNDLE-tag.
>
>
>
> Yes, the answerer picks the BUNDLE address:port – which it has to do no
> matter what – but what is does is picking an m- line (the m- line
> containing the address:port selected to be used) and assigns the BUNDLE-tag
> to it.
>

Yes, but that's not in fact what the text I quoted says, or is implied by
much of the rest of the document does.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Apr 2018 18:10:37 +0000

Hi,
 
…
 
>> Yes, the answerer picks the BUNDLE address:port – which it has to do no matter what – but what is does is picking an 
>> m- line (the m- line containing the address:port selected to be used) and assigns the BUNDLE-tag to it. 
>
> Yes, but that's not in fact what the text I quoted says, or is implied by much of the rest of the document does.

Sections 8.3.1 talks about selecting an m= section.

As far as the rest of the document is concerned, I don't think we can get rid of the address:port text, because many of the offerer procedures about assigning a given address:port to a given m- section.

Also, many of the answerer procedures (removing m- sections etc) are based on the address:port value of the m- section in the corresponding offer.
 
So, while it may be possible to introduce a head/tagged/bundle m- section concept, I don't think we are going to get rid of the address:port text.

Regards,
 
Christer

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Apr 2018 13:22:14 -0700

On Thu, Apr 19, 2018 at 11:10 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> …
>
> >>>> I think this has turned into an argument about style. One usage may
> be more pleasing to the “ear” than the other, but I
> matter what – but what is does is picking an
> > Yes, but that's not in fact what the text I quoted says, or is implied
> by much of the rest of the document does.
>

Yes. I haven't carefully studied that section, but this is the offerer text
and as I said, this is incorrect.

As far as the rest of the document is concerned, I don't think we can get
> rid of the address:port text, because many of the offerer procedures about
> assigning a given address:port to a given m- section.
>
> Also, many of the answerer procedures (removing m- sections etc) are based
> on the address:port value of the m- section in the corresponding offer.

Yes, I agree we have to be clear that the address:port needs to be assigned
to a given m= section, just as all the other parameters need to be assigned
properly. My concern is about treating address:port as special; that seems
to conflict with trickle.

-Ekr

So, while it may be possible to introduce a head/tagged/bundle m- section
> concept, I don't think we are going to get rid of the address:port text.
>
> Regards,
>
> Christer
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Apr 2018 07:15:58 +0000

Hi,

>>>>be more pleasing to the ³ear² than the other, but I don¹t see issues
>>>>of 
>>>> technical correctness or clarity here. As I asked for the the
>>>>³associated with² question, is anyone arguing that the word choice
>>>>here is likely to cause material implementation errors?
>>>
>>>"address:port" versus "m=section" or "transport parameters" will, and
>>>in fact I identified a material issue around trickle the other day,
>>>that I haven't seen a response to.
>>
>>
My suggestion was to add text about the special case of port 9 and IP
address 0.0.0.0.
Because, when you use trickle, the offer may not contain any address
information at all (you can send an offer without any candidates), so it
is a special case no matter what.
>
> Yes, but the point is that you cannot address the m=section parameters
>via address:port, so every piece of text in the document that suggests
>that you do so needs to be repaired.
>
> You don¹t need to address the parameters via address:port. You will
> Yes, the answerer picks the BUNDLE address:port  which it has to do no
>matter what  but what is does is picking an m- line
> (the m- line containing the address:port selected
 to be used) and assigns the BUNDLE-tag to it.
>by much of the rest of the document does.

You quoted the text in the following sections (I would be really useful to
have the section numbers in the review e-mail, btw, because I assume I
have to address them in a reply):

Section 8.1.:
-------------

   "When an offerer or answerer includes SDP attributes in bundled "m=³
   sections within a BUNDLE group for which the offerer and answerer
   BUNDLE addresses:ports have been selected, IDENTICAL and TRANSPORT
   mux category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are
   only included in the "m=" section indicated by the BUNDLE-tag in the
   offer or answer."

As I indicated earlier, I DO agree that we don¹t need to talk about
address:port here, and it has been removed in the pull request I created.

So, the new text will only talk about the m= section:

   "When an offerer or answerer includes SDP attributes in bundled "m=³
    sections within a BUNDLE group, IDENTICAL and TRANSPORT
    mux category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are
    only included in the "m=" section indicated by the BUNDLE-tag in the
    offer or answer.²

Section 8.3.:
-------------

    "If the answer contains a BUNDLE group, the answerer MUST:

     o  Select an offerer BUNDLE address:port [Section 8.3.1]; and

     o  Select an answerer BUNDLE address:port [Section 8.3.2].²

Regarding the offerer BUNDLE address:port, the functional task performed
by the answerer IS selecting the offerer address:port. Section 8.3.1
describes the detailed SDP procedures for that, and it does talk the m=
section.

Regarding the answerer BUNDLE address:port, I don¹t think we can change
anything there, because the task performed by the answerer IS selecting
the answerer address:port. AFTER that it will assign the address:port to
an m= section in the answer, as described in Section 8.3.2.

So, while we for sure could say something like ³Select an offerer
tagged/head m= section², the procedures would still describe the selection
of the offerer BUNDLE address:port.

Section 8.3.1:
--------------

    "If all of the criteria above are fulfilled, the answerer MUST select
the suggested offerer BUNDLE address:port.²

In the beginning of the section, the text DOES talk about m= section, but
the specific text above IS about the answerer selecting the offerer BUNDLE
address:port, i.e., the address:port that the offerer is going to use.

Section 8.4:
------------

    "When an offerer receives an answer, if the answer contains a BUNDLE
     group, the offerer MUST check that any bundled "m=" section in the
     answer was indicated as bundled in the corresponding offer.  If there
     is no mismatch, the offerer MUST use the offerer BUNDLE address:port,
     selected by the answerer [Section 8.3.1], as the address for each
     bundled "m=" section.²

This text talks about the offerer determining what address:port it will
use. 

Now, I do agree that we could modify this text by saying that the offerer
picks the tagged m= section, and then picks the address:port (and other
parameters) from that m= section.

Section 11:
-----------

     "In an offer, if the offer assigns a unique address:port to one or
      more bundled "m=" sections (excluding any bundle-only "m="
      sections), the offerer MUST include ICE-related media-level
      attributes in each of those "m=" sections.  If the offerer assigns
      an offerer BUNDLE address:port (previously selected
      [Section 8.3.1] or newly suggested [Section 8.5.1]) to a bundled
      "m=" section (the "m=" section indicated by the offerer BUNDLE-
      tag), the offerer only includes ICE-related media-level SDP
      attributes in that "m=" section, following the procedures in
      Section 8.1.²

Similar to section 8.1, I DO agree that we can remove the text about
address:port here, and talk about including ICE attributes in bundled m=
sections.

Section 11.1.:
--------------

The first paragraph talks about assigning a unique address:port (i.e.,
before the BUNDLE group has been negotiated), so I am not sure we can
modify that. Or, perhaps we could talk about assigning attributes to m=
sections before a BUNDLE group has been negotiated.

The second and third paragraphs talk about the case when a BUNDLE group
has been negotiated. Similar to section 11, I do agree that we don¹t need
to talk about address:port here. It¹s enough to talk about assigning
attributes to the tagged m= section.

HISTORY:
--------

When writing the comments above, I think one of the reasons we talk about
address:port is because previously I think the draft talked about ³BUNDLE
group² even before it had been negotiated - so we had to distinguish
between the cases where the BUNDLE addresses:ports had been selected and
where they had not (initial offer). Currently, a BUNDLE group does not
exist until it has been negotiated, so the m= sections within a BUNDLE
group will ALWAYS contain the BUNDLE address:port (or bundle-only plus
port zero). So, while the procedures were clarified, some parts may have
become redundant.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Apr 2018 13:45:13 -0700

> have to address them in a reply):

You might find it easier to read the review on Phabricator:

https://mozphab-ietf.devsvcdev.mozaws.net/D3382

> Section 8.1.:

Yes, this seems fine.

> Section 8.3.:

I don't see how you get that. The task is to select the m= section to use
as the lead m= section and then use its parameters, which include the
address:port. Again, if things were as you say, then trickle wouldn't make
sense.

> of the offerer BUNDLE address:port.

Right, but then it totally omits the text about the *other* parameters,
which
are equally important. Where does this document tell me to use the
ICE candidates from that m= section.

Yes, My point is that the emphasis on this is wrong.

> parameters) from that m= section.

Yes, that's what the test needs to say.

> Section 11:

Or something.

m= sections can exist in a variety of states (proposed bundled, proposed
bundle
lead, bundle-only, etc.) and each of those has various properties and
requirements,
which include, but are not limited to address.

> port zero).

Or, again, 9...

-Ekr

So, while the procedures were clarified, some parts may have

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Apr 2018 18:43:03 +0000

Hi,

...

Section 8.3.1:
-------------------

> Right, but then it totally omits the text about the *other* parameters, which

Ok, I agree that needs to be clarified.

(Section 8.1 defines how/where SDP attributes are assigned, but it doesn't say from which m= section and offerer/answerer picks the attributes of the peer)

Regards,

Christer