Hi Joe, and thank you very much for your review. See in-line for my
comments.
* Joe Clarke <jclarke(_at_)cisco(_dot_)com>
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.
Good catch! I changed «a WKP» to «the WKP».
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.
Actually I'm trying to not imply anywhere that 64:ff9b:1::/48 is a/the
«WKP» (although the previous point you brought up was a failure in that
regard). The WKP is defined to be exactly 64:ff9b::/96 by RFC6052, and
I do not want to cause any ambiguity here.
I rewrote the paragraph in question as follows:
Note that 64:ff9b:1::/48 (or any more-specific prefix) is distinct from
the WKP 64:ff9b::/96. Therefore, the restrictions on the use of the WKP
described in Section 3.1 of <xref target="RFC6052"/> do not apply to the
use of 64:ff9b:1::/48.
Is that better?
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.
How about: «Since the WKP 64:ff9b::/96 was reserved by [RFC6052],
several new IPv4/IPv6 translation mechanisms have been defined by the
IETF, such as [RFC6146] and [RFC7915].» ?
These two mechanisms do not interoperate at all, so they need different
translation prefixes if they're to be deployed in the same network.
NITS:
In your Abstract, you mention RFC6890, but this does not appear to be
an xref to it, and it should be.
As mentioned by others, the idnits tool complains about xrefs in the
abstract. In any case I've just dropped the Updates on 6890 completely.
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".)
Fixed, thanks!
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.
Fixed, thanks!
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".)
Fixed, thanks!
Tore