Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-t140-usage-data-channel-12: (with COMMENT) - Christer's reply

[Christer Holmberg <[e-mail]>]

Hi Benjamin,

Thank You for the review! 

In this reply I will mostly focus on the parts that Gunnar didn't already address in his reply.

...
    
    Section 4.1
    >
    >     The offerer and answerer MUST NOT include the max-retr or the max-
    >     time attribute parameters in the 'dcmap' attribute.  If any of the
    >     attribute parameters is received in an offer, the answerer MUST
    >     reject the offer.  If any of the attribute parameters is received in
    >
    > s/any of the/either of those/? (twice)

I will fix as suggested.

...

    > Section 4.2.3.3
    >
    >     If the answerer has not marked the direction of a T.140 data channel
    >     in accordance with the procedures above, it is RECOMMENDED that the
    >     offerer does not process that as an error situation, but rather
    >     assume that the answerer might both send and receive T.140 data on
    >     the data channel.
    >
    > My SDP O/A is a bit rusty, but isn't that a divergence from the default
    > behavior of "treat it as an error"?  Perhaps we could say something
    > about why diverging from the default is deemed best.

The reason is that the current version of the WebRTC API does not support setting of the direction attribute for a data channel.

We used to have text about that. But, people wanted it to be removed, because we should not document implementations that are not compliant, but instead make the procedures such that they support such implementations.

...

    Section 5.4
    >
    >     might have been lost.  Different mechanisms used by sending and
    >     receiving endpoints to detect or suspect text loss are outside the
    >     scope of this specification.
    >
    > I think I can accept that, but do we have reason to believe that any
    > such mechanisms are possible?

Martin D had a similar comment, and we are going to modify the text and remove the text about detecting or suspecting text loss:

https://github.com/cdh4u/draft-datachannel-t140/pull/56/commits/432cc24a42cec7f084657738bd2b69a8c2f9d380

...

    Section 6
    >>
    >>     o  During a normal text flow, T140blocks received from one network
    >>        are forwarded towards the other network.  Keep-alive traffic is
    >>        implicit on the T.140 data channel.  A gateway might have to
    >>
    >> I'm not sure what reference I should look at to understand what is meant
    >> by "keep-alive traffic is implicit".
    >
    > Implicit means here that keep-alive is handled somewhere in the 
    > underlying stack. It seems to me that it is in SCTP, RFC 4960, sections 
    > 1.5.7 Path management and 8.3 Heartbeat  even if I cannot find it 
    > expressed that the Heartbeat interval should be tuned so that they also 
    > serve as keep-alive on the connection through routers etc.
    >
    > But also ICE, RFC 5245 section 10 also has specification for how ICE 
    > usually takes care of keepalive.
    >
    > Maybe "implicit" could be changed to "handled by lower layers".

I would be fine with that.
    
 ...

    Section 8
    >
    >     The generic security considerations for WebRTC data channels are
    >     defined in [I-D.ietf-rtcweb-data-channel].  As data channels are
    >
    > Perhaps it is worth pre-dereferencing the reference chain to
    > rtcweb-security and rtcweb-security-arch directly?

So, to clarify, you want me to add references to rtcweb-security and rtcweb-security-arch?

I don't object doing that, but I wonder whether it is really needed.
    
    > It also seems appropriate to reiterate the note from earlier in the
    > document that "no mechanism to provide end-to-end encryption of T.140
    > data is defined at the time of this writing" and the consequences
    > thereof when the channel itself is not end-to-end.

Will do as suggested.

...

    Section 11.1
    >
    > We should maybe sprinkle a couple more RFC 3264 refs; the current one
    > doesn't seem to be in a normative manner (though I don't dispute the
    > status of 3264 as a normative reference!).

I agree. I suggest to add it to the first sentence of Section 4 - eventhough it is indirectly reference as part of the [I-D.ietf-mmusic-data-channel-sdpneg] reference.

So, something like:

   "The generic SDP considerations, including the SDP Offer/Answer
   Procedures [RFC3264]., for negotiating a WebRTC data channel are defined in
   [I-D.ietf-mmusic-data-channel-sdpneg]."

    ---------------------------

Regards,

Christer