Negotiating Media Multiplexing Using the Session Description Protocol (SDP)
draft-ietf-mmusic-sdp-bundle-negotiation-54

[Ballot 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.

[Ballot comment]
Thank you for writing this.

The Abstract says "This specification updates RFC 3264, ...", but it doesn't say how it updates RFC7941. I think it would be helpful if it did...

[Ballot 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.

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

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3382









DETAIL
>      When an offerer generates an offer, in which it wants to add a new
>      bundled "m=" section, the offerer MUST:
> 
>      o  Assign the offerer BUNDLE address:port (previously selected
>        [Section 8.3.1] or newly suggested [Section 8.5.1]) to the added
>        "m=" section; or

IMPORTANT: 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.


>      o  When the BUNDLE transport has been established, ICE connectivity
>        checks and keep-alives only need to be performed for the BUNDLE
>        transport, instead of per individual "m=" section within the
>        BUNDLE group.
> 
>      o  In an offer, if the offer assigns a unique address:port to one or

IMPORTANT: This does not define how to interact with trickle ICE.

[Ballot comment]
> 
>    Negotiating Media Multiplexing Using the Session Description Protocol
>                                    (SDP)
>              draft-ietf-mmusic-sdp-bundle-negotiation-49.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.


>      to negotiate which "m=" sections will become part of a BUNDLE group.
>      Within a BUNDLE group, each "m=" section will use a BUNDLE transport
>      for sending and receiving bundled media.
> 
>      Within a BUNDLE group, each endpoint uses a single address:port
>      combination for sending and receiving bundled media.  The

Nit: "pair"?


>      combination for sending and receiving bundled media.  The
>      address:port combination is referred to as the BUNDLE address:port.
>      In addition to negotiating the BUNDLE group, the offerer and answerer
>      [RFC3264] use the BUNDLE extension to negotiate the BUNDLE
>      addresses:ports, one for the offerer (offerer BUNDLE address) and one
>      for the answerer (answerer BUNDLE address:port).  Once the offerer

Why is one of these called "address" and the other "address:port"?


>      can be used to request that specific media is only used if the "m="
>      section describing the media is kept within a BUNDLE group.
> 
>      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.

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.



>      can be used to request that specific media is only used if the "m="
>      section describing the media is kept within a BUNDLE group.
> 
>      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 section is kind of a laundry list. I think it would be helpful to
break it out conceptually. Specifically.

1.
2.
3.



> 
>      "m=" section: SDP bodies contain one or more media descriptions,
>      referred to as "m=" sections.  Each "m=" section is represented by an
>      SDP "m=" line, and zero or more SDP attributes associated with the
>      "m=" line.  A local address:port combination is assigned to each "m="
>      section.

Was this intended to be a bullet?


>      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
>        dialog when the Session Initiation Protocol (SIP) [RFC3261] is
>        used to carry SDP), in which the offerer indicates that it wants
>        to create a given 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.


>      The BUNDLE extension is indicated using an SDP 'group' attribute with
>      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.

How about "is part of" instead of "associated with"


>      Each "m=" section whose identification-tag is listed in the
>      identification-tag list is associated with a given BUNDLE group.
> 
>      SDP bodies can contain multiple BUNDLE groups.  Any given bundled
>      "m=" section MUST NOT be associated with more than one BUNDLE group
>      at any given time.

Again "part of"


>      assign a zero port value to the "m=" section.  According to [RFC3264]
>      an answerer will reject such an "m=" section.  By including an SDP
>      'bundle-only' attribute in such an "m=" section, the offerer can
>      request that the answerer accepts the "m=" section if the answerer
>      supports the BUNDLE extension, and if the answerer keeps the "m="
>      section within the associated BUNDLE group.

I would put some of this text up before the attribute definition to
explain why the attribute exists.


> 
>      SDP offers and answers can contain multiple BUNDLE groups.  The
>      procedures in this section apply independently to a given BUNDLE
>      group.
> 
>  8.1.  Multiplex Category Considerations

Multiplexing?


>      When a BUNDLE group is initially negotiated, and a unique
>      address:port is assigned to each bundled "m=" section (excluding any
>      bundle-only "m=" section) in the initial offer [Section 8.2], any
>      IDENTICAL and TRANSPORT mux category SDP attributes included in the
>      BUNDLE group MUST explicitly be included in each bundled
>      "m=a€œ section (excluding any bundle-only "m=" sections).

Something bad happened here with your editor.


>      BUNDLE group MUST explicitly be included in each bundled
>      "m=a€œ section (excluding any bundle-only "m=" sections).
> 
>      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

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).




>      The semantics of some SDP attributes only apply to specific types of
>      media.  For example, the semantics of the SDP 'rtcp-mux' and SDP
>      'rtcp-mux-only' attributes only apply to "m=" sections describing
>      RTP-based media.  However, as described in Section 8.1, there are
>      cases where IDENTICAL and TRANSPORT mux category SDP attributes are
>      only included in the "m=" sections indicated by the BUNDLE-tag.  That

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"




>      type of media.
> 
>  8.2.  Generating the Initial SDP Offer
> 
>      When an offerer generates an initial offer, to negotiate a BUNDLE
>      group, it MUST:

This sentence is ungrammatical. "In order to negotiate a BUNDLE group
in an initial offer, the offerer MUST"


>      within the BUNDLE group, the offerer MUST:
> 
>      o  Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m="
>        section; and
> 
>      o  Assign a zero port value to the "m=" section.

I would reorder these, because the zero port is the main semantic.


> 
>      NOTE: If the offerer assigns unique addresses:ports to multiple
>      bundled "m=" sections, the offerer needs to be prepared to receive
>      bundled media on each unique address:port, until it receives the
>      associated answer and finds out which address:port combination has
>      been selected as the offerer BUNDLE-address.

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


> 
>      It is RECOMMENDED that the offerer assigns the suggested offerer
>      BUNDLE address:port to a bundled "m=" section that the offerer
>      assumes it is unlikely that the answerer will reject, or move out of
>      the BUNDLE group.  How such assumption is made is outside the scope
>      of this document.

I would say "believes" rather than "assumes"


>        b=AS:1000
>        a=mid:bar
>        a=rtcp-mux
>        a=rtpmap:31 H261/90000
>        a=rtpmap:32 MPV/90000
>        a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid

Line breaks between the m= sections would help here.


> 
>      When an answerer generates an answer that contains a BUNDLE group,
>      the following general SDP grouping framework restrictions, defined in
>      [RFC5888], also apply to the BUNDLE group:
> 
>      o  The answerer MUST NOT include a BUNDLE group in the answer, unless

Comma not needed here. Also, this negative phrasing is hard to follow.
I would say "MUST only ... if" here and below


>      o  The answerer MUST NOT include an "m=" section within a BUNDLE
>        group, unless the offerer requested the "m=" section to be within
>        that BUNDLE group in the corresponding offer.
> 
>      o  If the answer contains multiple BUNDLE groups, the answerer MUST
>        NOT move an "m=" section from one BUNDLE group to another.

This bullet is unnecessary as it immediately follows from the
preoceeding bukllet.


> 
>      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].

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


>      o  The answerer will not reject the "m=" section [Section 8.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 suggested offerer BUNDLE address:port.

Again, this isn't selecting the address:port but rather the m=section


>      bundled "m=" section the answerer MUST assign a zero port value and
>      include an SDP 'bundle-only' attribute.
> 
>      The answerer MUST NOT assign an answerer BUNDLE address:port to an
>      "m=" section that is not within the BUNDLE group, or to an "m="
>      section that is within another BUNDLE group.

This repeats text in S 8.3.


>      group in an answer, it MUST first check the following criteria:
> 
>      o  In the corresponding offer, an offerer BUNDLE address:port
>        (previously selected [Section 8.3.1] or newly suggested
>        [Section 8.5.1]) has been assigned to the "m=" section by the
>        offerer; or

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.


>      either reject the whole offer, reject each bundled "m=" section
>      within the BUNDLE group [Section 8.3.4], or keep the "m=" section
>      within the BUNDLE group in the answer and later create an offer where
>      the "m=" section is moved out of the BUNDLE group [Section 8.5.3].
> 
>      When the answerer generates an answer, in which it moves a bundled

No comma


> 
>      o  MUST NOT assign an SDP 'bundle-only' attribute to the "m="
>        section.
> 
>      An answerer MUST NOT move an "m=" section from one BUNDLE group to
>      another within an answer.  If the answerer wants to move an "m="

This is the third time you have said this. If you want to say it here,
say "Because ..., if"


>      it MUST first check the following criteria:
> 
>      o  In the corresponding offer, an offerer BUNDLE address:port
>        (previously selected [Section 8.3.1] or newly suggested
>        [Section 8.5.1]) has been assigned to the "m=" section by the
>        offerer.

Same comment here as above. These are entirely different conditions.


>      o  In the corresponding offer, an offerer BUNDLE address:port
>        (previously selected [Section 8.3.1] or newly suggested
>        [Section 8.5.1]) has been assigned to the "m=" section by the
>        offerer.
> 
>      If the criteria above is fulfilled, the answerer can not reject the

"criteria... are"


>      reject the whole offer, reject each bundled "m=" section within the
>      BUNDLE group, or keep the "m=" section within the BUNDLE group in the
>      answer and later create an offer where the "m=" section is disabled
>      within the BUNDLE group [Section 8.5.4].
> 
>      When an answerer generates an answer, in which it rejects a bundled

No comma


>        m=video 0 RTP/AVP 32
>        b=AS:1000
>        a=mid:bar
>        a=bundle-only
>        a=rtpmap:32 MPV/90000
>        a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid

Please put line breaks in between m= sections here too


>  8.4.  Offerer Processing of the SDP Answer
> 
>      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,

address:port, again. It's the m=section that's relevant.


>      bundled "m=" section.
> 
>      NOTE: As the answerer might reject one or more bundled "m=" sections,
>      or move a bundled "m=" section out of a BUNDLE group, each bundled
>      "m=" section in the offer might not be indicated as bundled in the
>      answer.

"each" -> "an given"


>      When the offerer generates a subsequent offer, the offerer BUNDLE-tag
>      MUST represent the bundled "m=" section to which the offerer BUNDLE
>      address:port (previously negotiated or newly suggested) has been
>      assigned.
> 
>  8.5.1.  Suggesting a New Offerer BUNDLE Address:Port

Again it would make more sense to describe this as suggesting a new m=
section.


>      section out of a BUNDLE group.
> 
>  8.5.4.  Disabling a Media Description in a BUNDLE Group
> 
>      When an offerer generates an offer, in which it wants to disable a
>      bundled "m=" section, the offerer:

Are you sure disable -> port 0, as opposed to "inactive"


>      configuration and packetization.
>      [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
>      attribute values are required to be identical for all codecs that use
>      the same payload type value.
> 
>  10.2.  Associating RTP/RTCP Streams with Correct SDP Media Description

Nit "the correct"


>      "m=" sections), following the procedures for IDENTICAL mux category
>      attributes in Section 8.1.  In addition, the offerer MAY include an
>      SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in a
>      RTP-based bundled "m=" section.
> 
>      NOTE: Whether the offerer associates the SDP 'rtcp-mux-only'

associates -> includes


>        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.

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.


>      Support and usage of ICE mechanism together with the BUNDLE extension
>      is OPTIONAL, and the procedures in this section only apply when the
>      ICE mechanism is used.  Note that applications might mandate usage of
>      the ICE mechanism even if the BUNDLE extension is not used.
> 
>  11.1.  SDP Offer/Answer Procedures

Same point here as above. Talking about address:port isn't helpful.

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3382









DETAIL
>      When an offerer generates an offer, in which it wants to add a new
>      bundled "m=" section, the offerer MUST:
> 
>      o  Assign the offerer BUNDLE address:port (previously selected
>        [Section 8.3.1] or newly suggested [Section 8.5.1]) to the added
>        "m=" section; or

IMPORTANT: 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.


>      o  When the BUNDLE transport has been established, ICE connectivity
>        checks and keep-alives only need to be performed for the BUNDLE
>        transport, instead of per individual "m=" section within the
>        BUNDLE group.
> 
>      o  In an offer, if the offer assigns a unique address:port to one or

IMPORTANT: This does not define how to interact with trickle ICE.

[Ballot comment]
> 
>    Negotiating Media Multiplexing Using the Session Description Protocol
>                                    (SDP)
>              draft-ietf-mmusic-sdp-bundle-negotiation-49.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.


>      to negotiate which "m=" sections will become part of a BUNDLE group.
>      Within a BUNDLE group, each "m=" section will use a BUNDLE transport
>      for sending and receiving bundled media.
> 
>      Within a BUNDLE group, each endpoint uses a single address:port
>      combination for sending and receiving bundled media.  The

Nit: "pair"?


>      combination for sending and receiving bundled media.  The
>      address:port combination is referred to as the BUNDLE address:port.
>      In addition to negotiating the BUNDLE group, the offerer and answerer
>      [RFC3264] use the BUNDLE extension to negotiate the BUNDLE
>      addresses:ports, one for the offerer (offerer BUNDLE address) and one
>      for the answerer (answerer BUNDLE address:port).  Once the offerer

Why is one of these called "address" and the other "address:port"?


>      can be used to request that specific media is only used if the "m="
>      section describing the media is kept within a BUNDLE group.
> 
>      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.

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.



>      can be used to request that specific media is only used if the "m="
>      section describing the media is kept within a BUNDLE group.
> 
>      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 section is kind of a laundry list. I think it would be helpful to
break it out conceptually. Specifically.

1.
2.
3.



> 
>      "m=" section: SDP bodies contain one or more media descriptions,
>      referred to as "m=" sections.  Each "m=" section is represented by an
>      SDP "m=" line, and zero or more SDP attributes associated with the
>      "m=" line.  A local address:port combination is assigned to each "m="
>      section.

Was this intended to be a bullet?


>      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
>        dialog when the Session Initiation Protocol (SIP) [RFC3261] is
>        used to carry SDP), in which the offerer indicates that it wants
>        to create a given 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.


>      The BUNDLE extension is indicated using an SDP 'group' attribute with
>      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.

How about "is part of" instead of "associated with"


>      Each "m=" section whose identification-tag is listed in the
>      identification-tag list is associated with a given BUNDLE group.
> 
>      SDP bodies can contain multiple BUNDLE groups.  Any given bundled
>      "m=" section MUST NOT be associated with more than one BUNDLE group
>      at any given time.

Again "part of"


>      assign a zero port value to the "m=" section.  According to [RFC3264]
>      an answerer will reject such an "m=" section.  By including an SDP
>      'bundle-only' attribute in such an "m=" section, the offerer can
>      request that the answerer accepts the "m=" section if the answerer
>      supports the BUNDLE extension, and if the answerer keeps the "m="
>      section within the associated BUNDLE group.

I would put some of this text up before the attribute definition to
explain why the attribute exists.


> 
>      SDP offers and answers can contain multiple BUNDLE groups.  The
>      procedures in this section apply independently to a given BUNDLE
>      group.
> 
>  8.1.  Multiplex Category Considerations

Multiplexing?


>      When a BUNDLE group is initially negotiated, and a unique
>      address:port is assigned to each bundled "m=" section (excluding any
>      bundle-only "m=" section) in the initial offer [Section 8.2], any
>      IDENTICAL and TRANSPORT mux category SDP attributes included in the
>      BUNDLE group MUST explicitly be included in each bundled
>      "m=a€œ section (excluding any bundle-only "m=" sections).

Something bad happened here with your editor.


>      BUNDLE group MUST explicitly be included in each bundled
>      "m=a€œ section (excluding any bundle-only "m=" sections).
> 
>      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

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).




>      The semantics of some SDP attributes only apply to specific types of
>      media.  For example, the semantics of the SDP 'rtcp-mux' and SDP
>      'rtcp-mux-only' attributes only apply to "m=" sections describing
>      RTP-based media.  However, as described in Section 8.1, there are
>      cases where IDENTICAL and TRANSPORT mux category SDP attributes are
>      only included in the "m=" sections indicated by the BUNDLE-tag.  That

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"




>      type of media.
> 
>  8.2.  Generating the Initial SDP Offer
> 
>      When an offerer generates an initial offer, to negotiate a BUNDLE
>      group, it MUST:

This sentence is ungrammatical. "In order to negotiate a BUNDLE group
in an initial offer, the offerer MUST"


>      within the BUNDLE group, the offerer MUST:
> 
>      o  Include an SDP 'bundle-only' attribute [Section 8.2.1] in the "m="
>        section; and
> 
>      o  Assign a zero port value to the "m=" section.

I would reorder these, because the zero port is the main semantic.


> 
>      NOTE: If the offerer assigns unique addresses:ports to multiple
>      bundled "m=" sections, the offerer needs to be prepared to receive
>      bundled media on each unique address:port, until it receives the
>      associated answer and finds out which address:port combination has
>      been selected as the offerer BUNDLE-address.

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


> 
>      It is RECOMMENDED that the offerer assigns the suggested offerer
>      BUNDLE address:port to a bundled "m=" section that the offerer
>      assumes it is unlikely that the answerer will reject, or move out of
>      the BUNDLE group.  How such assumption is made is outside the scope
>      of this document.

I would say "believes" rather than "assumes"


>        b=AS:1000
>        a=mid:bar
>        a=rtcp-mux
>        a=rtpmap:31 H261/90000
>        a=rtpmap:32 MPV/90000
>        a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid

Line breaks between the m= sections would help here.


> 
>      When an answerer generates an answer that contains a BUNDLE group,
>      the following general SDP grouping framework restrictions, defined in
>      [RFC5888], also apply to the BUNDLE group:
> 
>      o  The answerer MUST NOT include a BUNDLE group in the answer, unless

Comma not needed here. Also, this negative phrasing is hard to follow.
I would say "MUST only ... if" here and below


>      o  The answerer MUST NOT include an "m=" section within a BUNDLE
>        group, unless the offerer requested the "m=" section to be within
>        that BUNDLE group in the corresponding offer.
> 
>      o  If the answer contains multiple BUNDLE groups, the answerer MUST
>        NOT move an "m=" section from one BUNDLE group to another.

This bullet is unnecessary as it immediately follows from the
preoceeding bukllet.


> 
>      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].

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


>      o  The answerer will not reject the "m=" section [Section 8.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 suggested offerer BUNDLE address:port.

Again, this isn't selecting the address:port but rather the m=section


>      bundled "m=" section the answerer MUST assign a zero port value and
>      include an SDP 'bundle-only' attribute.
> 
>      The answerer MUST NOT assign an answerer BUNDLE address:port to an
>      "m=" section that is not within the BUNDLE group, or to an "m="
>      section that is within another BUNDLE group.

This repeats text in S 8.3.


>      group in an answer, it MUST first check the following criteria:
> 
>      o  In the corresponding offer, an offerer BUNDLE address:port
>        (previously selected [Section 8.3.1] or newly suggested
>        [Section 8.5.1]) has been assigned to the "m=" section by the
>        offerer; or

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.


>      either reject the whole offer, reject each bundled "m=" section
>      within the BUNDLE group [Section 8.3.4], or keep the "m=" section
>      within the BUNDLE group in the answer and later create an offer where
>      the "m=" section is moved out of the BUNDLE group [Section 8.5.3].
> 
>      When the answerer generates an answer, in which it moves a bundled

No comma


> 
>      o  MUST NOT assign an SDP 'bundle-only' attribute to the "m="
>        section.
> 
>      An answerer MUST NOT move an "m=" section from one BUNDLE group to
>      another within an answer.  If the answerer wants to move an "m="

This is the third time you have said this. If you want to say it here,
say "Because ..., if"


>      it MUST first check the following criteria:
> 
>      o  In the corresponding offer, an offerer BUNDLE address:port
>        (previously selected [Section 8.3.1] or newly suggested
>        [Section 8.5.1]) has been assigned to the "m=" section by the
>        offerer.

Same comment here as above. These are entirely different conditions.


>      o  In the corresponding offer, an offerer BUNDLE address:port
>        (previously selected [Section 8.3.1] or newly suggested
>        [Section 8.5.1]) has been assigned to the "m=" section by the
>        offerer.
> 
>      If the criteria above is fulfilled, the answerer can not reject the

"criteria... are"


>      reject the whole offer, reject each bundled "m=" section within the
>      BUNDLE group, or keep the "m=" section within the BUNDLE group in the
>      answer and later create an offer where the "m=" section is disabled
>      within the BUNDLE group [Section 8.5.4].
> 
>      When an answerer generates an answer, in which it rejects a bundled

No comma


>        m=video 0 RTP/AVP 32
>        b=AS:1000
>        a=mid:bar
>        a=bundle-only
>        a=rtpmap:32 MPV/90000
>        a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid

Please put line breaks in between m= sections here too


>  8.4.  Offerer Processing of the SDP Answer
> 
>      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,

address:port, again. It's the m=section that's relevant.


>      bundled "m=" section.
> 
>      NOTE: As the answerer might reject one or more bundled "m=" sections,
>      or move a bundled "m=" section out of a BUNDLE group, each bundled
>      "m=" section in the offer might not be indicated as bundled in the
>      answer.

"each" -> "an given"


>      When the offerer generates a subsequent offer, the offerer BUNDLE-tag
>      MUST represent the bundled "m=" section to which the offerer BUNDLE
>      address:port (previously negotiated or newly suggested) has been
>      assigned.
> 
>  8.5.1.  Suggesting a New Offerer BUNDLE Address:Port

Again it would make more sense to describe this as suggesting a new m=
section.


>      section out of a BUNDLE group.
> 
>  8.5.4.  Disabling a Media Description in a BUNDLE Group
> 
>      When an offerer generates an offer, in which it wants to disable a
>      bundled "m=" section, the offerer:

Are you sure disable -> port 0, as opposed to "inactive"


>      configuration and packetization.
>      [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
>      attribute values are required to be identical for all codecs that use
>      the same payload type value.
> 
>  10.2.  Associating RTP/RTCP Streams with Correct SDP Media Description

Nit "the correct"


>      "m=" sections), following the procedures for IDENTICAL mux category
>      attributes in Section 8.1.  In addition, the offerer MAY include an
>      SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in a
>      RTP-based bundled "m=" section.
> 
>      NOTE: Whether the offerer associates the SDP 'rtcp-mux-only'

associates -> includes


>        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.

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.


>      Support and usage of ICE mechanism together with the BUNDLE extension
>      is OPTIONAL, and the procedures in this section only apply when the
>      ICE mechanism is used.  Note that applications might mandate usage of
>      the ICE mechanism even if the BUNDLE extension is not used.
> 
>  11.1.  SDP Offer/Answer Procedures

Same point here as above. Talking about address:port isn't helpful.

[Ballot comment]
Thanks for doing this work. It's important.

I wonder if it's worth adding a mention of https://tools.ietf.org/html/rfc7657 as an Informational reference, because bundling makes it easier for you to shoot yourself in the foot by using different DSCP codepoints for different packets carried on a single 5-tuple.

If there's a better document to point that out to people who are considering using bundling for their applications, that's a fine answer ...

[Ballot comment]
8.1.  Multiplex Category Considerations

  When a BUNDLE group is initially negotiated, and a unique
  address:port is assigned to each bundled "m=" section (excluding any
  bundle-only "m=" section) in the initial offer [Section 8.2], any
  IDENTICAL and TRANSPORT mux category SDP attributes included in the
  BUNDLE group MUST explicitly be included in each bundled
  "m=a€œ section (excluding any bundle-only "m=" sections).

HTML encoding is not really readable in plain text.

Please add a reference on first mention of UTF-8.

[Ballot comment]
Should the NOTE in Section 8.5.2 explicitly reaffirm that only one
m= section within the BUNDLE group can have the offerer BUNDLE
address:port, regardless of whether it is a new or preexisting
address:port?  That is, that you cannot use an existing BUNDLE
address:port and offer a new one in the same BUNDLE group.


When we talk about how the offerer must move a section out of one
BUNDLE group and then generate a second offer where that section is
added to the other BUNDLE group (this occurs in several places,
IIRC), do we need to say anything about the offer that moves the
section out of the first BUNDLE group must be accepted before the
second offer is offered?


In Section 10.2, page 23, I appreciate the description of the
payload type/m= mapping used by legacy implementations, but I worry
that there may not be sufficient description of when an SDP participant
should take the care to ensure the uniqueness of the mapping (versus
when the legacy considerations can be ignored).


Does the first paragraph of Section 10.3.1.2 imply that an
implementation of BUNDLE must also implement rtcp-mux-only?


Should the RTP SDES header extension URI be mentioned somewhere
other than the IANA considerations?


In Section 17:
  The security considerations of "RTP Header Extension for the RTP
  Control Protocol (RTCP) Source Description Items" [RFC7941] requires
  that when RTCP is confidentiality protected, and that any SDES RTP
  header extension carrying an SDES item, such as the MID RTP header
  extension, is also protected using commensurate strength algorithms.
"that when [...], and that" seems the wrong construction here; I
think that just "that when [...]," is the intended meaning.

The following Last Call announcement was sent out (ends 2018-02-14):

From: The IESG
To: IETF-Announce
CC: fandreas@cisco.com, ben@nostrum.com, mmusic-chairs@ietf.org, mmusic@ietf.org, draft-ietf-mmusic-sdp-bundle-negotiation@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Negotiating Media Multiplexing Using the Session Description Protocol (SDP)) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document: - 'Negotiating Media
Multiplexing Using the Session Description Protocol
  (SDP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This specification defines a new Session Description Protocol (SDP)
  Grouping Framework extension, 'BUNDLE'.  The extension can be used
  with the SDP Offer/Answer mechanism to negotiate the usage of a
  single transport (5-tuple) for sending and receiving media described
  by multiple SDP media descriptions ("m=" sections).  Such transport
  is referred to as a BUNDLE transport, and the media is referred to as
  bundled media.  The "m=" sections that use the BUNDLE transport form
  a BUNDLE group.

  This specification updates RFC 3264, 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 specification defines a new RTP Control Protocol (RTCP) source
  description (SDES) item and a new RTP header extension that van be
  used to correlate bundled RTP/RTCP packets with their appropriate
  "m=" section.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-holmberg-mmusic-sdp-multiplex-negotiation: Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers (None - )

This is my AD Evaluation of  draft-ietf-mmusic-sdp-bundle-negotiation-47.

First, thank you for all the work on this. I know this has been a difficult process. I do have a few substantive comments and a number of editorial comments. I would like to resolve the substantive comments and make at least a pass over the editorial comments prior to IETF Last Call.

——————————

*** Substantive Comments ***

- boilerplate: I assume the pre-2008 boilerplate is present due to the extensive quoted text from RFC 3264. I note that it is not usually necessary to quote large amounts of text from an RFC in order to update it. I don’t expect a change in the update approach this late in the process, but I suggest that for future drafts people try to avoid creating the need for the pre-2008 boilerplate.

- section 8, first paragraph after bullet list: I’m confused as to whether this talks about the initial offer or a subsequent offer. the comment about the “previously negotiated SDP parameters” seems to suggest the latter. I suspect this is intended to cover all offers, in which case it needs clarification.

-8.3.3: IIUC, the criteria mean that the only m= sections that the answerer can move out of the bundle are those that have unique addresses but are not listed first in the group attribute. If that is correct, a sentence or two to say that would be helpful.

-8.5, first paragraph. IIUC, it’s not syntactically possible to assign more than one m= section the bundle address, since only one can be first in the group attribute. If that is correct, the MUST here is a statement of fact. Or am I missing something?

-9: There are several assertions that in order to do something you MUST have a spec saying how to do it. Formally, I think the requirement is really that you MUST NOT do that thing unless such a spec exists. (2119/8174 keywords are normally about implementation behavior.)

-10.2,
— paragraph 7: What implementations are we talking about that may not follow the requirements to include the tag in RTP/RTCP? Early implementations of this draft? Something else? As it is, it seems like we are talking about implementations that do not follow this spec. That makes the statement “  … In this situation, each "m=" section MUST use unique payload type values…” problematic, as it seems to be putting requirements on implementations that do not follow this draft in the first place.

— '  Therefore, when processing a compound packet, any contained SDES packet MUST be handled first.
      Note that this is a change from [RFC3550] Section 6.1 which
      states that "Each individual RTCP packet in the compound packet
      may be processed independently with no requirements upon the order
      or combination of packets”.’

Doesn’t this require an update of 3550? It’s not merely a tightening of requirements, it’s a reversal of guidance from that document when used in this context.

-10.3.1.3, last paragraph: What is the expected behavior when that "protocol error" occurs?

-15.2, last paragraph: Is it worth recommending against patterns which could be used as persistent identifiers, even if they don’t expressly identify a person or application?

-16.3: Please use the IESG and “iesg@ietf.org” as the contact for the IANA registrations.

-17, 2nd paragraph:
— Again, is it worth mentioning the risk of persistent identifiers?
—  “… SHOULD be 3 bytes or less, to allow them to efficiently fit into the MID RTP header extension.”
It seems like that requirement belongs in 15.2

-17, last paragraph: Doesn’t that require an update to 7941

-18: Would it make sense to have one of the examples use media-level c= lines?


*** Editorial Comments and nits ***

- Terminology issues: I think some of the terminology here will confuse readers who are new to the concepts. In particular, IIUC, “bundle address” means address + port. I think many readers will fall back to assuming that address means IP address. (Especially when we talk about a “unique address” assigned to an m= section, when much of the time that may just mean a unique port.)

I also find defining the term “Bundle Tag” to mean the first tag in the list to be confusing. It may be easier to just refer to the “first tag in the group list”.

— Examples: Any chance of some of the examples showing IPv6? I suspect it’s a trivial change for at least some examples, since they use domain names.

-abstract: The abstract seems longer and more detailed than strictly necessary. The first two sentences along with a brief mention of the update to 3264 and the SDES item/RTP header extension would be sufficient.

-Section 1,
— first paragraph: This sort of jumps into things without much context. (e.g. that we are talking about media sessions signaled using SDP offer/answer.”
s/consume/consumes
— paragraphs 5-9: Most of the instances of the word “also” are unneeded.
— paragraphs 7 and 9: These paragraphs both talk about updates to 3264; it would be better to keep them together.
— 2nd to last paragraph, “The procedures in this specification apply independently to a given BUNDLE group.” : I don’t understand what that sentence is trying to convey.

- Section 2: The terminology list would be more readable as a bullet list or hanging indent list.

-3: There are at least one lower case “must” and a number of lower case “shoulds”. Please consider using the boilerplate from RFC 8174, or verify that the lower case versions are not intended to be keywords.

-5:
— First paragraph: inconsistent tense. Please consider s/ “ … section will use …” / “… section uses…”
— 2nd paragraph: The citation to RFC5888 looks like a reference for the “BUNDLE” semantic value, rather than for the grouping framework. Please consider something to the effect of the following:
OLD:
    The BUNDLE extension is indicated using an SDP ’group’ attribute with a "BUNDLE" semantics value [RFC5888].
NEW:
    The BUNDLE extension is indicated using an SDP ’group’ attribute with a semantics value [RFC5888] of "BUNDLE”.

- Section 8.1:
— Consider moving this section to later in the offer/answer details. I think it would be easier for a reader to understand this section after they have some more general context.
— Title: Spell out “Multiplex” in the title.
— First Paragraph: The wording could be taken to mean that all attributes with a mux category of IDENTICAL or TRANSPORT must be included in the first place. I think the point is that, if they are present, they must be included in each m= section. I suggest something like the following:
OLD:
  … IDENTICAL and TRANSPORT mux category SDP attributes MUST explicitly be included in each bundled "m=“ section ...
NEW:
  … Any IDENTICAL and TRANSPORT mux category SDP attributes included in the BUNDLE group MUST explicitly be included in each bundled "m=“ section …

-8.2.1, first paragraph:
— The phrase “represented by the … BUNDLE-tag” occurs repeatedly throughout the document. The use of “represented” there seems awkward. I think “indicated” would be a better word choice.
— should “offerer BUNDLE address” be “offerer suggested BUNDLE address”?

-8.5.2: Should “add a bundled m= section” be “add a _new_ bundled m= section”?

-9:
— first paragraph: “ … different protocols on top of the transport-layer protocol …”
Upper layer protocols?
— Last paragraph: This paragraph seems mostly (or entirely) redundant to section 9.1.

-10.2:

— " RTCP packets for which no appropriate "m=" section can be identified
  MUST be processed as usual by the RTP layer, updating the metadata
  associated with the corresponding RTP streams, but are not passed to
  any "m=" section.”

I don’t think things gets passed to sections of SDP. What does this really talk about?

— “ Rules for additional processing of the various types of RTCP packets
  are explained below.”

Should that say “Additional rules for processing…”?

-11, 2nd bullet: " previously selected [Section 8.3.1 ] or new suggested [ Section 8.5.1]”
s/new/newly

— last paragraph: It may be worth clarifying that this doesn't change any requirement specified by the application or signaling protocol. For example, WebRTC still requires ICE even though bundle is used.

11.1:
— 2nd paragraph: “ previously selected or new suggested “
s/new/newly

— 3rd paragraph: Construct of the form of “MUST only” can be ambiguous. Please consider restating in the form of a MUST NOT construction. (For example, “MUST only do foo when….” can be interpreted as “MUST NOT do foo unless…” or “MUST NOT do anything but foo when…”  [Note: This construct repeats several times in the next few sections. ]

-19, 3rd paragraph from end: It’s seems a bit odd to thank a co-author (Cullen) for text contributions :-)

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. The title page shows Standards Track as the Intended Status, which is appropriate given the impact on other standards track documents.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'.  The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections).  Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media.  The "m=" sections that use the BUNDLE transport form a BUNDLE group.

To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled.  The specification also updates RFC 3264, 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.

When RTP-based media is used, there are multiple ways to correlate bundled RTP packets with the appropriate "m=" section.  This specification defines a new Real-time Transport Control Protocol (RTCP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/RTCP packets with a specific "m=" section.


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The mechanism has been worked on since 2011, and it has been a WG document since 2012. Originally, there were different approaches to solving the problem which resulted in significant disagreements and discussion in the WG about the best way forward. Ultimately, a compromise proposal agreeable to all parties was reached (as reflected in the document), and it has been in place for quite a while with very solid consensus. There has been a number of technical details to sort out, and the document has also received a lot of editorial feedback. The current version addresses all known technical issues as well as editorial comments that can reasonably be addressed (while respecting previous WG discussions/consensus and also considering sometimes conflicting editorial comments).


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The protocol is an important part of the RTCWeb suite of specifications and there are existing implementations of earlier versions of the specification.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Flemming Andreasen is the Document Shepherd
Ben Campbell is the Responsile Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed the current version(s) and several earlier versions of the document in detail. A number of WG participants have done the same. The document is ready to proceed.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No such concern.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Each author has confirmed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

As described above, there is solid WG concensus behind the document, especially as it relates to the technical contents. There has been some editorial comments related to overall readability, however we believe those have been addressed at this point. The recent version(s) of the document were out for review by the WG (once again) and did not receive any further feedback.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document contains a disclaimer for pre-RFC5378 work since it includes material from RFC 3264.

ID-nits checks produces 2 comments related to references, both of which are false positives.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

[I-D.ietf-ice-rfc5245bis] was recently submitted for publication.
[I-D.ietf-mmusic-sdp-mux-attributes] is in the RFC Editor's Queue
[I-D.ietf-mmusic-mux-exclusive] is in the RFC Editor's Queue
[I-D.ietf-mmusic-ice-sip-sdp] has completed WGLC


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The document updates RFC 3264, which is indicated on the title page and called out in the abstract and the introduction.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

IANA considerations have been reviewed. Registrations are consistent with the main body of the document and the relevant registry requirements.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A