From nalini.elkins@insidethestack.com Wed Jan 31 04:44:04 2024 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E98C15108C for ; Wed, 31 Jan 2024 04:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=yahoo.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 gtH6k0ybV-KH for ; Wed, 31 Jan 2024 04:43:59 -0800 (PST) Received: from sonic320-28.consmr.mail.ne1.yahoo.com (sonic320-28.consmr.mail.ne1.yahoo.com [66.163.191.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D264C15108B for ; Wed, 31 Jan 2024 04:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706705038; bh=qdqNdk3uHMaweUUeRuCll5OywOGNFFtgq1NMIHRCRXA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=Qe1IgvL5BnMAiCvmhsYnK81JXCI17qQQ7tCTVxz0VXrr/P7nDbq0ou/qen/VCg5SwtGYtyqBLrqRcZbGMqoKaJyDBVFZhxZY2xrXv21cDxd/Zbcp3VC265hQ7H/NnQvbuA01NeJUxP5Wb9BdyN3ERxp3fEdLhwZSUboY+pBrFgdG2nYU5DHqU94d+vpjl7KOGYAlwDMu2epXQs7SiAUGUcZkpgz8WtA8OVtiPIYEcMhTJHiiyr5C6BhLeB2khwQCiRIAsjmmrSzTstTpc7v2vyGLNZa+6q7LN4hRx6fD6ltJAlIFzmMSVuGNtL6nsaWCxP69BrA+gAAIp/LXLFpAdA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1706705038; bh=uzHTZGMndAPt98KMODh9mn4Tx+bmuHezJ0VlkGf5g7Z=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=L4wLkKIueMqRaTAqD76mMC59suvrb0fbXEAo3Azg+gG5jvRBkR88vYFSP7248pFkt0rC5PcD7Zu33+gW5tytXUc6zV4ZR5otfcVwE15Iqz4m4iHnz8orhWv5ZolUsmRpO/QO3x1jKVqW8Vlx/JPP0JFhzBq7lDsoiMRFhJoYMuXsXkpcl9A0yd7tddrgwYqiPWwgyhHiDSOBknkwESYjwf4yi1qBMZNhmkZcc3nKKx0E1v1z83kG5iXsJHSL22ir7jI54slhiUJ16CTmJ5oVQM0xLtGc+9KswH39hVSWJrXW4lJbpuYh362fRv1ztsOiZyCBSq7fwb7099WSGp6cZA== X-YMail-OSG: MJXw5XwVM1mm_lDsmQTlwTX2VEMMb_29jXpp0VoPZu62iWMwm1pe7GGefl02ZxJ wjfXPLJvwYd.ozT5U9cuSpu8Kaw0v_hMjV2qL4HmKjwFq2qCBvMwOanWRR2iRavCTv8TJnDNLX.Z xAOjJQf9KhzkbgwXzXZNEkSUY7X7_kO4u24IyIF3FKDPw1Cw9.SzMapSShgoGOkMJirIOyF.BkBp cYYcy.pAnRBGHruSBnrPMyepXxj9RgvstBxmEM3TDrpF_qLsi1NTMsQOZsl8NKgBoqBN0tnLnEDp _gMBtD7MtNRte3WmpUsZobiFTBth3i0_YglrudbNNgQSUElNpU3njj6.39Q8diatoSk8FPMZkgiy WDypByRGb_F3W_uXjXCCFiwT_HEht4S.SeG6ZeoIPDt4iNaXnTYMpWAQIMn2NAhLgVkU9iE_k0WP ETaQ75hgQsbImoZTfGm8bwmX54_jctCz6PlvsAAWj_YKTFKpSuv4.G6JtAA8BVwA7ONqlXpiBgoI icMhuWRSBaZsDQkx9FL.O9HYz2vqpGB3VMtYcnScuJr4GDmIASh30GEISAzwvfCOzCR878YFwpnm wdAlARnDxyo_vckJZgqBTAyQzTb8sIOTqXWOq7_2LvAF0IIRR4PkhJQIWrsYJmpptorGs3b7t4gP zxekflxvLDPtxuFOe4_OiGSDtt._tG0vZUC5vBZ7KtsUZ35SR_kH389voDzg2gMPnk2gfjOYdPQO CQjJSGJQDOp5_tY0w.rucvX9FMl2_coY79QG1UtAqWIUCNiCMA6_Ado7ukHZoVlacdgr0LqPrSFr D.GPBeEzDXOQPXn8mNOullq8_6MOjo.O.MTqbr7u42tnHra.GjTnIC.o.j38vvtNinKrj8k9fdZW 0K8W56Lp0TX9qPnCuykID7ZT_K7juBxuZahPErvgodWzYkr1E8hiiMIhVECKG4WTCPeMTaiQDNRK MHOBOcOkhHClzSZi67EtN.2qm9ql6PjPSjnpQuX.zmZQa6nfstEGgW_y1lKV84K.ulgtCQ5dcdjG GC31QjpUjvo1jZBSgx8O75_v4g23ruFnRnuKdhHtXksJGTzzLhpj7VYqfeJHSffjp5w_Zs9kQnN3 B6XQYBqEKvA8GmDj4b8LiKFzNAbjMmS_yZG3N.0y0AC8aGBB_xtsd7wSuvKoBNK23FrSkfv3sccB AQ_D0lHsimZ5Sr.g4oxqTNEquC67aO1zt9cQjv4ZXRgGl6iYzyWEjDUabVuaS_8cJIKJEvVpKYmY it6i0nbfVygNUr32NM0n6LJvxqHqjRMBEDunbxJ6lknb.UBXnGHB0iZOI0vcm6TgHkFXvQOirOIP qnjHqFB2ZKt_E0W_ins55wEPgccAS3pH4P5vcF2bJYr9ti2QcMVbgRx0G93VQsTxQPvd1BVn4tFH 6W3jvDrLTqr7i2aOB0CXBJyh31ZyX.BLxBHdFNDGU3zBygwceyLTOokGmQwSioB19EbMLZPpgUA3 zGntD8EW2SswyLmlr0RsuKCChc819cqPcCKxz9jQfexuJwoL3UCe2bAsyw8ZfZf4KNfsx6j.1Zjt aWLQmv7tERJy3lgbKy0bgoR.hn6L8fjyvWjPrihLExKG_MkJPjxxpFx6OkA2UxojuBRr5IzCfkHn zZWWRS.b38npO8l2YSEigBk5a.dN4rZjFUw9yVUpNoJUIdgHDw9X1ya7dw4XBPN6j.6QXQqTE2A3 4lVo71GWrLc2NABqUtbEty0dVwC5M_sngYS9i0rWOPSCno6uP7lQ6sTavQNwvFa_5nAPkY4oKC05 GAxk2ZkbWIkctQ_.lMQ5MWumel4hdPs1XSUD4LUFRRTTeGjTYogteiGwVsTiUTkZ07NxQ90V26tf DgbQgp.fu2Af09dsHFp7clWdvrhrASd0CNjhpEYxOj4NPfmlUo2U.dQ438M_fQlUEcxOijBpi55i FsVLknJ3_oxHHhgD7qgKJk66eCq2b4pUD34KAIPYxXrxGebPv7EEfUYxVwRXKgdiHNqAJu5Txnte xgHJPDvGHQ4Oq.85wXRRybgvEhYY4iqXF1o6cdTOlnU68ZnPBJR6DC36goZ7TLWU8T6J.jrXHUr. V4f8HoiJ8IFNsSdTDddldUPlYdZrt0TJteWWdco8_coLxEN16SbGrdWjwjy4p5iZaFzqK8ivc6tM UmaUgW0PuqeY5W3LshfoIdHgsx1LgW278tedtn2wCOqbWunCiVAJYB8yqzLO5bb91vA9MvJcSf2Y txU93YlsMBxdSgG263EI9E.DpxTjRhixUOg24O6BG6CuKenSLhZfDwVdgfC_mXYXh2rQI23OREQz VTxcAdjiabptV X-Sonic-MF: X-Sonic-ID: da39c145-58e8-4bc4-82da-7051c26c119f Received: from sonic.gate.mail.ne1.yahoo.com by sonic320.consmr.mail.ne1.yahoo.com with HTTP; Wed, 31 Jan 2024 12:43:58 +0000 Date: Wed, 31 Jan 2024 12:43:55 +0000 (UTC) From: "nalini.elkins@insidethestack.com" To: Tommy Pauly , Dhruv Dhody Cc: IETF IPPM WG Message-ID: <2076366995.3419874.1706705035221@mail.yahoo.com> In-Reply-To: References: <61AC7432-55A9-4E65-A1FE-CB23B3B414B0@apple.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3419873_1495583394.1706705035219" X-Mailer: WebService/1.1.22046 YMailNorrin Archived-At: Subject: Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdmv2-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2024 12:44:04 -0000 ------=_Part_3419873_1495583394.1706705035219 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dhruv, Thanks for the thoughtful comments.=C2=A0 Let us go over them thoroughly an= d we will come back with comments. Nalini Elkins CEO and Founder Inside Products, Inc. https://www.insidethestack.com PresidentIndustry Network Technology Councilhttps://www.industrynetcouncil.= org=20 On Saturday, January 27, 2024 at 01:53:25 AM PST, Dhruv Dhody wrote: =20 =20 Hi,=C2=A0 I support this work, but here are a few comments that should be handled bef= ore sending the I-D to our AD.=C2=A0 ## Suggestions/Query * I am assuming that the procedures specified in RFC 8250 continue to apply= . That should be stated explicitly.=20 * Section 3, Is it correct to say the difference between a client and serve= r is that it is the client that initiates the session? Maybe just state tha= t and other properties are for any endpoint node.=20 * Shouldn't there be some backward compatibility text to explain cases like= -- what happens when a node does not understand PDMv2 and thus expected a = length of 10 as per RFC 8250 but finds a different length. Also I wonder ho= w one decides if a client should use PDM, unencrypted PDMv2 or encrypted PD= Mv2. There should be specific text that says that the server MUST respond w= ith the same mechanism. Are all mechanisms mandatory to implement? Basicall= y we need more text... ## Minor * =C2=A0Section 1, Consider changing Man-In-The-Middle to Machine-In-The-Mi= ddle as per https://www.ietf.org/about/groups/iesg/statements/on-inclusive-= language/ - Section 1, it would be good to introduce what PDMv2 is before stating "PD= Mv2 adds...". - Section 3, mentions terms pkX and skX but never use it, is there a reason= they are defined?=20 - Section 9, you are reusing the option type 0x0F defined in RFC 8250, you = don't need to ask IANA to assign one!=20 - Section A.1, is there a reference to the primary-secondary architecture m= entioned?=20 ## Nits * Section 1, s/current PDM/PDM [RFC8250]/ * Section 4.1, expand HPKE, KEM, KDF (you do that later on in section 5.4, = but it should be done here). Also PSN.=20 * Don't capitalize "CAN" as it is not a BCP14 keyword. Maybe use MAY? * Section 6.3, the formatting for field descriptions is hard to follow.=20 * s/Reserved Bits/Reserved/ - add it MUST be set to zero on transmission an= d ignored on receipt.=20 * s/RFC3552/[RFC3552]/ * Remove appendix B and C as they are empty Thanks!=C2=A0Dhruv On Tue, Jan 9, 2024 at 10:56=E2=80=AFPM Tommy Pauly wrote: Hello IPPM,=C2=A0This email starts a Working Group Last Call for "IPv6 Perf= ormance and Diagnostic Metrics Version 2 (PDMv2) Destination=C2=A0Option=E2= =80=9D, draft-ietf-ippm-encrypted-pdmv2-05.=C2=A0https://datatracker.ietf.o= rg/doc/draft-ietf-ippm-encrypted-pdmv2/https://datatracker.ietf.org/doc/htm= l/draft-ietf-ippm-encrypted-pdmv2-05=C2=A0Please review the document and se= nd your comments in response to this email, along with whether you think th= e document is ready to progress. This last call will be three weeks long, and end on Tuesday, January 30. In= parallel, we have requested another SECDIR review.=C2=A0Best,Tommy & Marcu= s_______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm =20 ------=_Part_3419873_1495583394.1706705035219 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dhruv,

<= div class=3D"ydp5a33f0c9signature">
Thanks for the thoughtful comments.  L= et us go over them thoroughly and we will come back with comments.

N= alini Elkins
CEO and Founder
Inside Products, Inc.

President
Industry Network Technology Council
https://www.industrynetcouncil.org


=20
=20
On Saturday, January 27, 2024 at 01:53:25 AM PST, Dhruv= Dhody <dhruv.ietf@gmail.com> wrote:


Hi, 

I support th= is work, but here are a few comments that should be handled before sending = the I-D to our AD. 

## Suggestions/Query
* I am assuming tha= t the procedures specified in RFC 8250 continue to apply. That should be st= ated explicitly.
* Section 3, Is it correct to say the d= ifference between a client and server is that it is the client that initiat= es the session? Maybe just state that and other properties are for any endp= oint node.
* Shouldn't there be some backward compatibil= ity text to explain cases like -- what happens when a node does not underst= and PDMv2 and thus expected a length of 10 as per RFC 8250 but finds a diff= erent length. Also I wonder how one decides if a client should use PDM, une= ncrypted PDMv2 or encrypted PDMv2. There should be specific text that says = that the server MUST respond with the same mechanism. Are all mechanisms ma= ndatory to implement? Basically we need more text...

## Minor
*  Section 1, Consider chang= ing Man-In-The-Middle to Machine-In-The-Middle as per https://www.ietf.org/about/groups/ie= sg/statements/on-inclusive-language/
- Section 1, it = would be good to introduce what PDMv2 is before stating "PDMv2 adds...".- Section 3, mentions terms pkX and skX but never use it, i= s there a reason they are defined?
- Section 9, you are = reusing the option type 0x0F defined in RFC 8250, you don't need to ask IAN= A to assign one!
- Section A.1, is there a reference to = the primary-secondary architecture mentioned?

## Nits
* Section 1, s/current PDM/PDM [RFC8250= ]/
* Section 4.1, expand HPKE, KEM, KDF (you do that late= r on in section 5.4, but it should be done here). Also PSN.
* Don't capitalize "CAN" as it is not a BCP14 keyword. Maybe use MAY?* Section 6.3, the formatting for field descriptions is ha= rd to follow.
* s/Reserved Bits/Reserved/ - add it MUST = be set to zero on transmission and ignored on receipt.
*= s/RFC3552/[RFC3552]/
* Remove appendix B and C as they a= re empty

Thanks! 
Dhruv

On Tue, Jan 9, 2024 at 10:56=E2=80=AFP= M Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org<= /a>> wrote:
 
Please = review the document and send your comments in response to this email, along= with whether you think the document is ready to progress.

This last call will be three weeks long, and end on= Tuesday, January 30. In parallel, we have requested another SECDIR = review.
 
Best,
Tommy & Marcus
=
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm<= /a>
------=_Part_3419873_1495583394.1706705035219--