Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0230CC151084; Thu, 30 May 2024 04:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.098 X-Spam-Level: X-Spam-Status: No, score=-7.098 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYaLCcqSAxmW; Thu, 30 May 2024 04:43:58 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2109.outbound.protection.outlook.com [40.107.223.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931E5C1D4A8D; Thu, 30 May 2024 04:43:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OQekSkQ/Hm3H72ukG5AWukvPIUhma1fNVso/aXGvpYNaPaGCd8PI51jznX5KsiX0g7qY36yc0AO3Hh9jy8YLHL3ZtPxNY/RSWZnZVOFD6E9japZ5FJqbMo8AUGaUPqPBCJiettJtoJukAcslolVhefAo0IqfHaLSAQeqqlffokSmQWNZaY1o8S4mGTm89tnzZeFzzr05p+G+tVU5MakKDByk9G9aKxSN2j1m9dNQNjSDYcXoXJ2iEok8DN2+yqy6Q/ObDzmJYUwj3YWz3pZJ563WItDiQaHcTk20vrk5nE+Jtgptp48v6UwT/P9Fs0qVyZpFWf768xUa30AnPO1Qxg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=mGUZ45zW3Oss+RnMjUs6YswPF23wR+wVzbi/RZrlHEI=; b=TLm7yZYHPT8aeZWb/navW71DB7JmDLu+A49s5bVytrtqNi6Zi9pjdANj6ATA/45Ky2eRgvHzXvjRKE6bEqE8/n5lxHkL9JgzXtu/5VpxrRmWpC8utUjOVIrdexpZlc3KcXewDmpXksH67lW1fYyfguHNk9qTZ8zNocea0TRQBRNLKFCEY6APc6FXN41R7kGjVwr+AS3qKbX2Q1YCDumnZiaWQe1udtp/Lkwk72E/10YBDEimMcmSoHPJq5eUsuRvJ4UtQDetjqXdOsG2HQpgb8FKOHZ14sm1XREFhL2lId9Q+Q8RaRA6yI7LgPqV/GeYnyjcnr/hEQQG7RpDdG7AbA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mGUZ45zW3Oss+RnMjUs6YswPF23wR+wVzbi/RZrlHEI=; b=jgYIygmfpn9Url5C4d5pj/RhIcp1INGxXPEIpl0n2kGE7TrjDMlbWiZ7dEg/JvLP33Bl0jayFpzsJDoEwcd7gnZCPEtn1jyn+JvNNCZ7D3GygNNMx5XBOE8foBzZRu97DFL2B/5sA5T7BAkafdMIVLa2zwrrhP0EMndMng45TLI= Received: from MW5PR13MB5485.namprd13.prod.outlook.com (2603:10b6:303:190::9) by BLAPR13MB4706.namprd13.prod.outlook.com (2603:10b6:208:322::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7633.16; Thu, 30 May 2024 11:43:54 +0000 Received: from MW5PR13MB5485.namprd13.prod.outlook.com ([fe80::6f7a:21e9:60ce:8bb]) by MW5PR13MB5485.namprd13.prod.outlook.com ([fe80::6f7a:21e9:60ce:8bb%3]) with mapi id 15.20.7611.010; Thu, 30 May 2024 11:43:54 +0000 From: James Guichard To: Ron Bonica , The IESG Thread-Topic: Jim Guichard's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT) Thread-Index: AQHasitWbg3Qe+Kt6kCKEcwJc1BRiLGvqN1k Date: Thu, 30 May 2024 11:43:54 +0000 Message-ID: References: <171701972848.56003.16015982163088058594@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2024-05-30T00:50:07.7720000Z;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MW5PR13MB5485:EE_|BLAPR13MB4706:EE_ x-ms-office365-filtering-correlation-id: 573dbbcb-8d30-4601-0005-08dc809dc874 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230031|376005|1800799015|366007|38070700009; x-microsoft-antispam-message-info: =?Windows-1252?Q?X7aIMlFB5CEVIX1eQgKuwvbXuOA3bFOSiithG34TW9QEoTbD0Fit+oFa?= =?Windows-1252?Q?urQ2LTS0AooG6P95NXOBrm+ETSRu4+5Py4ot2m+U6vR2uc3IMdHmgDpZ?= =?Windows-1252?Q?6DQRjgPcQ4rrr50JzL8GbkoYEgA/peY+uN4EppJVxe/53s91pzhQRiLa?= =?Windows-1252?Q?pI15lH4Am1eEvsgKBAulj1KKPW9foabiSy9LPCQGKJYw4ZLodcPwFbPm?= =?Windows-1252?Q?Q2S4szsF1aLEJU+uTzdjLeuxyMr61gMhDzohzpVjzFaBeUCYj0vJRwlf?= =?Windows-1252?Q?n3U4F/zHKgBiWdzo7YN4B0MvB5uZ26WHfvJEgysGCxdd4MR5ezA/Pwrn?= =?Windows-1252?Q?Hwu3q42lyBYviF7Gg8PV6AKKNS/Ilty5vcN4Ha//uN8sXNlHuVF4hxra?= =?Windows-1252?Q?SYhXipCnasgLGEoS9bpyHGjfbvt0wzCMHA9I5OcpLqh+zcmrnT5+KW31?= =?Windows-1252?Q?3cwTru/HGihGWYvk6sskEqH844RsrG4+xr12DOuuRyyW1mEThYhyLxiE?= =?Windows-1252?Q?dTtK4cH+VybxnAdxCJ+1Wwhms0+RZgOAZECJIsymHiMZHP05b4ylijNH?= =?Windows-1252?Q?31yL/W73JEAWxnAqxVjBp28KZLhEqZeoAKMRZgyvU9aCaDO7x4g9yEcB?= =?Windows-1252?Q?fh6ZbpJp9+W1dZ1DtWwumy8uFEIomOzuSJIvC32kD3T+edvpAVXPBvDe?= =?Windows-1252?Q?jkA8Ljor04bA9Xt0hsdoS7Ic/SRtMtmUNnbbUP1gyJam1sl9ShQJdsW/?= =?Windows-1252?Q?eLcwv0qzzAYw64P9Yfk8npSEGleE/zf9G2H5sbXKruGEVn5fESA830Z/?= =?Windows-1252?Q?mwNuAROR3DXmnZ9mhKhTUyf3qEtLx0sBR7MyD+vJAxBonf6W8dHtupZ8?= =?Windows-1252?Q?0h+3on+GJE5nOzA4Nsi9UYetJXsbkKg6xix0HJR0o+xv7fVNt+Y7mbcj?= =?Windows-1252?Q?wJI7f1l/qpVRbf0KoKNE9IAgWYahU9oZW1+EZWHlSOAf6UveICfNNyB4?= =?Windows-1252?Q?Oa0pO2wq8CDWpHtNclhzDsgc+Y9RxPoMf4AHAEnhNIJv31cfWeO/3ta8?= =?Windows-1252?Q?LpR18TghLEdFsxyEGkThtu+yQnDzk5a3+pkO5EUNjszAXIduRTWdOHiW?= =?Windows-1252?Q?fns9evV+F5DNDxObfoBbsDuAjOQIsbGlQ3cv96D3Hx5MRsM3ddbmlnee?= =?Windows-1252?Q?WaBCWJYgtL6TTP+nvGmOIqWdEPBImCLeboH9S3l/Wl4o7yuVxDVfOhSQ?= =?Windows-1252?Q?YwfZbTQMznUomHAAJtPRT+MTnrpzq/mtpTgrxueolDKKDDE58Ef/sf/3?= =?Windows-1252?Q?wdMfFnsSatRLBG4MZHlhqkkBW4fQVUGSYIaxAZWU5gHXF4+cGi2rrUE4?= =?Windows-1252?Q?liQLlqJgisDFHR/ix2Dfv+1v0rVHtXx1wlY=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW5PR13MB5485.namprd13.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(1800799015)(366007)(38070700009);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?rGBfis2g/9ypEQdqbZ2xpShpwC6N66MDyqYUniPr5OaN71CRDw9mjIC0?= =?Windows-1252?Q?JLAeaEJeZo3OroyPHawFcQeFABAJqTKYOpb61kqDlZafGT01orj+CsFQ?= =?Windows-1252?Q?3AKAIrtNxc9Ol6kZxSW60R9jE/tmRjhnV8SiloBFKcdj+/+GLIj1g2ri?= =?Windows-1252?Q?TvfiZ75dLX2GWTqXVgJ3TAOZU1ZjkACOO/vfH1BkByYz9Fr3G7Gx1np9?= =?Windows-1252?Q?nr+JrS8qc8Y/iy4AHmzmeqvGD1E+j7414h2OSKWbJ4ScM8CcELSX2D1W?= =?Windows-1252?Q?rvzICCZ5jemEBzpPrKumBoNgc2a4CRVRdCB8OGGmj1d2hoIWGKMdDuug?= =?Windows-1252?Q?LPDFOG9MXwWcBFhdnxFqK3GKnmzsrRFO1YKL5EnMoMzGEt5WoVQRtfD8?= =?Windows-1252?Q?A7cVf1FXsC0yYBTfV3YtQf0lwpgPYrTwG8ZxUbUkQC0KsOmq4niEQgt6?= =?Windows-1252?Q?9CTQREZN3SeiXl3JxQmvATXXOLXcZ62Ev/yxF4uCtuEhd1BsytXL9Qba?= =?Windows-1252?Q?uoCNpX4j/cAwMwfUMlV4xsyXv1Ivgb7nCRORXsltppbKN3feK+EvyEtz?= =?Windows-1252?Q?v22osekNGqitgJjfCKJcQbf6pVV6m+tq5GkLqwQe5elmvnRHQ9N0pdAO?= =?Windows-1252?Q?E4ZHk6m10Q5XDk6daEjga2/55/DDPSMu+xOpIKJd53gcdf+RL8r5/bwS?= =?Windows-1252?Q?TpiEmSFkHzKDwZmZe4fUMRTWBua+2laq5Xi2HZ/rJYJfj727Lz9EheQa?= =?Windows-1252?Q?3bZzLhvrvu0ZsvyOvBLSs6fsMY4+IvUJvDujTeEhLA+8gufIftf2pzTz?= =?Windows-1252?Q?m9FZ/bMjdn5NgDjD+pDTtu7IoqTQpfsuOBAJ4K+crTSSeD/KaFi7knXh?= =?Windows-1252?Q?xgc2z1uOaMR6R/1eM1kAZVA9ou07LsDOjGLMgWwJYpsERpfHCcQS37Yw?= =?Windows-1252?Q?B0vBJ+p8hr5sH3JshMKGc94ZwzkeLaWPqiPYe6hhqYy8ludftl+iqG1A?= =?Windows-1252?Q?VVdJQD+WGezP1KUFmCdYqyfDcJqkJ6VLD+jXOmd/fcMwkj9vCAMTDsLq?= =?Windows-1252?Q?FG/4+r/BtzyvFWvQh9bqTcNvvO7HVLCsGnUZ6xXFhq28Se0uPKekw+or?= =?Windows-1252?Q?CB0UWoknFyhiu747VmCE5hjwVqaOJi467wQjE/EjCQD9k2Zp6FbHWyWl?= =?Windows-1252?Q?pAbS3a6DHKS/sHNCkaO8aY7ddqrDUl8UPkX52SmZdozNeT0VJt8IqL1U?= =?Windows-1252?Q?GTvbLPE6dLb84hlFHyL2FOB3cgWKjHqWx4uyxk6mJKViHKwNEaPkhpKd?= =?Windows-1252?Q?beB1ATIBTU/Mmc2IgkiRIAhXLOdHcsyHJ+cfAkh3n2jzu0R1e95Xy2kC?= =?Windows-1252?Q?l5mZ+c98ONcczMeJsAM5H8TDPta3DOwCPTbwtJXo/uQIbarHoDfXoKrZ?= =?Windows-1252?Q?121hCHXkkEsCD/ojWbJjSRqMX9Gy3eg2dOL5+XnPalC6A0+SiOckduWd?= =?Windows-1252?Q?r/5DQzWn5hG8k39do3TJVRtraDJfBSLu5XWdrTZUlSQjwcYnCT/m5LA4?= =?Windows-1252?Q?cONMGOBV6JDKureHojJFXknqZbdm0tJtj3rMi/WL5QX2Juf51g/BD36D?= =?Windows-1252?Q?g1BG+vLtq1dUOPOptbO5Jsd10DZ6fDpJwcR3+kq66Y4PHbpx184+F+Fp?= =?Windows-1252?Q?BiLG0pwjr1lOZXzpBYf6b4G0U1EC7u2or+EW2+xxO1cpCHYO/EnRf7E9?= =?Windows-1252?Q?V4b7cHczWHsJmF2jifWeZYO3PGiODMkPff5fpjSjuMfj1k9DQbIgpHLm?= =?Windows-1252?Q?ifV63g=3D=3D?= Content-Type: multipart/alternative; boundary="_000_MW5PR13MB548589D1C8BC2B107AF46CFBD2F32MW5PR13MB5485namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW5PR13MB5485.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 573dbbcb-8d30-4601-0005-08dc809dc874 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2024 11:43:54.0488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: y6Gzj8XrjABN7LZyr96XLWFJkGq+Jq8Awss0V8xqd6TkwOfLDF99hRRVGAfu5l56QiL1OG0saqKAbFqBYXzAGg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR13MB4706 Message-ID-Hash: AW7MMWDLDGHHXEZRG5X4O3GQBQTUKYHW X-Message-ID-Hash: AW7MMWDLDGHHXEZRG5X4O3GQBQTUKYHW X-MailFrom: james.n.guichard@futurewei.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "draft-ietf-6man-comp-rtg-hdr@ietf.org" , "6man-chairs@ietf.org" <6man-chairs@ietf.org>, "ipv6@ietf.org" , "bob.hinden@gmail.com" X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BIPv6=5DRe=3A_Jim_Guichard=27s_Discuss_on_draft-ietf-6man-comp-r?= =?utf-8?q?tg-hdr-08=3A_=28with_DISCUSS_and_COMMENT=29?= List-Id: "IPv6 Maintenance Working Group (6man)" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_MW5PR13MB548589D1C8BC2B107AF46CFBD2F32MW5PR13MB5485namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Ron, appreciate you taking care of this in such a timely manner. Jim From: Ron Bonica Date: Wednesday, May 29, 2024 at 8:50 PM To: The IESG , James Guichard Cc: draft-ietf-6man-comp-rtg-hdr@ietf.org , 6man-chairs@ietf.org <6man-chairs@ietf.org>, ipv6@ietf.org , furry13@gmail.com , bob.hinden@gmail.com , bob.hinden@gmail.com Subject: Re: Jim Guichard's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (wi= th DISCUSS and COMMENT) Jim, I have removed Section 7 and posted a new version. This satisfies your DISC= USS and one of Eric's DISCUSS's. Ron Juniper Business Use Only ________________________________ From: Jim Guichard via Datatracker Sent: Wednesday, May 29, 2024 5:55 PM To: The IESG Cc: draft-ietf-6man-comp-rtg-hdr@ietf.org ; 6man-chairs@ietf.org <6man-chairs@ietf.org>; ipv6@ietf.org ; furry13@gmail.com ; bob.hinden@gmail.com ; bob.hinden@gmail.com Subject: Jim Guichard's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with D= ISCUSS and COMMENT) [External Email. Be cautious of content] Jim Guichard has entered the following ballot position for draft-ietf-6man-comp-rtg-hdr-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/grou= ps/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!CtSfY4Ukz5xO_= 1x2KKbbtEi1Fax4xmb9rX8QQ9PX5AajwVpD25H0vtlybxZODNnHZM9oK9g__m9m1Gw$ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6ma= n-comp-rtg-hdr/__;!!NEt6yMaO-gk!CtSfY4Ukz5xO_1x2KKbbtEi1Fax4xmb9rX8QQ9PX5Aa= jwVpD25H0vtlybxZODNnHZM9oK9g_lQER24s$ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I would like to DISCUSS Section 7 of the document as I have a few concerns = and question whether the section is even necessary. The relevant text from this section is as follows: When a packet containing the CRH header leaves its source, it do= es not include its final destination address. The final destinatio= n address is not added to the packet until the final CRH SID is resolved. Jim> This first paragraph just seems to document what routing headers do - = the IPv6 destination address of the packet is not the final destination as carr= ied in the last entry in the routing header. Okay, got that but then the text j= umps to talk about address transparency but this concept is nothing new in the presence of routing headers. While destination address transparency enhances privacy, it prev= ents intermediate nodes from verifying transport layer checksums. Jim> Now the text introduces the notion that address transparency somehow enhances privacy - how and why is that relevant? I think you are trying to highlight that because addresses that are not the ultimate destination are carried in the IPv6 destination address, and the routing header may have on= e or more other addresses (these being the 'transparent' ones), then an intermed= iate node might have trouble verifying transport layer checksums. If so, why not just say if you use CRH then intermediate nodes may not be able to calculat= e transport layer checksums unless they are CRH aware? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few additional comments (I have included line numbers from idnits for the latest version): 18 This document describes an experiment in which two new IPv6 Rout= ing 19 headers are implemented and deployed. Collectively, they are ca= lled 20 the Compact Routing Headers (CRH). Individually, they are calle= d 21 CRH-16 and CRH-32. Jim> This first paragraph seems to overlap with the second paragraph with i= ts discussion of implementation and deployment. Perhaps reword it as follows a= s the second paragraph is clear enough as to the purpose of the experiment. This document describes an experiment in which two new IPv6 Rout= ing headers are defined; Collectively called the Compact Routing Hea= ders (CRH). Individually, they are called CRH-16 and CRH-32. 89 1. Introduction 91 IPv6 [RFC8200] source nodes use Routing headers to specify the p= ath 92 that a packet takes to its destination. The IETF has defined se= veral 93 Routing header types [IANA-RH]. This document defines two new Jim> [IANA-RH] defines =91Routing Types=92 not =91Routing header types=92. = It would be more precise to just say =91Routing Types=92. 107 * Because Path MTU Discovery (PMTUD) [RFC8201] is not entirely 108 reliable, many IPv6 hosts refrain from sending packets larger= than 109 the IPv6 minimum link MTU (i.e., 1280 bytes). When packets a= re 110 small, the overhead imposed by large Routing Headers is exces= sive. Jim> The above text is making a statement that may or may not be true depen= dent upon who one talks to ;-) I would suggest to say, =91large Routing Headers = may be excessive=92. 207 The topological function specifies how the processing node forwa= rds 208 the packet to the interface identified by the IPv6 address. The 209 following are examples: Jim> Is this an exhaustive list? If not, please specify that. 232 The above-mentoned mechanisms are not defined here and are beyon= d the Jim> s/above-mentoned/above-mentioned 250 * If L is greater than Hdr Ext Len, discard the packet and send= an 251 ICMPv6 Parameter Problem, Code 0, message to the Source Addre= ss, 252 pointing to the Segments Left field. Jim> Why would the ICMPv6 message point to the Segments Left field? Shouldn= =92t it point to the Hdr Ext Len field? 332 8. Applications And SIDs Jim> s/Applications And SIDs/Applications and SIDs --_000_MW5PR13MB548589D1C8BC2B107AF46CFBD2F32MW5PR13MB5485namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thanks Ron, appreci= ate you taking care of this in such a timely manner.

 

Jim

 

From: Ron Bonica <rbonica@juniper.net&g= t;
Date: Wednesday, May 29, 2024 at 8:50 PM
To: The IESG <iesg@ietf.org>, James Guichard <james.n.guich= ard@futurewei.com>
Cc: draft-ietf-6man-comp-rtg-hdr@ietf.org <draft-ietf-6man-comp-r= tg-hdr@ietf.org>, 6man-chairs@ietf.org <6man-chairs@ietf.org>, ipv= 6@ietf.org <ipv6@ietf.org>, furry13@gmail.com <furry13@gmail.com&g= t;, bob.hinden@gmail.com <bob.hinden@gmail.com>, bob.hinden@gmail.com <bob.hinden@gmail.com>
Subject: Re: Jim Guichard's Discuss on draft-ietf-6man-comp-rtg-hdr-= 08: (with DISCUSS and COMMENT)

Jim,

&n= bsp;

I have = removed Section 7 and posted a new version. This satisfies your DISCUSS and= one of Eric's  DISCUSS's.

&n= bsp;

  =                      = ;                     &nb= sp;                Ron

&n= bsp;

 

Juniper Business Use Only

From: Jim Gu= ichard via Datatracker <noreply@ietf.org>
Sent: Wednesday, May 29, 2024 5:55 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-comp-rtg-hdr@ietf.org <draft-ietf-6man-comp-r= tg-hdr@ietf.org>; 6man-chairs@ietf.org <6man-chairs@ietf.org>; ipv= 6@ietf.org <ipv6@ietf.org>; furry13@gmail.com <furry13@gmail.com&g= t;; bob.hinden@gmail.com <bob.hinden@gmail.com>; bob.hinden@gmail.com <bob.hinden@gmail.com>
Subject: Jim Guichard's Discuss on draft-ietf-6man-comp-rtg-hdr-08: = (with DISCUSS and COMMENT)

 

[External Email. Be cautious of content]


Jim Guichard has entered the following ballot position for
draft-ietf-6man-comp-rtg-hdr-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statemen= ts/handling-ballot-positions/__;!!NEt6yMaO-gk!CtSfY4Ukz5xO_1x2KKbbtEi1Fax4x= mb9rX8QQ9PX5AajwVpD25H0vtlybxZODNnHZM9oK9g__m9m1Gw$
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3= /__https://datatracker.ietf.org/doc/draft-ietf-6man-comp-rtg-hdr/__;!!NEt6y= MaO-gk!CtSfY4Ukz5xO_1x2KKbbtEi1Fax4xmb9rX8QQ9PX5AajwVpD25H0vtlybxZODNnHZM9o= K9g_lQER24s$



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I would like to DISCUSS Section 7 of the document as I have a few concerns = and
question whether the section is even necessary. The relevant text from this=
section is as follows:

           When a packet = containing the CRH header leaves its source, it does
           not include it= s final destination address.  The final destination
           address is not= added to the packet until the final CRH SID is
           resolved.

Jim> This first paragraph just seems to document what routing headers do= - the
IPv6 destination address of the packet is not the final destination as carr= ied
in the last entry in the routing header. Okay, got that but then the text j= umps
to talk about address transparency but this concept is nothing new in the presence of routing headers.

           While destinat= ion address transparency enhances privacy, it prevents
           intermediate n= odes from verifying transport layer checksums.

Jim> Now the text introduces the notion that address transparency someho= w
enhances privacy - how and why is that relevant? I think you are trying to<= br> highlight that because addresses that are not the ultimate destination are<= br> carried in the IPv6 destination address, and the routing header may have on= e or
more other addresses (these being the 'transparent' ones), then an intermed= iate
node might have trouble verifying transport layer checksums. If so, why not=
just say if you use CRH then intermediate nodes may not be able to calculat= e
transport layer checksums unless they are CRH aware?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A few additional comments (I have included line numbers from idnits for the=
latest version):

18         This document describes = an experiment in which two new IPv6 Routing
19         headers are implemented = and deployed.  Collectively, they are called
20         the Compact Routing Head= ers (CRH).  Individually, they are called
21         CRH-16 and CRH-32.

Jim> This first paragraph seems to overlap with the second paragraph wit= h its
discussion of implementation and deployment. Perhaps reword it as follows a= s
the second paragraph is clear enough as to the purpose of the experiment.
           This document = describes an experiment in which two new IPv6 Routing
           headers are de= fined; Collectively called the Compact Routing Headers
           (CRH).  I= ndividually, they are called CRH-16 and CRH-32.

89      1.  Introduction

91         IPv6 [RFC8200] source no= des use Routing headers to specify the path
92         that a packet takes to i= ts destination.  The IETF has defined several
93         Routing header types [IA= NA-RH].  This document defines two new

Jim> [IANA-RH] defines =91Routing Types=92 not =91Routing header types= =92. It would be
more precise to just say =91Routing Types=92.

107        *  Because Path MTU Disc= overy (PMTUD) [RFC8201] is not entirely
108           reliable, m= any IPv6 hosts refrain from sending packets larger than
109           the IPv6 mi= nimum link MTU (i.e., 1280 bytes).  When packets are
110           small, the = overhead imposed by large Routing Headers is excessive.

Jim> The above text is making a statement that may or may not be true de= pendent
upon who one talks to ;-) I would suggest to say, =91large Routing Headers = may be
excessive=92.

207        The topological function spec= ifies how the processing node forwards
208        the packet to the interface i= dentified by the IPv6 address.  The
209        following are examples:

Jim> Is this an exhaustive list? If not, please specify that.

232        The above-mentoned mechanisms= are not defined here and are beyond the

Jim> s/above-mentoned/above-mentioned

250        *  If L is greater than = Hdr Ext Len, discard the packet and send an
251           ICMPv6 Para= meter Problem, Code 0, message to the Source Address,
252           pointing to= the Segments Left field.

Jim> Why would the ICMPv6 message point to the Segments Left field? Shou= ldn=92t
it point to the Hdr Ext Len field?

332     8.  Applications And SIDs

Jim> s/Applications And SIDs/Applications and SIDs


--_000_MW5PR13MB548589D1C8BC2B107AF46CFBD2F32MW5PR13MB5485namp_--