Subject: [ippm] AD review of draft-ietf-ippm-6man-pdm-option-03

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 22 Aug 2016 19:37:48 -0500

Dear Authors,

Nice work, and this would have been very valuable when I was implementing
performance monitors at Tektronix, so I imagine it's equally valuable now.

I do have some comments that I'd like you let you consider before I request
IETF Last Call for this draft. Please let me know if you have any
questions, of course.

Thanks,

Spencer

I saw the abstract following the table of contents mentioned in the
shepherd write-up, but https://tools.ietf.org/html/rfc7322#section-4.7 says

   A Table of Contents (TOC) is required in all RFCs.  It must be
   positioned after the Copyright Notice and before the Introduction.

It's probably a good thing to use the organization from RFC 7322, just to
sidestep reviewers who start out complaining about document structure nits
and then keep on typing. Not that I ever did that in six years as a Gen-ART
reviwer, of course :-) ...

I probably lack imagination, but perhaps other readers will, also.

In this text

   DELTATLR = Send time packet 2 - Receive time packet 1

and

   Delta Time Last Sent = Receive time packet 2 - Send time packet 1

these are mathematical expressions, aren't they? If so, that would likely
be clearer if the right side terms had parentheses around the expression.

(It's a bit odd that the first expression uses the abbreviation DELTATLR
and the second term is spelled out as "Delta Time Last Sent" - you might
think about which seems clearer, and do that with both expressions)

In text like this

   We propose a base unit for the time.

you probably want to use a verb like "specify" (when the draft is published
as an RFC, it will no longer be a proposal). There are multiple occurrences
of "propose" in the document, so this comment applies in multiple places.

For this text

   Assume that two packets are sent for each ACK from the server.

you might point out that TCP does this, per RFC 1122 Section 4.2.3.2.

In this text from 6.3 PDM Flow - Multiple Send with Errors

   One might wonder if all of the functions of PDM might be better
   suited to TCP or a TCP option.

that's an interesting point in the broader sense, because (duh) putting PDM
in a TCP option doesn't help you with any other transport protocol (SCTP,
QUIC, what else are we doing these days? and, of course, they're all
running over UDP anyway). I wonder if that's worth pointing out earlier in
the document, perhaps in Section 1.4?

This text

   Let's say that packet 4 STILL does not make it.

is probably too breezy to translate well into other languages. Perhaps "is
also lost"? (Yes, I talk like this, too)

In the Security Considerations section, you might want to say something
about (1) what watching the unencrypted PDM values might tell attackers
that are doing pervasive monitoring (RFC 7258), and possibly about (2) what
happens if PDM is used as a covert channel. I don't think either of these
will be showstoppers at SECDIR review time, but I'd expect that
demonstrating awareness of at least (1) will shorten the review comments
cycle. Possibly a lot, judging by recent ballots on other drafts ...

---

From: <[email-masked]>
Date: Tue, 23 Aug 2016 17:42:04 +0000 (UTC)

Spencer,
Thanks for the kind words and the review.
The authoring team will meet and discuss how to respond & get back to you.
Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360

      From: Spencer Dawkins at IETF <[email-masked]>
 To: [email-masked] 
Cc: [email-masked]
 Sent: Monday, August 22, 2016 5:37 PM
 Subject: AD review of draft-ietf-ippm-6man-pdm-option-03
   
Dear Authors,
Nice work, and this would have been very valuable when I was implementing performance monitors at Tektronix, so I imagine it's equally valuable now.
I do have some comments that I'd like you let you consider before I request IETF Last Call for this draft. Please let me know if you have any questions, of course.
Thanks,
Spencer
I saw the abstract following the table of contents mentioned in the shepherd write-up, but https://tools.ietf.org/html/rfc7322#section-4.7 says 
   A Table of Contents (TOC) is required in all RFCs.  It must be   positioned after the Copyright Notice and before the Introduction.   It's probably a good thing to use the organization from RFC 7322, just to sidestep reviewers who start out complaining about document structure nits and then keep on typing. Not that I ever did that in six years as a Gen-ART reviwer, of course :-) ...
I probably lack imagination, but perhaps other readers will, also.
In this text
   DELTATLR = Send time packet 2 - Receive time packet 1   and
   Delta Time Last Sent = Receive time packet 2 - Send time packet 1   these are mathematical expressions, aren't they? If so, that would likely be clearer if the right side terms had parentheses around the expression.
(It's a bit odd that the first expression uses the abbreviation DELTATLR and the second term is spelled out as "Delta Time Last Sent" - you might think about which seems clearer, and do that with both expressions)
In text like this
   We propose a base unit for the time.     you probably want to use a verb like "specify" (when the draft is published as an RFC, it will no longer be a proposal). There are multiple occurrences of "propose" in the document, so this comment applies in multiple places.
For this text
   Assume that two packets are sent for each ACK from the server.   you might point out that TCP does this, per RFC 1122 Section 4.2.3.2. 
In this text from 6.3 PDM Flow - Multiple Send with Errors
   One might wonder if all of the functions of PDM might be better   suited to TCP or a TCP option.   that's an interesting point in the broader sense, because (duh) putting PDM in a TCP option doesn't help you with any other transport protocol (SCTP, QUIC, what else are we doing these days? and, of course, they're all running over UDP anyway). I wonder if that's worth pointing out earlier in the document, perhaps in Section 1.4? 
This text
   Let's say that packet 4 STILL does not make it.   is probably too breezy to translate well into other languages. Perhaps "is also lost"? (Yes, I talk like this, too)
In the Security Considerations section, you might want to say something about (1) what watching the unencrypted PDM values might tell attackers that are doing pervasive monitoring (RFC 7258), and possibly about (2) what happens if PDM is used as a covert channel. I don't think either of these will be showstoppers at SECDIR review time, but I'd expect that demonstrating awareness of at least (1) will shorten the review comments cycle. Possibly a lot, judging by recent ballots on other drafts ...