From: John Mattsson <john.mattsson@ericsson.com>
To: Wang Guilin <Wang.Guilin=40huawei.com@dmarc.ietf.org>, Ben S3
	<ben.s3=40ncsc.gov.uk@dmarc.ietf.org>, Michael Richardson
	<mcr+ietf@sandelman.ca>, Thom Wiggers <thom@thomwiggers.nl>, "ipsec@ietf.org"
	<ipsec@ietf.org>
Thread-Topic: [IPsec] Re: Call for adoption:
 draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 (Ends 2026-02-09)
Thread-Index: AQHcjB7WahH4wu4tPEiWm/eUuNg7L7VfZ6AAgAAQ4QCAAAwPIA==
Date: Fri, 23 Jan 2026 10:03:20 +0000
Message-ID: 
 <AS5PR07MB10596B07938131FB9C63EED078994A@AS5PR07MB10596.eurprd07.prod.outlook.com>
References: 
 <176824138819.764059.17372501962377307239@dt-datatracker-5656579b89-r5kdq>
 <064BDB29-C00E-43D1-ACD2-542ACFF0311F@thomwiggers.nl>
 <20460.1769116002@obiwan.sandelman.ca>
 <CWLP123MB34104BE8D2E872E42DD32A348094A@CWLP123MB3410.GBRP123.PROD.OUTLOOK.COM>
 <19ca7ee7354e4135b655cd7a6cae864d@huawei.com>
In-Reply-To: <19ca7ee7354e4135b655cd7a6cae864d@huawei.com>
Accept-Language: en-US
Content-Language: en-GB
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?Windows-1252?Q?uKravipvCelUxuUoGXWJptf8jKA1JbFqocgxCo/G5X+FjH3ek2e7+Bi8?=
 =?Windows-1252?Q?0lymM/zqz/gP1U4kcsyp1aLrwz6tQaZcsP9LJ5QB2e8ILs6lqEA1HczX?=
 =?Windows-1252?Q?+6jkzHr1eK6R+twBlZ5Nz4Nz/Tn7Sjq8N8kCDhX6E6j5beEeF6VV6JiB?=
 =?Windows-1252?Q?Ut5lt1k8vlY8EP9YdHOHQ+2T1XClm++RuiAV578Ripe5LEow2VPITRyz?=
 =?Windows-1252?Q?UOmks07QVtlinSyDISsdqh9fIBrZbqNOESzPaw3ez8bUjJeQSKG0lThO?=
 =?Windows-1252?Q?1smzfCP96JU5YCNmFFojwRMT0Dc0I+NU0mnkEC0pZb8E4SClWfUPeDpE?=
 =?Windows-1252?Q?75wO3nwHX74GRCFXzWNnWjGo99Zewt9hUUKorDabsmISQrStR5KtmkxJ?=
 =?Windows-1252?Q?Jg6vbHpiKP0TnHx6X0eOTl3HHcrbhoj/E3OyANB6ljBoSpZj5N+JW7Jh?=
 =?Windows-1252?Q?bu/4DvV6IIDPxr7lLQcfO7eKhMtSf6ZBiHVsQc7vrKOcSsmhPBxnlgTE?=
 =?Windows-1252?Q?0V3d7txX9fuHyXhGLHBoD7Xtcbt5m4dFnvEiVE1bCBcUKMEZ9gmXN9m+?=
 =?Windows-1252?Q?n3exHkuKvdakj9qnTAR6Ba8y5c40y62155ONj8xXKyP6x1lmhQv4AuVf?=
 =?Windows-1252?Q?RSaqwQqENaOAWW+yXCGIH5qUeTg0Z5C4JCVOW5d0HHXBgkxP1aSgdlGz?=
 =?Windows-1252?Q?YAJYCdC9OYwfPfBrvqnzrT++KDs5ds79X+cyF9/KsGxcb/su6l/b49V+?=
 =?Windows-1252?Q?s4UPne7DnVwrhklRgXNJ8CoaLnj6f+Iv6W8WaagEKU4VkX1ftUtkc80V?=
 =?Windows-1252?Q?H17YhGEyVLBUTNTqA9HtlJ9smHCoAn2iPq4HlsywOAo/L69KypOY5x3K?=
 =?Windows-1252?Q?9R6hdL0ySzEVl8CP7hRyIU3PieIH41c9Fxe1NKFt1MJzXw+7W2hAfLNm?=
 =?Windows-1252?Q?G08foZJ0/q0n2v3XMG45OcZyVnXLdeqeTd+a9BOrb5mhJY1Ko4FNk6qi?=
 =?Windows-1252?Q?LI6zWYGdgxLq0W8OhJ0TfFZG8uknxF3h1y4pXtQgB13wGcD61xVBL1cy?=
 =?Windows-1252?Q?W67TCt7OkypSHzs83OvtWfrZ0Iqzm8fH4P4nVRZHY6nK1ta98M/dQJvE?=
 =?Windows-1252?Q?LaZ/lZccj6P+6wIbaiUB9nE6nvlMQK6NUgbO91bRXNxbZ/NriT0fGDtg?=
 =?Windows-1252?Q?vUNQojF5SZa6Xd2IZfQWpLwwu0m83tyG8IU9pMpYcfFz2jx7ffTsBVQ/?=
 =?Windows-1252?Q?5Cm+4BFgkPOZPOqIuqGqn1VImv8XfVx84+4ZUmjBN4AemAr4msPGL9E3?=
 =?Windows-1252?Q?s5Otmw5zRBugb6ds8b6FdM+Swq2EATnC3sy4wo8evWMpd6R43DisqeBg?=
 =?Windows-1252?Q?8wAtGK7ukRAtBF/MerxpvWmd2WWh8g5xcoxHSFh5Ui6je0zGrqdZj1iM?=
 =?Windows-1252?Q?2wazcpA1JSYniLCvDqBLg7zVVCIHIC3OR67Wg/kRjUOGVVBO41ewY27e?=
 =?Windows-1252?Q?qxcvg5hVuE2UfpwFOkT2+yJL3IRd7xY4x8B5JutDqg6oi0khJEiL/DJ3?=
 =?Windows-1252?Q?zjk+J/uRA49jbXC2g75cWegrh4uDYonec2JlmwccNsu8zR1amTKPpNtU?=
 =?Windows-1252?Q?PA7fxqloyRJutG5LlS9TAoWxHEURgF0AA7a/gadL65sOR20KFOX0qGYg?=
 =?Windows-1252?Q?7bGPG0X2ZvMIQWxhSn8oE57pjx10FW4OxGWcDU5i2QPbx1DIs0YzFoLg?=
 =?Windows-1252?Q?DaxJEK7BX6fo7fwidVzcB4QDMzif2su+SC+5XLTRyvwb04tsGQbn3ZIb?=
 =?Windows-1252?Q?dcNbhUT720nGLoQmLB/5ekHS2ZCBcsfi8jSYaN5gbYS1VHKDZGrf5TkC?=
 =?Windows-1252?Q?QYGRKTUhMhOpxkXgkTZ1XaYIh/yST+wqItI=3D?=
Content-Type: multipart/alternative;
	boundary="_000_AS5PR07MB10596B07938131FB9C63EED078994AAS5PR07MB10596eu_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS5PR07MB10596.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 38af9dbd-f224-4209-fcfc-08de5a66a30a
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2026 10:03:20.1281
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 
 C/PStdhRY8kcrUw6a7ZrelkYtxZXE5U64y9Y3OHFGIfNdHsO5k17YLc++yjbt8walu0wGgWVZqqFYSkWm5wMRR8H752oz3Qi8w+auJGLGNQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA1PR07MB10212
Message-ID-Hash: W57EQGRJDZSVD4JADMSGEIAP35YR6JMT
X-Message-ID-Hash: W57EQGRJDZSVD4JADMSGEIAP35YR6JMT
X-MailFrom: john.mattsson@ericsson.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-ipsec.ietf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
CC: Wang Guilin <Wang.Guilin@huawei.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5BIPsec=5D_Re=3A_Call_for_adoption=3A_draft-wang-ipsecme-hybrid-k?=
 =?utf-8?q?em-ikev2-frodo-03_=28Ends_2026-02-09=29?=
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ipsec/O0ZD01Bm6O1Y8aJJ9-KnfDMgbGw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Owner: <mailto:ipsec-owner@ietf.org>
List-Post: <mailto:ipsec@ietf.org>
List-Subscribe: <mailto:ipsec-join@ietf.org>
List-Unsubscribe: <mailto:ipsec-leave@ietf.org>

--_000_AS5PR07MB10596B07938131FB9C63EED078994AAS5PR07MB10596eu_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

>- Still, the main part for our draft is about how to use FrodoKEM in hybri=
d way (traditional KE+FrodoKEM), though more PQ KEMs can be added by follow=
ing RFC 9370.

I disagree with this, I think the main part of IPSECME=92s draft should be =
to register code points for FrodoKEM without restricting how implementation=
s are using FrodoKEM.

John

From: Wang Guilin <Wang.Guilin=3D40huawei.com@dmarc.ietf.org>
Date: Friday, 23 January 2026 at 10:12
To: Ben S3 <ben.s3=3D40ncsc.gov.uk@dmarc.ietf.org>, Michael Richardson <mcr=
+ietf@sandelman.ca>, Thom Wiggers <thom@thomwiggers.nl>, ipsec@ietf.org <ip=
sec@ietf.org>
Cc: Wang Guilin <Wang.Guilin@huawei.com>
Subject: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2=
-frodo-03 (Ends 2026-02-09)

Yes, this true. Also considering what a better name for our draft draft-wan=
g-ipsecme-hybrid-kem-ikev2-frodo. And this may also indicate similar issue =
for draft-ietf-ipsecme-ikev2-mlkem.

For draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03:
- Current title: "Post-quantum Hybrid Key Exchange in IKEv2 with FrodoKEM"
- Michael Richardson: "Using FrodoKEM in Multiple IKEv2 Key Exchanges"
- Thom Wiggers: =93FrodoKEM for IKE_INTERMEDIATE IKEv2 Key Exchanges
- Scott Fluhrer: No exact name suggested, but commented: "I would recommend=
 that this draft should back off from assuming that Frodo can be used only =
in the "Classical+Frodo" combination."

For me, I like the current one or that from Michael. A few reasons:
- Still, the main part for our draft is about how to use FrodoKEM in hybrid=
 way (traditional KE+FrodoKEM), though more PQ KEMs can be added by followi=
ng RFC 9370.
- The draft can describe how to run pure FrodoKEM over TLS, as Scott sugges=
ted. But this is a smaller case in the draft.
- For my understanding, hybrid is more general than just T/PQ. It refers tw=
o or more crypto component algorithms are combined to achieve a security pu=
rpose. (Also, how to combine the component algorithms and how strong the re=
sulting solution are further issues.)
- RFC 9794 seems not giving definition for "hybrid", but mentions that it c=
an be used for T/PQ (like hybrid KE  defined by ETSI) or a more general con=
cept (like hybrid KE defined by NIST). Details can be found in Section 1 of=
 RFC 9794.

draft-ietf-ipsecme-ikev2-mlkem:
- Current title: "Post-quantum Hybrid Key Exchange with ML-KEM in the Inter=
net Key Exchange Protocol Version 2 (IKEv2)"
This WG document does specify how to use pure ML-KEM in IKEv2. Abstract tel=
ls "This draft specifies how to use ML-KEM by itself or as an additional ke=
y  exchange in IKEv2 along with a traditional key exchange."

Guilin
-----Original Message-----
From: Ben S3 <ben.s3=3D40ncsc.gov.uk@dmarc.ietf.org>
Sent: Friday, 23 January 2026 4:12 pm
To: Michael Richardson <mcr+ietf@sandelman.ca>; Thom Wiggers <thom@thomwigg=
ers.nl>; ipsec@ietf.org
Subject: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2=
-frodo-03 (Ends 2026-02-09)

OFFICIAL

Without stating an opinion either way, I=92ll note that the title of this d=
raft is consistent with the title of draft-ietf-ipsecme-ikev2-mlkem, which =
also assumes hybrid.

Of course, the solution here might be =93change the name of the ML-KEM draf=
t too=94.

Ben


OFFICIAL
-----Original Message-----
From: Michael Richardson <mcr+ietf@sandelman.ca>
Sent: 22 January 2026 21:07
To: Thom Wiggers <thom@thomwiggers.nl>; ipsec@ietf.org
Subject: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2=
-frodo-03 (Ends 2026-02-09)


Thom Wiggers <thom@thomwiggers.nl> wrote:
    > Title:
    > I do strongly feel that =93hybrid=94 should be removed from the title=
 of
    > the draft, because I think it will lead to confusion on what this dra=
ft
    > achieves in terms of security. Namely, =93hybrid=94 commonly means PQ=
/T
    > hybrids, but this draft can be used perfectly fine with ML-KEM-512 in
    > the IKE_SA_INIT key exchange. While I do agree that this would still
    > give us a (PQ/PQ) =93hybrid=94, I don=92t think that this matches
    > expectations surrounding the word =93hybrid=94.

I agree strongly.
RFC9370 defines multiple key exchanges, so linking it in that way makes mor=
e sense.

    > I don=92t think =93hybrid=94 adds much either, other than (to experts=
)
    > hinting that this needs to be done in IKE_INTERMEDIATE exchanges. So =
if
    > that is the intended message, I suggest renaming the draft to somethi=
ng
    > like =93FrodoKEM for IKE_INTERMEDIATE IKEv2 Key Exchanges=94.

Or, maybe "Using FrodoKEM in Multiple IKEv2 Key Exchanges"


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=F8T consulting =
)
           Sandelman Software Works Inc, Ottawa and Worldwide




_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-leave@ietf.org
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-leave@ietf.org

--_000_AS5PR07MB10596B07938131FB9C63EED078994AAS5PR07MB10596eu_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body>
<div style=3D"direction: ltr; font-family: Aptos; font-size: 14.666667px; c=
olor: rgb(33, 33, 33);">
<span style=3D"text-transform: none;">&gt;- Still, the main part for our dr=
aft is about how to use FrodoKEM&nbsp;in hybrid way (traditional KE+FrodoKE=
M), though more PQ KEMs can be added by following RFC 9370.&nbsp;</span></d=
iv>
<div style=3D"direction: ltr; font-family: Aptos; font-size: 14.666667px; c=
olor: rgb(33, 33, 33);">
<br>
</div>
<div style=3D"direction: ltr; font-family: Aptos; font-size: 14.666667px; c=
olor: rgb(33, 33, 33);">
I disagree with this, I think the main part of IPSECME=92s draft should be =
to register code points for FrodoKEM without restricting how implementation=
s are using FrodoKEM.</div>
<div style=3D"direction: ltr;"><br>
</div>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se=
rif; font-size: 12pt; color: rgb(0, 0, 0);">
John</div>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se=
rif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id=3D"mail-editor-reference-message-container">
<div class=3D"ms-outlook-mobile-reference-message skipProofing">
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"te=
xt-align: left; padding: 3pt 0in 0in; border-width: 1pt medium medium; bord=
er-style: solid none none; border-color: rgb(181, 196, 223) currentcolor cu=
rrentcolor; font-family: Aptos; font-size: 12pt; color: black;">
<b>From: </b>Wang Guilin &lt;Wang.Guilin=3D40huawei.com@dmarc.ietf.org&gt;<=
br>
<b>Date: </b>Friday, 23 January 2026 at 10:12<br>
<b>To: </b>Ben S3 &lt;ben.s3=3D40ncsc.gov.uk@dmarc.ietf.org&gt;, Michael Ri=
chardson &lt;mcr+ietf@sandelman.ca&gt;, Thom Wiggers &lt;thom@thomwiggers.n=
l&gt;, ipsec@ietf.org &lt;ipsec@ietf.org&gt;<br>
<b>Cc: </b>Wang Guilin &lt;Wang.Guilin@huawei.com&gt;<br>
<b>Subject: </b>[IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-ke=
m-ikev2-frodo-03 (Ends 2026-02-09)<br>
<br>
</div>
<div class=3D"PlainText" style=3D"font-size: 11pt;">Yes, this true. Also co=
nsidering what a better name for our draft draft-wang-ipsecme-hybrid-kem-ik=
ev2-frodo. And this may also indicate similar issue for draft-ietf-ipsecme-=
ikev2-mlkem.<br>
<br>
For draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03:<br>
- Current title: &quot;Post-quantum Hybrid Key Exchange in IKEv2 with Frodo=
KEM&quot;<br>
- Michael Richardson: &quot;Using FrodoKEM in Multiple IKEv2 Key Exchanges&=
quot;<br>
- Thom Wiggers: =93FrodoKEM for IKE_INTERMEDIATE IKEv2 Key Exchanges<br>
- Scott Fluhrer: No exact name suggested, but commented: &quot;I would reco=
mmend that this draft should back off from assuming that Frodo can be used =
only in the &quot;Classical+Frodo&quot; combination.&quot;<br>
<br>
For me, I like the current one or that from Michael. A few reasons:<br>
- Still, the main part for our draft is about how to use FrodoKEM in hybrid=
 way (traditional KE+FrodoKEM), though more PQ KEMs can be added by followi=
ng RFC 9370.<br>
- The draft can describe how to run pure FrodoKEM over TLS, as Scott sugges=
ted. But this is a smaller case in the draft.<br>
- For my understanding, hybrid is more general than just T/PQ. It refers tw=
o or more crypto component algorithms are combined to achieve a security pu=
rpose. (Also, how to combine the component algorithms and how strong the re=
sulting solution are further issues.)<br>
- RFC 9794 seems not giving definition for &quot;hybrid&quot;, but mentions=
 that it can be used for T/PQ (like hybrid KE&nbsp; defined by ETSI) or a m=
ore general concept (like hybrid KE defined by NIST). Details can be found =
in Section 1 of RFC 9794.<br>
<br>
draft-ietf-ipsecme-ikev2-mlkem:<br>
- Current title: &quot;Post-quantum Hybrid Key Exchange with ML-KEM in the =
Internet Key Exchange Protocol Version 2 (IKEv2)&quot;&nbsp;<br>
This WG document does specify how to use pure ML-KEM in IKEv2. Abstract tel=
ls &quot;This draft specifies how to use ML-KEM by itself or as an addition=
al key&nbsp; exchange in IKEv2 along with a traditional key exchange.&quot;=
&nbsp;<br>
<br>
Guilin<br>
-----Original Message-----<br>
From: Ben S3 &lt;ben.s3=3D40ncsc.gov.uk@dmarc.ietf.org&gt;<br>
Sent: Friday, 23 January 2026 4:12 pm<br>
To: Michael Richardson &lt;mcr+ietf@sandelman.ca&gt;; Thom Wiggers &lt;thom=
@thomwiggers.nl&gt;; ipsec@ietf.org<br>
Subject: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2=
-frodo-03 (Ends 2026-02-09)<br>
<br>
OFFICIAL<br>
<br>
Without stating an opinion either way, I=92ll note that the title of this d=
raft is consistent with the title of draft-ietf-ipsecme-ikev2-mlkem, which =
also assumes hybrid.<br>
<br>
Of course, the solution here might be =93change the name of the ML-KEM draf=
t too=94.<br>
<br>
Ben<br>
<br>
<br>
OFFICIAL<br>
-----Original Message-----<br>
From: Michael Richardson &lt;mcr+ietf@sandelman.ca&gt;<br>
Sent: 22 January 2026 21:07<br>
To: Thom Wiggers &lt;thom@thomwiggers.nl&gt;; ipsec@ietf.org<br>
Subject: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2=
-frodo-03 (Ends 2026-02-09)<br>
<br>
<br>
Thom Wiggers &lt;thom@thomwiggers.nl&gt; wrote:<br>
&nbsp;&nbsp;&nbsp; &gt; Title:<br>
&nbsp;&nbsp;&nbsp; &gt; I do strongly feel that =93hybrid=94 should be remo=
ved from the title of<br>
&nbsp;&nbsp;&nbsp; &gt; the draft, because I think it will lead to confusio=
n on what this draft<br>
&nbsp;&nbsp;&nbsp; &gt; achieves in terms of security. Namely, =93hybrid=94=
 commonly means PQ/T<br>
&nbsp;&nbsp;&nbsp; &gt; hybrids, but this draft can be used perfectly fine =
with ML-KEM-512 in<br>
&nbsp;&nbsp;&nbsp; &gt; the IKE_SA_INIT key exchange. While I do agree that=
 this would still<br>
&nbsp;&nbsp;&nbsp; &gt; give us a (PQ/PQ) =93hybrid=94, I don=92t think tha=
t this matches<br>
&nbsp;&nbsp;&nbsp; &gt; expectations surrounding the word =93hybrid=94.<br>
<br>
I agree strongly.<br>
RFC9370 defines multiple key exchanges, so linking it in that way makes mor=
e sense.<br>
<br>
&nbsp;&nbsp;&nbsp; &gt; I don=92t think =93hybrid=94 adds much either, othe=
r than (to experts)<br>
&nbsp;&nbsp;&nbsp; &gt; hinting that this needs to be done in IKE_INTERMEDI=
ATE exchanges. So if<br>
&nbsp;&nbsp;&nbsp; &gt; that is the intended message, I suggest renaming th=
e draft to something<br>
&nbsp;&nbsp;&nbsp; &gt; like =93FrodoKEM for IKE_INTERMEDIATE IKEv2 Key Exc=
hanges=94.<br>
<br>
Or, maybe &quot;Using FrodoKEM in Multiple IKEv2 Key Exchanges&quot;<br>
<br>
<br>
--<br>
Michael Richardson &lt;mcr+IETF@sandelman.ca&gt;&nbsp;&nbsp; . o O ( IPv6 I=
=F8T consulting )<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sandelman Soft=
ware Works Inc, Ottawa and Worldwide<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
IPsec mailing list -- ipsec@ietf.org<br>
To unsubscribe send an email to ipsec-leave@ietf.org<br>
_______________________________________________<br>
IPsec mailing list -- ipsec@ietf.org<br>
To unsubscribe send an email to ipsec-leave@ietf.org<br>
</div>
</div>
</body>
</html>

--_000_AS5PR07MB10596B07938131FB9C63EED078994AAS5PR07MB10596eu_--