Re: [dhcwg] AD review of draft-ietf-dhc-addr-notification-10
"Eric Vyncke (evyncke)" <evyncke@cisco.com> Mon, 15 April 2024 12:09 UTC
Return-Path: <evyncke@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AB2C14F69B for <dhcwg@ietfa.amsl.com>; Mon, 15 Apr 2024 05:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.933
X-Spam-Level:
X-Spam-Status: No, score=-13.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-2.049, DKIMWL_WL_MED=-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_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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="MfP7SooO"; dkim=pass (1024-bit key) header.d=cisco.com header.b="n9xMHTv3"
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 RDEqr0M71kIK for <dhcwg@ietfa.amsl.com>; Mon, 15 Apr 2024 05:09:06 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (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 BDB77C14F5F4 for <dhcwg@ietf.org>; Mon, 15 Apr 2024 05:09:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=38320; q=dns/txt; s=iport; t=1713182945; x=1714392545; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=t6TV2OKC/IAIDrEkw2ogT+KJ2tL4sYaTA9mNkogeOWw=; b=MfP7SooOQWOk1YWB43RS6Q4d+bUcN8nmdyGmnNRA4lhWBZ2dod/+nBws 8GUuSBo8M7XNBcGR8cRmo+RBohR5eC4sRp7C8O+9/sDdO4kS0XPq0lctF s2g1CmRTxWgotoA+sgLOSQeIZ5bCN9jYackxG7WfnhEquxxicsqoCpAZY 0=;
X-CSE-ConnectionGUID: 8kI14MzITfmJzxdM4lZUZA==
X-CSE-MsgGUID: ww00M4PNTEasCHN1DymK6Q==
X-IPAS-Result: A0ABAACFFx1mmIMNJK1aGQEBAQEBAQEBAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFlgRYEAQEBAQELAYFAMVJ6AoEXSIRVg0wDhE5fiGwDi2CFYoxGgSUDVg8BAQENAQFEBAEBhQYCFogBAiY0CQ4BAgICAQEBAQMCAwEBAQEBAQEBBgEBBQEBAQIBBwUUAQEBAQEBAQEeGQUQDieFbQ2GWQEBAQECARIRHQEBMgMCAQQLAgEIEQMBAgEgBwMCAgIeERQJCAIEDgUIGoJeAYIXFAMOIwMBpgIBgUACiih6gTKBAYIKAQEGBAXbGw2CTQmBSAGIDwQaASRIaQICgW2GdicbgUlEgRQBQoFmgQI+gh9CAoFIGh4GEIMlOYIvghKFEIIVAYUNgQMbHYMSQYFYgSKBEIE7DwSCNwcBEIV3VHciAyYzIREBVRMiDwwaAhsUDSQjAik+AwkKEAIWAx0UBC4RCQsmAyoGOQISDAYGBlsgFgkEIwMIBANQAyBwEQMEGgQLB3WBfIE9BBNHEIEyihIMQYE8gTQpgU4pgRGDIUtxE4QIgTkDRB1AAwttPRQhFBsFBB8BgRgFnDAEgkYBAg5bagRDMDArBw8yAj0BAQ8DHAEbGBEDlXUBSYspoh1CcAqEE45ijFaGKxeEBYx+kXuBFYU9ZJhiglSPIJFBBAQPCYUGAgQCBAUCDwEBBoFkOjuBIHAVgyJSGQ+EIIoABwUNCYNYlQd4OwIHAQoBAQMJimgBAQ
IronPort-PHdr: A9a23:dgofrxa/0XVTmlVdD40akxL/LTDmhN3EVzX9orI9gL5IN6O78IunY QrU5O5mixnCWoCIo/5Hiu+Dq6n7QiRA+peOtnkebYZBHwEIk8QYngEsQYaFBET3IeSsbnkSF 8VZX1gj9Ha+YgBOAMirX1TJuTWp6CIKXBD2NA57POPwT4PMnsK81O2a8JzIaAIOjz24Mvt+K RysplDJv9INyct6f7w8yBbCvjNEev8Dw2RuKBPbk0P359y7+9ho9CE4hg==
IronPort-Data: A9a23:O5bhlqOPn5nFvbPvrR3Xl8FynXyQoLVcMsEvi/4bfWQNrUoi1zFSy mEfCmnTOv2PY2One9snOdi1oRhTv5DTzdYwTnM5pCpnJ55oRWUpJjg4wmPYZX76whjrFRo/h ykmQoCdaphyFjmF/kvF3oHJ9RFUzbuPSqf3FNnKMyVwQR4MYCo6gHqPocZh6mJTqYb/W1zlV e/a+ZWFZAf5gmMsawr41orawP9RlKWq0N8nlgRWicBj5Df2i3QTBZQDEqC9R1OQrl58R7PSq 07rldlVz0uBl/sfIorNfoXTLiXmdoXv0T2m0RK6bUQNbi9q/UTe2o5jXBYVhNw+Zz+hx7idw /0V3XC8pJtA0qDkwIwgvxdk/y5Wba5noePiM1mDv8mx3V3KVifo8chcJRRjVWEY0r4f7WBm/ PgcLnUGaQqOwrvwy7OgQe4qjcMmRCXpFNpA4Tc7k3eAVrB/Gsmrr6bivbe02B89mNFIFvXTT 8EYcjFoKh/HZnWjP39NVcpkzb/w2SKXnztwt03N/Y9r207v4QVq+5jLafbEf//UfJAA9qqfj jmbpzuiWE5y2Mak4TaF+W2jru7CgS29X5gdfIBU7dZjhFmVg2cUEhBTDB2woOKyjQi1XNc3x 1EoFjQG/asTrRCOXPjBURiasm6Im0IYaediOrhvgO2S8Zb87wGcD2kCazdObt06qcM7LQDGM HfUz7sF4hQx6tWopWKhy1uCkd+l1cEowYIqbCsAS04O5MPu5dh1hRPURdElG6mw5jEUJd0S6 2/SxMTdr+xP5SLu60ld1QqZ695LjsOWJjPZHi2NAgqYAvpRPeZJnbCA51nB9upnJ42EVFSHt 3Vss5HBtbtXVMDRyn3TEb5l8FSVCxCtbWa0bblHQshJythR0y/LkX14uWghdBkzbq7ohxezO BeM0e+u2HOjFCD3NfAsOd3Z5zUCxqn7HtOtTeHPctdLedBwcgTBlByClmbOt10BZHMEyPllU b/CKJ7EJS9DWcxPkmHsL89DiuBD+8zL7T6JLXwN5075geP2ib/8YeptDWZimchjsv3V/FqFr r6y9aKikn1ibQE3WQGOmaY7JlERJn99Dpfzw/G7vMbaSua6MAnN08Ps/I4=
IronPort-HdrOrdr: A9a23:3FA8mK4kpEM8r0XtBwPXwYeCI+orL9Y04lQ7vn2ZFiYlEfBwxv rPoB1E737JYW4qKQAdcLC7VJVpQRvnhOdICPoqTMeftWjdySSVxeRZnOnfKlLbalDDH4JmpM Bdmu1FeaPN5DtB/IjHCWuDYqodKbC8mcjC65a6vhNQpENRGt5dBmxCe36m+zhNNXN77O0CZe GhD6R81lydUEVSRP6WQlMCWO/OrcDKkpXJXT4qbiRM1CC+yRmTxPrfCRa34jcyOgkj/V4lyw f4uj28wp/mn+Cwyxfa2WOWxY9RgsHdxtxKA9HJotQJKx334zzYJLhJavmnhnQYseuv4FElnJ 3nuBE7Jfl+7HvXYyWcvQbt4Q/9yzwjgkWSimNwwEGT4/ARdghKT/aptrgpNScxLHBQ+u2U5Z g7ml5xcaAnVC8o0h6Nv+QgHCsa5XZc6UBS49L7yUYvELf3rNRq3NYiFIQ/KuZaIAvqrI8gC+ VgF8fa+bJfdk6bdWnQui11zMWrRWlbJGbNfqEugL3c79FtpgEz82IIgMgE2nsQ/pM0TJdJo+ zCL6RzjblLCssbd7h0CusNSda+TjWle2OBDEuCZVD8UK0XMXPErJD6pL0z+eGxYZQNiJ8/go 7IXl9UvXM7P0juFcqN1ptW9Q2lehTxYR39jsVFo5RpsLz1Q7TmdSWFVVA1isOl5+4SB8XKMs zDca6+w8WTW1cGNbw5qDEWAaMiXEX2ePdlzuoGZw==
X-Talos-CUID: 9a23:5/6dsWob7VuySRcZKQMKZc/mUZAmUySB6WXxH0G9K3R5RJjJTW2tyooxxg==
X-Talos-MUID: 9a23:DQGXBAyiSVsA3SIrYhzqa9fFlD2aqLuxUBgoza0gh+SNLgdQHW6xnTGUHLZyfw==
X-IronPort-Anti-Spam-Filtered: true
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2024 12:09:04 +0000
Received: from rcdn-opgw-5.cisco.com (rcdn-opgw-5.cisco.com [72.163.7.169]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 43FC94Kh015850 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <dhcwg@ietf.org>; Mon, 15 Apr 2024 12:09:04 GMT
X-CSE-ConnectionGUID: T+Vc/yNPRjyK/n0W+QPt/Q==
X-CSE-MsgGUID: V/ek+Sw5R/yFT3Eyovkdfg==
Authentication-Results: rcdn-opgw-5.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=evyncke@cisco.com; dmarc=pass (p=reject dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.07,203,1708387200"; d="scan'208,217";a="7463722"
Received: from mail-bn1nam02lp2040.outbound.protection.outlook.com (HELO NAM02-BN1-obe.outbound.protection.outlook.com) ([104.47.51.40]) by rcdn-opgw-5.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2024 12:09:03 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AGCWjpjocuMa0Mk5vvh5ifQDwXYU54a3nNvjTRhDFqAi6BDdZECnCw98he+DckPY+BsJB3JBWnAFMX2O+CscrhGZ89wsIW073tFLswM7oQdH4GYRkfrQON+JokSrTs4UlOV81hSXzdCwJcC/y+2AS0j3rxitIIUFZ2tIGOG5PkSkhc4QuYumBijn0G2qD7bpXpHpd2wwC0114FGeGuvG+9JdFZZE4XFIQtl35+pVRKIonG+ISmcBzospuDEG2CfKQSY6iIfzviOVYUqfmvX5ds9eh/IllSXkuSAmBpp/V6lNDvNJOLD6kFRGkLPA+cgHiGMQfBkyITv5HKCrzPNXpw==
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=t6TV2OKC/IAIDrEkw2ogT+KJ2tL4sYaTA9mNkogeOWw=; b=FipjJR96w9bj/MmF3bar56Ez6/NpiDlWbrHP5lJKjiKoOYZqR2FBk1JZHSeKysGH3SMopg0Q3VegEwiJ2jNQhwdKho42p3pAg3E4nhHESQJyw98WhFCHkmxUXPjQT8B7TJd49bemR+laxl4gDJz5wKLVOmHMqIeTu4HLb/Rah3qy0PkE/NlCgtilZxugHI5zfwhpZvrTSY8gYa6p+OVrlKEe5vakk/ytSRvFrDJl6eehpe8DmH7FzVqbGQGeyyY+dZrG4s0lVST5kuYTbkcFAhHxBYyje1RTLU2QE06UYAaEMYx6cdG4ZqDz/sIoz7n9tJrHS1Pk+CmLuHEB0qfNvw==
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.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t6TV2OKC/IAIDrEkw2ogT+KJ2tL4sYaTA9mNkogeOWw=; b=n9xMHTv3oKKAWs7K0S+0naBfDSX2AhkiE59FxRZ2PiOSu6cd1BzPAPIMINGy/q1CCQ/q1Sgz5XvmFSEKg0YXjTkW18xEUrIzjkXi9oBTErwiYm75R9JhGVHGkDKm2kAGhcMOINf1L5+fjWqANXnzru//mGATveKxQlOMXB+2Qd4=
Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by SN7PR11MB6898.namprd11.prod.outlook.com (2603:10b6:806:2a6::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7472.27; Mon, 15 Apr 2024 12:08:59 +0000
Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::626d:78db:4371:447a]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::626d:78db:4371:447a%6]) with mapi id 15.20.7472.025; Mon, 15 Apr 2024 12:08:59 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Lorenzo Colitti <lorenzo@google.com>
CC: Jen Linkova <furry13@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, "rajiv.asati@gmail.com" <rajiv.asati@gmail.com>, Warren Kumari <warren@kumari.net>, "suresh.krishnan@gmail.com" <suresh.krishnan@gmail.com>, "shengjiang@bupt.edu.cn" <shengjiang@bupt.edu.cn>
Thread-Topic: AD review of draft-ietf-dhc-addr-notification-10
Thread-Index: AQHah062sst7qLuaykuB6bxlmIejhrFgmNoAgAQuREKABFDAgIAAMFSk
Date: Mon, 15 Apr 2024 12:08:59 +0000
Message-ID: <PH0PR11MB4966787D9CF663524F1B6FD0A9092@PH0PR11MB4966.namprd11.prod.outlook.com>
References: <PH0PR11MB49661E586240C0F620E04783A9032@PH0PR11MB4966.namprd11.prod.outlook.com> <CAFU7BAS2bhayYmyNya0pDDGDd4XwaqRF579H4WoGhGv6y_bXgw@mail.gmail.com> <PH0PR11MB49666DBAE552F214F1AC69F2A9042@PH0PR11MB4966.namprd11.prod.outlook.com> <CAKD1Yr2gts-s6=ZEdr263kX+wKoVjOjTQ64PPET1MzDTJcj8HQ@mail.gmail.com>
In-Reply-To: <CAKD1Yr2gts-s6=ZEdr263kX+wKoVjOjTQ64PPET1MzDTJcj8HQ@mail.gmail.com>
Accept-Language: fr-BE, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR11MB4966:EE_|SN7PR11MB6898:EE_
x-ms-office365-filtering-correlation-id: e09881d8-7880-4f04-5790-08dc5d44d526
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: kLrwoQndRFfe1lhT7PoQpXrfn8AIRhbaxtDxp/stqbW33atzhul3jgmyPjLY71w7NWjdePoFovhWc+ZREe9Ss7cyiIvL3fvSqUJBqLj7wkoY/WnZRntMzAEjICflr4/KmMAcqNCNrPs3QBXBK3pD399AYQwwYQXaF5sQRhxtZWWQ6SpKrT/xh+TV2A010dYkqaGK0PDuYl8+Rt1g4ozjUGWm9Nru0kNieaj7t8c8FnzA31kgvNC20Eh67+0nojMCrrfjm/BXDYmTvMFjiO0cBuca79ViugDAIYsyOwKP8BBem+7yn1QVRiffiwgOv/wrTDVXa/rphLwNtKAqUrsc8b1dBd8sQMiZf/AiphQzK5povs6+N5k2cQMItM881FY87flKxH0FuEJ22Pt90m8sbOANVQ+SdLFth74wGF2K2giQqZUjdZYsqEjuD/hNfPRjG6JsC5lrasV3Wi8pV18ZWM6mtE3rkUubgvmbefGR7syVNRTdqEV0lwUHZit/yCeT6QFVTxn578NSGK2ctQZWhCOwg2+MjFaGeSYDQ6O5wb/EaAHFxTSAxIkufUiAgsWMtQsVJKXfdn7SduW9x76RHatpEHnHofCJjomtgHq3r7ptx1Disx/2rh/fNaCpIl9xutqOwTeBLeKZl/kxgDrkSZ3a9lBRbFfHqSxFbfZrir4ObEiWRFZAJzQ+YDiTn2zF9gQWUI0JD1CiwHfhcPXhp9k3be7uJGhjSFUlOjRWP7o=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366007)(376005)(1800799015)(38070700009); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: PwZ+CJbZ57Qcjo3GHu+mFJGfjnKTSPNcKWatK5rcn3zs6xQuVaE443qYbdJhyxJDHi8z/iozA4PrYlQuqoZy3/li9y4kt7+1kSWndyVJVD0C9fEzBXevCKTA6uJYIarWOz0+X9Cmvs3V53RmMmuWbtihC+Zffpdu72JuSktZFhnkIFlc5tdO8V7JR5F3F9udbhx8yNVu7qhl66TUwKwqosv0knOcIbOFTlN+TTpOWlMAT1qVo8CPYJZWYVhcqdf2Nl4ZUHZvLixKfUbTImXWwrbtCIcmni/7OZ1BLCaCV1Jyf2a2ggSJpviEPb8dY5k+filCxi7L2/j/mfZXrdWISRmtiPlo/Zt+tu8OOdyxquLivL66pxcnnjpXgSyEr+uMuic1xdoWPZzxrHsj8tmZ0H8n1e+rnK/Ij3CkxOMBBC5741jLq3Zi+FjfGz6k62gDio8PSHAH0EHvIgwfrE083phGWpBtv1iKv3Ym9xlKRHJJFxSlMa++wylLZvxFzbsG0ibhaxkmmYQDzSVVH+Ol852jlDu/s/K0n3xOErCvtZfRxqGW6UwqiPg0WNLu9SSivfujcH7/xt2+csntsDAjFxD/TPFPYj8Z75NswI6ge4hJyyixRvGMbOTsIcJOfIupoJyhLdVcuaNqCxNpAK5OG3+KDbsajSeg0Wf9/3H4ZLQnXAVtsLE26OUzKvd2YwWxfjbf6GjjyGoK65cEap0qHxOTarGdtdePwOXZrtWYhkL/PcIZSXz9ly9UgxCy1Xb3AoWV9ajF4uygxwKWth0VLf1g8255eza62Budkz48fMLPB1HP9sEGdRQ8Mwubi3r96T6qVgnsnL27TIt3y/ErCQnNYpHiQe7K2NFZiGEx20BtOA7YmWw4Wr1rnzZ+uxZWEqs/vxt7oU8OOOExS3pXOfKh5XX3sIuPKNh6F33Bla9anO0yBQHaL6tI9tA2/Vov2BQnP8mgiHbk4iEUU2vyWQ1creBzUVReobny76ycgv48dNpnRa9b6vDNkzh8WRT0BgTgX57rDn2Z1/l5PWOd5+sBnTz8c6bEKkDpD0YaSZNZgDyGSRDYPuEhRjkANI7Mft+laz5Lu3C4QeeC2z6kTpEdXCUEiHyROWtycgZglo8Efk8imad4NzhRvoAcDB8AlPDpvhfZ1Otxf+sgdgtfJ1F1IWhFEc0FZ+gbThZjVXYJ72CI4oF3vfA5s0IBDenR39fZOAR4x40if8rNEY4OgZAdC2g/Vww6CA9LVw6U9Wcg82+tSjvRbTiuxTzoe0JGx5XjQj5N0IBJq2DdIStGfAiIz1bmIvRBnqc+NzQN+w5Z/xlyMYOqpnmJex4k3Q3j5POhgbih7tZHwkGACxNyMow9EoFJ8Ei/EHuBG37ThGnONibvAQ3WqF0mWFaE2fU+OeDxF2124phtO+LLzFp2NKD8DZi6VVRnjzlLgehIgrwdKKqfdV3Ntk9TdpGXWQSZrmEi9qzUzdbVEvuAzpl40+D1Lw2HhrfjLn4rd2BtOS5o4hYeCMoMCful7ro5ZY+woXsxeJtDqUTwBRSkwgsdw/AGw8eel28ocpgrM7iOgvMP9/ZFiOKK46wX+KJr6oYIAEX5pYKaq/bkrpHqoQSR5eDy4q9KWP+e7tc2iVisF8U957cQNooAY+x62RaXOJ1t8udeT8zUP0oN6axXSvzxCw==
Content-Type: multipart/alternative; boundary="_000_PH0PR11MB4966787D9CF663524F1B6FD0A9092PH0PR11MB4966namp_"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e09881d8-7880-4f04-5790-08dc5d44d526
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2024 12:08:59.4405 (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: pwmI3rbXeohy0BuvfmDSJHZAEPJxXgEVXQD+3JOcDlAKYRS8Fwfmogo9wNqUsC0K/e0lWXlYsK09K82MS6iv5g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB6898
X-Outbound-SMTP-Client: 72.163.7.169, rcdn-opgw-5.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/dAjoVYlap8s5Mr5FEoMtHhSo33A>
Subject: Re: [dhcwg] AD review of draft-ietf-dhc-addr-notification-10
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Dynamic Host Configuration <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2024 12:09:10 -0000
Hi Lorenzo, TL;DR: the document is only waiting for the shepherd’s write-up update to justify the 6 authors On the topic SHOULD/MUST, I agree that ther chance of collision is “rather small” (to say the least), but why not adding a MUST anyway to be on the safe side even if DAD will be done even for IA ? Anyway, not blocking, and happy to disagree with the authors on this minor issue. Regards, -éric From: Lorenzo Colitti <lorenzo@google.com> Date: Monday, 15 April 2024 at 11:00 To: Eric Vyncke (evyncke) <evyncke@cisco.com> Cc: Jen Linkova <furry13@gmail.com>, dhcwg@ietf.org <dhcwg@ietf.org>, rajiv.asati@gmail.com <rajiv.asati@gmail.com>, Warren Kumari <warren@kumari.net>, suresh.krishnan@gmail.com <suresh.krishnan@gmail.com>, shengjiang@bupt.edu.cn <shengjiang@bupt.edu.cn> Subject: Re: AD review of draft-ietf-dhc-addr-notification-10 I do see the argument for "MUST mark it as unavailable", but I think SHOULD is better. This is because with MUST, it is not valid to build an implementation that just logs the address notifications and does nothing else. In practice, such an implementation would work perfectly well. SLAAC works on /64s and on /64s conflicts are *incredibly* unlikely. I think it's less than one in a billion chance of collision even with 100k devices on the link, or something like that. On Sat, Apr 13, 2024 at 12:16 AM Eric Vyncke (evyncke) <evyncke@cisco.com<mailto:evyncke@cisco.com>> wrote: Hello Jen, Also replying implicitly to Warren’s reply dated 5th of April in the same thread. So, thank you, for the answers and suggested changes. We still disagree on one point (see below for EVY>) but, at this stage, I will it go as you have answered to my point (even if I do not like the answer). I.e., please upload a revised I-D and I will request an IETF Last Call Regards -éric From: Jen Linkova <furry13@gmail.com<mailto:furry13@gmail.com>> Date: Wednesday, 10 April 2024 at 01:15 To: Eric Vyncke (evyncke) <evyncke@cisco.com<mailto:evyncke@cisco.com>> Cc: dhcwg@ietf.org<mailto:dhcwg@ietf.org> <dhcwg@ietf.org<mailto:dhcwg@ietf.org>>, rajiv.asati@gmail.com<mailto:rajiv.asati@gmail.com> <rajiv.asati@gmail.com<mailto:rajiv.asati@gmail.com>>, Warren Kumari <warren@kumari.net<mailto:warren@kumari.net>>, suresh.krishnan@gmail.com<mailto:suresh.krishnan@gmail.com> <suresh.krishnan@gmail.com<mailto:suresh.krishnan@gmail.com>>, Lorenzo Colitti <lorenzo@google.com<mailto:lorenzo@google.com>>, shengjiang@bupt.edu.cn<mailto:shengjiang@bupt.edu.cn> <shengjiang@bupt.edu.cn<mailto:shengjiang@bupt.edu.cn>> Subject: Re: AD review of draft-ietf-dhc-addr-notification-10 Hi Eric, Thank you very much for your review and comments. Sorry for the delayed response, the authors have been discussing the remaining open items, our comments are below. On Sat, Apr 6, 2024 at 1:38 AM Eric Vyncke (evyncke) <evyncke@cisco.com<mailto:evyncke@cisco.com>> wrote: > Figure 1, suggest to also add the dst address. We'd prefer not to. The diagram focuses on elements which are either new (different from existing mechanisms) or important for understanding the proposed concept. That’s why Fig1 shows the source address: unlike all other DHCPv6 communications, ADDR-REG-INFORM MESSAGE is sent from the global address, not the link-local one. That difference is important to emphasize. The dst address is the standard multicast, so nothing new here. Adding it overloads the diagram with information and makes it harder to understand IMHO. EVY> fair enough > ` The client MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6.` what about the very special and rare case where not all multiple DHCPv6 servers have received the confirmation of address lease ? Well...This sounds like a problem DHCPv6 protocol should address with or without this proposal. Improving DHCPv6 reliability is out of scope for this draft (and sending ADDR-REG-INFORM for addresses received via IA_NA is a very high price to pay: it would be *very* noisy if we allow the client to register DHCPv6 addresses - and this group has spent a lot of time discussing how to optimize the registration algorithm to minimize the amount of multicast noise... So while nothing would be broken if we replace 'MUST NOT' with 'SHOULD NOT', it looks very much undesirable. EVY> fair enough > # Section 4.2.1 > In the case of multiple DHCPv6 servers, how can ` within a prefix delegated to the client`be checked ? There is not much difference between knowing which prefix is “appropriate for the link” and knowing which pool is used on the given link: both require some knowledge of the topology. If the administrator runs multiple DHCPv6 servers which share the same pool - some mechanism to keep the data in sync would be required anyway, even w.o this proposal - and defining such a mechanism sounds like out of scope of this draft. In case of a multi-homing scenario (or multiple administrative domains, each operating its own DHCPv6 infrastructure), then each DHCPv6 server would only register addresses belonging to its address space. Would adding the following text to the end of Section 4.2.1 address your concern?: “If a client is multihomed (connected to multiple administrative domains, each operating its own DHCPv6 infrastructure), the requirement to verify that the registered address is appropriate for the link or belongs to a delegated prefix ensures that each DHCPv6 server only registers bindings for addresses from the given administrative domain.” EVY> this would indeed improve the specification > ` SHOULD log the address registration information` should probably be more explicit about which information... I.e., DUID not always have MAC addresses. We’d like the behavior to be consistent with what the server does for assigned addresses and delegated prefixes, hence the text is saying “as is done normally for clients to which it has assigned an address” - we shall probably update it with “...or delegated a prefix” though. The proposed text: “the server SHOULD log the client DUID and the link-layer address, if available. The server MAY log any other information” EVY> LGTM > ` SHOULD mark the address as unavailable for use and not include it in future ADVERTISE messages` when can this SHOULD be bypassed ? I would assume that a MUST would be safer. If the DHCPV6 pool configuration permits a collision between DHCPv6-assigned and SLAAC addresses, then that problem exists even w/o this proposal. This draft provides an additional signal to prevent the collision but it should be up to the server administrator to use it. Making this SHOULD a MUST would be safer but wouldn't guarantee that there is no collision. MUST would prevent a server from assigning an address that another host has registered. But it wouldn't prevent a host forming an address with SLAAC that the server has assigned to another host. That has to rely on DAD or on the laws of probability. Given that MUST can't guarantee that collisions don't occur, SHOULD seems appropriate. EVY> we do not agree here. Up to the authors & WG to decide of course, but a MUST wont’ prevent other conflicts but would at least prevent some. Additionally, a very simple implementation of this draft could simply just log and do nothing else. Unless the hosts are malicious or the network is extremely large, this will work very well in practice, because a collision is extremely unlikely (even with 100k clients it's less than one in a billion). If we said MUST, such an implementation would be non-compliant. > ` SHOULD include the client's link-layer address in the relayed message` when can this SHOULD be bypassed ? I.e., without the client MAC, there is little use of this I-D. Good point, thank you! The proposed text: “DHCPv6 relay agents and switches that relay address registration messages directly from clients MUST include the client's link-layer address in the relayed message using the Client Link-Layer Address option ([RFC6939]) if they would do so for other DHCPv6 client messages such as SOLICIT, REQUEST, and REBIND” EVY> ACK > Should the client periodically try to register ? I fear that some statically addressed nodes will never register as they could stay for years without reboot or move. Warren's comment summarizes the WG decision. Anyway, statically assigned addresses are not the primary use case for this proposal... EVY> WG decision is paramount at this stage. So, let’s keep the text -- Cheers, Jen Linkova
- [dhcwg] AD review of draft-ietf-dhc-addr-notifica… Eric Vyncke (evyncke)
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Warren Kumari
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Jen Linkova
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Eric Vyncke (evyncke)
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Warren Kumari
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Lorenzo Colitti
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Eric Vyncke (evyncke)
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Warren Kumari
- Re: [dhcwg] AD review of draft-ietf-dhc-addr-noti… Rajiv Asati