On Sun, Apr 15, 2018 at 6:43 AM, MORTON, ALFRED C (AL) <acm@xxxxxxxxxxxxxxxx> wrote: > Thanks for your review, C.M. > > > > please see below [acm], > > Al > > > > From: C. M. Heard [mailto:heard@xxxxxxxxx] > Sent: Saturday, April 14, 2018 2:54 PM > To: IETF <ietf@xxxxxxxx> > Cc: IPPM <ippm@xxxxxxxx>; 6man <ipv6@xxxxxxxx> > Subject: Re: Last Call: <draft-ietf-ippm-2330-ipv6-04.txt> (IPv6, IPv4 and > Coexistence Updates for IPPM's Active Metric Framework) to Informational RFC > > > > 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. > Alfred, That is not what this draft is doing. It is advocating header extension insertion even though that is contrary to RFC8220. (it is also advocating processing and modification or destination option by middleboxes which is also contrary to RFC8200). From the draft: "Destination Option measurements [RFC8250] can benefit from inspection, modification, addition or deletion of IPv6 extension headers in hosts along the measurement path." That ignores the negative protocol implications of extension header insertion. draft-voyer-6man-extension-header-insertion proposed updating RFC8200 to allow extension header insertion. The draft got significant push back and in the 6man discussion a list of problem with extension header were enumerated. AFAICT the authors of that draft haven't provided answers to any of the issues yet. Tom > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@xxxxxxxx > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
