Re: [v6ops] Opsdir early review of draft-ietf-v6ops-v4v6-xlat-prefix-00

[Tore Anderson <[e-mail]>]

Hi Joe, and thank you very much for your review. See in-line for my
comments.

* Joe Clarke <[e-mail]>

> 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