+1 thanks, -suresh
On Mon, Dec 12, 2011 at 07:50:06AM -0800, Mark Boltz wrote: > +1 from me as well. The approach is a good idea, and the WG should proceed as > outlined. > > Mark > > On Dec 12, 2011, at 10:32 AM, <david.bl...@emc.com> > <david.bl...@emc.com> wrote: > > > +1, Thanks, --David > > > >> -----Original Message----- > >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > >> Stephen Hanna > >> Sent: Monday, December 12, 2011 10:19 AM > >> To: Yoav Nir; IPsecme WG > >> Cc: Paul Hoffman > >> Subject: Re: [IPsec] Large Scale VPN > >> > >> Yes, I definitely think this is a good idea. > >> > >> Thanks, > >> > >> Steve > >> > >>> -----Original Message----- > >>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > >>> Of Yoav Nir > >>> Sent: Monday, December 12, 2011 4:45 AM > >>> To: IPsecme WG > >>> Cc: Paul Hoffman > >>> Subject: Re: [IPsec] Large Scale VPN > >>> > >>> Hi all > >>> > >>> If we want Paul and Yaron to take this to our AD, we need to show that > >>> there are more people who think these work items are a good idea. More > >>> people than just me and MCR. So please show your support (or > >>> objections!) soon. An "I think this is a good idea", "I think we should > >>> use ternary logic", or "+1" is all it takes. > >>> > >>> Yoav > >>> > >>> On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: > >>>> > >>>> Agree. How about: > >>>> > >>>> In an environment with many IPsec gateways and remote clients that > >>> share an established trust infrastructure (in a single administrative > >>> domain or across multiple domains), customers want to get on-demand > >>> point-to-point IPsec capability for efficiency. However, this cannot be > >>> feasibly accomplished only with today's IPsec and IKE due to problems > >>> with address lookup, reachability, policy configuration, etc. > >>>> > >>>> The IPsecME working group will handle this large scale VPN problem by > >>> delivering the following: > >>>> > >>>> * The working group will create a problem statement document > >>> including use cases, definitions and proper requirements for discovery > >>> and updates. This document would be solution-agnostic. Should reach WG > >>> last call around October 2012. > >>>> > >>>> * The working group will review and help publish Informational > >>> documents describing current vendor proprietary solutions. These should > >>> be ready for IETF last call by August 2012. > >>>> > >>>> * The working group will choose a common solution for the discovery > >>> and update problems that will satisfy the requirements in the problem > >>> statement document. The working group may standardize one of the vendor > >>> solutions, a combination, an superset of such a solution, or a new > >>> protocol. > >>> > >>> _______________________________________________ > >>> IPsec mailing list > >>> IPsec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipsec > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
