Re: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680

Thanks very much for your review and comments, Joachim!
I will address these over the weekend, and ideally 
propose resolutions in the text before the deadline
on Monday...

Also, thanks to Bill and Ann Cerveny for comments and suggestions.

regards,
Al

> -----Original Message-----
> From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of
> Joachim Fabini
> Sent: Friday, October 18, 2013 2:44 PM
> To: ippm@ietf.org
> Subject: Re: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680
> 
> Dear group,
> 
> I support the test plan draft and have added below some minor
> remarks/comments/typos which might help in improving clarity.
> 
> regards
> Joachim
> 
> General remark (applies mainly to RFC6808, which I read as introductory
> document and a potential future "advancement of round-trip delay
> document".
> For the 2680 testplan it should have a minor effect, affecting only the
> time
> value after which a packet is considered as lost). We have discussed this
> in
> previous emails with Al: NetEm _might_ be an important additional source
> of
> error. NetEm's resolution typically equals the system kernel tick (Hz
> value). In some Linux distributions (Ubuntu, Debian) the kernel tick is by
> default configured at 250Hz, such that an uncertainty value of 4ms is
> introduced (kernel compile with appropriate settings can increase the tick
> to 1000 Hz). Fedora seems to have by default 1000 Hz settings, which
> results
> in 1ms uncertainty. And recently a tickless operation has been introduced
> but I don't know if/how this affects NetEm. Abstracting from these
> technical
> settings, I propose to make these decisions and potential uncertainty
> sources explicit by mentioning them in the documents.
> 
> - Page 7, Figure 1, upper: A detailed description of the figure, its
> notations, components and instances could be added. In particular I could
> not find any description about mapping the two Imp1 and two Imp2 instances
> to actual components/implementations. Are the Imp1's Netprobes and Imp2's
> Perfas, ore vice-versa? Is one of the two identically-labelled
> boxes/instances send-only and one receive-only? Or do the instances change
> for distinct tests, depending on the specific test? This might be detailed
> accurately in the text (what Imp1 and Imp2 rectangles are and how they
> relate to the figure and what their role for these tests is).
> 
> - Page 7, Figure 1, upper vs. lower: The mapping between the upper figure
> and lower one is not obvious to me. Is Imp1 in the lower figure one
> instance
> of an Imp1 box in the upper figure, or is it an aggregation of the two
> Imp1
> instances in the upper figure? Could be explained in text.
> 
> - Page 7, Figure 1, lower: I miss NetEm in the lower figure.
> According to the upper figure 1, the U-turn for V100 and V200 seems to be
> implemented in the right Ethernet switch. So the netem instance should be
> part of the flow representation, too (inserted between Internet and Remote
> Switch - imho important issue, as it is the one which impairs/drops the
> traffic and might introduce additional uncertainties)
> 
> - Page 20: Section 6.4.1: From a strictly technical point of view
> (affecting
> the timeout interval after which a packet is considered to be lost), it
> might make a difference whether timestamps are acquired before or after
> the
> system call. So the point in time when timestamp acquisition is scheduled
> should be defined unambiguously.
> 
> 
> -------------------- Layout, typos, etc. ----------------
> - Page 4, second paragraph ("A renewed work...") - it is not clear to me
> whether this paragraph is related to the third paragraph and references
> RFC6567 (merge the two in this case?). Alternatively a reference/citation
> could be added to the second paragraph.
> - Page 4, next-to-last paragraph: is it acceptable to reference an ID
> (I-D.morton-ippm-advance-metrics) from here?
> - Page 5, Section 2, second paragraph: typo "the an equivalent"
> - Page 8: Add reference to "mii-tool"? (btw, as a side-node: mii-tool
> seems
> to be deprecated on some Linux distributions, being replaced by ethtool)
> - Page 8: Typo (DCSP instead of DSCP?)
> - Page 10: I'd propose to mark and delimit start and end of the traceroute
> output visually - perhaps add a caption (Netprobe traceroute)?
> - Page 11: third paragraph, typo ("was be")
> - Page 14: Perhaps it would improve readability to delimit the R output
> (on
> this page and all subsequent occurrences) visually and add a caption?
> - Page 23: section 6.4.3: typo "distributions when according"
> 
> > -----Original Message-----
> > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On Behalf Of
> > Brian Trammell
> > Sent: 03 October 2013 09:32
> > To: ippm@ietf.org
> > Subject: [ippm] WGLC announcement for draft-ietf-ippm-testplan-rfc2680
> >
> > Greetings, all,
> >
> > As discussed in Berlin, "Test Plan and Results for Advancing RFC 2680
> > on the Standards Track", draft-ietf-ippm-testplan-rfc2680, is ready for
> > Working Group Last Call (WGLC); this message begins that last call.
> > Please direct any final comments on this draft to the ippm@ietf.org
> > mailing list by Friday 18 October 2013.
> >
> > Many thanks, best regards,
> >
> > Brian
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm