On Aug 25, 2013, at 8:39 AM, Abdussalam Baryun abdussalambar...@gmail.com
wrote:
I agree that charging IETF participants with any money is not a good idea,
but charging participants with some effort/work/contribution to do is needed.
For example, participants SHOULD do some work in IETF,
On Aug 21, 2013, at 3:18 PM, Christopher Morrow morrowc.li...@gmail.com wrote:
use a particular telephone number for an incoming call has no obvious and
it'd actually be kind of nice if the focus was NOT on the (us)
10-digit number, but instead on the 'identity' making the call.
There's a
On Aug 18, 2013, at 8:04 PM, SM s...@resistor.net wrote:
On reading the second paragraph of the above message I see that you and I
might have a common objective. You mentioned that you don't know how to do
that beyond what is done now. I suggested a rate for people with an open
source
On Aug 18, 2013, at 5:21 AM, SM s...@resistor.net wrote:
1. If the IETF is serious about running code (see RFC 6982) it would try to
encourage open source developers to participate more effectively in the IETF.
Define open source developers. Technically quite a lot of developers at my
just a few
people it's not worth arguing about... or doing anything about. It would only
be useful if we got a lot of such attendees.
-hadriel
On Aug 18, 2013, at 10:01 AM, John C Klensin john-i...@jck.com wrote:
--On Sunday, 18 August, 2013 08:33 -0400 Hadriel Kaplan
hadriel.kap
On Aug 17, 2013, at 7:05 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
I don't agree with charging remote attendees until after
it works for them and after successful remote participation
becomes somewhat disruptive to the f2f participants. We have
so far to go before we get there,
On Aug 13, 2013, at 6:24 AM, John Leslie j...@jlc.net wrote:
There are a certain number of Working Groups where it's standard
operating practice to ignore any single voice who doesn't attend an
IETF week to defend his/her postings.
I don't see that happening in the WGs I attend - when
Since the topic keeps getting raised... I think that charging remote
participants any fee is a really terrible idea. One of the really great things
about the IETF is its open and free (as in beer) participation policy. The
real work is supposed to be done on mailing lists, and there's no
Real Time web.
This seems to me like the perfect application to show and eat own dog
food.
Regards,
as
On 8/16/13 9:07 AM, Hadriel Kaplan wrote:
The next step up from our current jabber-scribe model is to have audio input
- the ability for remote participants to speak using
On Aug 16, 2013, at 10:56 AM, Keith Moore mo...@network-heretics.com wrote:
As someone who just spent $3.5K out of pocket to show up in Berlin, I have a
hard time being sympathetic to someone who won't participate because he has
to spend $100 out of pocket.
This isn't about fairness or
On Aug 16, 2013, at 11:55 AM, Dave Crocker d...@dcrocker.net wrote:
On 8/16/2013 6:10 AM, Hadriel Kaplan wrote:
Since the topic keeps getting raised... I think that charging remote
participants any fee is a really terrible idea. One of the really
great things about the IETF is its open
, 2013, at 3:10 PM, Keith Moore mo...@network-heretics.com wrote:
On 08/16/2013 11:36 AM, Hadriel Kaplan wrote:
On Aug 16, 2013, at 10:56 AM, Keith Moore mo...@network-heretics.com wrote:
As someone who just spent $3.5K out of pocket to show up in Berlin, I have
a hard time being sympathetic
On Aug 16, 2013, at 1:53 PM, John C Klensin john-i...@jck.com wrote:
(1) As Dave points out, this activity has never been free. The
question is only about who pays. If any participants have to
pay
(or convince their companies to pay) and others, as a matter of
categories, do not, that
On Aug 16, 2013, at 6:39 PM, John C Klensin john-i...@jck.com wrote:
IIR, we've tried audio input. It works really well for
conference-sized meetings (e.g., a dozen or two dozen people
around a table) with a few remote participants. It works really
well for a larger group (50 or 100 or
I agree with Harald.
Both the STUN and TURN URIs really do represent what we traditionally use URIs
for: they identify a physical resource, a protocol for accessing the resource,
etc. Unlike a data URL, the STUN/TURN URI is not locally/directly
self-contained data - it's a resource
Some comments on this STUN draft and the TURN one:
1) The ABNF in these drafts leaves no room for future extension such as adding
parameters. Was that intentional?
2) Why do both of these docs repeat a lot of ABNF from RFC 3986, instead of
just referencing it? It says in the appendix some
[personal disclaimer: I have participated remotely, a few times, and I agree
that it's not the same as being there, and I agree that it could be improved.
But I think we need to balance the needs of remote participants, vs. the goals
of physical meetings: to get work done that can only get
Ugh. Ignore that email below - I had sent it a few days ago but somehow it got
stuck in the outbox and never got sent, and the discussion is past that point
now so it doesn't matter.
-hadriel
On Aug 12, 2013, at 12:35 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote:
[personal
Howdy,
You asked for community input, so I'll pipe up from the peanut gallery.
I happen to be looking for a JSON-ish on-the-wire encoding with binary support,
and I actually like what I see in CBOR. (I'll probably end up using
MessagePack anyway though... popularity has a quality all its own)
On Aug 10, 2013, at 10:21 AM, Ted Lemon ted.le...@nominum.com wrote:
The reason we call things proposed standard is because we expect
interoperability. A thing that can't have or affect interoperability
probably isn't a proposed standard. In this case, what we have is
definitely a
On Aug 10, 2013, at 12:25 PM, Ted Lemon ted.le...@nominum.com wrote:
On Aug 10, 2013, at 11:30 AM, Hadriel Kaplan hadriel.kap...@oracle.com
wrote:
That's fair, and I should have been clearer. I think 'Informatonal' is more
appropriate for now, because I don't think we know what
On Aug 7, 2013, at 2:26 AM, Riccardo Bernardini framefri...@gmail.com wrote:
Just thinking out aloud
What about a web-cam (maybe a wireless one? Never tried to use
them...) right under the mic, so that it takes a picture of the badge
and shows it on the screen? Everyone (right?) in a
On Aug 6, 2013, at 1:41 PM, Joe Abley jab...@hopcount.ca wrote:
In my experience, slides are mainly useful:
1. To convey information which is difficult to express accurately by voice
only (e.g. graphs, names of drafts, big numbers)
Yup.
2. To distract the e-mail-reading audience in the
[to no one in particular]
Uhhh... I can't tell if you folks are being serious about this idea or not, but
in case you are being serious... ISTM there's such a thing as too much
technology being a bad thing. If you think technical glitches now-and-then
cause issues with remote participants
On Aug 6, 2013, at 4:46 PM, Ted Lemon ted.le...@nominum.com wrote:
On Aug 6, 2013, at 4:37 PM, Hadriel Kaplan hadriel.kap...@oracle.com wrote:
If the problem is we don't know who's speaking, then fix that problem. In
WGs I go to, both the WG chairs and the jabber scribes regularly yell
, Hadriel Kaplan wrote:
And have separate rooms that require registering, like
[wg-name]@members.ietf.org or whatever,
We don't have, nor (I believe) do we want, members.
Yeah, members.ietf.org was a poor choice of domain name. I wasn't making a
formal proposal - just thinking out loud. I'd
On Aug 5, 2013, at 5:26 AM, SM s...@resistor.net wrote:
At 13:10 04-08-2013, Hadriel Kaplan wrote:
You have the agenda and drafts 2 weeks in advance. The slides aren't
normative. Even
I do not have the agenda two weeks in advance.
Huh. Sounds like a WG Chair problem. I believe draft
On Aug 5, 2013, at 8:03 AM, Abdussalam Baryun abdussalambar...@gmail.com
wrote:
I agree with you John, I also not objecting it but wanted more meaning into
the report when I receive it, as I suggested before for clarifications.
It's just a weekly posting summary of raw stats - it's not a
OK, I'll bite. Why do you and Michael believe you need to have the slides 1
week in advance?
You have the agenda and drafts 2 weeks in advance. The slides aren't
normative. Even when they're not about a draft in particular, the slides are
not self-standing documents. They're merely to
On Aug 4, 2013, at 4:20 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
There is another equally important reason for having them well in advance,
for both on-site and remote attendees: so that participants can review
them in advance, decide which of several clashing sessions to
On Aug 3, 2013, at 7:25 PM, John C Klensin john-i...@jck.com wrote:
First, probably to the when meetings begin part, but noting
that someone who gets onto the audio a few minutes late is in
exactly the same situation as someone who walks into the meeting
room a few minutes late --
it at a
young enough age to cover that up... mostly.
On Aug 4, 2013, at 7:10 PM, Spencer Dawkins spencerdawkins.i...@gmail.com
wrote:
On 8/4/2013 3:10 PM, Hadriel Kaplan wrote:
OK, I'll bite. Why do you and Michael believe you need to have the slides 1
week in advance?
You have the agenda
Howdy,
I've read the draft and overall it looks good.
Some minor comments:
The examples in section 5 of the draft repeatedly show a Via header as follows:
Via: SIP/2.0/TCP bob...@example.com;branch=z9hG4bK309475a2
This is not a legal Via header format, since the sent-by field cannot contain a
I am not sure why 10.64.0.0/10 is being discussed instead of 10.128/10 or
10.192/10... but let's assume we picked 10.192.0.0/10 instead. I'm sitting at
home and my laptop currently has this interface:
inet 10.2XX.XXX.XXX netmask 0xff00 broadcast 10.2XX.XXX.XXX
[specific digits
I have a question to the authors and ISPs as well, which may help explain why
using RFC 1918 and Class-E address space can't be done; or it may not if the
answer is different.
The question: could this new address space be used *without* a NATing CPE being
provided by the ISP? In other words,
Hi Victor,
Yes that helps, thanks - it confirms what I had always assumed was the case but
could not grok from the discussions on this list nor the draft.
Because the new address space is actually seen/used by the consumer's
interface, we cannot possibly pick a safe RFC 1918 address nor
On Dec 4, 2011, at 11:20 AM, David Conrad wrote:
It isn't a question of whether CGN can be deployed, it is a question of how.
As far as I can tell, lack of the a new /10 will simply mean ISPs get to make
an operational decision, the result of which will either be more rapid
exhaustion of
allocated a different one.
-hadriel
p.s. I didn't mean cannot possibly in the sense of it being technically
impossible, I meant it in the sense of it being a very bad idea. :)
On Dec 4, 2011, at 1:39 PM, Joel jaeggli wrote:
On 12/4/11 08:48 , Hadriel Kaplan wrote:
Hi Victor, Yes that helps
On Dec 4, 2011, at 2:26 PM, Joel jaeggli wrote:
It's not a question of starting. outside of some small number of
developed economies mobile carriers and a number of wireline providers
were always depolyed that way, or out of squat space however bad an idea
that may have been.
OK, yeah
On Dec 4, 2011, at 2:48 PM, David Conrad wrote:
2) Squat on someone else's space or un-allocated space. I don't think
that's a result we should want to happen, for obvious reasons. (I also don't
think it's likely many ISPs would do this either - just noting it's possible)
Say you are
On Nov 28, 2011, at 4:25 PM, Ronald Bonica wrote:
...
Because the October 10 last call elicited so little response, and because
many community members have privately expressed strong opinions regarding
this draft, I will summarize outstanding issues below. The following are
arguments
On Nov 16, 2011, at 7:58 PM, Brian E Carpenter wrote:
Please see the reader comment by Oor Nonny-Muss on this story to understand
its relevance to the IETF.
http://www.theregister.co.uk/2011/11/16/salad_leaf_turns_out_to_be_dead_bird/
Obviously the pigeon failed due to choking on all the
I think this whole thread is based on a misunderstanding.
The IETF provides a Jabber/XMPP server with chat rooms for each session. You
can use your own Jabber/XMPP client to access it, through an XMPP provider of
your choosing such as jabber.org. Now imagine jabber.org decided to *also*
On Nov 2, 2011, at 11:35 AM, Randy Bush wrote:
Meanwhile, I haven't heard anyone raise complaints about WebEx
then you ignored my earlier mail.
Actually didn't mean to - my mail app sorts emails into threads (Mac Lion
mail.app), and for some reason this one is a separate thread from the
On Nov 2, 2011, at 11:45 AM, Melinda Shore wrote:
Out of curiosity, if it's just another client, why is it being
promoted the way it is?
It's not a client. The Meetecho sessions use our own IETF standards to let
remote participants hear the audio, see the presentation slides, and see a live
I thought the counting of votes was finished on this topic but people seem to
keep emailing their support/lack-of, so naturally I will be a good lemming and
do the same.
1) I am in favor of the two-maturity-levels draft and change. I have consulted
a textbook on Euclidean geometry and
+1
-hadriel
On Aug 23, 2011, at 2:04 AM, John C Klensin wrote:
+1. I could also happily live with the alternate, more
compressed, schedule -- I think both are preferable to the
schedule used in Quebec and earlier.
john
--On Tuesday, August 23, 2011 07:40 +0200 Eliot Lear
If we use actual *attendance* as a form of voting, Minneapolis would lose big
time.
According to the stats, since IETF-1, there have been 6 IETF meetings in
Minneapolis. Every one of them had significantly lower number of participants
than the meeting before and after them... except IETF-44
Don't worry - this thread occurs on a regular basis, and let's us vent our
frustration at having an unsolvable problem.
But you do raise a good point about there being places west of Kauai. In fact,
my guess is every IETFer is either west or east of Kauai. Therefore, I propose
we hold a
Fascinating. I had no idea that there even *was* such a phrase in common
usage, let alone that there was known etymology for it. One learns something
new every day.
But I meant it quite literally: a moderate/humble/etc. proposal for Friday
meeting schedule.
-hadriel
On Aug 1, 2011, at
Howdy,
First I'd like to thank the organizers for IETF-81 for another well-run
meeting. The logistics and coordination for such an event must be daunting,
and I know we (the attendees) tend to focus on the negatives rather than the
positives... but we really are thankful for all the time and
I don't know about the real-time remote participation aspects because I'm at
the IETF in QC, but I did use the meetecho recorded sessions for a couple WGs I
didn't attend this week and I have to say it was great - better than the mp3
recordings of previous IETFs. While the mp3 had better
On Nov 15, 2010, at 7:21 AM, David Harrington wrote:
I believe I'm the AD you are referring to.
Yes but I wasn't trying to pick on anyone - just trying to understand what the
official IESG position is.
I never said the IESG is discouraging NAT traversal mechanisms for new
protocols,
Hi,
In one of the working group meetings this past week, when the group was
discussing a NAT traversal solution for their new protocol, an A-D suggested
they not spend much time on NAT traversal. He/she indicated the IESG was
discouraging NAT traversal mechanisms for new protocols, in order to
I find it hard to believe you guys don't object to the badge checking in
particular, but just to the idea that a host/hotel would dictate such a policy
without notifying you in advance.
The host/hotel apparently also decided to have hotel staff pouring our coffee
and opening the doors for us,
On Nov 11, 2010, at 11:04 AM, Peter Saint-Andre wrote:
Security on the terminal room is long-standing. It has equipment in it.
To be fair, so might the meeting rooms (audio equipment, projectors,
etc.). Perhaps in this instance the hotel was concerned about theft of
such equipment.
On Oct 31, 2010, at 5:27 AM, Julian Reschke wrote:
All RFCs published since last January have that pointer in the
boilerplate, it goes to
http://www.rfc-editor.org/info/rfc
Sweet. :)
I actually checked the boilerplate I use for I-D's before saying it, but I
guess my boilerplate is
On Oct 31, 2010, at 12:00 AM, Masataka Ohta wrote:
TJ wrote:
I would be quite curious to know your definition of failure, given that
IPsec is currently deployed, and working in more than a few deployments
...
Sorry for lack of clarification.
My context is IPsec in the Internet, which
I don't think it's resistance to changing a process that we are not following
- I think it's which part of the process we think isn't working, or which part
is IMPORTANT that isn't working.
Going from three steps of which only one step is used, to two steps of which
only one step will be
Hi Ted,
I was with your statements all the way to this:
Russ's draft tries to
do two things:
Restore the 2026 rules for Proposed as the functionally in-use bar for the
first rung.
...
What makes you say that?
I read the draft and I don't see it doing that, really. I know it says:
The
On Oct 14, 2010, at 4:27 PM, Cullen Jennings wrote:
3) The backwards comparability issue seems huge. Some people have said an
endpoint using this draft will not talk with one that only does 4975. Yet if
this draft if published as an RFC would basically depreciate the 4975 and
replace it
On Oct 27, 2010, at 9:57 PM, Keith Moore wrote:
That's why I think we need a different set of labels, e.g.
Protocol-Quality. We need a statement about the perceived quality of the
protocol described in the document. (Is this protocol well-designed for the
anticipated use cases, or does it
On Oct 29, 2010, at 2:37 PM, Keith Moore wrote:
On Oct 29, 2010, at 12:36 PM, Michael Richardson wrote:
In-person meeting time is used regularly for powerpoints rather than
discussion.
I've been yelled-at in WG meetings for using the microphone meeting time for
discussion, vs. position
On Oct 26, 2010, at 2:39 PM, Dave CROCKER wrote:
I'm a fan of reducing down to 2 levels, too. But it has nothing to do with
how
overblown the effort to get to Proposed is. (Well, there's some pretty
simple
psych logic that says that it could actually make the barrier to Proposed
On Aug 30, 2010, at 6:21 PM, Randall Gellens wrote:
Why Kauai? You list detailed reasons why Hawaii is logical and
solves for many of the problems, but you don't say why this island.
Because it's the nicest, obviously. :)
We can even rotate islands if people get bored.
Well,
The obvious answer is to pick a location that is equi-distant or equally
expensive for most people, and does not meet too often in one contintent.
There is such a place: Hawaii. It is fairly mid-point between APAC and the
Americas, and just slightly farther from Europe (well, a lot farther
, August 19, 2010 6:41 PM
To: Hadriel Kaplan
Cc: ietf@ietf.org
Subject: RE: Varying meeting venue -- why?
If someone offered to sponsor a meeting there, I bet the IETF would
consider it. First, it actually has an airport, and second
there is
alternative public transportation: bus service
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
John Levine
Sent: Friday, August 13, 2010 1:04 PM
The US is a big place. Even the eastern US is a big place. I think
it'd be a swell plan to meet in Ithaca, New York, where I live (it has
Since you guys are affecting my top-of-the-list status for the weekly posting
summary, I'm gonna have to jump in... :)
We can all claim our environment doesn't change our views, but that's hard to
reconcile with human behavior research.
Regardless, I think even you'd agree that one's views on
Howdy,
I said I would shut up, but I missed one question from Cullen, which was:
This conversation constantly confuses the issue of must implement vs must
deploy. Which one are you objecting to here.
Answer: I am objecting to there not *being* a distinction between must
implement vs. must
-Original Message-
From: Richard Shockey [mailto:rich...@shockey.us]
Sent: Thursday, April 08, 2010 10:34 AM
Lets not forget what this specification was attempting to solve, which has
been the well known boot strap problem with SIP-CUA's we have collectively
ignored since the
-Original Message-
From: Scott Lawrence [mailto:xmlsc...@gmail.com]
Sent: Thursday, April 08, 2010 9:37 AM
To: Hadriel Kaplan
Well, one could argue that a provider could cause the returned SIP url
for the change notice subscription to be one for which there is no
routing (return
-Original Message-
From: Scott Lawrence [mailto:xmlsc...@gmail.com]
Sent: Thursday, April 08, 2010 4:51 PM
On Thu, 2010-04-08 at 15:15 -0400, Hadriel Kaplan wrote:
Right, but the since that would make it an unknown validity config,
and the requirements do not mandate any UA
-Original Message-
From: Cullen Jennings [mailto:flu...@cisco.com]
Sent: Tuesday, April 06, 2010 11:53 AM
To: Hadriel Kaplan
However,I did want to comment on the use cases for this. There are many
service providers that think it is important to be able to push a new
-Original Message-
From: Cullen Jennings [mailto:flu...@cisco.com]
Sent: Tuesday, April 06, 2010 12:56 PM
To: Hadriel Kaplan
No one has any empirical evidence or experience with what this thing
will do to large subscriber domains. (and by large I mean multiple
millions
Perhaps that would stop all of these LOOP MAIL DETECTED messages I keep
getting back from kisa.or.kr every time I post to this (particular) email list.
Anyone else getting those?
-hadriel
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
...@cs.columbia.edu]
Sent: Tuesday, April 06, 2010 1:59 PM
To: Hadriel Kaplan
Cc: Cullen Jennings; IETF Discussion Mailing List
Subject: Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session
Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Avalanche (restart) has
-Original Message-
From: Scott Lawrence [mailto:xmlsc...@gmail.com]
Sent: Tuesday, April 06, 2010 2:10 PM
To: Hadriel Kaplan
On Tue, 2010-04-06 at 13:39 -0400, Hadriel Kaplan wrote:
This draft says nothing at all about the ordering of the change notice
subscription vs any
-Original Message-
From: Cullen Jennings [mailto:flu...@cisco.com]
Sent: Monday, April 05, 2010 10:07 AM
To: Hadriel Kaplan
On Apr 1, 2010, at 12:59 PM, Hardier Kaplan wrote:
1) The mechanism does not scale, for large SSP's. (is this only meant
for small deployments?)
Why
-Original Message-
From: Scott Lawrence [mailto:xmlsc...@gmail.com]
Sent: Monday, April 05, 2010 11:00 AM
To: Hadriel Kaplan
On Fri, 2010-04-02 at 12:05 -0400, Hadriel Kaplan wrote:
Obviously you could make the expiration interval long, but however
long you make
-Original Message-
From: Scott Lawrence [mailto:xmlsc...@gmail.com]
Sent: Monday, April 05, 2010 11:00 AM
To: Hadriel Kaplan
One of the things that I personally fought very hard for in this
specification was removing optional behavior and choices of any kind
whenever possible
-Original Message-
From: Scott Lawrence [mailto:xmlsc...@gmail.com]
Sent: Monday, April 05, 2010 2:30 PM
To: Hadriel Kaplan
The spec says in section 2.6
(Validity of Stored Configuration Data):
The UA MAY use configuration data that is of unknown validity
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Scott Lawrence
Sent: Monday, April 05, 2010 3:55 PM
On Mon, 2010-04-05 at 15:09 -0400, Hadriel Kaplan wrote:
This form of optional is right up that alley. For example, if I am a
service
Not to belabor this thread, but...
I was in Schiphol the week before IETF Anaheim and bought a train ticket.
*None* of the my cards worked (Amex, Visa, Mastercard, and a debit, and yes I
tried all of them). In fact, not only did they not work at the machines, but
they were not accepted at
-Original Message-
From: Dave CROCKER [mailto:d...@dcrocker.net]
Sent: Friday, April 02, 2010 7:02 PM
To: Hadriel Kaplan
On 4/2/2010 3:46 PM, Hadriel Kaplan wrote:
p.s. on the other hand they have excellent licorice and hagelslag. :)
You could pay with licorice?
Did
Howdy,
This may not be within the normal rules of etiquette, but I will re-iterate my
issues with this draft which I raised when it was discussed in RAI.
1) The mechanism does not scale, for large SSP's. (is this only meant for small
deployments?)
Expecting every UA to keep a permanent SIP
At 11:01 AM 7/5/2009, Joel M. Halpern wrote:
I have seen some folks arguing that we should make XML2RFC normative
and mandatory. If they can figure out how to automatically and
accurate convert the other mechanisms people use, then that can be
considered. Otherwise, mandating would be
I realize the point of getting a small group of people as lab rats is to get a
first pass before the deluge, but I have just a couple very quick questions
that you can ignore as spam. :)
1) What is the scope of the redesign? Is it just www.ietf.org, or does it
include tools, datatracker, and
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Bill Manning
Do people seriously think (or fear) they are are getting scanned in
the room?
i have emperical evidence of the fact.
Not that I don't believe you, but it baffles my mind as
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Eric Rescorla
At Fri, 04 Apr 2008 10:22:42 +1100,
Mark Andrews wrote:
It's is the only unique token on the blue sheets. This
assumes no shared email accounts which is a pretty
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Dave Crocker
Eric Burger wrote:
2. Legal issues: When the inevitable patent dispute happens, we WILL get
served to report who was in the room when a particular subject was
discussed.
This is
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Michael Thomas
Mike, could be a dog too
I'm not sure what you people have against canines - if a dog can email in
cohesive comments on a draft or working group topic, I say we should
If 1000 fewer people board planes, I'm pretty sure it consumes some trivial
amount less in jet fuel, simply due to the lighter weight of the plane. But
that difference would be more than made up by the proximity of the hotel to the
airport and available mass transit to it, which would put San
93 matches
Mail list logo
