|
Thanks for your review, C.M. please see below [acm], Al From: C. M. Heard [mailto:heard@xxxxxxxxx]
Greetings, I have some last call comments on this document. Most (but not all) focus on aspects that do not respect RFC 8200 and RFC 8201. The Abstract says: [...] Exemplary use cases include,
but are not limited to IPv4-IPv6 translation, NAT, protocol
encapsulation, IPv6 header compression, or use of IPv6 over Low-Power
Wireless Area Networks (6LoWPAN).
These last two use cases, however, are explicitly excluded in Section 4: [...] Because of these reasons we
consider ROHC and 6LowPAN packets to be out of the scope of this
document.
On that basis, it seems that the last two use cases in the Abstract should be removed. Other places in the draft that IPv6 header compression also need to be looked at. [acm]
Clarified as follows: IPv6 header compression and use of IPv6 over
Low-Power Wireless Area Networks (6LoWPAN) are
considered and excluded from the standard-formed packet evaluation. and later: Because of these reasons we consider ROHC and
6LowPAN packets to be out of the scope for the
standard-formed packet evaluation. Section 3, page 3, next to last paragraph, has a reference "Diffserv [RFC2780]" -- shouldn't that be "Diffserv [RFC2474]"? [acm]
yes, 2474 was intended, thanks. Section 3, page 4, third paragraph, says: [...] For example, the packet length will
change if IP headers are converted to the alternate version/address
family, or if optional Extension Headers are added or removed. [...]
Adding or removing extension headers contravenes RFC 8200. Since this is just an example, I would recommend deleting the controversial second clause. [acm]
Understand, see below. Section 4, page 6, last paragraph, and page 7, first paragraph, say: The topic of IPv6 Extension Headers brings current controversies into
focus as noted by [RFC6564] and [RFC7045]. However, measurement use
cases in the context of the IPPM framework like in-situ OAM in
enterprise environments or IPv6 Performance and Diagnostic Metrics
(PDM) Destination Option measurements [RFC8250] can benefit from
inspection, modification, addition or deletion of IPv6 extension
headers in hosts along the measurement path.
As a particular use case, hosts on the path may store sending and
intermediate timestamps into dedicated extension headers to support
measurements, monitoring, auditing, or reproducibility in critical
environments. [RFC8250] endorses the use and manipulation of IPv6
extension headers for measurement purposes, consistent with other approved IETF specifications [acm]
This is the end-of-message I received, but I imagine you intended to
point-out that 8200 and 8250 appear to be in conflict over
addition/deletion of extension headers.
From 8200, section 4:
Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. I wonder why RFC 2119 requirement terms were not used to
express this idea? We certainly have agreements about
requirements language for Standards Track memos in IETF.
RFC8250 does not involve Extension header insertion/deletion
along the path, but other work-in-progress (in-situ OAM) would.
In any case, a measurement framework should be prepared to
handle some unexpected/discouraged behaviors encountered on the path.
|
