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
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 IPSec
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
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 IPSec
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
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 similar
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-developer"
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 which
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
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 that got moved
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
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 common
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 very
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 ITAR?
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
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
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 you guys
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
in
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
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.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
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 similar
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-developer still
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 which made
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
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 that got moved
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
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 common sense
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 very
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 buck
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
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 you guys
d then, FreeBSD-IPv6 plan.
Now (as attached), unified-ipv6 effort has settled down into KAME.
so it should be okay to merge KAME (= unified-ipv6) into
FreeBSD-current. There may be some changes that may trouble you
during the first period of merging, but I th
.
Now (as attached), unified-ipv6 effort has settled down into KAME.
so it should be okay to merge KAME (= unified-ipv6) into
FreeBSD-current. There may be some changes that may trouble you
during the first period of merging, but I think FreeBSD and KAME
guys
34 matches
Mail list logo
