Re: [MMUSIC] WGLC on draft-ietf-mmusic-msrp-usage-data-channel-16

[Paul Kyzivat <[e-mail]>]

On 5/7/20 3:33 PM, Christer Holmberg wrote:
> Hi Paul,
> 
> Thank You for the comments! Please see inline.

I'm fine with these.

	Thanks,
	Paul

> ---
>      
>>     1) NIT:
>>     
>>     In Section 3.1, in the table, the value for Label has a lot of white
>>     space between "See" and "Section 4.3". It would look better with a
>>     single space.
>    
> That's a bug. Will be fixed.
> 
> ---
> 
>>     2) MINOR ISSUE:
>>     
>>     In section 4.1, the abnf says:
>>     
>>         transport  /= "dc" / 1*ALPHANUM
>>     
>>     The /= means this is an added alternative to what is present in RFC4975.
>>     Hence it is equivalent to:
>>     
>>         transport = "tcp" / 1*ALPHANUM / "dc" / 1*ALPHANUM
>>     
>>     What you should really have is just:
>>     
>>         transport  /= "dc"
>   
> Will modify as suggested.
> 
> ---
> 
>>     3) NIT:
>>     
>>     Section 4.4 says:
>>     
>>         An offerer and answerer MUST include a dcsa attribute for the
>>         following MSRP-specific SDP attributes:
>>     
>>     I suggest: s/for the/for each of the/
> 
> Will modify as suggested.
>      
>>     Similarly, where it says:
>>     
>>         An offerer and answerer MAY include a dcsa attribute for the
>>     
>>     I suggest: s/for the/for any of the/
>    
> Will modify as suggested.
> 
> ---
>    
>>     4) QUESTION:
>>     
>>     Does section 4.6 this mean it is an error to use SDP to close the
>>     DTLS/SCTP association (via m=0) without all the added SDP attributes to
>>     close each data channel?
>>
>>     Could it not be implied that closing the association implicitly closes
>>     all the data channels?
>    
> The procedures follow what is defined in Section 6.6.1 of draft-ietf-mmusic-data-channel-sdpneg.
> 
> Whether closing the SCTP association, without explicitly closing the data channel(s) first, is an "error", or just "something one should not do",  I think should have been specified in draft-ietf-mmusic-data-channel-sdpneg.
> 
> ---
> 
>>     5) QUESTION:
>>     
>>     The example in section 4.8 includes use of the "path" attribute. How
>>     does that square with the following in section 4.4:
>>     
>>         The path attribute SHALL NOT be used for transport negotiation.
>>     
>>     I guess you mean that some usages of path are ok and others are not.
>>     Could you be more explicit about this?
> 
> I have got the same questions from others too, so I guess it needs to be clarified.
> 
> As the MSRP messages will be "routed" on the established data channel, the path attribute won't be used for routing.
> 
> Maybe something like this:
> 
> "When MSRP messages are transported on a data channel, the "path" attribute is not used for routing of the messages. Because of that an MSRP endpoint
> can set the MSRP-URI authority value of the "path" attribute at its own discretion. However, when an MSRP endpoint receives an MSRP message on
> a data channel it MUST still check the MSRP-URI in the To-Path of the MSRP message, as described in [RFC4975]."
> 
> ---
> 
>>     6) ISSUE:
>>     
>>     Section 7.1 registers "MSRP" as if it was a totally new websocket
>>     protocol name, but it isn't. It is already registered as a websocket
>>     protocol referencing RFC7977.
> 
> True.
> 
> That shows for how long we have been working on this document, because when we started RFC 7977 didn't exist...
> 
>>     I think you instead need to specify that the existing registration be updated.
> 
> Something like:
> 
> 7.1.  Subprotocol Identifier MSRP
> 
>     NOTE to RFC Editor: Please replace "XXXX" with the number of this
>     RFC.
> 
>     This document adds a reference to RFC XXXX for the subprotocol identifier "msrp" in
>     the "WebSocket Subprotocol Name Registry".
> 
> ---
> 
> Regards,
> 
> Christer
> 
> 
>   
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>