Re: [MMUSIC] I-D Action: draft-ietf-mmusic-data-channel-sdpneg-02.txt

[Juergen Stoetzer-Bradler <[e-mail]>]

Hello,

The changes of this new version -02 as compared to -01 are listed below and are related to 
corresponding email list discussions and the discussions in Dallas.
Below list is also copied to the change log section 10.1.

Thanks,
Juergen


    o  New Section 4 regarding applicability to SDP offer/answer only.

    o  Addition of new Section 9.1 "Subprotocol identifiers" as
       subsection of the "IANA Considerations" related Section 9.  Also
       removal of the temporary note "To be completed.  As [I-D.ietf-
       rtcweb-data-protocol] this document should refer to IANA's
       WebSocket Subprotocol Name Registry defined in [RFC6455]."

    o  In Section 6.2.2:

       *  In the first paragraph replacement of the sentence "If an SDP
          offer contains both of these parameters then such an SDP offer
          will be rejected." with "If an SDP offer contains both of these
          parameters then the receiver of such an SDP offer MUST reject
          the SDP offer."

       *  In the second paragraph capitalization of "shall" and "may"
          such that both sentences now read: "The SDP answer SHALL echo
          the same subprotocol, max-retr, max-time, ordered parameters,
          if those were present in the offer, and MAY include a label
          parameter.  They MAY appear in any order, which could be
          different from the SDP offer, in the SDP answer."

       *  In the third paragraph replacement of the sentence "The same
          information MUST be replicated without changes in any
          subsequent offer or answer, as long as the data channel is
          still opened at the time of offer or answer generation." with
          "When sending a subsequent offer or an answer, and for as long
          as the data channel is still open, the sender MUST replicate
          the same information.".

    o  In Section 6.2.2 the mapping of data channel types defined in
       [I-D.ietf-rtcweb-data-protocol] to the SDP "a=dcmap" attribute
       parameters were illustrated using example "a=dcmap" attribute
       lines.  Replacement of these example "a=dcmap" attribute lines
       with just the "a=dcmap" attribute parameters being relevant for
       the channel type.

    o  In Section 6.2.5 the description of bullet point "SDP offer has no
       a=dcmap attributes - Initial SDP offer:" was "Initial SDP offer:
       No data channel negotiated yet."  Replacement of this description
       with "Initial SDP offer: No data channel is negotiated yet.  The
       DTLS connection and SCTP association is negotiated and, if agreed,
       established as per [I-D.ietf-mmusic-sctp-sdp]."

    o  In Section 6.2.5 in both bullet points related to "Subsequent SDP
       offer" and "Subsequent SDP answer" replacement of "All the
       externally negotiated data channels must be closed now." with "All
       the externally negotiated data channels are expected be closed
       now.".

    o  In Section 5.2.2's sixth paragraph beginning with "[ASSUMPTION]"
       replacement of the two occurrences of "must" with "MUST".

    o  In Section 6.1.1.1 in the definition of the ABNF rule "dcmap-opt"
       there was a comment saying that "Either only maxretr-opt or
       maxtime-opt is present.  Both MUST not be present." Removal of
       the second normative sentence and instead addition of following
       new paragraph to the end of this section: "Within an 'a=dcmap'
       attribute line's 'dcmap-opt' value either only one 'maxretr-opt'
       parameter or one 'maxtime-opt' parameter is present. Both MUST
       NOT be present."

    o  In Section 6.1.1.7 replacement of the first sentence "The
       'ordered' parameter with value "true" indicates that DATA chunks
       in the channel MUST be dispatched to the upper layer by the
       receiver while preserving the order." with "The 'ordered'
       parameter with value "true" indicates that the receiver MUST
       dispatch DATA chunks in the data channel to the upper layer while
       preserving the order.".

    o  In Section 6.2.3's first paragraph replacement of the one
       occurrence of "must" with "..., it MUST wait until ...".

    o  In Section 6.2.4:

       *  In the second paragraph replacement of "must" with "... whether
          this closing MUST in addition ..."

       *  In the third paragraph replacement of the sentence "The port
          value for the "m" line SHOULD not be changed (e.g., to zero)
          when closing a data channel ..." with "The offerer SHOULD NOT
          change the port value for the "m" line (e.g., to zero) when
          closing a data channel ...".

       *  In the last but two paragraph replacement of the sentence "...
          then an SDP offer which excludes this closed data channel
          SHOULD be generated." with "... then the client SHOULD generate
          an SDP offer which excludes this closed data channel.".

       *  In the last but one paragraph replacement of "must" with "The
          application MUST also close...".

    o  In Section 6.1.2 addition of following note after the formal
       definition of the 'a=dcsa' attribute: "Note that the above
       reference to RFC 4566 defines were the attribute definition can be
       found; it does not provide any limitation on support of attributes
       defined in other documents in accordance with this attribute
       definition."

On 10.04.2015 16:36, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.
>
>          Title           : SDP-based Data Channel Negotiation
>          Authors         : Keith Drage
>                            Maridi R. Makaraju
>                            Juergen Stoetzer-Bradler
>                            Richard Ejzak
>                            Jerome Marcon
> 	Filename        : draft-ietf-mmusic-data-channel-sdpneg-02.txt
> 	Pages           : 30
> 	Date            : 2015-04-10
>
> 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, where each data channel might be used to
>     transport other protocols, called sub-protocols.  Data channel setup
>     can be done using either the internal in-band band (also referred to
>     as 'internal' for the rest of the document) Data Channel
>     Establishment Protocol or some external out-of-band simply referred
>     to as 'external negotiation' in the rest of the document . This
>     document specifies how the SDP offer/answer exchange can be used to
>     achieve such an external 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.  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's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-02
>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic