Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service
draft-ietf-v6ops-transition-ipv4aas-15

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.

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.

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?

Thank you for addressing my Discuss point.

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'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 ...

Thanks for addressing my DISCUSS.