Re: [IPv6] WG Last Call on draft-ietf-6lo-multicast-registration-11
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 21 November 2022 17:54 UTC
Return-Path: <pthubert@cisco.com>
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 075C9C1524AF; Mon, 21 Nov 2022 09:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.598
X-Spam-Level:
X-Spam-Status: No, score=-14.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, 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=jIBqdtRw; dkim=pass (1024-bit key) header.d=cisco.com header.b=JiN4Xx1s
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 40WV8I1Gl_bR; Mon, 21 Nov 2022 09:54:09 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B71C14CF19; Mon, 21 Nov 2022 09:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16032; q=dns/txt; s=iport; t=1669053249; x=1670262849; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=o62Q2nRR/9PHPqrToKCcBqAClF6js8L0N8UIhewCuns=; b=jIBqdtRwJXfzezeAdE8edizXFQ5w0nysxo93gd2aYLjaZSPqr7Q5LCKh l7AIICVr9TEIEzkjsUegUF6uIoDO0J0H9j/Yf5l9VfYsuu6bwdXGirJ4T GzjTpq//Zjkmpd5jz7PFe+cSXs/ozBqBu4IGJ1TUcqFajhaF4jDuntMLB g=;
X-IPAS-Result: A0AIAACruntjmIwNJK1aDg0BAQEBAQEBAQUBAQESAQEBAwMBAQFAgTsGAQEBCwGBWlKBAgJZOkWEToNMA4RQX4gcA4s3kE6BLBSBEQNWDwEBAQ0BAS4LCwQBAYFTgzICFoRqAiU0CQ4BAgQBAQEBAwIDAQEBAQEBAwEBBQEBAQIBBwQUAQEBAQEBAQEdGQUOECeFaA2GUwEBAQEDAQEQEQQNDAEBLAsBCwQCAQYCEQQBAQECAggBGgMCAgIfBgsUAQgIAgQBDQUIGoJbAYJuAzEDAQ+YKY88AYE/Aoofen8zgQGCCAEBBgQEgTgBFUGaOg2CRgMGgRQsAYcsA3Rcg0kXhDAnHIFJRIEVQ4FmgQE+giBCAQECAYEfBBELIAUzgx05gi6LVoJLWIETgWmFexw3A0QdQAMLOzIKShtYDgkfFgYOFw0FBhIDIEYmBUEPKC4BZyIJHBsHgQwqCR8VAwQEAwIGEwMgAg0pMRQEKRMNKydvCQIDImUFAwMEKCwDCSAEHAcWESQ8B1YSKAEEAwIPIDgGAwkDAiRWcwslJgUDCxUlCAVLBAg5BQZSEgIKEQMSDwYmRg5IPjkWBidCATEODhQDXoFpBDVIgSkIApoRgSsQWwYwDiYEUQIgLQIBCyoTAhYqERcUJzqSKAiDWKo6gQhuCoNoi02PAIYjFoN4jFSGZ5EFXpc0II0jg2mRDoUVAgQCBAUCDgEBBoFiOoFbcBUaIYJnUhkPjiAMDQmDUIUUhQVFdQI5AgcBCgEBAwmICYJZAQE
IronPort-PHdr: A9a23:+mqsyRAnLypd/WG5Ej37UyQVaBdPi9zP1kY95pkmjudIdaKut9TnM VfE7PpgxFnOQc3A6v1ChuaX1sKoWWEJ7Zub9nxXdptKWkwJjMwMlFkmB8iIQUTwMP/taXk8G 8JPHF9o9n22Kw5bAsH7MlbTuXa1qzUVH0aXCA==
IronPort-Data: A9a23:ZIcEia905OHUpn3yFPUwDrUDR36TJUtcMsCJ2f8bNWPcYEJGY0x3z WQbXmjVMqqPa2egL9wjaI7jpEoB75bVm9U2GQU5qixEQiMRo6IpJzg2wmQcns+2BpeeJK6yx 5xGMrEsFOhtEjmE4E3F3oHJ9RGQ74nQLlbHILOCa34ZqTNMEn9700s6wbdh2OaEvPDga++zk YKqyyHgEAfNNw5cagr4PIra9XuDFNyr0N8plgRWicJj5TcypFFJZH4rHpxdGlOjKmVi8kFWc M6YpF2x1juxEx7AkbpJmJ6jGqEBaua60QRjFhO6VoD66iWuqBDe3Y40DNlNZRl7yA+0xf5Wj 4txmoDgYhUma/ikdOQ1C3G0Egl3OalAvbTAO3X67oqYzlbNdD3nxPAG4EMeZNJDvL0pRzgVs 6VEcFjhbTjb7w6y6KqnSvRmi94/BMLqJ4gY/HpnyFk1CN5/H8+aGvyRube02h8dlvpHP92Dd /AaKjEsZhTZfBZXO3cYXcdWcOCA3ymjLGIwREiujasv/Tb7zQFt3v7qKtW9UoKOQu1Uk1qW4 GXc8AzRCRgAMNGEjzWC93++rvLXlmX2VJ96PLix7P14kk+Iw20PCDUZUFK6pb+yjUvWc9NSN 0If0iAypq808kGgUp/2WBjQnZKflhcYX9wVGOog5UTSjKHV+A2eQGMDS1atdeDKquc5fR972 gGl3OnUXxJI9+OpZm7N3aWb+Gba1TcuEUcOYioNTA0g6tbloZ0ugh+ncjqFOPPu5jESMWytq w1mvBTSlJ1I1pdSiPvTEUTvxmPy+MeYF2bZ8y2NBgqYAhVFiJlJjmBCwXHf6ftGRGpyZgbc5 CFf8yRyARxnMH1gvCWJRONIF7az6rPadjbdmlVoWZIm8lxBGkJPn6gOulmSx28wba7onAMFh meI42u9A7cIZxOXgVdfOd7ZNijT5fGI+S7Zfv7VdMFSRZN6aRWK+ipjDWbJgT69wRZ9yftva cvCGSpJMZr8Ifk5pNZRb7pNuYLHOghlrY8ubcmhlk/+geb2iIC9EO9fbDNikdzVHIvd8FmKr L6zxuOByg5UV6XlczLL/IsIRW3m3lBlba0aX/d/L7bZSiI/QTlJI6aIndsJJdc/94wLzbigw 51IchICoLYJrSeZeVzih7EKQO6HYKuTWlpgYnxzYQ3zhCF6CWtthY9GH6YKkXAc3LQL5ZZJo zMtIq1s3twnpuz7xgkg
IronPort-HdrOrdr: A9a23:pbTDYqm/tADJtBUgNJuG/aEM5izpDfOOimdD5ihNYBxZY6Wkfp +V8sjzhCWatN9OYh0dcIi7Sda9qXO1z+8Q3WBjB8bdYOCAghrnEGgC1/qs/9SEIUzDH4FmpN 9dmyYVMqyKMbEXt7eZ3OD8Kadd/DDlytHouQ699QYWcegCUcgJhG0Vanf5LqQ1fng6OXNTLu v62iMznUvYRZ1hVLXcOpBqZZmnm/T70LbdJTIWDR8u7weDyRmy7qThLhSe1hACFxtS3LYL6w H+4kzEz5Tml8v+5g7X1mfV4ZgTssDm0MF/CMuFjdVQAinwizyveJ9qV9S5zXMISaCUmRQXee v30lMd1vdImjTsl6aO0F3QMjzboXMTArnZuAalaDXY0JTErXkBert8bMpiA2vkAgwbzYpBOG Yh5RPFi3KRZimwxhgVruK4JS2DmieP0AkfuP9WgHpFXYQEbrhN6YQZ4UNOCZ8FWDn38YY9DY BVfYvhDdttABunhkrizyJS6c3pWm52EgaNQ0AEtMDQ2z9KnGphx09dwMAEhH8P+J80VpEBvo 3/Q+hVvaALStVTYbN2Be8HT8fyAmvRQQjUOGbXJVj8DqkIN3/Etpay6rQo4+OhfoAO0fIJ6d n8eUIdsXR3d1PlCMWI0pEO+hfRQH+lVTCo0c1a74gRgMy0eFMqC1z0dLkDqbrWnxxEOLyvZx +aAuMjP8Pe
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.96,182,1665446400"; d="scan'208";a="16711134"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Nov 2022 17:54:07 +0000
Received: from mail.cisco.com (xfe-aln-002.cisco.com [173.37.135.122]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 2ALHs7s0032538 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 21 Nov 2022 17:54:07 GMT
Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Mon, 21 Nov 2022 11:54:07 -0600
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9 via Frontend Transport; Mon, 21 Nov 2022 11:54:07 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C/1TXf/9AQs4VvFFS5uZAlTbDiyQ1aO/CbrEGXhWPX2lxrxbFMfczeF9tJNUIicj1HT7eGqiZtH/qbQthvLpyX0wbwJ9W7w+wpig5JTZDiTNh62gXrZZQx2/7hx70gUjWm3Gs4JQcGOMCQKtLYwiZwES+v8qE+lSowAo0XpFZUu9dNsA5pqJYn7A5BdWepvYppjdESLQV+rKTFSj134bZ/3qrAulduVvdfy7EXnxGVjM/ZPrZ01XBHSPJmWrkOuVT2MBW8J0MKcci4P9wuQQbEeDdltcfzplsQhpP5wWDAAdihmJT7RC5WEe2w8JNXtoAvyANua+1F4UOvSzTOjqTQ==
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=o62Q2nRR/9PHPqrToKCcBqAClF6js8L0N8UIhewCuns=; b=BjTLQW0UjUEfom95nKU5s4XgDJDNZvV+hIjQzXHOOrV+WYSM4Fp46sbc0USC0Okrz+3bdBo2rHBAJc6pw7hRK42Mi4r6JWpqBQVMTQasRYp6eqoWZCdZAITpExAhYxTTUqmzzYWqYbxfZREZgEggY6V4w//4fjcnvtUYmpHuv3fBzFoknJrmxruR9EcqY4Br3w/pq/v19YkkqWfwY70pMrdgzKv3kEKGdDjai0Pn830/XfY9Xak3p2+KJclJKD3W46Afvjuc8uvBY0sFh0CNdHqRCaovRmc8oVFOFyh3EYVMUF/xzTZ50nAcvXkqLrExr28gB9lHUqWQgPJcxb5O/Q==
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=o62Q2nRR/9PHPqrToKCcBqAClF6js8L0N8UIhewCuns=; b=JiN4Xx1s355+SaGOG0X3UewwSMe8lxDkq8JFxxf00UC5xdPw12Nu6thIv/Y/xHw9TS3wihR4kP4HgPSxr/SQASPyelMfT0fGpW0Qdgegvxv1HQIXlkbk5AMH3Fn4I1sa0QZdaW9AloRTLECuPgiQo5IjIFeL+vUXS+JIekSQDdg=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by DM4PR11MB5437.namprd11.prod.outlook.com (2603:10b6:5:398::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5834.15; Mon, 21 Nov 2022 17:54:06 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::20d9:5c5:9e71:961]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::20d9:5c5:9e71:961%7]) with mapi id 15.20.5834.015; Mon, 21 Nov 2022 17:54:05 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: tom petch <ietfc@btconnect.com>, Mark Smith <markzzzsmith@gmail.com>, "carles.gomez@upc.edu" <carles.gomez@upc.edu>
CC: "6lo@ietf.org" <6lo@ietf.org>, 6man WG <ipv6@ietf.org>
Thread-Topic: [IPv6] WG Last Call on draft-ietf-6lo-multicast-registration-11
Thread-Index: AQHY+iKX4t3qDQaMwkSF9cCM5QTVDa5DA+VQgABR7wCAASPDIIABvA8AgAME2ICAAGjxgIAADDyA
Date: Mon, 21 Nov 2022 17:53:43 +0000
Deferred-Delivery: Mon, 21 Nov 2022 17:53:34 +0000
Message-ID: <CO1PR11MB4881A9B5A7C27628D25B4A5DD80A9@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <CAAUO2xxJ-Cksm6uL19LxpbH4q1nodCsKbUPUAd3UEH=SMRSokg@mail.gmail.com> <CAO42Z2z6_kHhO5goSKDBudJjLTxBejZJEqQ-Rh5VSganinVnYQ@mail.gmail.com> <CO1PR11MB4881144FAEC23F671C46E25FD8069@CO1PR11MB4881.namprd11.prod.outlook.com> <AM7SPR01MB0017AF6A62A3D9935181A090A0069@AM7SPR01MB0017.eurprd07.prod.outlook.com> <CO1PR11MB4881AFB1045D0BE039E0ADC5D8099@CO1PR11MB4881.namprd11.prod.outlook.com> <VI1PR07MB6256DF69383B67B3D2ABAD19A0089@VI1PR07MB6256.eurprd07.prod.outlook.com> <CO1PR11MB4881FD27EAF74C486A0B1B44D80A9@CO1PR11MB4881.namprd11.prod.outlook.com> <VI1PR07MB6256C879554C4D39D1D656EAA00A9@VI1PR07MB6256.eurprd07.prod.outlook.com>
In-Reply-To: <VI1PR07MB6256C879554C4D39D1D656EAA00A9@VI1PR07MB6256.eurprd07.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CO1PR11MB4881:EE_|DM4PR11MB5437:EE_
x-ms-office365-filtering-correlation-id: c16088e1-37c0-4546-e931-08dacbe96211
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7JyiMLLHKmlT2LRSK8QrbDD/k07UO/oIHJGFp+SORgJQHuCHiluu/mBUcAQhlzNNomsih93c2MfsHu7+H4S/qoJNxedt3M6N+mUR54bmzAV9pLcE1S0hQx9j+sKmgrkf1BRdJsHmKqTiZanT0IWzcrfaL3raGVXDDyFSzdyLUOKeTzZ3WeQeDiWXZn+cHSGxohUKycdHnGUamPxfiteJ5/1WPxH/QOWPX2JP4CguKyejfYYsyi8fvYW77uy5nP2RY3dAUgIUqxDyJOIN4FnYaSBJm0QMxeIfD+epSjyZmm+Po+Uq8ScxaTpuzAYyQi0XxZQr7e7G3BvN5SmpQt4PGinnei4SKUIEGbkf65kVVpdUfae42ZBLd+kGgDNapFKF8o+9JVTWG4I5O0BDefqphAIGrmEqesb3AHJ7H3Ivo2Gl3LolA4tNyoIyihGxPcnF4tHKCHLgY3wQrKsT90SsokpJTqQf0NN3lA6HdAJgGHabmRp/D8RpTefGbcXuL/1aT3KYWos0G+wIE9JSUd6pbDxGdkW4o+XXhjZjXUyquq67JzWJEAaxtyBeZj4TIv+PbF4KmQkHlVuoQVHI4axbW8lZSy++9uxrlLniHe34xeMUOybtzwz6NI1AsaNTLF3hS7ajcw+3zgBmUZk/kPpE6b2Ji2sMR9hxZN4R1CIGCoHRTdJVfRxccqyfhCvPBGV1GzEh4Mht5Nu/TtxKqqQ4u1dkBufRhgSPhvObZcNBvCwTXHnfblktRzgazQjXq9Wy84ovSvIcDc+bGLQc8P5R1g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(376002)(396003)(39860400002)(136003)(346002)(366004)(451199015)(186003)(53546011)(9686003)(122000001)(83380400001)(38100700002)(55016003)(7696005)(64756008)(66574015)(76116006)(26005)(2906002)(5660300002)(6506007)(52536014)(71200400001)(296002)(54906003)(966005)(66556008)(4326008)(478600001)(6666004)(8676002)(66476007)(66446008)(8936002)(41300700001)(110136005)(66946007)(316002)(30864003)(33656002)(66899015)(86362001)(38070700005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 5A6ykfNt4WB0VoNSDLWpotFSTU2keL74dVSW9l1zWLXtlK7WxCQKXScFpUmo1JjHAkYoNQyQPUMEh3sngbPP+VSF2Wtqsl2AcfqHv4ahkltzkJS9e56QZ480zXRcSYNaYx7JQenHQ9HeYxBI8H9KQNIFVoYwq29b75XC0CJJ0TZRuw6sKfVuhWC8xh5yNCWX0xy3aer2d1VF6eYvvN8pwBaQevflobs5dyAGw8xC6DlkdJtQOmj9v/Lskcbnw2wTFT6zELRiWFlmxFjfgQovZ07BfapU89CsfXEnyVn9/5BiQYanEUf0xPUgPsXrtAkwon54mKMXcS6qPIEFcUk8Z5FCk6tjODZGsMkNVs9Y9QxGNrQN4BthcIznY2KyRPVt0ODjW3UmdzfLCU1R4D0X/qv6EYkmCq4/lQbhkDohUmSgTvOux5HjIrmSYc+J2Ysc4CVam7QqV5yPLm94gWObR4cpo7CYcMREpOG6YnFd2bSb9/4vRZzPO3lr9aONbwflnidoYnhLz8QOglhhEOPSNe/+IaeqAkBQXDIbAsNKg0AyjJ26bG1rPzq521ZwYoY9etJpv93c4iym1EGOAYZLoIxA0bWPOHMgb3OWKEdyUm1lu7KXpPsw4Dq17+Jj6Kk9c4q3dKZZczgvdG0k7hNAKlpdu29nZN51Hr2vL81KDaFE5i+dqjooZGoxJfBsTx8FS+A/kAd6QVoISUlfwe4yH46F3qKFdF1MUSANFUSMyi/b4tsKpPpLhxKnNzR6qK9KK6PE3WNEu7cLW7xRgp2rvXKHRGLaIDFwuii2wv8+sWbOOiKX/3hqSVwdEHp9BrhDai1xFRFuYIHvMPpS4+9toHjPJ+flRvl1dzWUGs+f9kQo4O2k6PobYX5CccLUAdE/o4sPcBEL9I36VmUOA/Bo0vOEkbWmGYmeDR1+VrToTpofQNCLRnyMxkbsEgZq9lf1PB5eRQtAtxrn+6c9z33qxTtFDgfJ7J54G74Q8JgwZ0HlBGy6GQNHLKQKNk7J3lW3ga1JZuzl0rmXZ4RvrQBS1ncuu7IVLOdYRVgQMlHMkpR2MEDCEUTRuZzp6ZyJrTMjjO8l6MRkvWkyMncodLwyBQ5UTF0Bgqly1fxeZxVIFX01qp3prOKVlMYnkxE/w3hIWv/1CMKzVjlXokWzqRgxnbjuwlvRu43CAuVn4DxC9x/BY5UKg8wxeeCifFlE3i8vYdzSUVaRuTR1LsGTTJjhzrqgMyg6zEz3jP49rRFmao+8qnwWP0PZDTxGwhGXx/xOs5HoG9N2SqlxAduKmuw/PkaUQQajZ7wAhAmLSltr0tx0b1eXB2dvx9wyoER1igiGzmtcUeR2p4BtHGMp/Fgmu2I0GZYUlmlh039TP6RCPiq/Jw0zonIaMUwueZyDYlHNBb4DdS1fS22V/d6a1tLJ4Bx/yoXB31nonepb6spmbAHSbRdb4UnKgJV5gqZcvl6YDUqQ/tvsksbgWr8+V88abwMjFQnjjerTvjU/+3JbFTsdgD7i45XgLTCi4VRbrvZxjpUKWiNiEfaXftnXMXF/vJCG3erEtYs90ZPIxjeQvGUQqSI4URo8g03wGJ85FPYo
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c16088e1-37c0-4546-e931-08dacbe96211
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2022 17:54:05.9037 (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: lhx28EP8tfv+4YOTqe8UvFu5T0UyM6M6HCmErmtxB4/liQum8xG6+aN5m7xnfCGkFXrsqbCDvDa/6moODTFesw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5437
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.135.122, xfe-aln-002.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/cncS8wd7GzeULiaZhLXBm8OCN6o>
Subject: Re: [IPv6] WG Last Call on draft-ietf-6lo-multicast-registration-11
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Nov 2022 17:54:14 -0000
Done 😊 many thanks, Tom. > -----Original Message----- > From: tom petch <ietfc@btconnect.com> > Sent: lundi 21 novembre 2022 18:08 > To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Mark Smith > <markzzzsmith@gmail.com>; carles.gomez@upc.edu > Cc: 6lo@ietf.org; 6man WG <ipv6@ietf.org> > Subject: Re: [IPv6] WG Last Call on draft-ietf-6lo-multicast- > registration-11 > > From: Pascal Thubert (pthubert) <pthubert@cisco.com> > Sent: 21 November 2022 13:11 > > Many thanks Tom. > > As a reference for the reader since it is unpublished, the current > title in github is: > " > IPv6 Neighbor Discovery Multicast and Anycast Address Listener > Subscription " > And the current abstract is as follows: > " > This document updates RFC 8505 to enable a listener to subscribe an > IPv6 anycast or multicast address; the draft updates RFC 6550 (RPL) > to add a new Non-Storing Multicast Mode and a new support for > anycast > addresses in Storing and Non-Storing Modes. This document extends > RFC 9010 to enable the 6LR to inject the anycast and multicast > addresses in RPL. > " > > > > Equally I found Multicast on its own adequate, Yes the I-D caters > for > > Anycast and that is in the Abstract but I query the need for it in > the > > Title- a reader might well wonder about the latter and find the > > answer in the Abstract. > > Pardon my non-native limitation here; I read this as: > "anycast is superfluous, find it in the abstract" is that correct? > The source of confusion is that your initial proposal was "Subscribing > to IPv6 Broadcast and Multicast Addresses in a 6LN Network" > Which clearly was a typo so I read " IPv6 Broadcast" -> "IPv6 Anycast" > and I applied that. Also, Mark recommended to place Anycast in the > title. > > > My thought remains that the Title should lead into the Abstract, as > > the Abstract leads into the document but in neither case will the > > former cover all that the latter does. > > Makes full sense to me. > > > So with no explicit mention of ND in the Abstract I query its > > appearance in the Title. > > I guess this calls for a change in the abstract to mention it. > The tension here is that we need to list RFC 8505 in the abstract > because we extend it. RFC 8505 is "Registration Extensions for IPv6 > over 6LoWPAN Neighbor Discovery" so using those words in full would be > cumbersome. > > > I think that the Title of the RFC needs to indicate the type of > > network involved and did look at other RFC to see how this network is > > referred to and see much usage of Low-Power Wireless Personal Area > > Networks (6LoWPANs) which seems cumbersome to me but suggests that > > there is no recognised, shorter tag which might be used:-(. > > True; and even worse, LoWPAN in IEEE parlance is 802.15.4 only. > But 6LoWPAN ND works on any link I'm aware of. So the term 6LoWPAN ND > is Highly misleading. > > > > > As you gather, I think that titles matter, as do abstracts, that they > > should be short enough to read, recognise or remember but should not > > be overloaded with all the possible semantics. > > > > By contrast, I care little about the title of the I-D which almost > > vanishes once the RFC is published; for me, many I-D titles are too > > cumbersome although this one is just fine (no need for Anycast or ND > in it:-). > > I appreciate that, Tom. > > From the discussion above I'm not sure I should take anycast out of the > title. > I made the changes below: > > IPv6 Neighbor Discovery Multicast and Anycast Address Listener > Subscription > > This document updates the 6LoWPAN extensions to IPv6 Neighbor > Discovery (RFC 8505) to enable a listener to subscribe an IPv6 > anycast or multicast address; the draft updates RPL (RFC 6550) to > add > a new Non-Storing Multicast Mode and a new support for anycast > addresses in Storing and Non-Storing Modes. This document extends > RFC 9010 to enable the 6LR to inject the anycast and multicast > addresses in RPL. > > <TPn> > Well, thank you for considering my suggestions. I will shut up now > about the Title but with a couple of editorial thoughts on the > Abstract. 'the draft' might be better as 'the document' and do you > 'subscribe' addresses or 'subscribe to'? I think the latter. > > Tom petch > > > Many thanks, > > Pascal > > > > -----Original Message----- > > From: 6lo <6lo-bounces@ietf.org> On Behalf Of tom petch > > Sent: samedi 19 novembre 2022 13:47 > > To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Mark Smith > > <markzzzsmith@gmail.com>; carles.gomez@upc.edu > > Cc: 6lo@ietf.org; 6man WG <ipv6@ietf.org> > > Subject: Re: [6lo] [IPv6] WG Last Call on draft-ietf-6lo-multicast- > > registration-11 > > > > From: Pascal Thubert (pthubert) <pthubert@cisco.com> > > Sent: 18 November 2022 10:56 > > > > Hello Tom: > > > > I agree nunicast is weird and I'm not inclined to use it. > > > > About your proposed "6LN network": we do not have that language so > > far. We have LLN but that does not imply 6LoWPAN ND, and RFC 8505 > does > > not imply constrained networks. It is a stateful AAD operation, it > > consumes less resource so it works EVEN in constrained devices and > > networks. It's an EVEN not an ONLY. It makes ND greener. As an L3 > > function, stateful AAD should be abstract to the lower layers, to the > > network they are used in, to the hardware in general. And it is, more > > than SLAAC actually, since SLAAC is limited to certain abstract > topologies (P2P and NBMA). > > > > Also there's a semantic confusion between "constrained node" and > "node > > that supports 6LoWPAN HC" or "node that supports 6LoWPAN ND". In this > > specification, we mean the latter, so we really refer to the L3 > > function not a type of nodes. In other words, we use 6LN and 6LR as > > nodes that support the L3 functions that 6LoWPAN defined as part of > > IPv6 ND for the host and the router side respectively to provide > > stateful AAD. Maybe we should have introduced new terms but at this > > point it makes sense reusing the language in RFC 8505 that we are > extending. > > > > Considering the number of ND broadcasts we observe it's probably time > > we sunset SLAAC in any large network. Our small contribution to the > > planet if you like. But dropping AAC with SLAAC would be throwing the > > baby with the water of the bath. RFC 8505 makes AAD greener and more > > deterministic by avoiding the broadcasts in SLAAC and providing a > > contract between the host and the router for address ownership and > > usability. As you've seen recently on v6ops ML, SLAAC has a huge > issue there and we're now hitting that wall. > > > > <tp> > > Pascal > > > > Thank you for the comprehensive reply. > > > > My thought remains that the Title should lead into the Abstract, as > > the Abstract leads into the document but in neither case will the > > former cover all that the latter does. > > So with no explicit mention of ND in the Abstract I query its > > appearance in the Title. > > > > Equally I found Multicast on its own adequate, Yes the I-D caters > for > > Anycast and that is in the Abstract but I query the need for it in > the > > Title- a reader might well wonder about the latter and find the > > answer in the Abstract. > > > > I think that the Title of the RFC needs to indicate the type of > > network involved and did look at other RFC to see how this network is > > referred to and see much usage of Low-Power Wireless Personal Area > > Networks (6LoWPANs) which seems cumbersome to me but suggests that > > there is no recognised, shorter tag which might be used:-(. > > > > As you gather, I think that titles matter, as do abstracts, that they > > should be short enough to read, recognise or remember but should not > > be overloaded with all the possible semantics. > > > > By contrast, I care little about the title of the I-D which almost > > vanishes once the RFC is published; for me, many I-D titles are too > > cumbersome although this one is just fine (no need for Anycast or ND > in it:-). > > > > Tom Petch > > > > All the best, > > > > Pascal > > > > > > > > > -----Original Message----- > > > From: tom petch <ietfc@btconnect.com> > > > Sent: jeudi 17 novembre 2022 17:53 > > > To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Mark Smith > > > <markzzzsmith@gmail.com>; carles.gomez@upc.edu > > > Cc: 6lo@ietf.org; 6man WG <ipv6@ietf.org> > > > Subject: Re: [IPv6] WG Last Call on > > > draft-ietf-6lo-multicast-registration- > > > 11 > > > > > > From: ipv6 <mailto:ipv6-bounces@ietf.org> on behalf of Pascal > > > Thubert > > > (pthubert) <mailto:pthubert=40cisco.com@dmarc.ietf.org> > > > Sent: 17 November 2022 12:02 > > > > > > Done 😊 > > > > > > <tp> > > > Piling nouns in a heap often does not work well in English and may > > > be ambiguous. The Abstract seems clear but I would not have > > > expected it from the title, old or new. > > > > > > Neighbor Discovery is not in the Abstract and I do not think it > adds > > > to the Title. The Abstract has subscribe as a verb and that seems > > > to me > > spot on. > > > > > > The Abstract has 6LR without expansion but it does narrow the scope > > > from all aspects of ND. > > > > > > Hence I suggest something along the lines of Subscribing to IPv6 > > > Broadcast and Multicast Addresses in a 6LN Network. > > > In passing, I saw recently the term 'nunicast' and thought it ugly > > > and incomprehensible. It got revised to non-unicast which I > > > understood and then to multicast and broadcast. > > > > > > Tom Petch > > > > > > From: ipv6 <mailto:ipv6-bounces@ietf.org> On Behalf Of Mark Smith > > > Sent: jeudi 17 novembre 2022 2:18 > > > > > > Hi, > > > > > > I think the naming needs to change now that it is also doing > > > anycast, to something like "IPv6 Neighbor Discovery Multicast and > > > Anycast Address Listener Subscription". > > > > > > I think anycast is a different and distinct type of communication > to > > > multicast, and is in the middle between unicast and multicast: > > > > > > i.e. unicast = 1 to 1; anycast = 1 to 1 of any/many; multicast = 1 > > > to many; > > > > > > Regards, > > > Mark. > > > > > > > > > > > > On Thu, 17 Nov 2022, 00:23 Carles Gomez Montenegro, > > > <mailto:carles.gomez@upc.edu<mailto:carles.gomez@upc.edu>> wrote: > > > Dear 6lo WG, > > > > > > (CC'ing 6man.) > > > > > > This message initiates WG Last Call on the following document: > > > > > > "IPv6 Neighbor Discovery Multicast Address Listener Subscription" > > > https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast- > regis > > > tr > > > ation-11 > > > > > > The Last Call will end on Wednesday, 30th of November. > > > > > > Please provide your feedback on this document on the mailing list. > > > Short confirmation messages such as "it looks fine" are also > welcome. > > > > > > Thanks, > > > > > > Shwetha and Carles > > > ------------------------------------------------------------------- > - > > > IETF IPv6 working group mailing list > > > mailto:ipv6@ietf.org<mailto:ipv6@ietf.org> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > ------------------------------------------------------------------- > - > > _______________________________________________ > > 6lo mailing list > > 6lo@ietf.org > > https://www.ietf.org/mailman/listinfo/6lo
- [IPv6] WG Last Call on draft-ietf-6lo-multicast-r… Carles Gomez Montenegro
- Re: [IPv6] [6lo] WG Last Call on draft-ietf-6lo-m… Esko Dijk
- Re: [IPv6] WG Last Call on draft-ietf-6lo-multica… Mark Smith
- Re: [IPv6] WG Last Call on draft-ietf-6lo-multica… Pascal Thubert (pthubert)
- Re: [IPv6] [6lo] WG Last Call on draft-ietf-6lo-m… Pascal Thubert (pthubert)
- Re: [IPv6] [6lo] WG Last Call on draft-ietf-6lo-m… Michael Richardson
- Re: [IPv6] WG Last Call on draft-ietf-6lo-multica… tom petch
- Re: [IPv6] WG Last Call on draft-ietf-6lo-multica… Pascal Thubert (pthubert)
- Re: [IPv6] [6lo] WG Last Call on draft-ietf-6lo-m… Pascal Thubert (pthubert)
- Re: [IPv6] [6lo] WG Last Call on draft-ietf-6lo-m… Michael Richardson
- Re: [IPv6] WG Last Call on draft-ietf-6lo-multica… tom petch
- Re: [IPv6] WG Last Call on draft-ietf-6lo-multica… Pascal Thubert (pthubert)
- Re: [IPv6] WG Last Call on draft-ietf-6lo-multica… tom petch
- Re: [IPv6] WG Last Call on draft-ietf-6lo-multica… Pascal Thubert (pthubert)