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

[Nick Buraglio <[e-mail]>]

On Wed, Mar 20, 2024 at 9:24 AM Tim Chown <[e-mail]> wrote:
>
>
>
> > On 20 Mar 2024, at 14:21, Nick Buraglio <[e-mail]>
wrote:
> >
> > Was this a successful experiment?
>
> For whom? Network operators?  Home users?  Application developers?


Another great question. Who was the target audience? It reads like the
document was aimed at network planners and operators with considerations
for application developers. The abstract describes it as:

   ...a stateless, transport-agnostic IPv6-to-IPv6
   Network Prefix Translation (NPTv6) function that provides the
   address-independence benefit associated with IPv4-to-IPv4 NAT
   (NAPT44) and provides a 1:1 relationship between addresses in the
   "inside" and "outside" prefixes, preserving end-to-end reachability
   at the network layer.


Did the wide array of implementations deliver on that? How far down do we
go to inform the question?  As a reference the standards process
guidelines, my personal interpretation as I go through them are that it
should be informational, at least as a first pass thought. I am trying to
be as impartial and pragmatic as possible, but again, I think the evidence
of successful use and deployments in its respective niché use cases should
be given consideration without bias. If the reality is that it was never
intended to be standards track, based on #4, it should be informational
based on #2. I'm guessing the initial publication was based on #4. If we
evaluate based on current knowledge and data, without an agreed upon set of
success criteria, then #2 probably makes some sense, as does #3, which
denotes that consensus is that we disavow the work but keep it as known
working and should a re-evaluation be agreed upon by rough consensus, since
it is very unlikely to be changed after that regardless of the deployment
status or lack of interest in feedback.

 via https://www.ietf.org/standards/process/informational-vs-experimental/


















*3. GuidelinesThe rules above are not always precise. In particular, the
reasons for declaring something "part of a research and development effort"
aren't clear, and the word "typically" allows a lot of wiggle room.So more
guidelines are often needed in order to interpret the rules.The following
set of guidelines will be used by the IESG. The list is read from top to
bottom; the first one that seems to apply is probably the one that makes
sense to follow.1. If it can't be practiced, it's Informational. Unless
it's a protocol, a procedure or a format, it is hard to see what kind of
experiment it can be. Case in point: "Terminology for ATM ABR benchmarking"
(RFC 3134).2. If it's not going to be changed no matter what the result is,
it's Informational. This is typically the case with vendor protocols; the
vendor will publish it for the good of the community, but retains full
change control, and gives no promises about listening to community
feedback. Case in point: "Microsoft Point-To-Point Encryption (MPPE)
Protocol" (RFC 3078).3. A similar case is work that could be practiced, was
developed in the IETF, has been dropped for some reason, but is being
published for the record. That's Informational, unless the IESG determines
that Historic status is more appropriate. Case in point: "A Delay Bound
alternative revision of RFC 2598" (RFC 3248).4. If the IETF may publish
something based on this on the standards track once we know how well this
one works, it's Experimental. This is the typical case of not being able to
decide which protocol is "better" before we have experience of dealing with
them from a stable specification. Case in point: "PGM Reliable Transport
Protocol Specification" (RFC 3208)5. If the document contains implicit or
explicit success/failure criteria, and it's clear that the outcome can be
used as the basis for a recommendation to the IETF community, it's
Experimental. Case in point: RFC 1797 "Class A Subnet Experiment" which led
to RFC 1879 "Class A Subnet Experiment Results and Recommendations"Note
that guideline 4 above is not intended to say that by publishing this, the
IETF is promising to do a followup; the IETF may later decide that the
experiment failed, and may sometimes believe this outcome to be very
probable even when publishing the document.Guideline 2 may sometimes be
hard to evaluate, because it requires evaluating the intent of the
proposer; still, often it is very easy, and nothing further needs to be
said.*

>
>
> Tim