Hi Raj
I don’t think we can specify MUST requirements for the AAA servers, because
we’re not specifying RADIUS or DIAMETER here.
For example in RADIUS, the VPN gateway sends an Access-Request to the server,
which contains the user-name, presumably the same user-name from the IDi
payload.
If
Hi all.
5 more issues.
Issue #153 - List of EAP methods
3.16: I suggest to remove the table quoted from the EAP RFC. There are dozens
of methods now in the IANA registry, many of which are preferable to the ones
mentioned here.
I agree, especially since we
Me too, but the draft still requires *some* selectors, so the childless draft
is still needed.
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Raj
Singh
Sent: Wednesday, February 03, 2010 5:25 AM
To: Dan McDonald
Cc: IPsecme WG; Paul Hoffman
Hi all.
Yet another batch of issues that we wish to close.
Issue #140 - No SPD entry for transport mode
Section 2.23.1: If the responder doesn't find SPD entry for transport mode with
the modified traffic selectors, and does a lookup with the
the request. The Response bit is set to 1, and the version
flags are set in the normal fashion.
-Original Message-
From: Tero Kivinen [mailto:kivi...@iki.fi]
Sent: Thursday, January 28, 2010 4:40 PM
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: [IPsec] Closing issue #143 (rewrite of section 1.5
Hi all.
Combining Pasi's proposed text with Tero's comments I came up with this version.
Is this acceptable to everyone?
Yoav
There are couple of cases when a node receives a packet it cannot
process, but may want to notify the sender about this situation:
o If an ESP or AH packet
Hi all
The offending paragraph is the following;
An initiator can use port 4500, regardless whether or not there is
NAT, even at the beginning of IKE. When either side is using port
4500, sending with UDP encapsulation is not required, but
understanding received packets with UDP
I've stayed out of this discussion so far, because my opinion has already been
noted, but since you've changed the subject...
On Jan 27, 2010, at 12:50 AM, Kemp, David P. wrote:
Yes. I agree that SCSV could be defined to convey only 1 bit of
information while RI conveys 2 bits, and agree
Hasn't this item just been approved by the IESG? Isn't it done?
snip/
- A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion detection system, to easily and reliably
determine whether an ESP packet is encrypted
Yes, but the heuristics document is not standards-track.
Never mind, I'm not trying to nit-pick our charter proposal.
On Jan 26, 2010, at 11:41 PM, Paul Hoffman wrote:
At 11:27 PM +0200 1/26/10, Yoav Nir wrote:
Hasn't this item just been approved by the IESG? Isn't it done
On Jan 22, 2010, at 11:57 PM, Yaron Sheffer wrote:
The text in 3.3 requires peace of mind to fully appreciate. A diagram might
be helpful.
Here's a first shot (we'll need to add some descriptive text):
SA Payload
|
On Jan 25, 2010, at 1:44 PM, Tero Kivinen wrote:
Yoav Nir writes:
Issue #141 - Silently deleting the Child SA after a CHILD_SA_NOT_FOUND
==
Section 2.25: A peer that receives a CHILD_SA_NOT_FOUND
notification SHOULD
Hi all.
A new version of the dictionary is posted to
http://www.lojban.org/tiki/Books
As before, I'm using this platform to request help in two areas:
- The last two sections contain missing definitions, either English or
lojban. Those of you who have the time, please have a look at those
Hi all
We would like to begin closing IKEv2bis issue at a faster rate than we are
opening new ones. Paul has sent the list a several issues. Some we have
discussed, others - not so much. Here's a summary of three issues, which I
think are ready for closure.
Issue #138 - Calculations
I think extensions such as RoHC that change (or extend) the way keying material
is generated, should and do specify how it is done. Leaving that text there
becomes a recommendation for future draft writers, which I think is
superfluous.
I think we should leave the text as it is.
On Jan 19,
We can't really prescribe actions for (presumably older) implementations that
don't support this spec.
Such implementations will do what it says in RFC 4306 and the clarifications
document: TEMPORARY_FAILURE is an error notification, so therefore the exchange
failed. In that case the old SA
Agree. Certainly types 4-6 have to be removed, as they are just methods, and we
RECOMMEND not to use them. I can see some value in mentioning type 1
(Identity), because later in that same section we mention that the responder
should not send such requests. I think we should remove all the rest,
I agree, and I don't think you need brackets:
only the first 64 bits of Ni and the first 64 bits of Nr are used in
calculating SKEYSEED, but all the bits are used for input to the prf+ function.
(although I personally did not find it confusing)
On Jan 19, 2010, at 4:25 AM, Paul Hoffman wrote:
+1
Anybody who starts implementing IKEv2 in a few months using the new RFC should
not have to care about the history, and which notify type was added at which
point, except to know that some implementations in the field may not support
these newer notifications.
-Original Message-
Hi Scott
When writing remote access VPN clients (running on phones, PCs, tablets,
probably not z/OS) it's usually safe to assume that the peer (a gateway)
supports NAT-T. This is because on the real Internet, a RAS that does not
support NAT-T simply doesn't work. NATs are everywhere.
So it's
On Jan 7, 2010, at 9:14 AM, Charlie Kaufman wrote:
Oh sigh!! What is it about IPsec that makes people go down this same path
every time:
snip/
IPsec?
So I guess you haven't been following the TLS mailing list these past couple of
months.
I don't think anyone's described a practical
On Jan 5, 2010, at 12:27 AM, Yaron Sheffer wrote:
Hi,
We have had a few discusses during the IESG review of the WESP draft. To
help resolve them, we would like to reopen the following two questions to WG
discussion. Well reasoned answers are certainly appreciated. But plain yes
or no
FWIW you see a lot more prenu than remna.
remna is used specifically to denote humans. There is no specific
requirement for prenu to be human or sentient. If you're one of those who
say cats are people too then you could use prenu for a cat.
Suppose you wanted to use legal language. Almost all
From: ipsec-boun...@ietf.org [ipsec-boun...@ietf.org] On Behalf Of Yoav Nir
[y...@checkpoint.com]
Sent: Wednesday, December 16, 2009 12:01 AM
To: Paul Hoffman; IPsecme WG
Subject: Re: [IPsec] Issue #128: Can implementations not reply fully to
Deletes
On Dec 16, 2009, at 6:36 AM, rahul bharadhwaj wrote:
Hi all
Could anyone let me know which crypt algo des/3des/aes should be used with
aes-xcbc-mac hashing.
As aes-xcbc-mac uses aes for authentication and integrity, is it correct to
apply des for encryption or is there any restriction.
Section 1.4.1 also says:
A node MAY refuse to accept incoming data on half-closed
connections but MUST NOT unilaterally close them and reuse the SPIs.
So if your peer is only responding with empty INFORMATIONAL responses to your
deletes, you're going to accumulate more and more stale inbound
Hi Alper.
The Do phase 1 first, and phase 2 as traffic demands it motivation is from
the remote access VPN domain (though may be useful for others).
The Do only phase 1, because we don't need encryption and MAC, just peer
authentication motivation is from the 3GPP (though it could be useful
On Dec 2, 2009, at 9:04 AM, Chris Newman wrote:
This the most time-sensitive and security-critical IETF draft with respect
to impact on the Internet community that I have seen in 17 years of IETF
participation.
This is the part I disagree with.
New extensions to protocols will take
On Nov 30, 2009, at 5:37 PM, The IESG wrote:
The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Transport Layer Security (TLS) Renegotiation Indication Extension '
draft-ietf-tls-renegotiation-01.txt as a Proposed Standard
There were several motivations listed for childless IKE SAs.
- remote access, where you create an IKE SA when the user wants to connect,
and only create child SAs in response to traffic
- authentication only over a physically secure network (not necessarily EAP,
but I think this is the use
+1
Even things that seem obvious like https and ftp require a lot of
considerations, like how to verify the certificate in https, or what identity
to present in ftp.
If someone wants to specify additional URL methods, they can specify then in an
I-D.
On Nov 24, 2009, at 8:24 PM, Paul Hoffman
What Dan and Gregory said.
But assuming an unloaded gateway, with normal hardware (Any Intel, AMD or
PowerPC processor from the last 10 years or a recent ARM), then even if you use
relatively secure parameters (2048-bit DH group, 2048-bit RSA keys) the round
trip time is going to dominate. The
in the
same list as VPN-A and VPN-B.
From: Paul Hoffman [paul.hoff...@vpnc.org]
Sent: Friday, November 13, 2009 02:58
To: Yoav Nir; Law, Laurie; ipsec@ietf.org
Subject: Re: [IPsec] RFC4869 bis submitted
At 10:07 PM +0200 11/11/09, Yoav Nir wrote
On Nov 12, 2009, at 5:34 AM, Raj Singh wrote:
The selection of AAA server will be based on IDi then EAP will happen.
The gateway will get EAP authenticated ID from the AAA server.
If EAP identity is different from IDi and no policy is found for EAP identity.
The gateway should initiate
and later in the EAP session.
On Nov 11, 2009, at 4:05 PM, Srinivasu S R S Dhulipala (srinid) wrote:
Hi Yoav,
Thanks for the quick response. Please see inline.
-Original Message-
From: Yoav Nir [mailto:y...@checkpoint.com]
Sent: Wednesday, November 11, 2009 7:23 PM
To: Srinivasu S R S
Hi Hui
I think there is very little difference between IPv4 and IPv6 as
regards to IPsec. See below
On Oct 11, 2009, at 9:50 AM, Hui Deng wrote:
Dear IPsec forks,
May I get advice about the differnce between them:
1) IPv4 doesn't mandate the support IPsec, IPv6 also doesn't mandate
it
On Sep 24, 2009, at 9:44 PM, Paul Hoffman wrote:
At 12:13 PM -0600 9/24/09, Grewal, Ken wrote:
Proposed change
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
I support advancing this document, and I think the explanations and
pseudo code are good.
I do, however, question the value of it in real life.
Security policies or the deep inspection kind usually are something
like:
- allow HTTP and HTTPS, and verify headers
- allow ICMP and DNS
-
Hi all
The draft linked below is a problem statement draft about using
IKEIPsec implementations in high availability and load sharing
configurations.
I will describe this at tomorrows Interim meeting.
Comments are welcome, of course, both on the list and at tomorrow's
session.
Yoav
A
On Fri, Sep 18, 2009 at 9:38 AM, Ross Ogilvie oges...@gmail.com wrote:
coi rodo,
I've been looking around the lojban wiki and I was wondering a few things.
The Solar System (http://jbo.wikipedia.org/w/index.php?title=solri_ciste)
in particular strikes me as poor word-for-word translated
On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote:
Section 3.1.5 of RFC 4945 states that when generating an ID type of
ID_DER_ASN1_DN that implementations MUST populate the contents of
ID with the Subject field from the end-entity certificate, and MUST
do so such that a binary
Wierbowski
z/OS Comm Server Developer
Phone:
Tie line: 620-4055
External: 607-429-4055
graycol.gifYoav Nir ---09/17/2009 02:50:34 AM---On Sep 17, 2009, at 5:33 AM,
David Wierbowski wrote: Section 3.1.5 of RFC 4945 states that when ge
ecblank.gif
From: ecblank.gif
Yoav Nir y
OK. One more try:
2.21. Error Handling
There are many kinds of errors that can occur during IKE processing.
If a request is received that is badly formatted, or unacceptable
for
reasons of policy (e.g., no matching cryptographic algorithms), the
response MUST contain a Notify
On Sep 7, 2009, at 3:48 PM, Tero Kivinen wrote:
Keith Welter writes:
I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted
either.
I do consider INVALID_SYNTAX fatal error, meaning the IKE SA will be
deleted immediately after sending that response containing
INVALID_SYNTAX
OK. Let's try this again. Is this acceptable?
2.21. Error Handling
There are many kinds of errors that can occur during IKE processing.
If a request is received that is badly formatted, or unacceptable
for
reasons of policy (e.g., no matching cryptographic algorithms), the
We should be able to preserve the tone and sarcasm through rhetorical
questions
paunai xu do bilga lenu cliva
paunai xu do bilga lenu klama le datselzva
On Fri, Sep 4, 2009 at 5:03 PM, tijlan jbotij...@gmail.com wrote:
Though i'm not a native English speaker, it seems to me that don't
you have
Then I should have explained better.
If an initiator sees an error in the response, the exchange is already over, so
the only way it can notify the responder of the error, is to create a new
INFORMATIONAL exchange with an error notification.
All the text here discusses the one INFORMATIONAL
Hi Kalyani
Of the two, I prefer the 2nd solution, as it is simpler. Reusing message IDs is
not that bad, and you can decrease the change by including (in the
RESET_MESSAGE_ID notification) a random number as the starting message ID.
What I'm not so sure, is that there is a real problem here
Yes, I will soften the language a bit, but I won't mention a DELETE payload. If
some implementations do it. others may come to expect it. We don't want to
encourage that by suggesting that it's a good idea.
On Sep 3, 2009, at 11:52 PM, Keith Welter wrote:
If the error occurs on the
coi rodo
The 6th edition of the jbovlaste-based dictionary (in PDF) is available from
http://www.lojban.org/tiki/books
Nothing new as far as features go, but the size has increased to 323 pages.
I guess a lot of new stuff is being added to jbovlaste.
Still looking for ideas/volunteers for some
:
hmmm, in the cheat sheet section, wouldn't {ma'a} have all three people
circled in yellow?
On Wed, Sep 2, 2009 at 11:18 AM, Yoav Nir yoav@gmail.com wrote:
coi rodo
The 6th edition of the jbovlaste-based dictionary (in PDF) is available
from http://www.lojban.org/tiki/books
Nothing new
Hello all.
Issue #26 was submitted by Tero Kivinen. It concerns section 2.21
(error handling) and states that several things are missing:
- handling of errors before authentication
- listing what error conditions cause the IKE SA to be deleted entirely
- listing how errors are handled in the
On Sep 1, 2009, at 5:07 PM, Tero Kivinen wrote:
Yoav Nir writes:
Following is our suggested new text. Please let us know what you
think. Also, please take a look at the description of
AUTHENTICATION_FAILED in section 3.10.1. response to an IKE_AUTH
message means either an IKE_AUTH response
I disagree.
Payloads in a particular CREATE_CHILD_SA exchange should be specifically
related to the SA being created. The IKE_AUTH exchange is different, because
it is used to set up everything we need to get an IPsec SA going.
We do not use the CREATE_CHILD_SA to delete old SAs, to query
Any INVALID_IKE_SPI or INVALID_SPI message can trigger DPD (or, as RFC 4306
calls it, liveness check). These messages are very easy to spoof.
But liveness check is just one round trip between the peers and it's supposed
to be rate-limited. I don't think an off-path attacker can cause the
Vijar Devarapalli wrote:
Hi Yoav,
On 7/29/09 9:13 PM, Yoav Nir wrote:
Hi Vijay.
default is usually associated with a particular implementation or
product. I think it would be better to say suggested value rather
than default value.
default value is the right terminology to use here
to discard #17. If it was still valid for
the initiator to send request #17 again, the responder would have to retain all
the old responses indefinitely.
From: Amjad Inamdar (amjads) [mailto:amj...@cisco.com]
Sent: Wednesday, July 22, 2009 12:23 PM
To: Yoav Nir; Raj
solvable, because the policies actually
conflict.
From: Gaurav Poothia [mailto:gpoot...@microsoft.com]
Sent: Thursday, July 09, 2009 7:57 AM
To: Yoav Nir; 'Raghunandan P (raghup)'; Raj Singh
Cc: ipsec@ietf.org
Subject: RE: [IPsec] FW: I-D Action:draft-nir-ipsecme
I've read it again, and it seems fine. One minor issue, though.
Section 2 describes the WESP header format. It has the following:
HdrLen, 8 bits: Offset to the beginning of the Payload Data in
octets. The receiver MUST ensure that this field matches with
the header offset computed
.
Maybe when we make version 2.1 of IKE, we can add a critical type bit to the
notification payload.
From: Raj Singh [mailto:rsjen...@gmail.com]
Sent: Wednesday, July 08, 2009 7:18 AM
To: Tero Kivinen
Cc: Yaron Sheffer; ipsec@ietf.org; Yoav Nir
Subject: Re: [IPsec] FW
, 2009 1:43 PM
To: Yoav Nir; Raj Singh
Cc: ipsec@ietf.org
Subject: RE: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
Hi Yoav/Raj,
I think its a good idea for the initiator to announce its capabilities about
supporting just IKE SA without child SA. The responder will then act
Hi.
IMO the CFG payloads are the last place where there will ever be a shortage of
IPv4 addresses. The addresses distributed through CFG payloads in IKEv2 or
through extensions to IKEv1 are almost always non-routable addresses, and even
for extremely large organizations, there are plenty of
I agree with Yaron that it should be the way it is now described in the draft.
If either side deleted the IKE SA, then it should not come back to life through
session resumption. Specifically, the client should not get reconnected without
authentication. The laptop example is excellent. If I
Interesting, because I can't pronounce it syllabic.
It comes out like shi-djer-ka-ri
On Tue, Jun 16, 2009 at 6:44 PM, Pierre Abbat p...@phma.optus.nu wrote:
On Tuesday 16 June 2009 09:30:24 tijlan wrote:
In LFB 12, the r-hyphen in cidjrkari is claimed to be a syllable on
its own, and the
I'm not so sure about that. The authentication in the IKE_AUTH exchange that
follows the resumption only proves that the (new) responder can decipher the
ticket (or has access to the ticket database).
Presumably a cluster of gateways backing each other up would have the same
IDr, but if
-
From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org]
Sent: Sunday, May 31, 2009 6:03 PM
To: Yoav Nir
Subject: New Version Notification for draft-nir-ike-nochild-01
A new version of I-D, draft-nir-ike-nochild-01.txt has been successfuly
submitted by Yoav Nir and posted to the IETF
Hi.
I've read through the draft again, and here are a few comments:
Section 3 has the following line:
If the
IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload,
the responder MUST NOT send the REDIRECT payload to the
be ASCII or UTF-8.
From: Tero Kivinen [kivi...@iki.fi]
Sent: Wednesday, May 27, 2009 13:02
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: [IPsec] Some comments about redirect
Yoav Nir writes:
Section 10 sets up an IANA registry for identity types. Couldn't we
just
in the GUI. In any case, the client is as aware of the names as the
gateways.
From: Vijay Devarapalli [vi...@wichorus.com]
Sent: Thursday, May 28, 2009 01:04
To: Yoav Nir; Tero Kivinen
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Some comments about redirect
Hi Yoav
...@wichorus.com]
Sent: Thursday, May 28, 2009 01:02
To: Yoav Nir; ipsec@ietf.org
Subject: Re: [IPsec] Some comments about redirect
Hello,
On 5/27/09 12:36 AM, Yoav Nir wrote:
Hi.
I've read through the draft again, and here are a few comments:
Section 3 has the following line
Paul Hoffman wrote:
IOW it's up to the initiator whether or not to do PFS, and both
configurations are OK to use the suite name.
That was my intention in RFC 4308; I cannot speak for the
authors of RFC 4869.
You can't speak for them, but Scott has to figure it out.
As for lifetimes,
WARNING: contains banned part
---BeginMessage---
On Tue, 2009-05-12 at 10:05 +, ss murthy nittala wrote:
Hi
Thanks for the clarifications regarding IV usage for AES methods.
RFC 2405 (DES) in its implementation note says
Common practice is to use random data for the first IV and the
Paul Hoffman wrote:
At 12:53 AM +0300 5/11/09, Yoav Nir wrote:
Paul Hoffman wrote:
At 2:08 PM +0300 5/10/09, Yoav Nir wrote:
Hi all
I've submitted issue #107 about certificate encoding.
IMO it's not clear how certificate chains are to be
encoded in IKEv2.
http
Pasi.Eronen wrote:
Yoav Nir wrote:
You can:
a) start using hash-and-url
b) hope your peer has the sub-CA
c) write an extension to 4306 that allows bundles in CERT
Doing (a) is the most interoperable, but you're probably
save with
(b) in a typical closed network
Hi all
I've submitted issue #107 about certificate encoding.
IMO it's not clear how certificate chains are to be encoded in IKEv2.
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107
Yoav
Email secured by Check Point
___
IPsec mailing list
Michael Richardson wrote:
Yoav Nir wrote:
Hi Raj
Matt is correct. There is no way in IKEv2 to do a phase1-only
exchange, and then wait for traffic to establish the child SAs.
While we do establish an IKE SA if the piggy-backed child SA failed
for whatever reason (bad selectors
Grewal, Ken wrote:
Issue #90: shorter WESP negotiation
In the current traffic visibility draft, we indicate that WESP can be
negotiated via IKEv2 using a new protocol identifier.
Charlie Kaufman suggested that it may be plausible to use a notification
method along the lines of
I don't think we should really prohibit such extensions and enhancements. It's
just that IKE will fail if you try it with a peer that does not support it.
As far as the end-user is concerned, this is not different from an
UNSUPPORTED_CRITICAL_PAYLOAD in IKE_AUTH. Either way, the tunnel setup
So are we working with the assumption that the gateway (or the AAA server) can
always authenticate any user that connects?
-Original Message-
From: Yaron Sheffer
Sent: Monday, April 20, 2009 10:43 AM
To: Yoav Nir; Vijay Devarapalli
Cc: IPsecme WG
Subject: RE: [IPsec] WG Last Call
Vijay Devarapalli wrote:
Hello,
Yoav Nir wrote:
I see that in section 6 the following:
In such cases, the gateway should send the REDIRECT notification
payload in the final IKE_AUTH response message that carries the AUTH
payload and the traffic selectors. The gateway MUST
I prefer the second proposal. I would rather have one (even if longer)
variation of the protocol over two variations (even if one is shorter)
With such a possible attack published, auditors are going to force large
installations to use the safer (and longer) version anyway, as it is up to the
Hi Matt
Requests and responses have matching MsgID numbers. The requestor can instantly
identify the response by its matching Msg ID number. INFORMATIONAL exchanges
have message authentication codes applied to messages, so the ID numbers can't
(or shouldn't) get messed up on the responsder.
Definitely
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott
C Moonen
Sent: Thursday, April 02, 2009 3:48 PM
To: Yaron Sheffer
Cc: IPsecme WG
Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go?
From Appendix C: The
some properties of that as-yet-non-existant IKE SA seems
premature to me. I think it should be in all but the IKE_SA_INIT exchange (and
also not in unprotected informational)
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav
Nir
Sent
RFC 4306 specifically requires implementations to support multiple parallel
child SAs.
If you use a different SA for each QoS class, you should not have problems with
the replay window
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Hi all
I've just posted version 4 of my (nicer) PDF rendering of jbovlaste
Still looking for people to draw more cheat sheet pages and for sites to
host it
files.me.com/yoavetali/mxc8u2
gabriel montenegro wrote:
I'll just comment on one item below:
As the draft says this is mostly meant for stateful devices, and that
has been the main goal for the document. The charter says:
A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion
Tero Kivinen wrote:
Can we live with push-to-talk?
Push-to-talk works well for normal discussion, but it was
impossible to use when giving presentation, which meant that
I myself changed the setting to voice activated microphone
when I started my presentation, and then changed back to
coi rodo
I have just created the 2nd edition of my jbovlaste-based dictionary (linked
below)
Some additions in this edition
- updated database
- analysis of lujvo (works almost every time)
- hyperlinks from lujvo analysis and from links in the text
- error list: lojban words that
Explorer 7? It's a PDF file.
You can read it in Acrobat Reader or Preview (on a Mac)
On Mon, Dec 1, 2008 at 12:25 AM, Yoav Nir [EMAIL PROTECTED] wrote:
coi rodo
I have just created the 2nd edition of my jbovlaste-based dictionary
(linked below)
Some additions in this edition
- updated
On Wed, Nov 12, 2008 at 2:31 AM, Jorge Llambías [EMAIL PROTECTED]wrote:
On Tue, Nov 11, 2008 at 8:30 PM, Yoav Nir [EMAIL PROTECTED] wrote:
I searched jbovlaste and could not find an Indian Chief, or even an
American
Indian or native american. I could make up a big tanru with
leader
Attempting to translate a joke like this gave me some thought.
The sentence is kind of easy
--- klama lo barja
or
--- klama mo'ine'i lo barja
The hard part is the participants.
I searched jbovlaste and could not find an Indian Chief, or even an American
Indian or native american. I could
coi rodo
Is there an algorithm to analyzing lujvo? I would like the input to be a
single lujvo and the output to be a sequence of the appropriate gismu and
cmavo.
Is that described anywhere on lojban.org or the CLL?
mi'e ioav
So I guess, not much interest...
Oh well, it's a fun project.
On Fri, Oct 24, 2008 at 10:28 PM, Yoav Nir [EMAIL PROTECTED] wrote:
coi rodo
For a while now, I've had some problems trying to get an English-lojban
dictionary from jbovlaste. Even when I managed to get one, I found searching
, 2008 at 4:00 PM, Luke Bergen [EMAIL PROTECTED] wrote:
It would be more useful for me if it were in a flat text file instead of a
pdf. If something like that were possible that would be great. Also, about
how large is this distribution list?
On Mon, Oct 27, 2008 at 7:39 AM, Yoav Nir [EMAIL
coi rodo
For a while now, I've had some problems trying to get an English-lojban
dictionary from jbovlaste. Even when I managed to get one, I found searching
it to be a pain.
So I downloaded the XML file, and re-formatted it to the format expected by
OpenOffice. I then opened the file in OO, and
On Mon, Oct 6, 2008 at 11:35 PM, H. Felton [EMAIL PROTECTED] wrote:
H. Felton wrote:
So, sisku _can_ mean ko sisku?
In general (if I understand correctly), any part of Lojban speech can be
omitted when grammatically unambiguous. In this case, the context
(application command) makes
like EAP-GTC?
Cheers,
Joe
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Yoav Nir
Sent: Monday, April 28, 2008 5:13 AM
To: emu@ietf.org
Subject: Re: [Emu] EMU charter revision
Gene Chang said:
Dan,
I am not sure I am able
On Feb 18, 2008, at 3:28 AM, Pierre Abbat wrote:
On Sunday 17 February 2008 15:43, David Cortesi wrote:
per jbovlaste, complex number is {lujna'u} i.e. {pluja namcu}, a
complicated type of number -- not pleasing to me, since it is more a
two-dimensional number than one that is {pluja}.
You might want to tell us first what this phrase means. It's always
better to translate the meaning, rather than a word-for-word
translation.
On Jan 26, 2008, at 11:53 AM, Earth Engine wrote:
Hi all,
I am from Chinese. In these days, a short phase is becoming very
popular: very erotic
1201 - 1300 of 1331 matches
Mail list logo
