Subject: [ippm] Murray Kucherawy's No Objection on draft-ietf-ippm-capacity-metric-method-06: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Thu, 25 Feb 2021 07:21:15 -0800

Murray Kucherawy has entered the following ballot position for
draft-ietf-ippm-capacity-metric-method-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-capacity-metric-method/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Since a SHOULD leaves an implementer with a choice, it's preferable to see
prose explaining why one might deviate from the SHOULD advice.  Thus, the
SHOULDs in Sections 5.3 and 6.3 leave me wondering under what circumstances an
implementer might legitimately choose to do something else.  If there are none,
should it be a MUST?

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 27 Feb 2021 21:27:42 +0000

> -----Original Message-----
> From: Murray Kucherawy via Datatracker [mailto:[email-masked]]
> Sent: Thursday, February 25, 2021 10:21 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; Ian Swett <[email-masked]>; [email-masked]
> Subject: Murray Kucherawy's No Objection on draft-ietf-ippm-capacity-
> metric-method-06: (with COMMENT)
> 
...
> implementer might legitimately choose to do something else.  If there are
> none, should it be a MUST?
> 
> 
Hi Murray,

Thanks for your review, and re-casting your ballot as a COMMENT. I listened to 
the telechat and heard it happen. It was my first chance to take advantage of 
the opportunity to listen-in, and I'm glad I did.

S 5.3

OLD + Ben's comments fixed:
Anticipating a Sample of Singletons, the number of sub-intervals with duration dt 
SHOULD be set to a natural number m, so that T+I = T + m*dt with dtn+1 - dtn = dt 
for 1 <= n <= m.

I cannot for the life of me conjure-up why a practical value of m would not be
a natural number. Thus, I'll make this a MUST unless someone produces a 
reasonable deviation (which we would add to the text).

NEW
Anticipating a Sample of Singletons, the number of sub-intervals with duration dt 
MUST be set to a natural number m, so that T+I = T + m*dt with dtn+1 - dtn = dt 
for 1 <= n <= m.

S 6.3

It's basically the same requirement in this section, so the same rationale and fix 
applies:

OLD + Ben's comments fixed:
The number of sub-intervals with duration dt SHOULD be set to a natural number m, 
so that T+I = T + m*dt with dtn+1 - dtn = dt for 1 <= n <= m.

NEW
The number of sub-intervals with duration dt MUST be set to a natural number m, 
so that T+I = T + m*dt with dtn+1 - dtn = dt for 1 <= n <= m.

These are the only SHOULDs in 5.3 and 6.3.

Going a bit further, I found a SHOULD in 7.3 that we could explain better:
 
OLD
st SHOULD be much smaller than the sub-interval dt. 
The st parameter does not have relevance when the Source is transmitting at 
a fixed rate throughout S.

NEW
st SHOULD be much smaller than the sub-interval dt and on the same order as FT, 
otherwise the rate measurement will include many rate adjustments and include
more time smoothing, thus missing the maximum rate. The st parameter does not 
have relevance when the Source is transmitting at a fixed rate throughout S.

And 7.4 has an unexplained SHOULD:
OLD
Both the Sender and Receiver or (source and destination) bit rates SHOULD 
be assessed as part of an IP-layer Capacity measurement. 
NEW
Both the Sender and Receiver or (source and destination) bit rates SHOULD 
be assessed as part of an IP-layer Capacity measurement. Otherwise, an 
unexpected sending rate limitation could produce an erroneous Maximum 
IP-Layer Capacity measurement.

We have some other SHOULDs, mostly associated with reporting results. These,
and others in S 10 are aspects we really cannot mandate.

All these changes are in the working version of -07 to-be.

Thanks again!
Al