Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
* Section 4 Since this behavior is clearly forbidden in RFC8200 there is no need to add a special case for this (as middleboxes perform any number of transformations that not standards compliant). Given that safe header insertion/deletion is a hard problem that has not been solved, I would remove this text or significantly augment it to describe potential issues that may occur due to header insertion/deletion (similar to the sections related to 6lowpan and translation). o Extension Header insertion or deletion: Although such behavior is not endorsed by current standards, it is possible that Extension Headers could be added to, or removed from the header chain. The resulting packet may be standard-formed, with a corresponding Type-P.
* Section 3 Please add RFC6398 as the reference for Router Alert as it provides significant guidelines regarding usage similar to what RFC7045 does for hop-by-hop options. * Section 4 I think this text should be removed [RFC8250] endorses the use of IPv6 extension headers for measurement purposes, consistent with other approved IETF specifications. as RFC8250 uses a destination option and defining new extension headers has been explicitly recommended against by section 4.8 of RFC8200. * Minor => The reference for 6lowpan is wrong throughout the document (typo?). It should be RFC4944 instead of RFC4494 (which is a crypto spec).
Requirements Language: Please use the actual boilerplate specified in RFC 8174.
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.
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")?