Return-Path: X-Original-To: ztcpp@mail2.ietf.org Delivered-To: ztcpp@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 798E4E1863D3 for ; Thu, 23 Apr 2026 01:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776934062; bh=NZoDxgSMY3mllL7a5xtJq1lcqYygNipc3XcXJJwdr2A=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=CahNyPO00Rq7TnEbgJlT4J3LmXoz9JZOsB7ba6jA5LPIoPHgNrH6epBFs7SFXM0w5 MG7rfec6QLOH8Ezkwx4+xQlhq0OG2+xiVPxolWMbhJAQsSkXCXjgnwUaZBMYj3LAuV E+Ern7ul5m39rIhpChycXG/HbcXmT1a34ZwW9rgg= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zatDB9-BXR9 for ; Thu, 23 Apr 2026 01:47:40 -0700 (PDT) Received: from mail-m49197.qiye.163.com (mail-m49197.qiye.163.com [45.254.49.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 3577CE18623C for ; Thu, 23 Apr 2026 01:46:05 -0700 (PDT) Received: from smtpclient.apple (unknown [IPV6:240e:404:7910:6c9:4c49:1386:c190:d88e]) by smtp.qiye.163.com (Hmail) with ESMTP id 3bdace701; Thu, 23 Apr 2026 16:45:56 +0800 (GMT+08:00) Content-Type: multipart/alternative; boundary=Apple-Mail-99E79ED9-C049-41C1-8EFC-8184F5C915D6 Content-Transfer-Encoding: 7bit From: Aijun Wang Mime-Version: 1.0 (1.0) Date: Thu, 23 Apr 2026 16:45:45 +0800 Message-Id: References: In-Reply-To: To: Philip Griffiths X-Mailer: iPhone Mail (23D8133) X-HM-Tid: 0a9db984697f03a2kunmc445a23346972 X-HM-MType: 10 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFITzdXWS1ZQUlXWQ8JGhUIEh9ZQVlCSkNJVhhKSEpJGhlDTUlLGFYeHw5VEwETFhoSFy QUDg9ZV1kYEgtZQVlJT0seQU9LT0FMQkpLQU0YQkFPGE9CQUpIQ01BGEpCS0EfQ0MeWVdZFhoPEh UdFFlBWU9LSFVCQklOSlVKS0tVSkJLQlkG X-MailFrom: wangaijun@tsinghua.org.cn X-Mailman-Rule-Hits: max-size X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; news-moderation; no-subject; digests; suspicious-header Message-ID-Hash: 66Z7KNJGQAWT4KOXWRUS7PGWAOBRAPDS X-Message-ID-Hash: 66Z7KNJGQAWT4KOXWRUS7PGWAOBRAPDS X-Mailman-Approved-At: Thu, 23 Apr 2026 02:06:10 -0700 CC: Chris Hood , ztcpp@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?b?W1p0Y3BwXSBSZTog44CQWlRDUFAgQ2hhcnRlciBEaXNjdXNzaW9uc+OAkVJFOiBS?= =?utf-8?b?ZTogW2FnZW50MmFnZW50XSBSZTog6L2s5Y+R77yaRlc6IE5ldyBOb24tV0cgTWFp?= =?utf-8?b?bGluZyBMaXN0OiB6dGNwcCAoWmVybyBUcnVzdCBDb250cm9sIGFuZCBQb2xpY3kg?= =?utf-8?b?UHJvdG9jb2wp?= List-Id: Zero Trust Control and Policy Protocol Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail-99E79ED9-C049-41C1-8EFC-8184F5C915D6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Philips:

Yes, you can refine the charter in th= e GitHub directly, describe concisely the problem existing, proposed standar= ds approaches and the expected deliverables.

You ca= n expand the current charter but should keep it confine within our initial a= im, that is, =E2=80=9Ccontrol and policy protocol for network and service se= curity under zero trust principles=E2=80=9D.

The Ch= arter is mainly used to convince other experts, invite the possible interest= experts and get the approval from our AD to support the forming of the form= al WG.

Aijun

On Apr 23, 2026, a= t 16:37, Philip Griffiths <philipleonardgriffiths@gmail.com> wrote:
=EF=BB=BF=
Morning Aijun,

Sure. Wrt the c= harter, I would say its a strong starting point and aligns well with th= e need for authenticated-before-connect (ABC) mechanisms and control-plane i= nteroperability.
One area that may benefit from strengthening is e= nsuring that service-based, least-privilege policy can be both e= xpressed and reliably bound to concrete sessions and flows (Seam 4.3). Interoperable policy distribution alone (Seam 4.2) is not sufficient unl= ess identity- and service-based intent can be enforced with verifiable fidel= ity at runtime, rather than being diluted into coarse address-based enforcem= ent.

Should I do a pull request on the GH repo??

Essentially, it would be to help to clarify that:

  • eliminating ambient reachability (Seam 4.1),
  • distributing and updating policy across enforcement points (Seam 4.2),
  • and binding policy intent to runtime sessions and flows (Seam 4.3)

are distinct but interdependent concerns, all required t= o achieve consistent Zero Trust outcomes across implementations.

Additionally, the problem statement could more explicitly reflect the operational complexity of current approaches, where secure con= nectivity often requires coordination across infrastructure (e.g., routing, N= AT, firewalls), governance processes, and distributed enforcement systems. T= his complexity largely arises from the absence of interoperable mechanisms t= o bind identity- and service-based policy directly to communication sessions= , resulting in inconsistent enforcement and reduced agility.

It would also be useful to more explicitly position identity - particular= ly non-human identity (workloads, services, devices, and agents) - as foundational, while clarifying that the goal is inte= roperability and composition with existing identity systems (e.g., O= IDC, PKI, workload identity), rather than defining new identity mechanisms.<= /p>

Finally, clarifying that posture and context signals (e.g., device or wor= kload state) are in scope at the protocol interaction level= , even if endpoint technologies themselves are not, would help ensure that d= ynamic trust (primarily carried via Seam 4.2 and enforced via Seam 4.3) can b= e consistently applied across implementations.

Overall, the seam-based= decomposition is a strong and practical foundation. Emphasising how these e= lements combine to enable service-level least privilege with verifia= ble runtime enforcement (Seam 4.3) would further strengthen alignme= nt with Zero Trust principles such as those described in NIST SP 800-207.Regards

Philip

On Thu, 23 Apr 2026 at 0= 8:02, Aijun Wang <wangaijun@= tsinghua.org.cn> wrote:

Hi, Ph= ilip and Chris:

 

Let=E2=80=99s confine o= ur discussions within the ztcpp@ietf.org

C= urrently, we would like to hear your opinions on the proposed charter: https://github.com/ietf-ztcpp/Charter/blob/main/Charter.md

 =

You can comments on the github directly for t= he detail description, or give the suggested text on the mail list.

 

Once we consensus on the Charter, we can discus= s more on the specific proposals in detail.

 

= The proposed charter should confine within our initial aim, and shoul= d also consider carefully the possible deliverables.

 

Aijun

 

From: forwardingalgorithm@ietf.org [mailto:forwardingalgorithm@ietf.org] On Behalf Of Philip Griffiths
Sent: Thursday, April 23, 2026 3= :22 AM
To: Chris Hood <chris@nomotic.ai>
Cc: sixuan23@foxmail.com; agent2agent@ietf.org; ztcpp@ietf.org; wangaijun@tsinghua.org.c= n
Subject: [Ztcpp] Re: [agent2agent] Re: =E8=BD=AC=E5=8F=91=EF=BC=9AFW: New Non-= WG Mailing List: ztcpp (Zero Trust Control and Policy Protocol)

 =

Hey Chris,<= u>

 

For sure, these are the slides we pull together in the CSA, whi= ch I presented, which Aijun and team used for protocol gap analysis of ZTCPP= - ht= tps://github.com/ietf-ztcpp/125meeting/blob/main/0.4--IETF%20-%20ZTCPP%20pre= sentation(Philips-Netfoundry).pdf.

 

I have also attached the= markdown I wrote before creating the slides.

=

 =

Regards=

Philip=  

 

<= span lang=3D"EN-US">On Wed, 22 Apr 2026 at 20:00, Chris Hood <chris@nomotic.ai> wrote:

Phil= ip,

 

Appreciate the thoughtful engagement. Your 4.2 and 4.3 refi= nements are genuinely clarifying.

 

One small reframe. AGTP is de= signed as a governance + transport layer rather than application-layer seman= tics. The intent is for agent-centric frameworks including MCP, A2A, ACP, an= d governance platforms such as Nomotic to function on top of AGTP rather tha= n alongside it, each gaining protocol-level identity, authority, and attribu= tion natively rather than retrofitting them. It seems that ZTCPP's coordinat= ion work sits naturally alongside those layers, ensuring coherent enforcemen= t across heterogeneous deployments. The composition is cleaner than a head-t= o-head comparison might suggest.

 

On 4.1, your reframing is the a= ccurate position. Both models will exist. AGTP's defaults target the open-ag= ent-web deployment profile while providing the primitives that enterprise-or= iented governance can build on.

 

<= p class=3D"MsoNormal">I'll follow up separately with th= e crosswalk I mentioned, mapping AGTP's binding-layer constructs (Authority-= Scope, Governance Tokens, Delegation-Chain, 451/551, Attribution-Record, NOT= IFY revocation) against the Seam 4.2 and 4.3 definitions.

Please sha= re with me the current ZTCPP seam documentation when you have a moment.


Regards,

=

Chris Hood<= /p>

Nomotic, Inc.

<= a href=3D"mailto:chris@nomotic.ai" target=3D"_blank">chris@nomotic.ai=

 

On Wed, Apr 22, 2026 at 8:09 AM Philip Grif= fiths <philipleonardgriffiths@gmail.com> wrote:

=

Hey Chris,

Thisis really helpful - appreciate you shar= ing the detail on AGTP. It was the first I heard about it so did some quick l= earning (thus please forgive if I make any misinterpretations). My hot take i= s there is alignment, but AGTP is not the same as what we are trying to achi= eve with ZTCPP, so there alignment and potential collaboration points. Much a= lignment comes around carrying identity, context, and scoped authority on ev= ery interaction.

wrt Seams 4.2 and 4.3, I agree there is strong overl= ap. AGTP=E2=80=99s use of Agent-ID, Principal-ID, delegation chains, and Aut= hority-Scope is very much in line with what we=E2=80=99ve been describing as= binding identity and policy intent to interactions. The Authority-Scope mod= el in particular feels like a concrete example of binding-layer semantics. O= ne nuance I=E2=80=99d highlight (and where I think ZTCPP can complement work= like AGTP) is the distinction between:

  • carrying semantics per re= quest, and
  • ensuring those semantics are interpreted, enforced, and verified consis= tently across different systems and enforcement points.=

=46rom the seam perspective:=

  • Se= am 4.2 is less about in-band propagation of identity/context (which AGTP han= dles well), and more about policy lifecycle and coordination across enforcem= ent points - e.g., update, revocation, reauth, convergence, and cross-domain= consistency.
  • Seam 4.3 is where we=E2=80=99ve been focusing on ensuring that whate= ver semantics are defined (e.g., Authority-Scope) can be reliably bound to r= untime behaviour - not just per request, but across interactions - with cons= istent enforcement and auditable outcomes.

= In other words, from my quick understanding, AGTP makes= the binding layer explicit at the application level, whereas ZTCPP is tryin= g to ensure that those semantics can be interoperably realised across implem= entations and trust domains, including how they map to enforcement in underl= ying systems.

On Seam 4.1, I think this is a really useful point of d= iscussion. I completely agree that AGTP aligns with the open web model where= reachability precedes authorisation, and governance controls what is expose= d. =46rom a Zero Trust perspective, the question we=E2=80=99ve been explorin= g is whether that model continues to hold in environments where:

  • = agents are highly dynamic
  • <= span lang=3D"EN-US">interactions are machine-speed
    • =
  • and exposure itself becomes a r= isk surface

So I=E2=80= =99d frame this less as a disagreement and more as a design choice with diff= erent assumptions:

  • AGTP preserves reachability-first interaction (= web model)
  • ZTCPP also considers architectures where reachability itself is mediate= d by identity and policy (which is a big request from large, enterprise orga= nisations)

I suspect both models will exist, but being explicit about the trade= -offs feels important. More broadly, I see a strong opportunity for collabor= ation here. AGTP can be seen as defining the application-layer semantics for= agent interaction (identity, intent, authority), while ZTCPP is focused on h= ow those semantics are:

  • distributed and updated across systems (4.2= )
  • and e= nforced with consistent, verifiable outcomes (4.3)
    • =

Agentic systems feel like a= natural driver for this work, but the same issues apply across users, servi= ces, and workloads more broadly.

Also completely agree on the vocabul= ary point - =E2=80=9CAuthority-Scope,=E2=80=9D =E2=80=9Cbinding layer,=E2=80= =9D =E2=80=9Ctool authorisation,=E2=80=9D etc., are all converging on the sa= me underlying need: consistent, enforceable semantics at the point of intera= ction

Happy to take this offline - comparing AGTP=E2=80=99s binding-l= ayer semantics against the Seam 4.3 definition would be very useful, especia= lly to understand where we can converge vs where differences are intentional= .

Best,
Philip

 

On Wed, 22 Apr 2026 at 15:10, Chris Ho= od <chris@nomotic.a= i> wrote:

Philip, Xuan, others -

 

Appreciate the framing for= your charter. Much of this maps closely to Agent Transfer Protocol, AGTP (d= raft-hood-independent-agtp). I wanted to share some context for your conside= ration as it relates specifically to agents and zero-trust. A few points of a= lignment and one considered disagreement.

 

=

On Seams 4.2 and 4.3:= AGTP carries identity, context, and authorization on every request through A= gent-ID, Principal-ID, and Authority-Scope headers, with a three-level verif= ication model (self-asserted, application-layer, transport-layer) covering d= ifferent deployment profiles. The Authority-Scope vocabulary is AGTP's bindi= ng-layer common semantics, tokens like `documents:query`, `booking:*`, `paym= ents:confirm` enforced on every request. The AGTP-CERT extension binds scope= cryptographically for O(1) per-request enforcement at infrastructure layers= . Delegation chains are strict-subset-constrained and recorded per hop. 451 S= cope Violation and 551 Authority Chain Broken are first-class status codes.<= u>

 

On Seam 4.1: respectful disagreement. Agents should be reachabl= e and discoverable prior to authorization, the same way websites are, with t= he governance platform controlling what's exposed and organizations able to h= ide agents when they choose to. AGTP's ANS gates discovery queries with Auth= ority-Scope, but reachability itself is not the gatekeeper. Pre-authorizatio= n reachability is how the open web works and I think it's the right default f= or the open agent web too.

 

In the broader context, AGTP was des= igned as a governance + application layer, with the goal of moving agent tra= ffic off HTTP so it's easier to observe, authenticate, and govern at the pro= tocol level. One place AGTP differs from the autonomy-constraints framing is= that AGTP doesn't define autonomy directly, because the systems aren't auto= nomous in the strong sense, they act on behalf of principals within scope gr= ants. Authority-Scope and archetypes (assistant, analyst, executor, orchestr= ator, monitor) bound the action space.

 

Where I find a genuine o= pportunity is in the vocabulary. AGTP uses "Authority-Scope," "governance zo= ne," "trust tier." CSA uses "seam," "binding layer," and "verifiable enforce= ment." ONUG uses "autonomy constraints," and "tool authorisation." Different= traditions, largely overlapping concerns. Happy to take this offline to com= pare AGTP's binding-layer semantics against the Seam 4.3 definition if that'= s useful.

 

Chris Hood

Nomotic, Inc.

<= /div>

 =

&nb= sp;

On Wed, Apr 22, 2026 at 4:57 AM Philip Griffiths <philipleonardgriffiths@g= mail.com> wrote:

Hey all,

 

Thanks Xuan. I have some feedback on t= he charter, should I just reply in this thread?? <= /p>

I also agree=  AI Agent communication should be done under the guise of zero trust pr= inciples. Mapping to the protocol gap work we created in the CSA, which I re= motely presented, as well as the talk I gave earlier this month at the DoW Z= ero Trust Symposium on AI in collab with the CSA, wrt agentic systems, the t= raditional =E2=80=9Cnever trust, always verify=E2=80=9D model needs to exten= d beyond identity verification (particularly for non-human identities such a= s agents, services, and workloads) into how decisions are bound to r= untime interactions.

In particular, agent-to-agent communication highlights three distinc= t but interdependent concerns:

    Eliminating ambient reachabilit= y (Seam 4.1) - agents should not be dis= coverable or reachable prior to authorisation
  • Distributing and updating dynamic= trust decisions (Seam 4.2) - including= identity, context, and authorisation policies across systems<= /span>
  • Binding policy in= tent to concrete interactions (Seam 4.3)&nbs= p;- ensuring that each agent-to-agent exchange is constrained to least-privi= lege semantics and can be verified at runtime
=

The last point becomes especially important in agent= ic environments. Agents are not just establishing connections - they are exe= cuting multi-step workflows, invoking tools, and passing context across doma= ins. It is not sufficient to authenticate the agent; we must ensure that eac= h interaction is explicitly authorised, scoped, and enforced at the session o= r operation level.

&nb= sp;

Without common sem= antics for this binding layer (Seam 4.3), we risk systems where identity is v= erified, and policy is distributed, but interactions remain over-broad or di= fficult to audit.

This maps v= ery closely to some work thats taking place in ONUG on 'AOMC' (AI Age= nt Operations and Management Control framework), where Z= ero Trust begins to intersect with agent governance. Controls such as= identity attestation, tool authorisation, and autonomy constraints require t= hat policy is not only distributed (Seam 4.2), but consistently enforced a= t the point of action (Seam 4.3).

This suggests that agentic communication may be a strong driver for Z= TCPP work around:

  • standardising how identity (incl. non-human) an= d service intent are bound to interactions
  • defining verifiable enforcement semanti= cs for agent-to-agent exchanges
  • ensuring interoperability across different agent f= rameworks and trust domains

Happy to share more detail or examples if use= ful - this feels like a natural extension of the current seam-based work.=

 

Regards

Philip

=

 

<= /div>

On Wed, 22 Apr 20= 26 at 11:42, Xuan Si <sixuan23@foxmail.com> wrote:

Hi All,=

 

I=E2=80=99m forwarding the announcement that the <= a href=3D"mailto:ztcpp@ietf.org" target=3D"_blank">ztcpp@ietf.org (Zero&= nbsp;Trust Control and Policy Protocol) mailin= g list has been established:

https://mai= lman3.ietf.org/mailman3/lists/ztcpp.ietf.org/

This m= ail list will serve as a platform for us to exchange ideas, discuss tec= hnical issues and promote related research collaboration in the field of AI A= gent and network security.

 

Our curre= nt Charter is available here:

<= u> 

One of our core research areas is reviewing AI Agent c= ommunication security under zero-trust principles. As agent-to-agent int= eraction grows, zero-trust models including =E2=80=9Cnever trust, always ver= ify=E2=80=9D are critical to building secure and trusted communication envir= onments.

 

We welcome every= one to submit proposals and share views on AI Agent security and zero-trust a= pplications.

 

<= div>

We als= o plan to hold a BoF or side meetings at IETF 126 for in-depth f= ace-to-face discussions.

Please feel free to commen= t on the current Charter =E2=80=94 your feedback will help us refine scope a= nd direction.

 

=

Looki= ng forward to your active participation.

=

&nb= sp;

Best regards,

Xuan Si

 

=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6=

 

<= tr>

=E5=8F=91=E4=BB=B6= =E4=BA=BA=EF=BC=9AAijun Wang <wangaijun@tsinghua.org.cn>

=E5=8F=91=E4=BB=B6=E6=97=B6=E9= =97=B4=EF=BC=9A2026=E5=B9=B44=E6=9C=8820=E6=97=A5 18:31=

=E6=94=B6=E4=BB=B6= =E4=BA=BA=EF=BC=9Asaag <saag@ietf.org>

=E6=8A=84=E9=80=81=EF=BC=9Aztcpp <ztcpp@ietf.org>=

=E4=B8=BB=E9=A2=98=EF=BC=9A[Ztcpp] FW: Ne= w Non-WG Mailing List: ztcpp (Zero Trust Control and Policy Protocol)=

=

<= u> 

Hi, All SAAG experts:

<= p class=3D"MsoNormal"> 

If you are&nb= sp;interested this direction, please subscribe the&= nbsp;mail list(https://mailman3.ietf.org/mailman3/lists/ztcp= p.ietf.org/) and propose your related drafts.

 

We also welcome you to review the&= nbsp;ZTCPP charter (https://github.com/ietf-ztcpp/Cha= rter/blob/main/Charter.md) and give your suggestions=  within the ztcpp@ietf.org mail list.

 

The materials&n= bsp;for the past IETF 125 ZTCPP side meet= ing can be accessed at https://github.com/ietf-ztcpp/125= meeting (include problem statements, gap analys= is, and brief of introduction of CSA alli= ance).

 

We are planning the IETF 126 = ;BoF(or side meeting), welcome you all interes= ted to join us together!

<= div>

 <= /p>

Aijun

&n= bsp;

 

 

= -----Original Message-----

From: forwardingalgorithm@= ietf.org [mailto:forwardingalgorithm@ietf.org] On Behalf O= f IETF Secretariat

Sent: Saturday, April 18,&nbs= p;2026 1:13 AM

To: IETF Announcement List &= lt;ietf-announce= @ietf.org>

<= p class=3D"MsoNormal">Subject: New Non-WG&nbs= p;Mailing List: ztcpp (Zero Trust Control and&= nbsp;Policy Protocol)

 

A new IETF non-workin= g group email list has been created.=

 

List address: ztcpp@ietf.org

=

 

<= /div>

Purpose: This&nbs= p;email list focuses on exploring the practice=  and development of zero-trust strategies in&n= bsp;modern multi-cloud and network environments, wi= th a focus on zero trust's core principle= s, key elements, and specific application scen= arios, control and policy protocol etc. 

 

The goal is to jointly advance underst= anding and practice of zero trust in clou= d and networks, pool industry insights, explor= e better security strategies, and develop rela= ted communication standards.

 

This list belo= ngs to IETF area: SEC

 

=

For additional&n= bsp;information, please contact the list administra= tors.

 

_______________________________________________<= /u>

IETF-An= nounce mailing list -- ietf-announce@ietf.org To unsubscri= be send an email to ietf-announce-leave@ietf.org

 

_______________________________________________

Ztcpp mailing&n= bsp;list -- zt= cpp@ietf.org

<= span lang=3D"EN-US">To unsubscribe send an email to=  ztcpp-leave@= ietf.org

 

_______________________________________________=

Ztcpp mailing list -- z= tcpp@ietf.org

= To unsubscribe send an email to ztcpp-leave@ietf.org

 

<= /div>
_____________________= __________________________
Ztcpp mailing list -- zt= cpp@ietf.org
To unsubscribe send an email to ztcpp-leave@ietf.org
= --Apple-Mail-99E79ED9-C049-41C1-8EFC-8184F5C915D6--