Subject: [bmwg] Benoit Claise's No Objection on draft-ietf-bmwg-imix-genome-04: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Tue, 28 May 2013 07:00:14 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-bmwg-imix-genome-04: 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 http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

No objection to the publication of this document.
However, I have some remarks/questions. Please engage in the discussion.

-  z=MTU is seen as valuable, so MTU MUST be specified if used.
Where? by whom? The tester? Following Section 4 " The tester MUST
complete the following table" example", you might need something such as:

    If the z (MTU) is used, the tester MUST specifiy the MTU value in the
report

- While this approach allows some flexibility, there are also
   constraints.

   o  Non-RFC2544 packet sizes would need to be approximated by those
      available in the table.

   o  The Genome for very long sequences can become undecipherable by
      humans.

   o  z=MTU is seen as valuable, so MTU MUST be specified if used.

   o  "jumbo" sizes are included.

"jumbo" sizes are included: is this a constraint or an advantage? I
thought it was an advantage.

-
OLD:

   The chosen configuration would be expressed the following general
   form:

NEW:
   The chosen configuration would be expressed in the following general
   form:

- 
   +-----------------------+-------------------------+-----------------+
   | Source                | Destination             | Corresponding   |
   | Address/Port/Blade    | Address/Port/Blade      | IMIX            |
   +-----------------------+-------------------------+-----------------+
   | x.x.x.x Blade2        | y.y.y.y Blade3          | IMIX - aaafg    |
   +-----------------------+-------------------------+-----------------+

I don't see the port in the examples.
Maybe you meant Address/{Port|Blade} ?
Or maybe you meant Address/{Port AND/OR Blade} ?

- Section 4.
The custom IMIX can use the MTU size, by setting it up in the Genome.
However, the MTU semantic is not conveyed.
Is this intentional? I was thinking that Z would be the MTU, with the
constraint that the tester MUST specify the MTU value in the report?

- Section 4.
Isn't it an issue that only 26 discrete values are possible?
Don't we have test for which the packet size increases by 1
monotonically?

- Section 5
I guess that the sentence "When a sequence can be decomposed into a
series of short repeating sequences, then a run-length encoding approach
MAY be used as shown below:" can also apply to custom IMIX. The example
doesn't show it. If this is the case, you should mention it.

Editorial
"Genome" versus "genome" throughout document

---

From: "MORTON JR., ALFRED C (AL)" <[email-masked]>
Date: Tue, 28 May 2013 13:34:33 -0400

Hi Benoit, 
thanks for your comments, minimal replies where needed below.
Al

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Benoit Claise
...
> COMMENT:
> ... Please engage in the discussion.
> 
> 

acm - I have added the sentence above (with slight clarification, see below),
and appended the following sentence to the scope and goals in section 2, 
which should help to clarify the role of the document:

Thus, the requirements presented in this specification, expressed in 
[RFC2119] terms, are intended for those performing/reporting laboratory 
tests to improve clarity and repeatability.

> thought it was an advantage.

acm - it is, but it evolved from a constraint when jumbo sizes were
 not included.
 Removed that last two bullets, above.

<editorial change fixed>

acm - Address + (Port AND/OR Blade)

> constraint that the tester MUST specify the MTU value in the report?

acm - the sentence that covers this now reads:
   If z (MTU) is used, the tester MUST specify the length of the MTU 
   in the report.

(so the MTU semantic remains in the table)

> Isn't it an issue that only 26 discrete values are possible?

acm - even if a sequence of different sizes is too long to describe,
the packet sizes are usually chosen from bins in a histogram and 
therefore some summarization of lengths.

At the end of Section 5, we have provisions for pseudo-random
packet size generation, where the algorithm and seed need to be

> Don't we have test for which the packet size increases by 1

acm - could also be included, but we didn't have this suggestion previously
and it would seem fairly obvious how to report the method, as
you've done above.

   If a deterministic packet size generation method is used (such as 
   monotonic increase by one octet from start value to MTU), then the
   generation algorithm SHOULD be reported.

> doesn't show it. If this is the case, you should mention it.

acm - yes, added that point.

> "Genome" versus "genome" throughout document

acm - ok

> 
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg

---

From: Benoit Claise <[email-masked]>
Date: Tue, 28 May 2013 23:52:43 +0200

Hi Al,

Thanks for the quick reaction.
All my points are addressed with your temp version.

Regards, Benoit