Note: This ballot was opened for revision 12 and is now closed.
General: I'm curious why this is not a BCP. The shepherd review states that it doesn't recommend practices, but that seems to be me to be exactly what it does. abstract: Does this need to update RFC7084? §1, 2nd paragraph: The paragraph does not parse. §1.1: Is there a reason not to use the updated boilerplate from RFC 8174? §3.2, third paragraph: The paragraph is hard to follow. Please consider breaking into simpler sentences. §3.2.1: "The IPv6 Transition CE Router MUST support CLAT functionality [RFC6877] if intended for the retail market. If 464XLAT is supported, it MUST be implemented according to [RFC6877]." The 2nd MUST seems redundant; we don't generally need to say that a function defined in an RFC MUST be implemented according to that RFC unless there's some reason to expect people might do otherwise. §7: - The entirety of this section is very hard to parse. - "... only integration and testing cost may become a minor issue." I don't think that's a judgement the IETF is in a position to make. It's not all that unusual for integration and testing to be greater costs than coding. §8, 2nd paragraph: Is there any guidance that can be given for mitigating this issue in the context of transition mechanisms?
Thanks for addressing my DISCUSS. Here is my original COMMENT: == Section 1 == OLD This ensures that remote IPv4-only services continue to be accessible, from an IPv6-only Internet Service Provider access network (typically referred as WAN - Wide Area Network, even if in some cases it may be metropolitan, regional, etc.), from both, IPv4-only and IPv6-only applications or devices in the LAN side. NEW This ensures that remote IPv4-only services continue to be accessible from an IPv6-only Internet Service Provider (ISP) access network from both IPv4-only and IPv6-only applications and devices on the LAN side. These ISP access networks are typically referred to as Wide Area Networks (WANs), even if in some cases they may be metropolitan or regional. (Then you could deleted the parenthetical "(Internet Service Providers)" in the sentence below Figure 1.) It seems odd that Figure 1 appears in Section 1 but isn't referenced in the text until Section 12. I think you need a sentence in this section to describe what is depicted in the figure or why it is there, or you need to remove the figure. s/devices or applications/devices and applications/ == Section 3.2 == s/an automated IPv6 transition mechanism provisioning/automated IPv6 transition mechanism provisioning/ s/per interface/per interface/ Would suggest dropping "(which may depend on each transition mechanism)" since it makes the sentence confusing and doesn't add anything. == Section 3.2.1 == OLD If DNS64 [RFC6147] is not used, or not trusted, as the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer, then the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115], which also can be used if the service provider uses DNS64 [RFC6147]. NEW It may be the case that the service provider does not use or does not trust DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behind the CE) may be modified by the customer. In that case, the service provider may opt to configure the NAT64 prefix either by means of [RFC7225] or [RFC8115]. These can also be used if the service provider uses DNS64. == Section 7 == I would suggest starting this section with "At the time of this writing, ..." == Section 12 == The text that refers to Figure 1 I think is meant to refer to Figure 2. Or if not, text is needed to describe Figure 2.
I'm willing to believe that Since it is impossible to know prior to sale which transition mechanism a device will need over its lifetime, IPv6 Transition CE Router intended for the retail market MUST support all the IPv4aaS transition mechanisms supported by this document. Service providers who specify feature sets for IPv6 Transition CE Router may specify a different set of features than those included in this document, for example supporting only some of the transition mechanisms enumerated in this document. we can't do better than requiring all IPv6 Transition CE Routers to support all five transition mechanisms listed in this document, but I am wondering if five is hitting a natural law, or if someone is likely to come up with more transition mechanisms (that the existing CE routers won't support because they're already deployed). But I trust the working group is doing its best ...
Thank you for addressing my Discuss point.
Thanks for addressing my DISCUSS.
Some more processing-related comments: 1) "The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, are not used as described in RFC 2119 [RFC2119]." While it is not forbidden to define their own language requirements, I find this really confusing. I've seen that RFC7084 uses the same definition but actually I don't think the usage is really that different. I'd say the keywords are used in a similar fashion in other informational docs. 2) In the abstract: "this document extends the "Basic Requirements for IPv6 Customer Edge Routers" (RFC7084) in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms." Shouldn't this doc maybe actually update RFC7084 then? Otherwise,how is someone reading RFC7084 supposed to know about this RFC as well?
I share Ben and Mirja's question about the formal relationship between this document and RFC 7084. I also share Ben's confusion about the document's status as not being a BCP -- statements like the following are, by my understanding of the term, specifying practices that are considered to be "best" at the present time: * "The IPv6 Transition CE Router MUST implement a DNS proxy as described in [RFC5625] (DNS Proxy Implementation Guidelines)." * "The IPv6 Transition CE Router MUST support the DHCPv6 S46 priority options described in [RFC8026]." * "The IPv6 Transition CE Router MUST have a GUI, CLI and/or API option to manually enable/disable each of the supported transition mechanisms." If these (and similarly phrased) statements are not recommending best current practices, then I don't understand the purpose of this document.