Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

["Howard, Lee" <[e-mail]>]

From: Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 3, 2015 at 2:00 AM
To: "Liubing (Leo)" <[e-mail]<mailto:[e-mail]>>
Cc: Lee Howard <[e-mail]<mailto:[e-mail]>>, 'IPv6 Operations' <[e-mail]<mailto:[e-mail]>>
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

On Tue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) <[e-mail]<mailto:[e-mail]>> wrote:
[Bing] I basically agree with this claim. But that is actually why we changed the document's purpose from recommendations to considerations, that it only discusses pros and cons of those possible scenarios, and NOT make any formal recommendation.

>From the discussion of the deployment considerations draft in the v6ops session yesterday, several WG members (I remember at least James Woodyatt, Dave Thaler, Igor Gashinsky, and myself) believed that it is not enough to list these deployment models with their pros and cons. Instead, these deployment models should be listed separately as "deployment models that are considered harmful".

Trying to find a way forward with the document. . .

You specifically want to recommend against ULA plus NPT66 or NAT66, right?
The relevant sections in the current document say (in part):


        Although NPTv6 works differently from


         traditional stateful NAT/NAPT (which is discouraged in
         [RFC5902<https://tools.ietf.org/html/rfc5902>]), it introduces similar additional complexity to
         applications, which may cause applications to break.

         Thus this document does not recommend the use of ULA+NPTv6.

...

        Although NPTv6 is a mechanism that has fewer architectural
      problems than a traditional stateful Network Address Translator in
      an IPv6 environment [RFC6296<https://tools.ietf.org/html/rfc6296>], it still breaks end-to-end
      transparency and hence in general is not recommended by the IETF.


...

There's also a full section called, "
Do Not Treat ULA Equal to RFC1918<https://tools.ietf.org/html/rfc1918>.
"

And so on. It seems pretty clear. Is this language insufficiently strong for you? What words would you use instead?

Thanks,

Lee









________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.