Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

[Tim Chown <[e-mail]>]

Hi,

> On 18 Mar 2024, at 19:25, Brian E Carpenter <[e-mail]> wrote:
> 
> Front posting for once:
> 
>> I don't think there is much work for this WG, so in my opinion it would be
>> better to not adopt this draft, but instead publish it as an individual
>> submisison.
> 
> I disagree. It is a core topic for this WG and it needs expert eyes on it,
> so my preference is for adoption here and publication as Informational,
> with Proposed Standard with a stronger applicability statement as my second
> choice.

I agree, but the question here is adoption, and if adopted then the Informational debate can begin.

> According to our rules (RFC2026) an Applicability Statement 'specifies
> the circumstances in which the use of a particular TS [tech spec] is
> required, recommended, or elective' and 'may describe particular methods
> of using a TS in a restricted "domain of applicability"'.
> 
> We can do that; most of the words are already somewhere in this thread.

Indeed.  And even as Informational I’d want to see a clear applicability statement.

Tim

> Regards
>   Brian
> 
> On 19-Mar-24 05:10, Philip Homburg wrote:
>>>    The requirement for obfuscation is, in my experience, not
>>>    necessarily rooted in anything other than a bit of a misguided
>>>    understanding of what middle box vendors and end user CPE touted
>>>    as security - conflation of SPI + NAT44 == "Firewall". Like it
>>>    or not, that has 25 years of tradition that has worked its way
>>>    into compliance requirements (there are a myriad of threads on
>>>    this in v6ops dating back many years) and worse yet the generations
>>>    of engineers that were not around pre NAT44, which is most at
>>>    this point, don't often consider a world without it. I say this
>>>    not to make excuses or cases, but to simply illustrate that it
>>>    is larger than "bad" or "good". It is just "current state".
>> The problem with IPv4 is not that some people prefer to run IPv4 with NAT44.
>> The problem is that it almost impossible to run an IPv4 network without NAT44.
>> Fortunately the situation with IPv6 is quite different at the moment. It is
>> quite possible to run an IPv6 network without some kind of NAT or NPT.
>> So if people want to install some kind of NAT or other translation mechanism
>> in their networks, then that is their choice. We are not here to block
>> people from running their networks as they see fit.
>>>    The change in status simply recognizes that fairly
>>>    indisputable fact.
>> However, if we declare something standard track, then that may come with a
>> host of other problems. If particular that future efforts to create a
>> standard may end up in conflict. Or that future drafts will refer to this
>> as a good thing. After all, it is a standard.
>> So for that reason, it is a lot better if it would move from experimental to
>> informational. That is perfectly fine for people who want to use this, but
>> also keep it clear that this is not a direction the IETF wants to go.
>> I don't think there is much work for this WG, so in my opinion it would be
>> better to not adopt this draft, but instead publish it as an individual
>> submisison.
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------