Hi Vijay, I agree there is no consensus on the "locally meaningful name". But I'd like to hear more opinions before we add new stuff to the draft at this late stage.
Regarding private values: We want to encourage experimentation with the
protocol, and private values are an important part of that. People may not
have stable documentation when they start to deploy a system, or such
documentation may be confidential. Private use ranges provide an easy way
for vendors to deal with such cases. In this particular case, I don't see
any reason NOT to include a private range.
Thanks,
Yaron
> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email protected]]
> Sent: Thursday, June 11, 2009 2:19
> To: Yaron Sheffer; Yoav Nir; Tero Kivinen
> Cc: [email protected]
> Subject: Re: [IPsec] Some comments about redirect
>
> Hello,
>
> On 5/31/09 1:19 AM, "Yaron Sheffer" wrote:
>
> > I think we should *not* add this type. I don't see how a client and a
> > gateway can agree on such a "locally meaningful name", without
> > non-interoperable protocols (or configuration databases). And I don't
> think
> > we should add this new concept, of all places, to the Redirect draft.
>
> I don't see a consensus on this yet. Tero and Yoav would like to see this
> new gateway id type.
>
> > But of course we should reserve a portion of the new ID Type registry
> for
> > private use.
>
> Since new values can be assigned by "Expert Review" do we really need to
> set
> aside space for private use? You can always request new assignments
> without
> having to revise the RFC.
>
> Vijay
>
> >
> > Thanks,
> > Yaron
> >
> >> -----Original Message-----
> >> From: [email protected] [mailto:[email protected]] On Behalf
> Of
> >> Vijay Devarapalli
> >> Sent: Saturday, May 30, 2009 0:51
> >> To: Yoav Nir; Tero Kivinen
> >> Cc: [email protected]
> >> Subject: Re: [IPsec] Some comments about redirect
> >>
> >> Ok.
> >>
> >> Anyone else have any comments on including "4 - Locally Meaningful
> Name"?
> >>
> >> Vijay
> >>
> >>
> >> On 5/27/09 3:14 PM, "Yoav Nir" wrote:
> >>
> >>> The client has to have a PAD that includes the gateways.
> >>>
> >>> Our implementation has the client downloading the configuration (by a
> >>> proprietary protocol) that includes the gateway names (and how to find
> >> them -
> >>> IP address or DNS name). These gateway names can optionally be shown
> to
> >> the
> >>> user in the GUI. In any case, the client is as aware of the names as
> >> the
> >>> gateways.
> >>> ________________________________________
> >>> From: Vijay Devarapalli [[email protected]]
> >>> Sent: Thursday, May 28, 2009 01:04
> >>> To: Yoav Nir; Tero Kivinen
> >>> Cc: [email protected]
> >>> Subject: Re: [IPsec] Some comments about redirect
> >>>
> >>> Hi Yoav,
> >>>
> >>> On 5/27/09 3:11 AM, "Yoav Nir" wrote:
> >>>
> >>>> OK. In that case I would add to the initial registry
> >>>>
> >>>> 4 - locally meaningful name
> >>>
> >>> The client should be able to resolve this "locally meaningful name" to
> >> an IP
> >>> address to which it can initiate a new IKE_SA_INIT exchange. These
> >> "locally
> >>> meaningful names" might make sense to the pool of IKEv2 gateways, but
> >> would
> >>> it make sense to the client? How does the client figure out what the
> new
> >> VPN
> >>> gateway is?
> >>>
> >>> Am I missing something?
> >>>
> >>> Vijay
> >>>
> >>>>
> >>>> In our product, the gateways have "names" that appear both in the GUI
> >> and the
> >>>> configuration files (and logs). It's easier for them to fetch another
> >>>> gateway's "object" by name than by IP address. Such a name could be
> >> ASCII or
> >>>> UTF-8.
> >>>> ________________________________________
> >>>> From: Tero Kivinen [[email protected]]
> >>>
> >>>
> >>> Scanned by Check Point Total Security Gateway.
> >>>
> >>> Email secured by Check Point
> >>
> >> _______________________________________________
> >> IPsec mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/ipsec
> >>
> >> Scanned by Check Point Total Security Gateway.
>
>
> Scanned by Check Point Total Security Gateway.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
