Hello, Tore and Fred. Thanks for requesting an OPSDIR review of this draft. Up front, I'd like to say that I enjoyed hearing the discussion on why certain decisions were made, especially with concern to ease of use for operators and compatibility with other established translation approaches. That said, I have a few minor issues/questions and nits concerning this draft. I think they will be easy to address. ISSUES/QUESTIONS: You set out to define WKP as _the_ well-known prefix. For the most part you adhere to this language in the draft. However, in section 3, you state (highlighting added by me): Also, because the WKP is a /96, an operator preferring to use _a WKP_ over an NSP can only do so for only one of his IPv4/IPv6 translation mechanisms. All others must necessarily use an NSP. And then in section 5: When 64:ff9b:1::/48 or a more-specific prefix is used with the [RFC6052] algorithm, it is considered to be a Network-Specific Prefix. I believe what you're saying is that while you define 64:ff9b:1::/48 as a WKP in _this_ draft, respective to RFC6052, it is an NSP. However, the combination of text in both sections was a bit confusing to me, and perhaps it would be useful to clarify your use of terms. === In Section 3, you state: Since the WKP 64:ff9b::/96 was reserved by [RFC6052], several new IPv4/IPv6 translation mechanisms have been defined by the IETF I think it would be useful to mention some of these new translation mechanisms as non-normative references, and if need be, show an example of interoperability. NITS: In your Abstract, you mention RFC6890, but this does not appear to be an xref to it, and it should be. === In Section 4.1 you state: OLD: The second criterion is that the prefix length chosen is is a multiple of 16. This ensures the prefix ends on a colon boundary when representing it in text, easing operator interaction with it. NEW: The second criterion is that the prefix length chosen is a multiple of 16. This ensures the prefix ends on a colon boundary when representing it in text, easing operator interaction with it. (Removed a redundant "is".) === In Section 4.1 again: OLD: The [RFC6052] algorithm specifies IPv4/IPv6 translation prefixes as short as /32. In order to facilitate multiple instances of translation mechanisms using /32s, while at the same time aligning on a 16-bit boundary, it would be necessary to reserve a /16. Doing so was however considered as too wasteful by the IPv6 Operations working group. NEW: The [RFC6052] algorithm specifies IPv4/IPv6 translation prefixes as short as /32. In order to facilitate multiple instances of translation mechanisms using /32s, while at the same time aligning on a 16-bit boundary, it would be necessary to reserve a /16. Doing so, however, was considered too wasteful by the IPv6 Operations working group. === In Section 6: OLD: The Stateless IP/ICMP Translation algorithm [RFC7915] is one well- known algorithm that can operate in a checksum-neutral manner, when using the [RFC6052] algorithm for all of its address translations. However, in order to attain checksum neutrality is imperative that the translation prefix is chosen carefully. Specifically, in order for a 96-bit [RFC6052] prefix to be checksum neutral, all the six 16-bit words in the prefix must add up to a multiple of 0xffff. NEW: The Stateless IP/ICMP Translation algorithm [RFC7915] is one well- known algorithm that can operate in a checksum-neutral manner, when using the [RFC6052] algorithm for all of its address translations. However, in order to attain checksum neutrality it is imperative that the translation prefix is chosen carefully. Specifically, in order for a 96-bit [RFC6052] prefix to be checksum neutral, all the six 16-bit words in the prefix must add up to a multiple of 0xffff. (Added a missing "it".) ===