[MMUSIC] Martin Duke's Discuss on draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-mmusic-t140-usage-data-channel-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-t140-usage-data-channel/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am confused as to the expected/allowed behavior regarding the cps attribute
parameter.

In RFC 4103 Section 6 it says receivers MUST be able to handle temporary bursts
over the cps rate but senders MUST stay below the rate.

In section 5.3 it says senders “can” (probably need a 2119 word here) buffer
blocks to stay below cps. There is a 500ms limit so this has its limitations.
Shouldn’t the buffer time be unbounded if characters are coming in at a rate
above cps?

Meanwhile in section 4.2.1 it suggests that receivers use sendOnly or inactive
(I presume these are the right direction values) to effectively flow control
the incoming data. 4566bis seems to only envision this at the start of a
channel. What is the impact of pending data if the directionality of the
channel changes? How does this interact with the maximum buffer time?

I suggest 4.2.1 be clearer on what actions a cps sender and receiver
MAY/SHOULD/MUST take, and make sure there aren’t contradictory requirements.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The Tsvarea review cites a few other places where the 2119 language is a little
loose, e.g. MUSTs with vague and unenforceable criteria.