> does KAME IPv6 and IPSec define additional facilities for
>syslog? I have been working with IPSec devices from a company called
>Network-Alchemy. They have additional syslog facilities including:
>IKE, IPSEC, L2TP, LOGIN (should be AUTH?), PPTP and others.
>
> Does KAME IPv6 and IP
Itojun,
does KAME IPv6 and IPSec define additional facilities for
syslog? I have been working with IPSec devices from a company called
Network-Alchemy. They have additional syslog facilities including:
IKE, IPSEC, L2TP, LOGIN (should be AUTH?), PPTP and others.
Does KAME IPv6 a
> does KAME IPv6 and IPSec define additional facilities for
>syslog? I have been working with IPSec devices from a company called
>Network-Alchemy. They have additional syslog facilities including:
>IKE, IPSEC, L2TP, LOGIN (should be AUTH?), PPTP and others.
>
> Does KAME IPv6 and I
Itojun,
does KAME IPv6 and IPSec define additional facilities for
syslog? I have been working with IPSec devices from a company called
Network-Alchemy. They have additional syslog facilities including:
IKE, IPSEC, L2TP, LOGIN (should be AUTH?), PPTP and others.
Does KAME IPv6
Mark Murray writes :
> > Speaking of ITAR, has anybody actually every approached FreeBSD to say
> > what we're doing is in violation of ITAR?
>
> IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days
> (at least outside the USA).
>
> The DoD, DoJ, DoE, DoC and watever other Do's yo
Mark Murray writes :
> > Speaking of ITAR, has anybody actually every approached FreeBSD to say
> > what we're doing is in violation of ITAR?
>
> IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days
> (at least outside the USA).
>
> The DoD, DoJ, DoE, DoC and watever other Do's y
> In message <28661.936093...@critter.freebsd.dk> Poul-Henning Kamp writes:
> : >Hmph. I guess common sense wins over ITAR in this case. :)
> :
> : That's certainly an improvement in that particular battle :-)
>
> Speaking of ITAR, has anybody actually every approached FreeBSD to say
> what we'r
> In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
> : >Hmph. I guess common sense wins over ITAR in this case. :)
> :
> : That's certainly an improvement in that particular battle :-)
>
> Speaking of ITAR, has anybody actually every approached FreeBSD to say
> what we're doing is in vi
> Speaking of ITAR, has anybody actually every approached FreeBSD to say
> what we're doing is in violation of ITAR?
IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days
(at least outside the USA).
The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all
passing the buc
In message <28661.936093...@critter.freebsd.dk> Poul-Henning Kamp writes:
: >Hmph. I guess common sense wins over ITAR in this case. :)
:
: That's certainly an improvement in that particular battle :-)
Speaking of ITAR, has anybody actually every approached FreeBSD to say
what we're doing is in
> Speaking of ITAR, has anybody actually every approached FreeBSD to say
> what we're doing is in violation of ITAR?
IANAL, but IIRC, ITAR is dead; Wasssenaar is the bogeyman these days
(at least outside the USA).
The DoD, DoJ, DoE, DoC and watever other Do's you guys have are all
passing the bu
In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: >Hmph. I guess common sense wins over ITAR in this case. :)
:
: That's certainly an improvement in that particular battle :-)
Speaking of ITAR, has anybody actually every approached FreeBSD to say
what we're doing is in violation of ITA
>Hmmm. That's a point. I was thinking primarily of the "segregate the
>crypto" issue, but you're right that this would also put us back to
>the "bad old days" where sys/ was broken across multiple directories.
>Hmph. I guess common sense wins over ITAR in this case. :)
Yes, this is ver
>Hmmm. That's a point. I was thinking primarily of the "segregate the
>crypto" issue, but you're right that this would also put us back to
>the "bad old days" where sys/ was broken across multiple directories.
>Hmph. I guess common sense wins over ITAR in this case. :)
Yes, this is ve
In message <506.936093...@localhost>, "Jordan K. Hubbard" writes:
>Hmmm. That's a point. I was thinking primarily of the "segregate the
>crypto" issue, but you're right that this would also put us back to
>the "bad old days" where sys/ was broken across multiple directories.
>
>Hmph. I guess com
Hmmm. That's a point. I was thinking primarily of the "segregate the
crypto" issue, but you're right that this would also put us back to
the "bad old days" where sys/ was broken across multiple directories.
Hmph. I guess common sense wins over ITAR in this case. :)
- Jordan
> In message <1033
On Tue, 31 Aug 1999, Mark Murray wrote:
> > >I'll be very happy to work with you on this one.
> >
> > Does it make sense to make src/crypto/sys for kernel code?
> > (for IPsec we need crypto code *in kernel*).
>
> I wonder...
>
> There was a contrib/sys (where softupdates went), and tha
> FYI, There are crypto-related files in the following locations.
> I'll take a detailed look into both repositories...
Thanks! It makes the most sense to keep this exactly as it it, except
for the files in src/sys/netinet6/ which should move to src/sys/crypto/
if they have crypto in t
In message <506.936093482@localhost>, "Jordan K. Hubbard" writes:
>Hmmm. That's a point. I was thinking primarily of the "segregate the
>crypto" issue, but you're right that this would also put us back to
>the "bad old days" where sys/ was broken across multiple directories.
>
>Hmph. I guess co
Hmmm. That's a point. I was thinking primarily of the "segregate the
crypto" issue, but you're right that this would also put us back to
the "bad old days" where sys/ was broken across multiple directories.
Hmph. I guess common sense wins over ITAR in this case. :)
- Jordan
> In message <103
>>> Does it make sense to make src/crypto/sys for kernel code?
>>> (for IPsec we need crypto code *in kernel*).
>>I'd say it makes a lot of sense.
>Yes, but shouldn't it be src/sys/crypto if we want to have
>"kern-developer" still have a sensible meaning ? (and for
>all the other reasons
In message <10335.936082...@localhost>, "Jordan K. Hubbard" writes:
>> Does it make sense to make src/crypto/sys for kernel code?
>> (for IPsec we need crypto code *in kernel*).
>
>I'd say it makes a lot of sense.
Yes, but shouldn't it be src/sys/crypto if we want to have
"kern-develope
On Tue, 31 Aug 1999, Mark Murray wrote:
> > >I'll be very happy to work with you on this one.
> >
> > Does it make sense to make src/crypto/sys for kernel code?
> > (for IPsec we need crypto code *in kernel*).
>
> I wonder...
>
> There was a contrib/sys (where softupdates went), and th
> FYI, There are crypto-related files in the following locations.
> I'll take a detailed look into both repositories...
Thanks! It makes the most sense to keep this exactly as it it, except
for the files in src/sys/netinet6/ which should move to src/sys/crypto/
if they have crypto in
>>> Does it make sense to make src/crypto/sys for kernel code?
>>> (for IPsec we need crypto code *in kernel*).
>>I'd say it makes a lot of sense.
>Yes, but shouldn't it be src/sys/crypto if we want to have
>"kern-developer" still have a sensible meaning ? (and for
>all the other reason
In message <10335.936082907@localhost>, "Jordan K. Hubbard" writes:
>> Does it make sense to make src/crypto/sys for kernel code?
>> (for IPsec we need crypto code *in kernel*).
>
>I'd say it makes a lot of sense.
Yes, but shouldn't it be src/sys/crypto if we want to have
"kern-develop
> >I'll be very happy to work with you on this one.
>
> Does it make sense to make src/crypto/sys for kernel code?
> (for IPsec we need crypto code *in kernel*).
I wonder...
There was a contrib/sys (where softupdates went), and that got moved
to sys/contrib.
Perhaps something simila
> Does it make sense to make src/crypto/sys for kernel code?
> (for IPsec we need crypto code *in kernel*).
I'd say it makes a lot of sense.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
>> KAME team really needs your suggestions on how to integrate crypto
>> part. In case of NetBSD/KAME integration, we did like this:
>> - place IPsec core part and AH part into cvs.netbsd.org (in US)
>> - place ESP part and crypto algorithms (DES, Blowfish and whatever
>>
> KAME team really needs your suggestions on how to integrate crypto
> part. In case of NetBSD/KAME integration, we did like this:
> - place IPsec core part and AH part into cvs.netbsd.org (in US)
> - place ESP part and crypto algorithms (DES, Blowfish and whatever
>
> >I'll be very happy to work with you on this one.
>
> Does it make sense to make src/crypto/sys for kernel code?
> (for IPsec we need crypto code *in kernel*).
I wonder...
There was a contrib/sys (where softupdates went), and that got moved
to sys/contrib.
Perhaps something simil
> Does it make sense to make src/crypto/sys for kernel code?
> (for IPsec we need crypto code *in kernel*).
I'd say it makes a lot of sense.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
>> KAME team really needs your suggestions on how to integrate crypto
>> part. In case of NetBSD/KAME integration, we did like this:
>> - place IPsec core part and AH part into cvs.netbsd.org (in US)
>> - place ESP part and crypto algorithms (DES, Blowfish and whatever
>>
> KAME team really needs your suggestions on how to integrate crypto
> part. In case of NetBSD/KAME integration, we did like this:
> - place IPsec core part and AH part into cvs.netbsd.org (in US)
> - place ESP part and crypto algorithms (DES, Blowfish and whatever
>
I heard that, some of you, got confused by recent news about
additional NetBSD-core guys (me).
The above fact does not change anything about KAME-FreeBSD
relationship (I can only speak for KAME side though), because:
- KAME project's goal is to provide IPv6/
I heard that, some of you, got confused by recent news about
additional NetBSD-core guys (me).
The above fact does not change anything about KAME-FreeBSD
relationship (I can only speak for KAME side though), because:
- KAME project's goal is to provide IPv6
36 matches
Mail list logo
