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

[Paul Kyzivat <[e-mail]>]

Thanks for doing this work. The draft is shaping up. Comments below.

On 7/21/15 9:13 AM, Juergen Stoetzer-Bradler wrote:
> Have submitted version 03 of draft-ietf-mmusic-data-channel-sdpneg.
> This version solves Roni's comments 1 and 2 and 5 to 9
> (http://www.ietf.org/mail-archive/web/mmusic/current/msg14790.html,
> http://www.ietf.org/mail-archive/web/mmusic/current/msg14811.html).
>
> Roni's 10th comment was about the still missing IANA registration text
> for the new SDP attributes dcmap and dcsa. Have added related
> section headers, but the actual text still needs to be added.
>
> Roni's comments 3 and 4 were related to the (JaveScript) API related
> text parts.
> Have removed most of these text parts.
> However, section 5.2.2 still contains some API related text.
> Before also removing this I'd like to raise a slightly broader question.
>
> Sections 5.1 and 5.2 contain informative generic non-DCEP negotiation
> related text,
> which could mostly be removed from the document, as this draft now
> exclusively
> focuses on SDP offer/answer extensions.
> Some parts might be moved to the related SDP offer/answer specific text
> in section 6.
> Have added a couple of related editor note's to sections 5.1 and 5.2
> indicating
> which text parts I think could be completely removed and which could be
> moved to
> section 6.
>
> Would that be agreeable?

I think the concept makes sense. Right now it is extremely hard to read 
the draft with all the editors notes and figure out how it might flow 
with those changes. IMO it would be better for you to go ahead and make 
the changes, so that the result can be reviewed to see how it works.

I find all the discussion of "non-DCEP negotiation" awkward. I do think 
it is better to simply discuss "SDP negotiation". I don't think we need 
treatise on how other negotiations, other than DCEP or SDP, work.

Other misc comments:

Section 6 says:

    This SDP extension can only be used with the SDP offer/answer model.

I'm not sure if that is true or not. I think it would be better to say:

    This SDP extension only defines usage in the context of SDP
    offer/answer.

Section 6.1.1 says:

    The intention of exchanging these attributes is to create data
    channels on both the peers with the same set of attributes without
    actually using the DCEP [I-D.ietf-rtcweb-data-protocol].

I think there is a bit more to say about this. I suggest:

    The intention in exchanging these attributes is to create, on two
    peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched
    pairs of oppositely directed data channels having the same set of
    attributes.

Section 6.1.1.5 says:

    The 'max-retr' parameter indicates the maximal number a user message
    will be retransmitted.

In the edit a bit was lost. This should say:

    The 'max-retr' parameter indicates the maximal number of times a
    user message will be retransmitted.

Section 6.2.1 says:

    However, an SDP offer/answer exchange MUST NOT be
    initiated if the associated SCTP stream is already negotiated via
    DCEP.

This phrasing is awkward and confusing. I suggest:

    However, an SCTP stream MUST NOT be referenced in a dcmap or
    dcsa attribute of an SDP offer/answer exchange if the associated
    SCTP stream has already been negotiated via DCEP.

Note: above comments based only on reviewing the diffs. I didn't do 
another full review of the document.

	Thanks,
	Paul