Re: [v6ops] RFC 6877 to Proposed Standard

Hi Fred, Jordi, all, 

I'm interested to participate this. I'm all for this. 
Please let me join this from the viewpoint of 464XLAT co-author and CE vendor as well. 

Regards, 
Masanobu 

=====================
 NEC Platforms, Ltd. 
 KAWASHIMA Masanobu  
=====================

> -----Original Message-----
> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Fred Baker
> Sent: Friday, July 17, 2020 9:08 AM
> To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
> Cc: IPv6 Operations <v6ops@ietf.org>
> Subject: Re: [v6ops] RFC 6877 to Proposed Standard
> 
> Well, may I suggest that you contact some appropriate people, whoever they may be, and put together a design team
> to do the update? Some or all of the original authors may be interested to participate. When you post it, I'll
> be interested in the rfcdiff (which I might just generate myself),the point being that this is not a rewrite but
> an update.
> 
> > On Jul 16, 2020, at 10:23 AM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
> >
> > Hi Fred, all,
> >
> > While I agree that 464XLAT is a procedure to put together other protocols, it defines how to. This is actually
> the case for other standard track documents. Sometimes this is in "the border line". However, I think it is clear
> that there is a strong signal for the market, CPE vendors, etc., when something is standard vs informational. This
> is a key reason.
> >
> > I think we may take the opportunity to see if some of the considerations in RFC8585 could be included in the
> RFC6877-bis. Those aren't new things, just nobody put them in text before, and in fact are part of existing 464XLAT
> implementations/deployments. I recall Jen mention one of them today, maybe there are others.
> >
> > There is also text in RFC8683 which may be re-used in an RFC6877-bis, again thinks that are there in deployments,
> but not written in RFC6877.
> >
> > Regarding the operational experience we have now, I was thinking to include a section reporting it in the RFC6877-bis,
> but I'm fine if you think it should me a different document. I will be happy to participate on it, and I would
> think that we should makes sure to have co-authors from other existing deployments.
> >
> > Regards,
> > Jordi
> > @jordipalet
> >
> >
> >
> > El 16/7/20 19:08, "v6ops en nombre de Fred Baker" <v6ops-bounces@ietf.org en nombre de fredbaker.ietf@gmail.com>
> escribió:
> >
> >    In today's Interim Meeting, Jordi pointed out that all transition mechanisms are at Proposed Standard except
> 464XLAT, and asked the working group to advance it to that status.
> >
> >    /* Personal Opinion */
> >    I have no problem with doing so, but I would ask whether 464XLAT is indeed a transition mechanism. It is an
> operational procedure (and therefore within v6ops' charter to produce, which it did) that uses RFCs 6146, 6147,
> 7915, and possibly 6092, which are at Proposed Standard.
> >    /* Personal Opinion */
> >
> >    My huffing and puffing aside, I'd like to poll the opinion of the working group.
> >       - does RFC 6877 need to be updated? A good approach to doing so would be to file errata
> (https://www.rfc-editor.org/errata.php).
> >         The document currently has no errata filed. Consider this an invitation to file any needed errata and
> tell v6ops you have done so.
> >
> >       - failing that, we certainly have operational experience with it. It is currently an informational document.
> >         Would it be appropriate to raise it to Proposed Standard?
> >
> >       - Per RFC 6410, we may be in a position to advance 6877, 6146, 6147, and/or 7915 to Internet Standard.
> The criterion and process are
> >         described in https://tools.ietf.org/html/rfc6410, and boil down to (1) multiple interoperable
> implementations and (2)
> >         a general belief that the technology works. From my perspective, if we believe that 464XLAT is widely
> deployed and useful,
> >         we believe that each of those are
> >
> >          "characterized by a high degree of
> >          technical maturity and by a generally held belief that the
> >          specified protocol or service provides significant benefit to the
> >          Internet community."
> >
> >    Please reply all with your viewpoint.
> >
> >    If the answer is "yes", fair warning: Ron and I are going to be looking for someone to write an internet draft
> documenting the fact and the deployment status.
> >    _______________________________________________
> >    v6ops mailing list
> >    v6ops@ietf.org
> >    https://www.ietf.org/mailman/listinfo/v6ops
> >
> >
> >
> > **********************************************
> > IPv4 is over
> > Are you ready for the new Internet ?
> > http://www.theipv6company.com
> > 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
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops