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

[Mark Smith <[e-mail]>]

On 6 November 2015 at 05:17, David Farmer <[e-mail]> wrote:
> On 11/5/15 03:05 , Howard, Lee wrote:
>>
>>
>> From: Lorenzo Colitti <[e-mail] <mailto:[e-mail]>>
>>
>>     On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         And so on. It seems pretty clear. Is this language
>>         insufficiently strong for you? What words would you use instead?
>>
>>
>>     I would prefer if we used phrasing of the form "<xxx> is considered
>>     harmful" or "<xxx> is not recommended".
>>
>>
>> You deleted a lot of context, including the text:
>>
>> “(NPT66) is not recommended by the IETF.”
>
>
> For the most part I like this.  It takes emotional trigger words out of it.
> However, I would suggest focusing on Internet connectivity and away from all
> potential uses of NAT.  I believe the primary objection to NAT is in a
> general-purpose Internet context, and other more specialized uses might be
> less objectionable to some.  So something like;
>
>    Use of NPT66, and NAT66 as a general concept, are NOT RECOMMENDED in
>    the context of general-purpose Internet connectivity.
>

I think the above simpler statement is better, this text implies that
there are no consequences (to anything) of using address translation
outside of an Internet context. There clearly are many technical
consequences, as have been documented in many RFCs, and we shouldn't
effectively be dismissing them by omission or implying they only
matter in certain contexts.

 (I think it would be better describe the thing being recommended
against being "address translation", rather than specific methods.
Mentioning specific address translation technologies implies that
other later ones may be consequence free.),

As far as I can see, only one person here is strongly objecting to
stating address translation is harmful. One person strongly objecting
doesn't mean that consensus hasn't been reached by the IETF (see
RFC7282 - "On Consensus and Humming in the IETF")

I think there are two types of people we need to address:

- people who don't really care as much or have as much time for the
details and to know the various benefits and drawbacks. They just want
to follow a guide as to what will work best, making minimal value
judgements

- people who are willing to make value judgements and consider various
trade-offs. They will be interested to know, research and consider the
topic.


The first category of people will mostly accept a simple statement
recommending against or for something, with their next question being,
"so what do I do instead." (e.g. RFC4864 instead of address
translation).

The second category will put weight on what is being stated in the
recommendation, however they themselves will want to have a much
deeper understanding of the why the recommendation has been made, by
researching and reading supporting references. In some ways they're
effectively making the decision their own. They may even decide
against the recommendation. In either case, they'd be able to defend
the decision themselves if they're challenged on it.

(With many people being only being used to private addressing and NAT
in IPv4, I suspect there will be a few people pushed into the second
category who are normally first category people.)

Since this ID is an advice document, I'd like to see content that
would satisfy both types of people. So perhaps:

(a) a simple statement recommending against address translation
(b) a paragraph or so as to mentioning the sorts of consequences it
has, and also that the increasing use of encryption will prevent the
ability to address translate addresses in payloads
(c) references to RFCs that discuss the consequences of address
translation, either specific to IPv6 (i.e., the Implications for
Applications section in the NPT66 RFC), or more general ones e.g.,
RFC2993, RFC1627, with mention that although they were written about
IPv4, some or all of the implications will also apply to IPv6 address
translation.


Regards,
Mark.