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

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 21 Jul 2015 15:13:43 +0200

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?

Alternatively, instead of completely removing some parts of the text,
such text parts could also be moved to a new informative appendix.

What would be your preference?

Thanks,
Juergen

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Jul 2015 15:03:47 -0400

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

> which text parts I think could be completely removed and which could be

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

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 22 Jul 2015 14:08:08 +0200

Hi Paul,

Thanks much for your comments.
Please see my replies inserted below.

Thank you,
Juergen

On 21.07.2015 21:03, Paul Kyzivat wrote:
> 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.

[Juergen] Ok. Will do that.

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

[Juergen] Ok. Had a look again at the text parts, where "non-DCEP negotiation" is mentioned. I think 
most of the related sentences could anyhow be deleted as discussed above.

>    This SDP extension only defines usage in the context of SDP

[Juergen] Agree. This is the intended meaning. Will change the sentence as you propose.

>    pairs of oppositely directed data channels having the same set of

[Juergen] Agree. Will changes this.

>    user message will be retransmitted.

[Juergen] Indeed. Thanks.

>    SCTP stream has already been negotiated via DCEP.

[Juergen] That's more precise. Thanks much. Will change the sentence as you suggest.

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

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 23 Jul 2015 07:23:15 +0000

With regards to the informative text parts:

>Alternatively, instead of completely removing some parts of the text, such text parts could also be moved to a new informative appendix.

I'm in favour of an Appendix, keeping such valuable information as background info.

/Albrecht

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Juergen Stoetzer-Bradler
Sent: Mittwoch, 22. Juli 2015 14:08
To: [email-masked]
Subject: Re: [MMUSIC] New draft version draft-ietf-mmusic-data-channel-sdpneg-03

Hi Paul,

Thank you,
Juergen

On 21.07.2015 21:03, Paul Kyzivat wrote:
>> Roni's 10th comment was about the still missing IANA registration 
>> text for the new SDP attributes dcmap and dcsa. Have added related 
>> 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.
>> 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.

[Juergen] Ok. Had a look again at the text parts, where "non-DCEP negotiation" is mentioned. I think most of the related sentences could anyhow be deleted as discussed above.

> another full review of the document.

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic