IMIX Genome: Specification of Variable Packet Sizes for Additional Testing
RFC 6985

Note: This ballot was opened for revision 04 and is now closed.

(Joel Jaeggli) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

Comment (2013-05-29 for -04)
No email
send info
A question out of curiosity - did the authors consider using a pseudo-random sequence to generate indexes to their packet length table?

That would allow the genome for a long sequence to be compacted to polynomial, starting value and length.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-05-28 for -04)
No email
send info
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

(Spencer Dawkins) No Objection

Comment (2013-05-29 for -04)
No email
send info
In 1 Introduction:

The term IMIX is defined, but Genome isn't. I know what a Genome is, but having an explicit definition would be helpful.

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-05-30 for -04)
No email
send info
section 1: s/this draft/this document/g

section 2: I don't see why the sequence length has to
be "not very long" - what's wrong with longer
sequences?

section 4: As a reader who'd never heard of this
before, I found this unclear but got it after a 2nd
reading. I'd suggest adding "This section describes
how to document an IMIX with custom packet sizes, e.g.
representing a 1020 byte packet size as ggg"
somewhere.

section 5: The run length encoding is also unclear.
Do you mean "IMIX - 20abcd40bcd" or something?

(Brian Haberman) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2013-05-30 for -04)
No email
send info
I don't object to what's documented here, although like Stewart, I was expecting this to involve some kind of pseudorandom sequence.

(Martin Stiemerling) No Objection

(Sean Turner) No Objection