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

[David Farmer <farmer@xxxxxxx>]

Prompted by this review, I reread the document and found what I think are a couple additional typos.  

Section 4.2, Prefix Value, compares two options: 64:ff9a:ffff:ffff::/48 and 64:ff9b:1::/48. However in the fifth paragraph of the section, I believe there are two errant references to 64:ff9b:1::/96, that should instead be 64:ff9b:1::/48, unless I'm misunderstanding the intent of the paragraph.  

Thanks.

On Tue, May 2, 2017 at 10:00 AM, Fred Baker <fredbaker.ietf@xxxxxxxxx> wrote:

Thanks!

> On May 2, 2017, at 9:30 AM, Joe Clarke <jclarke@xxxxxxxxx> 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".)
>
> ===
>

_______________________________________________
v6ops mailing list
v6ops@xxxxxxxx
https://www.ietf.org/mailman/listinfo/v6ops

--

===============================================
David Farmer               Email:farmer@xxxxxxx
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================