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".) > > === >