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 76D3AC180B64; Wed, 29 May 2024 17:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 (2048-bit key) header.d=juniper.net header.b="jy0tV+Ko"; dkim=pass (1024-bit key) header.d=juniper.net header.b="UlDRSGDZ" 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 FrOMWPQxi-xa; Wed, 29 May 2024 17:27:29 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 06B3EC180B48; Wed, 29 May 2024 17:27:28 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 44TLnWGq020315; Wed, 29 May 2024 17:27:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=PPS1017; bh=lZpMqYeOgjPPUVfmzAkJRBGFky 65cQ+KT9DYOhcRipc=; b=jy0tV+KoOpqbyLsqwzG5cbuonnAza0JFxabjvI+3E3 /dnqsD8hQEzgRB5/kzUAuPvYJn+FJ0TWlGfXmLb8OuFrgcUnI7bDAImCVFF7tPzl in/fE8hc+KF/JI+p8ylsaOBPGohlvAi8vqIP2qeuIWdhN3rSb284M2B+XYr8ApvR w9UYxgvk0aLprpDgbQ8JGTIvDnMt+kDwfWlhQaH0MldjmZEJ5M1tfn3gXs0dm0sH 9cPxwa1xu/qS4SJbsAdpBtm3eUBsUPuMjjwSk545wHkXhELYgxrIXbhFdh9xMQU5 Yr7sTGO3xzaS2y95DLj6aS33AiPOrgKGpKFuyxs0SKPg== Received: from dm5pr21cu001.outbound.protection.outlook.com (mail-centralusazlp17014044.outbound.protection.outlook.com [40.93.13.44]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3ybf3srhy1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 May 2024 17:27:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UGFJ8YSOs2m+CV4t9TglB0MugTBESayEB5f7aONBNshnz7Ao33fLex8K+bQkV1RpMb0Gip5x5ThJWW9v695934n/P0dlSKBVmU3vvTXKx2FHGZDDByEIRKPx7BrMDDEx8g7wOsbBTTzApwuRFNzOHAgomoJGUWp0pEm+tJD8OL9hwV7zaQfGA+koHEYoLqOkC2b0WOdI8QbwoCPwS+5zVxuAhuxRQ3LAhCBndjCV22PqVCsOGhfa24XgtIuwKIGQ33XLEQF40H7jeoYNN6AeUBRFPSOVD1WV7RjZL0K7WucuJPwsfuLmsE4ncNCYbHEaNy/B7zXNfcZCBJMqipnWKw== 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=lZpMqYeOgjPPUVfmzAkJRBGFky65cQ+KT9DYOhcRipc=; b=Ucdng0naltYiV1zPdC5tOGiq4AZpxrfb1vXVILeaZSY93hdKNxEYaGObyGMn2F4/OGb7Aq/sQPzZfCvhkHz/GsqTZyPg/uhymxn9yYyu6cqi9g+E13hHaokYfFt9MVU0k9N5PTmi68WXnDrq6vsG6DHkdhen6KuwNibvh/uO1rNM0QwxtKrao5GSfPU0SNYK+xY16Yzh5SK1XjwLFlf0M/v+tmOt/ytm6cT8rTAVJ7xgrRJJHuCQ4ocxve4fUdzdioJkved7NSUI0u29q2XlAwHSFm+3yX7TasAaEVACm0vD3Ym9F8rKl+t9iOdSF3Gv8qGW9uta4nMI5VZVk6SOeg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lZpMqYeOgjPPUVfmzAkJRBGFky65cQ+KT9DYOhcRipc=; b=UlDRSGDZ/vWhXQ3lNdaiMm3oNcEAR54oPaeG2Xr4njZXMYn+z+5T+7e8OpdnXwATVAcovDjxdO4P/AnctFMjNfmOPxaL1gTP6Q93rgNDiQa9UWu28+M/z7d3tPWVc7SNciqwvMOeNG+hGDtur6tuf9igLghuShWVIL9tAKpXLEg= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by PH7PR05MB10566.namprd05.prod.outlook.com (2603:10b6:510:302::5) 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 00:27:23 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::fdd9:52c5:6d88:4bbe]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::fdd9:52c5:6d88:4bbe%4]) with mapi id 15.20.7633.017; Thu, 30 May 2024 00:27:22 +0000 From: Ron Bonica To: The IESG , =?iso-8859-1?Q?=C9ric_Vyncke?= Thread-Topic: =?iso-8859-1?Q?=C9ric_Vyncke's_Discuss_on_draft-ietf-6man-comp-rtg-hdr-08?= =?iso-8859-1?Q?:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHasfysURST5hweSU6PKROK6DvBn7Gu2q/F Date: Thu, 30 May 2024 00:27:22 +0000 Message-ID: References: <171701017054.52762.15332933554163582477@ietfa.amsl.com> In-Reply-To: <171701017054.52762.15332933554163582477@ietfa.amsl.com> 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:27:21.959Z;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; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: BL0PR05MB5316:EE_|PH7PR05MB10566:EE_ x-ms-office365-filtering-correlation-id: dea670d1-d743-4b9f-03d3-08dc803f460b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230031|376005|366007|1800799015|38070700009; x-microsoft-antispam-message-info: =?iso-8859-1?Q?uDwMRRC2sauogVgAj/1D9RBdViES5JATVPYpSGG/G5QPpciTfaE25T1DV8?= =?iso-8859-1?Q?rbGrZvXZ5lCE6FKpkQv7U2QhkS14IKWlXjSPi5rPuJJrFwJrLCUiYl9tFm?= =?iso-8859-1?Q?Pxp7SCoWF2iRzUwpRjBEGwp1XMn69tMO7wYJsmcMbcOnjTyOQoBXAq1Nnq?= =?iso-8859-1?Q?gKIJcmslLB/9flhmCe4ocHTUCRLvn6S9gxeoyke33/8V7CMmkkyR+EzRY1?= =?iso-8859-1?Q?hLUsJyayrnbFxQVMh4ElDAii+bUvxuHlAl8B1SpzgCNj7g20dXJgO+g9nO?= =?iso-8859-1?Q?e5xfDstnIvPoRvZJyax1H3dls+UP60wKGzH6Cn/oJUJK6GfCdNaQQm4VVS?= =?iso-8859-1?Q?BpbHvCiwr0A+rdMKy0ANIFaE9f1DibU6LwJD70jUL+Q2XWsZdwD763VtlK?= =?iso-8859-1?Q?zcm5aIg0XWrDBdT9pGOZh6W87axst+m7MUPrxDa0Qa73VHj2I2fJYUgraR?= =?iso-8859-1?Q?67+zt0sb7BlDS6mefuGoUOjLvCgqWiQI/wY+KGZUXf5s6CIo0bdG6rkrSH?= =?iso-8859-1?Q?aJHJ2Ik+KaR7gMpqI6ACbCAGNPQn5kzqAxou7V4snVvMguk9yykYeu6G0P?= =?iso-8859-1?Q?p+05ABny7RY1fmh1YYW+fLh7YL7yMnbUbzYEDRI0M5X48JsC48vNOKRZER?= =?iso-8859-1?Q?fvo+up7BRDTNFCAAAjpLHxfYM39WUEFRIT0q4N9eMJa3w3DiJh/41NdjDN?= =?iso-8859-1?Q?He3VjhM93qNBIghr7YxmzTmYPIh01ELn0+9ZNfUWKJ8KlX/6fURnNCahRW?= =?iso-8859-1?Q?L0cDyDykNVcUEmsDpitPBymw4UX0dUOwj0UEV+OdFocruvPFNSXxw1NPa6?= =?iso-8859-1?Q?y1z5N+75Rac9aNc4fK1oL0Qnb/jBa4mSLL02p3amAkqOj8eN5qhiU5zIcp?= =?iso-8859-1?Q?C1ll3eFLM1nwgp+NFkxkYHAaVl3ha2tRYhRTQoMkFoK8951dmDmlHWVwtu?= =?iso-8859-1?Q?oOfNu6A03ZPX9HW8PlXQp7sQ7tMQtYlWji43UYvMca/X5ftaUEW7aZV52Z?= =?iso-8859-1?Q?p61J6UkFm97JuU9IN05om6CGUvG1h7C2gTsPLHnYnlDCyWvhJAMDVuWB1u?= =?iso-8859-1?Q?sLS+cfU5RStjKPKcBkSr1wN49QHCeO/TE7XFJD6RsE9Etnnzwstt3pBe8X?= =?iso-8859-1?Q?fMftKbXYiPKNm8XQOLxz6s+cq0ph4rEwKd+unban48PpLlhHo22nNelx1u?= =?iso-8859-1?Q?5+csqbVoX3Bud5qhr5Ss1UAgYLF1z5kpDmkktQUAG23a97lvzzXSXwRn8y?= =?iso-8859-1?Q?rJBRuddph/Dri8UJuYXk5FoYk5qLzweBYn499S63FAVSZL499glzvNoiKd?= =?iso-8859-1?Q?Bt+rRv4kgn3EDS0esE7GglmYXA=3D=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BL0PR05MB5316.namprd05.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(376005)(366007)(1800799015)(38070700009);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?mxROf1DgUZzCslENim+xlZkKCQiDgs9Cna9NWV7BwjTL2F/k0PEi50q2qy?= =?iso-8859-1?Q?/vJ//smuXKARMjL/8N9lO/45b9x7DiizNDIsmOj7isnxyrqH3pTxt5aZ4e?= =?iso-8859-1?Q?sN7Rce5ZNJ8IoWQCj2ZznER4+tyGL1HBESOGVx2V3o18ao9UmU068RsQaj?= =?iso-8859-1?Q?FCY8sOGKoyzy27dXNBnhzcJWRNrIqYsn+zyc03M+2X/0TNnxRMwsapQPC/?= =?iso-8859-1?Q?UTKop6J/Jl8B1kg3P2UznmpsvcPJrbqLgLMWkAfOtrnOz1FP7KltTsX3Sm?= =?iso-8859-1?Q?J79394d0pTEeWYNn+uBDGMF/dGzLUwVdmNDoKZex+BsCJThomsFiqyrfw1?= =?iso-8859-1?Q?WC4lGssBeaHqSH90epUUXotylIBvMLRj9Iz24zUw4YjmKLEUO/o/oygx6B?= =?iso-8859-1?Q?agjUsQihXIs60/bwFE8LgCU3zAWqOx7dGnId21ZR9trqt4w8m5if4XzMH2?= =?iso-8859-1?Q?RiJz7AkK3ynWkha/NeqJbb6DV6bjh8ki2iMGusxqOviZH02igPZFEU4ze1?= =?iso-8859-1?Q?LCY+g17r4+GUoHJQjrGKJwOsRYrVaLkxi3+HFuZVtmYkv5AUeQ7i8KTapw?= =?iso-8859-1?Q?Is5a7steKu01zMzKV3ztBVcSVQ/6hHVfTtK+SdcPAPxfllI80s9TYiBcnS?= =?iso-8859-1?Q?7CVpYaiX/BgJ2Nv2pyJ8+d0gHP9+uNmtA0w7xk+gjJKX8Cyf8HgAhyueLZ?= =?iso-8859-1?Q?6efCKj6YZ70kUYHHRdm7xRO+l0fmmGFTLCqyYYQ0TVEqC825twoRBWHaX+?= =?iso-8859-1?Q?RtCEro33IKrDnwdF4Y1MtHeqwTW3teWxGqmVj4pNFhweVfYDUUcfUOgNax?= =?iso-8859-1?Q?nzouq9nVANeyPHH2w5f4Idj53uszFzcp5LhEKkRwdMzxfA4DHpBIV9YshP?= =?iso-8859-1?Q?mZjJmKkhjfl8DkYNerdxs3hWNDhiEBkGsRwkeoiFhs2vl/PavdxSLhGsTf?= =?iso-8859-1?Q?S4EzH9kUbNU6TjCHeCdEvDbpgbtW6xmBga7GvTyKT7bhBJxo91fzhQIFzL?= =?iso-8859-1?Q?Uqqrlw5wVquQFiylBNbtzoyXTiq++9brRH5sM5UDteZUIJv/nk5VnMrOj4?= =?iso-8859-1?Q?E4zOwP4VwHBb1qaQJXiaJevVcDcVmJFYcODrRKeX7QCOuFwvi8lKpk8zYY?= =?iso-8859-1?Q?bDcTU2AA139JQQNNw9Ku1/IQdI2RBjvGoWrnQuZ5cEO4kqIYGJfUQ6oo8y?= =?iso-8859-1?Q?Pf9cchyUYVMc/k8JD2zZRMcy6GPk47DYFLM97NqtucWew8kIlh22DeDyLH?= =?iso-8859-1?Q?8mdDXOt44rUhgDlsXdaOHLp/XPCGRfsQO2eLRfHIE0Y4gGJUMCWVcDkrSg?= =?iso-8859-1?Q?zR66uOlysNNkUHgQ9l6V5FaDjnPeuj8+qVVwO9eSHXWEMi2+NQsPolyq5l?= =?iso-8859-1?Q?K6Q4y3CLE/xU5UkgPLa297RsJGs6Kp47nDZbfZmLH0B+UAwxBfOlp1yQnx?= =?iso-8859-1?Q?+7ZluA2Ro+mI9cj0CVwwL1EqOc6kbE9Oxy+LIa9KnANahtciRJXu0Kh6fu?= =?iso-8859-1?Q?aSRsJrxDW67IHV6DAJOGx4A8DOPSZNRl53SzffSbbesAz9UtG1DcGPl7dp?= =?iso-8859-1?Q?lo82nAmn8b3YzmO3zRv/1gwbCd3orLX0Ke3CK/xPIPUTUJGg7mOFvpfwmU?= =?iso-8859-1?Q?9V3z/YLxFm/8I=3D?= Content-Type: multipart/alternative; boundary="_000_BL0PR05MB5316FDC377FB931E50CEAA76AEF22BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dea670d1-d743-4b9f-03d3-08dc803f460b X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2024 00:27:22.6101 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FQ0Y6ugjSc4mb3KzscMp2p0PpSi0OJ5OWBC/udEhY2k9hJGr31PJ9ANRh/7QMIt+0wM7HY7j/hh5VwImTgDJPg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR05MB10566 X-Proofpoint-GUID: csJraYQNuqePZWPc9bB3smfUkb5XeKBx X-Proofpoint-ORIG-GUID: csJraYQNuqePZWPc9bB3smfUkb5XeKBx X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16 definitions=2024-05-29_16,2024-05-28_01,2024-05-17_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 suspectscore=0 mlxlogscore=999 impostorscore=0 malwarescore=0 adultscore=0 clxscore=1015 bulkscore=0 phishscore=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2405170001 definitions=main-2405300001 Message-ID-Hash: LEO2KKOBWK47F527G4RG7COJGYJPPN4S X-Message-ID-Hash: LEO2KKOBWK47F527G4RG7COJGYJPPN4S X-MailFrom: rbonica@juniper.net 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_=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-6man-co?= =?utf-8?q?mp-rtg-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_BL0PR05MB5316FDC377FB931E50CEAA76AEF22BL0PR05MB5316namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Eric, See response, inline [RB]. I will post an updated version tonight so that you can clear your discuss. Ron Juniper Business Use Only ________________________________ From: =C9ric Vyncke via Datatracker Sent: Wednesday, May 29, 2024 3:16 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: =C9ric Vyncke's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with = DISCUSS and COMMENT) [External Email. Be cautious of content] =C9ric Vyncke 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!DVJoms2WoGvxm= xqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmcjnBaXmI$ 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!DVJoms2WoGvxmxqkffXENdtHNjV3fbIs-eqSaGApHrZ= _QLRG6sy7korNjjBzml5sJ7eFURmcZZQBom0$ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # =C9ric Vyncke, INT AD, comments for draft-ietf-6man-comp-rtg-hdr-08 Thank you for the work put into this document. I do like the idea of compressing SRH-like header, but the document has room for improvements. Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only = for my own education), and some nits. Special thanks to Bob Hinden for the shepherd's detailed write-up including= the WG consensus *but* it lacks the justification of the intended status (and I= MHO experimental is the right one). I hope that this review helps to improve the document, Regards, -=E9ric # DISCUSS (blocking) As noted in https://urldefense.com/v3/__https://www.ietf.org/blog/handling-= iesg-ballot-positions/__;!!NEt6yMaO-gk!DVJoms2WoGvxmxqkffXENdtHNjV3fbIs-eqS= aGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmcZOFq8Vg$ , a DISCUSS ballot is a request to have a discussion on the following topics: ## Section 5 `Decrement the IPv6 Hop Limit.` what do to when hop limit is 0 ? Is there a deviation from RFC 8200 section 3, else why repeating this step ? [RB] Agree. IPv6 already decrements the Hop Limit as it processes the base = IPv6 header. So, decrementing it again would be a bad thing. I have removed= that step ## Section 7 It is not clear to me why this document needs to make an allowance for intermediate nodes (sic) that verify transport layer checksums. Transport l= ayer checksums are expected to be verified by the Transport layer endpoints and = not in the network. So since when the Internet architecture has changed to take care of `it prevents intermediate nodes from verifying transport layer checksums`? Actual references are required for such statement. And, explanations should be given whether this "sentence" helps RFC 7258 pervasi= ve monitoring perhaps in the security considerations section. [RB] Agree. I have removed section 7 in its entirety. ## Section 11 While not a real DISCUSS criteria, I am really surprised to see an IPv4-lik= e notation for CRH SID. [RB] Why not? IPv4-like is a convenient notation for 32-bit values. Is ther= e a reason not to like it? Can you propose an alternaive? ## Section 12 As AH is end-to-end, intermediate nodes do not have the shared secret, henc= e `The CRH is not compatibile with AH processing at intermediate nodes.` is useless and confusing. Please remove. Very similar to the DISCUSS about sec= tion 7. [RB] Agree. I have removed that sentence ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # COMMENTS (non-blocking) ## Abstract Can we really write `deployed` for an experimental I-D? [RB] The purpose of any IETF experiment is to demonstrate that something ca= n be deployed. You might want to deploy in a risk-free environment at first= . But if you don't demonstrate deployability, why bother. ## Section 1 s/to its destination/to its destination(s)/ (think multicast/anycast). Twic= e in the section ;) [RB] Done Suggest to move the motivation to its own section. [RB] I am going to push back on this. If we did that, the introduction woul= d contain only one paragraph. ## Section 3 Any recommendation on when to do `The first CRH SID in the path can be omit= ted from the list.`? [RB] Changed the sentence to read "The first CRH SID in the path is omitted= from the list unless there is some reason to preserve it." What is the expected behavior of any CRH-aware router and final node(s) whe= n `the Type- specific data field MUST be padded with zeros` is not respected = ? [RB] If it is padded with non-zero data, there should be no problem. CRH pr= ocessing does not inspect padding values. [RB] If it is not padded at all, IPv6 will not be able to find the beginnin= g of the header following the CRH and the packet will be dropped. [RB] I don't think that we need to mention this because it is generic IPv6 = behavior and not specific to CRH. ## Section 4 Can the IPv6 address in the CRH-FIB be a link-local or multicast or can onl= y be a unicast ? Section 5 gives some more explanations, but an early one would = be better. [RB] Added the following: [RB] The IPv6 address can be a Global Unicast Address (GUA), a Link Local Unicas= t address (LLU), or a Unique Local Address (ULA). When the IPv6 address is the final address in a= path, it can also be a multicast address. ## Section 5 The first bullet can probably be removed as it is the normal behavior of an= y IPv6 node per RFC 8200. [RB] Done `If Hdr Ext Len indicates that the CRH is larger than the implementation ca= n process, ` suggest using code 6 per https://urldefense.com/v3/__https://www.iana.org/assignments/icmpv6-paramet= ers/icmpv6-parameters.xhtml*icmpv6-parameters-codes-5__;Iw!!NEt6yMaO-gk!DVJ= oms2WoGvxmxqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmc25Y-Tx= M$ [RB] Done While wasting octets with too large CRH (i.e., larger than the minimum leng= th) is a bad thing, does it deserve to discard the packet on transit ? Why not requesting the source to enforce this mimimum length? [RB] This is defensive coding. The source may be buggy or hostile. If the C= RH is malformed, the processing node should attempt to access bits beyond t= he end of it. This could cause a router to crash. `If the search does not return a CRH-FIB entry` is the code 0 the most suit= able code ? If not, why not creating one ? Or even using ICMPv6 code 1 'destinat= ion unreachable' ? [RB] I'm going to push back on this. Destination Unreachable isn't appropri= ate because it suggests that the destination in the base IPv6 header isn't = reachable. That isn't the case. I could create a new code, but I don't want= to clutter up the registry with experimental stuff. So, parameter problem = is good enough for now `If Segments Left is greater than 0` this will always be the case per first bullet `If Segments Left equals 0` ;-) [RB] Not true. Segments left was decremented two steps above. The reader will welcome a justification of `CRH-FIB entry contains a multic= ast address, discard the packet and`. [RB] Added a parenthetic comment that this prevents packet storms. ## Section 6 I guess that this is linked to RFC 4302 (AH), so, please state this clearly= . [RB] Yes, RFC 4302 demands that this section is present. But do we really n= eed another reference back to RFC 4302? ## Section 7 Is it about `Destination Address Transparency` or privacy ? [RB] This section was deleted in response to your previous comment. ## Section 8 `Each CRH SID is processed by exactly one node.` isn't it rather "Each CRH = SID is processed by exactly one CRH-configured router whose one address matches= the packet destination address" ? [RB] Done ## Section 9 The title should rather be "operational considerations" [RB] Done What are the "representations described herein" in ` It is recommended that= the experimental versions of PING use the text representations described herein= ` ? Is it about section 11 ? Then please add a forward reference. [RB] Done ## Section 10 This is the usual considerations about ICMP, please consider to remove this section. Or refer for section 5 of RFC 4443. [RB] Removed ## Section 11 Beside the above semi-DISCUSS, please state that hexadecimal should be in l= ower case. [RB] Words "lower-case" added. ## Section 12 `The Source Address does not identify an interface on a trusted node.` is t= here any hint how this can be done ? How will it scale if all CRH-enabled router must know all the specific address of all trusted nodes ? The same scalabil= ity issue for `The ACL discards packets whose source address identifies an interface on a trusted node.` [RB] This is one of the things that we ask the experimenters to report on. = Some numbering plans support efficient ACLs. Others don't [RB] SRv6 has the same problems. Maybe we should develop common text that w= e both can use. ## Section 13 If the Wireshark/tcpdump modifications (cited in section 9) are public, the= n references to code will be welcome. [RB] The citations of which I am aware are comprehensible to Wireshark/tcpd= ump developers, but not to the general public. Do you know of any better ci= tations. `Interoperability among these implementations has not yet been demonstrated= .` should rather be in section 14 'experimental results' [RB] Not really. Section 14 doesn't provide experimental results. It descri= bes experimental result documents that should be written when the experimen= t is complete. ## Section 14 I am indeed very curious to see the experimental result of ``` Mechanism used to populate the FIB Scale of deployment [RB] Is this comment within the scope of this document? Or are you anticipa= ting the experimental results document? ``` even if the text states in one year after publication as an RFC, this work started back in 2019 and was adopted in 2023, do we already have some resul= ts ? [RB] Again, is this comment within the scope of this document? Or are you a= nticipating the experimental results document? What are the possible next steps as seen by the authors / 6MAN WG is the experiment is assumed to be successful ? And what are the criteria to decla= re a successful experiment ? [RB] Section 14 describes experimental results to be reported. To the best = of my knowledge, these results will provide a pretty good picture of whethe= r the experiment succeeded or failed. [RB] If the experiment fails, it fails. If it succeeds, the community will = have a few options. Is there any outcome to which you would object. Ron # NITS (non-blocking / cosmetic) ## Section 12 s/This is becasue /This is because/ --_000_BL0PR05MB5316FDC377FB931E50CEAA76AEF22BL0PR05MB5316namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Eric,

See response, inline [RB].

I will post an updated version tonight so that you can clear your discuss.<= /div>

                     = ;          Ron


Juniper Business Use Only

From: =C9ric= Vyncke via Datatracker <noreply@ietf.org>
Sent: Wednesday, May 29, 2024 3:16 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-comp-rtg-hdr@ietf.org <draft-ietf-6man-c= omp-rtg-hdr@ietf.org>; 6man-chairs@ietf.org <6man-chairs@ietf.org>= ; ipv6@ietf.org <ipv6@ietf.org>; furry13@gmail.com <furry13@gmail.= com>; bob.hinden@gmail.com <bob.hinden@gmail.com>; bob.hinden@gmai= l.com <bob.hinden@gmail.com>
Subject: =C9ric Vyncke's Discuss on draft-ietf-6man-comp-rtg-hd= r-08: (with DISCUSS and COMMENT)
 
[External Email. B= e cautious of content]


=C9ric Vyncke 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!DVJoms2WoGvxmxqkffXENdtHNjV3f= bIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmcjnBaXmI$
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.ie= tf.org/doc/draft-ietf-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!DVJoms2WoGvxmxqkff= XENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmcZZQBom0$



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


# =C9ric Vyncke, INT AD, comments for draft-ietf-6man-comp-rtg-hdr-08

Thank you for the work put into this document. I do like the idea of
compressing SRH-like header, but the document has room for improvements.
Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only = for
my own education), and some nits.

Special thanks to Bob Hinden for the shepherd's detailed write-up including= the
WG consensus *but* it lacks the justification of the intended status (and I= MHO
experimental is the right one).

I hope that this review helps to improve the document,

Regards,

-=E9ric

# DISCUSS (blocking)

As noted in https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-= positions/__;!!NEt6yMaO-gk!DVJoms2WoGvxmxqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG= 6sy7korNjjBzml5sJ7eFURmcZOFq8Vg$ , a
DISCUSS ballot is a request to have a discussion on the following topics:
## Section 5

`Decrement the IPv6 Hop Limit.` what do to when hop limit is 0 ? Is there a=
deviation from RFC 8200 section 3, else why repeating this step ?

[RB] Agree. IPv6 a= lready decrements the Hop Limit as it processes the base IPv6 header. So, d= ecrementing it again would be a bad thing. I have removed that step

## Section 7

It is not clear to me why this document needs to make an allowance for
intermediate nodes (sic) that verify transport layer checksums. Transport l= ayer
checksums are expected to be verified by the Transport layer endpoints and = not
in the network. So since when the Internet architecture has changed to take=
care of `it prevents intermediate nodes from verifying transport layer
checksums`? Actual references are required for such statement. And,
explanations should be given whether this "sentence" helps RFC 72= 58 pervasive
monitoring perhaps in the security considerations section.

[RB] Agree. I have= removed section 7 in its entirety.

## Section 11

While not a real DISCUSS criteria, I am really surprised to see an IPv4-lik= e
notation for CRH SID.

[RB] Why not? IPv4= -like is a convenient notation for 32-bit values. Is there a reason not to = like it? Can you propose an alternaive?

## Section 12

As AH is end-to-end, intermediate nodes do not have the shared secret, henc= e
`The CRH is not compatibile with AH processing at intermediate nodes.` is useless and confusing. Please remove. Very similar to the DISCUSS about sec= tion
7.

[RB] Agree. I have= removed that sentence


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


# COMMENTS (non-blocking)

## Abstract

Can we really write `deployed` for an experimental I-D?

[RB] The purpose o= f any IETF experiment is to demonstrate that something can be deployed. You= might want to deploy in a risk-free environment at first. But if you don't= demonstrate deployability, why bother.

## Section 1

s/to its destination/to its destination(s)/ (think multicast/anycast). Twic= e in
the section ;)

[RB] Done

Suggest to move the motivation to its own section.

[RB] I am going to push back on this. If we did that, the introduction w= ould contain only one paragraph.


## Section 3

Any recommendation on when to do `The first CRH SID in the path can be omit= ted
from the list.`?

[RB] Changed the s= entence to read "
What is the expected behavior of any CRH-aware router and final node(s) whe= n
`the Type- specific data field MUST be padded with zeros` is not respected = ?

[RB] If it is padd= ed with non-zero data, there should be no problem. CRH processing does not = inspect padding values.

[RB] If it is not = padded at all, IPv6 will not be able to find the beginning of the header fo= llowing the CRH and the packet will be dropped. 

[RB] I don't think= that we need to mention this because it is generic IPv6 behavior and not s= pecific to CRH.


## Section 4

Can the IPv6 address in the CRH-FIB be a link-local or multicast or can onl= y be
a unicast ? Section 5 gives some more explanations, but an early one would = be
better.

[RB] Added the fol= lowing:

[RB] 
The IPv6 address can be a Global Unicast Address (GUA), a Link Local Unicas= t address (LLU), or a
Unique Local Address (ULA). When the IPv6 address is the final address in a= path,
it can also be a multicast address.


## Section 5

The first bullet can probably be removed as it is the normal behavior of an= y
IPv6 node per RFC 8200.

[RB] Done

`If Hdr Ext Len indicates that the CRH is larger than the implementation ca= n
process, ` suggest using code 6 per
https://ur= ldefense.com/v3/__https://www.iana.org/assignments/icmpv6-parameters/icmpv6= -parameters.xhtml*icmpv6-parameters-codes-5__;Iw!!NEt6yMaO-gk!DVJoms2WoGvxm= xqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmc25Y-TxM$

[RB] Done

While wasting octets with too large CRH (i.e., larger than the minimum leng= th)
is a bad thing, does it deserve to discard the packet on transit ? Why not<= br> requesting the source to enforce this mimimum length?

[RB] This is defen= sive coding. The source may be buggy or hostile. If the CRH is malformed, t= he processing node should attempt to access bits beyond the end of it. This= could cause a router to crash.

`If the search does not return a CRH-FIB entry` is the code 0 the most suit= able
code ? If not, why not creating one ? Or even using ICMPv6 code 1 'destinat= ion
unreachable' ?

[RB] I'm going to = push back on this. Destination Unreachable isn't appropriate because it sug= gests that the destination in the base IPv6 header isn't reachable. That is= n't the case. I could create a new code, but I don't want to clutter up the registry with experimental stuff. So, p= arameter problem is good enough for now

`If Segments Left is greater than 0` this will always be the case per first=
bullet `If Segments Left equals 0` ;-)

[RB] Not true. Seg= ments left was decremented two steps above. 

The reader will welcome a justification of `CRH-FIB entry contains a multic= ast
address, discard the packet and`.

[RB] Added a paren= thetic comment that this prevents packet storms.

## Section 6

I guess that this is linked to RFC 4302 (AH), so, please state this clearly= .

[RB] Yes, RFC 4302= demands that this section is present. But do we really need another refere= nce back to RFC 4302?

## Section 7

Is it about `Destination Address Transparency` or privacy ?

[RB] This section = was deleted in response to your previous comment.

## Section 8

`Each CRH SID is processed by exactly one node.` isn't it rather "Each= CRH SID
is processed by exactly one CRH-configured router whose one address matches= the
packet destination address" ?

[RB] Done

## Section 9

The title should rather be "operational considerations"

[RB] Done

What are the "representations described herein" in ` It is recomm= ended that the
experimental versions of PING use the text representations described herein= ` ?
Is it about section 11 ? Then please add a forward reference.

[RB] Done

## Section 10

This is the usual considerations about ICMP, please consider to remove this=
section. Or refer for section 5 of RFC 4443.

[RB] Removed

## Section 11

Beside the above semi-DISCUSS, please state that hexadecimal should be in l= ower
case.

[RB] Words "l= ower-case" added.

## Section 12

`The Source Address does not identify an interface on a trusted node.` is t= here
any hint how this can be done ? How will it scale if all CRH-enabled router=
must know all the specific address of all trusted nodes ? The same scalabil= ity
issue for `The ACL discards packets whose source address identifies an
interface on a trusted node.`

[RB] This is one o= f the things that we ask the experimenters to report on. Some numbering pla= ns support efficient ACLs. Others don't

[RB] SRv6 has the = same problems. Maybe we should develop common text that we both can use.
## Section 13

If the Wireshark/tcpdump modifications (cited in section 9) are public, the= n
references to code will be welcome.

[RB] The citations= of which I am aware are comprehensible to Wireshark/tcpdump developers, bu= t not to the general public. Do you know of any better citations.

`Interoperability among these implementations has not yet been demonstrated= .`
should rather be in section 14 'experimental results'

[RB] Not really. S= ection 14 doesn't provide experimental results. It describes experimental r= esult documents that should be written when the experiment is complete.

## Section 14

I am indeed very curious to see the experimental result of
```
Mechanism used to populate the FIB
Scale of deployment

[RB] Is this comme= nt within the scope of this document? Or are you anticipating the experimen= tal results document?
```
even if the text states in one year after publication as an RFC, this work<= br> started back in 2019 and was adopted in 2023, do we already have some resul= ts ?

[RB] Again, is this comment within the scope of this document? Or are yo= u anticipating the experimental results document?

What are the possible next steps as seen by the authors / 6MAN WG is the experiment is assumed to be successful ? And what are the criteria to decla= re a
successful experiment ?

[RB] Section 14 de= scribes experimental results to be reported. To the best of my knowledge, t= hese results will provide a pretty good picture of whether the experiment s= ucceeded or failed.

[RB] If the experi= ment fails, it fails. If it succeeds, the community will have a few options= . Is there any outcome to which you would object.

    &nbs= p;                     &n= bsp;       Ron

# NITS (non-blocking / cosmetic)

## Section 12

s/This is becasue /This is because/



--_000_BL0PR05MB5316FDC377FB931E50CEAA76AEF22BL0PR05MB5316namp_--