Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
"Darren Dukes (ddukes)" <ddukes@cisco.com> Wed, 11 March 2020 14:44 UTC
Return-Path: <ddukes@cisco.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630E93A07C0; Wed, 11 Mar 2020 07:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.579
X-Spam-Level:
X-Spam-Status: No, score=-9.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Lt4jn3b/; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LcsuDchq
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 IF9Hc7EO2AT4; Wed, 11 Mar 2020 07:44:19 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5283A0815; Wed, 11 Mar 2020 07:44:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=71429; q=dns/txt; s=iport; t=1583937859; x=1585147459; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qz00RTa3U6yE+96PR3ZdKvjC7pcxjv+Z9Yffw2mtLls=; b=Lt4jn3b/M5vy/78qmVxBsvi4vphx6sqGbY5dHVIJJB3G8lv8f6utXD7b BwXJMIsZhemcbEP4mcUklPiB1+HuPZngdkAxu2H21WOm5KLqe+hHTamXR Jj7xx2W4iNgyWC96MRThp7D+mmoKHbCux45/Jn9FYnplZuBEdwYxnbn3a Y=;
IronPort-PHdr: 9a23:D693PByXQdk3cNvXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZuJBVD4IeXCZC0hF8MEX1hgrDm2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DqAAAV+Ghe/51dJa1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF7gSUvUAVsWCAECyoKhAuDRQOKdIJfmBWBQoEQA1AECQEBAQwBARgBCwkCBAEBg35FAheBdiQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFYwEBAQECAQEBEBEdAQEqAggDAQQHAgICAQgRBAEBASABAgQDAgICFBELFAkIAQEEDgUUDoMEAYF9TQMOIAEOnygCgTmIYnWBMoJ/AQEFgTMCg04YggwDBgWBM4wsGoFBP4ERJyCCHy4+axkBgV8BAQIBGYELBQQBAQsGASgQFgkCglkygiyNWByCPDuFc4oSj0IKgjyHVYFhjTUdgkqIJJBMRJAGhzCSVgIEAgQFAg4BAQWBaSJncXAVOyoBgkFQGA2OHQwMCxWDO4UUhUF0AgGBJopyASeBCwEzXAEB
X-IronPort-AV: E=Sophos;i="5.70,541,1574121600"; d="scan'208,217";a="469838733"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Mar 2020 14:44:17 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 02BEiHvO007710 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Mar 2020 14:44:17 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Mar 2020 09:44:17 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Mar 2020 10:44:16 -0400
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 11 Mar 2020 10:44:16 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GfVYiyvIPU6kUfATO4d27XtOIl5KSkJfHW2sWr56m51pAeHcgAZSF0irqsl64qr3ZW66zJlZ0hKZH69c/5rv32KoYRyPvQgJjpYgi7ZyH64SdZ2y7pjDw4gWghUYX8Tc/qCHV3OiWcRNmXzAE8vTLr/p92ecL7n6KGcVvtrya1G+0cUHyhvBMtnQ6x8nCVLtjWzzoaY+w/TpGSt6BmsN50j+r3Uy7uu0UuQlUuKVCouuvaRvMDkerjC81pz40uGdZxqQIJTbDSzXmnwK8Ay5F6gYMgO7E1o1UNeeKvyLe27nKRrVv2rwAugdo7Vj+8TmJCd3kOjnX+Kisa7PjJ/y+w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;bh=qz00RTa3U6yE+96PR3ZdKvjC7pcxjv+Z9Yffw2mtLls=; b=P+5PJ1S/4ZcVVD8A/1gHP67EjZOK25DRmb+MEr0F05PuYCIAVB/vkC7KFciqbpZcXDBOcsDS1EedwnJTYQIKHDxGv+JQ9ogCqodbUHfLfmfp2T28ucpafuyTPTjtzh/hp8pnWaS4RDHj0zVAPvnqI/PdyMBR/I6CojpFWs2mg8BaleuJ/xUas7lisp3Zqeqh1MktCc5SurGK7cl+YRSSsyvS+sADEW/YfeRVZVCIV+QI2fYjBdla2hHUrysAXLbz9etcmZKkMIcYiIoheJlZG7b70LcJLtS7h8sbUnUBJSaIM3pogLYQ/7AtkBdztLEr9lKPltuOnwV3WQjGbCDYGA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qz00RTa3U6yE+96PR3ZdKvjC7pcxjv+Z9Yffw2mtLls=; b=LcsuDchq/YMXG9OJPfoLYxqL/ZSHXuLVOeO3ZlCqjkuCOZPKespzx1fKjn+KUtULHq61a/Cu4zO/LzoqIk6hnZI2GeqqgF/7ldfmtyyLDS9vOgNT8t51dkW1cX7dv3ZHs/Pdv4rokciSneU0v2z5mX32xmDTmQL5tzuxQGlmWwg=
Received: from DM5PR11MB1818.namprd11.prod.outlook.com (2603:10b6:3:114::9) by DM5PR11MB1356.namprd11.prod.outlook.com (2603:10b6:3:14::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.14; Wed, 11 Mar 2020 14:44:15 +0000
Received: from DM5PR11MB1818.namprd11.prod.outlook.com ([fe80::4d47:30fc:1b10:3db8]) by DM5PR11MB1818.namprd11.prod.outlook.com ([fe80::4d47:30fc:1b10:3db8%12]) with mapi id 15.20.2793.018; Wed, 11 Mar 2020 14:44:15 +0000
From: "Darren Dukes (ddukes)" <ddukes@cisco.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
CC: Ted Lemon <mellon@fugue.com>, Fernando Gont <fernando@gont.com.ar>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Thread-Topic: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
Thread-Index: AdXtUHCBczz/925MQSaI7w9wOHJRdgACBA6AAAGG3AAAA/RiAAAAHJfwApEqIgA=
Date: Wed, 11 Mar 2020 14:44:14 +0000
Message-ID: <FCA51487-D859-4A22-8B66-744E72A4B3F7@cisco.com>
References: <6B803B308679F94FBD953ABEA5CCCCD701089509@dggema524-mbx.china.huawei.com> <6E7A3022-DEC7-4E35-9A56-0F708CD41180@fugue.com> <58c706f7-2370-2b63-37df-0b5daf1ad8a5@gont.com.ar> <9E058FE7-22DB-4267-A796-88301885F269@fugue.com> <DB3PR0302MB3228A52782E01BEA74C105F79DEB0@DB3PR0302MB3228.eurprd03.prod.outlook.com>
In-Reply-To: <DB3PR0302MB3228A52782E01BEA74C105F79DEB0@DB3PR0302MB3228.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ddukes@cisco.com;
x-originating-ip: [198.84.207.201]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ea6a2fc4-9aa7-45bb-af37-08d7c5caabbe
x-ms-traffictypediagnostic: DM5PR11MB1356:
x-microsoft-antispam-prvs: <DM5PR11MB135658588FC7060669FE8265C8FC0@DM5PR11MB1356.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0339F89554
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(136003)(366004)(376002)(199004)(478600001)(966005)(2906002)(71200400001)(316002)(8936002)(81156014)(81166006)(5660300002)(54906003)(6506007)(53546011)(66574012)(6512007)(6486002)(86362001)(36756003)(4326008)(33656002)(76116006)(186003)(66476007)(66446008)(66946007)(66556008)(64756008)(6916009)(2616005)(91956017)(26005)(8676002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1356; H:DM5PR11MB1818.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: HT6Rsn3szuNvLsRDSNldN3r16ViMNyNG1bmcYNWISF6Bfuz8UY0a7Ecmg9u9LRRbktrW8FRUKlp6bUzMQElkeo0TFLjetHG0qzMCPlGXwTfB8xmYUHgIvbj69/hi6dtdzkN+Bgdap2kqmthAxUykgNtRfNMB+0un/KTH6NmFWwDo++bn7l3QAeom0s8gQiB1Vlv3sMpm4Wa8fAzaREORPyRHZab5SUGhqM6W45eHZHnBmttjE6hGepbhRtZlFl5L+k5TknYS2ZOFX5lObuVwm7o/EoeIlICyP+mLvVRdDHgVMZt8q40HpOkC1K7hafwZJ4Lh2L10EQz6ZncLZNITse5gjhqZ9wtcoDCi24xN0aU9ZALRk3zFOjaGMVcPcwDsOyhirSkkaZv2cI4Krmq/NSlQWy1jkKly/AhhorbOVMVEWdLji72TwIyroZ0FV2BX8WzUk20r2OQNgLpgyHZduJ9CDmyW/Atm97VJuixh+56WuQjQtj2zPPSnG10SKQp184mFw7KCErkh3LfCMBxoCw==
x-ms-exchange-antispam-messagedata: klUbRIZf8ANjH8QV4KcgtpQxRHFTUJPq++XvomWHQuqvKJAYQnqUw6WU+R607wFazvgV8Tze0jf0fqCt2BvgnqDebyfArCs1HWKX8uSGd09Qs4pPjpxxQanxhzC7wpALcdd6sgf71S0U+cdnh7bfYw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_FCA51487D8594A228B66744E72A4B3F7ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ea6a2fc4-9aa7-45bb-af37-08d7c5caabbe
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2020 14:44:14.9661 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1EphR+ehLQQ16kn+ZfLuG6BtV/XJDg07mWKWueDu8nHF0pXNxUHmQgZg84QqloNfh297NmFJZ0z8fwILZmRbMw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1356
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/8VEj1SLBhyJg_DmWvcwvUTk9E9M>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Mar 2020 14:44:24 -0000
Hi Sasha, I think this question got lost in the other emails around this time. Thanks for asking though and, let me clarify. The SRH doc was built with section 4.3.1<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26#section-4.3.1> stating: "Future documents may define additional SRv6 SIDs. In which case, the entire content of this section will be defined in that document.” So draft-ietf-6man-segment-routing header explicitly gives other documents the ability to fully define new SIDs. In those documents the behavior of those SIDs would be fully defined, regardless of the text in section 4.3.1. draft-ietf-spring-srv6-network-programming is one of those documents, there are others that are and will be written defining new SID behaviors and their processing, this was expected and is necessary for the definition of new SIDs and their behaviors. Thanks, Darren On Feb 27, 2020, at 8:27 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> wrote: Hi all, I cannot say whether PSP is allowed or disallowed by RFC 8200. But, to the best of my understanding, format of SRH and its handling are specified by the IPv6 Segment Routing Header<https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-26> draft that is owned by the 6MAN WG and is already in the RFC Editor queue. Specifically, handling of the SRH by the Segment End Point ((of which PSP is a special use case) is defined in Section 4.3.1.1 and says: S01. When an SRH is processed { S02. If Segments Left is equal to zero { S03. Proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header. S04. } S05. Else { S06. If local configuration requires TLV processing { S07. Perform TLV processing (see TLV Processing) S08. } S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1 S10. If ((Last Entry > max_last_entry) or S11. (Segments Left is greater than (Last Entry+1)) { S12. Send an ICMP Parameter Problem, Code 0, message to the Source Address, pointing to the Segments Left field, and discard the packet. S13. } S14. Else { S15. Decrement Segments Left by 1. S16. Copy Segment List[Segments Left] from the SRH to the destination address of the IPv6 header. S17. If the IPv6 Hop Limit is less than or equal to 1 { S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in Transit message to the Source Address and discard the packet. S19. } S20. Else { S21. Decrement the Hop Limit by 1 S22. Resubmit the packet to the IPv6 module for transmission to the new destination. S23. } S24. } S25. } S26. } I.e., 6MAN WG did not define any special processing of the SRH by the penultimate segment endpoint. And the processing it has defined in the ultimate segment endpoint does not mention removal of the SRH either. I do not think that SPRING WG can change these definitions by and of itself. If PSP is so important, a new individual draft updating the (yet unpublished) RFC defining the SRH has to be submitted and discussed in the 6MAN WG in accordance with the normal IETF process. My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com> -----Original Message----- From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> On Behalf Of Ted Lemon Sent: Thursday, February 27, 2020 3:04 PM To: Fernando Gont <fernando@gont.com.ar<mailto:fernando@gont.com.ar>> Cc: 6man@ietf.org<mailto:6man@ietf.org>; SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>; Maojianwei (Mao) <maojianwei@huawei.com<mailto:maojianwei@huawei.com>>; draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org<mailto:draft-ietf-spring-srv6-network-programming@ietf.org>> Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming This is really not helpful, Fernando, and goes some way toward explaining why communication isn’t happening. What I reacted to in Brian’s message is that he asked a really simple question that could be readily answered with a pointer to the text in the document where the answer is given. Since the response was instead to explain in email, that tells me that the spec is incomplete. Separately, Brian mentioned that there is an issue with RFC8200 that would require an update, that discussions had occurred around this, but then the work never happened. It’s reasonable to raise an objection to proceeding with work that depends on other work that hasn’t been done. What I objected to in Maojianwei’s comment is the notion that the document should pass last call to support the industry. No, the working group should do the work to address the objections that have been raised. If you find yourself explaining some concept that’s mentioned in the document using text that is not in the document and not in another document referenced by the document, the fix is not to just publish anyway, because it supports the industry. The fix is to update the document. A dozen or so +1s should not be taken seriously if the work has not been done and nobody wants to do it. > On Feb 27, 2020, at 6:11 AM, Fernando Gont <fernando@gont.com.ar<mailto:fernando@gont.com.ar>> wrote: > > On 27/2/20 07:27, Ted Lemon wrote: >> The IETF serves users, not “industry”. The IETF does not promote. Our job is to make the internet work interoperably. Brian has raised an objection that could be answered, but has not been. It is inappropriate to say that this document has passed last call. >> In my experience, when it is hard to get consensus in situations like this it is because there is a wish to not address a concern that has been raised, not because the concern could not be addressed or should not have been raised. It may feel unreasonable, and like an imposition, but it is not. It is part of the process. >> Rather than trying to steamroll over the objection, why not simply answer it? > > As a service to the community, let me explain: > > Essentially, and for some reason, they seem to be meaning to circumvent specs and processes. > > One of their last inventions has been to pretend that IPv6 allows EH insertion/deletion en-route, based on their reading of RFC8200. Based on a curious interpretation of the text, they claim that each waypoint (intermmediate router that received the packet because its address was set as de Destination Address) can insert/remove EHs, and they claim that that's not a violation of RFC8200. > > However, the PSP behavour doesn't even fit in that fictional interpretation of RFC8200. > > What PSP does is that, given: > > ---- B ----- C > > > routers, when B realizes, after processing the SRH and setting the Dest Addr to the last segment, SegmentsLeft==0, it removes the SRH. > > This case is not even covered by their fictional interpretation of RFC8200. > > Hence the question is avoided, u<because thye would have no option than admiting they are violating RFC8200..unless... who knows... there might be yet another curious interpretation of the spec that allows it. > > > It should eb evident here that the strategy is not really to follow IETF process, gain consensus, formally update specs if/where needed, but rather push whatever they publish, at whatever cost, ignoring the issues raised in this wg, and circumventing IETF process. > > The fact that this behavior is allowed seems to be unfair with participants, and a dis-service to the group. > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar<mailto:fernando@gont.com.ar> || fgont@si6networks.com<mailto:fgont@si6networks.com> PGP Fingerprint: > 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://clicktime.symantec.com/a/1/o-dBN-ZJMARHA7wJjIE7olF-RwnUUzVtRfXwdFqzmq0=?d=atw_kIqYFUZmbITw7iRdx05oul7SqRcF_hk-ksY2RXOVWKrcCK0_wLPVA5oOx3wxd3LHRWzwabnrklpMwnJcysKDzB7ZAlgkvkI_TBgMOmmWYTmUi7Cm9DeRzA9j6wTSFHHT2weAR7rEioVw_JRBIGcaxmodH6_sktn84eDFcI7b-TIpjSTD5gU0KWBiQuDvf1fgXAGOMtYb2BcOlbUxU6OvpXZ6eEmX0ugTpLkPxEZFSk2oe1Z9fA9GHFrSipsTECbnE9i46sWaYjDh7GATRMJrjPz08XHrqoPpRB7Hsm9rjbmV88d0ZyolqYLMiUxJbp5amhzqx_c2BeMoCNWWvFXQvMuI7SjxdfYP_1Gl0kSP848JuUk6nscdAGk9674LMjiQnz9vnahy-HtQGjQKqurWyHUm6-Tz1xtmpxiRiHJNYk2yxwQqWOUECBStdTdJLvRtWygm6L4Af-pDvPecd5eBAZ-N2ZNF2MODlL14q3R4Ewbq5YIX0rNIi1WDxNdv8YnDaK-qKbLgGNwUcBpswtWNGkMPNLYy0mNNlvCPHw%3D%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org<mailto:ipv6@ietf.org> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
- Re: [spring] Request to close the LC and move for… Dongjie (Jimmy)
- [spring] Request to close the LC and move forward… Lizhenbin
- Re: [spring] Request to close the LC and move for… Huzhibo
- Re: [spring] Request to close the LC and move for… xiechf@chinatelecom.cn
- Re: [spring] Request to close the LC and move for… Gengxuesong (Geng Xuesong)
- Re: [spring] Request to close the LC and move for… Chengli (Cheng Li)
- Re: [spring] Request to close the LC and move for… dzp
- Re: [spring] Request to close the LC and move for… liupengyjy@outlook.com
- [spring] 答复: Request to close the LC and move for… Chenxia (D)
- Re: [spring] Request to close the LC and move for… bruno.decraene
- Re: [spring] Request to close the LC and move for… Fernando Gont
- Re: [spring] Request to close the LC and move for… bruno.decraene
- Re: [spring] Request to close the LC and move for… Zafar Ali (zali)
- Re: [spring] Request to close the LC and move for… Dirk Steinberg
- Re: [spring] Request to close the LC and move for… Fernando Gont
- Re: [spring] Request to close the LC and move for… Bob Hinden
- Re: [spring] Request to close the LC and move for… John Leddy
- Re: [spring] Request to close the LC and move for… Warren Kumari
- Re: [spring] Request to close the LC and move for… Mike Simpson
- Re: [spring] Request to close the LC and move for… 神明達哉
- Re: [spring] Request to close the LC and move for… john leddy.net
- Re: [spring] Request to close the LC and move for… Fernando Gont
- Re: [spring] Request to close the LC and move for… Brian E Carpenter
- Re: [spring] Request to close the LC and move for… Mark Smith
- Re: [spring] Request to close the LC and move for… Voyer, Daniel
- Re: [spring] Request to close the LC and move for… Bob Hinden
- Re: [spring] Request to close the LC and move for… Satoru Matsushima
- Re: [spring] Request to close the LC and move for… Eric Vyncke (evyncke)
- Re: [spring] Request to close the LC and move for… Gaurav Dawra
- Re: [spring] Request to close the LC and move for… Fernando Gont
- Re: [spring] Request to close the LC and move for… Fernando Gont
- Re: [spring] Request to close the LC and move for… Stefano Salsano
- Re: [spring] Request to close the LC and move for… Weiqiang Cheng
- Re: [spring] Request to close the LC and move for… Brian E Carpenter
- Re: [spring] Request to close the LC and move for… =?utf-8?B?WWlzb25nIExpdQ==?=
- Re: [spring] Request to close the LC and move for… Stefano Salsano
- Re: [spring] Request to close the LC and move for… Brian E Carpenter
- Re: [spring] Request to close the LC and move for… li_zhenqiang@hotmail.com
- Re: [spring] Request to close the LC and move for… Bernier, Daniel
- Re: [spring] Request to close the LC and move for… Ahmed Bashandy
- Re: [spring] Request to close the LC and move for… Ketan Talaulikar (ketant)
- Re: [spring] Request to close the LC and move for… Dirk Steinberg
- Re: [spring] Request to close the LC and move for… Fernando Gont
- Re: [spring] Request to close the LC and move for… Fernando Gont
- Re: [spring] Request to close the LC and move for… Mark Smith
- Re: [spring] Request to close the LC and move for… bruno.decraene
- Re: [spring] Request to close the LC and move for… Fernando Gont
- Re: [spring] Request to close the LC and move for… Maojianwei (Mao)
- Re: [spring] Request to close the LC and move for… Ted Lemon
- Re: [spring] Request to close the LC and move for… Andrew Alston
- Re: [spring] Request to close the LC and move for… Fernando Gont
- Re: [spring] Request to close the LC and move for… Stefano Salsano
- Re: [spring] Request to close the LC and move for… bruno.decraene
- Re: [spring] Request to close the LC and move for… Xiejingrong (Jingrong)
- Re: [spring] Request to close the LC and move for… Voyer, Daniel
- Re: [spring] Request to close the LC and move for… Voyer, Daniel
- Re: [spring] Request to close the LC and move for… Ted Lemon
- Re: [spring] Request to close the LC and move for… Ted Lemon
- Re: [spring] Request to close the LC and move for… Stefano Salsano
- Re: [spring] Request to close the LC and move for… Alexander Vainshtein
- Re: [spring] Request to close the LC and move for… Andrew Alston
- Re: [spring] Request to close the LC and move for… Joel M. Halpern
- Re: [spring] Request to close the LC and move for… Nick Hilliard
- Re: [spring] Request to close the LC and move for… John Scudder
- Re: [spring] Request to close the LC and move for… Stefano Salsano
- Re: [spring] Request to close the LC and move for… James Guichard
- Re: [spring] Request to close the LC and move for… Warren Kumari
- Re: [spring] Request to close the LC and move for… Robert Raszuk
- Re: [spring] Request to close the LC and move for… Ted Lemon
- Re: [spring] Request to close the LC and move for… Joel M. Halpern
- Re: [spring] Request to close the LC and move for… Ted Lemon
- Re: [spring] Request to close the LC and move for… Joel M. Halpern
- Re: [spring] Request to close the LC and move for… Warren Kumari
- Re: [spring] Request to close the LC and move for… 神明達哉
- Re: [spring] Request to close the LC and move for… Pablo Camarillo (pcamaril)
- Re: [spring] Request to close the LC and move for… Pablo Camarillo (pcamaril)
- Re: [spring] Request to close the LC and move for… Ted Lemon
- Re: [spring] Request to close the LC and move for… Pablo Camarillo (pcamaril)
- Re: [spring] Request to close the LC and move for… Pablo Camarillo (pcamaril)
- Re: [spring] Request to close the LC and move for… Ron Bonica
- Re: [spring] Request to close the LC and move for… Sander Steffann
- Re: [spring] Request to close the LC and move for… Fernando Gont
- Re: [spring] Request to close the LC and move for… 神明達哉
- Re: [spring] Request to close the LC and move for… Suresh Krishnan
- Re: [spring] Request to close the LC and move for… Fernando Gont
- Re: [spring] Request to close the LC and move for… Mark Smith
- Re: [spring] Request to close the LC and move for… Ron Bonica
- Re: [spring] Request to close the LC and move for… Darren Dukes (ddukes)
- Re: [spring] Request to close the LC and move for… Ron Bonica
- Re: [spring] Request to close the LC and move for… Keyur Patel
- Re: [spring] Request to close the LC and move for… 神明達哉
- [spring] "penultimate segment" [Re: Request to cl… Brian E Carpenter
- Re: [spring] Request to close the LC and move for… Brian E Carpenter
- Re: [spring] "penultimate segment" [Re: Request t… Stefano Salsano
- Re: [spring] "penultimate segment" [Re: Request t… Brian E Carpenter
- Re: [spring] "penultimate segment" [Re: Request t… Ketan Talaulikar (ketant)
- Re: [spring] Request to close the LC and move for… Ketan Talaulikar (ketant)
- Re: [spring] Request to close the LC and move for… S Moonesamy
- [spring] 答复: Request to close the LC and move for… huruizhao
- Re: [spring] Request to close the LC and move for… Tim Chown
- Re: [spring] Request to close the LC and move for… bruno.decraene
- Re: [spring] Request to close the LC and move for… Chengli (Cheng Li)
- Re: [spring] Request to close the LC and move for… S Moonesamy
- Re: [spring] Request to close the LC and move for… bruno.decraene
- Re: [spring] Request to close the LC and move for… S Moonesamy
- Re: [spring] Request to close the LC and move for… bruno.decraene
- Re: [spring] Request to close the LC and move for… S Moonesamy
- [spring] Automated Disclaimers (RE: Request to cl… Alvaro Retana
- Re: [spring] Automated Disclaimers (RE: Request t… S Moonesamy
- Re: [spring] Automated Disclaimers (RE: Request t… Barry Leiba
- Re: [spring] Automated Disclaimers (RE: Request t… S Moonesamy
- Re: [spring] Request to close the LC and move for… Darren Dukes (ddukes)
- Re: [spring] Request to close the LC and move for… Alexander Vainshtein
- Re: [spring] Request to close the LC and move for… Brian E Carpenter
- Re: [spring] Request to close the LC and move for… Alexander Vainshtein
- Re: [spring] Request to close the LC and move for… Darren Dukes (ddukes)
- Re: [spring] Request to close the LC and move for… Alexander Vainshtein