Skip to main content

Benchmarking Methodology for IPv6 Transition Technologies
draft-ietf-bmwg-ipv6-tran-tech-benchmarking-08

Yes

Warren Kumari

No Objection

(Alexey Melnikov)
(Alissa Cooper)
(Deborah Brungard)
(Kathleen Moriarty)
(Mirja Kühlewind)
(Spencer Dawkins)
(Terry Manderson)

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

Warren Kumari
Yes
Adam Roach Former IESG member
No Objection
No Objection (2017-06-07 for -07) Unknown
I was surprised not to find any mention of RFC 4380 (Teredo) in this document. If its omission was intentional, a statement to that effect (say, in the introduction) is probably warranted.
Alexey Melnikov Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (2017-06-06 for -07) Unknown
I note that this document discusses using jumbo Ethernet frames up.
The IEEE has a standard now for baby giant Ethernet frames - though
there is still concern about the EtherType value used.   An informative
reference might be helpful.
Alissa Cooper Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2017-06-07 for -07) Unknown
Section 4. (Test Setup):

   In terms of route setup, the recommendations of [RFC2544] Section 13
   are valid for this document assuming that an IPv6 version of the
   routing packets shown in appendix C.2.6.2 is used.

However, rfc2544 says in several places that the packets in the appendix are just examples.  The frame in C.2.6.2 is a RIP update -- but Section 11.3 references the rate at which "frames SHOULD be sent" (also in the appendix) which include OSPF and IGRP, so I'm assuming that any routing protocol used should work (if the recommendations are followed in terms of frequency, etc.).  I note that rfc5180 doesn't really say anything about routing setup for IPv6 either. :-(

I know this is not the document to define a complete set of (or even update) recommendations for routing setup, so my suggestion is to simply take off the reference to the appendix:

   In terms of route setup, the recommendations of [RFC2544] Section 13
   are valid for this document assuming that IPv6 capable routing    
   protocols are used.
Ben Campbell Former IESG member
No Objection
No Objection (2017-06-05 for -07) Unknown
-7.2, Reporting Format: Is it conventional to use 2119 keywords to describe report formatting? (Or is this paragraph really about content, rather than format?)

(Comment repeats for other "format" related paragraphs.)
Deborah Brungard Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (2017-06-07 for -07) Unknown
* I am surprised that this document does not use (and does not even mention) the Well Known Prefix (64:ff9b::/96) for the algorithmic mapping between IPv4 and IPv6 on translators as specified by RFC6052. Is there a reason why this is omitted?
* It is not clear from the document whether the time taken by the DNS64 resolution procedure is included in the latency measurements. It might be useful to note this.
Terry Manderson Former IESG member
No Objection
No Objection (for -07) Unknown