Dan, thanks for your review. David, thanks for your response. I’ve entered a No Objection ballot.
Alissa > On Mar 30, 2018, at 5:19 AM, David <[email protected]> wrote: > > Hi Dan, > > Thank you for reviewing this. We have just submitted an update that > addresses the major and minor issue you commented on. Thanks! > > Kind regards, > > David > > > On Fri, Mar 02 2018 at 09:37, Dan Romascanu <[email protected]> wrote: > >> Reviewer: Dan Romascanu >> Review result: Almost Ready >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >> >> Document: draft-ietf-rmcat-sbd-10 >> Reviewer: Dan Romascanu >> Review Date: 2018-03-01 >> IETF LC End Date: 2018-03-16 >> IESG Telechat date: 2018-04-05 >> >> Summary: >> >> Almost Ready >> >> This is an interesting and well-written document. The method described in the >> document have a proposed status of Experimental that seems appropriate, and I >> liked the fact that the expected feedback from the experiments is mentioned >> in >> Section 6. I believe that the document is almost ready for publication from >> the >> Gen-ART perspective, but lacks reference and relation to existing work in the >> IETF related to the definitions and measurement methods for metrics like >> packet >> loss or one-way delay. Adding this information would make clear what is >> currently missing and why this work is needed. >> >> Major issues: >> >> 1. The document does not refer or relate to existing work in the IETF. >> Metrics >> like packet loss or one-way-delay have been defined in IETF WGs like IPPM and >> dealt with in real-time applications context by XRBLOCK. For example Packet >> Loss is defined by RFC 2680, OWD by RFC 7679. Are these applicable? What is >> missing and why new work is necessary? I assume that there are good answers >> to >> these questions, but these are not included in the document. >> >> Minor issues: >> >> 1. It would be useful to explain what the authors mean in this document by >> 'signal' as the usage of the term is different than in other context. For >> example in section 1.2, or more specifically in section 1.2.1 where a >> sentence >> like 'Packet loss is often a relatively rare signal.' is hard to understand >> without such context explanation. >> >> Nits/editorial comments: >> >> 1. Several acronyms are not expanded at first occurrence - for example, but >> not >> limited to: RTP, ECN, etc. > > > -- > David Hayes > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
