Thanks!
On May 2, 2017, at 9:30 AM, Joe Clarke <jclarke(_at_)cisco(_dot_)com> wrote:
Reviewer: Joe Clarke
Review result: Has Issues
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".)
===