Re: [rmcat] Shepherd review of draft-ietf-rmcat-scream-cc-07

[Martin Stiemerling <[e-mail]>]

Hi Ingemar, all,



Am 16.03.17 um 15:36 schrieb Ingemar Johansson S:
> Hi
>
> Thanks for the review, comments inline.
>
> /Ingemar
>
>> -----Original Message----- From: Martin Stiemerling
>> [mailto:[e-mail]] Sent: den 15 mars 2017 10:18 To: rmcat
>> WG ([e-mail]) <[e-mail]> Subject: [rmcat] Shepherd
>> review of draft-ietf-rmcat-scream-cc-07
[...]
>>
>> b) This is a bigger issue: The draft specifies a number of protocol
>> behaviors, but is never using any of the RFC 2119 keywords. While
>> not using the RFC 2119 keywords is acceptable for an experimental
>> draft it is troublesome on the long run. The intention is for sure
>> to move this draft to standards track, once the experimental phase
>> is over. However, at this later stage RFC 2119 key words will be
>> required.
> [IJ] OK, yes. This can take a few hours to fix, should not be too
> troublesome, I hope. I had worse issues with rfc6236 as the RFC2119
> keywords had to be chosen carefully in light of existing SDP and SIP
> specs. This one should be more simple, I hope.

Ok, I will wait for the updated version.

>
>>
>> c) a bit of work, but easily fixable.
> [IJ] OK
>
>>
>> Other comments beyond idnits:
>>
>> - Section 4.1.1.1: It says that the constantns are deduced from
>> experiments. In what context have these experiments been specified,
>> carried out and documented? Is this something you can refer you?
>> The current text is a bit underspecified in that respect.
> [IJ] There are experiments results presented at the RMCAT meetings,
> last time was  in Berlin
> (https://www.ietf.org/proceedings/96/slides/slides-96-rmcat-0.pdf ),
> It is possible that I can present new results soon. Question is in
> which form should the results be presented ?. Is material presented
> at RMCAT sufficient.

A reference to this would be just good!

>
>>
>> - Section 4.1.1.1, page 10, bottom: " TARGET_BITRATE_MIN Min target
>> bitrate [bps].
>>
>> TARGET_BITRATE_MAX Max target bitrate [bps]. "
>>
>> I assume that the notion [bps] shall introduce the unit of this
>> constant. Please specify that this is the notion you are using for
>> specifying the unit.
> [IJ] If I understand it correct you mean that I should specify that
> [bps] indicate the unit "bits per second", right ?

Yes, and also introducing that the notation of "[]" in this case means a 
statement of the unit to be used.

>
>>
>>
>> - Section 9. IANA Considerations: This is not section for IANA but
>> more a question for the WG. Please remove the text from this
>> section and place it in a new section "Open Issues" or similar.
>> There is currently no request to IANA. Please state just this and
>> the request to remove the section before publication as RFC.
> [IJ] OK
>
>>
>> - Appendix A.4 looks like a regular section, with the note that
>> this is an experimental version and needs further vetting during
>> the experimentation period, isn't it?
> [IJ] Yes. The proposed feedback while waiting for some kind of
> generic feedback, this is the best one can do with existing
> standardized feedback. The feedback intensity is verified in
> simulator over a large range of bitrates, and also verified in an
> experimental testbed for a high quality video solution over LTE/5G.
> The objective has been to ensure a feedback rate that is not overly
> high and that at the same time does not limit throughput. It is not
> ruled out that the equations in section A.4.2 may change during the
> experimentation period.


How about adding at the top of A.4 what you replied to me, at least 
roughly? This will help to get other reviews a better understanding.

Thank you,

   Martin