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 68DD5C14F6F2 for ; Sun, 27 Oct 2024 00:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 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_BLOCKED=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_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 F4q9k9zcJeRq for ; Sun, 27 Oct 2024 00:24:21 -0700 (PDT) Received: from sonic304-53.consmr.mail.ne1.yahoo.com (sonic304-53.consmr.mail.ne1.yahoo.com [66.163.191.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED26BC14F6AD for ; Sun, 27 Oct 2024 00:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1730013860; bh=lvysjYpJuVa2R2MUuRAAvy88USWCDPEaJ8MuMn6YleA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=oxFeTw1ODgTrkCG6/hTRA7O179KrujgrzK/tb+Q5MtT3AFoM67Gz5mH4wczSy1OJoiC6y5hwkefl/dI3HbwgxcnPqtSovkIGTAnpaP5AwIw49IxDRZVYrUXELSRjfbx8aOaFIBO2LBwt3dLMB5GoJ+kBvXEF3q0hxvg96/XOmL089kWogJe2jsynrzDS26hEBiq7vqIgfO2jT9xkhpzQZSr/DqawiC3UI1XP0c8efaQ6JuEeJKT3C2+kSgPVYGpKsJ+lspXpL65eIp/J3cbtBM1oKY3ltlptRhkH4Jtsx3yfBF8dthJFVx8u+kOK4lFF8Yezh7M5JWFtdc6fsY2Gtg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1730013860; bh=qlHprTa28kL1xmAIm1LbMawUndiFphj0GJLWOm0nw/I=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=o0r0NZ8/yW/+jiW0oMyvRj6WZboTZ2hdbp1et+4s7Zg+l5PkHKHaekPJ/QSovxSgsuEmpPOU+/hdn2MkjfLlB4nIoawxeR2PvIassM7VbDa+l4nR9DerXwDZ22rfiXpKys0y+HgsW4nBC0aKWEkdGSJnTrFfvwsGD1RR09NFt4xSQcL3ZkEllkqtSBT6xYjx8KwztWRtybFmIysDTptyhJAQEdoaCLxfJ75D5jOE3CVM8EWxLKL8lvmBKWxNSDUEuAxXEoHAUJOub2Y269SF11oVvdreyvJbOA9JG50C8LqkeR23DvRotSowl7dKBevHrnWePw1PqouzuJCwDRSbFA== X-YMail-OSG: Uko5ccsVM1l6ho_LChUNPdwH2xJHpclf4z1IOkbwe3URRf5dXYP5wHF05fo9LmD 25.hZx2enylosuN8WCI7a8I_CuQ7_1rCRojJSzl0HgYfsgDhOnXpYbgHkNftlJh.RbZhOs_Yf95A QlLTq4IkxEE6y40HHDJek7GEVf6cl94VYnKd7CmLCPxXkeSMicXpt1GgvLzrer9ruzaM0hwiMgmd EwlH3VWdRlW.KiLyl.5fCO68RIuXC8_Tn8jBTUwqs_7TdcEKaQuJHOOIigo5FjyB_DmzfyAoOq9L xRmuhlfRJBtROiZdkgVajO9jMAjTIba0D.T3Q_COYPVtS_bybtIohZETOR2C0v0WOWH7Gxt_.n6j e9PELQoPL9TfIqFvgR0F_k1potd81QCBTPXFxa4bFcwFBQLEUs5.5Wg3s5Yl2VNk3yC6vsA3v2M7 A2VRM6Rmmgw7BYkBI9jOfNp0z226gt3DCCUG7u_jd8CH6rMnrNt9vpLUmxNqHpSaCLuKC__w5AuO dXVMooM86RTuQxhvcTeua81hLjgvmxPlGqey.hxut1ki6LjoqrlLWb8Xw5ny6mOjOoeJGIeR52uB xnRS1xq6ZhO0EHkCe8eWoksGw4h724LVxkjpKYjN.W.9cmTsY4DmRA.DsE2HGRWWDwxyh9fKzW4T EDclwBElkB8cPbDmZfeNpBuf4jZKfbIiLMtsstcruVNqId3Z1r._DNyASZT3K3VI8gRYwCASxh0g MlWoSu2SYHob.TZGzx21ynQLEl7MubTeI9TI5fUYXa50H4j8.XcdX0_luAywVIsQeF3slrQ7vvbf PZfcXHUFox4BLhsz_Kr5TlCkjCuJjuO6evKDMZjcHnC.eNmUBLeUxcwtgcI3WAiOQ6JUiA9eQ09q B6TwKdilC6o.IUpIUZR5SZbarydvwFfKfiU5xkBAcCJKzcj_KPZCYhsEcHPWC6yfi1tsH2VGX.SG JTKQfpb31PBjKYDzcp2hYYHOBjTnfP1Ul7xNVDC27v5jZ.SNKeU3AUuZ9aTf97RcUbuNaEDbeQ_6 lAj8jYxSEADTfj6V333sWylpIs_.x5Wzol5lzqjSw1Pr73zOhe0OdTxr.89TnHRj3eUMVfd98Bvd PGd28J7ZtpQJ5OnxJmFvcS09MMmuIzchqYPjcBh_qxvth1SaU5eY.PCP7ID50XfjREU3aWFoxEad 2x22bP.fsG1ArI.hdBmxfaGKbi7o2GYjluorR5ly1MGuV4dm2nZRaypw_iblbE4PWFnbt9jF.X98 og5wD8WP1bPpS.5ehD08mPCCr7YPZ4lrgWm.MNyIqgjDoVAATu7jeyt9LJp_oFpK_kChU_lzmLp3 wFke9VO1iw5ibcLQ6fHv2jILO3j.mTRnGuM5G2Gmx4Q4dzkJ8pjlyjHTOZ7VnGYTy6yJ4VacRBpg 4GRoA1omgwMWfNweAJMsv3fbPyrm0rfrlc3r11UexCcNddjkqlJOAFk0ruvurvCzM_.uYZHeey16 zk2_WGCaEQEeuw6DmgwxJtz9qXKKFuD5gRgNYif6BhuPe.gokxuPI4RCtV1D1jHdsjmdnNbtdU0B ypVA_jjz.Ilojft2EXk_N3UWFoJMu51uC_JHCE9UxnHxCLvIVsZCu7zUdu15qKZxyLdf9vdlM54R .prbBXhceF_UYl2D_cpdM5jNlE6VlwSNhIRlN6p3l_FULT2tQQR4VTXebVEASyVhiu.zo4jORN.r 5Uk9.4W7qQTU_M.MIrU3uHddwAqSZU14u9xlCXTQ0kW3XzUtXoIb4bu5ZgSUQ5wd8ydxRamNyC9a lJTeVTDC8RUfys8x.os4UI7D3dmr3Bj4_EsbcpA4V1QnCJOHZUYdGJKzlOJV0Y4PpQmHqwRV_Arg bFghOyxj8rVh2JeKklO_5k_.JPV6KP3E4muPycSy3Ao.D9ZpOaPgX2NSAL2K7zSpCZvHgBqI1DEX SVDt2hiYkaRRD9gkaOyWcRTOLq4cYk_w4xj1bp2RWNE9mojYmCQY6F_jevDIMhztD.TGeW_S5sDq FF148Rm1j.D4si8ovx26B_UgE0i6bpNSZzoEDldlq8LiAdRL1K5HDbwnonuIeI.str5mKAHDJ4FF dAFWLAEcIQZHGHh_YOb7283x8_VFVz4kY4YJW7tNRoYVbvyyUerk7BiPafSG4Dk66PEBwH_nMcZO AcZdFNI4OMcPKuBh02558DetqSCC6honusGcxx8eAK9awjrf7qQl97.U67gRImOTbYNsVJGGRySY uh6zS9._VMvZIi_ald8B6iNkNpbMOgBM0ofpJbQu2.mFVQZGUxAHx0BE6erRLwtntv3fSD.koCMg - X-Sonic-MF: X-Sonic-ID: f71cf48c-7997-4f0f-82fa-60d6eff2e357 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Sun, 27 Oct 2024 07:24:20 +0000 Date: Sun, 27 Oct 2024 07:22:04 +0000 (UTC) From: "nalini.elkins@insidethestack.com" To: The IESG , John Scudder Message-ID: <298224448.6633034.1730013724935@mail.yahoo.com> In-Reply-To: <172952307207.1992747.8170300186220087852@dt-datatracker-78dc5ccf94-w8wgc> References: <172952307207.1992747.8170300186220087852@dt-datatracker-78dc5ccf94-w8wgc> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6633033_498512630.1730013724931" X-Mailer: WebService/1.1.22806 YMailNorrin Message-ID-Hash: 2O3CNTGUKG53LC6QBT74UGNQCY5PTOBF X-Message-ID-Hash: 2O3CNTGUKG53LC6QBT74UGNQCY5PTOBF X-MailFrom: nalini.elkins@insidethestack.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ippm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "draft-ietf-ippm-encrypted-pdmv2@ietf.org" , "ippm-chairs@ietf.org" , "ippm@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bippm=5D_Re=3A_John_Scudder=27s_Discuss_on_draft-ietf-ippm-encry?= =?utf-8?q?pted-pdmv2-09=3A_=28with_DISCUSS_and_COMMENT=29?= List-Id: IETF IP Performance Metrics Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_Part_6633033_498512630.1730013724931 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, I am starting to address everyone's thoughts one by one.=C2=A0 =C2=A0So, th= ere will be multiple emails but then we can keep each thought chain separat= e. >From DISCUSS: > I was surprised not to see any discussion of the global pointer in the pr= ivacy considerations. I didn=E2=80=99t see any helpful discussion > of depl= oyment assumptions in the present document, but RFC 8250 says, >=C2=A0 =C2=A0Advantages include:=E2=80=A6 >=C2=A0 2. Ability to span organizational boundaries with consistent instru= mentation. > That implies to me that a given server might simultaneously be providing = instrumentation to clients within different=C2=A0> organizations. A reasona= ble default assumption is that it=E2=80=99s inappropriate to leak informati= on about one of these> clients to another. One might argue that even the me= trics RFC 8250 exposes can leak some information to a savvy endpoint, > but= the global pointer does so explicitly and by design: one client now gets t= o find out what the aggregate packet rate to other > clients is. > It seems as though this deserves explicit treatment in the security and/o= r privacy considerations. Or of course if I=E2=80=99ve missed=C2=A0> someth= ing (e.g. this kind of data exposure between clients was always the expecta= tion and everyone but me knows this)=C2=A0> please help me see that. First: >=C2=A0 2. Ability to span organizational boundaries with consistent instru= mentation. The key word here is "consistent".=C2=A0 The intent was that business partn= ers who have performance problems in their connections between each other w= ill be able to compare metrics. This is not the same as saying that clients from different organizations wi= ll be using a shared server.=C2=A0 That is a different issue.=C2=A0 So, let= 's take that on. Second:=C2=A0=C2=A0 My thought on one client being able to see the aggregate number of packets = sent by the server to all clients when using a server which serves multiple= organizations is that, yes, this is an exposure but how one would use this= in a way that is detrimental eludes me. If a client knows how many packets her organization is sending and the numb= er of global packets is larger than that, then she can possibly assume that= there are other organizations on that server.=C2=A0 BUT not how many other= organizations nor how many other clients.=C2=A0 Also not=C2=A0if the packe= ts are TCP, UDP, ICMPv6 or anything else.=C2=A0 These packets may well be N= D6 packets, depending on what the administrator has chosen to monitor with = PDMv2. By getting multiple values of the Global Counter at intervals, one could po= ssibly deduce if there was some type of constant or consistent traffic but = it would be a guess as to what that was.=C2=A0 Is it video?=C2=A0 Is it an = FTP? The idea of the counter was to enable the network performance analyst to "g= uess" at how busy the server was.=C2=A0 =C2=A0If the server response time i= s less than desirable and the Global Counter is increasing rapidly, then a = conversation could be started with the manager of the server.=C2=A0 The ide= a of PDMv2 is to do quick triage, that is to allow an organization to know = if the problem is more likely than not in the server / application componen= t or the network.=C2=A0 I have been on calls with many people on them to tr= y to solve just this particular issue on large production enterprise networ= ks.=C2=A0 =C2=A0Once you can point people in one direction or another, then= the teams for the server / network have many other fine-grained tools at t= heir disposal. For a hacker, there are better and easier ways to find actionable informati= on.=C2=A0 =C2=A0This reminds me a bit about when I was using a shared hosti= ng service to test IPv6 extension headers and we could see by doing a ping = to ff02::1 (multicast all nodes) and a Wireshark packet trace, that ALL the= other clients responded!=C2=A0 =C2=A0Then, we could actually tell WHO the = clients were and their link local address and so forth.=C2=A0 (The hosting = service has since disallowed response to FF02::1.)=C2=A0=C2=A0 In my opinion, if you do a Wireshark packet trace at a coffee shop or on th= e airplane, there are many very interesting pieces of information you can g= et which are far more useful to a would-be hacker than the Global Counter. The other thing is that your organization is using a shared service, the ad= ministrators of that organization's network know it is shared.=C2=A0 That i= s, it is not a shock that when you sign up for cloud hosting with a public = provider, that other organizations also use that service.=C2=A0 A network a= dministrator who wants all data and metrics to be completely private will n= ot use a shared service. Having said all this, we can certainly put some subset of the above as a gu= idance to the implementor in the draft to make it explicit that the value o= f the Global Counter can be seen by all users of the particular server. Thoughts? Thanks, Nalini Elkins CEO and Founder Inside Products, Inc. https://www.insidethestack.com PresidentIndustry Network Technology Councilhttps://www.industrynetcouncil.= org=20 On Monday, October 21, 2024 at 05:05:05 PM GMT+2, John Scudder via Data= tracker wrote: =20 =20 John Scudder has entered the following ballot position for draft-ietf-ippm-encrypted-pdmv2-09: 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://www.ietf.org/about/groups/iesg/statements/handling-= ballot-positions/=20 for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document. I have one point I'd like to have a discussion ab= out: ## DISCUSS I was surprised not to see any discussion of the global pointer in the priv= acy considerations. I didn=E2=80=99t see any helpful discussion of deployment a= ssumptions in the present document, but RFC 8250 says, =C2=A0 Advantages include: =E2=80=A6 =C2=A0 2. Ability to span organizational boundaries with consistent =C2=A0 =C2=A0 =C2=A0 instrumentation. That implies to me that a given server might simultaneously be providing instrumentation to clients within different organizations. A reasonable def= ault assumption is that it=E2=80=99s inappropriate to leak information about one= of these clients to another. One might argue that even the metrics RFC 8250 exposes = can leak some information to a savvy endpoint, but the global pointer does so explicitly and by design: one client now gets to find out what the aggregat= e packet rate to other clients is. It seems as though this deserves explicit treatment in the security and/or privacy considerations. Or of course if I=E2=80=99ve missed something (e.g.= this kind of data exposure between clients was always the expectation and everyone bu= t me knows this) please help me see that. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENT ### Global Pointer naming I found the name =E2=80=9CGlobal Pointer=E2=80=9D curiously opaque. It=E2= =80=99s not a pointer in any conventional sense. I=E2=80=99m sure there=E2=80=99s some perfectly sensibl= e historical reason for this nomenclature, but if I were picking a name ab initio that wouldn= =E2=80=99t be it. =E2=80=9CGlobal Packet Count=E2=80=9D seems more descriptive, for insta= nce. ### Section 6.4 =C2=A0 =C2=A0 =C2=A0 The basic mechanism is to encrypt the =C2=A0 symmetric key with the public key by joining both yields. I don=E2=80=99t understand what this means. In particular, =E2=80=9Cby join= ing both yields=E2=80=9D doesn=E2=80=99t make sense to me. If I remove those four words, the sentenc= e scans fine. Would it be reasonable to do that deletion? _______________________________________________ ippm mailing list -- ippm@ietf.org To unsubscribe send an email to ippm-leave@ietf.org =20 ------=_Part_6633033_498512630.1730013724931 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=
John,

I am s= tarting to address everyone's thoughts one by one.   So, there wi= ll be multiple emails but then we can keep each thought chain separate.

From DISCUSS:

> I was surprised not to see any discussion of the global pointer= in the privacy considerations. I didn=E2=80=99t see any helpful discussion= > of deployment assumptions in the present document, but RFC 8250 says,=

>  &= nbsp;Advantages include:
=E2=80=A6

>  2. Ability = to span organizational boundaries with consistent instrumentation.

> That implies to me that a given server might simultaneo= usly be providing instrumentation to clients within different 
> organizatio= ns. A reasonable default assumption is that it=E2=80=99s inappropriate to l= eak information about one of these
> clients to another. One might argue that eve= n the metrics RFC 8250 exposes can leak some information to a savvy endpoin= t, > but the global pointer does so explicitly and by design: one client= now gets to find out what the aggregate packet rate to other > clients = is.

> It seems as though this deserves explicit t= reatment in the security and/or privacy considerations. Or of course if I= =E2=80=99ve missed 
> something (e.g. this kind of data exposure between cli= ents was always the expectation and everyone but me knows this) 
=
> please he= lp me see that.

First:
<= br>
>  2. Ability to span organizational bounda= ries with consistent instrumentation.

The k= ey word here is "consistent".  The intent was that business partners w= ho have performance problems in their connections between each other will b= e able to compare metrics.

This is not the same as saying that clients from different orga= nizations will be using a shared server.  That is a different issue.&n= bsp; So, let's take that on.

Second:  
My thought on one = client being able to see the aggregate number of packets sent by the server= to all clients when using a server which serves multiple organizations is = that, yes, this is an exposure but how one would use this in a way that is = detrimental eludes me.

If a client knows how many pack= ets her organization is sending and the number of global packets is larger = than that, then she can possibly assume that there are other organizations = on that server.  BUT not how many other organizations nor how many oth= er clients.  Also not if the packets are TCP, UDP, ICMPv6 or anyt= hing else.  These packets may well be ND6 packets, depending on what t= he administrator has chosen to monitor with PDMv2.
=
B= y getting multiple values of the Global Counter at intervals, one could pos= sibly deduce if there was some type of constant or consistent traffic but i= t would be a guess as to what that was.  Is it video?  Is it an F= TP?

The idea of the counter was to enable the network = performance analyst to "guess" at how busy the server was.   If t= he server response time is less than desirable and the Global Counter is in= creasing rapidly, then a conversation could be started with the manager of = the server.  The idea of PDMv2 is to do quick triage, that is to allow= an organization to know if the problem is more likely than not in the serv= er / application component or the network.  I have been on calls with = many people on them to try to solve just this particular issue on large pro= duction enterprise networks.   Once you can point people in one d= irection or another, then the teams for the server / network have many othe= r fine-grained tools at their disposal.

For a hacker, there are bette= r and easier ways to find actionable information.   This reminds = me a bit about when I was using a shared hosting service to test IPv6 exten= sion headers and we could see by doing a ping to ff02::1 (multicast all nod= es) and a Wireshark packet trace, that ALL the other clients responded!&nbs= p;  Then, we could actually tell WHO the clients were and their link l= ocal address and so forth.  (The hosting service has since disallowed = response to FF02::1.)  

In my op= inion, if you do a Wireshark packet trace at a coffee shop or on the airpla= ne, there are many very interesting pieces of information you can get which= are far more useful to a would-be hacker than the Global Counter.

The other thing is that your organization is using a shared serv= ice, the administrators of that organization's network know it is shared.&n= bsp; That is, it is not a shock that when you sign up for cloud hosting wit= h a public provider, that other organizations also use that service.  = A network administrator who wants all data and metrics to be completely pri= vate will not use a shared service.

Having said all this, we can certainly put s= ome subset of the above as a guidance to the implementor in the draft to ma= ke it explicit that the value of the Global Counter can be seen by all user= s of the particular server.
Thoughts?

Thanks,

Nalini Elkins
CEO and Fo= under
Inside Products, Inc.

President
Indus= try Network Technology Council
https://www.industryne= tcouncil.org


=20
=20
On Monday, October 21, 2024 at 05:05:05 PM GMT+2, J= ohn Scudder via Datatracker <noreply@ietf.org> wrote:


=20 =20
John Scudder has entered the followin= g ballot position for
draft-ietf-ippm-encrypted-p= dmv2-09: Discuss

When = responding, please keep the subject line intact and reply to all
<= div dir=3D"ltr">email addresses included in the To and CC lines. (Feel free= to cut this
introductory paragraph, however.)


for more information about how to handle DISCUSS = and COMMENT positions.


The document, along with other ballot positions= , can be found here:



------------------------------------= ----------------------------------
DISCUSS:
------------------------------------------------------= ----------------

Thank= s for this document. I have one point I'd like to have a discussion about:<= br>

## DISCUSS

I was surprised not to see any di= scussion of the global pointer in the privacy
con= siderations. I didn=E2=80=99t see any helpful discussion of deployment assu= mptions
in the present document, but RFC 8250 say= s,

  Advantages = include:
=E2=80=A6
&nbs= p; 2. Ability to span organizational boundaries with consistent
<= div dir=3D"ltr">      instrumentation.

That implies to me that a given server migh= t simultaneously be providing
instrumentation to = clients within different organizations. A reasonable default
assumption is that it=E2=80=99s inappropriate to leak informati= on about one of these
clients to another. One mig= ht argue that even the metrics RFC 8250 exposes can
leak some information to a savvy endpoint, but the global pointer does s= o
explicitly and by design: one client now gets t= o find out what the aggregate
packet rate to othe= r clients is.

It seems= as though this deserves explicit treatment in the security and/or
privacy considerations. Or of course if I=E2=80=99ve miss= ed something (e.g. this kind
of data exposure bet= ween clients was always the expectation and everyone but me
knows this) please help me see that.
<= br>

----------------------= ------------------------------------------------
= COMMENT:
----------------------------------------= ------------------------------

## COMMENT

##= # Global Pointer naming

I found the name =E2=80=9CGlobal Pointer=E2=80=9D curiously opaque. It=E2= =80=99s not a pointer in any
conventional sense. = I=E2=80=99m sure there=E2=80=99s some perfectly sensible historical reason<= br>
for this nomenclature, but if I were picking a na= me ab initio that wouldn=E2=80=99t be
it. =E2=80= =9CGlobal Packet Count=E2=80=9D seems more descriptive, for instance.

### Section 6.4

      The basic me= chanism is to encrypt the
  symmetric key w= ith the public key by joining both yields.

I don=E2=80=99t understand what this means. In particu= lar, =E2=80=9Cby joining both yields=E2=80=9D
doe= sn=E2=80=99t make sense to me. If I remove those four words, the sentence s= cans
fine. Would it be reasonable to do that dele= tion?



_____________________________________= __________
ippm mailing list -- ippm@ietf.org
To unsubscribe send an email to ippm-leave@ietf.org<= br>
------=_Part_6633033_498512630.1730013724931--