IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework
RFC 8468

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

Spencer Dawkins Yes

Mirja K├╝hlewind Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Ben Campbell No Objection

Comment (2018-06-19 for -05)
No email
send info
Requirements Language: Please use the actual boilerplate specified in RFC 8174.

Alissa Cooper No Objection

Benjamin Kaduk No Objection

Comment (2018-06-20 for -05)
No email
send info
I'm glad to see that the "class C" potential confusion is already being addressed.  Even having
seen that previous discussion, I was still struck by how my mind jumped to "address class" when
reading it.

The Abstract claims that this document " deprecates the definition of minimum standard-formed packet",
but the body text refers only to a "minimal IP packet".

A couple of nits:

Section 4

   Two mechanisms require some discussion in the context of standard-
   formed packets, namely IPv6 over Low-Power Wireless Area Networks
   (6LowPAN, [RFC4494]) and Robust Header Compression (ROHC, [RFC3095]).
   IPv6 over Low-Power Wireless Area Networks (6LowPAN), as defined in
   [RFC4494] and updated by [RFC6282] with header compression and
   [RFC6775] with neighbor discovery optimizations proposes solutions
   for using IPv6 in resource-constrained environments.

Please put a comma before "proposes"

Maybe I should leave this one for the RFC Editor, but this document uses "exemplary"
twice when I think "example" is more appropriate -- to me, "exemplary" means something
like "best in class" and specifically has a positive connotation, whereas these usages are
for things that have ambivalent or negative connotations.

Suresh Krishnan (was Discuss) No Objection

Comment (2018-06-30)
No email
send info
Thanks for addressing my DISCUSS and COMMENT points.

Warren Kumari No Objection

Comment (2018-06-18 for -05)
No email
send info
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D6118

Thank you for writing this. Note that I'm using a new tool for
balloting, apologies in advance if it goes Boom!
Also apologies for the terseness / tone, still getting use to the 
tooling, and not sure what shows up where.

COMMENTS
S 1.
>      aspects of IP packets can influence its processing during transfer
>      across the network.
>
>      In Section 15 of [RFC2330], the notion of a "standard-formed" packet
>      is defined.  However, the definition was never updated to include
>      IPv6, as the original authors planned.

Nit: This is slightly ambiguous - it is unclear if "As the authors
intended, it was not updated", or if the authors planned to update it,
and never did.


S 3.
>      This suggests we devise a metric or suite of metrics that attempt to
>      determine C.
>
>      Load balancing over parallel paths is one particular example where
>      such a class C would be more complex to determine in IPPM
>      measurements.  Load balancers often use flow identifiers, computed as

I think you might want "load balancers and routers" here. Generally a
load-balancer is used to mean something which chooses a server (or
cluster of servers) to direct a packet / transaction to. Hashing to
choose amongst parallel paths is more likely to be a router (yes, the
terminology gets squishy - a router doing this is in fact load-
balancing amongst links / paths, but...)



S 3.
>      fields that are used for the forwarding decision, are not known when
>      measuring the path as a black-box.  Potential assessment scenarios
>      include the measurement of one of the parallel paths, and the
>      measurement of all available parallel paths that the load balancer
>      can use.  Knowledge of a load balancer's flow definition
>      (alternatively: its class C specific treatment in terms of header

I realize that RFC2330 also used this term, but it was less jarring
there (it is also only used once)  - I think that you might want to
clarify that "class C" is used here in a different way to "class C
addresses".

I don't have any text to suggest though...


S 4.
>      o  Its total length as given in the IPv4 header corresponds to the
>         size of the IPv4 header plus the size of the payload.
>
>      o  Either the packet possesses sufficient TTL to travel from the
>         Source to the Destination if the TTL is decremented by one at each
>         hop, or it possesses the maximum TTL of 255.

I'm confused here - why do you need to add the "or 255 bit"?

Are you saying that a IPv4 packet that has a TTL of 255 sent to a
destination that is 300 hops away is still "standard-formed"? (not
that that would work anyway!)

Surely just saying "Either the packet possesses sufficient TTL to
travel from the Source to the Destination" is enough? (255, as used by
some protocols is more than sufficient for their single hop).

This feels like over specifying, leading to confusion.


S 4.
>         the packet, and the headers appear in the standard-conforming
>         order (Next Header).
>
>      o  All parameters used in the header and Extension Headers are found
>         in the IANA Registry of Internet Protocol Version 6 (IPv6)
>         Parameters, partly specified in [IANA-6P].

I'm confused again -- this says that all parameters must be in the
"IANA Registry of Internet Protocol Version 6 (IPv6)
Parameters". Ok, cool.
But which part of that registry isn't specified by
https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml?

(why the "partly")?

Terry Manderson No Objection

Alvaro Retana No Objection

Adam Roach No Objection

Martin Vigoureux No Objection