[bmwg] Murray Kucherawy's Discuss on draft-ietf-bmwg-evpntest-09: (with DISCUSS and COMMENT)

[Murray Kucherawy via Datatracker <[e-mail]>]

Murray Kucherawy has entered the following ballot position for
draft-ietf-bmwg-evpntest-09: Discuss

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 DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bmwg-evpntest/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The tests in Sections 3.3, 3.4, 4.3, and 4.4 each define two distinct things to
be measured, but they appear to refer to themselves using a common name.  Feels
like some text copy-paste happened here from previous sections, but wasn't
fully developed.  For instance, Section 3.3 says:

   Measure the time taken for flushing these X MAC addresses.  Measure
   the time taken to relearn these X MAC in DUT.  The test is repeated
   for N times and the values are collected.  The flush and the
   relearning time is calculated by averaging the values obtained by N
   samples.  N is an arbitrary number to get a sufficient sample.  The
   time measured for each sample is denoted by T1,T2...Tn.  The
   measurement is carried out using external server which polls the DUT
   using automated scripts which measures the MAC counter value with
   timestamp.

   Flush rate = (T1+T2+..Tn)/N

   Relearning rate = (T1+T2+..Tn)/N

So you finish the definition appearing to define two distinct things using the
same arithmetic over a single time series.  In other words, you call two
different time series by the same name, and then give an identical formal
definition for what are really two different measurements.

It seems to me what you actually meant was for these to be, maybe,
"F1+F2+..+Fn" for the flush rate and "R1+R2+..+Rn" for the relearning rate,
which makes it clear they are distinct quantities.


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

I support Martin and Eric's DISCUSS positions about how some of the tests are
characterized.

Like Eric, I found the number of typos, capitalization mistakes, and sentence
fragments to be distracting.

Though its coverage of the WG process was good, the shepherd writeup declares
the document status but avoided answering the other questions about its status
(e.g., "Why is this the proper type of RFC?").  This seems to be a common
omission, and I'm starting to wonder if we should just drop it from the
template.

I think RFC 7432 and RFC 7623 should be normative, insofar as this document
doesn't really make sense unless one understands those first.

Please use the correct boilerplate for BCP 14.  (See RFC 8174, Section 2.) 
However, I also note that the only place the key words are used is Section 7,
so it occurs to me you could avoid using BCP 14 altogether and basically say
the same thing with the same force.

Section 1.2 defines "All-Active Redundancy Mode", but it's not used anywhere in
this document other than its own definition.  Similarly, "AA", "ES", "Ethernet
Tag", "RT", and "Sub interface" don't appear anywhere else.  "Single-Active
Redundancy Mode" could be folded into the definition of "SA", since the latter
is actually used elsewhere.