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

From: Martin Stiemerling <[email-masked]>
Date: Wed, 15 Mar 2017 10:18:08 +0100

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

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.

c) a bit of work, but easily fixable.

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.

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

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

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

Thanks,

   Martin

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 16 Mar 2017 14:36:48 +0000

Hi

Thanks for the review, comments inline.

/Ingemar

> -----Original Message-----
> From: Martin Stiemerling [mailto:[email-masked]]
> Sent: den 15 mars 2017 10:18
> To: rmcat WG ([email-masked]) <[email-masked]>
> Subject: [rmcat] Shepherd review of draft-ietf-rmcat-scream-cc-07
> 
> Dear all,
> 
> 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:
> a) The copyright year in the IETF Trust and authors Copyright Line does not
> match the current year
[IJ] OK

> 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

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

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

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

---

From: Martin Stiemerling <[email-masked]>
Date: Mon, 27 Mar 2017 07:58:27 +0200

Hi Ingemar, all,

Am 16.03.17 um 15:36 schrieb Ingemar Johansson S:
>> -----Original Message----- From: Martin Stiemerling
>> [mailto:[email-masked]] Sent: den 15 mars 2017 10:18 To: rmcat
>> WG ([email-masked]) <[email-masked]> 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.

>> 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]. "
>>
> [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