Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

li zhenqiang <li_zhenqiang@hotmail.com> Thu, 05 September 2019 02:58 UTC

Return-Path: <li_zhenqiang@hotmail.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 4DA21120B9E; Wed, 4 Sep 2019 19:58:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.114
X-Spam-Level:
X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 wSBvBp--Tdkt; Wed, 4 Sep 2019 19:58:35 -0700 (PDT)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255014.outbound.protection.outlook.com [40.92.255.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD4C1208FA; Wed, 4 Sep 2019 19:58:34 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oIoSiYP0CTWQCGEMNJZGK2JNSAhDwNEQd19pqDTRZjpgFA2yucWR8aMY9LDHfsNWE4Vsqn8MtZ+hwEyS5s7alDrMDXQ3uKQlvZIGUwpfv2xoo/PobU05Fe91wLz+0iBMtr1JNRGFiFUbKTGUbxY/Ml7wl1Wi2b6HOd3h8GGQZoI2GTzonYYX/Yiu0nMkssONixLZQhUIkKM8GwRRMNCk3ZPyrSRu6trJ6WCYSFqhDeW9h260hziYoYaeILfwzjOb4T0mcoM2Q0TTCRxB828Cr4a45KKxeO0sV6ZJsZ82b0u08ukl7Ws75JaFVqr+Ub6RionafcX8Zq4cs9PRIlS+YA==
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=9FAttLW468T2fgwHF9Xp8/phfgO9SLXf33Nh3YSUavg=; b=EKYWr3oHCQQPdA74/41Qor/ZIrPnyzTt1NuH7scSxYrf8opiUtb+PMYobtTXjmlAQmIokfaG6ga4xIXfwyj3XryiSRyIK/iJWzGJnOC5TfV2d0F+2OGLtNsRu/RqEeRg+Tl8CzVDhIHeqXjbS6FOODyYt48NRuHvBvxtSIVOETfbPykFOEOQlIsylQZcOEf1jCHn+gEJp62a4At7yUyJ0hdQj5bt7nPVa69O9ZuOWvP2Q+d5ROsdgQpIVrx4O+aycrQk7/7IKvjbGEAVkC5ok+tm6PgyDcVgvlXVaR37Lw9KNqUct0Jugr72TwCitl+kJ/Zb5+rdq2Te0b1T3dvYow==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9FAttLW468T2fgwHF9Xp8/phfgO9SLXf33Nh3YSUavg=; b=tLgy3JIMlfm7tAC2vzGEDD/gD0x1Sh6aAOIesNEK2gXD0o3ktLPPBp+JtcVQrL6a4Q7Q4v7UYvpd2ZidAv0Sy12rcJ7+HFpslmT4jSjBWnnwfHVft5vcRReLoSgh54GmYTSlkTpTwziBQ7Zsxev0EXO5Y+t8vxLDZzqy/zzkR6SIKeDrj1kP+BA++yf8d/N9iV+ehiRTwBgyGIfWdXyz4E2aUsIvw111AdWObx1gcol6QpZ5JpD0SYLTYYhhTZBelt0Lm2H0Q75/lgsVICATH5IRt+UXFrfCU3zWbsVQFfEyZ5Qqg6StTFenFYt6sis3gl7lbtGv+WmIx49wr9/Ozw==
Received: from SG2APC01FT057.eop-APC01.prod.protection.outlook.com (10.152.250.58) by SG2APC01HT104.eop-APC01.prod.protection.outlook.com (10.152.251.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2220.16; Thu, 5 Sep 2019 02:58:30 +0000
Received: from HK0PR03MB3970.apcprd03.prod.outlook.com (10.152.250.58) by SG2APC01FT057.mail.protection.outlook.com (10.152.251.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2241.14 via Frontend Transport; Thu, 5 Sep 2019 02:58:30 +0000
Received: from HK0PR03MB3970.apcprd03.prod.outlook.com ([fe80::58ab:9421:d860:7c34]) by HK0PR03MB3970.apcprd03.prod.outlook.com ([fe80::58ab:9421:d860:7c34%6]) with mapi id 15.20.2241.014; Thu, 5 Sep 2019 02:58:30 +0000
From: li zhenqiang <li_zhenqiang@hotmail.com>
To: Fernando Gont <fgont@si6networks.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, Ole Troan <otroan@employees.org>, Fernando Gont <fernando@gont.com.ar>
CC: draft-voyer-6man-extension-header-insertion <draft-voyer-6man-extension-header-insertion@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>, "spring@ietf.org" <spring@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programming@ietf.org>
Thread-Topic: Re: Spirit and Letter of the Law (was: Question about SRv6 Insert function)
Thread-Index: AdVjS14TVsuRj78sSeu1r8rfsn3VOQ==
Date: Thu, 05 Sep 2019 02:58:30 +0000
Message-ID: <HK0PR03MB3970EB9B1326CDD4609A6CB4FCBB0@HK0PR03MB3970.apcprd03.prod.outlook.com>
References: <BYAPR05MB54637FEAE1518F83977D274FAEB80@BYAPR05MB5463.namprd05.prod.outlook.com>, <0d3df64e-d596-1cac-eb3d-e08a6e1151ea@si6networks.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: HK0PR01CA0016.apcprd01.prod.exchangelabs.com (2603:1096:203:92::28) To HK0PR03MB3970.apcprd03.prod.outlook.com (2603:1096:203:97::17)
x-incomingtopheadermarker: OriginalChecksum:4C07C5997400AD8FD31EAECDFEB050A6DE820B326FCC84728CDFDB21206807D5; UpperCasedChecksum:87AC66C91A5876E47936019AF46E44A15AAF05EC9BB571E6C4BF98E147DFCC3D; SizeAsReceived:7985; Count:51
x-ms-exchange-messagesentrepresentingtype: 1
x-has-attach: no
x-mailer: Foxmail 7.2.9.156[cn]
x-tmn: [OrGZSaeXZ72YdqY88Kp9Y1IcbyrSTVa7]
x-microsoft-original-message-id: <2019090510582685124518@hotmail.com>
x-ms-publictraffictype: Email
x-incomingheadercount: 51
x-eopattributedmessage: 0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:SG2APC01HT104;
x-ms-traffictypediagnostic: SG2APC01HT104:
x-microsoft-antispam-message-info: 0x60BvyYjG2zCn2bXijRyp5Pig7HCNyxxGzVNAd+y/fQyt4zzmkFkvRy/SQvkka2oPwsjGF91dFMsRlF57PvhUUKvNfIApEDsJLE8mDoQH9MNL3FEb7Ho0ZjY0clY/d0ERmTmU5g9N2dqy5n4alWfgaWbFLwfmyCcnvlJUJ8+gSAO8qkoEkkjBNTifxQtZjx
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_HK0PR03MB3970EB9B1326CDD4609A6CB4FCBB0HK0PR03MB3970apcp_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a8cc2e9-8260-4a46-a685-08d731acedf8
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2019 02:58:30.0981 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT104
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/wEN0K5awT8wDXaWt8PU45daUtJQ>
Subject: Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)
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: Thu, 05 Sep 2019 02:58:37 -0000

Hello all,

I don't think we can infer from RFC 8200 that something is mandated and something is strongly suggested. If guys with different interests can infer from an "Internet Standard" what they are interested, the standard is ambiguous and deserves a bis.

If the standard is clear, we MUST obey it, especially for the result after intensive debates, do we need to repeat the discussion again?

Best Regards,
Zhenqiang Li
________________________________
li_zhenqiang@hotmail.com

From: Fernando Gont<mailto:fgont@si6networks.com>
Date: 2019-09-05 09:23
To: Ron Bonica<mailto:rbonica=40juniper.net@dmarc.ietf.org>; Ole Troan<mailto:otroan@employees.org>; Fernando Gont<mailto:fernando@gont.com.ar>
CC: draft-voyer-6man-extension-header-insertion<mailto:draft-voyer-6man-extension-header-insertion@ietf.org>; 6man@ietf.org<mailto:6man@ietf.org>; Suresh Krishnan<mailto:suresh.krishnan@gmail.com>; spring@ietf.org<mailto:spring@ietf.org>; draft-ietf-spring-srv6-network-programming<mailto:draft-ietf-spring-srv6-network-programming@ietf.org>
Subject: Re: Spirit and Letter of the Law (was: Question about SRv6 Insert function)
On 4/9/19 21:27, Ron Bonica wrote:
> Ole,
>
> Yes, a deep breath and some introspection are always a good thing.
>
> First, I think that we need to make a distinction between the "spirit" and "letter" of the law. Next, we need to make a statement regarding good engineering practice.
>
> RFC 8200 mandates some things. For example, In an IPv6 header, the source address must precede the destination address. Any attempt to reverse those two would violate the letter of the law.
>
> By contrast, RFC 8200 strongly suggests other things. For example, transit nodes should not insert or delete extension headers.

I don't think it "suggests" this. It clearly forbids it.



> In general, these suggestions should be heeded. But exemptions can be granted, on a case-by-case basis,

An exception about this would be a major change regarding what IPv6 is
and its operation.



> For better or worse, RFC 8200 does not use RFC 2119 language. So it is difficult to distinguish between the spirit and letter of the law.

I think you can talk about spirit when there's room for interpretation,
or the text is not clear.

I don't think there's any of that in RFC8200 regarding EH insertion
being forbidden.

In fact, we added the text we added to make it clear that it was forbidden.



> Beyond that, we need to make a statement regarding good engineering practice.

I would like to contribute one: if one is to get into publishing specs,
new specs should comply with the specs they depend on (i.e. the
normative references). That means:

1) Don't violate other specs, or,
2) If you strongly feel like it, you first update the target spec, so
that you behave nicely (you eventually comply with it).



> If a technology violates the spirit of RFC 8200 once, with good reason, that is fine.

I tend to differ here. If a technology is violating an aspect of a spec
on which we spend a long time and energy, that's not fine.

If we (IETF) do it, that would seem to be an indication of issues in the
standardization process -- we publishing specs that not even us comply
with doesn't seem to look nice.


Doing this kind of major surgery (EH insertion) after elevating IPv6 to
"Internet Standard" would bring another set of uncomfortable questions.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------