Re: [v6ops] RFC 6877 to Proposed Standard

"xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn> Fri, 17 July 2020 06:36 UTC

Return-Path: <xiechf@chinatelecom.cn>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB003A10C0 for <v6ops@ietfa.amsl.com>; Thu, 16 Jul 2020 23:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZwjfmEluepA for <v6ops@ietfa.amsl.com>; Thu, 16 Jul 2020 23:36:32 -0700 (PDT)
Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.223]) by ietfa.amsl.com (Postfix) with ESMTP id 7F71D3A0FE5 for <v6ops@ietf.org>; Thu, 16 Jul 2020 23:36:31 -0700 (PDT)
HMM_SOURCE_IP: 172.18.0.218:49823.511996811
HMM_ATTACHE_NUM: 0000
HMM_SOURCE_TYPE: SMTP
Received: from clientip-219.142.69.75?logid-77dda039f67b44b4bdd24565c352ae3b (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 2D09A2800CF; Fri, 17 Jul 2020 14:36:13 +0800 (CST)
X-189-SAVE-TO-SEND: 66040161@chinatelecom.cn
Received: from ([172.18.0.218]) by App0025 with ESMTP id 77dda039f67b44b4bdd24565c352ae3b for jordi.palet=40consulintel.es@dmarc.ietf.org; Fri Jul 17 14:36:16 2020
X-Transaction-ID: 77dda039f67b44b4bdd24565c352ae3b
X-filter-score: filter<0>
X-Real-From: xiechf@chinatelecom.cn
X-Receive-IP: 172.18.0.218
X-MEDUSA-Status: 0
Sender: xiechf@chinatelecom.cn
Date: Fri, 17 Jul 2020 14:36:12 +0800
From: "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>
To: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, "fredbaker.ietf" <fredbaker.ietf@gmail.com>
Cc: v6ops <v6ops@ietf.org>
References: <080F53E6-79BC-44E2-9F0E-91D328CA5E38@gmail.com>, <4D47A678-CEC7-4513-A3A8-C6A72EE7C0E8@consulintel.es>, <8FE9D2BC-E76D-4752-858D-74F7F3B5C167@gmail.com>, <80F07ECE-B36F-40F4-BD00-220D56E8DE66@consulintel.es>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7.2.16.188[cn]
Mime-Version: 1.0
Message-ID: <2020071714361215140011@chinatelecom.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart821331147662_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/kyQ8tYHdaNPR9DIiPXwpOOtp7Y8>
Subject: Re: [v6ops] RFC 6877 to Proposed Standard
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2020 06:36:34 -0000

Hi,Jordi and Fred,
I am interested in this work and I'd like to join the design team.
Best regards
Chongfeng


From: JORDI PALET MARTINEZ
Date: 2020-07-17 14:19
To: Fred Baker
CC: IPv6 Operations
Subject: Re: [v6ops] RFC 6877 to Proposed Standard
Hi Fred,
 
Actually, before your message to the list on this, I'd already sent a message to the original authors of RFC6877, so just waiting for them to respond.
 
We can look also into other folks that have already deployed 464XLAT in other networks.
 
Regards,
Jordi
@jordipalet
 
El 17/7/20 2:08, "Fred Baker" <fredbaker.ietf@gmail.com> escribió:
 
    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.
    > 
    > 
    > 
 
 
 
 
**********************************************
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