Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - text that can be removed

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Dec 2017 14:02:37 +0000

…and the following can be removed, in my opinion:

    "Multiplexing characteristics of SDP attributes are described in
     [I-D.ietf-mmusic-sdp-mux-attributes].  Various SDP attribute
     multiplexing categories are introduced there.”

It is enough to say that "the mux category
[I-D.ietf-mmusic-sdp-mux-attributes] is this and that".

Regards,

Christer

On 04/12/17 15:59, "mmusic on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>Hi,
>
>The draft also repeats “data channel with Offer/Answer” many times. I
>think it is enough to say once that the procedures are for negotiating
>data channels using offer/answer. No need to keep repeating it…
>
>Regards,
>
>Christer
>
>
>On 04/12/17 15:56, "Roni Even" <[email-masked]> wrote:
>
>>Hi Christer,
>>This looks to me like redundant text.
>>Roni
>>
>>> -----Original Message-----
>>> From: Christer Holmberg [mailto:[email-masked]]
>>> Sent: יום ב 04 דצמבר 2017 15:51
>>> To: Roni Even; [email-masked]
>>> Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-
>>> sdpneg-14.txt - glare question
>>> 
>>> Hi,
>>> 
>>> Section says:
>>> 
>>>  "If a peer receives an SDP offer before starting to send a new SDP
>>>offer  with
>>> data channels that are to be SDP offer/answer negotiated, or  loses an
>>>SDP
>>> offer glare resolution procedure in this case, it MUST  wait until the
>>>ongoing
>>> SDP offer/answer completes before resuming the  SDP offer/answer
>>> negotiation procedure."
>>> 
>>> 
>>> Now, assuming I understand the text correctly, it simply repeats
>>>generic O/A
>>> glare procedures.
>>> 
>>> Or, is there supposed to be something data channel specific?
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 04/12/17 08:07, "mmusic on behalf of Roni Even"
>>> <[email-masked] on behalf of [email-masked]> wrote:
>>> 
>>> >Hi,
>>> >
>>> >This new revision addresses all nits pointed out by the idnits tool.
>>> >As a new editor, I looked at the MMUSIC mail archive and as far as I
>>> >can tell there were no open issues from the list.
>>> >
>>> >Thanks
>>> >Roni Even
>>> >
>>> >
>>> >-----Original Message-----
>>> >From: mmusic [mailto:[email-masked]] On Behalf Of
>>> >[email-masked]
>>> >Sent: יום א 03 דצמבר 2017 18:28
>>> >To: [email-masked]
>>> >Cc: [email-masked]
>>> >Subject: [MMUSIC] I-D Action:
>>> >draft-ietf-mmusic-data-channel-sdpneg-14.txt
>>> >
>>> >
>>> >A New Internet-Draft is available from the on-line Internet-Drafts
>>> >directories.
>>> >This draft is a work item of the Multiparty Multimedia Session Control
>>> >WG of the IETF.
>>> >
>>> >        Title           : SDP-based Data Channel Negotiation
>>> >        Authors         : Keith Drage
>>> >                          Maridi R. Makaraju
>>> >                          Juergen Stoetzer-Bradler
>>> >                          Richard Ejzak
>>> >                          Jerome Marcon
>>> >                          Roni Even
>>> >	Filename        : draft-ietf-mmusic-data-channel-sdpneg-14.txt
>>> >	Pages           : 41
>>> >	Date            : 2017-12-03
>>> >
>>> >Abstract:
>>> >   The Real-Time Communication in WEB-browsers (RTCWeb) working group
>>> is
>>> >   charged to provide protocols to support direct interactive rich
>>> >   communications using audio, video, and data between two peers' web-
>>> >   browsers.  For the support of data communication, the RTCWeb
>>>working
>>> >   group has in particular defined the concept of bi-directional data
>>> >   channels over SCTP (Stream Control Transmission Protocol), where
>>>each
>>> >   data channel might be used to transport other protocols, called
>>> >   subprotocols.  Data channel setup can be done using either the in-
>>> >   band Data Channel Establishment Protocol (DCEP) or using some
>>>out-of-
>>> >   band non-DCEP protocol.  This document specifies how the SDP
>>>(Session
>>> >   Description Protocol) offer/answer exchange can be used to achieve
>>> >   such an out-of-band non-DCEP negotiation.  Even though data
>>>channels
>>> >   are designed for RTCWeb use initially, they may be used by other
>>> >   protocols like, but not limited to, the CLUE protocol (which is
>>> >   defined by the IETF "ControLling mUltiple streams for tElepresence"
>>> >   working group).  This document is intended to be used wherever data
>>> >   channels are used.
>>> >
>>> >
>>> >The IETF datatracker status page for this draft is:
>>> 
>>>>https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/
>>> >
>>> >There are also htmlized versions available at:
>>> >https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-14
>>> 
>>>>https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sd
>>> >pne
>>> >g-14
>>> >
>>> >A diff from the previous version is available at:
>>> 
>>>>https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg
>>> >-14
>>> >
>>> >
>>> >Please note that it may take a couple of minutes from the time of
>>> >submission until the htmlized version and diff are available at
>>> >tools.ietf.org.
>>> >
>>> >Internet-Drafts are also available by anonymous FTP at:
>>> >ftp://ftp.ietf.org/internet-drafts/
>>> >
>>> >_______________________________________________
>>> >mmusic mailing list
>>> >[email-masked]
>>> >https://www.ietf.org/mailman/listinfo/mmusic
>>> >
>>> >_______________________________________________
>>> >mmusic mailing list
>>> >[email-masked]
>>> >https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic