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

["MORTON JR., ALFRED C (AL)" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Benoit Claise
...
> COMMENT:
> ... 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

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.


> 
> - 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.

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


<editorial change fixed>

> 
> -
>    +-----------------------+-------------------------+-----------------+
>    | 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} ?

acm - 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?

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)

> 
> - Section 4.
> 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
specified.  The size generation you mention below:

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

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.


> 
> - 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.

acm - yes, added that point.

> 
> Editorial
> "Genome" versus "genome" throughout document
> 

acm - ok

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