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

From: "t.petch" <[email-masked]>
Date: Fri, 22 Sep 2017 12:04:18 +0100

Having done my own homework, the IPR datatracker records IPR against two
of the drafts that became RFC6877 and so, by implication, against the
RFC itself.

My recollection is that this was seen as ok for Informational but not
for BCP and was a factor in the change of status of the prospective RFC
for it to be Informational.

Tom Petch

----- Original Message -----
From: "t.petch" <[email-masked]>
To: "Fred Baker" <[email-masked]>; "JORDI PALET MARTINEZ"
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 20, 2017 10:41 AM
Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info

> ----- Original Message -----
> From: "Fred Baker" <[email-masked]>
> To: "JORDI PALET MARTINEZ" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, September 19, 2017 9:27 PM
>
> > Hmm. Wearing the chair hat, but not making pronouncements. Thinking
> through the options and considerations.
>
> Fred
>
> What was the final resolution of the IPR claim by China Mobile
relating
> to this work that caused much bemusement at the time of the approval
> thereof and which also may have been a factor in changing the status
> from BCP to Informational?
>
> Tom Petch
>
> >
> > Some reading matter:
> > https://tools.ietf.org/html/rfc2026#section-5
> > https://tools.ietf.org/html/rfc6410
> > RFC 2026 section 4 as updated by 6410.
> >
> > https://tools.ietf.org/html/rfc6782
> > https://tools.ietf.org/html/rfc7269
> > https://tools.ietf.org/html/rfc7335
> > https://tools.ietf.org/html/rfc7445
> > https://tools.ietf.org/html/rfc7849
> > https://tools.ietf.org/html/rfc7934
> >
> > I would agree that informational status is probably inappropriate at
> this point. I'll note that the progression is not all that unusual;
GRE,
> for example, was originally informational (RFC 1701), was taken to
> Proposed Standard in RFC 2784, and has been updated by RFC 2890. If it
> were taken to Internet Standard, we would need to demonstrate the
points
> raised in https://tools.ietf.org/html/rfc6410#section-2.2.
> >
> > What gives me pause in using the PS/IS standards track is the issue
of
> interoperation of multiple implementations. I'm not entirely sure what
> that means in an operational procedure or service, which is in my
> perception what 464XLAT is. If that is the interoperation of multiple
> networks, it might be the interoperation of an IPv6-only (subset of a)
> network with other IPv4 networks, as the interoperation of that same
> network with IPv6 networks or networks with IPv6 capabilities doesn't
> require such services. The description of a BCP in RFC 2026 sounds
more
> like what we're looking at here.
> >
> > My thought at the moment (which I can be argued out of) is that the
> right status is BCP, and that we would want an updated document that
> captures anything we have learned since RFC 6877 was published.
> >
> > > On Sep 19, 2017, at 5:23 AM, JORDI PALET MARTINEZ
> <[email-masked]> wrote:
> > >
> > > Hi all,
> > >
> > > RFC6877 (464XLAT) is an informational document.
> > >
> > > However, this transition mechanism is the one that has a bigger
> deployment in terms of number of subscribers using it (hundreds of
> millions), which I think is even more than ALL the other transition
> mechanism together.
> > >
> > > Doesn’t make any sense, in my opinion to keep it as an
informational
> document, while we have many others that are standards track and don’t
> have such level of deployment.
> > >
> > > I was commenting this last week with a couple of the co-authors of
> this document, and they have the same opinion.
> > >
> > > So, should we aim to do this?
> > >
> > > Can we even consider moving it to STD?
> > >
> > > Regards,
> > > Jordi
> > >
> > >
> > >
> > >
> > > **********************************************
> > > IPv4 is over
> > > Are you ready for the new Internet ?
> > > http://www.consulintel.es
> > > The IPv6 Company
> > >
> > > This electronic message contains information which may be
privileged
> or confidential. The information is intended to be for the exclusive
use
> of the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not
the
> intended recipient be aware that any disclosure, copying, distribution
> or use of the contents of this information, even if partially,
including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
> > >
> > >
> > >
> > > _______________________________________________
> > > v6ops mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>