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

[Ingemar Johansson S <[e-mail]>]

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
> 
> Dear all,
> 
> Please find here the document shepherd review of
> 
> Summary:
> Draft is not ready for submitting it to the AD, as it has a few items to be
> checked first which are formal issues and but no technical flaws!
> 
> Issues:
> 1) ID nits has a number of issues, noteable these:
> 
> a) The copyright year in the IETF Trust and authors Copyright Line does not
> match the current year
> b) The document doesn't use any RFC 2119 keywords, yet has text
> resembling RFC 2119 boilerplate text.
> c) Found something which looks like a code comment -- if you have code
> sections in the document, please surround them with '<CODE BEGINS>' and
> '<CODE ENDS>' lines.
> 
> a) is easily fixable, when recompiling the draft
[IJ] OK

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

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

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

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

> 
> Thanks,
> 
>    Martin
>