NS;
see RFC 7719 for definitions of DNS terms. I suggest that this paragraph be
changed to:
The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
passed to another (DNS) program for processing. Some DNS programs
only handle domain names in
define "character", you will also have a problem (some encodings of characters
take up multiple octets).
If you really want to go down this path, you must say something like "domain
names where each label consist only of octets which map to the ASCII encoding
of the following values: A to Z, a to z, 0 to 9, "-", and "_".
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
er (DNS) program for processing. As with any network input, the
> content should be considered untrusted and handled accordingly.
Yep, that works for me. With that and the other change you said was fine, I
think this is quite ready for IETF Las
I'm glad to see this document finally make it towards standardization.
Just a minor editorial note: capitalizing "Quantum Computers" is
incorrect and should be fixed before it goes to the RFC Editor.
--Paul Hoffman
___
IPsec mai
y Paterson, said so awhile back.
I don't think that's what he said in the slides you posted, but I've
Cc'd him so he can reply. The slides are about picking new post-quantum
algorithms; what is described in the draft is a method for mixing in
preshared secrets with curren
On 11 Dec 2019, at 11:11, Yoav Nir wrote:
Hi, Paul
On 11 Dec 2019, at 20:03, Paul Hoffman wrote:
On 11 Dec 2019, at 8:23, Salz, Rich wrote:
We are seeing a flurry of these kind of “post quantum
protection” things.
This is the only one I have seen that is a method, not a new key
We have heard very few comments on this thread, and yet it is an important one.
--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
This is the wrong mailing list to ask about specific pieces of software that
implement IPsec. Instead, you need to go to the mailing list for that specific
software. This mailing list is for discussing the development of the IPsec
protocol.
--Paul Hoffman, Director
--VPN Consortium
I am going to close these issues accepting Yoav's proposal from 2010-12-13.
Not only would it be nice, but it would be *really useful to the IPsec
community*, if there were more people in the WG who were reading our two
remaining documents and commenting on the open issues...
--Paul Ho
We propose have a virtual interim WG meeting near the end of this month
to discuss any remaining issues with the failure detection document. We
propose a conference call on Tuesday January 25, 16:00 GMT (21:30
Kolkata, 18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for up to 2
hours. We are pla
I am closing this open issue. Yaron: please use your proposed text.
Failure detection authors: please have a new draft ready by Monday and
close out all the resolved issues on the issue tracker. I think we are
getting ready for a WG Last Call.
--Paul Hoffman, Director
--VPN Consortium
conference call using a VoIP conference bridge and posted slides (if
needed). Technical details here:
http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls.
--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https
On 1/10/11 12:03 AM, Yoav Nir wrote:
Greetings.
We have just submitted version -03 of the draft. This closes issues, #198,
#199, #200, and #201.
Which leaves us with just one issue: #202
So far, there have been no posts on this thread. I encourage the
document authors to weigh in on the to
. Also note that our virtual interim meeting, which is
meant to focus on this document, happens the day before this WG LC
closes. If there continues to be little comment on the document or on
issue #202, that will be a very short meeting.
--Paul Hoffman, Director
--VPN Cons
On 1/19/11 2:10 PM, Keith Welter wrote:
This may be a naive answer, but I'm not opposed to the idea of
Individual Submission. I do have some comments/questions:
1. My draft depends on RFC 6023 and cites it as a normative reference.
Since I'd like to get my draft on the standards track, does that
n this document, happens the day before this WG LC
closes. If there continues to be little comment on the document or on
issue #202, that will be a very short meeting.
--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
This is just a reminder of tomorrow's meeting. Given the lack of traffic
on the mailing list for the WG LC, I suspect that this will be a *very*
short meeting.
==
The IPsecME WG will have a virtual interim WG meeting on Tuesda
As expected, it was short. If any of the participants have changes to
the minutes, let me know in the next two days.
--Paul Hoffman
IPsecME WG
Minutes of the Virtual Interim Meeting
2011-01-25 1600 GMT
Attendees:
David Wierbowski
Matt Lepinski
Paul Hoffman
and, assuming there is general agreement, the authors will put out a
final version with it in it and we can move the document to our Area
Director.
--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/ma
varies *greatly* depending on the type of instructions
and register use; this is even true withing sub-types of ARM processors.
You probably want to do your own study for your specific intended target
CPU and specific level of CPU optimization.
--Paul Hoffman, Director
--VPN Consortium
Verified
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Any other comments on this issue and the proposals for wording?
--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
the following text, which is a mixture of
the two proposals, with an extra paragraph break to show where the new
idea starts. Yaron and I will move this to the Area Director as soon as
we have a new draft. Thanks for all the work done so far!
--Paul Hoffman
9.2. QCD Token Transmission
A token
nent=ipsecha-protocol
+1 to "Please review the document". It would be a bummer to go into WG
LC and then have people find things that take major revision.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
rs.
OK, let's have an extra round before we go to IETF Last Call. If no one
disagrees with Dave's new wording before Tuesday, Feb 15, I will ask the
authors to put it in a new draft.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Greetings again. This is just confirming what Yaron and I had said
earlier, namely that the IPsecME WG will not meet in Prague. We will
hopefully be done with WG LC on the HA protocol document by then, and
therefore it is not worth the hassle of scheduling a meeting and so on.
--Paul Hoffman
On 2/10/11 7:56 PM, Paul Hoffman wrote:
On 2/8/11 12:15 PM, Yaron Sheffer wrote:
Hi,
this version attempts to address all the open issues that were raised in
the last few months. In particular, it clarifies the behavior of the IKE
Message ID during failover while reducing some of the
implementation. I'm hoping after a rev or two that Tero will publish
this as an RFC.
--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
I have already sent the new draft to our AD for consideration to bring
to IETF Last Call. Changes can certainly be made after IETF Last Call,
and this discussion seems worthwhile there.
--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing
ts gives you that option to implement multiple of
> them if you want. This draft only provides instructions for those
> other draft authors so they can at least common methods to negotiate
> the feature and use common method to trasmit data between peers.
True, but it is still punting the problem of us having just one.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
epending how you do it) in the ENONCE and PKEi/PKEr payloads.
>
> So in total the technical differences will be 7 extra bytes. Is there
> anything else?
Regardless of what the authors of this document do, that question is not
relevant to whether or not you, as the designated expert, giv
Tero to not allocate code points for SHA-3,
because it does the "same thing" as SHA-2. Let's not go there.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
On Aug 2, 2011, at 6:12 AM, Tero Kivinen wrote:
> Paul Hoffman writes:
>> You are *not* responsible for the IANA registries. RFC 5226 says:
>>
>> It should be noted that a key motivation for having designated
>> experts is for the IETF to provide IANA with a su
e probably is a
"better" way to do it, but at the cost of greater complexity. I vaguely
remember this being discussed in MOBIKE, but dismissed as too complicated for
the value. Others here might remember more.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
, proposed it as an informational submission.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
it. The use case for RFC 4322,
opportunistic encryption (and thus no trusted introducer), is quite different
than the one being proposed here.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
es.
Having said that, it would be great of the authors of the document could come
up with some terminology to differentiate "spoke trust hub to introduce to
other spokes directly" and "spoke trusts hub to introduce to other spokes,
possibly through indirection through ot
oint needs to be a bit more specific: "a method to identify the next
cryptographic hop towards a particular address range".
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
ssibility that SpokeA might like. So there are two types of policy:
tunnel (address), and crypto (authentication and eventual encryption).
At least, that was my picture of the requirements.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
ress-space-only environments, that's great:
I suspect that some people will gravitate towards it. But that's not the
problem that is being discussed here.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Of interest to the WG. Note that there is nothing to discuss, this is just a
message from the IESG to the ISE.
Begin forwarded message:
> From: The IESG
> Subject: Re: Informational RFC to be:
> Date: October 31, 2011 4:41:37 PM PDT
> To: RFC ISE
> Cc: i...@iana.org, The IESG , ietf-annou...@
Begin forwarded message:
> From: The IESG
> Subject: Document Action: 'Secure Password Framework for IKEv2' to
> Informational RFC (draft-kivinen-ipsecme-secure-password-framework-03.txt)
> Date: November 1, 2011 6:20:52 AM PDT
> To: IETF-Announce
> Cc: RFC Editor
>
> The IESG has approved th
ple here advocate for "discovery", what do they mean? Do you mean:
- hubs can receive information from the spokes about what addresses the spoke
gateways protect
- hubs can proactively go out and find spokes and then ask what addresses each
spoke gateway protects
-
additional information such as policies). I further propose that there is a
requirement for gateways to be able to send introducers map-making information
for themselves, but the process by which an introducer uses that information
(such as when two gateways claim the same protected addresses) is out of scope.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
ut the gateway.
> Or have I misunderstood the problem space?
You have one view, I have a different one, and the rest of the WG should be
chiming in about which they think are required for the problem of P2P VPN.
--Paul Hoffman
___
IPsec mailing list
IPs
On Nov 29, 2011, at 5:39 PM, Nico Williams wrote:
> On Tue, Nov 29, 2011 at 7:31 PM, Paul Hoffman wrote:
>> At this point, we are trying to state requirements. You have already ran
>> full-force into proposed solutions.
>
> Looking at the sorts of solutions that might be
hing it knows on a period basis to
reduce the route setup time.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
choose a common solution for the discovery and
> update problems that will satisfy the requirements in the problem statement
> document. The working group may consider multiple proposals, and then choose
> one to bring to the standard
roup may consider
> multiple proposals, and then choose one to bring to the standards track." by
> "The working group may standardize one of the vendor solutions, a combination
> of several, or a new protocol." The latter is c
On Dec 8, 2011, at 12:00 PM, Yoav Nir wrote:
>
> On Dec 8, 2011, at 6:04 PM, Paul Hoffman wrote:
>
>>
>> On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote:
>>
>>> In an environment with many IPsec gateways and remote clients that share an
>>>
Begin forwarded message:
> From: rfc-edi...@rfc-editor.org
> Subject: RFC 6467 on Secure Password Framework for Internet Key Exchange
> Version 2 (IKEv2)
> Date: December 19, 2011 8:53:55 AM PST
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> Cc: rfc-edi...@rfc-editor.org
>
>
> A new Re
s
strongly as you want. Such a document can be a BCP, which has the same effect
as a standard.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
off the chin-scratching about "what
does Historic really mean" and let us focus on what you actually want, which is
people not using AH.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
yone with drafts that deal with
modern IPsec usage, such as the documents in this thread. Are you saying that
such documents should not be discussed on this mailing list?
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman
xample where WESP (a protocol that was done in this WG) is not
100% reliable for parse-into or parse-past? If we need to change the protocol,
we should.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
On Jan 4, 2012, at 10:59 AM, RJ Atkinson wrote:
>
> On 04 Jan 2012, at 13:46 , Paul Hoffman wrote:
>
>> On Jan 4, 2012, at 10:37 AM, RJ Atkinson wrote:
>>> Neither WESP nor the other document provide a 100% reliable way
>>> to parse-into/parse-past/dee
Begin forwarded message:
> From: rfc-edi...@rfc-editor.org
> Subject: RFC 6479 on IPsec Anti-Replay Algorithm without Bit Shifting
> Date: January 18, 2012 5:04:49 PM PST
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> Cc: rfc-edi...@rfc-editor.org
>
>
> A new Request for Comments is now
draft submitted *and* interesting questions that would
benefit from face-to-face discussion instead of just work on the list. Do
people believe we will have that?
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo
On Jan 20, 2012, at 12:59 AM, Yoav Nir wrote:
> On Jan 20, 2012, at 12:43 AM, Paul Hoffman wrote:
>
>> We have a new charter. Do we have any volunteers to start work on the two
>> documents we committed to work on?
>
> I think it's premature to start work on the
-chartered work. In my mind,
that means both a first draft submitted *and* interesting questions that would
benefit from face-to-face discussion instead of just work on the list. Do
people believe we will have that?
--Paul Hoffman
___
IPsec mailing list
tement and contribute ideas such as "this should be a requirement" and "that
thing there should not be a requirement"?
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
someone
publishes a new authentication mechanism for IKEv1 that has significant flaws
(and they certainly will), they publish a new document and it gets a new
identifier. This will damp out fairly quickly, and auth mechanism developers
will get more i
cussion, we could have an open design team meeting
related to this in a week or so.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
solution is that if the responder narrows the tunnel, the IPsec stack tells the
application "you never got a tunnel".
IKEv2 was designed around the idea of gateways being the ones that control the
tunnel properties, thus avoiding the API issues to applications.
--Paul Hoffman
"lower" criteria.
I still find this to be too heavy-weight for my tastes, but I may be the only
one who thinks so.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
i.e. it shares the same format for the
> raw key.
And this is good.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
ocus on open issues. This will give the folks in the room the maximum
amount of time to discuss issues.
This WG has one active draft in front of it; it is not too much of us to expect
you to read it before coming to the meeting.
--Paul Hoffman
___
IPs
-pubkey issues
Are there other IPsec-related topics for the meeting?
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
uot;peer to peer" which kinda assumes unknown peers
> and on the fly configuration.
The term "peer" means no such thing. It means "two parties who communicate
without there being a client-server relationship". There are numerous other
IETF p
ead on opportunistic VPNs, which this is not.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
resume the discussion of #210 after we have answers on the other issues.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
.ietf.org/meeting/83/materials.html>
For contributing to the discussion, you need to send messages to the Jabber
room that will be relayed to the mic. In the Jabber room, prepend "mic:" to any
message you want read at the mic.
--Paul Hoffman
___
ither ATM nor DC are defined in the current document. It would be better not
to introduce new acronyms for a single use case.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Let me know if you think I got anything wrong. If you were one of the people
whose names I missed, by all means let me know. If you want to discuss anything
that was said, do *not* reply to this message, but use a new thread.
--Paul Hoffman
IPsecME WG
IETF 83, Paris
Monday, March 26, 2012
WG LC count for
more than a bare statement of interest.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Begin forwarded message:
> From: rfc-edi...@rfc-editor.org
> Subject: RFC 6617 on Secure Pre-Shared Key (PSK) Authentication for the
> Internet Key Exchange Protocol (IKE)
> Date: June 1, 2012 6:50:52 PM PDT
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> Cc: rfc-edi...@rfc-editor.org
>
> From: rfc-edi...@rfc-editor.org
> Subject: RFC 6628 on Efficient Augmented Password-Only Authentication and Key
> Exchange for IKEv2
> Date: June 1, 2012 6:51:04 PM PDT
> To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
> Cc: rfc-edi...@rfc-editor.org
>
>
> A new Request for Comments is now
this behavior at the ISP is novel.
* Use IKE over TCP only after IKE over UDP fails during transmission of a
packet >512 bytes. That would be interoperable with current deployments
(although they would not see the second attempt, of course), it costs little,
and is trivial to implement.
--Pa
On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote:
> On Thu, 7 Jun 2012, Paul Hoffman wrote:
>
>>> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is
>>> already allocated to "ISAKMP". We have had IKE running over TCP for several
>>>
On Jun 7, 2012, at 10:26 AM, Nico Williams wrote:
> On Thu, Jun 7, 2012 at 11:54 AM, Paul Hoffman wrote:
>> On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote:
>>> Also, if we are doing this, I'd prefer to be able to signal which tcp
>>> port to use, to make it
On Jun 7, 2012, at 2:53 PM, Yoav Nir wrote:
>
> On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote:
>
>>> * Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is
>>> already allocated to "ISAKMP". We have had IKE running over TCP for several
Here is the proposed agenda; let us know if you think it should be different.
Greetings, note well, blue sheets: 5 min
draft-ietf-ipsecme-p2p-vpn-problem: 60 min
draft-nir-ipsecme-ike-tcp: 15 min
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
On Jul 16, 2012, at 12:18 PM, Paul Wouters wrote:
> On Mon, 16 Jul 2012, Paul Hoffman wrote:
>
>> Here is the proposed agenda; let us know if you think it should be different.
>>
>> Greetings, note well, blue sheets: 5 min
>> draft-ietf-ipsecme-p2p-vpn-problem: 6
On Jul 18, 2012, at 11:56 AM, Tero Kivinen wrote:
> Paul Hoffman writes:
>> On Jul 16, 2012, at 12:18 PM, Paul Wouters wrote:
>>> On Mon, 16 Jul 2012, Paul Hoffman wrote:
>>>> Here is the proposed agenda; let us know if you think it should be
>>>>
iated.
During the discussion of the -00 draft earlier this year, a number of WG
participants sent comments to the list. It appears that none of those comments
were addressed, either on the list or in this -01 draft. Could any of the draft
authors please reply
and
SEC1-v2.0) list things that newer curves might not meet because, well, they're
newer than the standards. Why should that be a limitation on what is used in
IPsec?
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
nd parameters.
Good suggestion, yes.
>> The solution should be an extension to IKEv2,
>
> Why should this be a requirement? It is something of a layer violation
> to require the protocol to provide the information about how to process
> the signa
ing we do here should have good reason, and it should be
documented.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
hope that IPsec-concerned
people come to the MIF WG today but, even if not, participate in the discussion
of the draft.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
<http://www.ietf.org/proceedings/84/minutes/minutes-84-ipsecme>
Please submit any changes.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
ant to do those, I want the ADs to decide whether it is
appropriate to do more work on IKEv1, such as adding these curves to the IKEv1
registries. If they think the work is appropriate, they can also say where it
should be done.
--Paul Hoffman
___
This appeared on the list over two weeks ago and it has received no comments
since. This is supposed to be the WG's main work item, folks.
--Paul Hoffman
On Aug 23, 2012, at 9:02 AM, Stephen Hanna wrote:
> Vishwas and I have updated the AD VPN Problem Statement
> and Requiremen
eks ago, seriously. I am very hesitant to wait for additional requirements
comments from people who don't even know about the work without some reasonable
expectation that those comments will be useful. I don't want to be harsh, but
is there a particular reason that those folks have not pa
This all works for me, adding #6) Remove the snark.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Greetings again. draft-ietf-ipsecme-ike-tcp-00.txt has been out for over a
month and has received no discussion. Please review this short draft and
comment on the mailing list.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org
e is given to those which are in the WG charter.
draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully there
will be more discussion of it before the meeting
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.o
On Oct 17, 2012, at 7:52 AM, Yaron Sheffer wrote:
> A quick correction: the latest version of the now-finished draft has been
> renamed draft-ietf-ipsecme-ad-vpn-problem ("auto-discovery VPN",
> http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00).
Whoops, yes. An artifact of my so
fts to say how
they cover or don't cover what's in the requirements and scenarios document.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
uce the -01 draft (and I did not notice this). I
*really* hope they produce a new version before the submission cutoff on
Monday; we can then either continue the discussion or send the document to IETF
Last Call.
--Paul Hoffman
___
IPsec mailing list
IPse
on the problems that your document
solves for the IPsecME WG? Yaron and I suspect that there is overlap, and
having good lists of the similarities and differences behind the documents
would help the two WGs decide what should be in them.
--Paul Hoffman
__
1 - 100 of 589 matches
Mail list logo
