Re: [MMUSIC] New draft version: draft-ietf-mmusic-data-channel-sdpneg-01

[Paul Kyzivat <[e-mail]>]

Juergen,

In general this is good. I have a few remaining comments:

Section 5.2.2 says:

    ... If an SDP offer contains both of
    these parameters then such an SDP offer will be rejected.

The use of "will" is confusing - it isn't normative. IMO it should 
either use "MUST" or else it should say such usage is undefined.

Then:

    The SDP answer shall echo the same subprotocol, max-retr, max-time,
    ordered parameters, if those were present in the offer, and may

Again, "shall" is non-normative. IMO this should be SHALL or MUST.

Then:

    Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are
    mapped to SDP in the following manner:

    DATA_CHANNEL_RELIABLE
          a=dcmap:2 subprotocol="BFCP";label="channel 2"
    ...

"This is a bit unclear because these are *examples* using BFCP. (It also 
uses 'ordered=0' rather than 'ordered=false'. I think it would be 
clearer as:

    Data channel types defined in [I-D.ietf-rtcweb-data-protocol] are
    mapped to SDP a=dcmap parameters in the following manner:

    DATA_CHANNEL_RELIABLE
          ordered=true

    DATA_CHANNEL_RELIABLE_UNORDERED
          ordered=false

    DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT
          ordered=true;max-retr=NNN

    DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT_UNORDERED
          ordered=false;max-retr=NNN

    DATA_CHANNEL_PARTIAL_RELIABLE_TIMED
          ordered=true;max-time=NNN

    DATA_CHANNEL_PARTIAL_RELIABLE_TIMED_UNORDERED
          ordered=false;max-time=NNN

('ordered=true' is default and may be omitted.)"

	Thanks,
	Paul

On 3/9/15 7:04 AM, Juergen Stoetzer-Bradler wrote:
> Hello,
>
> Have submitted version -01 of draft-ietf-mmusic-data-channel-sdpneg.
> The changes as compared to version -00 are listed below and are related
> to corresponding recent email list discussions.
> This list is also copied to the change log section 10.1.
>
> Thanks,
> Juergen
>
>
>     o  In Section 3 "WebRTC data channel" was defined as "A bidirectional
>        channel consisting of paired SCTP outbound and inbound streams."
>        Replacement of this definition with "Data channel: A WebRTC data
>        channel as specified in [I-D.ietf-rtcweb-data-channel]", and
>        consistent usage of "data channel" in the remainder of the
>        document including the document's headline."
>
>     o  In Section 4 removal of following note: 'OPEN ISSUE: The syntax in
>        [I-D.ietf-mmusic-sctp-sdp] may change as that document progresses.
>        In particular we expect "webrtc-datachannel" to become a more
>        general term.'
>
>     o  Consistent usage of '"m" line' in whole document as per [RFC4566].
>
>     o  In Section 5.1.1 removal of the example dcmap attribute line
>        'a=dcmap:2 subprotocol="BFCP";label="channel 2' as there are
>        already four examples right after the ABNF rules in
>        Section 5.1.1.1.  Corresponding removal of following related note:
>        "Note: This document does not provide a complete specification of
>        how to negotiate the use of a WebRTC data channel to transport
>        BFCP.  Procedures specific to each sub-protocol such as BFCP will
>        be documented elsewhere.  The use of BFCP is only an example of
>        how the generic procedures described herein might apply to a
>        specific sub-protocol."
>
>     o  In Section 5.1.1 removal of following note: "Note: This attribute
>        is derived from attribute "webrtc-DataChannel", which was defined
>        in old version 03 of the following draft, but which was removed
>        along with any support for SDP external negotiation in subsequent
>        versions: [I-D.ietf-mmusic-sctp-sdp]."
>
>     o  Insertion of following new sentence to the beginning of
>        Section 5.1.1.1: "dcmap is a media level attribute having
>        following ABNF syntax:"
>
>     o  Insertion of new Section 5.1.1.2 containing the dcmap-stream-id
>        specifying sentence, which previously was placed right before the
>        formal ABNF rules.  Removal of the sentence 'Stream is a mandatory
>        parameter and is noted directly after the "a=dcmap:" attribute's
>        colon' as this information is part of the ABNF specification.
>
>     o  In Section 5.1.1.1 modification of the 'ordering-value' values
>        from "0" or "1" to "true" or "false".  Corresponding text
>        modifications in Section 5.1.1.7.
>
>     o  In Section 5.1.1.1 the ABNF definition of "quoted-string" referred
>        to rule name "escaped-char", which was not defined.  Instead a
>        rule with name "escaped" was defined.  Renamed that rule's name to
>        "escaped-char".
>
>     o  Insertion of a dedicated note right after the "a=dcmap:4"
>        attribute example in Section 5.1.1.1 regarding the non-printable
>        "escaped-char" character within the "label" value.
>
>     o  In Section 5.1.2's second paragraph replacement of "sctp stream
>        identifier" with "SCTP stream identifier".
>
>     o  In first paragraph of Section 5.2.1 replacement of first two
>        sentences 'For the SDP-based external negotiation described in
>        this document, the initial offerer based "SCTP over DTLS" owns by
>        convention the even stream identifiers whereas the initial
>        answerer owns the odd stream identifiers.  This ownership is
>        invariant for the whole lifetime of the signaling session, e.g. it
>        does not change if the initial answerer sends a new offer to the
>        initial offerer.' with 'If an SDP offer / answer exchange (could
>        be the initial or a subsequent one) results in a UDP/DTLS/SCTP or
>        TCP/DTLS/SCTP based media description being accepted, and if this
>        SDP offer / answer exchange results in the establishment of a new
>        SCTP association, then the SDP offerer owns the even SCTP stream
>        ids of this new SCTP association and the answerer owns the odd
>        SCTP stream identifiers.  If this "m" line is removed from the
>        signaling session (its port number set to zero), and if usage of
>        this or of a new UDP/DTLS/SCTP or TCP/DTLS/SCTP based "m" line is
>        renegotiated later on, then the even and odd SCTP stream
>        identifier ownership is redetermined as well as described above.'
>
>     o  In Section 5.2.3 the first action of an SDP answerer, when
>        receiving an SDP offer, was described as "Applies the SDP offer.
>        Note that the browser ignores data channel specific attributes in
>        the SDP."  Replacement of these two sentences with "Parses and
>        applies the SDP offer.  Note that the typical parser normally
>        ignores unknown SDP attributes, which includes data channel
>        related attributes."
>
>     o  In Section 5.2.3 the second sentence of the third SDP answerer
>        action was "Note that the browser is asked to create data channels
>        with stream identifiers not "owned" by the agent.". Replacement
>        of this sentence with "Note that the agent is asked to create data
>        channels with SCTP stream identifiers contained in the SDP offer
>        if the SDP offer is accepted."
>
>     o  In Section 5.2.4 the third paragraph began with "A data channel
>        can be closed by sending a new SDP offer which excludes the dcmap
>        and dcsa attribute lines for the data channel.  The port value for
>        the m line should not be changed (e.g., to zero) when closing a
>        data channel (unless all data channels are being closed and the
>        SCTP association is no longer needed), since this would close the
>        SCTP association and impact all of the data channels.  If the
>        answerer accepts the SDP offer then it MUST also exclude the
>        corresponding attribute lines in the answer. ..." Replacement of
>        this part with "The intention to close a data channel can be
>        signaled by sending a new SDP offer which excludes the "a=dcmap:"
>        and "a=dcsa:" attribute lines for the data channel.  The port
>        value for the "m" line SHOULD not be changed (e.g., to zero) when
>        closing a data channel (unless all data channels are being closed
>        and the SCTP association is no longer needed), since this would
>        close the SCTP association and impact all of the data channels.
>        If the answerer accepts the SDP offer then it MUST close those
>        data channels whose "a=dcmap:" and "a=dcsa:" attribute lines were
>        excluded from the received SDP offer, unless those data channels
>        were already closed, and it MUST also exclude the corresponding
>        attribute lines in the answer."
>
>     o  In Section 5.2.4 the hanging text after the third paragraph was
>        "This delayed close is to handle cases where a successful SDP
>        answer is not received, in which case the state of session should
>        be kept per the last successful SDP offer/answer." Replacement of
>        this sentence with "This delayed closure is RECOMMENDED in order
>        to handle cases where a successful SDP answer is not received, in
>        which case the state of the session SHOULD be kept per the last
>        successful SDP offer/answer."
>
>     o  Although dedicated to "a=dcmap" and "a=dcsa" SDP syntax aspects
>        Section 5.1.1 contained already procedural descriptions related to
>        data channel reliability negotiation.  Creation of new
>        Section 5.2.2 and moval of reliability negotiation related text to
>        this new section.
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>