Re: [v6ops] reclassify 464XLAT as standard instead of info

[Ole Troan <[e-mail]>]

> On 21 Sep 2017, at 22:39, Brian E Carpenter <[e-mail]> wrote:
> 
> On 21/09/2017 20:05, Ole Troan wrote:
>>>>>> From my perspective, there are multiple interoperable specs. We have several CLAT client implementations/vendors, from different vendors, and they work fine in the same and different operators and interoperate with different NAT64 and DNS64 vendors/implementations.
>>>>> 
>>>>> What I’m not sure is, because 464XLAT is basically RFC6145 (SIIT) + RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are already Standards track, if we need also to move them to STD in that case, etc.
>>>> 
>>>> I'll repeat myself earlier. Looking at the definitions of the terms, there is no reason it can't or shouldn't be BCP, which our charter does allow us to do, and which is a one-shot standard more appropriate to the case (IMHO). If you want it to be a standardard, a BCP is a standard. Let's advance it to BCP.
>>> 
>>> I think there’s an argument for this.
>>> 
>>> But there will be people who will argue that encapsulation is the ‘best’ practice.  Is there scope for a BCP by translation and a BCP by encapsulation?  Or would the BCP say NAT64/DNS64/464XLAT is the best way to serve nodes in an IPv6-only network?
>>> 
>>> With IPv4 NAT, the IETF didn’t define specific NAT mechanisms, so we ended up with many varieties, with different properties. There’s an argument also I think to nail down one single best translation approach.
>> 
>> Yes, I do wonder in what alternate universe the IETF consensus is that best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-)
> 
> We have a problem in that people confuse "a standard" with "the standard" and
> "a best current practice" with "the best current prcatice". But in the end that's
> just a matter of wording in the Abstract and Introduction. We say: if you want
> to run a pure IPv6 network service while supporting IPv4-only clients and servers,
> and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a good way to do it.
> 
> That does sound like a BCP to me.

Quite the contrary. 
“Do not wish to...” isn’t a qualifier for deciding if this is what the community considers best current practice. 

Rfc2026 does actually say:
The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function.

Ole