Re: [MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Tools failure here failed to get my new review. Expect something correct
soon.

On Sat, May 19, 2018 at 1:18 PM, Eric Rescorla <[e-mail]> wrote:

> Eric Rescorla has entered the following ballot position for
> draft-ietf-mmusic-sdp-bundle-negotiation-51: No Objection
>
> 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:
> ----------------------------------------------------------------------
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3382
>
> This is really vastly better. Thanks for making the changes. I have
> made a few notes of things that I still think are problematic, but I
> am clearing my DISCUSS.
>
>
> IMPORTANT
> S 7.3.5.
> >      a zero port value to, the video "m=" section.
> >
> >      SDP Answer
> >
> >        v=0
> >        o=bob 2808844564 2808844564 IN IP6 2001:db8::1
>
> This doesn't sound right. You can't use the existing address:port,
> because if the peer rejects BUNDLE but accepts the m= section then
> it's broken.
>
>
> S 9.3.1.2.
> >
> >   9.3.1.2.  Generating the SDP Answer
> >
> >      When an answerer generates an answer, if the answerer supports RTP-
> >      based media, and if a bundled "m=" section in the corresponding
> offer
> >      contained an SDP 'rtcp-mux' attribute, the answerer MUST enable
> usage
>
> This does not define how to interact with trickle ICE.
>
> COMMENTS
>
> >
> >    Negotiating Media Multiplexing Using the Session Description Protocol
> >                                    (SDP)
> >               draft-ietf-mmusic-sdp-bundle-negotiation-51.txt
> >
> >   Abstract
>
> This document is quite a bit improved from when I read it before, but
> it's still very confusing. The primary problem here is the repeated
> use of "address;port" as synechdoche for the m= section which is the
> "head" of the BUNDLE group (i.e., that which is indicated by the
> BUNDLE-tag). That's not what's going on and it's misplaced
> concreteness. I would invent some new term ("head" is actually not
> bad) and then use it throughout for this concept.
>
>
> S 1.2.
> >      transport) for sending and receiving media (bundled media) described
> >      by multiple SDP media descriptions ("m=" sections).  The
> address:port
> >      combination used by an endpoint for sending and receiving bundled
> >      media is referred to as the BUNDLE address:port.  The set of SDP
> >      attributes that are applied to each "m=" section within a BUNDLE
> >      group is referred to as BUNDLE attributes.  The same BUNDLE
> transport
>
> Nit: "pair"?
>
>
> S 1.2.
> >      group is referred to as BUNDLE attributes.  The same BUNDLE
> transport
> >      is used for sending and receiving bundled media, which means that
> the
> >      symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is
> >      always used for RTP-based bundled media.
> >
> >      This specification defines a new SDP Grouping Framework [RFC5888]
>
> Why is one of these called "address" and the other "address:port"?
>
>
> S 1.2.
> >      Interactive Connectivity Establishment (ICE)
> >      [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group.
> >
> >      A given BUNDLE address:port MUST only be associated with a single
> >      BUNDLE group.  If an SDP offer or answer contains multiple BUNDLE
> >      groups, the procedures in this specification apply to each group
>
> 1. Bundle lets you have multiple SDP m= sections on a single 5-tuple
> 2. The underling mechanism here is that you put those m= sections in
> the same BUNDLE group
> 3. In order to facilitate demuxing, we define a new RTP extension for
> MID.
> 4. It is sometimes desirable to say that an m= section should only be
> negotiated if it can be bundled. This is done with port=0 and a
> =bundle-only.
>
>
>
> S 1.2.
> >      Interactive Connectivity Establishment (ICE)
> >      [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group.
> >
> >      A given BUNDLE address:port MUST only be associated with a single
> >      BUNDLE group.  If an SDP offer or answer contains multiple BUNDLE
> >      groups, the procedures in this specification apply to each group
>
> This section is kind of a laundry list. I think it would be helpful to
> break it out conceptually. Specifically.
>
> 1.
> 2.
> 3.
>
>
>
> S 1.3.
> >         SDES header extension that can be used to associate RTP streams
> >         with "m=" sections.
> >
> >      o  The specification updates [RFC7941], by adding an exception, for
> >         the MID RTP header extension, to the requirement regarding
> >         protection of an SDES RTP header extension carrying an SDES item
>
> Was this intended to be a bullet?
>
>
> S 2.
> >
> >      o  BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category
> >         SDP attributes.  Once a BUNDLE group has been created, the
> >         attribute values apply to each bundled "m=" section within the
> >         BUNDLE group.
> >
>
> This is a very idiosyncratic definition, because it's *not* the first
> offer in the session, but the one where the BUNDLE group is
> introduced. Given that 3264 has a different meaning for this same
> term, and the difference is critical, I would strongly urge you to
> pick a different term.
>
>
> S 2.
> >      o  Bundle-only "m=" section: A bundled "m=" section that contains an
> >         SDP 'bundle-only' attribute.
> >
> >      o  Bundled media: All media associated with a given BUNDLE group.
> >
> >      o  Initial offer: The first offer, within an SDP session (e.g. a SIP
>
> This appears still not to be resolved. Here is the 3264 definition "
> Protocol operation begins when one agent sends an initial offer to
> another agent.  An offer is initial if it is outside of any context
> that may have already been established through the higher layer
> protocol." I'm not making this part of my DISCUSS, but I think it's
> very confusing and I would strongly urge the AD to address it.
>
>
>
>
> S 2.
> >         BUNDLE group is created once the answerer sends the initial
> >         answer.
> >
> >      o  Subsequent offer: An offer which contains a BUNDLE group that has
> >         been created as part of a previous offer/answer exchange.
> >
>
> How about "is part of" instead of "associated with"
>
>
> S 2.
> >         been created as part of a previous offer/answer exchange.
> >
> >      o  Subsequent answer: An answer to a subsequent offer.
> >
> >      o  Identification-tag: A unique token value that is used to identify
> >         an "m=" section.  The SDP 'mid' attribute [RFC5888] in an "m="
>
> Again "part of"
>
>
> S 5.
> >      a semantics value [RFC5888] of "BUNDLE".  An identification-tag is
> >      assigned to each bundled "m=" section, and each identification-tag
> is
> >      listed in the SDP 'group:BUNDLE' attribute identification-tag list.
> >      Each "m=" section whose identification-tag is listed in the
> >      identification-tag list is associated with a given BUNDLE group.
> >
>
> I would put some of this text up before the attribute definition to
> explain why the attribute exists.
>
>
> S 7.
> >      rejected by the answerer, the previously negotiated addresses:ports,
> >      SDP parameters and characteristics (including those associated with
> a
> >      BUNDLE group) apply.  Hence, if an offerer generates an offer in
> >      order to negotiate a BUNDLE group, and the answerer rejects the
> >      offer, the BUNDLE group is not created.
> >
>
> Multiplexing?
>
>
> S 7.
> >      "m=" line proto value assigned to a bundled "m=" section.  Section 9
> >      defines additional considerations for RTP based media.  Section 6
> >      defines additional considerations for the usage of the SDP 'bundle-
> >      only' attribute.  Section 10 defines additional considerations for
> >      the usage of Interactive Connectivity Establishment (ICE)
> >      [I-D.ietf-ice-rfc5245bis] mechanism.
>
> Something bad happened here with your editor.
>
>
> S 7.
> >      the usage of Interactive Connectivity Establishment (ICE)
> >      [I-D.ietf-ice-rfc5245bis] mechanism.
> >
> >      Offers and answers can contain multiple BUNDLE groups.  The
> >      procedures in this section apply independently to a given BUNDLE
> >      group.
>
> This is pretty opaque. It's not that the address:port pair have been
> selected but rather that BUNDLE has been negotiated for that m=
> section (though of course the address:port being selected is a side
> effect of this).
>
>
>
>
> S 7.1.1.
> >      attribute values have been assigned to each bundled "m=" section.
> >
> >   7.1.1.  Connection Data (c=)
> >
> >      The "c=" line nettype value [RFC4566] associated with a bundled "m="
> >      section MUST be 'IN'.
>
> It seems like you should define bundled "m=" section. I believe it's
> one that appears in a bundle tag?
>
>
> S 7.1.1.
> >
> >   7.1.1.  Connection Data (c=)
> >
> >      The "c=" line nettype value [RFC4566] associated with a bundled "m="
> >      section MUST be 'IN'.
> >
>
> Huh? This is section 8.1.
>
> This whole paragraph is a mess. I would say
>
> "One consequence of these rules is that because SDP attributes which
> are appropriate only to some other m= section may appear in the m=
> section indicated by the BUNDLE-tag. For instance, the BUNDLE-tag may
> indicate a data channel but contain the 'rtcp-mux' attribute because
> that applies to an RTP m= section that is part of the BUNDLE group"
>
>
>
>
> S 7.1.2.
> >      with each "m=" section.
> >
> >      NOTE: Extensions to this specification can specify usage of the
> >      BUNDLE mechanism for other nettype and addrtype values than the ones
> >      listed above.
> >
>
> This sentence is ungrammatical. "In order to negotiate a BUNDLE group
> in an initial offer, the offerer MUST"
>
>
> S 7.1.3.
> >
> >      An offerer and answerer MUST include SDP attributes in every bundled
> >      "m=" section where applicable, following the normal offer/answer
> >      procedures for each attribute, with the following exceptions:
> >
> >      o  In the initial offerer, the offerer MUST NOT include IDENTICAL
> and
>
> initial offer
>
>
> S 7.1.3.
> >      "m=" section where applicable, following the normal offer/answer
> >      procedures for each attribute, with the following exceptions:
> >
> >      o  In the initial offerer, the offerer MUST NOT include IDENTICAL
> and
> >         TRANSPORT multiplexing category SDP attributes (BUNDLE
> attributes)
> >         in bundle-only "m=" sections.  The offerer MUST included such
>
> MUST include
>
>
> S 7.1.3.
> >         attributes in all other bundled "m=" sections.  In the initial
> >         offer each bundled "m=" line can contain a different set of
> BUNDLE
> >         attributes, and attribute values.  Once the offerer tagged "m="
> >         section has been selected, the BUNDLE attributes contained in the
> >         offerer tagged "m=" section will apply to each bundled "m="
> >         section within the BUNDLE group.
>
> I would reorder these, because the zero port is the main semantic.
>
>
> S 7.1.3.
> >         tagged "m=" section).  The offerer and answerer MUST NOT include
> >         such attributes in any other bundled "m=" section.  The BUNDLE
> >         attributes contained in the tagged "m=" section will apply to
> each
> >         bundled "m=" section within the BUNDLE group.
> >
> >      o  In an offer (initial or subsequent), or in an answer (initial or
>
> Why is this an "If"? There are only two choices: "unique" and "zero".
> Just put this graf up before the discussion of bundle-only and you can
> remove the conditional
>
>
> S 7.2.
> >      within the BUNDLE group does describe RTP-based media).
> >
> >   7.2.  Generating the Initial SDP Offer
> >
> >      When an offerer generates an initial offer, in order to negotiate a
> >      BUNDLE group, it MUST:
>
> I would say "believes" rather than "assumes"
>
>
> S 7.2.
> >      within the negotiated BUNDLE group, the offerer MUST:
> >
> >      o  Include an SDP 'bundle-only' attribute [Section 7.2.1] in the
> "m="
> >         section; and
> >
> >      o  Assign a zero port value to the "m=" section.
>
> Line breaks between the m= sections would help here.
>
>
> S 7.2.
> >      section, but does not include an SDP 'bundle-only' attribute in the
> >      "m=" section, it is an indication that the offerer wants to disable
> >      the "m=" section [Section 7.5.3].
> >
> >      [Section 7.2.2] and [Section 17.1] show an example of an initial
> >      offer.
>
> Comma not needed here. Also, this negative phrasing is hard to follow.
> I would say "MUST only ... if" here and below
>
>
> S 7.2.1.
> >      In the initial offer, the bundled "m=" section indicated by the
> >      offerer BUNDLE-tag is the suggested offerer tagged "m=" section.
> The
> >      address:port combination associated with the "m=" section will be
> >      used by the offerer for sending and receiving bundled media if the
> >      answerer selects the "m=" section as the offerer tagged "m=" section
> >      [Section 7.3.1].  In addition, if the answerer selects the "m="
>
> This bullet is unnecessary as it immediately follows from the
> preoceeding bukllet.
>
>
> S 7.2.1.
> >      section as the offerer tagged "m=" section, the BUNDLE attributes
> >      included in the "m=" section will be applied to each "m=" section
> >      within the negotiated BUNDLE group.
> >
> >      The offerer MUST NOT suggest a bundle-only "m=" section as the
> >      offerer tagged "m=" section.
>
> This isn't right, because each BUNDLE group has its own address:port,
> so instead "For each BUNDLE group" contained in the offer.
>
> More importantly, it's not the address:port that the answerer chooses,
> but rather the m= section. I.e.,
>
> o Determine the first m= section in the BUNDLE group which will be
> BUNDLEd in the answer
> o Select an answerer BUNDLE address:port
>
>
> S 7.3.
> >        a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
> >
> >   7.3.  Generating the SDP Answer
> >
> >      When an answerer generates an answer (initial or subsequent) that
> >      contains a BUNDLE group the following general SDP grouping framework
>
> Again, this isn't selecting the address:port but rather the m=section
>
>
> S 7.3.
> >         section using the procedures in Section 7.3.1.  In case of a
> >         subsequent answer, the offerer tagged "m=" section is indicated
> in
> >         the corresponding subsequent offer, and MUST NOT be changed by
> the
> >         answerer; and
> >
> >      o  Select the answerer tagged "m=" section [Section 7.3.2]; and
>
> This repeats text in S 8.3.
>
>
> S 7.3.
> >
> >      o  Include SDP attributes in the bundled "m=" sections following the
> >         rules in [Section 7.1.3]; and
> >
> >      o  Include an SDP 'group:BUNDLE' attribute in the answer; and
> >
>
> This text is baffling. As far as I can see, the first condition is
> "don't pick it as the head m= section if you intend to move it out".
> The second is some entirely different case. Can you rewrite it so it
> makes sense.
>
>
> S 7.3.
> >      group, it MUST:
> >
> >      o  Move the "m=" section out of the BUNDLE group [Section 7.3.3]; or
> >
> >      o  Reject the "m=" section [Section 7.3.4].
> >
>
> No comma
>
>
> S 7.3.1.
> >      value, but the "m=" section does not contain an SDP 'bundle-only'
> >      attribute, it is an indication that the offerer wants to disable the
> >      "m=" section [Section 7.5.3].
> >
> >   7.3.1.  Answerer Selection of Offerer tagged 'm=' section
> >
>
> This is the third time you have said this. If you want to say it here,
> say "Because ..., if"
>
>
> S 7.3.1.
> >      o  The answerer will not reject the "m=" section [Section 7.3.4];
> and
> >
> >      o  The "m=" section does not contain a zero port value.
> >
> >      If all of the criteria above are fulfilled, the answerer MUST select
> >      the "m=" section as the offerer tagged "m=" section.
>
> Same comment here as above. These are entirely different conditions.
>
>
> S 7.3.1.
> >      o  The "m=" section does not contain a zero port value.
> >
> >      If all of the criteria above are fulfilled, the answerer MUST select
> >      the "m=" section as the offerer tagged "m=" section.
> >
> >      If one or more of the criteria are not fulfilled, the answerer MUST
>
> "criteria... are"
>
>
> S 7.3.1.
> >      indicated by that identification-tag.  If there are no more
> >      identification-tags in the identification-tag list, the answerer
> MUST
> >      NOT create the BUNDLE group.  Unless the answerer rejects the whole
> >      offer, the answerer MUST apply the answerer procedures for moving an
> >      "m=" section out of a BUNDLE group [Section 7.3.3] or rejecting an
> >      "m=" section within a BUNDLE group [Section 7.3.4] to every bundled
>
> No comma
>
>
> S 7.3.2.
> >   7.3.2.  Answerer Selection of Answerer tagged 'm=' section
> >
> >      The answerer MUST select the "m=" section in that corresponds to the
> >      selected offerer tagged "m=" section in the corresponding offer
> >      [Section 7.3.1] as the answerer tagged "m=" section.  In the answer
> >      the answerer BUNDLE-tag indicates the answerer tagged "m=" section.
>
> I'm having trouble reading this paragraph. How do you select an m=
> section that correspond to the selected m= section.
>
>
> S 7.3.3.
> >      has been negotiated, a bundled "m=" section can not be moved out of
> >      the BUNDLE group in an answer.  Instead an offer is needed.
> >
> >      When the answerer generates an answer, in which it moves a bundled
> >      "m=" section out of a BUNDLE group, the answerer:
> >
>
> Please put line breaks in between m= sections here too
>
>
> S 7.3.3.
> >
> >      o  MUST include any applicable SDP attribute in the "m=" section,
> >         using the normal offer/answer procedures for the each Attributes;
> >         and
> >
> >      o  MUST NOT place the identification-tag associated with the "m="
>
> address:port, again. It's the m=section that's relevant.
>
>
> S 7.3.3.
> >         list associated with the BUNDLE group.
> >
> >      o  MUST NOT include an SDP 'bundle-only' attribute to the "m="
> >         section; and
> >
> >      Because an answerer is not allowed to move an "m=" section from one
>
> "each" -> "an given"
>
>
> S 7.3.4.
> >      another BUNDLE group [Section 7.5.1].
> >
> >   7.3.4.  Rejecting a Media Description in a BUNDLE Group
> >
> >      When an answerer wants to reject a bundled "m=" section in an
> answer,
> >      it MUST first check the following criterium:
>
> criterion would be more standard English. criterium generally refers
> to a bike race
>
>
> S 7.3.4.
> >         the procedures in [RFC3264]; and
> >
> >      o  MUST NOT place the identification-tag associated with the "m="
> >         section in the SDP 'group:BUNDLE' attribute identification-tag
> >         list associated with the BUNDLE group; and
> >
>
> Again it would make more sense to describe this as suggesting a new m=
> section.
>
>
> S 7.5.
> >
> >      o  Pick one bundled "m=" section as the offerer tagged "m=" section.
> >         The offerer can either pick the "m=" section that was previously
> >         selected by the answerer as the offerer tagged "m=" section, or
> >         pick another bundled "m=" section within the BUNDLE group; and
> >
>
> Are you sure disable -> port 0, as opposed to "inactive"
>
>
> S 7.5.1.
> >
> >   7.5.1.  Adding a Media Description to a BUNDLE group
> >
> >      When an offerer generates a subsequent offer, in which it wants to
> >      add a bundled "m=" section to a previously negotiated BUNDLE group,
> >      the offerer follows the procedures in [Section 7.5].  The offerer
>
> You should make clear that it's not possible to have an added m=
> section that the peer can take as bundled or not.
>
>
> S 8.1.
> >      correct protocols.
> >
> >   8.1.  STUN, DTLS, SRTP
> >
> >      Section 5.1.2 of [RFC5764] describes a mechanism to identify the
> >      protocol of a received packet among the STUN, DTLS and SRTP
> protocols
>
> Nit "the correct"
>
>
> S 9.2.
> >         If the RTCP packet is a feedback request that includes target
> >         SSRC(s), for each target SSRC that is found in the outgoing SSRC
> >         table, deliver a copy of the RTCP packet to the "m=" section
> >         associated with that SSRC.  PSFB and RTPFB types that are handled
> >         in this way include:
> >
>
> associates -> includes
>
>
> S 9.3.1.2.
> >      section, following the procedures for BUNDLE attributes
> >      [Section 7.1.3].  In addition, if the "m=" section that is selected
> >      as the offerer tagged "m=" section contained an SDP "rtcp-mux-only"
> >      attribute, the answerer MUST include an SDP "rtcp-mux-only"
> attribute
> >      in the answerer tagged "m=" section.
> >
>
> You should rewrite this graf and the one below to be about BUNDLED-
> ness not port assignment. I.e., if you are definitely bundled, willing
> to bundle, or not bundled.
>
>
> S 9.3.1.2.
> >
> >      If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
> >      negotiated in a previous offer/answer exchange, the answerer MUST
> >      include an SDP 'rtcp-mux' attribute in the answerer tagged "m="
> >      section .  It is not possible to disable RTP/RTCP multiplexing
> within
> >      a BUNDLE group.
>
> Same point here as above. Talking about address:port isn't helpful.
>
>
>